STUN discovers possible paths
STUN allows a client to learn its public-facing address and contributes candidates to ICE negotiation. It does not guarantee that peers can establish a direct connection.
Different NAT and firewall behaviors mean that a successful STUN response is not the same as a successful media path.
TURN is the reliability safety net
When direct connectivity fails, TURN relays the media stream. This increases bandwidth cost and infrastructure load but prevents a large class of connection failures.
Production systems should assume that some percentage of calls will require relay and size capacity accordingly.
Capacity planning is not optional
TURN traffic can be bandwidth intensive, especially for video. Teams need region planning, utilization metrics, limits and alerting.
A service can look healthy in application logs while media quality degrades because relay infrastructure is saturated.
Telemetry must cover the media path
Track candidate types, ICE state transitions, connection time, packet loss, jitter, bitrate, reconnects and relay use.
Without these metrics, operators cannot distinguish signaling bugs from network quality or TURN capacity problems.
Security belongs in the media architecture
TURN credentials should be short-lived, endpoints protected from abuse and media encryption requirements understood end-to-end.
If additional application-level E2EE is used, key lifecycle and failure behavior need their own design.
What to verify before a WebRTC launch
Test calls across mobile networks, corporate Wi-Fi, restrictive NAT, IPv4/IPv6 combinations and geographically distant users. Capture ICE candidate types and relay use so the team can quantify how often TURN is required instead of guessing from lab conditions.
Then load-test relay capacity with realistic audio and video profiles. A production readiness review should connect TURN utilization, call success rate, media quality and alert thresholds so capacity problems are visible before users report them.