Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-12.txt

[Flemming Andreasen <[e-mail]>]

On 10/25/12 10:39 AM, Magnus Westerlund wrote:
> Hi Flemming and WG,
>
> Thanks for the detailed review. As you might have seen we managed to
> update this document to address your comments.
Thanks for the update Magnus - responses below, incl. a request for more 
people to weigh in.

> Below is answers to these
> questions.
>
> On 2012-10-11 21:57, Flemming Andreasen wrote:
>> Hi Magnus
>>
>> I have taken a look at the document and, the only real technical
>> comments I have at this point are:
>>
>> - Section 6.3 (Non-Supporting Proxies), last paragraph says that:
>> <quote>
>> This variance in results is the reason
>>     we don't recommend the usage of the Proxy-Require header. Instead we
>>     recommend the usage of the Supported header to force proxies to
>>     include the feature tags they support in the proxy-supported which
>>     will provide a positive indication when all proxies in the chain
>>     between the client and server support the functionality.  Even if not
>>     explicitly indicating support, any SETUP response including a
>>     transport specification with "D-ICE" will be implicit indication that
>>     the proxy chain supports at least passthrough of this media.
>> </quote>
>>
>> I didn't follow the inferred logic in the last sentence (how does the
>> response convey support for the entire chain). Can you elaborate on that
>> part ?
> We have reformulated this to hopefully make it clear. But the logic is
> like this.
>
> If a client includes a transport specification with protocol D-ICE, and
> that reaches the server and that supports it and provide that transport
> spec in its answer that again reaches the client then you know that the
> D-ICE is supported. This would only occur if any proxies are either
> explicitly supporting it or are of the pass-through version.
>
> That needs to be compared with a proxy-require where the passthrough
> would be forced to negatively answer that. Also a supported header value
> will be stripped by a passthrough proxy as it is not explicitly
> supporting the functionality.
>
> That is why you have cases where trying and see if it works might be the
> best option.

The updated text makes it much clearer.

>> - Section 8 (Fallback)
>> Section title and overall description is a bit confusing (it seems to be
>> about about backwards compatibility with non-ICE supporting RTSP entities).
>> Also, the section recommends use of defunct (obsolete) behavior defined
>> in RFC 3489 to try and determine the NAT type. Why is that (shouldn't we
>> be based on RFC 5389) ?
> This fallback text is intended as a discussion of what would happen if a
> ICE enabled client would try to use its capabilities to facilitate
> NAT/FW traversal when the server is non ICE capable.
>
> The second thing to remember is that a SETUP request normally provides
> multiple transport offers, rather than doing try, error, re-try other
> alternative.
>
> Thus I at least think it is worth talking what it would mean to use STUN
> derived reflex ports as transport identifier and then be willing to send
> STUN checks towards the server. So far you actually don't need to do a
> attempt to determine the mapping behavior. If one would try it could
> reveal the failure mode earlier.
The updated text makes the brittleness issue clearer and also notes that 
RFC3489 based NAT type detection may not work, so I'm ok with that.

> But, maybe we should re-structure this section to say that like ICE the
> best fallback addresses from functionality point of view would be a
> relay address. Barring that one can attempt using a STUN derived one.
> This may however fail, and have unexpected impact on server.
>
I think it would be worthwhile including that (but would welcome other 
points of view).

Also, apart from this, I think we are ready to issue WGLC on this one.

> I do agree that we should not depend on the classification behavior of
> the old STUN spec. But, the text really is a warning that this is brittle.
The updated text makes this clearer.
>> Also, we could really use another set of eyes on it (preferably by
>> somebody that has both ICE and RTSP expertise)
> Me to.
Can we get any volunteers (or suggested names we can bug :-) ?

Thanks

-- Flemming


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