SIP and NAT traversal

1
votes

I'm trying to understand the exact problem with NAT and SIP and have seen many different explanations. Here's what I've gathered so far:

1) SIP User agent is both initiating and accepting calls, therefore unless the NAT/firewall is configured to accept incoming traffic on this port it cannot work - this makes sense but sounds more firewall and port mapping

2) SIP messages contain IP addresses (that can be private) in the body which requires NAT traversal - if this is the case

3) it's not a problem with SIP but with RTP, whose parameters that are included in the SDP as part of the SIP message body that include private IP addresses

4) something to do with UDP vs. TCP?

4
siptraversalnat
And we're all trying to understand what programming problem you're trying to solve. – Don Roby
@Don Roby: I trust you apply the same comment to every other SIP, RTP, TCP and UDP question on SO? – Frank Shearar
Only if they contain no indication of a programming problem. – Don Roby

4 Answers

3
votes

When a call is done with SIP the calling endpoing does not know the endpoint the call must reach i.e. the endpoint's IP.
It only knows the IP address of the SIP server.
So the INVITE goes to the SIP server and SIP servers "knows" where/how to reach the called endpoints.
The idea is that the SIP messages contain SDP data that contain the information needed so that eventually the phones will be able to set up a session and users will be able to start talking.
These data include IP, port, codecs and other parameters.
So if one of the phones is behind NAT the phone will report as its IP e.g. IP_X which is its private IP and the other endpoint can not reach that IP; the public IP is unknown at that point.

1
votes

All of your assumptions are correct. In SIP, you can split it into 2 main problems: signaling and media. The signaling runs in SIP over either TCP or UDP, and the connection can open from both directions, as calls can be dialed or accepted by user agents. The media runs over RTP (and RTCP), which is usually done over UDP (unless you're trying to achieve NAT traversal), and then it might go over TCP). The ports and addresses here are allocated dynamically, need to go both ways and run on multiple sessions (=multiple sockets and connections).

To achieve NAT traversal, you will usually use multiple techniques: STUN, TURN, ICE, HTTP tunneling and even an SBC. NAT traversal for SIP requires external support from servers - usually not the SIP server - that are dedicated for the job.

1
votes

I'll disagree mildly with Tsahi Levent-Levi's answer.

The problem is that the IP address you put in your Via, Contact, From/To headers, SDP, etc., must be globally routable. If you're behind a NAT you'll obviously need to put in your external IP address.

Implementing ICE, using STUN, etc., allows you to do this automatically, but you can always solve the program manually.

In particular, by inspecting your machine's routing table you can tell whether or not the machine you're calling is behind a NAT or not (by virtue of knowing that work machines are behind this VPN NAT here, and local machines are on this subnet, and everything else runs through your router's NAT). With that information you may find out a NAT's far-side/external address somehow (STUN gives this automatically, but your internet router may have a static address, or you could contact an HTTP server capable of returning your external address, or ...). Once you have that far-side/external address, you can put the address where necessary - your Contact header, SDP c= headers, and the like.

1
votes

There is a whitepaper by Eyeball Networks that clearly explains the NAT & firewall traversal problem for voip and the STUN, TURN, ICE solution. There are also a couple of great diagrams on how SIP P2P and SIP TURN calls are achieved at http://www.eyeball.com/voip-solutions/stun-turn-ice.htm