FreePBX

FreePBX SIP Settings: NAT, RTP Ports, and Codec Choices

MYLINEHUB Team • 2026-02-13 • 10 min

Screenshots + clean steps to configure this FreePBX module in a production-safe way.

FreePBX SIP Settings: NAT, RTP Ports, and Codec Choices

FreePBX SIP Settings: NAT, RTP Ports, and Codec Choices

If your calls connect but audio is missing, audio is one-way, calls drop after a few seconds, or WebRTC/softphones behave randomly, FreePBX SIP Settings is where you fix the foundation.

This guide is written for FreePBX 16/17 (Asterisk 18/20) with chan_pjsip, and maps every major step directly to the screenshots in this page.

  • Security + NAT: External Address, Local Networks, guest/anonymous toggles
  • RTP: Port range and timeouts (the #1 “no-audio” cause)
  • WebRTC/ICE + STUN/TURN: what to fill and when
  • Codecs: keep it small to avoid transcoding surprises
  • PJSIP Misc + Transports: UDP/TCP/TLS/WS/WSS, TLS cert selection

After these settings are correct, your Trunks, Extensions, Inbound Routes, IVR, Queues, and ARI/AMI integrations (like MYLINEHUB VoiceBridge) become much more stable.

Where to Find SIP Settings in FreePBX

Go to:

  • Settings → Asterisk SIP Settings

Depending on your FreePBX build, you will see multiple sections/tabs like: Security, NAT, RTP, WebRTC, Codecs, PJSIP, Transports, TLS/SSL/SRTP, etc.

FreePBX SIP Settings showing Security and NAT sections
SIP Settings (chan_pjsip): this screen includes Security Settings and NAT Settings (External Address + Local Networks).

A Simple Mental Model (Why These Settings Break Audio)

SIP calling is two different flows:

  • SIP signaling (INVITE / 200 OK / BYE): usually port 5060 (UDP/TCP) or 5061 (TLS)
  • RTP media (actual voice): a range of UDP ports (example 10000–20000)

Common symptom mapping:

  • Call connects, no audio → RTP ports blocked OR wrong public address advertised in SDP
  • One-way audio → NAT/Local Networks incorrect OR asymmetric routing
  • Call drops after ~15–30 sec → NAT timers / keep-alive issues / firewall pinholes closing
  • WebRTC connects, no audio → ICE/STUN/TURN missing OR WSS/SRTP/DTLS mismatch

Step 0: Security Settings (Do This Before NAT)

In production, you should not allow random SIP endpoints to hit your PBX. Most PBX hacks start with open SIP. Use the security toggles in SIP Settings and pair them with FreePBX Firewall rules/trusted IPs.

Security Settings in FreePBX SIP Settings
Security section: Allow Anonymous Inbound SIP Calls, Allow SIP Guests, and TLS port assignment. NAT settings: set External Address to your public IP (or stable DDNS hostname). The screenshot shows an example public IP filled in. Local Networks: add your real LAN/VPN subnets (example shown includes 192.168.0.0/24 and multiple 10.x ranges).
  • Allow Anonymous Inbound SIP Calls: No (keep it closed unless you have a very specific reason)
  • Allow SIP Guests: No (avoid unauthenticated endpoints)
  • Default TLS Port Assignment: keep PJSIP if you use TLS on chan_pjsip

If you truly need a trunk that arrives “anonymous”, do it safely: create a proper pjsip identify match for the provider IP(s) and accept only from those IP ranges.

Step 1: NAT External Address (Most Important)

- Refer above image

If your server is behind NAT (office router / cloud firewall / VPS with private interface), Asterisk must know what public address to advertise to the outside world. If this is wrong, the far end will send RTP to the wrong IP → silent audio / one-way audio.

What to set

  • External Address:
    • If you have a static public IP, set it directly.
    • If your IP changes, use a DDNS hostname (and ensure it updates correctly).
  • Detect Network Settings: This can help, but in production a known static IP/DDNS is more predictable.

Reality check: External Address impacts what Asterisk writes into SDP. If SDP advertises a private IP (like 192.168.x.x), your provider/remote phone will send RTP there and you’ll hear nothing.

Step 2: Local Networks (Tell Asterisk What Is “Inside”)

- Refer above image

Local Networks is where you define your internal LAN subnets. Asterisk uses this to decide when to apply NAT rewriting and how to treat contacts.

Correct way to add Local Networks

  • Use subnets (like 192.168.0.0/24) not just one host IP.
  • Include VPN subnets if your remote phones connect over VPN.
  • Include all internal ranges that can register phones or talk to the PBX.

Common mistake

  • People add 192.168.0.10/32 (single device) and forget the actual LAN subnet.
  • They forget cloud/VPN ranges, so endpoints get treated “external” and NAT decisions become wrong.

Step 3: RTP Settings (Audio Must Have Open Ports)

RTP is the actual voice stream. If your RTP ports are blocked on the server firewall, FreePBX firewall, or your router/security group, calls will connect but audio will be silent or one-way.

RTP Port Range settings and RTP timeouts in FreePBX
RTP settings: the screenshot shows a standard RTP range 10000–20000, with timeout fields below. Media Transport Settings: STUN/TURN fields are present and empty by default. Only fill these when you actually use WebRTC or need ICE traversal support.
  • RTP Port Range: keep a standard documented range like 10000–20000
  • RTP Timeout: 30 is common (drop calls if no RTP for 30 seconds)
  • RTP Hold Timeout: 300 (hold state can be longer)
  • RTP Keep Alive: 0 means disabled (enable only if you understand the need)

Firewall ports you must allow (minimum)

UDP 5060        (SIP over UDP, if used)
TCP 5060        (SIP over TCP, if used)
TCP 5061        (SIP TLS, if used)
UDP 10000-20000 (RTP audio media)

If you use FreePBX Firewall module, ensure the services for SIP/RTP are enabled and the correct zones/trusted IPs are set.

Step 4: Media Transport (STUN/TURN) + ICE (WebRTC/Hard NAT Cases)

For most classic SIP trunks + desk phones, you can leave STUN/TURN blank. But for WebRTC or difficult NAT environments, these fields become important.

ICE Blacklist, ICE Host Candidates and WebRTC settings
ICE and WebRTC settings: ICE Blacklist/Host Candidates and WebRTC STUN/TURN are shown here. These are mainly for WebRTC endpoints.

When you need STUN/TURN

  • You are using browser calling (WebRTC) over the internet.
  • Your users are behind restrictive NAT where direct UDP hole-punching often fails.
  • You see “connected” calls but media never flows unless both are on same LAN/VPN.

Practical guidance

  • STUN helps a client discover its public mapped address.
  • TURN relays media when direct peer-to-peer cannot happen (more reliable, costs bandwidth).
  • For production WebRTC, you usually want a TURN server available (even if not always used).

ICE Blacklist / ICE Host Candidates

  • ICE Blacklist: block specific IPs/subnets from being offered as ICE candidates (rarely needed). Example use: prevent private subnets from being advertised to public clients.
  • ICE Host Candidates: manual mapping of internal→external candidates. Most setups keep this empty unless you have a special multi-interface NAT scenario.

Step 5: Audio Codecs (Keep It Small to Avoid Transcoding)

Codecs decide the audio format negotiated between endpoints and trunks. The more codecs you enable, the higher the chance of: wrong negotiation, unexpected transcoding, and CPU usage spikes.

Audio codec selection list in FreePBX SIP Settings
Audio codecs list: the screenshot shows many codecs enabled (ulaw, alaw, g729, opus, etc.). In production, prefer a minimal, predictable set.
  • For PSTN / SIP trunks: use G.711 only (PCMU/PCMA). It is the safest and most compatible.
  • For WebRTC endpoints: use Opus first (best quality), then G.711 fallback.
  • Avoid “enable everything” unless you have a clear requirement from a provider or legacy device.

Practical minimal sets

Classic SIP trunk only (recommended):

ulaw (PCMU)
alaw (PCMA)   (optional, depending on trunk/provider)

WebRTC + SIP trunk (recommended):

opus
ulaw (PCMU)
alaw (PCMA)

If your trunk forces a compressed codec (rarely ideal), enable only what is required. Example: some providers require g729 (then you must ensure licensing/codec availability).

Codec order matters

  • Put Opus at the top for WebRTC endpoints.
  • Put PCMU/PCMA at the top for PSTN/trunks if you are not using WebRTC.

Step 6: Video Codecs (Optional)

If you are not doing video calling, you can disable video to reduce negotiation complexity. If you do need video, keep it limited to modern codecs.

Video Support and Video Codecs list in FreePBX
Video settings: Video Support enabled with h264/mpeg4/vp8/vp9 shown. If you do not use video, disable Video Support.
  • If unused: Disable Video Support.
  • If used: prefer h264 (most compatible), keep the list small.
  • Max bitrate depends on your network; keep it conservative if calls happen over mobile networks.

Step 7: PJSIP Misc Settings + TLS/SSL/SRTP

These settings affect stability (keep-alives), troubleshooting (debug), overload protections, endpoint matching, and TLS certificate selection.

Misc PJSIP Settings and TLS SSL SRTP settings
Misc PJSIP Settings: Keep Alive Interval, Endpoint Identifier Order, and TLS/SSL certificate manager selection.
  • Enable Debug: No (turn on only during troubleshooting)
  • Keep Alive Interval: 90 seconds is a common stable value
  • Caller ID into Contact Header: usually No unless you have a specific interop reason
  • Show Advanced Settings: enable temporarily if you need deeper tuning

Endpoint Identifier Order (very important in real trunks)

  • If you use IP-auth trunks/providers, keep ip early in the list. This helps Asterisk match inbound INVITEs by source IP quickly.
  • If you use registration-auth endpoints, username/auth_username becomes important.

TLS/SSL/SRTP

  • Certificate Manager: select the correct domain certificate used for TLS/WSS
  • SSL Method: tlsv1_2 is a safe baseline
  • Verify Client: usually No unless you do mutual TLS
  • Verify Server: usually No unless you control the far-end CA requirements

If you enable TLS but forget to select the correct certificate, you’ll see handshake failures and clients won’t connect.

Step 8: Transports (UDP/TCP/TLS/WS/WSS) and What to Enable

Transports define how SIP signaling reaches Asterisk: UDP/TCP/TLS for classic SIP, and WS/WSS for WebRTC signaling.

Transports toggles in FreePBX for UDP TCP TLS WS WSS
Transport toggles: UDP/TCP/TLS/WS/WSS can be enabled. Only enable what you will actually use.
Transport details for TCP and TLS ports
Transport details: TCP typically uses 5060, TLS uses 5061. Keep ports aligned with your firewall rules and your trunk/client expectations.
  • Most SIP trunks: UDP 5060 only (simple and compatible)
  • Enterprise/strict networks: TCP 5060 sometimes preferred
  • TLS SIP: TLS 5061 (only when you have TLS endpoints and correct certs)
  • WebRTC: WSS (secure websockets) is usually required for browsers

Important note about restart

The Transports screen usually warns that after enabling/disabling a transport, Asterisk needs to be restarted (not just “Apply Config”). Plan a quick maintenance window when changing transports in production.

Step 9: Apply Config + Validate (CLI Checks That Save Hours)

After changes:

  1. Click Submit / Save
  2. Click Apply Config
  3. If you changed Transports: do a controlled restart of Asterisk

Useful validation commands

asterisk -rvvv

; Confirm PJSIP is up and transports exist
pjsip show transports

; Confirm NAT/external address style settings (varies by FreePBX version)
pjsip show settings

; Show endpoints and what codec lists they advertise
pjsip show endpoints

; Debug RTP only when needed (disable after)
rtp set debug on
rtp set debug off

Packet-level truth (when you suspect NAT)

  • sngrep (best for SIP dialogs)
  • tcpdump (best for confirming RTP packets actually arrive/leave)
apt install -y sngrep
sngrep

; RTP capture example (adjust interface and port range)
tcpdump -ni any udp portrange 10000-20000

Production Checklist (Use This Every Deployment)

  • Security: Anonymous + Guests = No (then allow only trusted IPs / authenticated endpoints)
  • External Address: correct public IP/DDNS (matches what the world sees)
  • Local Networks: correct subnets (LAN + VPN)
  • RTP Ports: allowed end-to-end (server firewall + FreePBX firewall + router/security group)
  • Codec list: minimal + ordered (avoid transcoding)
  • WebRTC: if used, WSS + Opus + STUN/TURN planning is done
  • Transports: only what you use; restart Asterisk after changes
  • SIP ALG: disabled on routers (very common cause of broken SIP)

Troubleshooting Quick Map

  • Call connects, no audio: RTP blocked OR wrong External Address advertised in SDP.
  • One-way audio: Local Networks missing OR NAT mismatch on one side.
  • Calls drop after ~15–30 seconds: NAT pinholes closing; check keep-alives and firewall timers.
  • WebRTC connects but no audio: ICE/STUN/TURN/WSS/SRTP mismatch; verify Opus and NAT correctness.

Next supporting articles that connect well to this page: FreePBX Firewall (trusted networks + services), Router SIP NAT / SIP ALG, and WebRTC on FreePBX (WSS + certificates + TURN server setup).

Try it

Want to see API-driven CRM + Telecom workflows in action? Try the WhatsApp bot or explore the demos.

💬 Try WhatsApp Bot ▶️ Watch CRM YouTube Demos
Tip: Comment “Try the bot” on our YouTube videos to see automation in action.
M
MYLINEHUB Team
Published: 2026-02-13
Quick feedback
Was this helpful? (Yes 0 • No 0)
Reaction

Comments (0)

Be the first to comment.