La señalización WebRTC es el proceso por el que dos navegadores o dispositivos intercambian información de control (metadatos) para coordinar y abrir una conexión directa punto a punto (P2P). Sin ella, dos clientes no pueden encontrarse ni ponerse de acuerdo sobre cómo conectarse.
En esta guía verás qué es la señalización, qué se intercambia durante el proceso, cómo se establece la conexión paso a paso, el papel de los servidores STUN y TURN, qué tecnologías se usan y cómo proteger el canal.
Índice de contenidos
WebRTC es un proyecto de código abierto (impulsado por Google y estandarizado por el W3C y el IETF) sobre el que se construye buena parte de las aplicaciones punto a punto de internet. Permite comunicaciones de audio, vídeo y datos en tiempo real directamente entre navegadores o dispositivos.
En una aplicación punto a punto, los equipos de los usuarios se comunican directamente entre sí en lugar de pasar por un servidor central. Eso ahorra muchos recursos de infraestructura y es una forma eficiente de llevar vídeo y voz en tiempo real a tus aplicaciones. Ahora bien, los servidores centrales sí desempeñan un papel: las conexiones que crea WebRTC son punto a punto, pero montarlas necesita un paso previo de coordinación. Ahí entra la señalización.
Dicho en pocas palabras, la señalización es cómo unos equipos descubren a otros para conectarse. WebRTC deja en manos del desarrollador qué conexiones se establecen entre pares, así que ese «quién se conecta con quién» ocurre en el servidor de señalización, como parte de la aplicación.
Piensa en el servidor de señalización como un celestino: empareja a los clientes, pero no participa en la conversación. Es importante entenderlo: el servidor de señalización solo gestiona metadatos, es decir, datos sobre los clientes. No toca los flujos de audio y vídeo, que van directamente entre los pares.
El servidor de señalización se ocupa de información como:
Son las cosas que dos clientes necesitan saber antes de conectarse. Siguiendo con la analogía, es como preparar una cita a ciegas.
Durante la señalización viajan sobre todo dos tipos de información:
Puedes ver estos conceptos con más detalle en nuestra guía sobre ICE y SDP en WebRTC.
El proceso es sencillo de contar, aunque por debajo pasen bastantes cosas.
Un cliente que quiere usar una aplicación WebRTC envía una oferta al servidor de señalización de esa aplicación. Da igual que el servidor esté hecho en Node.js, PHP o cualquier otra tecnología: la oferta es, en esencia, información sobre ese cliente y cómo conectarse a él. Esa oferta usa el Session Description Protocol (SDP).
El servidor de señalización empareja a dos o más clientes repartiendo esos mensajes SDP. Cuando un par recibe la oferta inicial, la guarda, genera su respuesta (answer) con su propia información y la devuelve a través del servidor, que la reparte al cliente inicial (o a todos los que quieran conectarse).
Junto con las ofertas y respuestas SDP, los pares intercambian también sus candidatos ICE a través del servidor de señalización, y los van enviando según los descubren (lo que se conoce como trickle ICE).
Cuando cada cliente tiene la información de los demás, pueden empezar a conectarse punto a punto, sin pasar ya por el servidor de señalización. A partir de ahí eligen la mejor ruta para conectarse; de eso se encargan STUN, TURN e ICE, que vemos a continuación.
En el mundo real, muchos equipos están detrás de firewalls o de NAT (traducción de direcciones de red), que impiden exponer su IP pública. Eso es un problema para una aplicación punto a punto: internet no puede comunicarse directamente con ese equipo. Para resolverlo entran en juego STUN, TURN e ICE.
ICE es, en esencia, «cuál es la mejor forma de que estos clientes se conecten». Reúne todas las rutas posibles (los candidatos ICE) y elige la más eficiente.
STUN es un servicio sencillo que le devuelve al cliente su IP pública. Los clientes lo necesitan porque, al estar detrás de NAT, no saben cuál es su dirección pública, y sin esa dirección no pueden comunicarse entre sí. Lo que debes saber de STUN:
TURN es el método de respaldo cuando STUN no consigue una conexión directa (por ejemplo, con NAT simétrica). Son servidores que reenvían los flujos de datos entre los pares, como un relé. Lo que debes saber de TURN:
Por eso TURN se reserva como último recurso: es preferible a no tener conexión, pero se prefiere evitarlo. ICE se encarga de mirar todas las rutas y quedarse con la mejor.
Un detalle importante: WebRTC no estandariza la señalización. El estándar no impone ningún protocolo ni servidor concreto, así que el desarrollador elige cómo implementarla.
Lo habitual es usar protocolos de mensajería bidireccional combinados con un servidor intermedio. Los más comunes son:
En la práctica, WebSockets es la opción por defecto: ofrece comunicación bidireccional (full-duplex) y baja latencia, justo lo que pide el ida y vuelta de la señalización. SSE sirve cuando basta con enviar del servidor al cliente; MQTT encaja en entornos con muchos dispositivos; y SIP es habitual si te integras con telefonía o VoIP.
Como por la señalización viajan metadatos sensibles, el canal debe estar protegido. Dos medidas básicas:
Si no proteges este canal, alguien podría colarse en la negociación o hacerse pasar por otro participante. Tienes más detalle en nuestra guía de seguridad en WebRTC.
| Ventajas | Limitaciones |
|---|---|
| Permite conexiones punto a punto | Compleja de implementar a mano |
| Reduce la carga y el coste de los servidores | Hay que lidiar con NAT y firewalls |
| Estándar abierto con soporte en navegadores | Necesita servidores STUN/TURN de respaldo |
| Muy personalizable | La seguridad y la privacidad corren de tu cuenta |
WebRTC es complicado de usar: funciona como una capa de compatibilidad entre navegadores y deja en tus manos la señalización, los servidores STUN/TURN, el escalado y la seguridad.
Por eso la tendencia es usar plataformas CPaaS (comunicaciones como servicio) que abstraen toda esa dificultad tras una API. Usar una de estas API te ahorra infraestructura, problemas de seguridad y mucho trabajo de desarrollo, y suele darte funciones ya depuradas de vídeo y voz en tiempo real.
Digital Samba es una de esas opciones. Ofrece una API y un SDK de videoconferencia que embebes en tu aplicación, con la señalización y los servidores STUN/TURN ya resueltos. Funciona sobre infraestructura europea y con cumplimiento del RGPD, así que no tienes que montar ni mantener la señalización por tu cuenta.
Sí. Aunque WebRTC permite la comunicación punto a punto, siempre se necesita un servidor de señalización para establecer la conexión inicial entre los pares.
STUN ayuda a los clientes a descubrir su dirección IP pública; TURN reenvía el tráfico cuando no es posible una conexión directa. STUN es barato y ligero; TURN es más caro porque transporta los flujos de datos.
Sí, con herramientas como Node.js y librerías de WebSockets. Hay muchos tutoriales y ejemplos de código abierto disponibles, aunque tendrás que encargarte tú de la seguridad y del escalado.
Si el intercambio de señalización no se completa, los clientes no pueden conectarse: no se comparte vídeo ni datos. Por eso conviene un canal fiable y seguro.
Es la fase de negociación en la que los pares intercambian sus ofertas y respuestas SDP (y sus candidatos ICE) a través del servidor de señalización para establecer la conexión.
La señalización es el proceso invisible que hace posibles las conexiones punto a punto de WebRTC: coordina a los clientes, intercambia los metadatos (SDP y candidatos ICE) y, con la ayuda de STUN, TURN e ICE, atraviesa NAT y firewalls. Montarla desde cero es posible, pero complicado, y la seguridad queda de tu parte.
Si quieres añadir vídeo a tu aplicación sin construir la señalización desde cero, echa un vistazo a la API de vídeo de Digital Samba o habla con el equipo para ver cómo encaja en tu proyecto.