Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 10 March 2014 15:16 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693C71A0233 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 08:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.64
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZL0eKnM0VaY for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 08:16:52 -0700 (PDT)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2849E1A0492 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 08:16:44 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-ba-531dd756dcbe
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BF.25.04853.657DD135; Mon, 10 Mar 2014 16:16:39 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:16:38 +0100
Message-ID: <531DD756.50900@ericsson.com>
Date: Mon, 10 Mar 2014 16:16:38 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
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 <christer.holmberg@ericsson.com>, Justin Uberti <juberti@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Eric Rescorla <ekr@rtfm.com>
References: <CAOJ7v-063mGE_zndtAqAMN2fJw7kWvUHX2SgyDMryfw_-aS-9w@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se>
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
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kpFdQ5_NR3viaFYaYUW4Ao7hYI4
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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.

cheers

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------