Subject: symmetric RTP as a solution for NAT traversal

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2001 17:56:10 -0500

Folks,

I would like to draw your attention to some work we have done on NAT
traversal for sip, documented in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

Earlier versions of this draft recommended running RTP over TCP to traverse
NATs, which is very unappealing. This -01 draft describes a way to run RTP
over UDP, and still traverse off the shelf, vanilla, regular, ALG-free NATs.
However, to do so requires a small change in the way RTP is done for
unicast, and a small update to some ongoing SDP work. Thats the reason for
my broad cross-post.

The problem with RTP usage for unicast (at least within SIP), is that there
are effectively two RTP sessions established; the caller specifies, in the
INVITE, the IP address and port pair where they would like to receive
packets, and the called party specifies, in the 200 OK, the IP address and
port where they'd like to receive packets. There are no restrictions on the
source port for sending to these addresses. Unfortunately, this is why NAT
traversal is hard. Most NATs which support UDP create NAT bindings, based on
the source address of packets, when a packet is sent outwards. However,
here, we must create the binding by inspecting the SDP. Thats why ALGs were
needed for UDP.

So, our solution is to fix that. To do so, we define symmetric RTP (aka
bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it uses a
single connection, rather than two. One participant in a call acts as the
active side, and another, the passive side. The active participant sends the
RTP packet, and the passive side receives it. Packets are sent back from the
passive user to the active one, using the source address learned from the
RTP packet just received. So, lets say Joe calls Bob. Joe acts as the active
side of the RTP connection. When the 200 OK arrives from Bob, it contains
Bob's address for RTP; say its IP address X and port Y (abbreviated {X,Y}).
So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets say
Joe is behind a NAT. Sending this RTP packet creates a binding in the NAT,
from {U,V} to {A,B}, and rewrites the source IP address/port of the packet
to this pair. When Bob receives this, Bob can send media back to Joe, using
destination address {A,B} and source {X,Y}. These packets arrive at Joe's
NAT, and because a binding has been established, the destination is
rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has just
traversed a NAT without an ALG. The IP address Joe provided in his SDP was
never used, which was good, since it was wrong.

Note that who is active, and who is passive, as far as setting up the RTP
connections, is completely unrelated to who initiates the call. 

This little trick means that we can establish RTP-over-UDP calls with SIP
through vanilla NATs so long as one side has a public address. This covers a
huge amount of calling patterns we are seeing, right off the bat, including
PC to phone and phone to PC. In the case where both are behind NATs, the
draft describes usage of an RTP translator that can be used as an
intermediary. Other solutions may be possible depending on how the NAT
treats UDP packets. More to come.

I have left out some details about how we determine who is active, and who
is passive, and how this is signaled. Well, fortunately for us, there has
been some excellent work in mmusic on the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

which discusses exactly how to use connection oriented media within SDP. All
we need to do is define an additional keyword, BRTP, or something like that,
to describe this new type of connection oriented media, symmetric (aka
bidirectional) RTP.

The draft goes into details about all of this. It requires only small
changes to existing SIP/SDP/RTP devices to support, and can solve a problem
which I believe will continue to hamper ubiquitous deployment of SIP.

Comments? I'll be discussing this work in more detail on Friday during the
SIP session at IETF 50.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Dirk Kutscher <[email-masked]>
Date: 15 Mar 2001 16:59:32 +0100

>>>>> "Jonathan" == Jonathan Rosenberg <[email-masked]> writes:

    Jonathan> Folks, I would like to draw your attention to some work
    Jonathan> we have done on NAT traversal for sip, documented in:

    Jonathan> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

    Jonathan> [...]

    Jonathan> I have left out some details about how we determine who
    Jonathan> is active, and who is passive, and how this is
    Jonathan> signaled. Well, fortunately for us, there has been some
    Jonathan> excellent work in mmusic on the following draft:

    Jonathan> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

    Jonathan> which discusses exactly how to use connection oriented
    Jonathan> media within SDP. All we need to do is define an
    Jonathan> additional keyword, BRTP, or something like that, to
    Jonathan> describe this new type of connection oriented media,
    Jonathan> symmetric (aka bidirectional) RTP.

    Jonathan> The draft goes into details about all of this. It
    Jonathan> requires only small changes to existing SIP/SDP/RTP
    Jonathan> devices to support, and can solve a problem which I
    Jonathan> believe will continue to hamper ubiquitous deployment of
    Jonathan> SIP.

    Jonathan> Comments? I'll be discussing this work in more detail on
    Jonathan> Friday during the SIP session at IETF 50.

Jonathan, Henning,

interesting idea! Some comments:

I think, both the ALG- and the "bidirectional RTP" approach have their
merits and drawbacks:

What is nice about the bidirectional RTP approach is that users are
not required to install additional SIP-ALG boxes in order to use their
SIP telephony equipment (assuming a few characteristics of the typical
installed NAT device).

What's not so nice is that both endpoints *and* provider-operated
proxies have to be NAT-aware: e.g., endpoints have to use the pseudo
hostname in the Contact-header of REGISTER requests and make use of
a=direction (and BAVP) in the session description. Proxies will have
to support this stuff (plus the SDP-manipulation and
RTP-translator-control).

ALG-based solutions (given corresponding NAT-device and firewall
control) would at least allow users to deploy "plain", NAT-naive SIP
endsystems, and providers would not have to support the
SDP-manipulation and RTP translator functionality in their
proxies. Basically, it allows to keep the knowledge of NAT inside the
NATed network.

A note on the use of SDP: Since bidirectional RTP is not a different
transport (it's just a convention on the usage of source and
destination ports) and we are still using the RFC 1890 profile, maybe
it's more appropriate to use an a= line to signal the use of
bidirectional RTP?

-- 
	Dirk

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 Mar 2001 14:28:27 -0800 (PST)

Jonathan, 

On the surface this doesn't sound unreasonable to
me, but my main question is whether, in the end
you end up needing ALG functionality to deal with
NAT's whether this incremental step is necessary.
That is, if you end up needing an ALG to deal with
the UAS-behind-the-NAT problem, have we bought 
anything?

On a different tangent, (never being one to shy
away from having multiple contradictory opinions
on the same subject), plain old firewalls (not
NAT'ing firewalls) are current still a problem
since they typically block the dynamic range for
RTP. Is it possible that this might be munged to
deal with that problem? Ie, allow RTP on a well
known port and demux using the SSCR? I seem to
recall that this has a fatal problem, but I can't
remember what it is. I really should go re-read my
Chapman/Zwicky first, but... If we could do this
your BRTP proposal would make RTP look like any
old UDP command/response protocol from the
firewall standpoiont which might interesting.

		Mike