Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review

Magnus Westerlund <> Wed, 19 December 2012 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 403E521F8750 for <>; Wed, 19 Dec 2012 05:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.216
X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtSVpyG4rc5M for <>; Wed, 19 Dec 2012 05:09:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E833821F87BD for <>; Wed, 19 Dec 2012 05:09:58 -0800 (PST)
X-AuditID: c1b4fb30-b7f736d0000010de-f2-50d1bca57fa5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7A.A9.04318.5ACB1D05; Wed, 19 Dec 2012 14:09:57 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 19 Dec 2012 14:09:57 +0100
Message-ID: <>
Date: Wed, 19 Dec 2012 14:09:55 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Ari Keranen <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje7SPRcDDJ5f1LRoe/OLzaL9zREm i6nLH7M4MHssWfKTyaNzUbTHl8uf2QKYo7hsUlJzMstSi/TtErgylszcwlRwT6fieKNRA+NR 5S5GTg4JAROJ619mMUPYYhIX7q1n62Lk4hASOMkoserwOSYIZzmjRP/fFkaQKl4BbYnLr7Yy gdgsAqoSu87OYQOx2QQsJG7+aASzRQV8JWbt+cUEUS8ocXLmExYQW0RAR6J7212wOLOAu8TR Q9/BNgsLWEnsf9fPCrFsI6PEzhvzwIo4BfQk/r9Zwg5xnqTEommdLBDNehJTrkIcxCwgL9G8 dTbYICGg4xqaOlgnMArNQrJ7FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAzfg1t+G+xg3HRf7BCj NAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/puXx1vdLv8XaD7NILPw/vce mcedamoB50L+8W1yd/nziq/wjI7i9FnSXImrl87TPpHy/FCW0rkjD3sPv65///DlEal2jkOv EkJW3HhsJH+ytHLR5oCJ14RFlSQf8nSK/TTrn/rrwplnwj5y7If8BNdM/9DfsEn2nJPEzFAG m0aN9eo9D9eZK7EUZyQaajEXFScCAJhlr2ctAgAA
Cc:, mmusic <>
Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review
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: Wed, 19 Dec 2012 13:10:00 -0000


Thanks for keep following up on this. Please see below.

On 2012-12-18 13:43, Ari Keranen wrote:
> On 12/17/12 6:07 PM, Magnus Westerlund wrote:
>> On 2012-12-17 16:36, Ari Keranen wrote:
>>> On 12/6/12 5:03 PM, Magnus Westerlund wrote:
>>>> On 2012-12-05 22:22, Ari Keranen wrote:
> [...]
>>>>>      Aggressive nomination SHALL be used with RTSP.  This doesn't have
>>>>> the
>>>>>      negative impact that it has in offer/answer as media playing only
>>>>>      starts after issuing a PLAY request.
>>>>> But it does have the downside of possibly selecting a lower-priority
>>>>> pair due to single dropped (e.g., due to congestion) connectivity
>>>>> check
>>>>> message for a higher priority pair. That said, probably SHALL is
>>>>> appropriate here, just wanted to make sure the implications are
>>>>> understood.
>>>> Yes, but with ICE-RTSP you will retransmit the higher priority also,
>>>> thus if that works and you get a response that alternative is nominated
>>>> and will be used. But we probably should clarify what it means when
>>>> multiple candidate pairs are nominated, and in worse case the server
>>>> will use different paths for different media streams.
>>> According to ICE RFC, if multiple pairs end up nominated due to
>>> aggressive nomination, the highest priority one will be used (you get
>>> some transient behavior).
>>> But do you mean that you will keep retransmitting on a higher priority
>>> pair even if a lower priority pair has been (aggressively) selected and
>>> all check lists are in Completed state?
>> I guess this needs to be expanded a bit. What I mean is that if due to
>> some reason one get a lower prioritized pair to respond and then get an
>> answer from the more prioritized then it actually makes sense to unlock
>> the full checklist for the more prioritized and let it run to completion
>> prior to sending the PLAY request.
> By unlocking checklist, do you mean moving it from Completed back to
> Running state and continuing all running checks (until when)? And in the
> case you mention above, both candidates are in the same check list, right?
> Anyway, it would be good to clarify this.

I have produced a bit of new text. However, having thought about this I
don't want to make any change to the ICE procedures as that could easily
introduce issues and makes the changes for ICE-RTSP even bigger. Instead
I propose that we change the SHALL to a SHOULD so that client
implementations that see issues with using aggressive nomination can
select to do regular nomination instead and always accept a bit more
delay instead of possibly ending up with different network paths between
different media resources SETUP in the RTSP session.

Thus I have written the following text, please review and comment.

6.7.  Client to Server ICE Connectivity Check

   The client receives the SETUP response and learns the candidate
   addresses to use for the connectivity checks.  The client SHALL
   initiate its connectivity check, following the procedures in Section
   6 of ICE [RFC5245].  The STUN transaction pacer SHALL be used across
   all media streams part of the same RTSP session.

   Aggressive nomination SHOULD be used with RTSP during initial SETUP
   for a resource.  This doesn't have all the negative impact that it
   has in offer/answer as media playing only starts after issuing a PLAY
   request.  Thus the issue with a change of the media path being used
   for delivery can be avoided by not issuing a PLAY request while STUN
   connectivity checks are still outstanding.  Aggressive nomination can
   result in multiple candidate pairs having their nominated flag set
   but according to Section of ICE [RFC5245] when the PLAY
   request is sent the media will arrive on the pair with the highest
   priority.  Note, different media resources may still end up with
   different foundations.

   Note: The above does not change ICE and its handling of aggressive
   nomination.  Using aggressive nomination a given media stream can
   have a higher priority candidate pair with an outstanding
   connectivity check message when its check list completes, to also
   move that candidate pair into Succeeded state and set the Nominated
   flag.  Thus moving the used pair to this higher priority candidate
   pair.  To avoid this occurring during actual media transport, the
   RTSP client can add an additional checks when getting the ICE
   processing overall is completed to indicate if there is still higher
   priority connectivity checks outstanding.  If some check is still
   outstanding then some additional timeout or the completion of the
   outstanding checks before progressing with a PLAY request.  One
   alternative is to accept the risk for a path change during media

   For RTSP clients that want to ensure that each media resource uses
   the same path can use regular nomination where both the ICE
   processing completion criteria can be controlled in addition to which
   media streams being nominated for use.  This does not affect the RTSP
   server, as its role is the one of being controlled.


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: