Frequently Asked Question

All Categories » Open Source Software / Asterisk / FreePBX

Reliable SIP / RTP over NAT for Endpoints

Last Updated 4 hours ago

For robust SIP/RTP functionality over Network Address Translation (NAT) for endpoints, the primary goal is ensuring both signalling (SIP) and media (RTP) traffic can traverse the NAT device bidirectionally.

Key Requirements

Public IP Advertisement (Contact header): The endpoint (phone/softphone) must inform the SIP server of its public IP address (the IP seen by the server) and the specific port it expects to receive incoming SIP signalling on. This is typically achieved via the Via and Contact headers within SIP messages.
STUN (Session Traversal Utilities for NAT): STUN is a protocol that allows a NATed endpoint to discover its public IP address and the type of NAT it is behind. It helps the endpoint construct correct SIP Contact and Via headers, and also aids in opening UDP ports for RTP. While optional if the public IP is explicitly configured, it is highly recommended as a reliable fallback and for dynamic IP environments.
SIP REGISTER: Endpoints register periodically with the SIP server, informing it of their availability and current network location (IP and port). This keeps NAT bindings alive and allows the server to route incoming calls correctly.
RTP Port Range: RTP uses a range of UDP ports, typically 10000-20000. The endpoint's NAT device needs to allow this range for outgoing and incoming traffic, or the endpoint must be configured to use specific ports that can be port-forwarded.
Keep-Alives: To maintain NAT bindings and prevent them from timing out, endpoints should send periodic keep-alive packets (e.g., SIP OPTIONS or blank UDP packets) to the server.

Endpoint Configuration for NAT Traversal

Most modern SIP phones and softphones offer specific settings for NAT traversal.

1. Public IP Configuration (Manual)

If you have a static public IP and are not using STUN, you can often configure the phone directly.

Yealink/Grandstream/Fanvil (and similar IP Phones):
Navigate to Account > Advanced or Network > NAT.
Look for an option like External IP or Public IP Address.
Enter your public IP, for example: 192.0.2.1

    External IP: 192.0.2.1

Ensure NAT Traversal is set to Static NAT or similar.

Softphones (Zoiper, Bria, etc.):
Go to Settings > Accounts > Network Topology or NAT Settings.
Enable Use Public IP and enter the public IP.

2. STUN Configuration (Recommended for Dynamic or Unknown Public IP)

STUN allows the endpoint to discover its public IP automatically. Specify the provided STUN server: stun.gen.network.

Yealink/Grandstream/Fanvil:
Navigate to Account > Advanced, Network > NAT, or Advanced Settings > SIP/RTP.
Find NAT Traversal, STUN Server, or ICE/STUN/TURN.
Select STUN or Use STUN Server.
Enter the STUN server address:

    STUN Server Address: stun.gen.network

The STUN Port is typically 3478 by default and does not usually need to be changed.

Softphones (Zoiper, Bria, etc.):
Go to Settings > Accounts > Network Topology or NAT Settings.
Enable Use STUN or STUN Enabled.
Enter the STUN server address:

    STUN Server: stun.gen.network

3. SIP Port (Signalling) Configuration

The server will accept non-standard SIP ports. Configure the endpoint to use the assigned port, e.g., 5001.

Yealink/Grandstream/Fanvil:
Navigate to Account > Register or Account > SIP.
Look for SIP Server Port or Local SIP Port.
Enter the assigned port:

    SIP Server Port: 5001

Note: The SIP Server Host should be ip4-7355.gen.network (or your assigned hostname).

Softphones (Zoiper, Bria, etc.):
When configuring the SIP account, specify the port with the hostname:

    SIP Registrar/Proxy: ip4-7355.gen.network:5001

Common NAT Scenarios and Causes

Symptom	Likely Cause(s)	Resolution
One-way audio (A hears B, B does not hear A)	1. RTP Path Blocked: The endpoint's NAT device is blocking incoming RTP from the server to the endpoint. The `Contact` header in the SIP INVITE was incorrect.	Ensure STUN is enabled and correctly configured on the endpoint. If using manual public IP, verify it is correct. Check local firewall on the endpoint's device (PC, phone). Ensure the router has a dynamic UDP NAT binding for the endpoint's RTP port range established.
One-way audio (B hears A, A does not hear B)	1. RTP Path Blocked (Server to Endpoint): Same as above, but in the opposite direction. The server cannot send RTP to the endpoint.	As above, verify STUN or manually configured public IP. This is often the case if the endpoint's `Contact` header (or m-line in SDP) advertises an incorrect internal IP or port for RTP.
Calls cut off after 30-60 seconds	1. NAT Session Timeout: The NAT device is closing the UDP port mapping for the media stream after a period of inactivity or due to its configured timeout.	Endpoint Keep-Alives: Ensure the endpoint sends periodic keep-alives (SIP `OPTIONS`, `NOTIFY` or blank UDP packets) to the server. Most phones have a `NAT Keep Alive` or `RTP Keep Alive` setting (e.g., 30 seconds). Also, enable RTP `PJSIP` Fax `T38` `NAT` Keep-Alive at the endpoint config via FreePBX. Router Configuration: Increase UDP NAT timeout on the local router if possible (not common in consumer routers).
Incoming calls ring, but cannot be answered or fail to connect	1. SIP `REGISTER` Issues: The endpoint's `REGISTER` message is not correctly updating its public IP/port with the server, or the NAT binding for SIP signalling has expired.	Enable `Register Expiry` or `SIP NAT Keep Alive` on the endpoint (e.g., every 60-120 seconds). Ensure `STUN` is active. Verify the SIP account is correctly registered. The router might be aggressively closing UDP ports for SIP signalling.
Calls fail to connect/register at all	1. Firewall Block: The local firewall (on the phone, PC, or router) is blocking outgoing SIP or RTP traffic. 2. Incorrect SIP Server/Port: Endpoint is trying to reach the wrong IP or port for the SIP server.	Verify network connectivity to `ip4-7355.gen.network` on port `5001` (or your assigned port). Check endpoint local firewall. Test with `ping` or `traceroute` if available (for hostname `ip4-7355.gen.network`). Double-check SIP Server Address and Port configuration on the endpoint. Ensure no proxy server is interfering. Some cheap routers block SIP, or intercept it.
Intermittent call issues / dropped calls	1. Unreliable NAT: The NAT device is a Symmetric NAT and is unpredictably changing port mappings. 2. Network Congestion/High Latency/Jitter: Poor network quality impacting RTP packets.	For Symmetric NAT, STUN alone may not be sufficient; in some rare cases, a VPN might be necessary. But for endpoints (not the server), STUN should generally suffice. Implement Quality of Service (QoS) on the local network (router) to prioritise voice traffic. Evaluate the internet connection quality. Make sure your router doesn't have SIP/ALG enabled (this causes endless issues).