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

[Roman Shpount <[e-mail]>]

On Wed, Mar 9, 2016 at 2:09 AM, Christer Holmberg <
[e-mail]> wrote:

> Any opinions?
>
> If I remember correctly, it was mainly Roman who didn't want to use
> a=ssrc. However, it does seem like a straight forward (and most backward
> compatible) mechanism.
>

I was against a=rtcp for two reasons:

1. There is a conflict with RFC 5245 and things derived from it such as
JSEP which caused confusion. I have proposed the language to
draft-ietf-mmusic-ice-sip-sdp to make a=rtpc optional. I am not sure if
this was accepted or is still being discussed. If this language is accepted
then this reason goes away.

2. I want to limit a=rtcp for non-ICE end points only or only when interop
with non-ICE end points is desired. For anything modern which will not work
without ICE, such as webrtc, there is no reason to specify RTP address in
c= and m= lines, or RTCP address in a=rtcp. I do not want to create new
usages for a=rtcp to keep it alive after it have outlived its usefulness.
For webrtc, including a=rtcp-mux, setting c= address to IN IP4 0.0.0.0, m=
to port 9, and not generating any RTCP ICE candidates should be enough to
indicate what we want to achieve with a=rtcp-mux-only.

As far as a=rtcp-mux-exclusive is concerned, I see it as a optimization
attribute which helps in the following two cases:

1. Tells the remote end point not to allocate RTCP ICE candidates if
trickle ICE is used. This can be an ice-option. I would actually prefer the
ice-option to say the opposite, i.e. that RTCP candidates will be
allocated, since not allocating RTCP candidates will be a much more common
flow.

2. Tells any RTP forwarding intermediaries such as SBC, not to allocate any
resources to forward RTCP. I think this is really marginal

Regards,
_____________
Roman Shpount