Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Mon, 10 March 2014 14:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0CEB61A044C for <>; Mon, 10 Mar 2014 07:18:55 -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 Mb_2GKkBpIo7 for <>; Mon, 10 Mar 2014 07:18:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3F3931A0447 for <>; Mon, 10 Mar 2014 07:18:53 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-b3-531dc9c7a522
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 15.AD.10875.7C9CD135; Mon, 10 Mar 2014 15:18:47 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 15:13:31 +0100
From: Christer Holmberg <>
To: Magnus Westerlund <>, Justin Uberti <>, "" <>, Eric Rescorla <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcA==
Date: Mon, 10 Mar 2014 14:13:31 +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+Jvje7xk7LBBi8XS1mseH2O3WLrVCGL tf/a2R2YPRZsKvVYsuQnk8fkx23MAcxRXDYpqTmZZalF+nYJXBmPNn9mK2jmq2idtp+pgXE+ dxcjB4eEgInEv9ccXYycQKaYxIV769m6GLk4hAQOMUqsPnULylnCKLHt/2t2kAY2AQuJ7n/a IHERgYWMEi8/HmAB6RYWMJaY0jmZDcQWARo6d+JrFgjbSeLyxfOMIDaLgKrEvO13wWxeAV+J uxvnMEEs2MYosfflY2aQBKeAjsS+2TfBBjECnfT91BomEJtZQFzi1pP5TBCnCkgs2XOeGcIW lXj5+B8rhK0k8WPDJRaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllI WhYwsqxiZM9NzMxJLzfcxAiMjoNbfuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGMWa7Vf7ewqdTJJhbymf/vSR5ilFDlmfazs3xU6fvHMXx4bjoTel7qff dbE8/PWRofWO+LLwC5vSk3bodvYruQtuqp9uaJ48QSzBRFQ7TqDhW4faVq4o0VLpkq+smooz xXP/nl1jWfut49itvqdpIs5FjTGLDv9Y7MbNfuWyNj/nwmfP7lrfVWIpzkg01GIuKk4EANPI 1HNcAgAA
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 14:18:55 -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).

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.