WebRTC (Web Real-Time Communication) es un estándar abierto para enviar audio, vídeo y datos en tiempo real directamente entre navegadores, sin instalar nada. Frente a otras opciones como WebSockets, HLS, DASH o RTMP, destaca por su latencia muy baja, por debajo de medio segundo, a cambio de exigir más de la red. En esta guía comparas WebRTC con los demás protocolos en tiempo real y ves cuándo conviene cada uno.
Así queda cada protocolo frente a WebRTC:
| Protocolo | Modelo | Uso ideal | Latencia | Escala | Cifrado |
|---|---|---|---|---|---|
| WebRTC | P2P o SFU, bidireccional | Videollamadas y colaboración en directo | Muy baja, por debajo de 0,5 s | Alta | Obligatorio (DTLS-SRTP) |
| WebSockets | Cliente-servidor persistente | Chat, notificaciones, datos en vivo | Baja | Alta | TLS (WSS) |
| HLS y DASH | HTTP por fragmentos | Streaming masivo unidireccional | Alta, de 5 a 30 s (2-3 s con LL-HLS) | Muy alta | HTTPS |
| RTMP | Ingesta (Adobe) | Enviar vídeo a un servidor desde un codificador | Media-alta | Media | Opcional (RTMPS) |
| SRT | Ingesta segura de baja latencia | Contribución e ingesta de vídeo | Baja, en torno a 1 s | Según el servidor | Cifrado AES |
| RTSP | Streaming de cámaras IP | Videovigilancia y cámaras | Baja-media | Limitada | Según la implementación |
| SIP / VoIP | Señalización de llamadas | Telefonía IP | Baja | Alta | SRTP o TLS, opcional |
Mantienen una conexión cliente-servidor persistente para enviar datos en los dos sentidos. Van de maravilla para chat, notificaciones o tableros en vivo, pero no están pensados para el flujo pesado de audio y vídeo en directo, que es justo lo de WebRTC. De hecho, muchas aplicaciones de WebRTC usan WebSockets para la señalización.
Son streaming por HTTP en fragmentos. Escalan muy bien a millones de espectadores y a bajo coste de servidor, así que mandan en la transmisión masiva de eventos o de televisión. La contrapartida es la latencia: de 5 a 30 segundos. El HLS de baja latencia (LL-HLS) reduce ese retardo a unos 2-3 segundos, sin llegar al tiempo real de WebRTC. Sirven para difundir, no para conversar.
Un protocolo veterano de Adobe. Hoy se usa sobre todo para la ingesta: enviar vídeo desde un codificador como OBS hacia una plataforma de streaming. Para la reproducción directa en el navegador ha quedado atrás, y su latencia es mayor que la de WebRTC. Aun así, SRT ha desplazado en buena parte a RTMP para la ingesta, con menor latencia y cifrado AES de serie. Y en el lado de WebRTC, WHIP (estandarizado como RFC 9725 en 2025) y WHEP le dan un camino estándar de ingesta y de entrega que antes le faltaba.
Pensado para el streaming de cámaras IP y la videovigilancia. No es nativo del navegador, así que llevarlo a la web suele exigir un paso intermedio. WebRTC, en cambio, entra directo en el navegador.
El estándar clásico de la telefonía IP. Se encarga de la señalización de las llamadas. Para hablar con la web necesita pasarelas (gateways), mientras que WebRTC integra la voz directamente en el navegador. Muchos sistemas combinan los dos.
Elige WebRTC cuando la interacción en tiempo real es el objetivo: videollamadas, clases en directo, atención al cliente por vídeo o colaboración. Es lo que buscas cuando el retardo se nota y molesta.
No es la mejor opción para difundir a decenas de miles de espectadores que solo miran: ahí HLS o DASH escalan más barato, aunque con más latencia. Y si solo tienes que llevar vídeo de un codificador a un servidor, RTMP o SRT hacen bien ese trabajo de ingesta. En producción lo habitual es combinar varios: WebRTC para la parte interactiva y HLS o RTMP para la difusión o la ingesta.
WebRTC no es magia y conviene conocer sus costes. Para atravesar NAT y cortafuegos depende de servidores TURN. El escalado a grupos grandes recae en tu SFU, y montarlo y sostenerlo tiene coste. Y no está pensado para la difusión masiva unidireccional: ahí HLS o DASH salen mejor. Por eso muchos equipos usan una plataforma que ya trae esa infraestructura hecha.
Construir sobre WebRTC desde cero es complejo: señalización, servidor de medios (SFU), TURN para las conexiones difíciles, escalado y seguridad. Digital Samba te da todo eso hecho a través de una API y un SDK, así que pones videollamadas de baja latencia dentro de tu producto sin construir la infraestructura tú mismo. Además, admite la ingesta de fuentes externas por WHIP.
Por debajo usa WebRTC, con el transporte cifrado (DTLS-SRTP) y cifrado de extremo a extremo opcional para lo más sensible. Y el vídeo se aloja en la Unión Europea, conforme al RGPD. Si quieres profundizar en la decisión de construir tu propia solución o integrar una prefabricada, la tienes en nuestra guía sobre construir o integrar videoconferencia.
Es un estándar abierto (Web Real-Time Communication) que permite enviar audio, vídeo y datos en tiempo real directamente entre navegadores, sin instalar complementos, mediante las API de JavaScript.
Depende. Para interacción en directo con baja latencia, WebRTC. Para enviar vídeo de un codificador a un servidor (ingesta), RTMP sigue siendo habitual, aunque SRT gana terreno por su menor latencia y su cifrado de serie. Muchas cadenas de producción combinan los dos.
Sí, apoyándose en un servidor de medios (SFU). Para audiencias enormes que solo miran, HLS o DASH suelen salir más baratos, a cambio de más latencia.
Sí: cifra el transporte por defecto con DTLS y SRTP, y no es opcional. Algunas plataformas añaden además cifrado de extremo a extremo para el contenido.
WebSocket mantiene un canal de datos cliente-servidor, ideal para chat o notificaciones. WebRTC está hecho para el flujo de audio y vídeo en tiempo real entre pares. A menudo se usan juntos: WebSocket para la señalización de WebRTC.
Sí, en los navegadores modernos (Chrome, Firefox, Safari y Edge) y también en aplicaciones nativas mediante bibliotecas de WebRTC.