Few VoIP problems are more confusing than a call that connects normally but has VoIP one-way audio. One person can hear the other, while the second person hears silence. The call may ring, show a connected status, and remain active, making the issue look like a handset or microphone failure.
In many cases, SIP signaling works but the actual voice media does not. Understanding that distinction makes troubleshooting more systematic. This guide explains SIP, RTP, NAT, firewalls, VPN routing, and codecs, then provides a safe diagnostic order for business phone systems, hosted PBX platforms, and self-managed systems such as FreePBX or Asterisk.
What one-way audio actually means
VoIP calls usually involve two related but separate traffic flows:
- SIP signaling: Messages used to register a phone, start a call, negotiate call details, and end the call.
- RTP media: Real-time Transport Protocol packets that carry the audio during the call.
A call can complete because SIP signaling reaches the expected server or PBX while RTP packets are sent to the wrong address, blocked, or routed in only one direction. This is why rebooting a phone may not help: the phone may be working correctly while the audio path is broken.
One-way audio can occur in either direction. An outside caller may hear an employee while the employee cannot hear the caller, or the employee may hear the caller while their own voice never arrives. The direction often provides a clue about which network or media path is failing.
Start by defining the exact call pattern
Before changing firewall rules or PBX settings, document the circumstances. “VoIP is broken” is much less useful than a repeatable pattern.
- Does the problem affect every extension or only one phone?
- Does it occur on inbound calls, outbound calls, or both?
- Do internal extension-to-extension calls have two-way audio?
- Does the issue affect remote phones, Wi-Fi devices, or wired phones differently?
- Is it limited to one provider, trunk, destination, or area code?
- Does it begin after a transfer, hold, conference, or call pickup?
Test one call at a time and record the approximate time, call direction, endpoints, network location, and which side could hear whom. Avoid changing several settings between tests; otherwise, you may not know which change affected the result.
Confirm whether the failure is RTP media
First separate an audio problem from a broader endpoint problem. Confirm that the call connects and that both devices can complete other basic functions. If internal calls have two-way audio but external calls do not, the issue is more likely related to the SIP trunk, public NAT, or an edge firewall than to the handset microphone or speaker.
If one phone has no audio on every call, inspect that phone, its local network connection, and its registration details. A muted handset, incorrect headset selection, faulty cable, damaged port, incorrect VLAN, or local security policy can imitate a network problem.
For a PBX administrator, supported diagnostics, logs, a packet capture, or a provider-side trace may show whether RTP packets are transmitted and received. RTP commonly uses a range of UDP ports rather than the same port used for SIP signaling. The exact range depends on the PBX, provider, phone system, and configuration, so do not assume a familiar port list applies everywhere.
Packet captures require care. Capture only relevant test traffic, protect the files because call audio may be present, and delete or securely retain captures according to your organization’s privacy requirements.
Check NAT and the addresses advertised for audio
Network Address Translation (NAT) allows private devices to share a public IP address. It works well for many ordinary applications, but VoIP has an additional complication: SIP messages can contain IP addresses and ports that tell the other endpoint where to send RTP.
If a phone or PBX advertises a private address such as 192.168.x.x to a device on the public internet, the remote endpoint may send audio to an unreachable destination. The call can still connect because the signaling and media paths are not identical.
Review every NAT boundary:
- Is the phone behind a router while the PBX is hosted elsewhere?
- Is the PBX behind a firewall with a public address or port forwarding?
- Are multiple routers creating double NAT?
- Has the public IP address changed recently?
- Does the PBX know which addresses are local and which are external?
- Is a SIP-aware feature, often called SIP ALG, rewriting traffic unexpectedly?
SIP ALG is a router feature intended to help SIP pass through NAT. Its behavior varies by device and firmware, and it can modify signaling or address information in ways that interfere with a correctly configured PBX. Disabling it is sometimes appropriate, but do so only after checking the router documentation, current configuration, and provider requirements. Record the original setting so it can be restored if necessary.
Do not expose a PBX management interface or broad UDP ranges to the internet simply to test audio. Prefer documented provider requirements, restricted source addresses where practical, strong authentication, and a firewall policy that allows only necessary traffic.
Review firewall rules and RTP port ranges
Firewalls can allow SIP signaling while blocking RTP. This creates a deceptive failure: phones register, calls ring, and calls connect, but audio never arrives or works in only one direction.
Check the firewall on both sides of the media path. Possible control points include the office gateway, PBX host firewall, cloud security group, VPN appliance, and remote worker’s local router. Confirm that the configured RTP range matches the range allowed by the relevant firewalls and NAT rules.
Also check whether the firewall tracks UDP sessions correctly. Some devices expire UDP state quickly, particularly when calls are placed on hold or remain connected for a long time. Timeouts, intrusion-prevention rules, geo-blocking, and rate limits can affect media even when no obvious deny message appears.
Make narrow, reversible changes. If a temporary test rule is necessary, restrict it by source, destination, interface, and time where possible. Do not replace a specific rule with a permanent broad “allow all” policy. After testing, verify two-way audio and return the configuration to the intended secure state when appropriate.
Investigate VPN routing and split media paths
VPNs can create one-way audio when signaling and media take different routes. A phone may reach the PBX through the VPN while RTP uses the local internet connection. Alternatively, the PBX may send audio toward a VPN address that the remote phone cannot route correctly.
Determine whether the affected device is expected to send both SIP and RTP through the VPN. Then inspect routing tables and VPN policies on the phone network, firewall, and PBX side. Ask:
- Which subnet contains the phone?
- Which subnet contains the PBX?
- Are the RTP destination addresses included in VPN routes?
- Does the VPN use full tunneling or split tunneling?
- Are overlapping private subnets sending traffic along the wrong route?
- Does the firewall permit UDP media across the tunnel in both directions?
Test internal and external calls separately. If internal calls work over the VPN but external calls fail, the route between the PBX and SIP provider may be the problem. If remote-to-remote calls fail while each remote phone can call the office, inspect whether the PBX is attempting direct media between endpoints.
Some systems support direct media, also called media bypass, where endpoints exchange RTP without keeping the PBX in the audio path. This can reduce server traffic but makes routing and firewall requirements more complicated. An administrator may test with media anchored through the PBX if the platform supports that change and capacity has been considered. Document the prior setting before changing production media behavior.
Check codec negotiation after network causes
A codec is the method used to encode and decode voice audio. Common deployments may use codecs such as G.711 or compressed alternatives, but the correct choice depends on the phones, PBX, trunk provider, bandwidth, and platform support.
Codec mismatch more often causes failed calls, no audio, or poor quality than classic one-way audio. Still, codec review belongs after RTP routing and firewall checks. Review the codec lists and order on the phone, extension, PBX, and trunk. Confirm that at least one common codec is permitted for the affected call path.
Do not use codec changes as a substitute for fixing NAT or firewall problems. Adding every available codec can make diagnosis harder and may introduce transcoding—the conversion between codecs—which can increase resource use or reduce consistency. Use a small, documented codec policy suited to the environment.
A safe troubleshooting sequence
- Reproduce the issue: Record call direction, endpoints, network location, and the failed audio direction.
- Compare call types: Test internal, inbound, outbound, and remote calls where applicable.
- Check endpoint basics: Verify mute status, headset selection, registration, cables, Wi-Fi, and VLAN placement.
- Verify RTP evidence: Use supported PBX diagnostics, logs, or a controlled capture to determine whether media is sent and received.
- Review NAT: Confirm public and private address handling, port mappings, and SIP ALG behavior.
- Review firewalls: Match allowed UDP media ranges to the actual PBX and provider configuration.
- Trace VPN routes: Confirm that both RTP directions follow an intended, reachable path.
- Check direct-media behavior: Determine whether endpoints bypass the PBX and test anchored media only when appropriate.
- Review codecs: Confirm a common codec and avoid unnecessary transcoding.
- Retest and document: Use the same call pattern, record the result, and preserve the working configuration.
When to involve the provider or a VoIP specialist
Contact the SIP provider when the problem affects only one trunk or destination pattern, provider-side traces show missing RTP, or the provider recently changed routing or account settings. Provide timestamps, call direction, anonymized identifiers where possible, and a precise description of which side could hear audio.
Professional remote assistance may be appropriate when firewall, NAT, VPN, and PBX settings interact across multiple locations. Tech Rescue Ops LLC can help organize a controlled test, review the media path, and make documented changes without treating broad internet exposure as a shortcut.