[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] RTSP and NATs


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
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic