Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Fri, 14 March 2014 16:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8657B1A0161 for <>; Fri, 14 Mar 2014 09:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6hd3Fm2WUTbn for <>; Fri, 14 Mar 2014 09:30:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 91B551A00F1 for <>; Fri, 14 Mar 2014 09:30:45 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-a4-53232ead1a31
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8C.1E.04249.DAE23235; Fri, 14 Mar 2014 17:30:38 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 17:30:37 +0100
From: Christer Holmberg <>
To: Justin Uberti <>, Magnus Westerlund <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Date: Fri, 14 Mar 2014 16:30:36 +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+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje46PeVggwWLGC1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozb77rZC+6IVGzcMJ+pgfG2 QBcjJ4eEgInEho8H2CBsMYkL99YD2VwcQgJHGCUOblkH5SxhlGg9upC9i5GDg03AQqL7nzaI KSIQI/HuaDFIL7OAq0TTw6UsILawgLHElM7JYDNFgObPnfiaBWSMiMAkRonlf/oYQRIsAqoS M6feYgKZwyvgK9E+0Qdi1S02ibUzG5lBajgFAiW+b3rGBGIzAh33/dQaJohl4hK3nsxngjha QGLJnvPMELaoxMvH/1ghbCWJHxsusUDU60gs2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMGoObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamBk1r8vLCld+Pudn2tyv4aORPG+zV+7jL0VjPVY/6bz /vwivtBI89yS+ZIZ014uKLkr/O6d7bkO0Vqe1ed6y52U3nx5UXtuQfjqH5HeDCvrDLMTNHWe XOoPmnWxzJit/Jl21Wm1PJEzSgEi7kmPJJM2z57SI2lkee31JN5exTrbv3IejwT21SuxFGck GmoxFxUnAgCTr7NxaAIAAA==
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: Fri, 14 Mar 2014 16:30:49 -0000

Hi Justin,

What do you mean by "RTCP transport in the offer"? Are you referring to the a=rtcp attribute, or?

Even if we mandate rtcp-mux within a BUNDLE group, the a=rtcp-mux attribute must still always be present - even if you know the remote endpoint supports rtcp-mux (or, even if you have already negotiated usage of rtcp-mux).


From: Justin Uberti []
Sent: Friday, 14 March 2014 6:26 PM
To: Magnus Westerlund
Cc: Christer Holmberg;; Eric Rescorla
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux

On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <<>> wrote:
(as individual)

Although this discussion really should be on MMUSIC, I am still
following up here. Anything we come to conclude here really need to go
to MMUSIC for confirmation.

Justin, I do agree that it appear unnecessarily of having to include an
RTCP transport in an OFFER when the offerer know the answerer is BUNDLE
capable. I am fine with that and think the rule needed here is something
along the line of the below:

A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already
required). In any answer by a BUNDLE capable endpoint, it MUST NOT
change the usage of a=rtcp-mux. If it is present in the offer, it must
be confirmed to be used in the answer, and if not present in the offer,
it MUST NOT be added in the answer. An BUNDLE capable endpoint is
RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not
be suitable include, lack RTP payload types, or cases when RTCP traffic
is needed to be on its own transport flow (5-tuple) to enable QoS or
other traffic handling functionalities.

The reason for writing the rule like the above, is that then an endpoint
can choose when creating an offer to renegotiate the use of a=rtcp-mux.
For example due to it running out of available PTs.

Feedback on this proposal?

I am not OK with this. It just gets too complicated to deal with all the cases, especially if with the provision that rtcp-mux can change during the session.

I think Christer's current language is what we want - if you are going to BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer cannot do that, it needs to reject the BUNDLE.

I agree with your initial point though - if you know that both sides are going to BUNDLE and rtcp-mux, it makes sense to allow them to do that from the outset, i.e. no need to include a RTCP transport in the offer.