Asterisk PJSIP: NAT Part 1 (Latest Versions)

NAT (Network Address Translation) is the #1 cause of real-world SIP and RTP problems. Most Asterisk deployments are either:

• behind a router (office broadband)
• behind a firewall (enterprise)
• behind cloud networking rules (AWS / GCP / Azure)

Even when calls "connect", NAT issues cause:

• one-way audio
• no audio after answer
• incoming calls fail randomly
• registration works sometimes, breaks sometimes

This guide explains NAT in a practical way for modern PJSIP Asterisk and gives working configurations + a debugging workflow you can trust.

What NAT Actually Does (Why SIP Breaks)

NAT allows multiple private devices (192.168.x.x / 10.x.x.x) to share one public IP. Your router rewrites traffic:

• Outbound packets: private IP → public IP
• Inbound packets: public IP → private IP (only if port forwarding / rules exist)

SIP and RTP are not like normal web browsing. SIP messages contain IP/port information inside the payload (SDP and headers). If Asterisk advertises the wrong IP/port, the provider sends RTP to the wrong place.

SIP vs RTP: NAT Breaks Them Differently

• SIP signaling (usually UDP 5060): call setup, INVITE/200 OK/ACK/BYE
• RTP media (usually UDP 10000–20000): actual audio packets

Common pattern:

• SIP works (call rings, answers)
• RTP fails (silence / one-way audio)

That’s why NAT troubleshooting must always include RTP verification.

Three Common Deployment Scenarios

Scenario A: Asterisk has a Public IP (No NAT)

• Typical in cloud servers
• Inbound traffic reaches Asterisk directly (if security groups allow)
• Still need firewall rules

Scenario B: Asterisk behind Router NAT (Office)

• Private LAN IP (ex: 192.168.1.50)
• Public IP on router
• Requires port forwarding and correct Asterisk NAT config

Scenario C: Double NAT (Very Common Problem)

• ISP modem NAT + office router NAT
• Or cloud NAT gateway + internal VM
• Usually causes random failures unless fixed properly

Golden Rule: Use a Static Public IP for Production

SIP providers and inbound calling become unstable if your public IP changes. For production trunks you should use:

• static public IP
• or cloud elastic IP

Without a stable IP, registration may keep flipping and inbound calls can fail.

Firewall and Port Forwarding Checklist (Must Do)

Whether you use UFW, iptables, cloud security groups, or firewall appliances, your NAT setup is incomplete unless these are open:

• SIP: UDP 5060 (or TCP/TLS ports if provider uses them)
• RTP: UDP 10000–20000 (default range)

Example (UFW):

sudo ufw allow 5060/udp
sudo ufw allow 10000:20000/udp

If Asterisk is behind a router, you must also port-forward:

• 5060 UDP → Asterisk LAN IP
• 10000-20000 UDP → Asterisk LAN IP

Disable SIP ALG (Critical)

Many routers have SIP ALG enabled by default. SIP ALG attempts to "help" SIP by rewriting packets, but often breaks modern PJSIP flows.

Symptoms of SIP ALG problems:

• calls connect then drop immediately
• random one-way audio
• registration flaps
• provider sees incorrect Contact address

Best practice: Disable SIP ALG on your router/firewall.

PJSIP NAT Settings You Must Understand

PJSIP has two levels of NAT control:

• Transport level: what IP Asterisk advertises for signaling/media
• Endpoint level: how Asterisk handles rport, symmetric RTP, contact rewriting

In production, both matter.

Transport NAT Configuration (Most Important)

If Asterisk is behind NAT, you must define:

• local_net: your private LAN range
• external_signaling_address: your public IP for SIP
• external_media_address: your public IP for RTP

Example (UDP transport):

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

; Your internal networks
local_net=192.168.0.0/16
; add multiple local_net lines if needed:
; local_net=10.0.0.0/8

; Your public IP (static or elastic)
external_signaling_address=YOUR_PUBLIC_IP
external_media_address=YOUR_PUBLIC_IP

