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

[Christer Holmberg <[e-mail]>]

Hi,

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

I know what you would like to see, but my point was that the a=rtcp-mux plus RTP solution doesn’t require such change, does it?

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

I think it’s clumsy to have two different tags for trickle, based on whether RTCP candidates will be provided or not.

Regards,

Christer