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

Re: [MMUSIC] RTSP and NATs

inline.

Tom Marshall wrote:

On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote:
Hi,

Here is a proposal to the RTSP spec for how to handle NATs using STUN. Please read and comment. It is planned to discuss NAT's on wednessday's RTSP telecon.

I believe that a viable NAT traversal protocol should not require changes to
the protocols that it supports.  If it is desired that RTSP and STUN work
well together, I think the proper course of action is to modify the STUN
draft to allow requests for consecutive blocks of mapped UDP ports required
by RTSP and RTP.
No, that is impossible. You have misunderstood how STUN works.

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


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.



Having said that, here are my thoughts on STUN in general:

I am not in favor of STUN. There are other NAT traversal protocols[1] which
are already deployed and adding support for this one just muddies the waters
further.
There are many topologies in which UPnP will not work. These icnlude:

* cases where the residential nat doesnt support it
* cases where there are multiple nats in tandem, such as cable operators that nat their networks
* enterprises with multiple access points to the public Internet


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.

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.



The major focus of STUN seems to be the rapidly growing "NAT in a box" class
of router devices that have proliferated around broadband and wireless. Given the current lack of support for RTSP, why would we assume that vendors
will be any more willing to support STUN?
You have again misunderstood how stun works. STUN requires no support in NATs. A provider that wants to provide streaming media services using rtsp would deploy the stun server, NOT the ISP or IP access provider of the end user.


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.

What incentive has Linksys, Netgear, and the REAMS of other home nat boxes to support ALGs for RTSP? Are those companies the experts on RTSP? Surely not! The need to separate out applications from NATs and firewalls is central to the midcom working group and much of the other work going on in IETF.


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

OPTION 2: Coming Soon
I am working on a draft (out before the -00 deadline end of this month) that finally unifies all of the mess of nat traversal together - STUN, TURN, symmetric RTP. It has the property that it always results in the optimal media path, lowest latency, lowest cost, and highest probability of working (i.e., you hear media), compared to any other technique. In the case of the RTSP server running on the public Internet, it would end up working a lot like OPTION 1 above. But, it would also work in cases where that was not true, for example, a client connecting to a media server in another enterprise that is behind a nat.

More to come soon.


In fact, one might say that the best approach for nat traversal is not to document it in the RTSP revision itself, as there are multiple solutions in any case. We have done that for sip, documenting solutions in a separate document:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt

Then there are other thigns coming like nsis. So, keeping this separate from RTSP itself is probably a good thing.

-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