WebRTC ICE STUN TURN Deep Dive

Connectivity Model

1. Signaling exchanges SDP and ICE candidates.
2. ICE gathers candidate types: host / srflx / relay.
3. ICE connectivity checks pick the nominated pair.
4. DTLS handshake secures media and data channels.

STUN Role

• STUN discovers server-reflexive candidate address.
• It is a mechanism inside ICE, not a complete connectivity solution.

TURN Role

• TURN is fallback path when direct candidate pairs fail.
• Production setups usually include TURN for worst-case NAT/firewall.

Under UDP: How Media Is Carried

• WebRTC media uses RTP packets and RTCP control feedback.
• Security layer is SRTP/SRTCP.
• DataChannel runs SCTP over DTLS over ICE transport.

Answers to Key Questions

How do two NAT devices punch through?

• Both peers gather candidates and perform ICE checks.
• If NATs allow compatible mappings, direct route wins.
• Otherwise TURN relay path is selected.

How does slicing/packetization work for video over UDP?

• Encoded frames are packetized into RTP payloads.
• Large frames are fragmented across multiple RTP packets.
• Receiver reorders and depacketizes before decode.

How can devices with no public IP connect?

• Via ICE with STUN for discovery and TURN for relay fallback.
• Tailscale-like systems additionally use coordination + relay networks.

References

• ICE: https://www.rfc-editor.org/rfc/rfc8445
• STUN (current): https://www.rfc-editor.org/rfc/rfc8489.html
• TURN (current): https://www.rfc-editor.org/info/rfc8656
• W3C WebRTC: https://www.w3.org/TR/webrtc/
• MDN Connectivity overview: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity
• Media transport requirements: https://www.rfc-editor.org/rfc/rfc8834