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

[Roman Shpount <[e-mail]>]

On Thu, Mar 17, 2016 at 10:45 AM, Christer Holmberg <
[e-mail]> wrote:

> >We kind of need two solutions --  one which works with ICE and another
> that works with legacy. If we fix the issue with a=rtcp attribute
> handling by draft-ietf-mmusic-ice-sip-sdp and stop requiring
> >it when it serves no purpose, then we can use a=rtcp-mux plus RTP
> candidate to indicate mux-exclusive when ICE is used, and a=rtcp set to RTP
> address and port when ICE is not used (legacy).
>
> I am not sure a=rtcp-mux plus RTP candidate would require removal of
> a=rtcp usage, because today a=rtcp does not contain the RTP port (as it
> would in case of mux-exclusive).
>

ICE candidates contain both RTP and RTCP addresses and ports. If all end
points in the deployment support ICE, address in c= line, port in m= line
and a=rtcp are completely redundant. I actually would like to see to move
to "ICE only" solution where there is IN IP4 0.0.0.0 is always specified in
the c= line, port 9 in m= line and no a=rtcp is added. In this scenario a
re-INVITE when ICE candidate is selected is also removed.


> >We can use both together (a=rtcp-mux plus RTP and a=rtcp set to RTP) when
> ICE with legacy fall back is required.
>
> My apologies if you already said it, and I missed it, but how does
> a=rtcp-mux plus RTP work with trickle? How does the receiver know that the
> RTCP candidate won’t be trickled later?
>

What I was proposing that ICE trickle either always requires rtcp-mux or
that there are two ice-option values are defined -- one for trickle with
RTCP and another for trickle with rtcp-mux required where no RTCP
candidates will be trickled later.
_____________
Roman Shpount