The Problem
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
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 87.45.78.65 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.
Thanks for taking the time to put this together. I think it is important to distinguish between endpoints (phones/ATAs) that are traversing NAT/PAT devices and servers — between users and peers — to have a server on a private IP with its local endpoints not NAT/PATd with respect to that server, yet that server being NATd with respect to its PSTN gateway or other SIP+RTP paths requires a different explanation than does that of an endpoint behind a NAT/PAT transacting SIP+RTP to a remote server, which may or may not also be behind a NAT/PAT — but that is what has made this a 7-years-long (longer?) discussion, and it is still hard to follow, in narrative. Thanks for this essay though, it is helpful.
Thanks for your comment. I can’t tell if you are asking me a question though or would like it explained differently?
I feel this article is very informative. I appologize Rldel99 but your narrative was more confusing.
not asking a specific question — suggest though that you could expand on this essay, with a description of just how a NAT’d endpoint, registered to, say, a remote publicIP’d server, is assigned a WAN address:port and how this assignment is achieved/.maintained by the NAT’ing end’s router — what the public-IP server sees, to what address it replies, and how that is translated downstream to the endpoint. This then gets onto the way that routers and their various ALG functions rewrite SIP and RTP packet headers, etc., and what things look like at the server debug level, say. I grapple with this topic a lot, and I don’t yet have it distilled into an elegant outline — obviously!!
I think that this was very helpful and informative to those who are new to this subject.
Great Job Sir!! 🙂
Interesting read. Am having one way audio using a Sonicwall. Told them to apply the Voip switch before the Sonicwall but they did not listen.
What about Voip behind 2 Nat routers? I need to control the network but can’t get to the first router/modem connected to dsl. Anything from the outside comes in as one way audio or I can’t reach the outside voip device from the inside.
sir, we have still problem,issue one way voice travel in nimbuzz
Hi I am trying to use Nimbuzz with voipcallnet.com services but one way audio do you know how to solve this issue.
Hello,
We having the same problem like doing one way call..We are using the VoIP Phone “siemens Gigaset C470IP” and the router is “Dlink DSL-2730B”. So, the problem is the phone making a local calls with both way but not making any mobile or international calls(only one way call, i mean can not hear form other end when we call out side.)
So, can you please let me know what kind of port setting I can change in the router itself..!!!
thanks in advance.!!!!!
The best and most effective way to handle and put an end to all worries about NAT is to use an asterisk IAX2 switch and you are set to go.
Enjoy!!!!!…
Your article is useful. But why should we use symmetric NAT ?
you shouldn’t, that’s the point. Symmetric NAT is more secure though
In case of symmetric NAT, do we need to use RTP server as a relay node ? Is that the general overcome ?
Sipgo download on samsung chat phone but oneway. Audio problem solve this problem
This explains a great deal. We are still having an issue with audio going out but not back in. We are using Avaya IPO and a SonicWall. We have opened all ports on the NAT and are blocking nothing, yet still one way audio. Watching all ports using the packet monitor. We see the audio going out, but not seeing anything hitting the firewall on the way back. We do see the 5060 traffic in and out, so the devices do see each other.
Anyone have some feedback on this issue?
Opening the ports is not the same port forwarding them. If you truly have all the ports open and forwarded onto the PAB then you would not be able to host any other services (unless you have multiple public IPs). You would have to have a one-to-one NAT setup, do you know if this is the case? Your best option is to port forward port 5060 (which it sounds like you are already) and all the RTP port range to the PAB. This should fix it. This must be done at both ends. Let me know your results
We have a large outside IP range. Everything according to SonicWall is setup correctly. We see packets destined for port 5060 come in and go out. During a call, we see packets going out, but nothing coming back to the SonicWall. It’s as if the other side is sending back to the wrong address. We monitored the entire SonicWall, all connections and IPs, and there is 0 communication coming from the telco.
It might be…Have you configured STUN correctly and set the NAT type? If they are not set right your PBX tells the remote PBX to send the audio to the private IP address which is assigned to it which is obviously non routeable on the net…
I do not think the phone guy has STUN setup at all on our IPO 500. Run STUN on startup is not checked. STUN Server IP Address is 69.90.168.13 (no idea where that is) I read that that should be set to the same address as the Puplic IP Address. Should both settings be the same? Would I net need to forward port 3478 as well.
Thanks for the help.
We have multiple IPs. We have the NAT setup any in / any out. one-to-one NAT?
Hi Matt,
I have got this fixed with our IPO and Sonicwall. What you need to do is to turn on “Enable consistent NAT” and “Enable SIP Transformations” under VoIP->Settings menu. This resolves the one-way audio issue. Also, other then allowing the traffic (SIP and RTP), you still need to forward those port to your IPO as well. SIP is 5060-5061 and RTP is the one you can retrieve from your IPO’s System -> LAN1 -> VoIP menu.
I got 2 DIDs from didnumbers.com and I was struggle with the one-way audio for few days and couldn’t get it done until today I found a post for changing settings on Sonicwall instead of on the IPO.
Hope you can resolve the issue.
I had an issue with a Linksys PAP2T with no dialtone and one way audio solved by switching the port from 5061 to 5060.
Hello, my issue is on the vlans. The call manager is on vlan 13. All the phones and jabber client users that are on vlan 13 are not having one way Audio issue. But users on different vlans are experiencing one way Audio issue.
I have performed some trouble shooting tips. If I disable nat on the vlans, users that you on different vlans will experience two way Audio it conversation flows in two direction. The problem now is that only one user can call the other user. Ie user A calls users B and everything is OK. But user B cannot call user A. Can any one assist?