In LiveKit, TURN (Traversal Using Relay NAT) is a protocol used when direct peer-to-peer media connections cannot be established, typically due to restrictive NATs or firewalls. In this context, a "TURN" refers to the LiveKit-embedded TURN server that securely and authentically relays media for clients who cannot connect directly to the server or to each other. TURN is managed in LiveKit via configuration in your LiveKit server settings. You can enable TURN over UDP or, for maximum compatibility (especially in enterprise environments), TURN/TLS on port 443. LiveKit provides built-in authentication, port management, and uses TURN as a fallback when direct ICE connections are blocked. When enabled, only participants who have authenticated with the signaling server can use the TURN relay. To collect TURN-specific metrics: • Prometheus: Enable the Prometheus port in your LiveKit config. This exposes a

/metrics

endpoint, which includes TURN connection and relay stats (e.g., connection counts, relay bandwidth). • Built-in telemetry: TURN operations are instrumented for telemetry—listeners and relay allocators are monitored and metrics are available out-of-the-box when Prometheus integration is enabled. • For Kubernetes, expose the Prometheus port via your deployment and manage TURN certificates using secrets for secure TURN/TLS support. For best practices, use TURN/TLS on port 443 with a valid certificate, ideally behind a layer 4 load balancer if scaling, to ensure the broadest accessibility and to make traffic appear as standard HTTPS. Monitor connection success rates, bandwidth usage, protocol types (UDP vs. TLS), and geographic patterns to optimize deployment. Let me know if you need specific help with enabling metrics in your deployment, or if you have questions about interpreting the Prometheus output. Sources: Documentation/ImprovingCallReliability.md | Deploying LiveKit | LiveKit Docs | pkg/service/turn.go | Firewall Tips | livekit-server/templates/deployment.yaml