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.
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
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. 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].
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? 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.
[1] Another example (with heavy industry backing) is http://www.upnp.org/ .
[2] From STUN draft: "STUN does not enable incoming UDP packets through
symmetric NATs ..., which are common in large enterprises."
--
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX.
Attachment:
pgp00013.pgp
Description: PGP signature