Re: [rtcweb] BUNDLE with implicit rtcp-mux

Bernard Aboba <bernard.aboba@gmail.com> Tue, 11 March 2014 04:44 UTC

Return-Path: <bernard.aboba@gmail.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 9EDC51A04AE for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 21:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=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 jsrk-3Yv4ohK for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 21:44:01 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 611AA1A0361 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 21:44:01 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id m15so7193697wgh.3 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 21:43:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Si3T0k9DMzGd+kKgddjEquMukmEt++54xH+wgF43Ac=; b=m1O5CfQXZm89mtiOw2jDrGBhitodzB/sggeP7p7vGbjkQCGKGF2jQtugwbRGRb2D5d 2fmNBVJKJnWTPyztw/HvOiiZLb3+RF0+gckXSO709uHVJwGg0ce4rnOhqaYluIa3eAin HwkP6+ik1t5+3u1LTAEogg7KT11ZlwgMRkgLi5dpIWk/7s9tL98x07QF80RD3zn1kasU pwd+5WfEmnSz0Es7gZN16p1G63sthd9ztUs6w6dslkIWQ4rOhZq26kduAem2ZpL3z+Hc KJjsF//iTBG73FDuOaPWeGR1UonD+k1xuF257c0O/5CzByZHL22BU0o8VXtkS+aWcTe8 nGYg==
X-Received: by 10.180.98.200 with SMTP id ek8mr1294021wib.4.1394513035334; Mon, 10 Mar 2014 21:43:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.161.66 with HTTP; Mon, 10 Mar 2014 21:43:35 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se>
References: <CAOJ7v-063mGE_zndtAqAMN2fJw7kWvUHX2SgyDMryfw_-aS-9w@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 10 Mar 2014 21:43:35 -0700
Message-ID: <CAOW+2dtVYjRKGwZU5EocXCcrC4JZPVe6e14tfdcWLRafoUbing@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=f46d044288601b1bb704f44d5e1a
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aAYZM44S3fYb8tZK9OLy7C5b3no
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: Tue, 11 Mar 2014 04:44:04 -0000

Christer said:

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


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