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

[Magnus Westerlund <[e-mail]>]

On 2012-12-17 16:36, Ari Keranen wrote:
> 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.

OK, so far I haven't actually done such an addition to the modified
texts. But I will see what I can do before submitting the update.

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

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