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

[Roman Shpount <[e-mail]>]

On Thu, Mar 17, 2016 at 11:46 AM, Paul Kyzivat <[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