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

[Christer Holmberg <[e-mail]>]

Hi,

>I've been reading this document and I'm finding myself confused about
>why we need it.
>
>As I understand it, the current state of play is that mux-only
>endpoints will send offers with both a=rtcp-mux and one set of
>candidates for each m= line (and with trickle, perhaps no candidates
>in the initial offer).  If that offer is processed by a non-mux
>endpoint, that endpoint will reject rtcp-mux and then eventually you
>end up with a failure to negotiate transport connections because there
>will never be RTCP-candidates.
>
>What this draft seems to offer is that a way for the mux-only endpoint
>to indicate that it is mux-only, so that non-mux endpoints can instead
>fail the connection immediately (section 4.3). So you get a hard
>failure instead of a transport failure. Is that correct so far?

Correct.

>If so, here's my problem: because unknown a= lines are ignored, old
>endpoints won't know about rtcp-mux-exclusive and so they will just
>ignore it. Thus, this attribute is only useful for *new* endpoints
>which don't want to do mux (but do know about this attribute). I
>suppose that endpoints like that might exist (maybe gateways) but I'm
>skeptical that it's worth extra effort to have a hard fail here.

Unfortunately this is related to a general problem with SDP -you can't mandate support of features (for SIP, one can always define an option tag and place it in a Require header field).

But, we agreed that we want to have an explicit indicator, and then we can only hope people will implement it (by mandating support of it etc).

Regards,

Christer