Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Tue, 11 March 2014 07:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 159BD1A02A0 for <>; Tue, 11 Mar 2014 00:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.05
X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OoGENDYw2RUD for <>; Tue, 11 Mar 2014 00:51:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 354E41A0139 for <>; Tue, 11 Mar 2014 00:51:09 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-27-531ec0668f9d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id CB.07.10875.660CE135; Tue, 11 Mar 2014 08:51:02 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Tue, 11 Mar 2014 08:51:01 +0100
From: Christer Holmberg <>
To: Bernard Aboba <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggAFFHoCAAERkzg==
Date: Tue, 11 Mar 2014 07:51:01 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2009B4ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW7aAblgg39bDS027PvPbLHi9Tl2 i61ThSzW/mtnd2Dx2DnrLrvHgk2lHkuW/GTymPy4jTmAJYrLJiU1J7MstUjfLoEro/HPWbaC 87kVy1pPsjUw7orrYuTkkBAwkVi47wIbhC0mceHeeiCbi0NI4BCjxKRZN5khnCWMEq+3rQBy ODjYBCwkuv9pgzSICGhL9H3bxwRiMwtkS1x6toQVxBYWMJaY0jmZDaLGRGLuxNcsELaTxNrV C5hBbBYBVYn2NbfAbF4BX4k/x9awQOy6yShxet1qdpAEp0CgxLt/6xlBbEag676fWgO1TFzi 1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0osfNsO9jNzAL5Ek+6eCB2CUqcnPmEZQKj6Cwkk2Yh VM1CUgVRYiDx/tx8ZghbW2LZwtdQtr7Exi9nGZHFFzCyr2Jkz03MzEkvN9zECIy6g1t+6+5g PHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYC9lNxY9mrVzikv2o 1kyl0Dzn1bHX5zXSzOR3O0wMvrz33txfas2vZBmv7d4wa2qylTTPVzndSSeaHsSLH3t9+J7C 56nXy5gtN72aHZRUV72udzfXrBeHC0QE6gr4DxyyD4k/2DIxtqZDu776zkIpvrA/Mlzngtgu qmYkagYuEH11cP8Vlx8xSizFGYmGWsxFxYkAGfm/O4gCAAA=
Cc: "" <>
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: Tue, 11 Mar 2014 07:51:13 -0000


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



On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg <<>> wrote:

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?



From: Justin Uberti [<>]
Sent: 10. maaliskuuta 2014 8:18
To:<>; 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
m=video 11000
Existing "max-bundle" policy - video port is 0 because bundle-only, but both RTP and RTCP ports allocated for audio:
m=audio 10000
m=video 0
The new “force-bundle” policy - only a single set of ports allocated - audio, video, RTP, RTCP share the same port.
m=audio 10000
m=video 10000
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
m=video 0
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<>