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

[Christer Holmberg <[e-mail]>]

Hi,

>>>>But, we agreed that we want to have an explicit indicator,
>>>
>>>My point is that I think that that agreement was wrong and we should not do so.
>>
>> I think such statements should be given when the chairs initially ask the community whether it is something we 
>> should work on in the first place - not during WGLC, after people have spent time and effort on defining the feature.
>
>Yes, I agree it would have been better to have made this comment then, sorry about
>that. Nevertheless, sunk cost seems like a poor reason to continue with a feature
>which is not useful.

Well, I do think it is useful to have a mechanism to indicate exclusive mux.

a=rtcp-mux means you support fallback to non-mux, and I don't think we should have a mechanism where people have to do a try-and-fail to figure out that you can't do fallback. I also think it's misuse of the attribute.

>>>>and then we can only hope people will implement it (by mandating support of it etc).
>>>
>>>But again, why would you?
>>
>>Because then you will have a mechanism to explicitly indicate that you can do mux only, without having to 
>>test-and-fail. The current rtcp-mux attribute indicates that you are able to do fallback to non-mux, and 
>>entities (endpoints and intermediaries) will have to have resources if that happens.
>>
>>Also, in non-ICE cases there will be no candidates, so entities will always have to assume that the rtcp-mux attribute indicates possibility to fallback to non-mux.
>
>I'm sorry, I'm asking a different question: I don't think there's a problem with new endpoints
>emitting this, but I am skeptical that any old endpoints (i.e., the ones that presently don't
>do mux) will add detection for this rather than just adding mux. Can we point to a significant
>population of implementors which intends to add this?

There are WebRTC gateways that, if they receive a=rtcp-mux, may fallback to non-mux (due to different policies related to radio, the core network etc). 

I know about at least one company that intend to implement a=rtcp-mux-exclusive in the WebRTC gateway. If non-mux is then required in the core network, the gateway will then do mux/non-mux "transcoding".

I also know about SBCs that, if they receive the attribute, will not reserve resources for RTCP, because they know that they don't need to support any fallback.

Now, in earlier versions of the draft, the offerer included BOTH a=rtcp-mux and a=rtcp-mux-exclusive, so that older endpoints (that don't support mux exclusive) would know that the offerer supports mux. Perhaps we should put that back?
 
Regards,

Christer