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

[Magnus Westerlund <[e-mail]>]

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.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------