Home / NAT, ICE, and the ALG problem / Media latching on an SBC
Media latching on an SBC
Many SBCs learn the remote RTP address from the first packet instead of trusting c=. That is deployment practice, and RFC 5853 is the requirements RFC.
Learn in 5 minutes
- Describe latching as learning RTP from the first packet
- Cite RFC 5853 as requirements, not as an algorithm
- Refuse to move the latch toward an unexpected source
Visual
Latching is something many SBCs do. RFC 5853 collects requirements. It is not an IETF algorithm.
Worked example
Compare c= with the packet source Extract the INVITE and read c=. Then read the RTP note. The source port's address is not the c= address.
- Press Extract SIP and read c=.
- Read the RTP source in the text.
- State where a latching SBC sends return media.
Fault
c= says 203.0.113.10. The first RTP source is 198.51.100.30, which is not the phone side the SBC authenticated. Return media moves there.
Many SBCs learn the remote RTP address from the first packet instead of trusting c=. That is deployment practice. RFC 5853 is the requirements RFC, not an IETF algorithm.
Quiz
Ecosystem
Glossary, sister systems, and the integration seam for this room.
Workforce management WFM forecasts volume and builds schedules. It consumes contact-center events. It does not parse Via headers. When a forecast is wrong, the SIP symptom is usually queue delay and 480 or carrier congestion, not a broken dialog ID.
Programmable communications APIs Twilio’s docs home is API reference, tutorials, and integration for Twilio products. Elastic SIP Trunking is the SIP-shaped product already cited in this lab. This page does not define the word CPaaS from an RFC. Read the vendor page before you copy a diagram that uses that word.
Sources and go deeper
- RFC 5853 — last checked 2026-10
- RFC 8866 — last checked 2026-10
- RFC 8445 — last checked 2026-10
- RFC 3261 §22 — last checked 2026-10