STUN vs TURN vs ICE: cómo hacer que WebRTC funcione detrás de firewalls corporativos
Qué hace cada uno de STUN, TURN e ICE en WebRTC, y por qué planificar la capacidad TURN es clave en redes empresariales reales.
WebRTC promete audio y video peer-to-peer directamente en el navegador, pero la internet real está llena de NATs, routers restrictivos y firewalls corporativos. Dos peers no pueden simplemente intercambiar direcciones IP y esperar que el medio fluya.
ICE, o Interactive Connectivity Establishment, es el framework de negociación que intenta descubrir la mejor ruta posible entre dos peers. Coordina la recopilación de candidatos y las pruebas de conexión para que WebRTC se adapte a entornos de red complejos del mundo real.
STUN es la ayuda ligera dentro de ese proceso. Un cliente pide a un servidor STUN que le revele su IP y puerto públicos, y luego comparte esa información con el peer remoto. Cuando el NAT es lo bastante permisivo, eso basta para establecer una conexión directa.
TURN existe para los casos difíciles. En redes corporativas estrictas y NATs simétricos, una conexión directa puede no llegar a funcionar aunque ambos peers conozcan su identidad pública. En esa situación, ICE recurre a un relay TURN que recibe el flujo de un lado y lo reenvía al otro.
Ese fallback es lo que hace viable WebRTC en entornos enterprise, pero también cambia el modelo de costes. STUN es barato, mientras que TURN consume ancho de banda e infraestructura reales porque retransmite el flujo multimedia.
La lección práctica es optimizar para tráfico P2P directo, pero planificar el entorno de producción como si una parte significativa de las llamadas fuese a necesitar TURN. Sin una infraestructura TURN sólida, WebRTC funciona muy bien en demos y falla justo donde los clientes enterprise más lo necesitan.