Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <> Mon, 10 March 2014 14:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BCAE61A0447 for <>; Mon, 10 Mar 2014 07:28:00 -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 HTUVaWAUuQcf for <>; Mon, 10 Mar 2014 07:28:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 90C6A1A043E for <>; Mon, 10 Mar 2014 07:27:59 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-88-531dcbe999be
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 02.40.04249.9EBCD135; Mon, 10 Mar 2014 15:27:53 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 15:27:53 +0100
Message-ID: <>
Date: Mon, 10 Mar 2014 15:27:53 +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+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rvfladlgg+bZ+hYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8aFrf/ZCuaKVrw6uJKtgfGf QBcjJ4eEgInE8XOfWCFsMYkL99azdTFycQgJHGGUuNV6lx3CWc4o8W3WHLAqXgFNiVkrL7GD 2CwCqhKfbneA2WwCFhI3fzSygdiiAsESOw/8ZoSoF5Q4OfMJC8ggEYGFjBLbL29mAUkICxhL HLq8lBliwxdGiUsnvoJ1cwr4SVzY/BdoKgfQTeISPY1BIGFmAT2JKVdbGCFseYnmrbOZQWwh AW2JhqYO1gmMgrOQ7JuFpGUWkpYFjMyrGDmKU4uTctONDDYxAgP14JbfFjsYL/+1OcQozcGi JM778a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGfWbrmB7nF917o+MW6n+Ibeq8e52t m/7kfg9tOLxt3bHEy5NXxZ04Nm/7/GTvtO3nprem7mNLUlHc9vfZD57CteXGJhM3/7WrWpp/ 2r7opFx2jf2VfC95JoP5DbcVfM5svb17a5/7TafXJR/e2ZxzfuN56HbWrlNJMsdrd/WZPPx9 4szhZ6m/biixFGckGmoxFxUnAgBmngQJIgIAAA==
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:28:00 -0000

On 2014-03-10 15:13, 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.


Magnus Westerlund

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: