WebRTC, SFU y códecs de voz explicados
Cómo WebRTC transporta el audio, cómo Opus comprime la voz y cuándo el vídeo en grupo necesita un SFU. Guía para desarrolladores con la arquitectura de Voxal y RFC.
WebRTC mueve audio y vídeo entre navegadores, un códec como Opus comprime la voz para que quepa en la red, y una Selective Forwarding Unit (SFU) es un servidor que reenvía el vídeo de cada participante a todos los demás en llamadas más grandes. Estas tres piezas explican la mayor parte de lo que ocurre entre un micrófono y un altavoz remoto.
Esta guía está pensada para desarrolladores y lectores curiosos que quieren conocer la mecánica: señalización, ICE, STUN y TURN, RTP, Opus, y el equilibrio entre una malla peer-to-peer y un SFU. Termina explicando cómo Voxal las combina: la voz sigue siendo peer-to-peer, mientras que la cámara y la pantalla compartida pueden usar un SFU. Si solo quieres entender el concepto, empieza por qué es el chat de voz peer-to-peer.
1. ¿Qué es WebRTC?
WebRTC es un conjunto de estándares y API de navegador para la comunicación de audio, vídeo y datos en tiempo real.
Permite que las aplicaciones establezcan conexiones multimedia entre dispositivos compatibles sin obligar a los desarrolladores a implementar desde cero cada mecanismo de transporte y seguridad.
WebRTC no es un único protocolo. Varios componentes trabajan juntos.
Señalización
Antes de que dos dispositivos puedan establecer una conexión multimedia, necesitan intercambiar información sobre la sesión y sus capacidades de conexión.
Este proceso se llama señalización. Cada aplicación elige su propio mecanismo de señalización; WebRTC no prescribe un servidor ni un protocolo de señalización universal.
Voxal usa la señalización para coordinar la pertenencia a las salas y el establecimiento de conexiones. Su ruta de señalización está separada de la ruta multimedia.
ICE, STUN y TURN
Los dispositivos suelen estar detrás de routers, cortafuegos o traducción de direcciones de red (NAT). Por eso, encontrar una ruta de conexión viable puede ser más complicado que conectar dos direcciones IP públicas.
WebRTC utiliza Interactive Connectivity Establishment (ICE) para reunir y probar las posibles rutas de conexión.
- STUN ayuda a un dispositivo a descubrir cómo se ve desde la red pública.
- TURN ofrece una ruta de retransmisión cuando no se puede establecer una conexión directa adecuada.
Un relé TURN reenvía tráfico multimedia cifrado. No es lo mismo que un SFU, que termina las conexiones multimedia y reenvía selectivamente los flujos.
Una conexión directa suele ser preferible, pero un relé puede ser esencial para lograr la conectividad.
RTP y transporte multimedia seguro
Los medios en tiempo real suelen transportarse mediante el Real-time Transport Protocol (RTP), junto con RTCP para el control y los informes.
WebRTC usa RTP seguro (SRTP) para proteger los medios. La capa de transporte ayuda a entregar los paquetes, mientras que el códec determina cómo se representa el audio o el vídeo.
Son responsabilidades distintas: un códec no establece una conexión de red, y una conexión de red no determina cómo se comprime el sonido.
2. ¿Qué es un códec de voz?
Un códec codifica y decodifica medios. En la comunicación por voz, su función es representar el habla de forma eficiente, conservando la inteligibilidad y una calidad de audio aceptable.
Sin compresión, transmitir audio sin procesar puede consumir bastante más ancho de banda del que necesita una aplicación de voz.
Un códec equilibra varios factores:
- Calidad de audio e inteligibilidad del habla.
- Tasa de bits y uso de ancho de banda.
- Complejidad de codificación y decodificación.
- Retardo y duración de las tramas.
- Comportamiento ante condiciones de red cambiantes.
No existe un mejor códec para todas las aplicaciones. La transmisión de música, las llamadas telefónicas, el chat de juegos y las conversaciones grupales en tiempo real tienen prioridades distintas.
Por qué Opus se usa tanto
Opus es un códec de audio interactivo diseñado para aplicaciones como voz sobre IP, videoconferencias y chat dentro de juegos.
Admite un amplio rango de tasas de bits, frecuencias de muestreo y duraciones de trama. Esta flexibilidad lo hace adecuado tanto para el habla como para aplicaciones de audio más exigentes.
Opus es además un códec de audio de implementación obligatoria para los extremos WebRTC según los requisitos de códecs de audio de WebRTC.
Eso no significa que toda conexión WebRTC use siempre Opus. La selección real del códec depende de las capacidades negociadas por los extremos participantes.
En Voxal, el flujo de audio WebRTC del navegador usa Opus por defecto en la arquitectura documentada. El navegador se encarga de gran parte del trabajo de codificación, transporte y decodificación.
En una aplicación de voz en tiempo real, el códec es solo una parte de la experiencia. También importan la calidad del micrófono, el procesamiento de audio, la pérdida de paquetes, la latencia de red, el búfer de jitter y la reproducción en el dispositivo.
3. ¿Qué es un SFU?
SFU significa Selective Forwarding Unit.
Un SFU es un servidor multimedia que se usa habitualmente en las videollamadas en grupo. En lugar de exigir que cada participante envíe un flujo de vídeo distinto directamente a todos los demás, cada participante puede enviar sus medios al SFU, que reenvía los flujos adecuados al resto.
Imagina una sala con seis personas, cada una enviando un flujo de cámara.
En una malla peer-to-peer completa, cada participante puede necesitar subir su vídeo a otros cinco. En una topología con reenvío por servidor, cada participante puede enviar un flujo al SFU, que se encarga de la distribución.
Esto puede reducir de forma significativa el número de flujos de vídeo salientes independientes que debe mantener un participante.
¿Qué hace realmente un SFU?
Un SFU normalmente recibe flujos multimedia codificados y los reenvía de forma selectiva. Según la implementación y las funciones negociadas, puede elegir qué flujos o capas de calidad enviar a cada receptor.
Por ejemplo, un participante que ve una miniatura pequeña no necesita la misma calidad de vídeo que alguien que muestra a un ponente a pantalla completa.
Un SFU puede ayudar a gestionar estos requisitos diferentes sin que cada emisor tenga que transmitir un flujo separado a cada destinatario.
Sin embargo, un SFU no es gratis. Introduce infraestructura, ancho de banda de servidor, costes operativos y un componente más en la ruta multimedia.
Un SFU también tiene un modelo de privacidad distinto al de un relé TURN. Como un SFU termina el transporte multimedia y reenvía los medios de forma selectiva, técnicamente puede acceder a los medios que recibe. El cifrado entre un participante y un SFU no proporciona, por sí solo, confidencialidad de extremo a extremo frente a ese SFU.
4. Malla peer-to-peer frente a SFU
Las dos arquitecturas resuelven problemas relacionados pero distintos.
Malla peer-to-peer
Cada participante establece conexiones multimedia con los demás participantes.
Ventajas:
- Son posibles rutas multimedia directas.
- No hace falta un servidor multimedia central para redistribuir los medios.
- Las salas pequeñas pueden funcionar sin un servicio de reenvío de medios.
Inconvenientes:
- Cada emisor puede necesitar subir un flujo distinto a cada uno de los demás participantes.
- El número de conexiones multimedia crece con el tamaño de la sala.
- El ancho de banda de subida y la gestión de conexiones pueden convertirse en factores limitantes.
Distribución basada en SFU
Cada participante envía sus medios a un servicio central de reenvío, que los distribuye al resto de participantes.
Ventajas:
- Distribución más eficiente en muchos escenarios de vídeo en grupo.
- Menos necesidad de que cada emisor suba copias separadas a cada destinatario.
- Más control sobre qué flujos de vídeo y capas de calidad reciben los receptores.
Inconvenientes:
- Infraestructura de servidor adicional y costes de ancho de banda.
- Un intermediario entra en la ruta multimedia.
- El modelo de privacidad y confianza difiere de la comunicación peer-to-peer directa.
La clave está en no dar por hecho que debe usarse la misma topología para todos los tipos de medios. El audio y el vídeo tienen patrones de tráfico y requisitos distintos.
5. Por qué Voxal mantiene la voz peer-to-peer pero puede usar un SFU para el vídeo
Voxal separa el audio de voz del vídeo de cámara y de pantalla compartida.
El audio de voz siempre sigue siendo peer-to-peer. Nunca pasa por el SFU de vídeo opcional.
Es una decisión de arquitectura deliberada: la voz es la función de comunicación central, y Voxal no usa el SFU como servicio central de distribución de audio.
El vídeo de cámara y de pantalla compartida es diferente. En salas más grandes, una malla peer-to-peer completa puede exigir que cada participante suba varios flujos de vídeo. Eso resulta cada vez más exigente a medida que crece el número de participantes.
Por eso Voxal puede usar el SFU de Cloudflare Realtime para el vídeo y la pantalla compartida cuando la preferencia de enrutamiento configurada lo permite y la sala supera los límites prácticos de la malla.
La preferencia de enrutamiento importa:
- Allow relay for large rooms: Voxal puede usar el SFU cuando la sala crece más allá de una topología de vídeo peer-to-peer cómoda.
- Prefer direct: Voxal prueba primero el peer-to-peer y pregunta antes de permitir un relé cuando la malla deja de ser adecuada.
- Direct only: el vídeo y la pantalla compartida nunca usan el SFU, aunque una sala grande tenga dificultades para establecer todas las conexiones directas.
Estos ajustes afectan al vídeo y a la pantalla compartida, no al audio de voz.
¿Por qué no enrutarlo todo por el mismo servidor?
Porque la mejor topología depende del tráfico que se transporta.
Un flujo de voz es, en general, mucho más pequeño que un flujo de cámara. Enviar la voz por un servicio central de reenvío introduciría un equilibrio distinto de infraestructura y privacidad sin ser necesario para la arquitectura de voz elegida por Voxal.
El vídeo tiene un perfil de ancho de banda más exigente y puede beneficiarse mucho de la distribución asistida por servidor a medida que crece el grupo.
Separar ambos permite a Voxal conservar su modelo de voz peer-to-peer y, a la vez, ofrecer una opción más escalable para el vídeo en grupo.
6. Qué significa esto para la privacidad
A veces los términos de redes se usan como si garantizaran automáticamente un nivel concreto de privacidad. No es así.
El audio peer-to-peer significa que los medios de voz no pasan por un servidor multimedia central, pero los servidores de señalización pueden seguir coordinando las conexiones y procesando los metadatos asociados.
Un relé TURN reenvía medios cifrados sin decodificarlos. Un SFU, en cambio, termina el transporte multimedia para reenviar los flujos de forma selectiva y técnicamente puede acceder al vídeo que recibe.
Por eso es importante la distinción que hace Voxal:
- La voz sigue siendo peer-to-peer, con la opción de usar un relé TURN cifrado.
- El vídeo de cámara y de pantalla compartida puede usar un SFU en salas más grandes, según la preferencia de enrutamiento.
- El procesamiento local de los fondos virtuales ocurre en el dispositivo del emisor, pero eso por sí solo no significa que todas las conexiones de vídeo sean directas.
Entender la ruta real de los medios es más útil que describir una aplicación simplemente como «sin servidor».
7. Todo junto
Una aplicación de comunicación en tiempo real combina varias capas independientes:
- La señalización coordina a los participantes y la configuración de la conexión.
- ICE, STUN y TURN ayudan a establecer una ruta de red viable.
- WebRTC y el transporte RTP seguro transportan los medios en tiempo real.
- Un códec como Opus representa el audio de forma eficiente.
- La topología de red determina si los medios fluyen directamente entre pares o a través de un servicio de reenvío.
El diseño de Voxal aplica estas decisiones por separado a la voz y al vídeo. El resultado es una arquitectura centrada en la voz, en la que el audio sigue siendo peer-to-peer, mientras que el vídeo y la pantalla compartida pueden usar un reenvío opcional asistido por servidor cuando las salas más grandes lo necesitan.
Estas distinciones son importantes al diseñar cualquier sistema de comunicación en tiempo real. El objetivo no es simplemente minimizar los servidores o maximizar las conexiones directas, sino hacer concesiones deliberadas entre latencia, ancho de banda, fiabilidad, escalabilidad y privacidad.
Prueba Voxal
Voxal combina chat de voz peer-to-peer, push-to-talk (pulsar para hablar), modo manos libres, supresión de ruido y vídeo y pantalla compartida opcionales.
Prueba Voxal en tu navegador o explora la implementación en el repositorio de código abierto de Voxal.
Lecturas relacionadas: ¿Qué es el chat de voz peer-to-peer? · ¿Qué es el push-to-talk? Una guía práctica · Documentación de Voxal sobre el enrutamiento de vídeo
