Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Wed, 12 March 2014 08:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6DA81A092C for <>; Wed, 12 Mar 2014 01:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cGXnRsQiSNbA for <>; Wed, 12 Mar 2014 01:47:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BFC0A1A0927 for <>; Wed, 12 Mar 2014 01:47:17 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-88-53201f0fe52c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5E.48.04249.F0F10235; Wed, 12 Mar 2014 09:47:11 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 09:47:10 +0100
From: Christer Holmberg <>
To: Magnus Westerlund <>, Justin Uberti <>, "" <>, Eric Rescorla <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAABUUUA==
Date: Wed, 12 Mar 2014 08:47:10 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjS6/vEKwwfdDghYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV0bLtT+sBXPVK54vcWlgnCbf xcjJISFgIvF6/UJGCFtM4sK99WxdjFwcQgJHGCV6zzewQzhLGCX+zV4MVMXBwSZgIdH9Txsk LiKwkFHi5ccDLCDdwgLGElM6J7OB2CJAU+dOfM0CYWdJXHm9HMxmEVCV+DP1MVgNr4CvxKsZ axkhFjxhlrjR+oMJJMEpoCPRcOIbmM0IdNL3U2vAbGYBcYlbT+YzQZwqILFkz3lmCFtU4uXj f6wgx0kIKEos75eDKNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUB I8sqRo7i1OKk3HQjg02MwOg4uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoHxxlo+9QVxrT2NFUuNGvccZen2arn3PZrl9K1lK9h65n/7P2XaxElb0l4r B20UjH/UaO9RclPr/MW3q2wTFVhkFPmOBnwMWXR7f8uBWi7pya8niVU66q60i1+8mnlBz7Qr vpWb3zSvzuXL8H7rIZi6vmzKUUtzjlm9bqeqJNdu7ZuxequToPcCJZbijERDLeai4kQAih5L tVwCAAA=
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:47:20 -0000


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


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.