One Way Audio, Common Problems and Solutions
We’ve all experienced one-way audio on a phone call before. It’s the typical “Hello, Hello?” and “Can you hear me now?” conversation. The issue is not specific to Voice over IP (VoIP) and affects an astonishing 1 in every 100 calls. However, it does tend to show up more in VoIP because there are simply more things that can cause it. So, in this article, we’ll go over how to troubleshoot one-way audio, potentially fix it, or at the very least – understand it.
What is One-Way Audio and why does it occur?
One-way audio happens when the receiver can’t hear you, but you can hear them (or vice versa); and it’s possible for this to occur at any point during call.
Some common reasons for one way audio include:
- Bandwidth
- Latency / Jitter
- Quality of Service (QoS)
- Firewall / NAT Issue
- Incompatible Codecs
- Routing Issue
- Equipment Problem
Bandwidth
One reason for one way audio is bandwidth. Not having enough of it can disrupt the flow of data packets and cause a drop in audio . Remember, while a VoIP call might squeak by with 100 kbps of bandwidth, it’s wise to estimate your bandwidth needs based on the number of simultaneous calls and application data you plan on transmitting. Even then, it is recommended to add 2-3 times that amount as a buffer (the extra capacity is to prevent interruptions during peak periods of heavy usage).
Depending on the codec you use for your audio stream it can have a great impact on the amount of bandwidth required to make a good quality call. The minimum bandwidth requirements per call:
| Codec | Bitrate | Bandwidth Usage |
|---|---|---|
| G.711 | 64 Kbps | 87.2 Kbps |
| G.729 | 8 Kbps | 31.2 Kbps |
| G.723.1 | 5.3 Kbps | 20.8 Kbps |
| G.726 | 32 Kbps | 55.2 Kbps |
Latency (Jitter)
Another common reason for one way audio during a call is Latency, but more specifically something called “Jitter”. Latency is the amount of time it takes one packet of information to get from point “A” to “B” and back to point “A” again. Jitter is the variance in those round trip times. Latency and Jitter are both measured in milliseconds (ms), and 1ms is equivalent of 1 / 1000th of a second (so pretty fast).
For optimal VoIP call quality you want a network latency of less than 50ms with a network jitter less than 30 to 50ms. In the real world with congested networks you might legitimately see latencies as high as 300ms (or more) for some things destined to and from the internet. Thankfully, modern VoIP devices have something known as a “Jitter Buffer” which greatly reduces the lost audio associated to Jitter. These work by waiting a preset amount of time for packets to arrive before building them back into an audio stream for you to hear.
Quality of Service (QoS)
By default, network devices (routers, switches, firewalls, etc.) use a queueing strategy called “First In First Out” (FIFO). While incredibly fair, it can inadvertently delay a time sensitive packet from getting to its destination on time. If the packet arrives too late it may even be discarded causing a momentary loss of audio (garbling). Quality of Service (QoS) is a method to identify, mark / tag, rate-limit, and otherwise prioritize packets of information on a data network. It is often used in voice networks to increase the quality and clarity of VoIP audio.
To implement QoS it is required to modify settings on both your network devices, as well as the VoIP device(s). It is important that note that not all routers and switches support this functionality. Even if they do, they all have their own way of implementing them. Check with the manufacturers of these devices if you question whether or not they support this feature.
Business Class Devices will likely support it, and also adhere to a common standard of how to do this using IP Addresses, MAC Addresses, IP Precedence, Differentiated Services Code Points (DSCP), and some type of a weighted queueing strategy.
In CGI’s data networks, there are only 3 markings that matter for VoIP prioritization.
| IP Precedence (binary) | DSCP Value (binary) | Description |
|---|---|---|
| 0 (000) | 0 (000000) | Default, Routine (be) — Regular Traffic |
| 3 (011) | 26 (011010) | Flash Priority (af31) — SIP Traffic |
| 5 (101) | 46 (101110) | Critical, Expedited Forwarding (ef) — RTP Audio |
Network Address Translation (NAT)
NAT converts the Public (WAN) IP Address that your Internet Service Provider (ISP) assigns you and changes it to a group of Private (LAN) IP Addresses for your internal devices to use. It also makes your internal network more secure by not making it directly available from the public Internet. Now – That is vastly over simplified, and I will skip the lengthy networking class on PAT, NAPT, NAT44, NAT64, etc… but for the purposes of this article consider that protocol ports are also used in association to NAT and required for NAT to function properly, specifically TCP and UDP.
Most VoIP providers (including CGI) handle one instance of NAT pretty easily, but sometimes – depending on the router/firewall used in your network – it may be required for you to forward certain communication ports through directly to your VoIP device(s) in order for service to function properly.
Commonly VoIP uses ports 5060 – 5080 (UDP or TCP) for session management (SIP) and ports 16000-18500 (UDP) for real-time audio (RTP). Always check with your VoIP provider about which ports need to be open on your routers or firewalls as they may not be what is reflected here.
Double NAT and SIP ALG
So now that you know what regular NAT is, lets talk about Double NAT. Double NAT is when the IP conversion occurs twice (or more). It’s not always a bad thing, but it can cause connectivity issues when trying to communicate with devices outside of the network (or vice versa), especially for applications like VoIP. Resolving a double NAT condition, while possible, will definitely require configuring Port Forwarding and properly configuring the Application Layer Gateway on the routers. It is always best to avoid this condition if possible.
SIP ALG (Application Layer Gateway) can be a picky feature. Sometimes it works very well, and others not so much. Essentially this feature rewrites the SIP IP header’s information in the packet as it leaves the router. In cases of a single NAT this usually works ok and does not interfere with the VoIP devices ability to Register or receive SDP communication. However, in cases of double NAT it will almost assuredly cause an issue with One Way Audio or calls that drop after being connected only a short time. We find its best to completely disable this feature on the router, do the port forwarding, and configure the phone so that it knows what its public IP address is and let it handle the IP header information.
Equipment Malfunction or Failure
In some instances its a physical problem like a cable or our telephone hardware at fault. It’s not as common of a reason, but it does happen. Usually in the case of a complete failure, its noticeable because the device no power or appears “hung or bricked”. Sometimes and sometimes it’s a less transparent reason like a faulty communication cable. Try power cycling all VoIP equipment and maybe your network devices and see if that resolves the issue. If it does not, check your cabling to make sure it appears in good working order.
Incompatible Codecs, and Routing Problems
These are almost always configuration issues at the end-user level, but sometimes they can also be at the provider level – either the Internet Service Provider (ISP) or the VoIP Provider (TELCO). If you have already verified that your Internet connection is working, and are using a standard codec like G711.U or T.38 for communication on your VoIP devices, you are probably going to need to reach out to one or both of these providers.
If you have one of those services with CGI-Communication, give us a call or open a support ticket with us – we are happy to assist!
