WebRTC Signaling Config Generator

STUN (Session Traversal Utilities for NAT) helps peers discover their public IP address and port, enabling direct peer-to-peer connections in most cases. TURN (Traversal Using Relays around NAT) is a fallback relay server that proxies all traffic when direct connection fails — typically for peers behind symmetric NAT firewalls. STUN is free and low-cost; TURN requires dedicated server infrastructure and bandwidth.

About 10–15% of internet users are behind symmetric NAT (common in corporate networks, some ISPs, and mobile carriers). Without a TURN server, these users cannot establish WebRTC connections at all. If you want >95% connection success rate, a TURN server is essential. The iceTransportPolicy:relay option forces all traffic through TURN, useful for privacy-sensitive applications.

TURNS is TURN over TLS, typically on port 443 (same as HTTPS). It allows WebRTC traffic to pass through firewalls that block UDP and non-standard TCP ports. It's slower than plain TURN but works in the most restrictive network environments like corporate proxies.

max-bundle combines all media (audio, video, data) into a single ICE candidate pair, reducing port usage and improving NAT traversal. It's the recommended setting for modern WebRTC. max-compat uses separate candidates per media stream for legacy compatibility. balanced is a middle ground.

Pre-allocating ICE candidates (pool > 0) starts gathering candidates before the offer/answer exchange, reducing connection setup latency. However, it uses network resources upfront. For low-latency applications like video calls, a pool of 2–5 is recommended. For background file transfer, leave it at 0.

Google's public STUN servers (stun.l.google.com) are reliable and widely used, but Google makes no SLA guarantees for third-party use. For production applications, especially with thousands of users, consider running your own STUN/TURN infrastructure using Coturn (open source) or services like Twilio, Xirsys, or Cloudflare Calls.