Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Fri, 14 March 2014 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D7CC71A018E for <>; Fri, 14 Mar 2014 10:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 2LR3JyVYpFdw for <>; Fri, 14 Mar 2014 10:40:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8648A1A0194 for <>; Fri, 14 Mar 2014 10:40:36 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c8-53233f0c4990
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A0.90.10875.C0F33235; Fri, 14 Mar 2014 18:40:29 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 18:40:28 +0100
From: Christer Holmberg <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Date: Fri, 14 Mar 2014 17:40:28 +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+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS6vvXKwwcHnLBYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8bvo0YFU6Ur1h5SbmD8KdrF yMkhIWAisfnfAyYIW0ziwr31bF2MXBxCAocYJXo/XGWBcJYwSuxasQXI4eBgE7CQ6P6nDdIg IqAm8XDWLlYQm1mgWmLbin9gg4QFjCWmdE5mg6gxkZg78TXYHBGBeYwS12adBGtgEVCV2Nz4 FKyBV8BXYvWFBVCbn7JLbLnVygiS4BQIlJg58TdYAyPQed9PrWGC2CYucevJfKizBSSW7DnP DGGLSrx8/I8VwlaUaH/awAhRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELS MgtJywJGllWM7LmJmTnp5YabGIExc3DLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QD44RpPEUFH0Nijfzmf9mmw9k/73H81He3FosXRon6rloXv9uQQe5X 2KVSzW7ddZ+TTW/+3CAhsym7ZF/61FuuCZdTGwP3xNyV1W/vucWkkbG+5v+mzXa7mT19WA5/ u+t2fXXWykRhsdnanwxnTZv8/dGTl8yt76Y+uNCvtn8dn+oCU5n+J7zBPEosxRmJhlrMRcWJ AMQKBoVnAgAA
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 17:40:41 -0000


> By "RTCP transport in the offer", I mean separate ICE candidates generated for a RTCP ICE component, the original problem that I was proposing to solve.


But, again, we do have a decision that we are not going to specify procedures based on pre-knoweldge of BUNDLE support by the answerer. Or, at least that was the outcome in London, I guess it still has to be verified on the list.

> I agree the rtcp-mux attribute must always be present if you are going to do rtcp-mux.

Good :)



On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg <<>> wrote:

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.