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

[Ari Keranen <[e-mail]>]

Hi Magnus,

On 12/6/12 5:03 PM, Magnus Westerlund wrote:
> On 2012-12-05 22:22, Ari Keranen wrote:
>> 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.

"runs" sounds good to me.

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

Yes, that would be good.

[...]
>>     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?


Cheers,
Ari