How NAT Affects SIP and RTP

Network address translation (NAT) is behind many of the most common VoIP problems. A router with NAT lets many devices share one public IP address by rewriting the source address and port of every outgoing packet and remembering the mapping so replies can come back. That works for protocols that only care about packet headers. SIP is not one of them. SIP writes the phone's address inside the message, in the Via header, the Contact header and the SDP media description, and NAT leaves message contents alone. The result is a server that reads 192.168.1.20 and tries to send calls and audio to an address that does not exist from where it stands.

Quick checklist

For readers who want the fixes before the theory:

1. Use TCP or TLS transport where possible so the signalling connection stays open.
2. Turn on STUN and ICE in the softphone (in SIPdia under Account > Advanced, per the app's documentation).
3. Have the server enable rport handling and symmetric RTP (comedia).
4. Keep NAT mappings alive with keep-alives or a short registration interval.
5. Open or forward the RTP port range on the server side.
6. Disable SIP ALG on the router.

Where does SIP embed addresses?

Three places in a typical INVITE carry the phone's own address:

• Via tells the server where to send responses. RFC 3261 says responses go to the address in Via.
• Contact tells the server where to send future requests, such as a BYE or a new INVITE for an incoming call.
• SDP c= and m= lines tell the other party where to send RTP audio (RFC 3550).

Behind NAT, all three contain a private address. The router translated the IP header on the way out, but the message still says 192.168.1.20. The server may answer the Via address (private, unreachable), send incoming calls to the Contact address (private, unreachable) and send audio to the SDP address (private, unreachable). The phone's own outbound packets arrive fine, which is why you can register and hear nothing back.

How does rport fix signalling replies?

RFC 3581 added the rport parameter to the Via header. When the phone includes rport, the server fills in the source port it actually saw and sends responses back to the source IP and port of the request rather than the address written in Via. Since the router created a mapping for the outgoing request, the response travels back through it. Nearly every modern phone and server supports rport; on Asterisk it is the force_rport option. Rport fixes responses, but not new requests from the server, and not RTP.

How does the server reach the phone for incoming calls?

The Contact address is still private. Two things help. First, over UDP the router's mapping stays open for a short time after each packet, so if the server sends a request to the same public address and port it saw the REGISTER come from, the packet gets through. Servers do this by rewriting the Contact with the observed source (Asterisk calls it rewrite_contact). Second, the mapping must not expire. That is what keep-alives are for.

Keep-alives and SIP outbound

Home routers drop idle UDP mappings after 30 to 180 seconds. A phone that registers every hour leaves the mapping dead for most of that hour, so incoming calls are lost even though the phone thinks it is registered. Phones send small packets periodically to keep the mapping fresh. RFC 5626, called SIP outbound, standardises the approach: the phone opens a flow to the server, keeps it alive with CRLF or STUN pings, and the server uses that same flow for all requests to the phone. With TCP or TLS the connection itself is the flow, which is one reason connection-oriented transports behave better behind NAT. SIP over UDP, TCP and TLS compares them.

How does RTP get through?

RTP is the hard part because it is a separate stream on separate ports, and the ports are chosen per call.

Symmetric RTP on the server

Most phones send and receive RTP on the same port. A server can exploit this: instead of sending to the address in the SDP, it waits for the first RTP packet from the phone, reads the real public source address and port, and sends audio back there. Asterisk calls this comedia (chan_sip) or rtp_symmetric (PJSIP). It fixes the common case of a phone behind NAT and a server on a public address, without any help from the phone.

STUN on the phone

STUN (RFC 5389) is a small protocol in which the phone sends a request to a public STUN server and gets back the address and port the server saw. The phone can then write that public address into its SDP and Contact. This works when the router assigns the same external port regardless of destination, which is true of most consumer routers. It fails on routers that map each destination separately, sometimes called symmetric NAT, because the address learned from the STUN server is not the one the SIP server will see.

ICE: trying every path

ICE (RFC 8445) stops guessing. The phone gathers candidates: its private address, its STUN-derived public address, and optionally a TURN relay. It lists them all in the SDP. The other side does the same. Both then send connectivity checks across every pair and pick the first that works. ICE needs support on both ends. Phone-to-server ICE is common; Asterisk supports it when enabled. It costs a little setup time at the start of each call.

TURN: relaying when nothing else works

TURN extends STUN with a relay. When no direct path passes the ICE checks, both sides send media to the TURN server, which forwards it. It works on almost any network because both sides make outbound connections to a public server, but it adds latency and consumes bandwidth on the relay. TURN is a last resort, mostly for phone-to-phone media where no PBX sits in the middle.

What can a softphone do on its own?

A softphone controls only its end. It can:

• include rport in Via;
• use TCP or TLS so the signalling path stays open;
• send keep-alives;
• use STUN to learn and advertise its public address;
• run ICE when the other side supports it;
• send RTP from the same port it listens on, so symmetric RTP on the server works.

It cannot:

• change what the router does with idle mappings;
• stop a SIP ALG from rewriting packets, except by using TLS so the ALG cannot read them;
• fix a server that advertises its own private address in SDP;
• open firewall ports on the server side.

That is why one-way audio often needs a change on both the phone and the PBX. How to Fix One-Way Audio in VoIP Calls lists the settings on each side.

What about the server behind NAT?

Everything above also applies in reverse. A PBX in an office behind a router has the same private-address problem, and external phones send audio to it in vain. The server must be told its public address and its local networks so it chooses the right one for each peer, and the router must forward the SIP port and the RTP range to it. Asterisk's external_media_address, external_signaling_address and local_net options exist for this.

Next steps

With the theory in place, the practical fixes are in How to Fix One-Way Audio in VoIP Calls and What Is SIP ALG and Should You Disable It?. If registration itself drops behind NAT, see Why Does SIP Registration Keep Failing?. The TLS and SRTP feature page explains how encrypted transport also sidesteps ALG rewriting.