When making audio calls using SIP the phone rings but when it is answered there is only one way audio or no way audio.
What Cause One Way Audio
The cause of one way audio is a combination of NAT and STUN (which we’ll come onto later). Let’s talk about NAT first.
NAT by default blocks ALL incoming connections from the Internet. This is well known and isn’t normally a problem; if you want a server accessible through the Internet you just port forward the relevent ports to it. The issue here is that SIP uses a large range of ports and it will choose one at random for each SIP call. We can’t just open our network up to a massive range of ports, it is bad security practice. More to the point how does it even work if you are not port forwarding any ports? All inbound traffic should be blocked by the NAT because there is no port forwarding going on. So how does it work? It works by using a technique known as UDP Hole punching.
UDP Hole Punching
UDP hole punching is a clever technique. It works by “punching” holes through the NAT device to create NAT mappings. What happens in the process is that it opens up the ports which in turn allows audio to flow inbound through that port. Two devices behind two NATs can communicate this way without having to explicitly open ports on the NATs. VoIP switch A sends traffic to VoIP switch B; in the process it opens up a port which is mapped to it. At the same time switch B does the same thing opening it’s own port and creating a mapping. The first two packets sent from both devices will fail when they arrive at their remote locations but all traffic afterwards now works as the ports are now open. Too see why this is only possible using UDP read The Differences Between TCP and UDP.
How SIP Works
Basically the two VoIP switches talk to each other using SIP and decide which ports are going to be used for the audio calls. A simplified example is as follows:
- Switch A: Hi switch B, I have a SIP audio call here with IP 192.168.1.8 that wants to use port 65875 to send and receive audio with a SIP phone you know about with extension 234, what is it’s IP address and and what port will it use to send and receive the audio?
- Switch B: It’s IP is 192.168.1.2 using port 57683 so send audio to this. I will pass on your IP and port information to the SIP phone with extension 234.
- Both switches pass on this info to the SIP phones and they talk directly to each other using those IP’s and ports.
It basically controls everything that is needed in setting up the call. For each call SIP will find a spare port, allocate it, send these details to all parties, set the call up and ring the phones. Once the call has finished SIP terminates the session and informs the VoIP switch that this port can be reassigned to another call.
SIP and NAT Traversal
The problem with SIP and NAT is that SIP doesn’t know it is behind a NAT. Let’s say your VoIP switch is 192.168.1.1 and the remote VoIP is 192.168.2.1. NAT translates the SIP packets to the public IP address as normal when traversing the internet but it does not change the actual data in the SIP packets themselves (the payload). It is the payload that has all the information about what ports and IP addresses to use for the audio call. The local VoIP sends it’s own private IP and port across to the remote VoIP in the SIP payload. This is never going to work because private IP addresses are non routable on the Internet. We need some method to help SIP know it is behind a NAT device and send it’s public IP address across instead of it’s private IP. This where a STUN server comes in.
Stun stands for Session Traversal Utilities for NAT and as you may have guessed by it’s name it is a collection of utilities to aid in the traversal of a NAT devices.
Most of you will know that NAT changes your private IP address to the public IP address but not everyone knows that it ALSO changes the source port. Using our examples above switch A uses IP 192.168.1.8 and 65875 but when this comes out the other side of the NAT it may be seen as 22.214.171.124 and port 87563. Simply put a STUN server detects this and sends this information back to the switch so it can amend the SIP packets accordingly.
STUN fixes the apparent short comings of SIP and NAT but it doesn’t work with symmetric NATs. This is the cause of one way audio.
Why You Experience One Way Audio
If you remember I spoke about UDP hole punching at the beginning of this article; it allows traffic to punch through the NAT. How is it possible to experience one way audio when NATs at both sites are configured exactly the same? How is it possible to have UDP hole punching working at one end and not at the other? It is probably because you have different types of NAT at each site. NAT isn’t standardised and there are various implementations of it. The site with one way audio will have a symmetric NAT as this is the one that is incompatible with STUN. Yes this is the cause of one way audio! STUN doesn’t work with a symmetric NAT, here is why.
All types of NAT besides symmetric NAT use the same source port when punching holes to different destinations (the STUN server and remote VoIP). A symmetric NAT however, punches a new random source port for different destination. In other words rather than use one NAT mapping for connections to different destinations a symmetric NAT creates additional NAT mappings for each connection using new ports. What this means is that the port that will be opened for the actual audio will be different to the one the STUN server detected. In this case a STUN server is useless and the VoIP switch can never learn it’s NATed port. Since it can’t learn it’s NATed port it can’t send this information across to the remote VoIP so audio fails in this direction.
This is the cause of one way audio. If both NAT devices are non symmetric they will get the correct information through STUN and audio will flow both ways. If one device is symmetric and the other is non symmetric only one of them can learn the correct port so audio flows one way producing one way audio.
How to Achieve Two Way Audio
The solution is far simpler than you might have thought. All you need to do is the following:
- On your VoIP switch (Avaya in my case) reduce the SIP port range. How many SIP calls do you think you will have going at any one time max? Most of you reading this will be 10 at a guess, maybe 20. In my case the range was 49152 to 53246 so I reduced the max range to 49162 giving me 10 ports.
- On your NAT device set up port forwarding for the 10 ports to your VoIP switch.
The reason this works is because when the VoIP learns it is behind a symmetric NAT via STUN it will instead tell the remote switch to send audio to it’s local (non NATted) ports. Since we reduced the port range to 10 and have now opened these ports manually on the NAT it will allow the audio to come in. This will eliminate one way audio.