Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2001 02:20:56 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 5:28 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> 
> 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?

Well, you don't need an ALG to deal with UAS behind NAT.
THe document handles the case where one, the other, or
both users are behind NATs, without an ALG in all three cases.
The case where both are behind NAT is still a bit unappealing
(requiring an rtp forwarder), but there still may be ways
around that too, even.

Other peer-peer apps have dealt with nats in intelligent
ways, and I think its beneficial to learn from them.

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

Yup.

> Is it possible that this might be munged to
> deal with that problem? 

In some respects, the problem gets easier with this change.
I think (and am not sure), that an implication of using this
symmetric RTP is that sip clients can now traverse socks v5.0
compliant firewalls. Its just a suspicion - I'm looking for
expert input to verify/reject that claim.

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

It doesn't work when there are machines that have
multiple processes, each of which is terminating RTP.
Thats because you can no longer use the system provided
demux (ports), and now must resort to a new, intermediate
demux layer (using ssrc). Plus, it would require signaling
the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
in a separate thread on the sip list.

-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: Michael Thomas <[email-masked]>
Date: Fri, 16 Mar 2001 08:39:22 -0800 (PST)

> in a separate thread on the sip list.

   On the first part, that's mainly an OS implementation
   issue; in fact, an OS could just ignore this problem
   and allow processes to camp on the well known port on 
   a first come first serve basis and it would probably
   work sort of OK until things got sorted out.

   The second part is more interesting. I think that
   we all agree that this would require some sort of 
   hint in SDP; I believe you suggested calling it
   BRTP ala the 1890 profile convention (*). If we
   assumed that that is what was placed into SDP,
   the normal thing a server does is reverses the
   source and destination port to reply, and the
   receiver could just camp on its source port to
   get the return flow, right? In fact, you might
   not even need to modify SDP at all if you got
   an IANA registered port and used that as the 
   key of whether to do BRTP or not. This may
   be risky though, but maybe not: an ignorant
   implementation would just issue a new SDP
   for the other direction which would fail, but
   that's the thing that would happen if it didn't 
   understand the semantics of the explicitly signaled BRTP
   in SDP.

[*] I'm a little worried about name space
    combinatorics here. how would you express
    BRTP+SRTP, for example, in SDP?

		   Mike

---

From: [email-masked]
Date: 16 Mar 2001 17:56:13 -0000

And of course there are SIP-ALGs that don't cost an arm and
a leg that solve all these problems (my biased opinion).

If SIP proxy vendors are interested in partnering to solve
this problem for their customers we would welcome that.

> > since they typically block the dynamic range for

This problem is solved by a SIP ALG sitting in parallel with
a this kind of a firewall. AKA a side-car approach in which
timer based pin holes are created in the SIP-ALG.

Shiv
sip:[email-masked]

Quoting Jonathan Rosenberg <[email-masked]>:

> The case where both are behind NAT is still a bit unappealing> >

> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> [email-masked] with "subscribe" in the body.
>