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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 14 December 2012 09:13 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 62BFC21F84FA for <mmusic@ietfa.amsl.com>; Fri, 14 Dec 2012 01:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.204
X-Spam-Level:
X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U46OIIZzZu49 for <mmusic@ietfa.amsl.com>; Fri, 14 Dec 2012 01:13:19 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 213D821F84F8 for <mmusic@ietf.org>; Fri, 14 Dec 2012 01:13:15 -0800 (PST)
X-AuditID: c1b4fb25-b7fb26d000006129-48-50caedaa5581
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.F3.24873.AADEAC05; Fri, 14 Dec 2012 10:13:15 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Dec 2012 10:13:14 +0100
Message-ID: <50CAEDAA.3080803@ericsson.com>
Date: Fri, 14 Dec 2012 10:13:14 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com>
In-Reply-To: <50C0B3AB.4010509@ericsson.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje7qt6cCDHYv4bJoe/OLzaL9zREm i6nLH7M4MHssWfKTyaNzUbTHl8uf2QKYo7hsUlJzMstSi/TtErgynt7+wVrQblpxqHUaWwPj Ic0uRk4OCQETieV/fjBC2GISF+6tZ+ti5OIQEjjJKNH9eC0zhLOcUeL+mYPsXYwcHLwC2hKv /4eBNLAIqEocPXGRFcRmE7CQuPmjkQ3EFhXwlZi15xcTiM0rIChxcuYTFhBbRMBM4uGE/WA1 zAIlEpdntIHVCAtYSex/1w82Rwiod+2rXWA2p4COxKODu9ggjpOUWDStkwWiV09iytUWRghb XqJ562xmiF5tiYamDtYJjEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLjTYxAoP34JbfqjsY75wT OcQozcGiJM5rvXWPv5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGnjDB1jDtXz/lb9oqKjV0 TWrItZw7Nc5676T8SxM+6Ul53Hu1Z/2j0BMGHm2nnyw5VNZ2kcl40f+rlrdjs3/Py9281OJ7 OndDXegOLTZvteIpoQJVHJM7xKa2/bkpydj/K4Vp/+rdH+/s236XRYLZ8VZCTfqKcL+fFx8z Lo9e0bXzblfl+bXrlFiKMxINtZiLihMB79qVhSwCAAA=
Cc: mmusic <mmusic@ietf.org>, draft-ietf-mmusic-rtsp-nat@tools.ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review
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: Fri, 14 Dec 2012 09:13:21 -0000

Hi,

Follow up on comments as I have edited proposals to resolve the issues.
I have the general set of changes on review with my co-authors. Hope to
be able to submit next week.


On 2012-12-06 16:03, Magnus Westerlund wrote:
> 
> On 2012-12-05 22:22, Ari Keranen wrote:

>>
>>
>>         If the server has a public IP address with a single candidate
>>         per media stream, component and address family, then the server
>>         may be configured to not initiate connectivity checks.
>>
>> This is the "ICE-RTSP", right? Maybe one (small) subsection defining
>> this "feature" would make sense. Now it's a bit trickled around in this
>> section, sec 4.8.1, 5.4, etc. For someone not familiar with ICE-RTSP, it
>> looks like you're talking about ICE lite.
> 
> Yes, this is definitely ICE-RTSP. It is still doing triggered checks.

However, I think you might have misinterpreted what ICE-RTSP really is.
It is the full usage of ICE as defined by this specification. The high
reachability configuration of the RTSP server is a variant of the normal
ICE-RTSP behavior.

I have tried to clarify this and created a special section for
discussing the differences, this include the text in the old 4.8.

5.  ICE-RTSP

   This Section discusses differences to the regular ICE usage defined
   in [RFC5245].  The basic for the modifications in the general
   procedures are in the clearer client/server roles that RTSP provides
   and how the RTSP Session establishment signalling occurs within RTSP
   compared to SIP/SDP Offer/Answer.

