Re: [rtcweb] BUNDLE with implicit rtcp-mux

Magnus Westerlund <> Fri, 14 March 2014 08:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D518E1A00B8 for <>; Fri, 14 Mar 2014 01:57:37 -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 5pj43yhowG12 for <>; Fri, 14 Mar 2014 01:57:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E12E71A00B2 for <>; Fri, 14 Mar 2014 01:57:35 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-fb-5322c478a521
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B2.3B.04249.874C2235; Fri, 14 Mar 2014 09:57:28 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Mar 2014 09:57:25 +0100
Message-ID: <>
Date: Fri, 14 Mar 2014 09:57:25 +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: Christer Holmberg <>, Justin Uberti <>
References: <> <> <> <> <> <> <> <> <> <> <>, <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+JvjW7FEaVggylPFCxWvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErowPnV1sBZ95K7afbGVvYFzA 3cXIySEhYCKxZdFCRghbTOLCvfVsILaQwBFGicvHYrsYuYDs5YwSSw7uYQZJ8ApoSzxd8YAF xGYRUJVYducFK4jNJmAhcfNHI1izqECwxM4Dvxkh6gUlTs58AlYvIhAj8avvDlicWcBVounh UrC4sICxxKHLS5khlt1mlTgz8zfYUE4Bd4nXR/4wdTFyAF0nLtHTGATRqycx5WoL1Bx5ieat s5khjtaWaGjqYJ3AKDQLyepZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzB4D275bbGD8fJfm0OM 0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg3GWheepUiBUHh2PjW91g67jb rkefb9Q+kjDJq/us9qeJUcv3mIR/t5j3MvDYKt+iuT+kpmT2XOwKcvm8tLRlhUCEEIvl1uwn k1ycrCZ/MPHaOrOpcM+nxovmdcmOXN42q+f+Sfb29H0vvN9O64rSrr8fw9oKSvd279WxelpU aJOTuuNhtJqZEktxRqKhFnNRcSIAKX5kPiwCAAA=
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 08:57:38 -0000

(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?


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: