One-way audio is the most common — and most frustrating — problem in Asterisk deployments. One party can hear the other but not vice versa. It is almost always a NAT traversal issue. After debugging hundreds of these, here is our systematic approach.
Understanding Why It Happens
SIP uses two separate protocol layers: the SIP signalling layer (handles call setup on port 5060) and the RTP media layer (carries actual audio on ephemeral high ports). NAT works fine for the SIP layer because responses follow the TCP/UDP connection. But RTP is bidirectional UDP — and most NAT routers do not know how to route RTP from the external IP back to the internal SIP phone. This is the root cause of 90% of one-way audio cases.
Step 1: Capture Traffic with sngrep
Before touching any config, capture the actual SIP traffic to see what IP addresses are being negotiated in the SDP body.
# Install sngrep
yum install sngrep -y # CentOS/Rocky
apt install sngrep -y # Debian/Ubuntu
# Capture SIP traffic (filter for your trunk IP)
sngrep -I /tmp/capture.pcap host 203.0.113.10
# During the capture, make a test call
# Press Enter to stop. Look at the SDP body in the INVITE.In the SDP body of the INVITE, look at the "c=" (connection) and "m=" (media) lines. If you see a private IP (192.168.x.x, 10.x.x.x, 172.16.x.x) in the "c=" line when Asterisk is behind NAT, that is your problem. The remote end is trying to send RTP to a private IP it cannot reach.
Step 2: Fix externip and localnet in sip.conf / pjsip.conf
; For chan_sip (sip.conf):
[general]
externip=203.0.113.50 ; your public IP (or use externhost= for dynamic IP)
localnet=192.168.1.0/24 ; your LAN subnet
localnet=10.0.0.0/8 ; add any additional private ranges
nat=force_rport,comedia ; force correct NAT handling
; For PJSIP (pjsip.conf):
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=203.0.113.50
external_signaling_address=203.0.113.50
local_net=192.168.1.0/24Step 3: Check RTP Port Range and Firewall
Asterisk uses a range of UDP ports for RTP (default 10000–20000). Every port in this range must be open in your firewall, bidirectionally. A common mistake is opening only port 5060 (SIP) but forgetting the RTP range.
# Check rtp.conf
cat /etc/asterisk/rtp.conf | grep -E "rtpstart|rtpend"
# Open RTP ports in firewalld
firewall-cmd --permanent --add-port=10000-20000/udp
firewall-cmd --reload
# Or iptables
iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPTStep 4: RTP Direct Media (canreinvite)
If "directmedia=yes" (or canreinvite=yes in old configs) is set, Asterisk tries to get the two endpoints to send RTP directly to each other, bypassing Asterisk. This is efficient on a LAN but breaks calls when one or both parties are behind NAT. Set directmedia=no for any endpoint that may be behind NAT.
Quick diagnostic: run "asterisk -rx 'rtp set debug on'" and make a test call. Check /var/log/asterisk/full for RTP packets. If you see packets arriving from one direction but not the other, NAT is blocking the return path.
Step 5: STUN/TURN for WebRTC Clients
For WebRTC SIP clients (browser-based softphones), you need a STUN server to help the browser discover its public IP, and a TURN server for cases where STUN fails (symmetric NAT). Set up Coturn on a public server and configure it in your WebRTC gateway (Asterisk's ARI or Janus).
One-way audio in Asterisk is almost always NAT-related. The fix is always in externip/localnet configuration, firewall rules, or directmedia settings. Use sngrep to confirm what IP is in the SDP before changing anything — it saves hours. If you are still stuck after these steps, our VoIP support team resolves most critical issues the same business day.