Real-time / Web

NAT Traversal in SIP/VoIP

NAT (Network Address Translation) breaks SIP because SIP signaling carries IP addresses inside the message body (the SDP). NAT traversal techniques rewrite those addresses or use helper protocols so media actually flows.

Why SIP is NAT-hostile

The SDP body in a SIP INVITE includes c=IN IP4 192.168.1.5 (the sender's private IP). The recipient tries to send RTP to that private address — which is unroutable. Result: silence, one-way audio, or call setup failure.

Solutions in order of complexity

1. Symmetric RTP / latching: the receiver ignores the SDP IP and sends RTP back to whatever IP+port it received the first inbound RTP packet from. Most modern PBXs default to this. Works for ~95% of NATs.
2. SIP ALG (Application-Level Gateway): a NAT router rewrites SIP/SDP on the fly. Avoid — consumer-grade ALGs corrupt more than they help. Disable on your router if available.
3. STUN-aware client: client discovers its public IP via STUN and writes that into the SDP itself.
4. TURN relay: last resort for symmetric NATs. Both endpoints relay media through a public TURN server.
5. Hosted SBC: a public-IP SBC in front of the PBX terminates SIP+RTP from outside, then re-originates them to the private PBX. DIDHub managed-SBC deployments use this.

Asterisk pjsip example

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
external_media_address=<public-ip>
external_signaling_address=<public-ip>

[didhub]
type=endpoint
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

Related terms