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

[Christer Holmberg <[e-mail]>]

Roman,

In my opinion, what you are suggesting goes far outside the scope of mux-exclusive.

Regards,

Christer

From: mmusic [mailto:[e-mail]] On Behalf Of Roman Shpount
Sent: 17 March 2016 19:47
To: Paul Kyzivat <[e-mail]>
Cc: [e-mail]
Subject: Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

On Thu, Mar 17, 2016 at 11:46 AM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>> wrote:
On 3/17/16 11:29 AM, Roman Shpount wrote:
This enforces something to be specified in c= line, m= line and
a=rtcp-mux attributes. Because of this it prevents removal of those
attributes in the future.

Why do you want to remove these attributes? What is the harm in having them?

If all parties support ICE, there is no additional useful information carried by c= line address, m= line port and a=rtcp port address (there was a typo in my original message where I incorrectly listed a=rtcp-mux). All this information is already available in ICE candidates. Also, ICE is trying to keep address information between the selected ICE candidates and  c=, m=, and a=rtcp synchronized, which causes it to send an extra re-INVITE.

More importantly, if ICE is used without trickle, if offer is sent with a=rtcp-mux, c=IN IP4 0.0.0.0, m= line has port 9 and there no RTCP candidates, this end point achieved all the required goals of a=rtcp-mux-exclusive. No RTCP will be ever sent to this end point. If a=rtcp-mux is not present in the answer, connection can be dropped. No additional resources will be allocated by any intermediaries. This is what we are trying to solve and we get this for free.

If we require that ICE trickle require a=rtcp-mux, then we get the solution for free there as well.

All we have left are end points that are not using ICE, but this does not affect WebRTC, so it is much less time sensitive. For legacy endpoints we can require a=rtcp set to the same port as RTP, but since this is not guaranteed to work, and since absence of a=rtcp-mux support can be easily detected, this is either not a problem at all (if you can tolerate small number of RTCP packets sent to the random IP:port) or much harder problem to solve cleanly (since we never know if a=rtcp will be or was supported by remote).

Regards,
_____________
Roman Shpount