Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <> Mon, 10 March 2014 15:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 693C71A0233 for <>; Mon, 10 Mar 2014 08:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.64
X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nZL0eKnM0VaY for <>; Mon, 10 Mar 2014 08:16:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2849E1A0492 for <>; Mon, 10 Mar 2014 08:16:44 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-ba-531dd756dcbe
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BF.25.04853.657DD135; Mon, 10 Mar 2014 16:16:39 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:16:38 +0100
Message-ID: <>
Date: Mon, 10 Mar 2014 16:16:38 +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+NgFprLLMWRmVeSWpSXmKPExsUyM+JvjW74ddlgg6cr+C1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsEroyny9sZC1bKV6xsrmlg7JTs YuTgkBAwkWh6XNHFyAlkiklcuLeerYuRi0NI4ASjxL0/W5lBEkICyxklJkzRBbF5BTQlZl1f xgpiswioSuz+NAfMZhOwkLj5o5ENxBYVCJbYeeA3I0S9oMTJmU9YQIaKCCxklNh+eTMLSEJY wFji0OWlzBDbrjBJfN/1jAkkwSngJ/F08nUmiOvEJXoag0DCzAJ6ElOutjBC2PISzVtnQx2n LdHQ1ME6gVFwFpJ9s5C0zELSsoCReRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceomRmAQ H9zy22gH48k99ocYpTlYlMR5r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLglGpgnKl91Vfj MOeB3Cqx6S8U3ugsFHsx0/PsNBW9jPqjcjnBa0RCVZfdXvqHe5ffuXWqR7rFqjO8zc8vNm5p FtN4c91bqvzoffG9u6qcpubEd3z9edmJY3vK8ktbfprUboj4KVawhv2ubNnTq7e+fU6/u/mB aUUpz72K/O8q3kebpEWNHi5xf/tLSYmlOCPRUIu5qDgRALxPNRwwAgAA
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 15:16:53 -0000

On 2014-03-10 15:38, 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. I also thought the a=rtcp-mux is a MUST to implement, not a MUST use.

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

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


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: