How to Fix One-Way Audio in VoIP Calls

One-way audio is the classic symptom of NAT. The call connects, the timer runs, one person hears the other, and the reply is silence. SIP signalling made it through because it travels between the phone and the server. The voice itself travels in RTP, a separate stream (RFC 3550) that flows to whatever address and port each side announced in its SDP. When one of those addresses is a private one such as 192.168.1.20, the far end sends into the void. The fix is to make the announced address reachable, or to make the server ignore the announced address and reply to where the packets actually come from.

Quick checklist

1. In the softphone, set a STUN server and turn on ICE (in SIPdia both are under Account > Advanced, per the app's documentation).
2. On the PBX, enable NAT handling for the extension: nat=force_rport,comedia (or the older nat=yes) on chan_sip, or rtp_symmetric, force_rport and rewrite_contact on PJSIP.
3. Make sure the firewall allows the RTP range, commonly UDP 10000 to 20000 on Asterisk-based systems, between the phones and the server.
4. Turn off SIP ALG on the router.
5. If the PBX itself is behind NAT, set its external address and local networks in the SIP settings.
6. Retest from a different network to confirm which side is at fault.

Why does RTP go to a private IP address?

A SIP phone describes its media in the SDP body of the INVITE or the 200 OK. The description includes an IP address and a port where it wants to receive audio. A phone behind a home or office router only knows its private address, so that is what it writes. The server or the other phone obediently sends RTP to 192.168.1.20:4000, which does not exist from the outside. Meanwhile the phone sends its own RTP out through the router, which does create a mapping, so audio in that direction works. Hence one way.

The SIP headers have the same problem: Via and Contact carry the private address. RFC 3581 added the rport parameter so servers reply to the real source port instead. How NAT Affects SIP and RTP explains the whole picture.

Fix 1: Turn on STUN and ICE in the softphone

STUN (RFC 5389) lets the phone ask a public server "what address do you see me as?". The phone then writes that public address and port into its SDP instead of the private one. It works when the router gives the same external port to the same internal socket, which most home routers do.

ICE (RFC 8445) goes further. The phone gathers several candidate addresses, private and STUN-derived, lists all of them in the SDP, and both sides test which pair actually passes traffic before committing. ICE copes with routers that STUN alone cannot predict, as long as the far end also supports ICE. Asterisk supports ICE when configured.

Any public STUN server works for the lookup. Enable both and test again.

Fix 2: Tell the PBX to ignore the advertised address

Even if the phone advertises a private address, the server can work around it. The technique is called symmetric RTP or comedia: the server waits for the first RTP packet from the phone, notes the real source address and port, and sends its own RTP back there. This works because almost all phones send and receive on the same port.

On Asterisk-based systems such as Issabel and FreePBX:

• chan_sip: set nat=yes on the extension (older versions) or nat=force_rport,comedia on newer ones.
• PJSIP: set rtp_symmetric=yes, force_rport=yes and rewrite_contact=yes on the endpoint.

The Asterisk documentation describes each option. The Issabel integration page shows where they appear in the web interface. These settings fix the common case where the phone is behind NAT and the server is not.

Fix 3: Open the RTP port range

Even with correct addresses, a firewall can block the media. SIP and RTP use different ports. Allowing 5060 alone is not enough. Asterisk defaults to UDP 10000 to 20000 for RTP; other servers use other ranges, and providers publish theirs. The rule must permit UDP in that range between the phones and the server. On the phone side, outbound UDP is normally allowed and the reply comes back through the same mapping, so the server side is where the rule matters most.

Fix 4: Switch off SIP ALG

A SIP Application Layer Gateway in the router tries to rewrite private addresses in SIP and SDP to public ones. When it does half the job, or rewrites after STUN has already inserted the right address, the result is one-way audio that appears and disappears with no pattern. Disable it in the router's firewall or NAT settings and test again. See What Is SIP ALG and Should You Disable It?.

Fix 5: The PBX is behind NAT too

When the server itself sits behind a router, its SDP contains its own private address and external phones cannot reach it. Asterisk needs to know its public address and which networks are local so it can choose the right one. In chan_sip these are externip or externhost plus localnet; in PJSIP they are external_media_address, external_signaling_address and local_net on the transport. Port forwarding for the RTP range to the server is also required.

How do I work out which side is broken?

Think about which direction fails:

• You hear them, they do not hear you. Your outbound RTP is dropped or sent to the wrong place. Check your firewall and whether the server's address in SDP is public.
• They hear you, you do not hear them. Their RTP is going to your private address or to a closed port. STUN and ICE on your phone, or symmetric RTP on the server, are the fix.
• It works on mobile data but not on Wi-Fi. The Wi-Fi router or firewall is at fault. Look at SIP ALG and the RTP range.
• It works for internal calls but not external ones. The trunk or the provider's media path is involved. Check the server's external address settings.

Next steps

If audio is missing in both directions rather than one, the cause may be codec or SRTP mismatch instead; read How to Troubleshoot No Audio in a SIP Call. For the protocol background, How NAT Affects SIP and RTP goes deeper into rport, STUN, ICE and TURN. If you are configuring SIPdia against an office PBX, the Issabel integration page lists the NAT and firewall settings in one place.