[asterisk-users] Understanding NAT Traversal

[Mojo with Horan & Company, LLC]

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