Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Mon, 10 March 2014 14:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 722271A0479 for <>; Mon, 10 Mar 2014 07:38:40 -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 e-O3swvKohox for <>; Mon, 10 Mar 2014 07:38:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CEA781A0446 for <>; Mon, 10 Mar 2014 07:38:38 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-da-531dce68e8bc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 81.DF.04853.86ECD135; Mon, 10 Mar 2014 15:38:33 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 15:38:32 +0100
From: Christer Holmberg <>
To: Magnus Westerlund <>, Justin Uberti <>, "" <>, Eric Rescorla <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5A=
Date: Mon, 10 Mar 2014 14:38:32 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjW7mOdlgg42bmSxWvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErow1R78zFUwVr1i74ShjA+NV oS5GDg4JAROJPVfKuhg5gUwxiQv31rN1MXJxCAmcYJT4+HQ3lLOEUeL8r6lMIA1sAhYS3f+0 QeIiAgsZJV5+PMAC0i0sYCwxpXMyG4gtAjR07sTXLBC2n8SOw3PB4iwCqhLX7n5hArF5BXwl rq3YxQpiCwnMYpJ4/0QdxOYU0JK43nIBrIYR6KLvp9aA2cwC4hK3nsxngrhUQGLJnvPMELao xMvH/1ghbCWJHxsusUDU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELS soCRZRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceomRmD8HNzy22gH48k99ocYpTlYlMR5 r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLglGpgzJa4/T3KKrjIKpwv4dC0uXPvV3Z/y1nv Xnqc+2lm2+ZGhjm77xeviwta8TmU+R3/SQPTy28vLHp/5XVV0/OSN5UWth+bp7B+DHvmoDb1 8qypVhnPOJtj+hh92afYqQVaqFcGXdL9evnq6Rk907lU+F7t7zuyh9Gg7c15nR3Bne12lV/1 boYrKLEUZyQaajEXFScCABMsI8ttAgAA
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 14:38:40 -0000


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

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.

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?