Quick question re. NAT traversal. 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? A web brower behind a NAT sends an HTTP request much the same way as a SIP UA might send an INVITE. However it seems to me that in the case of the Web Browser, the HTTP request includes the IP address of the NAT and the NAT takes care of routing the server's response back to the web browser. So what am I missing here? Why doesn't it work the same way for SIP? Where does the HTTP / SIP analogy breakdown? Perhaps NATs just take care of HTTP better than SIP because it's an older protocol (i.e. perhaps NATs replace the unnavigable IP address with a navigable one for HTTP requests)? Curious anyway. Similarly, why do we need a timeout on a SIP registration? Does this work the same way as a "heartbeat" enabling disconnected UA to be unregistered? Thanks, H -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061010/dacd3105/attachment.htm
Mojo with Horan & Company, LLC
2006-Oct-10 15:37 UTC
[asterisk-users] Understanding NAT Traversal
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
On Tue, Oct 10, 2006 at 05:03:30PM -0400, 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? > A web brower behind a NAT sends an HTTP request much the same way as a > SIP UA might send an INVITE.Kind of, except: (1) HTTP runs over TCP, SIP runs over UDP. This is not in itself a major issue, because the NAT firewall will keep state open in both cases (so that inbound response packets are de-masqueraded back to the original host). But: (2) All the web content (whether it be HTML, embedded images etc) is pulled back down the same TCP session as requested it in the first place. With a SIP phone, one UDP exchange performs the INVITE signalling, but a separate (unrelated at the IP layer) UDP exchange is used for the actual audio traffic. (3) A web browser is not expected to receive inbound requests from a central server. A SIP client has to receive unsolicited INVITEs for inbound calls. (4) The HTTP request does not include any IP addresses within the request or response. SIP headers and SDP bodies do: e.g. Contact: <sip:bob@192.168.0.1> This information is invalid on the other side of a NAT, since these addresses are not reachable by the other party. So SIP and NAT do not mix well. There are a host of half-baked solutions which sometimes work and sometimes don't, because even the concept of NAT itself is not well-defined, and NAT implementations differ widely (see RFC 3489 for the gorey details) Probably the most nearly-baked solution is to use a SIP and RTP proxy, such as siproxd, and give it a real public IP address. Roll on the day when all NAT routers have this built in. For more info see: * http://www.voip-info.org/wiki-NAT+and+VOIP * http://www.sipcenter.com/sip.nsf/html/WEBB5YN5GE/$FILE/SIPNATtraversal.pdf * http://siprouter.onsip.org/doc/gettingstarted/ch04s05.html HTH, Brian.
On Tue, Oct 10, 2006 at 05:03:30PM -0400, hugolivude wrote:> Similarly, why do we need a timeout on a SIP registration? Does this > work the same way as a "heartbeat" enabling disconnected UA to be > unregistered?Yes, that's the purpose: so that if you unplug a SIP phone without giving it a chance to unregister itself, it will eventually be unregistered due to the timeout. (Additionally, some half-baked SIP NAT solutions require you to set a ludicrously short registration timeout, e.g. 20 seconds, just to keep UDP state open on the firewall) Regards, Brian.