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

[Roman Shpount <[e-mail]>]

On Mon, Mar 21, 2016 at 6:17 AM, Christer Holmberg <
[e-mail]> wrote:

> >>>> In my opinion, a=rtcp-mux PLUS a=rtcp with RTP port would be an easy
> was to indicate mux-exclusive, and it would work both with ICE and non-ICE.
> I don’t think we should define multiple mechanisms for doing the same thing.
> >>>
> >>>I would argue that a=rtcp is completely redundant potentially ignored
> information. It does not indicate (at least not yet) that trickle will not
> generate RTCP candidates. If ICE is used, the
> >>>absence of RTCP candidates is enough to indicate that RTCP should not
> be sent yet. If ICE is not used, there is no grantee that a=rtcp is not
> ignored, so >it does not help. So, we can just include rtcp-mux and do not
> include any RTCP candidates, and we will get the result we need without any
> new specifications.
> >>
> >>How does the receiver know that RTCP candidates won’t be trickled later?
> >
> > If offer contained rtcp-mux and answer specified rtcp-mux, rtcp-mux will
> be used. Because of this, answerer always knows if rtcp-mux is used. Even
> if RTCP candidates will be trickled later, they will not be used and can be
> safely ignored.
>
> An “mux transcoder” needs to know about exclusive mux when it receives the
> offer – it cannot wait for the answer.
>
>
Are you saying that "mux trancoder" which converts trickle ICE into non-ICE
or non-trickle needs to know in advance that it needs to allocate an RTCP
address/port in the offer it generates on the other side of transcoder?

This is somewhat feasible but extremely marginal. Such transcoder would
have to convert between rtcp-mux and non-mux anyway. Since there is no way
to force rtcp-mux-exclusive on any legacy end points, such transcoder will
need to deal with rtcp-mux mismatch between the two call legs anyway.
_____________
Roman Shpount