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.
>
> No, I see a path of grief to not explicitly signal things when you use them. 

But, the whole idea of using port zero in bundle-only was that, if the answerer supports BUNDLE, port zero will be replaced with the negotiated address:port.

When you send the offer, you don't yet know which address:port will be selected, so there is no idea to insert a=rtcp. Inserting a=rtcp-mux probably doesn't harm, though, so I won't argue about it :)

>I also thought the a=rtcp-mux is a MUST to implement, not a MUST use.

Currently the draft says MUST use. But, that may be a mistake, or a leftover from previous procedures. I agree that one should be able to use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports for the RTP traffic and the RTCP traffic).
 
>> 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.
>
>My understanding is that a=rtcp has been required in any non-private network deployments due to >NATs for the last 10 years. Thus, I don't see how you can remove them and expect it to work, unless >you are doing a=rtcp-mux. Thus, my view would be that you can remove a=rtcp if you know that the >peer supprots a=rtcp-mux.

Are you saying that we should use a=rtcp ONLY to indicate the RTP port, in case the answerer does not support a=rtcp-mux?
 
>> 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?
>
> That is a=rtcp-mux per RFC 5761 that has higher priority, please see Section 5.1.1.

You are right - my mistake.

But, never the less, if the offerer sends both a=rtcp-mux and a=rtcp, unless a=rtcp points to the rtp port, the offerer needs to be prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and rtp+<a=rtcp value>), because it does not know which attribute (if any) the answerer supports, and which (if any) the answerer is willing to use.

Regards,

Christer