Symmetric RTP and Latching

1. The NAT problem for RTP

SIP signaling tells each side where to send RTP. The SDP offer says “send my audio to address X port Y.” The answer says “send your audio to address Z port W.”

Behind NAT, this breaks. The SDP from a phone behind NAT contains private IP addresses (192.168.x.x, 10.x.x.x). The far side cannot route to those addresses. Even if it could, the phone's NAT has not opened a pinhole for inbound RTP from the far side's actual public IP and port.

Three solutions exist:

• STUN/ICE: Discover the public address externally and put it in the SDP. Works but requires both sides to support ICE.
• SBC media anchoring: An SBC sits in the middle, terminates RTP from each side, and bridges between them. Works always but requires SBC infrastructure.
• Symmetric RTP plus latching: The endpoint sends RTP from the same socket it receives on, and the far side “latches” onto the source IP/port of the first packet it receives, regardless of what was in the SDP. This works without ICE or SBC, just by convention.

Symmetric RTP plus latching is the most common technique in real-world deployments because it works in the most environments without infrastructure changes.

2. Symmetric RTP

Symmetric RTP means an endpoint uses the same IP and port for both sending and receiving RTP. The port the endpoint listens on is the same port it sends from.

This sounds obvious but is not the default behavior of RTP per RFC 3550. Strictly, RTP allows separate transmit and receive ports. Symmetric RTP is a constraint added on top to make NAT traversal work.

Why it helps:

1. Phone behind NAT sends RTP to far side from source port 49170
2. Phone's NAT creates a mapping: internal 192.168.1.50:49170 ↔ public 1.2.3.4:55000
3. Far side observes the source IP/port of incoming RTP: 1.2.3.4:55000
4. Far side sends its RTP back to 1.2.3.4:55000 (latching, see next section)
5. NAT recognizes the inbound packet matches the existing mapping and forwards to the phone
6. The phone receives RTP on port 49170 — the same port it sends from

If the phone used different ports for send and receive, step 6 would fail. The far side's RTP would arrive at the public mapping for the send port, but the phone is listening on a different port internally. The NAT mapping does not exist for the receive port until the far side sends something to it — which it cannot, because the receive port's public IP is not in the SDP's NAT mapping.

3. Latching

Latching is the complement to symmetric RTP. It is what the far side does: instead of trusting the IP/port in the received SDP, it observes the actual source of incoming RTP and starts sending its own RTP back to that source.

Why it helps:

1. Phone behind NAT sends SDP claiming RTP at 192.168.1.50:49170 (the private address)
2. Far side receives the SDP but recognizes 192.168.1.50 is not routable
3. Far side starts sending RTP to whatever public address shows up
4. When the first RTP packet from the phone arrives (say from 1.2.3.4:55000), the far side latches onto that source
5. From then on, it sends its RTP to 1.2.3.4:55000 instead of the SDP-declared address

Latching is sometimes called “media latching” or “learn from receive.” The far side learns the actual public IP/port of the NAT'd phone by observing it, then uses that for its own transmits.

4. How symmetric RTP and latching work together

The two techniques are paired. Each makes the other work:

• Symmetric RTP from the NAT'd side ensures the phone's send and receive use the same NAT mapping
• Latching from the far side ensures it sends RTP to the public mapping, not to the unroutable private address in the SDP
• The NAT, having an outbound mapping for the phone's RTP, recognizes inbound RTP from the same far-side source and forwards it

Both sides must implement their respective behaviors. If the phone is symmetric but the far side does not latch, the far side sends RTP to the SDP address (unroutable) and the phone hears nothing. If the far side latches but the phone is not symmetric, the latched-onto port is for the phone's send-only mapping; the receive port has no NAT mapping and audio is one-way.

This is one reason why symmetric RTP and latching are widely deployed together — either alone is much less effective than both.

5. Failure modes

6. Diagnosing latching issues

Look for:

• Source IP/port of inbound RTP vs SDP-declared address. If they differ, latching is required for return RTP to work. Verify the far side latched.
• Direction of audio failure. One-way audio toward the NAT'd endpoint is a latching failure. One-way audio away from the NAT'd endpoint is a symmetric RTP failure on the endpoint.
• RTCP traffic. If RTP works but RTCP is missing, check rtcp-mux or RTCP latching. Modern stacks use rtcp-mux to share the same port for RTP and RTCP.
• SBC presence. An SBC anchoring media bypasses the symmetric/latching question by terminating RTP at the SBC. If audio fails despite SBC, the issue is between SBC and endpoint, not between endpoints directly.
• SIP ALG interference. SIP ALGs that rewrite SDP can break latching by replacing the private address with what it thinks is the public address — if it gets it wrong, the far side latches onto a useless target.

Frequently asked questions

What is symmetric RTP?

Symmetric RTP means an endpoint uses the same IP and port for both sending and receiving RTP. This is essential for NAT traversal — using the same port for both directions ensures the NAT mapping created by outbound RTP is also used for return RTP, allowing audio to flow in both directions through the NAT.

What is RTP latching?

RTP latching is the technique where one endpoint observes the actual source IP and port of incoming RTP and starts sending its own RTP back to that observed source, instead of relying on the IP/port in the received SDP. Latching enables RTP to work through NAT without ICE or SBC media anchoring — the far side learns where to send by observing where the NAT'd endpoint's RTP actually came from.

Why do symmetric RTP and latching need to work together?

They are complementary techniques. Symmetric RTP ensures the NAT'd endpoint's send and receive use the same NAT mapping (so return RTP traverses the existing pinhole). Latching ensures the far side sends RTP to the public mapping rather than the unroutable private address in the SDP. If only one is in place, audio fails — either the far side cannot reach the NAT'd endpoint (no latching) or the latched address points to a port without a NAT mapping (no symmetric RTP).