One-way audio in SIP: NAT, SDP and the RTP media path

2026-07-12 · sip, webrtc, nat

The call connects, both sides think they’re talking, but audio only flows one way (or not at all). Signalling succeeded; media did not. Nine times out of ten the culprit is NAT and the SDP.

The SDP c= line is a promise about where to send RTP

Each side tells the other where to send media via the SDP c= (connection) and m= (port) lines. If an endpoint advertises a private address — 10.x, 192.168.x, 172.16–31.x, or CGNAT 100.64–127.x — the far side dutifully sends RTP to an unroutable destination. You hear nothing; they hear you (or the reverse), depending on which leg is behind NAT.

Spot it fast

Paste the INVITE (or 200 OK) into the SIP message analyzer. Its NAT lint flags a private IP in the SDP c= line or the Contact header and warns you to expect one-way audio. The SDP panel shows the exact c=/m= the far end will trust.

Fixes

1. SBC / media relay. Put a session border controller in the media path to rewrite the SDP and anchor RTP on a public address.
2. ICE (WebRTC). For browser legs, ICE with STUN/TURN discovers a reachable candidate — a TURN relay guarantees connectivity through symmetric NAT.
3. Symmetric RTP / comedia. Have the far side latch to the source address it actually receives RTP from, ignoring the advertised private address.

Don’t forget the ACK

A private Contact also breaks the mid-dialog ACK and BYE — the call may drop after ~30 seconds when the ACK never arrives. Same root cause, different symptom.