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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 10 July 2012 12:30 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57621F8702 for <mmusic@ietfa.amsl.com>; Tue, 10 Jul 2012 05:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.607
X-Spam-Level:
X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwCiCVRhmshD for <mmusic@ietfa.amsl.com>; Tue, 10 Jul 2012 05:30:55 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 284EA21F8602 for <mmusic@ietf.org>; Tue, 10 Jul 2012 05:30:54 -0700 (PDT)
X-AuditID: c1b4fb30-b7f916d000000bfb-9d-4ffc2099e7d1
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D5.EF.03067.9902CFF4; Tue, 10 Jul 2012 14:31:22 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 14:31:21 +0200
Message-ID: <4FFC2099.7020702@ericsson.com>
Date: Tue, 10 Jul 2012 14:31:21 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <4FFC1D96.107@ericsson.com> <4FFC1E2E.6090509@ericsson.com>
In-Reply-To: <4FFC1E2E.6090509@ericsson.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3VneWwh9/g+sTeCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIWf77IW3FOsON69i7WB8ZJUFyMnh4SAiUTr6TdMELaYxIV7 69m6GLk4hAROMUpsafrCDOEsZ5Q4Ob2BHaSKV0Bb4uCMhYwgNouAqsTcrd/AbDYBC4mbPxrZ QGxRgWCJadPvQdULSpyc+YQFxBYREJaY8fYvWI2wQKTEkh/7wWqEBNwlHjetYgaxOQV0JM79 vMsCcZGkxL321WD1zAJ6ElOutjBC2PISzVtnM0P0aks0NHWwTmAUnIVk3SwkLbOQtCxgZF7F KJybmJmTXm6ul1qUmVxcnJ+nV5y6iREYmAe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGGN3db2v37FeaKbJ0+tijkFx1efM98vffTRB8jRTscnD42xq d3sl15ZLX5kVc1EzY6HybGPv3jN+XQWSIV5aGzcbW8uarJlvp9y1Z76yZ+N5x/JOdc071fwm C8zv8f4s3XB742OFSReYXNbbeP94n9xwKej/4fn823VfrLdblCDK8ffa/PknPZVYijMSDbWY i4oTAVeG0RIaAgAA
Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 12:30:56 -0000

On 2012-07-10 14:21, Stefan Hakansson LK wrote:
> On 07/10/2012 02:18 PM, Stefan Håkansson LK wrote:
>> 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.
> 
> So, now I am confused. Are we OK as is, or should the Bundle draft be 
> updated, or something else? (To me it sound like the Bundle draft should 
> be updated.)

Yes, I think there is need for an update. But there is actually two
issues here.

One is the question of how a bundle implementation sending an offer to a
non-bundle capable answerer deals with determining which m= lines
particular received binding requests are related to in the case of
peer-reflexive candidates. This appears to be possible to resolve by
having different ufrags per m=line in the offer.

The second question is how to handle RTP-RTCP mux fallback. This does
not appear to be able to be resolved by using the ufrag as that is
either per session level or media level. Thus some other solution is
needed. One is to simply have to allocate and gather candidates for two
local ports even when supporting bundle. It is at least better than 2*N
where N is the number of bundled m= lines.

Cheers

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------