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

[Magnus Westerlund <[e-mail]>]

Ari,

Thanks for keep following up on this. Please see below.

On 2012-12-18 13:43, Ari Keranen wrote:
> On 12/17/12 6:07 PM, Magnus Westerlund wrote:
>> On 2012-12-17 16:36, Ari Keranen wrote:
>>> On 12/6/12 5:03 PM, Magnus Westerlund wrote:
>>>> On 2012-12-05 22:22, Ari Keranen wrote:
> [...]
>>>>>      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.
>>>
>>> According to ICE RFC, if multiple pairs end up nominated due to
>>> aggressive nomination, the highest priority one will be used (you get
>>> some transient behavior).
>>>
>>> But do you mean that you will keep retransmitting on a higher priority
>>> pair even if a lower priority pair has been (aggressively) selected and
>>> all check lists are in Completed state?
>>
>> I guess this needs to be expanded a bit. What I mean is that if due to
>> some reason one get a lower prioritized pair to respond and then get an
>> answer from the more prioritized then it actually makes sense to unlock
>> the full checklist for the more prioritized and let it run to completion
>> prior to sending the PLAY request.
> 
> By unlocking checklist, do you mean moving it from Completed back to
> Running state and continuing all running checks (until when)? And in the
> case you mention above, both candidates are in the same check list, right?
> 
> Anyway, it would be good to clarify this.

I have produced a bit of new text. However, having thought about this I
don't want to make any change to the ICE procedures as that could easily
introduce issues and makes the changes for ICE-RTSP even bigger. Instead
I propose that we change the SHALL to a SHOULD so that client
implementations that see issues with using aggressive nomination can
select to do regular nomination instead and always accept a bit more
delay instead of possibly ending up with different network paths between
different media resources SETUP in the RTSP session.

Thus I have written the following text, please review and comment.

6.7.  Client to Server ICE Connectivity Check

   The client receives the SETUP response and learns the candidate
   addresses to use for the connectivity checks.  The client SHALL
   initiate its connectivity check, following the procedures in Section
   6 of ICE [RFC5245].  The STUN transaction pacer SHALL be used across
   all media streams part of the same RTSP session.

   Aggressive nomination SHOULD be used with RTSP during initial SETUP
   for a resource.  This doesn't have all the negative impact that it
   has in offer/answer as media playing only starts after issuing a PLAY
   request.  Thus the issue with a change of the media path being used
   for delivery can be avoided by not issuing a PLAY request while STUN
   connectivity checks are still outstanding.  Aggressive nomination can
   result in multiple candidate pairs having their nominated flag set
   but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY
   request is sent the media will arrive on the pair with the highest
   priority.  Note, different media resources may still end up with
   different foundations.

   Note: The above does not change ICE and its handling of aggressive
   nomination.  Using aggressive nomination a given media stream can
   have a higher priority candidate pair with an outstanding
   connectivity check message when its check list completes, to also
   move that candidate pair into Succeeded state and set the Nominated
   flag.  Thus moving the used pair to this higher priority candidate
   pair.  To avoid this occurring during actual media transport, the
   RTSP client can add an additional checks when getting the ICE
   processing overall is completed to indicate if there is still higher
   priority connectivity checks outstanding.  If some check is still
   outstanding then some additional timeout or the completion of the
   outstanding checks before progressing with a PLAY request.  One
   alternative is to accept the risk for a path change during media
   delivery.

   For RTSP clients that want to ensure that each media resource uses
   the same path can use regular nomination where both the ICE
   processing completion criteria can be controlled in addition to which
   media streams being nominated for use.  This does not affect the RTSP
   server, as its role is the one of being controlled.






-- 

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