Re: [MMUSIC] RTSP and NATs

[Jonathan Rosenberg <[e-mail]>]

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