5.1.  ICE Features Not Required

   A number of ICE signalling features are not needed with RTSP and are
   discussed below.

5.1.1.  ICE-Lite

   The ICE-Lite attribute shall not be used in the context of RTSP.  The
   ICE specification describes two implementations of ICE: Full and
   Lite, where hosts that are not behind a NAT are allowed to implement
   only Lite.  For RTSP, the Lite implementation is insufficient because
   it does not cause the media server to send a connectivity check,
   which is used to protect against making the RTSP server a denial of
   service tool.

5.1.2.  ICE-Mismatch

   The ice-mismatch parameter indicates that the offer arrived with a
   default destination for a media component that didn't have a
   corresponding candidate attribute.  This is not needed for RTSP as
   the ICE based lower layer transport specification either is supported
   or another alternative transport is used.  This is always explicitly
   indicated in the SETUP request and response.

5.1.3.  ICE Remote Candidate Transport Header Parameter

   The Remote candidate attribute is not needed for RTSP for the
   following reasons.  Each SETUP results in an independent ICE
   processing chain which either fails or results in promoting a single
   candidate pair to usage.  If a new SETUP request for the same media
   is sent, this needs to use a new username fragment and password to
   avoid any race conditions or uncertainty about which round of
   processing the STUN requests relate to.

5.2.  High-Reachability Configuration

   ICE-RTSP contains one variant for RTSP Servers that are not behind
   NATs, i.e. are highly reachable by the clients.  Similar to ICE-Lite
   this allows for some reductions in the servers burden.  However, due
   to the need to still verify that the client is actually present where
   it claims the server must also initiate binding requests and await
   binding responses.  The reduction for the high-reachability
   configuration of ICE-RTSP is that they don't need to initiate its own
   checks, and instead rely on triggered checks for verification.  This
   also removes a denial of service threat where a RTSP SETUP request
   will trigger large amount of STUN connectivity checks towards
   provided candidate addresses.



>>
>> 5.12.  Re-SETUP
>>
>>    If the client decides to change any parameters related to the media
>>    stream setup
>>
>> Could clarify (again) here that we talk about ICE parameters.
> 
> Yes, definitely. I actually had to think a long time if this was only
> ICE parameters or also RTSP parameters. But, it is so unnecessary to
> restart ICE for most RTSP parameter changes.

When looking at this again, I though it unclear enough that I have
attempted a bit of rewording. I propose the section should read like this:

6.12.  Re-SETUP

   A client that decides to change any parameters related to the media
   stream setup it will send a new SETUP request.  In this new SETUP
   request the client MAY include a new different username fragment and
   password to use in the ICE processing.  New username and password
   SHALL cause the ICE processing to start from the beginning again,
   i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]).  The client SHALL
   in case of ICE restart gather candidates and include the candidates
   in the transport specification for D-ICE.

   ICE restarts may be triggered due to changes of clients or servers
   attachment to the network, i.e. changes to the media streams
   destination or source address or port.  Most RTSP parameter changes
   would not require an ICE restart, instead existing mechanisms in RTSP
   for indicating from where in the RTP stream they apply should be
   used.  These include performing a pause prior to the parameter change
   and then resume or if server supports in do SETUP during PLAY state,
   and thus use RTP-Info header (Section 18.43 of
   [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media
   stream the change apply.

   The server SHALL support SETUP requests in PLAY state, as long as the
   SETUP changes only the ICE parameters, which are: ICE-Password, ICE-
   ufrag and the content of ICE candidates.

   If the RTSP session is in playing state at the time of sending the
   SETUP request requiring ICE restart, then the ICE connectivity checks
   SHALL use Regular nomination.  Any ongoing media delivery continues
   on the previously nominated candidate pairs until the new pairs have
   been nominated for the individual candidate.  Once the nomination of
   the new candidate pair has completed, all unused candidates may be
   released.

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
----------------------------------------------------------------------