One Way Audio: I Can Hear Them But They Can't Hear Me

When Your Phones Sound Bad: Part 2 of 12

One way audio is one of the most distinctive VoIP problems. The call connects, one person can hear the other perfectly fine, but the audio only goes in one direction. Sometimes the caller can hear the callee but not vice versa. Sometimes it's the other way around. Sometimes neither side can hear anything at all, which is technically zero way audio but often gets reported as "the call connected but nobody could hear anything."

Unlike choppy audio, which can have a dozen different causes, one way audio has a much shorter list of likely culprits. And the most common one by far is a NAT or firewall issue. If you're experiencing one way audio, there's probably a 70 to 80 percent chance that what follows in the first section of this post describes your problem.

The NAT problem (the most common cause)

NAT stands for Network Address Translation, and it's how your office router allows multiple devices to share a single public internet address. It works transparently for web browsing, email, and most internet activity. It does not work transparently for VoIP, and the reason is technical but worth understanding because it explains exactly why one way audio happens.

When you place a VoIP call, your phone tells the other end where to send audio. It does this by embedding its own IP address and a port number inside the call setup messages (specifically in something called SDP, which is covered in detail in the SIP Signaling series). The problem is that your phone knows its own local IP address, which is a private address like 10.0.0.50 or 192.168.1.25. That private address only works inside your office network. When the other end receives the call setup and tries to send audio to that private address, the packets have nowhere to go because that address doesn't exist on the public internet.

The result is that audio flows in one direction but not the other. Your phone can send audio to the other party (because your outbound traffic passes through NAT and gets translated to your public address), but the other party can't send audio back to you (because they're trying to reach your private address, which is unreachable from outside your network).

This is such a common problem that there's an entire post in the SIP series dedicated to NAT traversal. But from a troubleshooting perspective, here's what to do about it.

Turn off SIP ALG

SIP ALG (Application Layer Gateway) is a feature in many routers that tries to fix the NAT problem by inspecting VoIP traffic and rewriting the embedded IP addresses. In theory, this should make things work. In practice, SIP ALG implementations are notoriously buggy and cause more problems than they solve. The universal recommendation from VoIP providers is to turn it off.

The challenge is finding it. Different router manufacturers call this feature different names: SIP ALG, SIP Helper, SIP Passthrough, or it might be buried under an Application Layer Gateway menu. Some routers have it enabled by default with no obvious way to disable it. If your router doesn't have a clear option to turn it off, check the manufacturer's documentation or support forums.

After disabling SIP ALG, restart the router and the phones. Test calls again. In a surprising number of cases, this single change resolves one way audio.

Check firewall rules

If SIP ALG isn't the issue (or is already disabled), the next thing to check is your firewall. VoIP uses two separate streams of traffic: SIP for the call signaling (usually on UDP port 5060) and RTP for the actual audio (usually on a range of UDP ports, commonly 10000 through 20000, though the exact range varies by phone and PBX configuration).

A firewall might allow the SIP signaling through (so the call connects) but block the RTP audio (so nobody can hear anything). Or it might allow RTP in one direction but not the other. Check that your firewall allows bidirectional UDP traffic on both the SIP port and the full RTP port range used by your phones.

If you're not sure what port range your phones or PBX use for RTP, check the PBX configuration. Asterisk, for example, defaults to ports 10000 through 20000. FreeSWITCH uses 16384 through 32768. 3CX has its own configurable range. Your firewall needs to permit traffic on whatever range your system uses.

Configure STUN on your phones

STUN (Session Traversal Utilities for NAT) helps phones discover their own public IP address so they can include it in the call setup messages instead of their private address. When STUN is configured, the phone queries a STUN server before placing a call, learns its public address, and uses that address in the SDP. The remote end then sends audio to the correct public address, which passes through NAT and reaches the phone.

Most VoIP phones have a STUN setting in their configuration. Your VoIP provider may operate a STUN server and provide the address in their setup documentation. Common public STUN servers also exist, though using your provider's server is preferred.

Note that STUN doesn't work in all NAT scenarios. Specifically, it fails with symmetric NAT, where the router assigns different public ports for different destinations. If STUN doesn't resolve the issue, your VoIP provider may need to use a different NAT traversal method on their end, or you may need to use a router that provides better NAT behavior for VoIP.

Firewall on the phone itself or the computer

If you're using a softphone (a VoIP application on a computer rather than a hardware desk phone), the computer's own firewall can block RTP traffic. Windows Firewall, macOS firewall, or third party security software might block the softphone's audio ports even though the signaling gets through.

Check whether the softphone application has been granted firewall exceptions. On Windows, check both the Windows Firewall settings and any third party antivirus or security suite that includes its own firewall. The symptom is the same as a network firewall issue: the call connects but audio doesn't flow in one or both directions.

VPN and one way audio

If the person experiencing one way audio is connected through a VPN, the VPN itself is a very likely culprit. VPNs create an encrypted tunnel for all network traffic, and the way they handle UDP traffic (which VoIP uses) can cause audio problems.

When a phone or softphone sends audio through a VPN, the packets have to be encrypted, encapsulated in the VPN tunnel, sent to the VPN endpoint, decrypted, and then forwarded to the destination. This process can change the apparent source address of the audio packets, interfere with NAT traversal, and add latency. Many VPN configurations are simply not designed to handle real time audio well.

If VoIP calls need to work over a VPN, the VPN needs to be configured to handle UDP traffic properly, and the VoIP traffic might need to be excluded from the VPN tunnel entirely (a configuration called split tunneling, where VoIP traffic goes directly to the internet while other traffic goes through the VPN). This is a common configuration in hybrid and remote work setups and is covered in more detail in the Working From Home series.

Codec mismatch

A less common but possible cause of one way or no audio is a codec mismatch. A codec is the algorithm that encodes and decodes voice audio into digital data. Both sides of a call need to agree on a codec. If they can't agree (or if they nominally agree but one side can't actually process the agreed codec), audio doesn't flow.

In most configurations, codec negotiation happens automatically and works fine. But misconfigurations can occur. If a PBX is configured to offer only G.729 and the remote end only supports G.711, no common codec exists and the call either fails entirely or connects with no audio.

If you suspect a codec issue, check the codec settings on your PBX and phones. Ensure that at least one common codec (G.711 is the safest universal option) is enabled on all devices and trunk connections.

Network asymmetry

In some network configurations, the path that outbound traffic takes is different from the path that inbound traffic takes. This is called asymmetric routing. If the inbound path is blocked or broken while the outbound path works, audio flows in one direction but not the other.

This is most common in complex network setups with multiple internet connections, multiple routers, or policy based routing rules. If your network has any of these, check whether the routing for UDP traffic (particularly on the RTP port range) is symmetric, meaning inbound and outbound traffic follow the same path through the same router and firewall.

The troubleshooting order

For one way audio, work through this checklist:

1. Disable SIP ALG on the router
2. Verify firewall rules allow bidirectional UDP on SIP and RTP ports
3. Configure STUN on the phones if not already set
4. Check for computer firewalls or security software blocking the softphone
5. If using a VPN, test without the VPN to isolate
6. Verify codec configuration matches between endpoints
7. Check for asymmetric routing in complex network setups

In the majority of cases, the first three steps resolve the problem. One way audio is almost always a NAT or firewall issue. The challenge is usually finding exactly where in the chain the blockage is, not figuring out the general category of problem.

Next up: Calls Dropping After a Set Amount of Time, why your calls disconnect at exactly 30 seconds, 15 minutes, or some other suspiciously consistent interval.