If these are wrong or missing, Asterisk may advertise private IPs in SDP and providers will send RTP into a black hole.

Endpoint NAT Settings (Practical Defaults)

These settings solve a large percentage of NAT edge cases:

[provider-endpoint]
type=endpoint
; ... other trunk settings ...

direct_media=no

; NAT-friendly options
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

Meaning:

• rtp_symmetric=yes → send RTP back to where it came from (helps NAT)
• force_rport=yes → respect source port of SIP packet (RFC3581)
• rewrite_contact=yes → fixes Contact header when NAT is present
• direct_media=no → prevents endpoints from bypassing Asterisk (safer for NAT)

How to Detect NAT Problems Quickly (Real Symptoms → Real Cause)

Symptom 1: Call answers but no audio

• Cause: RTP ports blocked OR wrong external_media_address

Symptom 2: One-way audio (you hear them, they don’t hear you)

• Cause: RTP only flowing one direction due to NAT/firewall

Symptom 3: Inbound calls sometimes fail

• Cause: provider sends from multiple IPs OR NAT mapping changing OR SIP ALG

Symptom 4: Registration flapping

• Cause: NAT timeouts, firewall state expiry, incorrect Contact rewriting

Debug Workflow: Prove the Truth (No Guessing)

Use this workflow every time. It prevents random config changes.

1) Confirm SIP signaling behavior

asterisk -rvvv
pjsip set logger on

Place an inbound/outbound test call and confirm:

• INVITE arrives / is sent
• 200 OK happens
• SDP shows the IP/port Asterisk advertises

2) Confirm RTP packet flow

rtp set debug on

You should see RTP packets being received and sent. If you see only one direction, it’s NAT/firewall.

3) Prove it with tcpdump

sudo tcpdump -i any -n udp port 5060

Capture SIP + RTP for Wireshark:

sudo tcpdump -i any -s 0 -w nat_test.pcap udp port 5060 or udp portrange 10000-20000

Open nat_test.pcap in Wireshark and check:

• Does SDP advertise private IP or public IP?
• Is provider sending RTP to the correct public IP?
• Is RTP arriving on your server?

Reading SDP in Wireshark (What to Look For)

Inside SIP messages, SDP contains:

• c=IN IP4 X.X.X.X → where RTP should be sent
• m=audio PORT RTP/AVP ... → which RTP port is used

If you see:

• c=IN IP4 192.168.x.x in SDP → NAT misconfiguration (wrong external IP)
• RTP sent to wrong public IP → provider side config or stale registration

Keep NAT Stable: Registration and Qualify Timers

NAT mappings can expire if there is no traffic. Two practical techniques keep NAT stable:

• Use registration retry/expiration correctly (registration-based trunks)
• Use AOR qualify (OPTIONS ping) to keep path alive

Example AOR:

[provider-aor]
type=aor
contact=sip:PROVIDER_IP
qualify_frequency=60

Advanced Note: RTP Port Range (Tune for Your Firewall)

Default RTP range is often 10000-20000. You may adjust in rtp.conf. Example:

; /etc/asterisk/rtp.conf
[general]
rtpstart=10000
rtpend=20000

If you change this range, your firewall rules must match the same range.

Production Checklist (NAT Done Correctly)

• Static public IP (or elastic IP) in production
• Router SIP ALG disabled
• Port forwarding for SIP + RTP if behind NAT
• Firewall open for UDP 5060 and RTP range
• PJSIP transport has local_net + external_signaling/media_address
• Endpoints use rtp_symmetric + force_rport + rewrite_contact
• Wireshark/tcpdump workflow available for proof

Key Takeaway

NAT problems are not random — they are predictable once you separate:

• SIP signaling correctness
• SDP advertised IP/port correctness
• RTP firewall reachability

With the correct PJSIP transport + endpoint settings, plus proper firewall and SIP ALG control, Asterisk becomes stable in real production networks.