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

[Eric Rescorla <[e-mail]>]

On Fri, Mar 4, 2016 at 9:34 AM, Christer Holmberg <
[e-mail]> wrote:

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


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


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?


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?
>

I'd rather first resolve whether any change at all is indicated.

-Ekr


>
> Regards,
>
> Christer
>
>