Re: [MMUSIC] Simulcast worries: What bitrate? (from the WEBRTC list)

[Adam Roach <[e-mail]>]

On 10/23/15 08:37, Magnus Westerlund wrote:
> Den 2015-10-22 kl. 16:56, skrev Adam Roach:
>> On 10/21/15 08:42, Harald Alvestrand wrote:
>>> I'd be happier if we could say "this is the same bitrate as b=TEAS" or
>>> something like that - if an implementation has to stick to multiple
>>> definitions of bitrate for the same media flow, which will happen with
>>> a=rid .. max-br and b= in the same message, it would be nice to be able
>>> to use the same counters.
>>
>> I'm good either way. We can keep this as-is, or add a reference to
>> RFC3890. Anyone want to speak for or against moving over to the RFC3890
>> definition of bandwidth?
>
> Hi,
>
> I am of the opinion (having authored RFC 3890) that we should use a 
> more well defined bit-rate definition than what is in TIAS.
> In fact the current definition is well matching that of TIAS, with the 
> additional constraints of a measuring interval. I think this is the 
> minimal improvement we should do.

I read this to say that you think the text in draft-ietf-mmusic-rid is 
sufficient without any external reference. I'm happy with that as an 
answer. :)

> I can argue for an even more specific bandwidth definitions. My 
> personal position is that the stream specific ones (SMT and SLT) in 
> our SDP bandwidth proposal (now expired) actually makes sense to be 
> used with RID:
> https://www.ietf.org/archive/id/draft-westerlund-mmusic-sdp-bw-attribute-02.txt 
>

All of the definitions in that document are problematic for the vast 
majority of WebRTC's use cases, since they all include the phrase 
"including protocol overhead."   In general, web browsers operate high 
enough on the protocol stack that getting access to "protocol overhead" 
introduced by layers 1 through 4 is simply implausible.

/a