One-way audio on a VoIP call means the SIP signaling completed — the call connects, one party hears the other — but the RTP media stream flows in only one direction. The cause is overwhelmingly NAT or a firewall on the customer side, sometimes a router’s SIP ALG or a blocked RTP port range, and almost never the carrier.
Before you reboot the PBX or open a carrier ticket: the direction of the silence is itself a diagnostic clue. This page turns that clue into a fix, in order of likelihood.
Why the call connects but the audio doesn’t
SIP and your voice travel separately. SIP signaling sets the call up — INVITE, ringing, answer — usually over UDP port 5060. The audio itself rides RTP, a different protocol on a different, dynamically negotiated port range. A firewall or NAT device can pass the signaling perfectly while mangling or blocking the media, which is exactly the split personality one-way audio shows: the call “works,” the sound doesn’t.
The classic mechanism is a private IP in the SDP. During call setup, each side tells the other where to send audio, inside the SDP body’s c= (connection) line. An endpoint behind NAT that hasn’t been configured for it advertises its private LAN address — 192.168.1.50 — instead of its public IP. The far end obediently sends RTP to an address that’s unroutable from the internet, and that direction of audio dies. Your outbound stream still lands, because you sent it to their valid public address. Result: they hear you, you hear nothing — or the mirror image.
Two other culprits produce the same symptom. A router’s SIP ALG “helpfully” rewrites the SDP in transit and, in the OpenSIPS project’s words, in most cases ends up making changes that are not correct — our SIP ALG guide covers how and why. And a firewall that allows SIP but not the RTP port range blocks the media at the door even when every address in the SDP is right.
One disambiguation: this page is about missing audio. If both directions work but sound choppy or robotic, that’s a degradation problem — start with our packet loss guide instead.
The diagnostic ladder: let the silence point at the fault
Work down this ladder before changing any config. Each step narrows the fault domain.
Step 1 — note the direction. Whichever party can’t be heard is the party whose RTP isn’t arriving — which means the other side advertised a bad address, or a NAT or firewall on the path is dropping that stream. The silence points at the fault.
Step 2 — capture the signaling. Pull a SIP trace (sngrep on the PBX is the fast way; tcpdump plus Wireshark works everywhere) and read the SDP in both the offer and the answer. Check the c= and m= lines on each: do they contain routable public IPs and sensible ports? A 10.x, 172.16–31.x, or 192.168.x address in a call that crosses the internet is your smoking gun.
Step 3 — watch the media. In the same capture, filter for RTP. You’re asking two blunt questions: do RTP packets leave this box toward the far end, and do RTP packets arrive from it? Leaving but nothing arriving means the far side (or a middlebox) is sending to the wrong place, or your firewall is eating the inbound stream. Both arriving and leaving on the wire but silence in the handset means the problem is past the capture point — a local firewall rule or the endpoint itself.
Step 4 — check for in-flight rewrites. If the SDP your PBX sent doesn’t match the SDP the far end received (compare captures on both sides of the router), something between them is rewriting packets — almost always the SIP ALG.
The fix ladder
Apply these in order. On dialer floors and Asterisk-based PBXs this sequence resolves the overwhelming majority of one-way audio tickets.
1. Fix the NAT settings on the PBX
Asterisk has to be told it lives behind NAT so it stops advertising private addresses and starts latching media correctly. On legacy chan_sip trunks that’s the nat=force_rport,comedia pattern — the exact trunk block, and what each setting does, is in the key settings section of our VICIdial trunk setup guide, so we won’t restate it here.
On PJSIP, the equivalent is transport-level: set external_media_address and external_signaling_address to your public IP, and define local_net so Asterisk substitutes the public address only for destinations outside your LAN. Get these three right and the SDP your server sends carries an address the far end can actually reach.
2. Open the RTP port range on the firewall
Signaling on 5060 is not enough — the audio needs its own UDP range forwarded or allowed. For Asterisk, the range lives in rtp.conf: the sample config file ships with rtpstart=10000 / rtpend=20000, which is why UDP 10000–20000 is the range you’ll see in most guides (that same file notes the compiled-in defaults are actually 5000–31000, so check what your box is configured for rather than assuming). Allow the configured range, in both directions, restricted to your carrier’s media IPs where practical.
3. Disable SIP ALG on the router
If the addresses are right and the ports are open but audio still fails — or the SDP is arriving modified — the edge router’s ALG is rewriting your packets. Turn it off. What SIP ALG is and why it misfires is covered in its own guide, with device-specific steps for pfSense, FortiGate, UniFi, and Netgear.
4. Remote agents: fix the far endpoint too
A softphone at an agent’s house sits behind its own NAT and can advertise its own private address, breaking audio for just that agent. Enable the endpoint’s NAT traversal option (STUN, or the vendor’s public-address setting), and remember the home router has an ALG of its own. With comedia-style symmetric RTP on the server, the PBX latches onto wherever the agent’s media actually comes from, which papers over most home-NAT weirdness. If one-way audio follows one agent across campaigns, it’s their edge, not yours; the broader triage flow is in our VICIdial troubleshooting guide.
When it actually is the carrier
Rarely, the fault sits upstream: a media proxy on the carrier path with a misconfigured address, or an asymmetric route where signaling and media take different paths and one leg fails. Establish it with evidence — the same capture from step 3. If your SDP carries correct public addresses and your RTP demonstrably leaves toward the carrier’s media IP and no inbound RTP arrives at your WAN interface outside your own firewall, the missing leg is upstream — and that capture is exactly what a carrier NOC needs to act quickly. Carriers get blamed first and are guilty last; a two-minute capture saves a two-day ticket.
Preventing the repeat
One-way audio recurs because config decays: a router replacement silently re-enables the ALG, a firewall migration drops the RTP rule, a public IP change invalidates external_media_address. Three habits prevent the relapse — document the PBX’s NAT settings and RTP range beside the firewall rules that mirror them; put “SIP ALG off” on every router-change checklist; and after any network change, place one test call and confirm audio both ways before agents log in. Multi-site deployments can put a session border controller at the edge to own NAT traversal in one place.
Frequently asked questions
What causes one-way audio on VoIP calls?
NAT, in the overwhelming majority of cases. The endpoint behind NAT advertises its private IP in the SDP, so the far end sends audio to an unroutable address and that direction goes silent. The remaining cases are a router’s SIP ALG rewriting the SDP in transit, and a firewall passing SIP on 5060 while blocking the UDP range RTP uses. Carrier-side faults are real but rare — rule out your own edge first.
How do I tell which side is causing one-way audio?
The silent direction points at the fault. Whichever party can’t be heard is sending RTP that never arrives — so the other side advertised a bad address, or a NAT or firewall on the path is dropping that stream. Confirm with a packet capture: check the SDP’s c= lines for private IPs in both offer and answer, then watch whether RTP packets actually leave and arrive at your edge.
Why do I get one-way audio only for remote agents?
Because each home network adds its own NAT and its own SIP ALG. A remote softphone can advertise its private address exactly the way an unconfigured PBX does, breaking audio for that one agent while the office runs clean. Enable the endpoint’s NAT traversal setting, disable the ALG on the home router, and use symmetric-RTP settings on the server so it latches to wherever the agent’s media really originates.
When is one-way audio the carrier’s fault?
Rarely — and only after your own captures clear your edge. If the SDP you send carries correct public addresses, your RTP demonstrably leaves toward the carrier’s media IP, and nothing returns at your WAN interface outside your firewall, the missing leg is upstream: typically a media proxy or asymmetric-route issue. Send that capture with the ticket; it’s the difference between a fast fix and days of finger-pointing.
Dialer-grade SIP trunks from an FCC-licensed carrier, with a NOC that reads packet captures — SIPNEX, (833) 665-2220.
Keep reading.
The carrier built by operators, for operators.
FCC-licensed carrier with its own STIR/SHAKEN SP certificate. Operator-owned. SIP trunks built for operators who dial at volume.