Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer Holmberg <> Fri, 14 March 2014 05:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 181B51A0052 for <>; Thu, 13 Mar 2014 22:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZWHN2BDFbvRd for <>; Thu, 13 Mar 2014 22:56:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A31B11A0040 for <>; Thu, 13 Mar 2014 22:56:47 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-be-53229a175b53
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F7.11.04853.71A92235; Fri, 14 Mar 2014 06:56:39 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 06:56:39 +0100
From: Christer Holmberg <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux
Date: Fri, 14 Mar 2014 05:56:38 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_cm0fhueueaioe4gj0u8m7vqa1394776596681emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvja74LKVgg8nHrC1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozjc1rZC/rkK55/lGtgvCHZ xcjJISFgIrF0cwsrhC0mceHeerYuRi4OIYETjBIrptxkgXCWMEpcfTKTuYuRg4NNwEKi+582 SIOIgJrEw1m7wJqZBaoltq34xwRiCwsYSxy6vJQZosZEYu7E1ywQdp1E59kJjCA2i4CqRO+y ZewgNq+Am0TjgiZmiF1bWCUWL/gBVsQpECjxYctesEGMQNd9P7WGCWKZuMStJ/OZIK4WkFiy 5zwzhC0q8fLxP6iDciQOvtnGDLFAUOLkzCcsExhFZiFpn4WkbBaSMoi4jsSC3Z/YIGxtiWUL XzPD2GcOPGZCFl/AyL6KUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMw3g5u+W20g/Hk HvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEZpHL5Q7f71hHTGj6Mn HiWuTmdqqpHS9FxmpLfM5q3mgcfJRqmObC90rbdNOaJ8zX1mmNA5g/jy8K6o/znaRdGHpfhW GJvYqJTKxq/xYyj/u6dQgHV74pYVekvY7ubUC90w6nrC5nvg0+fs7gxpnVlavx+WZcf0rOvO ODjZyPSKNC/fwrh8JZbijERDLeai4kQAG47qoYUCAAA=
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 05:56:50 -0000


Just to clarify: you would still use the a=rtcp-mux attribute, right?

It is e.g. needed to inform intermediaries (that may not understand BUNDLE) about the usage of RTCP mux.



Sent from my Sony Ericsson Xperia arc S

Justin Uberti <> wrote:

On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmberg <<>> wrote:
Hi Justin,

> I think rtcp-mux has to be a MUST use when BUNDLE is used between the two endpoints. (If the endpoint doesn't support
> BUNDLE, rtcp-mux is not required.)
> Otherwise, you get into weird edge cases, such as where you have a data channel (no RTCP component), and then want
> to add audio (with RTP and RTCP components). You could bundle the audio RTP over the existing data channel transport,
> but it's not clear what you should do with the RTCP component. Mandating rtcp-mux avoids this issue completely.

According to section 4 in RFC 5761, if you multiplex RTP and RTCP on the same port, you need to assign dedicated PT values to the RTCP packets, which means that at least PT values 64-95 cannot be used for RTP.

As you have been one of those talking about the risk of running out of PT values, I just want to make sure you have taken this into consideration :)

Yes. The upside of rtcp-mux far outweighs this minor limitation.