Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Magnus Westerlund <[e-mail]>]

On 2014-03-10 21:09, Christer Holmberg wrote:
> 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
> :)

Well, if you can't insert the port, the same applies to a=rtcp as to the
port in the m= line.

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. 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

> 
>> 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.

> 
>>> 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.

> 
>>> 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.

Cheers

Magnus Westerlund
(As individual)

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------