One-Way Audio on VoIP Calls: Causes and Fixes

One-way audio on a VoIP call means the call connects—you hear the other party, but they cannot hear you, or vice versa. The signalling (SIP) succeeded, so the call setup went through, but the media stream (RTP) is not reaching the other end. This is a connection symptom, not a codec or handset fault. The mechanism is almost always a routing or NAT problem: the RTP packets are sent to an address that is unreachable or blocked.

This guide walks through the causes in order of likelihood, from the most common (NAT) to the less common (firewall, carrier). For each cause, it explains what to check and how to fix it. If the problem is on the carrier side, no local change will help—the guide says so explicitly.

The Mechanism: Why Signalling Works but Audio Doesn’t

SIP signalling and RTP media use different ports and often different paths. SIP typically uses port 5060 (UDP or TCP), while RTP uses a range of UDP ports (commonly 10000–20000, but configurable). A NAT device (router) translates private IP addresses to a public one. For signalling, the SIP protocol includes the IP address and port in the message body (the SDP payload), not just in the packet headers. If the device does not handle this correctly, the remote end tries to send RTP to a private address (like 192.168.1.10) that is not routable on the public internet. That is the classic one-way audio scenario: the call connects because the SIP INVITE got through, but the RTP stream to the private address is dropped.

There are two main NAT-related failures:

1. No SIP ALG or misconfigured SIP ALG: Some routers have a SIP Application Layer Gateway that is supposed to rewrite SDP addresses. If it is broken or misconfigured, it may rewrite addresses incorrectly, causing one-way audio.
2. No port forwarding or STUN: If the device behind NAT does not know its public IP and port, it sends RTP to the wrong destination. STUN (Session Traversal Utilities for NAT) helps devices discover their public mapping, but if not configured, the device uses its private IP.

Check Order: From Local to Remote

Work through these steps in order. Each step is less destructive than the next. Stop when the problem is resolved.

1. Confirm the Symptom Is One-Way Audio, Not No Audio

Before changing anything, verify that the call connects and one direction of audio works. If neither party hears anything, the problem is likely a codec mismatch or a complete media failure, not one-way audio. One-way audio specifically means one direction works.

2. Check the Local Network for NAT Issues

Diagnosis: The device’s SDP is advertising a private IP address. To confirm, capture the SIP traffic on the LAN (e.g., with Wireshark) and look at the SDP body of the INVITE. If the c= line shows a private IP (like 192.168.x.x) and the remote end is on the public internet, that is the cause.

Fix: Configure the device or softphone to use STUN or set the public IP manually. Most VoIP phones have a NAT settings section. Enable STUN and enter the STUN server address provided by your VoIP provider. If the phone supports it, set the public IP and port explicitly. Alternatively, configure port forwarding on the router for the RTP port range to the phone’s IP, but this only works for a single device and does not scale.

When this does NOT apply: If the call is between two devices on the same LAN and one-way audio occurs, NAT is not the cause because no NAT is involved. In that case, check the firewall on the receiving device.

3. Disable or Fix SIP ALG on the Router

Diagnosis: SIP ALG is a common culprit. To check if it is enabled, log into the router’s admin interface and look for SIP ALG or VoIP settings. If enabled, it may be rewriting SDP incorrectly.

Fix: Disable SIP ALG. On many routers, this is a checkbox. After disabling, reboot the router and test. If the problem goes away, leave it off. If the router does not allow disabling, consider replacing it or using a different router.

When this does NOT apply: If the router does not have SIP ALG (some business routers do not), or if the problem occurs on a network without a router (e.g., a direct modem connection), skip this.

4. Check Firewall and Port Forwarding

Diagnosis: If NAT is not the issue, a firewall may be blocking RTP in one direction. Check the firewall logs on the local machine or router for dropped packets on the RTP port range.

Fix: Open the RTP port range (e.g., UDP 10000–20000) in the firewall for the VoIP device’s IP. If using a software firewall (Windows Defender Firewall), add an inbound rule for that port range. On the router, ensure port forwarding is set up correctly if the device is behind NAT and STUN is not used.

When this does NOT apply: If the firewall is not blocking anything (logs show no drops), or if the problem is symmetric (both directions fail), this is not the cause.

5. Check the Carrier or ISP Side

Diagnosis: If all local checks pass and the problem persists, the issue may be on the carrier’s or ISP’s network. For example, the carrier may be using symmetric NAT or a media relay that does not work correctly. You cannot fix this from your side.

Fix: Contact the VoIP provider or carrier and describe the symptom. Ask if they support STUN/TURN or if they have a media relay. If they do not, the problem may be inherent to their network. In that case, no local change will help.

When this does NOT apply: If the problem occurs only on calls to certain numbers (e.g., PSTN) but not others, the issue is likely with the carrier’s media handling, not your network.

Comparison Table: Causes and When They Apply

What People Get Wrong About One-Way Audio

The most common misdiagnosis is blaming the phone or softphone. Users often try reinstalling the app or changing codecs, which does nothing because the problem is in the network path. It is a natural mistake because the symptom appears to be a device issue—audio fails, so the device seems faulty. But the call connects, which proves signalling works, and the device is sending audio (you can hear the other side), so the device is not completely broken. The real issue is that the return path is broken, which is a network problem.

Another common mistake is assuming that if the call works on the same LAN, the network is fine. That is false because NAT and firewalls do not apply to local traffic. The problem only manifests when traffic crosses a NAT boundary.

Commands and Tools for Diagnosis

While on a Windows machine, you can use built-in tools to check network connectivity and firewall state. These commands help confirm the diagnosis but do not fix the problem directly.

ipconfig /all

Shows the local IP configuration. If the IP is private (192.168.x.x, 10.x.x.x, 172.16-31.x.x), the device is behind NAT.

netsh advfirewall firewall show rule name=all

Lists all firewall rules. Look for rules that might block UDP ports used for RTP.

netstat -an | findstr 5060

Shows UDP/TCP connections on port 5060 (SIP). If the call is active, you should see a connection. If not, signalling is not reaching the device.

ping <public IP of remote>

Tests basic connectivity. If ping fails, there may be a routing issue, but note that many firewalls block ICMP, so a failed ping does not prove a problem.

These commands give you information, but the actual fix is in the router or device configuration.

When You Cannot Fix It

If the problem is on the carrier’s side, no local change will help. For example, if the carrier uses symmetric NAT without a media relay, the RTP stream cannot traverse it. In such cases, the only option is to ask the carrier to fix their network or to use a different provider. Do not waste time on local changes if the carrier confirms the issue is on their end.

Summary

One-way audio is a network problem, not a device problem. Work through the checks in order: NAT, SIP ALG, firewall, then carrier. Use the comparison table to match your situation. If you cannot fix it locally, contact the carrier.