WebRTC a escala: cómo gestiona Mandraki las llamadas grupales masivas

La videollamada grupal es una de esas funcionalidades que parecen simples al usuario pero que conllevan una notable complejidad de ingeniería bajo la superficie. Una llamada uno a uno es relativamente directa: dos pares intercambian medios directamente. Pero en cuanto se añade un tercer participante, las decisiones arquitectónicas se multiplican, y cuando se llega a cincuenta participantes repartidos en múltiples sesiones concurrentes, se está frente a un problema de sistemas distribuidos genuinamente difícil.

Este artículo explica cómo la arquitectura de medios en tiempo real de Mandraki está diseñada para una escala masiva, sin renunciar al cifrado ni a la soberanía de datos.

Por qué no peer-to-peer

En una topología de malla peer-to-peer, cada participante envía su flujo de medios directamente a cada uno de los demás participantes. Para una llamada con N participantes, cada persona envía N-1 flujos y recibe N-1 flujos. El número total de conexiones es N*(N-1), y el requisito de ancho de banda de subida de cada participante escala linealmente con el número de participantes.

Esto funciona aceptablemente para tres o cuatro participantes con buenas conexiones a internet. Más allá de eso, se desmorona. Un participante con 5 Mbps de subida que envía un flujo de vídeo de 1,5 Mbps solo puede servir a tres pares antes de saturar su subida. El uso de CPU para codificar múltiples flujos crece rápidamente. Y las condiciones de red entre pares arbitrarios de participantes son impredecibles.

La topología de malla es elegante en teoría e impracticable a escala.

El enfoque SFU

Una Selective Forwarding Unit (SFU) se sitúa en el centro de la topología de la llamada. Cada participante envía un único flujo de subida al SFU. El SFU reenvía entonces ese flujo a todos los demás participantes. El ancho de banda de subida del participante es constante con independencia del número de participantes: siempre envía un flujo. El SFU gestiona la difusión.

La parte “selectiva” es importante. El SFU no se limita a retransmitir cada flujo a cada participante. Toma decisiones inteligentes de reenvío basadas en las condiciones de red, la visibilidad de los participantes y el ancho de banda disponible. Si la conexión de descarga de un participante está limitada, el SFU puede reenviar capas de resolución más baja. Si un participante no está visible actualmente en la UI (por ejemplo, en una llamada grande donde solo se muestra a tamaño completo el orador activo), el SFU puede reducir o pausar el reenvío de su flujo.

Esto es fundamentalmente distinto de una Multipoint Control Unit (MCU), que decodifica todos los flujos entrantes, los compone en un único flujo mezclado, lo vuelve a codificar y envía el compuesto a cada participante. Las MCU son intensivas en CPU, añaden latencia de codificación y, críticamente, requieren acceso al medio en texto plano, lo que las hace incompatibles con el cifrado de extremo a extremo.

Un SFU reenvía paquetes cifrados sin decodificarlos. Esto es lo que hace posible el cifrado de extremo a extremo basado en SFrame en una llamada grupal. El SFU enruta texto cifrado.

La arquitectura SFU de Mandraki

Mandraki utiliza una biblioteca SFU de código abierto integrada directamente en nuestra infraestructura. En lugar de depender de un servidor de medios monolítico de terceros, integramos el SFU como biblioteca dentro de nuestra propia base de código. Esto nos da control total sobre cómo se integra con nuestra capa de aplicación, el protocolo de señalización y el sistema de autenticación.

El SFU utiliza una arquitectura de múltiples workers. Cada worker es un proceso nativo independiente que gestiona el enrutamiento real de medios a un rendimiento cercano al nativo. La capa de coordinación gestiona workers, transportes e interactúa con nuestra lógica de aplicación. Esta separación mantiene rápida la ruta de medios mientras la ruta de control permanece flexible.

El SFU da soporte a simulcast y SVC (Scalable Video Coding), esenciales para el reenvío adaptativo al ancho de banda. Los navegadores de los participantes codifican su vídeo en múltiples niveles de calidad simultáneamente. El SFU selecciona el nivel apropiado para cada destinatario en función de su ancho de banda disponible y del contexto de UI.

Escalar a cientos de sesiones

Para despliegues a gran escala, la arquitectura está diseñada en torno al escalado horizontal con enrutamiento inteligente de sesiones.

