Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used

Magnus Westerlund <> Fri, 06 July 2012 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7B6821F8758 for <>; Fri, 6 Jul 2012 00:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.628
X-Spam-Status: No, score=-105.628 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rgsn1dzCaNso for <>; Fri, 6 Jul 2012 00:00:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 230B821F86DC for <>; Fri, 6 Jul 2012 00:00:29 -0700 (PDT)
X-AuditID: c1b4fb25-b7fc16d000005db2-b9-4ff68d1cfe6d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D3.CD.23986.C1D86FF4; Fri, 6 Jul 2012 09:00:45 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 6 Jul 2012 09:00:44 +0200
Message-ID: <>
Date: Fri, 06 Jul 2012 09:00:43 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To:, "Christer Holmberg (JO/LMF)" <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3Vle295u/wY5lLBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv2WnUwFP8UrVs/+yd7AuFq4i5GTQ0LAROLwyW9MELaYxIV7 69m6GLk4hAROMUpcfPkaylnGKLF+1R5mkCpeAW2JoxuvsYLYLAIqEu9mPmYDsdkELCRu/mgE s0UFgiWmTb/HDlEvKHFy5hOWLkYODhGBMIlj0xxAwsICkRJLfuxnh5g/g1Fi8pcGsHpOAV+J p9tes0BcJClxr3012ExmAT2JKVdbGCFseYnmrbPB7hECuqehqYN1AqPgLCTrZiFpmYWkZQEj 8ypG4dzEzJz0ciO91KLM5OLi/Dy94tRNjMDAPLjlt+oOxjvnRA4xSnOwKInzWm/d4y8kkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0e3pOZu4IJ853bvNnDcsN/o9W9+7+vnNlSGr326doaI1 n+PnMt81c3cfnjH/bCI347Rv4QqK0nLb/xy1f5IW+/G7i2rL/w2nV30/qb2mU+VlMqNWQ3lF dN7UM9eu699/nbky/fnhnkUepd9KVUJ7KvgEtS8v7+Wq2/3gMH/7ssU6+7r9+Xbui1NiKc5I NNRiLipOBAAvhUj3GgIAAA==
Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jul 2012 07:00:31 -0000

On 2012-07-05 21:14, Muthu Arul Mozhi Perumal (mperumal) wrote:
> Hi Christer,
> I think the question boils down to whether the fallback port for RTCP
> described in section 5.1.3 of RFC5761 could be the same as the RTP
> port. This looks fine from a pragmatic point of view. However, the
> following statements from RFC5761 seem to forbid it:
> On receipt of the answer, the offerer looks for the presence of the 
> "a=rtcp-mux" line for each media where multiplexing was offered.  If 
> this is present, then connectivity checks proceed as if only a
> single candidate (for RTP) were offered, and multiplexing is used
> once the session is established.  If the "a=rtcp-mux" line is not
> present, the session proceeds with connectivity checks using both RTP
> and RTCP candidates, eventually leading to a session being
> established with RTP and RTCP on separate ports (as signalled by the
> "a=rtcp:" attribute).
> Not sure if the statement "eventually leading to a session being
> established with RTP and RTCP on separate ports" was intentional. If
> not, it needs to be fixed.

As co-author of RFC5761 I think that sentence reflects how we perceived
it would be used. In other words we only thought of the current legacy,
not what could happen when someone made additional proposals that
interacts with the RTP and RTCP port multiplexing. And based on that you
would fall back to having different ports.

However, I think I have found an issue that prevents one from using the
same port for RTP and RTCP on one side. What I can figure out there
exist nothing in a STUN binding request that are different between a
binding request targeted to the ICE candidate for component ID=0 and
component ID=1. If those two ICE candidates are co-located on the same
port then you don't know which component the binding request is targeted
for. It appears that the only thing keeping those separate is that the
different components would not be present at the same base address+port.

I think this identifies another requirement on bundle as the same is
true between ICE media streams, i.e. m=lines. To ensure that different
m=lines and their candidates can be correctly associated an OFFER with
bundle MUST contain different ufrag per m= block. That way the offerer
can use the security mechanism to verify that this STUN binding request
is intended for m= context X and not any of the others. This is not the
prettiest, but at least possible.

I hope someone can poke a hole in my reasoning and show some way this
can be avoided.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: