Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

[Roman Shpount <[e-mail]>]

On Mon, Jan 25, 2016 at 12:57 PM, Christer Holmberg <
[e-mail]> wrote:

> We need to ask ourselves FOR WHAT we would need something new.
>
> Do we need something new in order to indicate an non-RTP+1 RTCP port
> number? Some people say we don't: as ICE becomes more and more deployed,
> you will use candidates to indicate the RTCP port number. The a=rtcp value
> won't even work in many cases - no matter if entities can indicate support
> for the attribute or not.
>
> Do we need something new in order to indicate exclusive-mux? My opinion is
> that we do, because e.g. in trickle ICE cases you will not be able to
> indicate exclusive-mux using candidates.
>
> The launch customers of exclusive-mux are WebRTC enabled browsers, and any
> entity that wants to communicate with such browsers needs to support ICE.
>
>
I agree.

If end-points are deployed behind NAT they really should use ICE. If end
points are not deployed behind NAT they do not need a=rtcp. I think what we
need the simplest possible solution that works with end points on public
addresses and end points that use ICE. I think a simple, flag like
negotiated attribute would be ideal for this.

Furthermore, we should decide if we care about few RTCP packets being sent
during the session setup by an end point that does not understand a=rtcp,
a=mux, or new attribute. If we can allow those packets, then flag like
attribute is sufficient. If we need to block those few packets, then we
need to either set c= line to IN IP4 0.0.0.0 or m= line port to 0 and
provide the actual address/port elsewhere.

Finally, whatever design is used, I would like to see something that would
definitely fail to setup the media session when both sides do not support
RTCP mux. What I would like to avoid is an end point continuously sending
RTCP to address/port which is not expecting it. When deploying this can be
a hard issue to detect during the interop testing and it can produce a lot
of interesting and unexpected results. This is one of the reasons I do not
linke a=rtcp only solution.

Regards,
_____________
Roman Shpount