WebRTC a gran escala: arquitectura de señalización y topologías de media
El artículo explica cómo montar un servidor de señalización para WebRTC y compara las topologías P2P, SFU y MCU para escalar videollamadas.
WebRTC sigue siendo la única solución estándar para transmitir audio, video y datos entre navegadores sin plugins. El estándar define tres APIs JavaScript – RTCPeerConnection, MediaStream y RTCDataChannel – que cubren la negociación de codecs, la captura de medios y el canal de datos, pero dejan fuera la forma de encontrar al otro peer.
Señalización y el intercambio Offer/Answer
Antes de que cualquier medio fluya, los peers deben intercambiar una descripción SDP que enumere codecs, tipos de medio y datos de red. WebRTC no provee un transporte para ese SDP; normalmente se usa WebSocket o HTTP long‑polling. El flujo típico consiste en que el iniciador crea una oferta, la envía por el canal de señalización y el receptor responde con una respuesta, usando sólo setLocalDescription y setRemoteDescription para hacer el trabajo real.
Traversal NAT: ICE, STUN y TURN
La mayoría de los dispositivos están detrás de NAT o firewalls, por lo que la dirección pública no está disponible directamente. ICE recopila candidatos de tres fuentes: host (interfaz local), server‑reflexive (respuesta de un servidor STUN) y relé (servidor TURN). Si los candidatos directos fallan, TURN actúa como proxy, añadiendo latencia y consumo de ancho de banda del servidor.
Los candidatos pueden enviarse todos al final del proceso de recolección (ICE tradicional) o de forma incremental – trickling ICE – lo que permite que la negociación empiece tan pronto como llega el primer candidato. La mayoría de los stacks modernos habilitan trickling por defecto.
Implementación de un servidor de señalización escalable
El autor construyó un MVP de señalizador con Node.js y Express, aprovechando el modelo de bucle de eventos de Node para manejar miles de conexiones WebSocket simultáneas sin crear un hilo por conexión. La señalización se expone mediante Socket.IO, lo que simplifica la transmisión de mensajes SDP y candidatos ICE entre peers.
Topologías de media y su escalado
- P2P (peer‑to‑peer): Cada par establece su propia conexión directa. Funciona bien para grupos pequeños, pero el número de flujos crece como n·(n‑1)/2, lo que rápidamente sobrecarga el ancho de banda de los clientes.
- SFU (Selective Forwarding Unit): Cada cliente envía su stream a un nodo central que reenvía solo los paquetes necesarios a los demás participantes. Reduce la carga de los clientes y permite cientos de usuarios, aunque el servidor consume ancho de banda proporcional al número de streams.
- MCU (Multipoint Conferencing Unit): El nodo central recibe, decodifica y vuelve a codificar los streams en una única mezcla. Minimiza el consumo de ancho de banda del cliente al recibir solo un flujo mixto, pero introduce latencia y una carga de CPU considerable en el servidor.
Qué considerar al escalar
- Conectividad: La capacidad del servidor de señalización para mantener conexiones WebSocket bajo alta carga.
- Seguridad: Autenticación y cifrado de los canales de señalización, además de la gestión de credenciales STUN/TURN.
- Fiabilidad: Redundancia del servidor de señalización y balanceo de carga para evitar puntos únicos de falla.
Para profundizar en los detalles de la API, consulte la documentación de MDN: WebRTC API y la guía de Socket.IO docs. La combinación de una señalización ligera y la elección adecuada de topología permite que aplicaciones de videoconferencia escalen desde decenas hasta miles de usuarios simultáneos.
En conclusión, WebRTC sigue siendo viable a gran escala siempre que se diseñe una arquitectura que separe la señalización del procesamiento de media y se elija la topología que mejor equilibre ancho de banda, latencia y carga de CPU.
