Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <> Thu, 20 March 2014 09:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 968341A06F5 for <>; Thu, 20 Mar 2014 02:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BCNdqVREluGQ for <>; Thu, 20 Mar 2014 02:37:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 751C91A08AC for <>; Thu, 20 Mar 2014 02:37:12 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-55-532ab6becfe1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 44.70.23809.EB6BA235; Thu, 20 Mar 2014 10:37:03 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Thu, 20 Mar 2014 10:36:37 +0100
Message-ID: <>
Date: Thu, 20 Mar 2014 10:36:37 +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+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje7+bVrBBot/sFiseH2O3WLrVCGL tf/a2R2YPRZsKvVYsuQnk8fkx23MAcxRXDYpqTmZZalF+nYJXBknFs5iLbgsW3GtvZelgXGe eBcjB4eEgInEi9nFXYycQKaYxIV769lAbCGBQ4wSZzdHdTFyAdnLGSV2X3/EDpLgFdCWWLHn NJjNIqAqcWLXHrAGNgELiZs/GsFsUYFgiZ0HfjNC1AtKnJz5hAXEFhFQk3g4axcriM0sUC3x 9OBLsDnCAsYShy4vZYZYtpRdYu3ONWANnAKBEpc2/GKHOFRcoqcxCKJXU6J1+292CFteonnr bGaIo7UlGpo6WCcwCs1CsnoWkpZZSFoWMDKvYmTPTczMSS832sQIDNyDW36r7mC8c07kEKM0 B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjjM2RkGoQlW352bvx1umbVfHX1 toYyhYzNnPpxcmWzli60VJn+5vS8irKcWUe6X3DfOLagQ9X9hv5FtZtqfr/lLe5+YxWu/Rh+ /aOGJ3denIBV7c99mp9XPLvN/Ha9Wjxf1dYYr66QN/cd7NWEmqWOfZ4tdHnOC84bXd1/Nvum mJWpx1ir/lBiKc5INNRiLipOBABLeSNIKgIAAA==
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: Thu, 20 Mar 2014 09:37:25 -0000

Please see inline.

This is as an individual!

On 2014-03-20 01:21, Justin Uberti wrote:

> On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund
> < <>>
> wrote:

>     (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.
> It is significant because you always know you can rtcp-mux. And you
> always know you can BUNDLE when rtcp-muxing. But I think trying to
> BUNDLE a no-rtcp-mux m= line into a rtcp-mux m= line is asking for
> problems. 

To be clear, I am arguing for consistent behavior and usage across the
whole bundle group. Certainly you MUST NOT be allowed to have some m=
line for RTP to use a=rtcp-mux and some other m= line in the same bundle
group to not use it.

What I am considering is the possibility to have a bundle group with
multiple m= RTP lines that do not use a=rtcp-mux and instead have RTCP
over a separate port.

I started arguing that this was important for being able to recover PT
space. But there is actually another reason for this. In cases when you
have QoS, for example in cellular environment, mandating the use of
rtcp-mux forces one to send the RTCP over the expensive QoS bearer. The
amount of RTCP to support adaptation as well as codec control means that
it is still likely that you want to spend at least 5% of the Video
bandwidth on RTCP. If the cost associated with providing QoS for video
can be reduced by 3-5% we in the cellular business definitely like to be
able to utilize it.

I would also like to stress that we are discussing what BUNDLE enables.
RTCWEB is the first user of bundle, but likely not the only one. We have
to be careful to apply all WebRTC context specific limitations on a
general mechanism.

First of all I really like to see that BUNDLE does not restrict ones
choices if one like to multiplex RTP or RTCP when doing BUNDLE. As a
general IETF SDP Signaling mechanism we need this generality.

Secondly, I would strongly prefer that also RTCWEB's specifications do
support this mode of operation.


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: