Solving problems with external SIP without losing your mind

External SIP or in other words SIP through firewalls and routers or more accurately SIP traversal through Network Address Translation (NAT) is arguably one of if not the most common problem people face.  SIP is notorious for this.  This little article is my attempt to provide a simple no nonsense method of finding and fixing these problems.  Ideally before they ever happen.  To keep it simple I will assume everything on the PBX itself is configured correctly. 

In order to track down and solve these problems it helps to know how NAT and SIP work and why they don't get along.  In the context of this article we will assume we are talking about a NAT gateway that maps internal IP address and port combinations to one external IP address using Port Address Translation (PAT).  

Session Initiation Protocol (SIP) is the standard used to establish, maintain, and terminate calls between two or more endpoints.  SIP is ASCII based so devices are identified using a unique ID similar to an email address such as DeviceID@gateway.com.  When a device makes a call request the request includes the ID of the caller (in the from header field) and the ID of the callee (in the to header field).  The IP of these devices are part of the SIP message.  This is where things go pear shaped because the information in the SIP message is that of the internal network.  The NAT gateway works at a lower level and cannot translate the SIP message.  The result is that the external device sends the audio stream to the internal address indicated in the SIP message.  The result is a failed call or missing audio.

So how do we solve the problem.  SIP traffic is made up of two types.  One is the signalling such as call set up and tear down, the other is the actual Real Time Protocol (RTP) audio packets.  If the PBX is behind a firewall then the most fullproof way to avoid any problems is forward the ports we know will be needed.  The SIP signalling usually uses port 5060.  The audio packets on Asterisk are generally set to use ports between 10000-20000 so we would simply open a small range around port 5060 and the range between 10000-20000.  On the remote phone extension this is not always the best solution because we often do not have easy access and/or cannot control how the remote extension is used.  If the default configuration on the phone causes it to re-register frequently so that any NAT it has to go through opens up that port then we are ok there.  We also have to assume port 5060 is already used and the NAT device may have to port forward to 5061 etc. which is why we should have a range of ports from 5058-5062 (for example) forwarded on the PBX end.

The RTP audio packets are where the majority of problems occur.  First we have to keep in mind that 2 ports are used for each conversation.  One for outgoing and one for incoming.  Secondly and more importantly, these ports are not standardized so they could be any random pair of ports.  As already explained, SIP will indicate what ports it is using internally but NAT will not translate those indicated ports so we must ensure that we do not block inbound SIP packets because they are going to ports that have not been NATed on the outbound. 

About the most fullproof and simplest solution to date is to use a STUN (Simple Traversal of UDP through NAT) server because it does not require any changes to any NAT devices.  All that is required is STUN support on the SIP device and the PBX.  STUN works because it doesn't care about internal networks.  It only looks at the appearance of devices on the external network.  STUN acts as a client server protocol.  A STUN aware device first tries to communicate with the PBX directly.  If that fails it sends a request to a STUN server which responds with the public IP address and associated port.  It will also try identify the type of NAT used but I won't bother going into that for simplicity sake except to say the only time STUN won't work is when symentric NAT is used.  Since that is usually on high end routers used on Enterprise networks it is assumed there are technical people who are always around to manage and deal with these issues so it is beyond the scope of this article.  The only catch with STUN is the requirement to have access to a STUN server.  These days this is not a problem as there are many publicly available and free STUN servers or you can set up your own.

If you only have one SIP device behind a NAT and access to the NAT device you can simply forward the public ports used to the SIP device on the internal network.  If you have multiple devices you need to map individual internal ports which requires each internal SIP device to be manually configured to use a different port.

Reference material and further reading:
Freshmeat: NAT traversal for the SIP protocol
LinuxJournal: How to Configure SIP and NAT
Cisco: Overview of SIP
Fredrik Thernelius Masters Thesis: SIP, NAT, and Firewalls
AsteriskGuru: SIP with NAT or Firewalls

Sections: