VoIP one-way audio means the SIP signaling worked but the RTP media flows one way. The call connects. One party hears the other, but not back. The cause is almost always NAT or a firewall on the customer side. Sometimes it is a router’s SIP ALG or a blocked RTP port range. It is almost never the carrier.
Before you reboot the PBX or open a carrier ticket, note which side is silent. The direction of the silence is itself a clue. This page turns that clue into a fix, in order of likelihood.
Why VoIP one-way audio happens
SIP and your voice travel apart. SIP signaling sets the call up — INVITE, ringing, answer — usually over UDP port 5060. The audio rides RTP. That is a different protocol on a different port range, chosen for each call. A firewall or NAT device can pass the signaling and still block or mangle the media. That split is exactly what one-way audio looks like: the call “works,” the sound doesn’t.
The classic cause is a private IP in the SDP. During setup, each side tells the other where to send audio. That address sits in the SDP body’s c= (connection) line. An endpoint behind NAT that has not been set up for it advertises its private LAN address — 192.168.1.50 — instead of its public IP. The far end sends RTP to an address the internet cannot route, 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. Routers’ SIP ALG implementations are widely documented to rewrite SDP incorrectly — 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 distinction matters. This page is about missing audio. If both directions work but sound choppy or robotic, that is a different class of audio issues. Start with our packet loss guide instead.
The diagnostic ladder: let the silence point at the fault
Work down this ladder before you change any config. Each step narrows the fault.
Step 1 — note the direction. The party who can’t be heard is the party whose RTP is not arriving. So 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. Read the SDP in both the offer and the answer. Check the c= and m= lines on each. Do they carry routable public IP addresses 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 are asking two blunt questions. Do RTP packets leave this box toward the far end? 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 RTP streams 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. Compare the SDP your PBX sent with the SDP the far end received. Capture on both sides of the router. If they differ, 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 clears the vast majority of one-way audio tickets.
1. Fix the NAT settings on the SIP server
Asterisk, or whichever SIP server you run, has to be told it lives behind NAT. Otherwise it keeps advertising private addresses and never latches media correctly. On legacy chan_sip trunks that is 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 fix is at the transport level. Set external_media_address and external_signaling_address to your public IP. Define local_net so Asterisk swaps in 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 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 appears in most guides. That same file notes the compiled-in defaults are actually 5000–31000. So check what your box is set to 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
Suppose the addresses are right and the ports are open, but audio still fails — or the SDP arrives modified. Then the edge router’s ALG is rewriting your packets. Turn it off. What SIP ALG is and why it misfires has 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. It can advertise its own private address and break audio for just that agent. Enable the endpoint’s NAT traversal option (STUN, or the vendor’s public-address setting). 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. That papers over most home-NAT weirdness. If one-way audio follows one agent across campaigns, it is their edge, not yours. The broader triage flow is in our VICIdial troubleshooting guide.
Asterisk one-way audio: the five-minute checklist
Asterisk one-way audio almost always traces back to one of five settings. Check them in this order before you blame the network.
- NAT mode. chan_sip:
nat=force_rport,comedia. PJSIP:force_rport=yes,rtp_symmetric=yes, andrewrite_contact=yeson the endpoint. Asterisk’s own samplepjsip.confpairs these for a device behind a far-end NAT or firewall. - Public address. When Asterisk itself sits behind NAT, its PJSIP transport needs
external_media_addressandexternal_signaling_address, pluslocal_netfor each LAN range. Without them the SDP carries a private IP. - Media path. Keep media through Asterisk. On chan_sip that is
canreinvite=no. On PJSIP it isdirect_media=no; the default isyes, and the sample config recommendsnofor remote endpoints on a NAT transport to prevent audio issues. - RTP range. The firewall rule must match
rtp.conf. Allow the range Asterisk actually uses, not the one a guide assumed. - Live proof.
pjsip set logger on(orsip set debug onon chan_sip) shows the SDP Asterisk sent.rtp set debug onlogs every RTP packet Asterisk sends and receives, with the far-end address. One direction missing from that log tells you where the media dies.
When it actually is the carrier
Rarely, the fault sits upstream. A media proxy on the carrier path may carry a wrong address. Or an asymmetric route sends signaling and media down different paths, and one leg fails. Prove it with evidence — the same capture from step 3. Three things must all be true. Your SDP carries correct public addresses. Your RTP visibly leaves toward the carrier’s media IP. No inbound RTP reaches your WAN interface outside your own firewall. Then the missing leg is upstream, and that capture is exactly what a carrier NOC needs to act fast. Carriers get blamed first and are guilty last. A two-minute capture saves a two-day ticket.
Preventing the repeat
One-way audio comes back because config decays. A router swap silently re-enables the ALG. A firewall migration drops the RTP rule. A public IP change breaks 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. 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 great majority of cases. The endpoint behind NAT advertises its private IP in the SDP. The far end then sends audio to an address it cannot reach, and that direction goes silent. The remaining cases are a router’s SIP ALG rewriting the SDP in transit, and a firewall that passes SIP on 5060 but blocks 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. The party who 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 IP addresses 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. That breaks audio for one agent while the office runs clean. Enable the endpoint’s NAT traversal setting. Disable the ALG on the home router. Use symmetric-RTP settings on the server so it latches to wherever the agent’s media really comes from.
How do I fix Asterisk one-way audio behind NAT?
Tell Asterisk it sits behind NAT, then open the RTP range it actually uses. On chan_sip that means nat=force_rport,comedia on the trunk. On PJSIP it means force_rport, rtp_symmetric, and rewrite_contact on the endpoint, plus external_media_address, external_signaling_address, and local_net on the transport. Mirror the rtp.conf port range in the firewall. If audio still fails, capture the SDP on both sides of the router and look for a SIP ALG rewrite.
When is one-way audio the carrier’s fault?
Rarely — and only after your own captures clear your edge. Three conditions must hold. The SDP you send carries correct public addresses. Your RTP visibly leaves toward the carrier’s media IP. Nothing returns at your WAN interface outside your firewall. Then the missing leg is upstream — typically a media proxy or an asymmetric-route issue. Send that capture with the ticket. It is 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.