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

Magnus Westerlund <> Thu, 06 December 2012 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A36E621F86DD for <>; Thu, 6 Dec 2012 07:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 NhqqSzDkW3Nv for <>; Thu, 6 Dec 2012 07:03:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6C11321F86CC for <>; Thu, 6 Dec 2012 07:03:13 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-c4-50c0b3b0f3a4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A4.23.26143.0B3B0C05; Thu, 6 Dec 2012 16:03:12 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 6 Dec 2012 16:03:11 +0100
Message-ID: <>
Date: Thu, 06 Dec 2012 16:03:07 +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+Jvje6GzQcCDD7tELFoe/OLzaL9zREm i6nLH7M4MHssWfKTyaNzUbTHl8uf2QKYo7hsUlJzMstSi/TtErgyFvavZS24KF8x+dJXxgbG YxJdjJwcEgImEgt2zmaGsMUkLtxbz9bFyMUhJHCSUWLN0zYmCGcZo8TBU78ZQap4BbQlrk79 yAZiswioSNz9+58dxGYTsJC4+aMRLC4q4Csxa88vJoh6QYmTM5+wgNgiAjoS3dvugsWZBdwl jh76DrZZWMBKYv+7flYQW0hAV2LhjGlgNqeAnsSBjZOgrpOUWDStkwWiV09iytUWRghbXqJ5 K8QHQkC3NTR1sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15utIkRGL4Ht/xW3cF455zIIUZp DhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAu/Tnty9QWhojAUOv8rA2e1yLv uvC2Gdycwdl7MmTPsZf92deXtDU+WBL/+Rz7BKPk9l18aSHr/N+y2Dh8erB88b3czLR8o9Xb Dmi+2xUd7NlinPpsT/qfT+LTWl3tN7vuuiDI+VIzm+HX9cfPk/hS3n9mjFA9EJ/wvapLzV1X ou0c92Wz6Z1KLMUZiYZazEXFiQAXHcBFLQIAAA==
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: Thu, 06 Dec 2012 15:03:14 -0000

Hi Ari,

Thanks for the review. I feel much more confident now that we haven't
significantly screwed up any ICE details.

On 2012-12-05 22:22, Ari Keranen wrote:
> Hi,
> I reviewed the draft-ietf-mmusic-rtsp-nat-14 and I think the document is
> in pretty good shape and ready to move forward. Some (mostly editorial)
> comments to consider:
> 3.  Solution Overview
>         The client then installs the STUN servers on each of
>         the local candidates transport addresses it has gathered
> I would rather say "The client then prepares to act as a STUN server on
> each [...]"

Sure, maybe "runs STUN servers" is better than both "installs" and
"act". They are STUN server, but with limited utility. Act as STUN
servers sounds like it is impersonating STUN, rather than actually being
STUN servers.

>         If the server has a public
>         IP address, then a single candidate per address family
> In some cases (e.g., certain ISPs, I've heard) even "public" IP address
> does not mean you're not behind a NAT. Maybe it's better to say here "If
> the server is not behind a NAT". Same issue in step 8.

Sure, maybe we need to define what we mean with not being behind a NAT.
It is a matter of being reachable from the top anchorin address domain
in regards to the clients.

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

>    the NAT need to be refreshed by the client to server traffic provided
>    by the STUN keep-alive.
> s/keep-alive/keep-alive mechanism/ (or messages).
> Also in section 5.11.

Will address.

> 5.7.  Client to Server ICE Connectivity Check
>    The client receives the SETUP response and learns the candidate
>    address to use for the connectivity checks.
> s/address/addresses/ (right?)
>    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.

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


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: