Re: [rtcweb] BUNDLE with implicit rtcp-mux

Justin Uberti <> Fri, 14 March 2014 16:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF10B1A0166 for <>; Fri, 14 Mar 2014 09:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.325
X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xTWGPH1XHkDV for <>; Fri, 14 Mar 2014 09:46:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::234]) by (Postfix) with ESMTP id 0BCBE1A00F1 for <>; Fri, 14 Mar 2014 09:46:54 -0700 (PDT)
Received: by with SMTP id jz11so3022532veb.11 for <>; Fri, 14 Mar 2014 09:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NqgJf9/W/iF0wX4MouSJtmf0Qt8OnxrwlYMbZqL+h+4=; b=QrZMzB3Yn8ybqKcLp+a+utG57h3U9+bIVZEJexEJqdZo/0ACX9lSrBUpNwajeK3mQZ oUWl6vZpZejBfCgO6LcTLGXFTlOKfhYpaKPc+8hR2/E/lFs44ULQlXQIjaPqzeiPP0gL FtiMlu1aR/pLc7Y9moTMoDSYcDW+zxtitJZ6c82qNL75Muf7Zb2pEdqm2dDtqqeXew6B /WiCPXy/MupQwrRJoLO3g9cU9NlI80DXZiEz3WnN85uK6Q6vLP+hquJQhJDwAlgWgbS8 60vpmr9h5Hpiv3O0hQ2/ILL0hhgyxN3lF5j5myUFOKJmM2Ud5eu4wYdHvGHZD+hjnZIi tJRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NqgJf9/W/iF0wX4MouSJtmf0Qt8OnxrwlYMbZqL+h+4=; b=Jw7T/5G/yg6HCH+HQzXqQqOBm3TpGPTku/hCjEMmtFBiUPmNhYratwYEHw4fSQJVqU fIHBw2xtWZ5m13BzanwZKcXbzQkwGdlgYJDdBeOJzcLNYbu87fdxr+P7wacSgcu2gmbI Nw5GnbuVSgoSgzTYHKFIvWB5ZkkrMjLpkkARW3h6J24ExSFvFG5cPv+zSnj3S07/mqCT Pl+x4CBks4k9039a1tO26owmncwjI+ZJE0OMOTB0UZjECleCGHXakV+a41O+OYD53rnR GfPe73K3MmK6kyJfjCOGiizBTo6WvR52rTsQW8wgYxd+D4pfu2jDiDbRBNs8WkbezUKu DxsQ==
X-Gm-Message-State: ALoCoQmJM9BXNhkAGW8NBsJpJSDaP5myMfVLZSoriLJ2UIOHzCm2JqgX9JjBOKjbeApQGNmDc/MKPHEApkVUOcOizJdFnhlVXdcIJcHnwlWpt481MkdNUYax/nxzotQNTs5nVIF7LTlzmSgSU8sHMt+MdLBV3hJLf5mNj6RPZ3PG6ABJ0ky6HaNZ19d/uHXXqzN4MiqqPgSm
X-Received: by with SMTP id kh10mr1035364vec.31.1394815608021; Fri, 14 Mar 2014 09:46:48 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Mar 2014 09:46:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Justin Uberti <>
Date: Fri, 14 Mar 2014 09:46:27 -0700
Message-ID: <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="047d7bdc945ed8002204f493d034"
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:46:57 -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

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

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).
> Regards,
> Christer
> ________________________________________
> 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:
> 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.
> 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.