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

From: Flemming Andreasen <[email-masked]>
Date: Thu, 11 Oct 2012 15:57:56 -0400

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 ?

- 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) ?

I have some editorial/minor comments as well that I will send to the 
authors directly.

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

Thanks

-- Flemming

On 5/7/12 4:39 AM, Magnus Westerlund wrote:
> WG,
>
> This version of the RTSP NAT specification contains some actual changes.
>
> - Specifies how one may Optionally use RFC 6544 TCP based candidates
> with RTSP.
>
> - Found a syntax bug related to ICE password and ufrag. They may
> contain characters that aren't allowed outside of double quote in RTSP
> transport parameters. Thus the syntax has been changed to put the
> password and ufrag values inside double quotes.
>
> - Updated IANA section to better meet the respective registries rules.
>
> - A number of editorial changes.
>
> Diff from the previous version.
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-12
>
> I would appreciate a review of this to confirm that this document is in
> fact ready for WG last call.
>
> Thanks
>
> Magnus Westerlund
>
>
> On 2012-05-07 09:55, [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>>
>> 	Title           : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)
>> 	Author(s)       : Jeff Goldberg
>>                            Magnus Westerlund
>>                            Thomas Zeng
>> 	Filename        : draft-ietf-mmusic-rtsp-nat-12.txt
>> 	Pages           : 30
>> 	Date            : 2012-05-07
>>
>>     This document defines a solution for Network Address Translation
>>     (NAT) traversal for datagram based media streams setup and controlled
>>     with Real-time Streaming Protocol version 2 (RTSP 2.0).  It uses
>>     Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
>>     signalling channel, defining the necessary extra RTSP extensions and
>>     procedures.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-12.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-12.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Oct 2012 16:39:49 +0200

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.

> response convey support for the entire chain). Can you elaborate on that

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.

> in RFC 3489 to try and determine the NAT type. Why is that (shouldn't we

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.

> somebody that has both ICE and RTSP expertise)

Me to.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 29 Oct 2012 14:39:07 -0400

On 10/25/12 10:39 AM, Magnus Westerlund wrote:
> 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.
>

The updated text makes it much clearer.

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

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

> the old STUN spec. But, the text really is a warning that this is brittle.
The updated text makes this clearer.
>> somebody that has both ICE and RTSP expertise)
Can we get any volunteers (or suggested names we can bug :-) ?

Thanks

-- Flemming

> .