One-way audio — where one party can hear the other but not vice versa — is among the most common and frustrating VoIP problems. This guide covers systematic troubleshooting.
Understanding Why One-Way Audio Happens
SIP signaling (call setup) and RTP media (actual audio) are separate streams, sometimes taking different paths — one-way audio typically means the RTP media stream isn't correctly flowing in one direction, most commonly due to NAT-related issues (see How to Configure NAT Traversal for SIP (STUN/TURN)).
Step 1 — Identify Which Direction Is Failing
Determine specifically: can the internal party hear the external party but not vice versa, or the reverse? This directionality is a key diagnostic clue pointing toward which specific NAT/firewall boundary is causing the problem.
Step 2 — Check Asterisk's NAT Configuration
[general]
nat=force_rport,comedia
externip=YOUR_PUBLIC_IPVerify these settings are correctly configured — missing or incorrect NAT configuration is the most common root cause of one-way audio when your Asterisk server itself is behind NAT (or has misconfigured public IP settings).
Step 3 — Check RTP Port Range Firewall Configuration
sudo ufw allow 10000:20000/udpSee VPS Requirements for VoIP and Communication Servers — verify your configured RTP port range is genuinely open in your firewall; a blocked RTP port range means media simply can't flow, manifesting as one-way (or entirely absent) audio.
Step 4 — Check for Firewall on the Client Side Too
One-way audio can originate from the client's network, not just the server — a client behind a restrictive firewall/NAT that blocks inbound RTP will experience exactly this symptom, even with a correctly configured server.
Step 5 — Capture and Analyze SIP/RTP Traffic
sudo tcpdump -i any -w capture.pcap port 5060 or portrange 10000-20000Capture actual traffic during a reproduced one-way audio call, then analyze in Wireshark — reveals exactly whether RTP packets are genuinely being sent/received in each direction, providing definitive diagnostic evidence beyond guessing.
Step 6 — Verify SDP (Session Description) Contains Correct Addresses
Within the captured SIP traffic, examine the SDP (Session Description Protocol) content for the media connection address — if it shows a private/internal IP address that the other party can't reach, this confirms the NAT traversal issue directly.
Step 7 — Check for SIP ALG Interference
Some routers/firewalls have a "SIP ALG" (Application Layer Gateway) feature intended to help with NAT traversal but frequently causes problems instead by incorrectly rewriting SIP/SDP content — a commonly recommended troubleshooting step is disabling SIP ALG on any router in the call path.
Step 8 — Test with a Direct, Non-NAT Connection
If possible, test a call where both parties have genuinely direct public IP connectivity (no NAT involved on either end) — if this works correctly, confirms the issue is specifically NAT-related rather than a more fundamental Asterisk configuration problem.
Common Errors
Issue only occurs for calls to/from specific external providers — some SIP trunk providers have specific NAT-handling requirements or quirks; check your specific provider's documentation for any provider-specific configuration recommendations for NAT traversal.
Continue Reading
- How to Configure NAT Traversal for SIP (STUN/TURN)
- VPS Requirements for VoIP and Communication Servers
- How to Troubleshoot Common VoIP Quality Issues (Jitter, Latency, Packet Loss)
Browse more articles in VoIP & Communication Servers.
