Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Christer Holmberg <[e-mail]>]

Hi,

>>>> Before I comment on your proposal, let's take a few steps back 
>>>> (maybe it can even solve your issue).
>>>> 
>>>> BUNDLE currently mandates the usage of both the SDP rtcp-mux and 
>>>> rtcp attributes. I remember we had discussions about that, but I 
>>>> don't remember the justification at the moment. But, I wonder 
>>>> whether that text is from before we made a decision that, unless 
>>>> both endpoints support BUNDLE, no endpoint will use a single 
>>>> address:port.
>>>> 
>>>> 
>>>> 
>>>> So, the question is: do we really need the SDP rtcp attribute?
>>> 
>>> I think it is a question of how you want the fallback to work. In the 
>>> case of bundle only lines, a non  bundle supporting peer will reject 
>>> them, thus no issues with what is written around RTCP-mux and a=rtcp 
>>> in those m= blocks. However, the first one if you want that to 
>>> support fallback that makes sense then you will need both a=rtcp-mux 
>>> and an a=rtcp (with a different port) to handle that with optimal 
>>> backwards compatibility.
>>> 
>>> Regarding the motivation for a=rtcp-mux and a=rtcp, I think it is 
>>> reasonably straight forward. We want a=rtcp-mux to minimize port 
>>> usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle that would 
>>> mean two ports (RTP and RTCP) for the bundle group. To get the 
>>> backwards compatibility the usage of a=rtcp would be required.
>> 
>> Keep in mind that the offerer must always be prepared that the 
>> answerer does not support the rtcp-mux attribute (or the rtcp 
>> attribute).
>
> Yes, that was what I meant with fallback in the above text. What you do in case the peer doesn't support bundle.
> 
>> So, at least my understanding is: no matter whether BUNDLE is used or 
>> not, if the answer does not contain a rtcp-mux (e.g. in case of
>> fallback) attribute, the offerer must use the default "rtp+1" port.
>
> I have a tendency to agree, which means that the first m= block in a bunde-only group will be required to contain a=rtcp and if RTCP mux is desired also that attribute.
>
> I think a=rtcp could be skipped for a bound-only m= block due to the requirement on supporting a=rtcp-mux if you do bundle.

For bundle-only, I actually think BOTH can be skipped, because bundle-only will by default use whatever address:port is negotiated - both for RTP and RTCP.

But, for non-bundle-only, I still ask whether we really need a=rtcp. Isn't a=rtcp-mux enough? If the answerer supports it, you will use it, otherwise you will use rtp+1.

Otherwise, assume that the answerer supports BOTH a=rtcp and a=rtcp-mux. Which has higher "priority"? How does the answerer knows whether the offerer wants to use rtcp-mux, or whether it wants to use whatever port is indicated in a=rtcp?

Regards,

Christer