Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Mon, 10 March 2014 20:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5BA2C1A024B for <>; Mon, 10 Mar 2014 13:09:32 -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 tGDTVeFnla1D for <>; Mon, 10 Mar 2014 13:09:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 112021A0495 for <>; Mon, 10 Mar 2014 13:09:28 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-0f-531e1bf2d310
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 19.BE.10875.2FB1E135; Mon, 10 Mar 2014 21:09:22 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 21:09:21 +0100
From: Christer Holmberg <>
To: Magnus Westerlund <>, Justin Uberti <>, "" <>, Eric Rescorla <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mw
Date: Mon, 10 Mar 2014 20:09:20 +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+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje4nablggzmLJC1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozNN7+xFaxRq1hzaRFjA+NP uS5GTg4JAROJP8sPMULYYhIX7q1n62Lk4hASOMQo0bxtBlhCSGAJo8TbE9ldjBwcbAIWEt3/ tEFqRAQWMkq8/HiABaRGWMBYYkrnZDYQWwRo6NyJr1lA6kUEoiQu/40BCbMIqErs+r6XCcTm FfCV2Pl5AiPErn9MEv+bVoMlOAW0JB6dmA22lxHooO+n1oDFmQXEJW49mc8EcaiAxJI955kh bFGJl4//sULYShKLbn+GqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmF pGUBI8sqRvbcxMyc9HLDTYzA2Di45bfuDsZT50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgbEp/q+4bqcP13z5M4ETQpysq3Xc8yrf/onp/22ffXvHss9XXpe2627c fTQ20jVLZUXZs7iHuxIzmZedcUk6fzHiu4V2X9BiPrZpJ3ZMO70p+0LB8diLSvaLjord/vnT XCRoI8fvqtaXz2dckZ0QN6NQs2XzEsYArTt57/jOOqmGbmJ8UPrO5IISS3FGoqEWc1FxIgD6 GKfLWwIAAA==
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: Mon, 10 Mar 2014 20:09:32 -0000


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