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

[Magnus Westerlund <[e-mail]>]

Hi Flemming and WG,

Thanks for the detailed review. As you might have seen we managed to
update this document to address your comments. 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.

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

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

> Also, we could really use another set of eyes on it (preferably by
> somebody that has both ICE and RTSP expertise)

Me to.

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