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

Magnus Westerlund <> Fri, 06 July 2012 09:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C02FE21F8700 for <>; Fri, 6 Jul 2012 02:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.91
X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5KBt2Gh1QjAN for <>; Fri, 6 Jul 2012 02:25:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB3D521F86BD for <>; Fri, 6 Jul 2012 02:25:09 -0700 (PDT)
X-AuditID: c1b4fb25-b7fc16d000005db2-02-4ff6af03eed1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 76.B4.23986.30FA6FF4; Fri, 6 Jul 2012 11:25:23 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 6 Jul 2012 11:25:23 +0200
Message-ID: <>
Date: Fri, 06 Jul 2012 11:25:22 +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: "" <>
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+NgFprMLMWRmVeSWpSXmKPExsUyM+JvrS7z+m/+BnNOW1tMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGY8m7mQsOC9ecff0dsYGxknCXYwcHBICJhLrD+p0MXICmWIS F+6tZ+ti5OIQEjjFKLFrwUoWCGcZo8Sdk3PZQKp4BbQllq1ZDGazCKhIdLZdZgWx2QQsJG7+ aASLiwoES0ybfo8dol5Q4uTMJywgtoiAusTXvT3MIDazgJnEpVsnwOLCApESS37sZ4dYtoNR 4kfzCrAEp4COxLU56xghzpOUuNe+mg2iWU9iytUWRghbXqJ562ywoUJAxzU0dbBOYBSahWT3 LCQts5C0LGBkXsUonJuYmZNebqSXWpSZXFycn6dXnLqJERiwB7f8Vt3BeOecyCFGaQ4WJXFe 6617/IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw7shqEJwRu+5JevLZotMWdzfcepDAODOF Y/tflsb3EWum3L+9esNsx5a4k7G3Ffs1FdK6P6W/s9Kbo7flqmvPxI1Rf2fpHpJMsp7fvXyV 9ddbfVlBcyxiT869IB256F5J+hVlXpmra88f8We0OuPjxi/ZJCzwrX7bMdYPp1p8/xgv6G2f vMNDVImlOCPRUIu5qDgRAI9ZyWomAgAA
Cc: Christer Holmberg <>
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 09:25:10 -0000

On 2012-07-06 09:00, Magnus Westerlund wrote:
> 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 forgot one thing when writing this. When the offerer gets the SDP
answer and the candidates it contains it will know the source
address+port for any candidate that matches the ones the answerer
provided. Thus most of the answers binding requests will be correctly
determined and bound to the right component. Unfortunately there exist
peer-reflexive candidates and those can't be correctly bound at this stage.


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: