Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

[Flemming Andreasen <[e-mail]>]

On 3/5/16 12:10 PM, Eric Rescorla wrote:
> I think we're just repeating ourselves. Chairs, can we please reserve 
> some time in
> B-A to discuss this?

Sure. In the mean-time, we would like to hear from more people on this. 
As Christer noted, there were several people in favor of adopting this 
work when we asked in mid-December 2015, so we would like to understand 
if anything has changed since then.

Thanks

-- Flemming (as MMUSIC co-chair)




> -Ekr
>
>
> On Sat, Mar 5, 2016 at 7:39 AM, Christer Holmberg 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     >>> Yes, of course, but the question is how they will behave if
>     they receive rtcp-mux-exclusive.
>     >>
>     >> IF (for whatever reason) non-mux is required on the "other
>     side" of the gateway then the gateway will do "transcoding"
>     between mux and non-mux.
>     >
>     > Given that essentially every Web browser is going to do only
>     mux, it seems like the gateway
>     > can just infer this. In fact, since in most of these cases, the
>     gateway and the Web app are
>     > related entities, that should be extremely straightforward.
>
>     WebRTC is more than browsers, and mux-exclusive is more than
>     WebRTC. There is a general wish to move towards mux. However, that
>     is not going to happen over night.
>
>     >>> Can we get those implementors to speak up on the list?
>     >>
>     >>I represent one of those implementers :)
>     >
>     >Yes, I had assumed so.
>     >
>     >Bottom line, this seems like just another piece of complexity for
>     minimal value, so I
>     >propose dropping it.
>
>     I don't see the complexity - it's adding a static attribute
>     without a value, in the same way you add a=rtcp-mux. If your
>     browser is always only going to do mux there is no need for any
>     additional logic or configuration.
>
>     Also, I don't agree with minimal value. Reserving RTCP resources
>     that may never be needed, and/or doing mux/non-mux transcoding
>     "just in case" is not minimal. Maybe for single-user device, but
>     not for devices handling large number of users.
>
>     And, again, from a protocol perspective, a=rtcp-mux means you are
>     able to fallback, and I don't think we shall break that semantics.
>     There are enough problems related to offer/answer, we don't need
>     to create more on purpose.
>
>     Regards,
>
>     Christer
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic