Re: [MMUSIC] RTSP and NATs

[Jonathan Rosenberg <[e-mail]>]

Tom Marshall wrote:

>>STUN does not allocate the addresses. It merely tells the client what a 
>>regular, off the shelf NAT has allocated to a user. Since regular, 
>>off-the-shelf NATs do not know anything about RTP port pairings, two 
>>separate STUN requests will result in a nat allocating two bindings 
>>which are most likely not consecutive (or follow the odd/even rule). 
>>THis is dealt with through an SDP extension that allows a client to 
>>provide a specific address and port for SDP 
>>(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt).
> 
> 
> This draft again assumes that RTP is the only transport choice:
> 
>   rtcp-attribute =  "a=rtcp:" port
> 
> What if there were some other UDP based transport that required two UDP
> ports (perhaps even "RTPng")?  You would need yet another draft to address
> it.  Why not make the solution generic instead?

Well, if thats so, I would have rather had such a debate in the context 
of the above draft. Anyway, I know of no other media stream that uses 
UDP that uses multiple ports AND that has an algorithmic relationship 
between those ports (i.e., has no way to express in the SDP which ports 
are needed). Seems like a non-problem.

> 
> 
>>>Regardless of STUN, it may be useful to have a mechanism for non-contiguous
>>>UDP port mappings.  I would argue in favor of a list based approach that 
>>>has
>>>general applicability instead of an approach that is specific to RTP.  For
>>>example, the client_port attribute could use '/' to separate non-contiguous
>>>ports:
>>>
>>>Transport: rtp/avp/udp;unicast;client_port=7834/23478
>>
>>Well, I will take this opportunity to once more complain, as I have done 
>>at IETF meetings in the past, of the continued cost of repeating 
>>protocol development related to session initiation twice - once for SIP, 
>>and once for RTSP. We already have a way to do this representation in 
>>SDP for SIP. Seems like we need to repeat such design now for RTSP.
> 
> 
> I am not familiar with SIP (although I will read up on it before the next
> meeting).  My only concern is that any modification to RTSP does not limit
> itself needlessly.  If SIP has done so (and it appears that at least one SDP
> draft is doing so), then perhaps those decisions should be reconsidered.

Ultimately, I'd like to see SIP used to set up sessions both 
point-to-point and to media servers, and if control is needed, RTSP be 
introduced in order to achieve that end. There are many benefits from 
using a single protocol to achieve setup. We've stumbled onto one of 
them (duplication of specification work). Another is a single 
call/communications routing infrastructure. I have been hoping to find 
the time to write that up in an I-D, but there are always higher 
priority ones than chasing a goal that no one else seems to care about...


> 
> 
>>>If someone were to propose a simple and complete solution for all
>>>NATs that everyone could get behind, that would be worth supporting.  STUN
>>>is, by its own admission, not a complete solution[2].
>>
>>Heh. How about world peace while you are at it.
> 
> 
> And a complete IPv6 transition too, eh (reducing or eliminating NAT)? ;-)

Dont get me started...

> 
> 
>>The problem is this. Experience has shown that solutions which ALWAYS 
>>work tend to be way too expensive in situations that are far more 
>>simpler solution will do. There is therefore a cost/generality curve 
>>with a highly non-linear behavior, which results in solutions being 
>>defined across this curve. STUN happens to be extremely cheap to do in 
>>the cases where it works. THe most general solution, which are 
>>media-relay types of solutions, are very expensive because of the need 
>>to route media through intermediaries.
> 
> 
> I have just started looking at STUN but I have some questions:
> 
> 1. Given a NAT that supports RTSP (eg. Linux 2.2 masquerading with an RTSP
>    module loaded), will the client "detect" that it is behind a NAT? 

Yes.

>    If so,
>    how does this affect the Transport: header as it passes through?  It
>    seems to me that the RTSP enabled NAT will break the STUN-enabled
>    Transport: header.  If this is the case, I think that STUN should be
>    reconsidered (at least for RTSP) as would break an otherwise functional
>    NAT setup.

A smart ALG won't. It should know not to muck with IP addresses inside 
of the RTSP message if they are not private addresses (if stun is used, 
those addresses will have already been changed to public ones by the 
RTSP client). Indeed, one can imagine usign RTSP to setup a streaming 
media session to some third party device outside of the nat, in which 
case the ALG has to know not to change the IP. I wonder if the linux 
code you cite supports that.

Which, of course, brings me to my beef with ALG - the wrong people write 
them in general. Only an RTSP expert would probably know to look for 
such nuances (even then...), and Linksys and Netgear to not hire such 
people - its not their business.


> 
> 2. Given a successful STUN setup, does the STUN client direct all UDP
>    traffic to the STUN server as a relay point,

No, the stun server is NOT a relay point.

>    or does the client assume
>    that all UDP packets sent between the STUN mapped port and any outside
>    address will have the same NAT mapping? 

STUn works a binding discovery mechanism ONLY if the client can assume 
that any client outside of the nat can send to that address.



> I will have to do some checking,
>    but IIRC the Linux 'ipchains' NAT code does mappings with a '5-tuple':
>    client ip, client port, nat port, server ip, server port.  If the latter
>    case is assumed (no relay), I don't think that the STUN mappings would
>    behave as described in the draft.  Packets sent to and from the appserver
>    will have a different 5-tuple, and thus a different nat port, rendering
>    STUN ineffective.  Has this case been considered?

Certainly. This is called "symmetric NAT". Its common but to date the 
full-cone variety, which maps bindings by private IP/port alone, is 
quite prevalent amongst the home NATs. The presenec of a symmtric NAT is 
discoverable by STUN, in which case you need somethign else to receive 
media. Symmetric RTP, for example, is an application-specific method. 
Another would be TURN 
(http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-00.txt) which 
does use a relay.

> 
> 
>>>If the vendors won't support it, then adding more Transport attributes
>>>creates more implementation headaches for ourselves with little or no
>>>benefit.  I think the best solution is to find out how to persuade the
>>>vendors to properly support RTSP.  It is really not much more difficult
>>>to support than, say, FTP.
>>
>>I sinceerely doubt that.
> 
> 
> Which do you doubt?  The implementation headaches or that RTSP support is
> not difficult in NAT?

That RTSP ALGs are likely to be supported widely in the vast array of 
$100 NAT boxes on the market. FTP *is* widely supported, but RTSP is a 
domain-specific protocol, and I suspect not on their radar screens.


> 
> 
>>ANYWAY, all of that said (just responding to this assault on STUN), I do 
>>not think STUN by itself is the right solution to RTSP nat traversal. 
>>THere are two options that are better.
>>
>>OPTION 1: Symmtric RTP. See 
>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.txt. 
>>Effectively, the IP address/ports provided by the RTSP client are 
>>ignored by the server. The client sends RTP/RTCP packets to the server, 
>>and the server sends media back to the client at the source ip/port that 
>>the RTP/RTCP came from. Requires no changes to the RTSP protocol, except 
>>to recommend this method. No STUN support needed. Works through all NAT 
>>types. It will require the client to send keepalive packets if there is 
>>a pause in media.
>>
>>NB: This ONLY works if the RTSP server is on the public Internet!!!!
> 
> 
> This is similar to a technique that we (RealNetworks) use for our internal
> transport.  It is quite effective (but not 100% of course). 

I am curious about what problems you have encountered.


-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic