Re: [MMUSIC] RTSP and NATs

[Tom Marshall <[e-mail]>]

On Mon, Feb 03, 2003 at 03:11:57PM -0500, Jonathan Rosenberg wrote:
> 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.

Yes, you are correct.  On initial reading of the STUN draft, I assumed
"server" meant the NAT device.  My understanding now is that the STUN server
resides on a publicly accessible address outside and independent from any
NAT.

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

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

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

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

2. Given a successful STUN setup, does the STUN client direct all UDP
   traffic to the STUN server as 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?  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?

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

> 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).  The biggest
problem I see is that client->server RTP traffic is not expected.  There is
some chance that an intermediate device or proxy may behave badly.  But so
far, it seems to be the best choice.

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

I will keep an eye out, thanks.

-- 
You can complain because roses have thorns, or you can rejoice because
thorns have roses.
        -- Abraham Lincoln