Subject: RE: [Sip] update to nat traversal draft!

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 1 Aug 2001 02:12:33 -0400

> -----Original Message-----
> From: John Lazzaro [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 1:16 PM
> To: [email-masked]
> Subject: RE: [Sip] update to nat traversal draft!
> 
> 
> 
> 
> > Jonathan Rosenberg <[email-masked]> writes
> 
> > An interesting solution might be for the caller (and 
> callee) to always offer
> > two alternate media streams (using the FID draft), one of 
> which is with its
> > public address, and another with the private address. If 
> media starts
> > arriving on the private address, it re-invites to disable 
> the stream on the
> > public one. Actually, that is probably the most robust and simplest
> > solution. Not sure FID gives you all the semantics you need 
> for this,
> > though...
> 
> Yes, the online gaming world uses this technique and it seems 
> to work  
> well, so there's some successful history with the general idea of 
> "send to both the public and private address and see what comes back
> in the return packets on the same UDP port." 

For RTP, the trick is going to be to figure out which of the two succeeded
when you start receiving packets. For regular unidirectional RTP, its not
clear that the source address tells you much. For symmetric RTP, its easy if
you are the active side (the source address in the media in the reverse
direction matches one of the two places you sent media to). 

> Also, if the source 
> address on the return packet is neither the public or private address
> that a third party has handed you, its an indication that the sender
> is behind a NAT that is not a Full Cone NAT, I think (not 
> totally sure).

That doesn't sound right... for all the nat cases it should be the address
you sent to (at least for symmetric RTP). 

-Jonathan R.

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

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 01 Aug 2001 18:43:43 +0300

Hello,

> An interesting solution might be for the caller (and callee) to always offer
> two alternate media streams (using the FID draft), one of which is with its
> public address, and another with the private address. If media starts
> arriving on the private address, it re-invites to disable the stream on the
> solution. Not sure FID gives you all the semantics you need for this,
> though...

I believe it does. The syntax would look like this:

a=group:FID 1 2
m=audio 10000 RTP/AVT 8
c=IN IP4 123.123.123.123
a=mid:1
m=audio 20000 RTP/AVT 8
c=IN IP4 10.0.0.1
a=mid:2

The application would send media to both addresses at the same time (in
parallel), since both contain codec 8.

Regards,

Gonzalo

> 
> >
> > A secondary issue is that you would be exposing private IP addresses
> > on the outside.
> 
> How is that? The whole idea is that a public address is used in the SDP.
> 
> >
> > In the port sharing (on the AVT mailing list) case, with a VPN like
> > tunnel, local calling (2 sip devices behind the same NAT) may require
> > sending all packets across the WAN link and back.
> 
> Yes, as I comment above, it is worse for the VPN case.
> 
> -Jonathan R.
> 
> ---

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: John Lazzaro <[email-masked]>
Date: Wed, 1 Aug 2001 10:24:10 -0700

> you sent to (at least for symmetric RTP). 

I'll be concrete here with an example, although I realize the details
don't match your I-D that closely. Think of two clients, A and B, 
both of which are sending and receiving RTP on a single UDP port (lets
not consider RTCP for now), and who are also communicating with a 
SIP server using that same UDP port. The SIP server is acting as a
B2BUA conference server, shuffling SDP's between clients A and B to
set up the session. No SIP proxies or ALGs in this scenareo.

Each client sends in its SDP to the SIP server the IP/port it thinks it
has. The SIP server can tell if the client is behind a NAT, and if so
adds extra connection and media lines to the SDP whose port and IP number
correspond to those it would add in the received and rport parameters of
a Via. The SIP server sends this (potentially) modified SDP to the other
client, who then uses it to start the RTP session, by sending RTP to
both IP/ports sets in the SDP. This is happening for both clients, so
initially 

-- client A is sending the first RTP wave to one or maybe 2 IP/ports for B
-- client B is sending the first RTP wave to one or maybe 2 IP/ports for A

In a world with static IP's and Full Cone NATs, I believe this first
wave always has a happy ending -- whether both clients are behind a
different NAT, both are behind the same NAT, or one or both have
static IPs, each client will receive one of the two RTP packets sent
by the other, and examining the IP/port reveals one of the  
two sources it also sent to. There's now enough knowledge to discard
the useless address and just send on one channel.

But consider the case where the clients are behind different NATs, 
but B's NAT isn't Full Cone -- it only lets in a UDP packet whose IP/port  
matches the IP/port destination address of the outgoing packet that
established the binding. 

At the start of the session client A sends out
his first wave of two RTP packets, but neither get to client B -- 
B's NAT discarded the packet that should have gotten through. Meanwhile,
B's RTP wave is successful in getting to A, since A has a more sensible
NAT. Client A is able to use the IP/port of the received packet to start
sending data successfully back to B -- but:

      this IP/port will be different than both IP/ports it used
      to send to B the first time, I believe.

And, to finish the story, the hopeless case seems to be when both 
client A and B are behind different NATs that aren't full cone, unless
one of the clients is using a service provider that doesn't do egress
filter, in which case source forging might work ... or else, of course,
use a third party to shuttle every RTP packet.

Is this scenareo too different from your I-D for the conclusions to
apply, or is there an error in the logic above?

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Aug 2001 15:29:18 -0400

> Sent: Wednesday, August 01, 2001 1:24 PM
> To: [email-masked]; [email-masked]; [email-masked]
> SIP server using that same UDP port. 

The same port for RTP and SIP? How will you demux?

> a Via. 

We found that its easier for the client to figure out whether its behind a
nat, rather then the server to figure it out for it. This also simplifies
the overall operation, since proxies can just be proxies rather than having
to do all this SDP rewriting.

> The SIP server sends this (potentially) modified SDP 
> to the other

This works only with symmetric RTP, since otherwise you can't figure out
which one has succeeded or not.

> sending data successfully back to B -- but:

This is symmetric RTP - send the media back to the source IP/port where it
came from. As you point out, it works only when ONE of the two parties is
behind symmetric nats.

> apply, or is there an error in the logic above?

Its pretty close. The main difference is that the clients to the detection
of whether they are behind a nat or not, and allocation of a public address
before the call is made. But otherwise, we use symmetric RTP if possible,
take advtantage of full-cone nats if possible, and only use a third party
intermediary server in the worst case when both are behind symmetric nats.

-Jonathan R.
---

---

From: John Lazzaro <[email-masked]>
Date: Fri, 3 Aug 2001 13:18:21 -0700

>> John Lazzaro wrote:
>> Think of two clients, A and B,

> Jonathan Rosenberg wrote:

> The same port for RTP and SIP? How will you demux?

Pattern recognition on the beginning of the packet plus examination of
the source address, lets the client handle this problem, the SIP server
will only see SIP. For ISO 8859-1, the capital letter that starts a SIP
method will be in the range 65-90 decimal, whereas for version 2 and
above for RTP and RTCP, the first byte will be at least 128 (V=2). 
The next few bytes can be used as sanity checks. 

>> John Lazzaro wrote:
>>
>> The SIP server can tell if the client is behind a NAT, and if so
>> adds extra connection and media lines to the SDP whose port 
>> and IP number correspond to those it would add in the received
>> and rport parameters of a Via.

> Jonathan Rosenberg wrote:
>
> nat, rather then the server to figure it out for it.

Actually, we do also, but explaining it would have added several more 
paragraphs to an overly-long posting :-). Our SIP server always kicks
back the first INVITE with a 401 Unauthorized, the client checks out
the received and rport and adds the NAT information into the revised
SDP for the new INVITE, to which it also adds the appropriate 
SIP Authorization header field.

By the way, anyone reading on the list who wants to experiment with these
symmetric RTP ideas can download our network musical performance client
and bounce packets off our SIP server, I can send SIP logs of your 
session back to you in email if you want to see the NAT detection in action 
from the server side, see:

http://www.cs.berkeley.edu/~lazzaro/sa/sfman/user/network/index.html

for details on the networking and 

http://www.cs.berkeley.edu/~lazzaro/sa/index.html

to actually download.