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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------