Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <> Wed, 12 March 2014 08:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5BE001A090D for <>; Wed, 12 Mar 2014 01:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ctfqM8CnBcac for <>; Wed, 12 Mar 2014 01:16:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 66C781A08FA for <>; Wed, 12 Mar 2014 01:16:36 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-3f-532017dd77e5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 74.55.23809.DD710235; Wed, 12 Mar 2014 09:16:29 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 09:16:28 +0100
Message-ID: <>
Date: Wed, 12 Mar 2014 09:16:29 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Christer Holmberg <>, Justin Uberti <>, "" <>, Eric Rescorla <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RveuuEKwwboLRhYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8biR5EFG0wrLm46y9bAeFGr i5GTQ0LARGLn1WVsELaYxIV764FsLg4hgUOMEp0rN7BDOMsZJdpuvGEFqeIV0Jb4euM9M4jN IqAqcX/PLHYQm03AQuLmj0awSaICwRI7D/xmhKgXlDg58wkLyCARgYWMEtsvb2YBSQgLGEsc uryUGWLDFmaJO9cvgSU4Bfwk1v3bB5TgALpJXKKnMQgkzCygJzHlagsjhC0v0bx1NtgRQkAH NTR1sE5gFJyFZN8sJC2zkLQsYGRexciem5iZk15utIkRGKQHt/xW3cF455zIIUZpDhYlcd4P b52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCWdEx5lHPwrF6b5qHn239E9zqVuq5MPSyk HzlV9UAV58S91j+tU/31b6okmzy4bhX9VOORQ3TkU0ub50cDo5WvKM7QvC14Z1blWYZ9+gIh Pv/KqwN7dv1zCa8ovtgov3Wf3cK370+KJwsIZxzezFfX/evU7+z/qc8mi5+6OTPb4ILMi6d+ +5crsRRnJBpqMRcVJwIAAugHxCACAAA=
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Mar 2014 08:16:39 -0000

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.


Magnus Westerlund
(As individual)

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: