Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <> Mon, 17 March 2014 13:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E50F1A0201 for <>; Mon, 17 Mar 2014 06:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0w-HbpXODCtk for <>; Mon, 17 Mar 2014 06:23:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5DCA1A011C for <>; Mon, 17 Mar 2014 06:23:39 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-a4-5326f753a14e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 43.0E.04249.357F6235; Mon, 17 Mar 2014 14:23:31 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Mar 2014 14:23:30 +0100
Message-ID: <>
Date: Mon, 17 Mar 2014 14:23:30 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Justin Uberti <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjW7wd7Vgg3/LZSxWvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozlnz8wFlxTr/g6s5WlgXGF fBcjJ4eEgInEgalNrBC2mMSFe+vZuhi5OIQEjjBKnF26mhXCWc4osXrDJxaQKl4BbYlXVxcy gtgsAqoS/xe9ArPZBCwkbv5oZAOxRQWCJXYe+M0IUS8ocXLmE7BeEQE1iYezdoFtYxaolnh6 8CU7iC0sYCxx6PJSZohlB9gk9lyZATaIUyBQ4vumZ0xdjBxA54lL9DQGQfRqSrRu/80OYctL NG+dzQxiCwHd1tDUwTqBUWgWktWzkLTMQtKygJF5FSNHcWpxUm66kcEmRmD4Htzy22IH4+W/ NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAeOWKac/X3qMrON3+L442 VWQzqiwPUVsYmDL9Qf/z5auWGW5K59rnzZXbcvBxZcWxUpXmz1xHTuYHVtyTWn1zcUXydMO6 e7dMQ7LjtoY4uL89bVursojjep5pSurJu61duq88nwWdW7JEenLyrifbZNVaXf8tqLZPuHGy aqNh/+YLjmwTz3e9VGIpzkg01GIuKk4EACWrmjAtAgAA
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: Mon, 17 Mar 2014 13:23:42 -0000

On 2014-03-14 17:26, Justin Uberti wrote:
> On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund
> < <>>
> wrote:
>     Hi,
>     (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.

(still as individual)

Lets be clear what we are discussing here. I don't think this is lot of
cases. And if you don't want to implement this in your code generating
offer, that is fine. What this describes is that your code handling
reception of offers and generating answers must be able to handle the
lack of a=rtcp-mux in any offer, rather than just the initial one.

I would question if even that assumption holds considering what happens
if people start implementing session resumption or session mobility
between devices using rehydration style establishment procedures. What
one sides consider an initial offer might not be the state the answering
party is in. Thus, I am worried about cases that are first offer/answer
exchange related.

To my understanding you will have code to handle the following cases
when offers contains:

1) No bundle, no a=rtcp-mux
2) No bundle, with a=rtcp-mux
3) Bundle, with a=rtcp-mux

Considering that you support bundle, and you support usage or not of
a=rtcp-mux. Then I don't see how the code handling the SDP logic for
Bundle, without a=rtcp-mux is that significant.

First of all, to be robust, you have to be capable of handling
significant reconfigurations of the Peer Connection session in an Offer.
If someone moves the peer of one peer connection to another device
anything can happen, and everything can change.

Secondly, to be able to turn off a=rtcp-mux is one method which can free
up PTs if one run out. The other would be first unbundle the media
types, then to completely unbundle the media sources. The later would be
far worse when it comes to requiring providing ICE candidates and
dealing with new transports. I however think unbundling the media types
is likely to resolve many of the PT shortage situations.

Just to confirm, you are also against allowing any initial offer request
with bundle but without a=rtcp-mux within that bundle-group?

This, I would question, as it prevents anyone from treating the RTCP
packets differently from the RTP packets within one RTP session. I know
that this has been done in some cases, including IMS.

>From a principal point of view I think this should be either be use of
BUNDLE groups results in MUST use a=rtcp-mux with RTP or that any offer
may change the usage of a=rtcp-mux. Anything else depending on initial
offer appears very messy and prone to errors.

I would appreciate if someone else would provide their input and views

First on the question if they need to separate the RTP and RTCP at all
within a BUNDLE group?

Secondly if they see that splitting a bundle group into different groups
if one runs into issue is a sufficient and more preferred method for
dealing with any PT exhaustion issue?


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: