How to Fix One-Way Audio on VoIP Calls (NAT, Firewalls and SIP ALG)
One-way audio is one of the most common VoIP problems. The call connects, signalling works, but one person can't hear the other. Almost every case comes down to the same thing: RTP audio packets are being sent to an address that can't receive them. Usually that's a private IP address behind NAT.
Why signalling works but audio doesn't
SIP sets up the call, but the audio travels separately over RTP, on different (usually random high) UDP ports. Each side advertises where it wants to receive audio in the SDP body of the SIP message, in the c= (connection address) and m=audio (port) lines.
If a phone behind a router puts its private address, such as c=IN IP4 192.168.1.20, into the SDP, the far end dutifully sends audio to 192.168.1.20. That packet never arrives, so the person behind NAT hears nothing. Meanwhile their own audio flows out fine, so the far end hears them. That's one-way audio.
Diagnose it in five minutes
- Note who can't hear whom. The side that hears nothing is usually the side whose incoming RTP is being lost or misdirected.
- Capture the call with
sngrepon the PBX or SBC, or with Wireshark (Telephony → VoIP Calls). - Look at the SDP in the INVITE and the 200 OK. Is the
c=address a private range (10.x, 172.16–31.x, 192.168.x, 100.64.x)? That's your culprit. - Check RTP flow. In Wireshark's RTP Streams view, you should see two streams, one in each direction. If only one exists, packets in the other direction are being blocked or sent to the wrong place.
The fixes, in order of likelihood
1. Disable SIP ALG on the router
Many consumer and SMB routers include a "SIP ALG" or "SIP helper" that tries to rewrite SIP messages for NAT. In practice it often corrupts them by half-rewriting addresses, breaking SDP, or changing ports. Turn it off and let your PBX or phones handle NAT. Read our guide to SIP ALG for where to find the setting.
2. Tell the PBX its public address
If your PBX sits behind NAT, configure its external address and local networks so it writes the public IP into SDP for outside calls:
- Asterisk (PJSIP): set
external_media_address,external_signaling_addressandlocal_neton the transport. - FreePBX: Settings → Asterisk SIP Settings → set External Address and Local Networks.
- Endpoints behind NAT: enable
rtp_symmetric,force_rportandrewrite_contactso the PBX sends audio back to where it actually came from.
3. Open and forward the RTP port range
Your firewall must allow inbound UDP on the RTP range your PBX uses. For Asterisk this defaults to 10000–20000 (see rtp.conf). Narrow the range if you like, but make sure the firewall and PBX agree. Forward the range to the PBX if it's behind NAT.
4. Use an SBC or media relay
For remote workers on unpredictable home networks, the robust answer is a Session Border Controller or RTP relay (for example, RTPengine with OpenSIPS or Kamailio). It anchors media on a public address and fixes SDP for both sides.
5. Check codec and encryption mismatches
If RTP is flowing in both directions but one side still hears silence, check that both sides agree on SRTP and on the codec. A phone expecting encrypted audio will play silence if it gets plain RTP.
Bonus: calls dropping after 30 seconds
A close cousin of one-way audio: the call connects, then drops after about 32 seconds. The 200 OK reaches the caller, but the caller's ACK never reaches the callee because of a wrong Contact or Record-Route behind NAT. So the callee keeps retransmitting the 200 OK and finally gives up, often with a BYE. The cures are the same: disable SIP ALG and fix NAT settings. You may see 481 Call/Transaction Does Not Exist in the trace when this happens.
Try the SIP Response Codes
Every SIP status code from 100 to 608, with plain-English meanings, common causes and fixes.