Despliegue SFU multi-instancia. Varias instancias de SFU se ejecutan en distintas zonas de disponibilidad. Cada instancia registra su capacidad ante una capa de coordinación. Cuando se crea una nueva llamada, el sistema selecciona la instancia de SFU con mayor capacidad disponible. Los participantes de la misma llamada siempre se enrutan a la misma instancia de SFU para un enrutamiento óptimo de medios.

Paralelismo a nivel de worker. Cada proceso SFU lanza múltiples workers nativos, normalmente coincidiendo con el número de núcleos de CPU disponibles. Cada worker puede gestionar múltiples salas de llamada de forma independiente. Esto significa que un único servidor SFU con 16 núcleos puede gestionar eficientemente decenas de llamadas concurrentes, cada una con hasta 50 participantes.

Reenvío adaptativo al ancho de banda. Para llamadas con muchos participantes, varias optimizaciones se activan automáticamente. La detección de orador activo reduce el número de flujos de alta calidad que deben reenviarse. La selección de capa de simulcast se vuelve más agresiva, favoreciendo capas inferiores para los participantes no visibles. La caída a solo audio está disponible para participantes con ancho de banda severamente restringido.

Despliegue europeo multi-zona. La infraestructura de Mandraki se ejecuta en múltiples zonas de disponibilidad dentro de la UE sobre infraestructura hyperscale europea. Las instancias de SFU se despliegan cerca de los usuarios, reduciendo la latencia de ida y vuelta para los paquetes de medios. Todo el enrutamiento de medios permanece dentro de las fronteras europeas: ningún medio se relé jamás a través de infraestructura no europea.

Atravesado de NAT

La mayor fortaleza de WebRTC — la conectividad peer-to-peer directa — es también su mayor desafío. La mayoría de dispositivos están detrás de cortafuegos NAT (Network Address Translation) que impiden las conexiones entrantes directas. WebRTC utiliza ICE (Interactive Connectivity Establishment) para descubrir una ruta de red viable, probando conexión directa, conexión mediada por STUN y relé TURN en secuencia.

Mandraki opera servidores TURN dedicados junto a la infraestructura SFU. TURN actúa como relé de último recurso: cuando un participante no puede establecer una conexión directa con el SFU (debido a cortafuegos restrictivos, NAT simétrico o servidores proxy corporativos), los medios fluyen a través del servidor TURN. Esto añade algo de latencia pero garantiza la conectividad.

Los servidores TURN dan soporte a UDP y TCP, además de TLS para entornos que solo permiten tráfico HTTPS. Como todo lo demás en nuestra pila, se ejecutan íntegramente dentro de la UE.

Cifrado de extremo a extremo a escala

La arquitectura SFU se elige específicamente porque preserva la compatibilidad con el cifrado de extremo a extremo. Mediante WebRTC Encoded Transforms y el protocolo SFrame (RFC 9605), los frames de medios se cifran en el dispositivo del remitente antes de llegar al SFU. El SFU reenvía los frames cifrados a los destinatarios, que los descifran localmente.

El SFU nunca tiene acceso a los medios en texto plano. Enruta texto cifrado. Esto significa que incluso a escala — con decenas de participantes y múltiples llamadas concurrentes — las garantías de cifrado se mantienen. Ningún servidor de nuestra infraestructura ve ni procesa jamás audio o vídeo sin cifrar.

Esta es una elección arquitectónica fundamental. Muchas plataformas afirman ofrecer cifrado pero utilizan arquitecturas basadas en MCU que requieren decodificación en el servidor. El enfoque SFU de Mandraki significa que el cifrado no es solo una funcionalidad: es una garantía estructural.

Monitorización y fiabilidad

Los problemas de WebRTC son notoriamente difíciles de diagnosticar. Recopilamos telemetría del lado del cliente que incluye transiciones de estado de la conexión ICE, tipos de pares de candidatos seleccionados, estimaciones de tiempo de ida y vuelta, tasas de pérdida de paquetes y estimaciones de ancho de banda. Estas métricas se agrupan en lotes y se envían a nuestro endpoint de telemetría para su agregación.

En el servidor, el SFU registra eventos de transporte, ciclo de vida de productores y consumidores, y estimación de ancho de banda. Combinada con la telemetría del cliente, esto proporciona una visión integral de la calidad de la llamada que nos permite identificar y abordar incidencias de forma sistemática.

La comunicación en tiempo real a escala masiva es un reto de ingeniería profundo. Seguimos invirtiendo en la infraestructura de medios que hace que las llamadas de Mandraki sean fiables, de baja latencia y cifradas de extremo a extremo, todo ello dentro de una infraestructura europea soberana.