Quite a common problem, when a voice call is successfully completed, but the voice packets only successfully travel in one direction, or not at all.
A one-way audio call is when you have a call between two phones, and one of them cannot hear the other.
A no-audio call is when you have a call between two phones, and neither of them can hear the other.
Without going deeply into the networking stuff, it is important to remember that a call consists of the signaling part (SIP) and the media part (RTP). When a call connects initially, that indicates that the signaling part works OK. But if the media part malfunctions, then we have a one-way-audio or no-audio problem. This is greatly simplified explanation, but it is important to distinguish between signaling and media.
The possible causes of no-audio or one-way-audio can be listed like this:
Let‘s go look at each possible cause in slightly more detail.
The first things you must eliminate are a faulty phone, handset earpiece, or a headset on a softphone. It sounds obvious, but there are countless stories about call-center agents with broken headphones who report a troubleshooting job and keep several people busy for hours.
To begin with, there are some obvious reasons why RTP traffic may be blocked or consumed.
VoIP is blocked in some countries (Kuwait, Libya, North Korea, Oman, Qatar, Syria, the UAE, Guyana, and Venezuela). VPN is the answer, but this is pretty obvious and hardly ever requires any troubleshooting.
VoIP traffic can be and is blocked by some Internet providers. Consult with them if you suspect this could be the case. It‘s hard to detect, but if suspicion arises, it never hurts to ask.
For a voice call to function properly, the RTP packets must travel from one side to the other, through the firewall/NAT. A firewall can be misconfigured to block audio traffic.
Devices under NAT could be unable to bypass NAT properly. A device could be unaware of the NAT’s existence and send its local IP to the Internet. NAT is a common cause of one-way and no-way audio on VoIP calls. Best practices have been written up in an RFC to define NAT traversal for SIP-based voice communications.
Double NATing: when a device is under double NAT. This can work if configured properly for the internet, but for the audio it introduces more variables and creates unecessary complications. It should be avoided.
An IP could be blocked on either side on the firewall. It is a common way for VoIP providers to block everything, but allow only trusted IPs to connect; the so-called whitelist. If a device’s IP is not on this whitelist, that means it is blocked. This mainly applies to signaling, but some providers also do it with RTP ports. RTP traffic is usually accepted from everywhere, but it’s always good to check.
The RTP ports might not be open. Sometimes it is necessary to open ports and forward them correctly. Without this, the audio will not be able to reach its intended recipient.
VoIP uses IP to send voice packets as the usual traffic, and is governed by the same network rules. When routing rules are configured, it is important to understand that if you can send packets from A to B, that does not mean that B to A will succeed. This error causes one-way audio. Such network routing misconfigurations should be approached in the same way as a usual network problem. There are top-down, bottom-up, or other troubleshooting methods to solve this.
A separate note is with VPNs. If your traffic is routed over VPN and you have a no-audio/one-way-audio problem – test an alternative route to eliminate the possibility that VPN could be the cause of the problem.
This happens very rarely, but sometimes devices are under public IPs which change from time to time. This could also be the cause of a no-audio or one-way audio problem.
The SIP standard defined in RFC3261 is sometimes implemented with exceptions or interpretations made in various devices, thus leading to broken audio.
For example, the header in the SIP packet can have local IP, and some devices will fail to deliver audio because of this.
The same goes for a wrongly configured Via: header.
A broken SDP could have multiple c= lines or an m= line missing altogether. It could be tagged as ‘send only’ or ‘receive only’. The ports could be missing, or could be wrong.
It is important to investigate SIP packets, looking for the audio problems; for example, with Wireshark or Homer.
But before that, it’s worth mentioning how important is to completely disable ALG (SIP Application Layer Gateway) on the devices. Broken ALG implementations are cursed daily by VoIP engineers.
A malformed RE-Invite could cause audio to cease in the middle of the call. Check how the SIP packet looks and resolve the problem.
This does not directly mean that RTP is corrupted, but could explain why audio is not flowing. Disagreement between end-points over which codec to use for the call can be avoided by forcing some common codecs, such as G711 or G729, to be given the highest priority.
SBC/Softswitch can have faulty SIP implementation or misconfiguration, as described above. This will lead to one side (or both sides) not transmitting or receiving audio.
If the RTP packets have the wrong sequence, the audio on some phones will not play. Wireshark can indicate when packets are corrupted or malformed.
Handling could be corrupted in various ways. Here are some links which show a futile Freeswitch fight in an attempt to properly communicate with Sonus SBC.
Some SBC/Softswitches do not accept audio from an RTP port range greater than 50,000. The safe zone is 10,000–50,000.
Some SBC/Softswitches ignore IP:PORT in SDP, and send media back to the IP:PORT from where the SIP message was received.
As you can see, there are a number of possible causes of a no-audio or one-way audio problem. We will cover the troubleshooting steps to take to resolve this problem in a future article.
Let us know if we missed something. We will be glad to add it to this list.
