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

[Ari Keranen <[e-mail]>]

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.


Cheers,
Ari

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

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