¿Qué es la señalización en WebRTC y cómo funciona?
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
- Qué es WebRTC
- Qué es la señalización en WebRTC
- Qué se intercambia durante la señalización
- Cómo se establece la conexión paso a paso
- STUN, TURN e ICE: atravesar NAT y firewalls
- Qué tecnologías se usan para la señalización
- Seguridad del canal de señalización
- Ventajas y limitaciones de la señalización WebRTC nativa
- ¿Hay una forma más fácil?
- Preguntas frecuentes
Qué es WebRTC
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.
Qué es la señalización en WebRTC
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:
- Configuración del cliente. ¿Qué resolución tiene disponible? ¿Cómo accede la aplicación a su micrófono y su cámara? ¿Qué códecs puede usar para reproducir y transmitir?
- Información de red. ¿Cuál es la dirección de red del cliente y cómo se le conecta?
- Información de sesión. ¿Qué datos se pueden transmitir? ¿Cuándo y cómo termina la sesión? ¿Qué pasa si alguien se desconecta?
Son las cosas que dos clientes necesitan saber antes de conectarse. Siguiendo con la analogía, es como preparar una cita a ciegas.
Qué se intercambia durante la señalización
Durante la señalización viajan sobre todo dos tipos de información:
- SDP (Session Description Protocol). Mensajes con los códecs, los formatos, las resoluciones y las capacidades de audio y vídeo de cada participante. Se intercambian en forma de oferta (offer) y respuesta (answer).
- Candidatos ICE (Interactive Connectivity Establishment). Las direcciones IP y los puertos candidatos que cada cliente descubre (con ayuda de servidores STUN o TURN) para intentar atravesar firewalls y NAT.
Puedes ver estos conceptos con más detalle en nuestra guía sobre ICE y SDP en WebRTC.
Cómo se establece la conexión paso a paso
El proceso es sencillo de contar, aunque por debajo pasen bastantes cosas.
Empieza con una oferta
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).
Sigue con un intercambio
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).
Termina con una conexión
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.
STUN, TURN e ICE: atravesar NAT y firewalls
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:
- Funciona con NAT de cono completo, de cono restringido y de cono restringido por puerto.
- No funciona con NAT simétrica.
- Es barato de usar y mantener.
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:
- Funciona con NAT simétrica.
- Reenvía los paquetes entre dispositivos (actúa de relé).
- Es caro de usar y mantener, y añade algo de latencia.
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.
Qué tecnologías se usan para la señalización
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:
- WebSockets, la opción más extendida para el intercambio en tiempo real.
- SSE (Server-Sent Events), para flujos de servidor a cliente.
- MQTT, ligero y pensado para entornos con muchos dispositivos.
- SIP, clásico en telefonía y voz sobre IP.
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.
Seguridad del canal de señalización
Como por la señalización viajan metadatos sensibles, el canal debe estar protegido. Dos medidas básicas:
- Cifrado con TLS. Protege el intercambio de mensajes de control entre el cliente y el servidor de señalización.
- Autenticación fuerte. Usa tokens o un sistema como OAuth para evitar suplantaciones de identidad o secuestros de sesión.
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 y limitaciones de la señalización WebRTC nativa
| 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 |
¿Hay una forma más fácil de crear aplicaciones punto a punto?
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.
Preguntas frecuentes
¿Siempre hace falta un servidor de señalización en WebRTC?
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.
¿Qué diferencia hay entre STUN y TURN en WebRTC?
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.
¿Puedo construir mi propio servidor de señalización?
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.
¿Qué pasa si falla la señalización en WebRTC?
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.
¿Qué es el handshake (la negociación) de WebRTC?
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.
Lo que hay que recordar
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.
