Re: [rtcweb] BUNDLE with implicit rtcp-mux

Justin Uberti <juberti@google.com> Wed, 12 March 2014 04:38 UTC

Return-Path: <juberti@google.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 6AAC41A08D9 for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 21:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.125
X-Spam-Level:
X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.547, 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 QiWX9Oq9qGmt for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 21:37:59 -0700 (PDT)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 671D71A03AC for <rtcweb@ietf.org>; Tue, 11 Mar 2014 21:37:59 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id jw12so9472325veb.37 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 21:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=plJd5ac5469l5DpiDZa1Ewcvj+0gGE071md2/Us6+h4=; b=eeS2izMgn3jz3xsQLPFHe1eEDK34EguDQQipPfhoiApXvNAq1lxkXsfmNi+mFByPtQ Y3m0vFUP8Kh8kEz6I3tUP7SFX0Q6YALBprAxCrcMRzz9e29jdoHAwpgGp98tpumpANJQ 2pvudBJRbvY7ET8QuaaxNuggsf+UcAY58OgocZCCSOpJiZkzQBO7Tt2e+1mLefhsKjOM QUcC7+nWzduvkXw2Cx8wJmaKeA3h/tnSBDyAiCxhdx6Ars8ReUqZpZ35CZVJ/jVQ+OOb b4BDH0KGmwXrlwwbZL2+FeblOibiNGAAi11gLOlzSHObb4HyFhXPo1gq/ayXTKvfUuFC VU7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=plJd5ac5469l5DpiDZa1Ewcvj+0gGE071md2/Us6+h4=; b=gzXwCg0Xn9wIZpDZ+OT+qQH67LKjgWmU5bAZBN/ATVpox4TOuiPwbRHW7hyky1DkTv M3tKf8qagznh+w57QMD0q+HFxP2QSzH5VOfv+1mOD92n+kp/egIOmJC/jL92V2bdaK2b 7VYo2nhjra+t6mqGSqZm6S+zTK5KHYceIHpgs4kwGm1h7ACfCPP3unq6Q2SD5maKgXsw 2AoDZsgcma65DtiRLa5AOdEr+RQBV1Ryh29VyIdnJ20GsJyt0o+6uc04c6mAS/kjbF6l lBS1izhBchsh4/ksmaDOY9QFIPtp5WvYJOxhhlfkNO+G6OaOKLDISrE9+KW3JyuvDXSS tfPQ==
X-Gm-Message-State: ALoCoQkYAd+LG75yWyFDs/1C2JxKm1TS5DuIzHrrrY45WOEEE6d3dPLApCb6xTjWFCoWcEGrkjhnTVGaEA6NJ88UiTBaZIc+LMmtBr3YN743y3J3K+ZQrENggDs62zbCJMkY2h7Awe8m858ZCUIMiXIPehVEvFvrhTzG5EkW6OsydBvz1vHMJdC6TQeG5jamiMK0XtiuiLCk
X-Received: by 10.58.95.161 with SMTP id dl1mr13117916veb.21.1394599073163; Tue, 11 Mar 2014 21:37:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 21:37:33 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2009B4@ESESSMB209.ericsson.se>
References: <CAOJ7v-063mGE_zndtAqAMN2fJw7kWvUHX2SgyDMryfw_-aS-9w@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <CAOW+2dtVYjRKGwZU5EocXCcrC4JZPVe6e14tfdcWLRafoUbing@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D2009B4@ESESSMB209.ericsson.se>
From: Justin Uberti <juberti@google.com>
Date: Tue, 11 Mar 2014 21:37:33 -0700
Message-ID: <CAOJ7v-0_3J8bc5wZENx-0QKOH6UCa7A4DuL_SDz-HOTgz=nobQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=089e013cb9965c47e604f46166d1
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HRKGqDTZUVIogXwPxb5OpfHMZj0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Wed, 12 Mar 2014 04:38:01 -0000

Sort of. The idea is whether JSEP should have a mode which _gathers_ only a
single set of ports, in effect assuming the other side supports rtcp-mux.
The use of a=rtcp is incidental here, and only used to point out that the
RTP and RTCP ports that are offered will be identical.


On Tue, Mar 11, 2014 at 12:51 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>   "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."
>
>  [BA] The justification was that an implementation interested in
> multiplexing A/V would almost certainly also want to multiplex RTP and
> RTCP, because the motivation for both is minimizing port usage.
>
> [Christer] So, again, the idea is to use a=rtcp to indicate the *same*
> port as a=rtcp-mux indicates, and hope that the receiver supports at least
> either a=rtcp or a=rtcp-mux?
>
> Regards,
>
> Christer
>
>
>
> On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> 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?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Justin Uberti [mailto:juberti@google.com]
>> *Sent:* 10. maaliskuuta 2014 8:18
>> *To:* rtcweb@ietf.org; Eric Rescorla; Christer Holmberg
>> *Subject:* BUNDLE with implicit rtcp-mux
>>
>>
>>
>> In my JSEP preso during the RTCWEB session last Wednesday, I discussed
>> adding a new BUNDLE policy to JSEP. This policy, which would be called
>> something like “force-bundle”, would force the use of the same ports for
>> BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the
>> other side supports BUNDLE, this would reduce candidate gathering even over
>> the currently defined “max-bundle” policy, since there would be no need to
>> gather RTCP ports at all, and also avoid the need for the BUNDLE fixup
>> offer (where the ports are updated to be the same for all BUNDLEd
>> m-sections).
>>
>> To explain the differences here, here are some example offers for an
>> audio+video call:
>>
>> Default bundle policy - separate ports for audio, video, RTP and RTCP:
>> m=audio 10000
>> a=rtcp:10001
>> a=rtcp-mux
>> m=video 11000
>> a=rtcp:11001
>> a=rtcp-mux
>>
>> Existing "max-bundle" policy - video port is 0 because bundle-only, but
>> both RTP and RTCP ports allocated for audio:
>> m=audio 10000
>> a=rtcp:10001
>> a=rtcp-mux
>> m=video 0
>> a=bundle-only
>> a=rtcp-mux
>>
>> The new “force-bundle” policy - only a single set of ports allocated -
>> audio, video, RTP, RTCP share the same port.
>> m=audio 10000
>> a=rtcp:10000
>> a=rtcp-mux
>> m=video 10000
>> a=rtcp:10000
>> a=rtcp-mux
>>
>> During the discussion, the ability to avoid RTCP port gathering was seen
>> as valuable, but not the ability to avoid the fixup offer. However, after
>> thinking about it a bit, I don’t think that there is a viable solution that
>> avoids RTCP port gathering that *doesn’t* use a single set of ports. The
>> only other option would be to do something like this:
>>
>> m=audio 10000
>> a=rtcp:10000 # same as m=audio port
>> a=rtcp-mux
>> m=video 0
>> a=bundle-only
>> a=rtcp-mux
>>
>> but this will almost surely will result in a malfunction when talking to
>> a non-rtcp-mux client, due to the same port being used for RTP and RTCP,
>> and still requires the fixup offer, and as such is net worse than the
>> force-bundle approach indicated above.
>>
>> So I think we the force-bundle approach is the one we want to minimize
>> port gathering. The only question is whether we should keep max-bundle as
>> well. To be specific, we need to decide between:
>>
>> a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and
>> add a new force-bundle policy that creates an offer with a single port
>> shared between all m-sections (RTP and RTCP). max-bundle remains nominally
>> backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it
>> will still send a single audio stream. force-bundle is not backwards
>> compatible with non-BUNDLE endpoints.
>>
>> b) Add force-bundle, but get rid of max-bundle.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>