When a VoIP call connects but audio only flows one way, the problem is rarely the call itself — it's the network infrastructure the audio travels through. VoIP separates call signaling from voice data, routing each over different protocols and ports. 

That separation is why a call can ring, connect, and stay active while leaving one party unable to hear anything. Unlike a dropped call, one-way audio is harder to diagnose because the session appears intact. 

The causes are consistently identifiable: SIP ALG interference, NAT misconfiguration, blocked RTP ports, or a codec mismatch. 

This guide covers the hardware checks to rule out first, the mechanism behind each cause, and the specific fix for each.

What is one-way audio on a VoIP call?

One-way audio on a VoIP call occurs when the call session is active, but voice packets fail to reach one party, typically due to SIP ALG interference, NAT misconfiguration, blocked RTP ports, or a codec mismatch between endpoints.

Hardware and device checks to rule out first

Before diagnosing network-layer causes, eliminate the hardware variables. 

One-way audio caused by a muted device, a misconfigured audio source, or a faulty headset produces the same symptom as a complex firewall misconfiguration — but takes less than two minutes to rule out. 

Running these checks first prevents wasted time on network troubleshooting when a simpler explanation exists.

Check each of the following before moving to network diagnostics:

• Mute and volume settings: Confirm that the microphone is not muted on the device, in the softphone application, or on the physical phone. Volume controls on headsets and desk phones are independent of system audio settings — check both.
• Audio source selection: On softphones and computer-based systems, verify the correct microphone is selected as the input device. A system update or new peripheral connection can silently change the default input without any visible notification.
• Cable and hardware condition: For wired headsets, inspect connections at both ends and test with a known-working device. Wireless headsets introduce an additional failure point — battery level and Bluetooth interference from nearby devices can both produce one-way symptoms.

Why VoIP audio can fail even when the call connects

One-way audio is counterintuitive: the call rings, connects, and stays active while audio fails in one direction. For businesses that rely on inbound calls to qualify new leads, intermittent audio failures translate directly to lost revenue. Understanding why requires knowing how VoIP handles two distinct types of traffic.

How VoIP separates signaling from audio

VoIP uses two distinct protocols:

1. The Session Initiation Protocol (SIP) handles call control on ports 5060 and 5061. 
2. The Real-time Transport Protocol (RTP) carries voice packets on a separate port range, typically 10,000 to 20,000. 

Both must work for audio to flow. SIP can set up a call while RTP packets are blocked entirely — which is why the phone rings, connects, and shows an active session while both parties hear silence.

SIP ALG interference on your router

SIP Application Layer Gateway (ALG) is built into most routers and enabled by default. 

Its purpose is to help SIP traffic traverse a NAT, but it frequently incorrectly modifies IP addresses within SIP packets, sending RTP audio to the wrong destination. 

The result is a call that connects while audio routes into a void — and it is the most common cause of one-way audio in small and mid-size business environments.

NAT blocking RTP traffic

Network Address Translation (NAT) allows multiple devices to share a single public IP address — and for most traffic, it works transparently. 

For VoIP, it creates a problem: RTP packets use dynamically assigned ports, and NAT has no built-in way to route incoming voice packets to the correct internal device. 

One party hears audio while the other hears silence. The asymmetry depends on which direction NAT is blocking.

Firewall rules that block audio ports

A firewall that passes SIP traffic on ports 5060 and 5061 but blocks the RTP port range will produce one-way or no audio. 

This happens when firewall rules are written with the SIP control ports in mind, while the voice data ports are overlooked. The RTP port range varies by provider — some use 10,000 to 20,000, others 16,384 to 32,767 — making it easy to miss.

Codec mismatch between devices

When a VoIP call is initiated, both endpoints negotiate a common audio codec — the format used to compress and transmit voice data. If they cannot agree on a shared codec, the call completes over SIP without audio. 

Mismatches are more common after firmware updates or provider changes. G.711 (ulaw for North America, alaw for international) is the most widely supported baseline.

How to fix one-way audio on your VoIP system

Each of the four causes above has a specific fix. Working through them in order — starting with SIP ALG, then NAT, then firewall ports, then codecs — is the most efficient path to resolution, since SIP ALG accounts for the majority of one-way audio cases in small and mid-size business environments.

Disable SIP ALG on your router

Access your router's administration panel and locate the SIP ALG setting — it typically appears under advanced networking, SIP, or firewall settings depending on the manufacturer. 

Disable it, save the configuration, and restart the router. On most consumer routers, the setting is labeled "SIP ALG" or "SIP Passthrough."

