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

Ari Keranen <> Mon, 17 December 2012 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F273021F895E for <>; Mon, 17 Dec 2012 07:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IRU-Ei8DpE5v for <>; Mon, 17 Dec 2012 07:38:21 -0800 (PST)
Received: from (unknown [IPv6:2001:14b8:400:101::2]) by (Postfix) with ESMTP id AC90A21F8946 for <>; Mon, 17 Dec 2012 07:38:20 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06CF94E6FA; Mon, 17 Dec 2012 17:38:20 +0200 (EET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CoS0xsY-kflE; Mon, 17 Dec 2012 17:38:18 +0200 (EET)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTPSA id B6BE24E6F8; Mon, 17 Dec 2012 17:38:18 +0200 (EET)
Message-ID: <>
Date: Mon, 17 Dec 2012 17:38:18 +0200
From: Ari Keranen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 17 Dec 2012 15:38:22 -0000

Hi Magnus,

These changes look good to me. And please add forward-reference(s) to 
the ICE-RTSP section where applicable. Couple of nits inline.


On 12/14/12 11:13 AM, Magnus Westerlund wrote:
> 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

(remove "it")

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

"in do SETUP" ?

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