[asterisk-users] Understanding NAT Traversal

[Samy Kamkar]

Hi guys,

In addition to the required RTP ports needing to be opened on a NAT 
router, the primary difference between HTTP and SIP is that SIP opens up 
an additional session (the RTP session) on a completely different port 
(and possibly IP) as stated below, and even more specifically, the SIP 
packet defines where to connect to.

When you send an HTTP request, the only place your IP address is located 
is in the IP header itself, not the HTTP header of the packet. A typical 
(see: symmetric) NAT changes your internal IP address in the IP header 
of the HTTP you've sent to the IP address of the gateway, sends it along 
its merry way, and waits for it to come back (with the same source and 
destination ports/IPs, but swapped). Once it comes back, it contains all 
the data you asked for. At no time does the remote HTTP server ever have 
any idea that you're on an internal IP.

SIP, on the other hand, typically only handles the call setup/etc, but 
not the audio (RTP) stream. When you send a SIP INVITE, included is an 
SDP header which contains _your_ IP address in addition to the IP header 
of the packet. While your router modifies your internal IP address to 
the gateway address in the IP header, it does not alter the internal IP 
address in the SDP header (unless it's a SIP-enabled router/fw). The 
destination then attempts to connect to the RTP IP+port you provided, 
which is an internal IP address and probably not accessible from 
wherever you're sending your INVITE to. Asterisk's sip.conf's `externip` 
and `localnet` lines are used to resolve this when making calls through 
Asterisk.

The way SIP works is much more like active FTP connection rather than 
HTTP, where there are actually multiple connections and the important 
data you're trying to transmit (audio, data, pron) is sent on a 
different port. One of the benefits is that you don't need to transmit 
the data yourself if you're simply handling the session data between two 
remote parties. Being a SIP proxy in this scenario is very similar to 
FTP's "FXP".

Hope that helps

-samy

Mojo with Horan & Company, LLC wrote:
> I'll take a stab at the first one, but I am probably gonna get nailed 
> for my own rudimentary understanding of it...
>
> hugolivude wrote:
>> I understand how sitting behind a NAT could cause problems for a SIP 
>> UA.  The SIP UA would create SIP mesages using IP addresses from 
>> inside the network (i.e. 192.#.#.# or 10.#.#.#) and these IP 
>> addresses are of course unnavigable for the recipient.
>>
>> What I don't get is why don't web browsers suffer the same problem? 
>
> When the initial http request goes out the packet has a return address 
> with a source port on the (for example) 192.x.x.x machine.  the NAT 
> router does the same thing, sending it out into the world, with a 
> return address containing a source port on the NAT router.  when it 
> receives a response, it knows which internal box to route it to, 
> things are OK. The HTTP server simply sends its reply to that return 
> address, and it's routed back the way it came.
>
> I think the biggest problem with SIP is the RTP ports.  The initial 
> SIP request goes out (for example) to port 5060, and FROM port 5060 as 
> well.  The response needs to get back to the SIP UA on that port 
> (which would limit the nat router to only be able to deal with ONE 
> internal ua at a time, if they were both using the standard port 
> 5060), which could conceivably happen easily enough.  But in the SIP 
> "handshake" more ports are chosen, typically in the 10,000 to 20,000 
> range.  The NAT router would then need to be configured to direct that 
> anticipated RTP stream to the proper internal client.  That just 
> doesn't happen :)
>
> For various reasons, I'm not too partial to UPnP, but maybe there 
> needs to be a SIP UA that uses UPnP to configure a NAT router for it, 
> when an RTP stream is begun?
>
> Now the clincher to all of this is that I'm merely talking about the 
> ip packets transferred and their return addresses.  While I'm not 
> qualified or experienced enough to comment on problems that might 
> arise with the contents of the SIP headers themselves, I suspect 
> that's where the REAL trouble lies with SIP NAT traversal.  The SIP UA 
> needs to put the proper return address in the SIP headers before the 
> lower layers of the OSI model take over.  It can't know its 
> externally-visible ip address unless A) the user manually enters it or 
> B) it can ask some outside server what it's perceived address is.
>
> Moj
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users