Re: [rtcweb] BUNDLE with implicit rtcp-mux

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 976B71A0168 for <>; Fri, 14 Mar 2014 09:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Status: No, score=-1.925 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pqPSkwb98kPL for <>; Fri, 14 Mar 2014 09:26:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::22d]) by (Postfix) with ESMTP id 6D5A21A0164 for <>; Fri, 14 Mar 2014 09:26:38 -0700 (PDT)
Received: by with SMTP id oy12so2942514veb.18 for <>; Fri, 14 Mar 2014 09:26:31 -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=lexa7iuDR6QT5BqGKtn3PmMsqS9DW09Vydw2ElWE7yM=; b=jMlXqiG/vzJGfKc1RiaW/sKviWm8u5f5ZLhxUNe4wB9s6VKpxN3ibgL5XeAl83Gj3k hdcQd5RHUz7qLM48DwKIxP/ZR8nMa83LQnGcEuiLP3CvpX6TO8yiHHgOwUgYAonBS1sX YviKjQxs217q5MjZn0fCyFmhrdBmV/6govGLP4j5S1Eq+3ff9RGKZMVhktTyII/spdpI rMVEuesjXC7PKyb+DasC1MKtLQpIKzhwUaj5Fheg1h0UcKQn9Gmp6de7KGh1lznkmnhq 2wUYTqghfMsSXJss0kdn78L9g3Tfy6O+hmrgS8Jj3YogxPaqoX8GyhrMF5Doxhzp2t14 iedw==
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=lexa7iuDR6QT5BqGKtn3PmMsqS9DW09Vydw2ElWE7yM=; b=DObIrZFp8cB2sHfNetw/CVbqGA0HpU4VP79cPg7d53KiRHRI2gyGv1AXwFnwTBVqTl 1dzydsUsXNrr3HWpPe8GTrRmGo1Ier5QNGqXnih9enEehPdYcUQ95rO+nlMKWMnPeVfK QSZjohOkqyv9A0qllDm5+BCbU0QRCDnDeDMCT7/y4jCGI75gUoSVthhH1siEVlwgl2/S MWPftbnN7RF+fXr6dM65meHQess6pUD3EasCdv3IY4OYXL/IZRr8f0wjGUWCf4AULvFU TO3FUP0eEfHlNILr7935IZtQmybGElWpnHN5hn2nBfeNSle1BjQf5/uas14rX47OMCBo ca8w==
X-Gm-Message-State: ALoCoQlKnSjAWurIPYmhiJyfTclMTj1TWRV44gJv7LQNUfKwrQFir1ekdOgKU/enEbU2MTu9ZO2kqRF7Bsv53uRdJH9WSvQ5ccq7JI0M12ltjcmrHU+t4Cx6eFmR848OlpQPFmTSZDNPxOyluLc+lLdthfkc8NP+Ei7us1iSraAkHalsz/Cw8kfs8iBbRCvZtCKj69+34olP
X-Received: by with SMTP id fg7mr5895757vdb.17.1394814391200; Fri, 14 Mar 2014 09:26:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Mar 2014 09:26:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Justin Uberti <>
Date: Fri, 14 Mar 2014 09:26:10 -0700
Message-ID: <>
To: Magnus Westerlund <>
Content-Type: multipart/alternative; boundary="bcaec546950550c86c04f49388f5"
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:26:40 -0000

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

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.