VoIP one-way audio, where one party hears the other but not the reverse, is almost never a codec or phone fault. It means RTP media is flowing in one direction only, and nine times out of ten the cause is NAT: the PBX or phone advertises a private address in the call setup, so the far end sends its audio somewhere unreachable. The six checks below find the cause in order of likelihood.
Short answer: Capture a call with sngrep and read the c= line of the SDP. If it shows a private 10.x, 172.16-31.x or 192.168.x address going to the internet, set the public address and local networks on the PBX (in PJSIP: external_media_address, external_signaling_address and local_net, plus rtp_symmetric, force_rport and rewrite_contact on the endpoint). Then make sure the RTP range is open and forwarded, SIP ALG is off, and outbound NAT keeps a static source port.
Table of Contents
1. Read the SDP
Record a failing call and open it in sngrep’s call flow. The INVITE and the 200 OK each carry an SDP body with a c=IN IP4 address and an m=audio port: that is where the sender wants to receive audio.
sngrep -d any port 5060 or portrange 10000-20000
# inside the call flow press F2 to show the SDP, look for:
# c=IN IP4 192.168.1.20 <-- private address sent to the internet = NAT problem
# m=audio 14562 RTP/AVP 0 8 1012. Fix NAT settings on the PBX
On Asterisk with PJSIP, tell the transport which networks are local and what the public address is, and make endpoints reply to wherever packets actually come from:
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
external_media_address=203.0.113.25
external_signaling_address=203.0.113.25
local_net=192.168.1.0/24
[office-phones](!)
type=endpoint
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yesIn FreePBX the same values are under Settings » Asterisk SIP Settings: set the external address and add every internal subnet under local networks, then reload. On 3CX run the firewall checker in the admin console; it confirms the detected public IP and whether the media ports reach the server.
3. Confirm RTP arrives
Watch the RTP range on the PBX during a call. Packets in only one direction pinpoint which side is blocked:
tcpdump -ni any udp portrange 10000-20000 -c 40
asterisk -rx "rtp set debug on"If nothing arrives from the provider, the RTP range is not open or not forwarded; the SIP ports firewall guide shows the rules for CSF, firewalld and pfSense.
4. Turn off SIP ALG
A router that rewrites SIP on top of the PBX’s own NAT handling produces mismatched addresses and ports. Disable it on every device in the path; the disable SIP ALG guide has commands for the common brands.
5. Keep NAT mappings stable
Firewalls that randomise source ports or expire UDP mappings quickly break audio mid-call or after a hold. On pfSense use static-port outbound NAT for the PBX, and raise UDP timeouts above the registration and RTP keepalive intervals. Phones behind NAT should send keepalives every 20 to 30 seconds.
6. Rule out routing and VPN issues
Where phones reach the PBX over a VPN, make sure direct_media is off so audio does not try to flow phone-to-provider directly, and check that the tunnel carries the return route for the phone subnet. Asymmetric routing, where replies leave by a different interface, also produces one-way audio and shows up as RTP leaving but never returning on the same path.
VoIP one-way audio at a glance
Official documentation: Asterisk PJSIP configuration, 3CX documentation, RFC 3550: RTP.
Related guides: Disable SIP ALG · SIP ports firewall rules · VoIP call quality.
Frequently asked questions
Why does one-way audio start after about 30 seconds?
That pattern points to a NAT or firewall UDP timeout, or to a re-INVITE that moves media to an address the far end cannot reach. Increase UDP timeouts and check the SDP of any re-INVITE sent during the call.
Can a codec mismatch cause one-way audio?
Rarely. A codec mismatch usually makes the call fail to connect or produces no audio both ways. When audio works in exactly one direction, look at NAT, RTP ports and SIP ALG first.
Does one-way audio happen with cloud phone systems?
Less often, because the provider handles NAT traversal, but a restrictive office firewall blocking inbound UDP media or an active SIP ALG can still cause it. The same packet capture approach applies on the office router.