Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Christer Holmberg <[e-mail]>]

Hi,

>> 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
>> :)
>
> Well, if you can't insert the port, the same applies to a=rtcp as to the port in the m= line.

Exactly. 

The bundle-only m- lines will "inherit" the port that is selected for the whole BUNDLE group.

> Because in the bundle-only case we are assuming and that assumption needs to apply also for a=rtcp. And for a bundle-only case 
> I think the appropriate thing is to assume that a=rtcp-mux will be honored. To have it being honored you need explicit signal it. 

Sure. But, the important thing is to include a=rtcp-mux in the m- line that will be used for selecting the BUNDLE address. That will determine whether rtcp-mux will be used or not.

> The a=rtcp can be considered redundant in this case, but I am sensitive to removing it as that would create a special case for a=bundle-only lines. I think it is better to simply include it, even if it will say a=rtcp:0

We can do that, if people think it's a good idea.


>>> 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).
>
> I hope if people disagree that they shout now.

And shout loud :)


>>>>> 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?
>
> It has its normal usage, i.e. RTCP port in cases when a=rtcp-mux is not agreed on. In a bundle-only offer, I think the only reasonable approach is to handle it identically to the m= line port number.

I don't know what you mean by "bundle-only offer". There must exist at least one non-bundle-only m- line in an offer, in order to indicate the port value. And, whatever a=rtcp value is used in that m- line will also be applied to the bundle-only m- lines is the BUNDLE group is accepted.
 
>>>> 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.
>
> This is actually not necessary, if one can get the rtp+1 port for RTCP, then include that in the a=rtcp line and everything is fine.
>
> I was under the impression that almost all SIP SDP O/A was using a=rtcp.
> But if that is a misunderstanding from my perspective, I still think the rules will hold. If you don't include the a=rtcp attribute, then the
> rtp+1 port is the equivalent of the a=rtcp value.
>
> From a bundle perspective, I think what needs to be considered is the actual or implied values on the m= blocks for the rtcp port when using bundle-only as well as the other case.

It may be that we agree, but talk past each other :)

My understanding of bundle-only has been that it is a mechanism to ensure that the m- line is accepted only if the BUNDLE group is accepted, e.g. in order to avoid having to reserve extra ports. BUT, the bundle-only m- lines are NOT used to negotiate the actual BUNDLE address - they will inherit the selected BUNDLE address, negotiated using non-bundle-only m- lines.

Regards,

Christer