SIP behind NAT — why your audio is one-way and how to fix it

"I can hear them but they can't hear me" — or the reverse — is the most-asked SIP question on the internet, and the answer is almost always NAT. This article explains why SIP and NAT fight each other, how to fix it on the FreePBX® and FusionPBX® side, and how to fix it on the network side when you can't change the PBX.

Why SIP and NAT fight

SIP signaling and RTP audio are separate streams on separate ports. When a SIP endpoint behind a NAT router (your office's internet router, your home router) sends an INVITE:

1. The phone's INVITE message embeds its own local address in the SDP body — the address it thinks it has, which is private (192.168.x.x or 10.x.x.x).
2. The router rewrites the IP header to use the public WAN IP, but doesn't rewrite the SDP body inside the SIP message.
3. The far end (PBX or carrier) receives the INVITE, looks at the SDP, and tries to send RTP audio to a private IP it can't reach.
4. You get one-way audio (the side that's NOT behind NAT can send but not receive, or vice versa).

The fix is to teach the SIP endpoint or the PBX to lie sensibly: "yes, I'm at 192.168.x.x, but really I'm reachable at <public- IP>:5060."

Fixing it on the PBX side

Your LYLIX-hosted PBX has a public IP and isn't behind NAT — so PBX → carrier and PBX → public phones works without intervention. The problem is phones in customer locations trying to register to the PBX from behind their office routers.

FreePBX (chan_pjsip)

In FreePBX: Settings → Asterisk SIP Settings → Chan PJSIP.

• External Address: your PBX's public IP. Auto-detected on a LYLIX VPS but verify it's correct.
• Local Networks: list the private subnets you DON'T need NAT handling for. If all your phones are external, leave this minimal (just 127.0.0.1/8). If you have a site-to-site VPN, add those subnets.

Then on each extension (Applications → Extensions → edit), under the Advanced tab:

• NAT Mode: force_rport,comedia (lets Asterisk learn the actual return address from incoming packets rather than trusting the SDP).
• Rewrite Contact: Yes.
• Direct Media: No. (Don't let endpoints stream RTP to each other; force everything through the PBX. Otherwise two NATted phones can't reach each other.)

Reload Asterisk config (Apply Config). Re-register the phones and test.

FusionPBX (FreeSWITCH)

FreeSWITCH handles NAT for endpoints via the aggressive-nat-detection and NDLB-force-rport profile params on the internal SIP profile, plus per-extension sip-force-contact and aggressive-nat-detection settings.

FusionPBX exposes these:

1. Advanced → SIP Profiles → internal → edit.
2. Find NDLB-force-rport, set to true.
3. Find aggressive-nat-detection, set to true.
4. Save and restart FreeSWITCH (or sofia profile internal restart in fs_cli).

On each extension under Accounts → Extensions → edit:

• nat: true
• sip-force-contact: NDLB-connectile-dysfunction (yes, that's the actual option name)

Fixing it on the phone side

Most SIP phones (Polycom, Yealink, Grandstream) have NAT-traversal settings in their config:

• STUN: phone queries a STUN server to discover its public IP and port, then uses those in the SDP. Works for most NATs. STUN servers: stun.l.google.com:19302, or your PBX can run its own.
• Outbound proxy: send all SIP through one proxy (your PBX), letting the PBX figure NAT out. Simpler than STUN; recommended for phones connecting to a single PBX.
• Keep-alive: phones behind NAT need to send periodic packets to keep the router's NAT mapping alive, otherwise inbound calls fail after a few minutes of idle. Polycom: natKeepalive=30. Yealink: keep-alive in the SIP advanced settings. Most defaults are sane.

Fixing it at the network level (router config)

Almost universally, the right move on the customer's router is to disable "SIP ALG". SIP ALG is a router feature meant to help — it inspects SIP traffic and rewrites embedded addresses — but it's notoriously buggy in consumer routers and usually makes things worse, not better.

Where to find it on common routers:

• Most consumer routers: WAN settings → "SIP ALG" or "Application Layer Gateway" → disable
• pfSense: System → Advanced → Firewall & NAT → disable SIP proxy
• OPNsense: similar
• Some routers don't expose this; check the router's documentation or the SIP forums for the specific model

Forwarding ports on the router is sometimes necessary, sometimes not — depends on the NAT type and the SIP setup. If outbound registration works but inbound calls don't ring, port-forward 5060/UDP and 10000-20000/UDP from WAN to the phone (or to the PBX if the PBX is local).

Diagnosing one-way audio specifically

The asymmetry tells you which direction is broken:

• You can't hear them, they can hear you: their RTP isn't reaching you. Your side is the one with the NAT problem (or your firewall is blocking inbound RTP).
• You can hear them, they can't hear you: your RTP isn't reaching them. Their side has the NAT problem.
• Both directions silent for the first few seconds then clears up: RTP timing issue or STUN discovery delay. Sometimes resolves itself; tweak keep- alive intervals.

Asterisk's sip set debug on (or pjsip set logger on for chan_pjsip) shows the SDP exchanges and helps you see what IPs each side is advertising.

The nuclear option: VPN your phones to the PBX

If a customer's network keeps breaking SIP regardless of what you do, run the SIP traffic over a WireGuard or OpenVPN tunnel from the phone (or a small router at the site) to a private interface on the PBX. SIP and RTP traverse the tunnel; no NAT traversal needed.

This is more setup but eliminates the entire class of problem. Useful for difficult customers, hotel networks, anywhere you don't control the router.

If you're still stuck

Asterisk and FreeSWITCH both log enough to diagnose nearly any NAT scenario. Capture:

• The full SIP exchange (INVITE, 100, 180, 200, ACK) for one problem call.
• The advertised IPs in both directions (look at the SDP body's c= and m= lines).
• The phone's actual public IP (search-engine your address or check the router's WAN page).

Open a LYLIX ticket with those, and we can help interpret. NAT debugging is half the SIP support tickets we see; we've seen most of the failure modes.

FreePBX® and Asterisk® are registered trademarks of Sangoma Technologies Corporation. FusionPBX® is a registered trademark of FusionPBX, LLC. FreeSWITCH® is a registered trademark of SignalWire, Inc.