After disabling SIP ALG, restart both the router and the VoIP phones or softphone applications to ensure they re-register with the provider using the corrected network path. 

If calls that previously showed one-way audio now work normally, SIP ALG was the cause. If the issue persists, move to the NAT configuration.

Configure NAT settings for VoIP traffic

The most reliable way to resolve NAT-related one-way audio is to enable STUN (Session Traversal Utilities for NAT) on your PBX or IP phones. 

STUN allows the VoIP device to discover its public IP address and include it in outgoing SIP messages, which ensures RTP packets return to the correct address. Most hosted PBX platforms and IP phone manufacturers natively support STUN configuration.

For environments where STUN is unavailable, narrowing the RTP port range on your PBX and creating a specific port-forwarding rule for that range on your router is a practical alternative. 

This is more secure than opening the full default range and gives NAT a predictable destination for incoming voice packets.

Open RTP ports in your firewall

Identify the RTP port range used by your VoIP provider or PBX — this is documented in most providers' technical setup guides or can be obtained from their support team. 

Create inbound and outbound rules in your firewall to allow UDP traffic on that specific port range. Use the tightest range your provider supports rather than opening the full 16,000-plus port range common in some default configurations.

If your firewall supports VoIP-aware or SIP-aware inspection, enable it. Next-generation firewalls can examine SIP and RTP traffic at the application layer and make dynamic decisions about which ports to open for each call. 

This improves call reliability and customer service quality without unnecessarily widening the network attack surface.

Align codec settings between devices

Access the codec configuration on each VoIP endpoint — IP phones, softphones, and any gateways in the call path — and confirm at least one common codec appears in the priority list of every device. G.711 (ulaw for North America, alaw for international) is the safest universal baseline. 

If G.711 is already listed but calls still produce no audio, check whether a codec override exists in the PBX dial plan.

After aligning codecs, test with a call between two internal extensions before testing external calls. 

If internal calls now carry audio but external calls still don't, the mismatch is between your PBX and the provider rather than between your own devices — which narrows the diagnostic to the provider's SIP trunk configuration.

When to escalate to your VoIP provider

Not every one-way audio issue originates on your network. Once SIP ALG, NAT, firewall, and codec fixes have been applied without resolving the issue, the problem is likely upstream.

Customer experience data shows that persistent call quality issues erode client confidence faster than almost any other service failure.

The issue only occurs on calls outside your local network

If two phones on the same internal network carry audio clearly on internal calls, but one-way audio appears on external calls, the failure point is in the path between your premises and the provider. 

The problem is not your hardware or local configuration — it is somewhere in the SIP trunk, the provider's media servers, or the routing between them.

Internal calls work, but external calls to specific destinations don't

One-way audio affecting calls to certain carriers or area codes, but not others, points to a routing or codec negotiation issue at a carrier interconnect. 

Providers route calls through multiple carrier networks, and mismatches in how RTP is handled at those interconnect points can produce one-way audio that appears random to the customer. This is a provider-to-carrier issue, not a customer-to-provider one.

The problem started after a provider-side change

If one-way audio appeared suddenly without any changes on your network, the cause is almost certainly a provider-side update. 

Providers push firmware updates to hosted PBX systems, change media server IP addresses, and adjust SIP trunk configurations on their own maintenance schedules. 

When escalating, ask your provider to check for recent configuration changes and to pull a SIP trace from the affected call period.

Your network checks out clean but one-way audio persists

If SIP ALG is disabled, NAT is configured correctly, RTP ports are open, codecs are aligned, and the issue persists, request a SIP trace and RTP stream capture from your provider. 

These diagnostic tools show exactly where in the call path voice packets are being lost or misrouted. Without them, further troubleshooting is guesswork — and any provider supporting a 24/7 answering service or business communications environment should offer this as a standard diagnostic step.

When VoIP issues cost you calls

One-way audio on VoIP calls is a diagnostic problem with identifiable causes. Working through hardware checks, SIP ALG, NAT, firewall rules, and codec alignment resolves most cases without escalation.

When call quality issues hit your front office, the calls you can't hear are the leads you lose. 

Smith.ai AI Receptionist and Virtual Receptionist handle inbound calls independently of your VoIP setup — screening new inquiries, scheduling consultations, and capturing caller details 24/7. 

Book a free consultation to see how both serve your business.

Related reading:

• Business voicemail greetings
• Call routing guide
• How to leave voicemail
• Customer experience statistics
• Receptionist greeting scripts