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.
>
> Well, they're going to fail anyway, so failing fast seems of modest value.

Entities that don't support the attribute will obviously fail, but at least we would have a mechanism to indicate exclusive mux.


>>>>>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).
>>
> 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.

>> 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.
>
> Can we get those implementors to speak up on the list?

I represent one of those implementers :)

Regards,

Christer