WHIP y WHEP: Los Protocolos WebRTC que Están Reemplazando a RTMP en Streaming

WHIP define una forma de iniciar ingesta WebRTC mediante HTTP y fue publicado como RFC 9725. WHEP aborda la reproducción y, a 4 de septiembre de 2026, figura como Internet-Draft en curso, no como RFC publicado.

Antes de conectar un encoder o un player, verifica qué protocolo de señalización implementa el servidor. Ofrecer WebRTC no implica soportar WHIP o WHEP.

XtreamCast recibe señal por RTMP/SRT y su reproducción WebRTC actual utiliza señalización WebSocket con su player compatible. Esta guía explica los protocolos de la industria; no ofrece un endpoint WHEP de XtreamCast.

WHIP fue ratificado como RFC 9725 en marzo de 2025, convirtiéndose en un estándar oficial de internet. El flujo es elegantemente simple:

Flujo de conexión WHIP

1. El encoder genera una oferta SDP (Session Description Protocol) que describe los codecs, resolución y parámetros de media que quiere usar
2. Envía esa oferta como POST HTTP al endpoint WHIP del servidor, típicamente una URL como https://servidor/whip/stream-key
3. El servidor responde con HTTP 201 y la respuesta SDP, negociando los parámetros de conexión
4. Se establece la conexión WebRTC y el video fluye con latencia sub-segundo

¿Ves la diferencia con la señalización WebRTC tradicional? No hay WebSocket, no hay servidor de señalización separado, no hay intercambio de candidatos ICE manual. Es un HTTP POST y listo.

Qué software ya soporta WHIP

Software/Hardware	Soporte WHIP	Notas
OBS Studio 30+	Nativo	Seleccionar "WHIP" en servicio de streaming
FFmpeg 7.0+	Nativo	Via -f whip
GStreamer	Plugin	whipsink / whipsrc
Larix Broadcaster	Nativo	App móvil iOS/Android
OvenMediaEngine	Nativo	Servidor open source
Cloudflare Stream	Nativo	CDN/plataforma
Dolby.io (Millicast)	Nativo	CDN WebRTC global

Ventajas de WHIP sobre RTMP

• Latencia sub-segundo: RTMP tiene latencia de 3-5 segundos solo en la ingesta; WHIP hereda la latencia WebRTC (~200-500ms)
• Cifrado nativo: DTLS/SRTP siempre activo; RTMP no tiene cifrado integrado
• Codecs modernos: VP8, VP9, H.264, H.265 (según implementación); el soporte de codecs depende de RTMP clásico o Enhanced RTMP y de ambos extremos
• Sin Flash: RTMP fue diseñado para Flash Player, que murió en 2020
• Estándar abierto: RFC oficial de la IETF, no propiedad de Adobe

WHEP complementa a WHIP del lado del espectador. Mientras WHIP estandariza la ingesta, WHEP estandariza la distribución. El flujo es similar:

1. El reproductor envía un POST HTTP al endpoint WHEP con su oferta SDP
2. El servidor responde con la respuesta SDP y los parámetros de conexión
3. La conexión WebRTC se establece y el video fluye al reproductor

¿Por qué WHEP es importante?

Antes de WHEP, cada plataforma que ofrecía playback WebRTC tenía su propio SDK JavaScript propietario. Si querías reproducir un stream WebRTC de Millicast, necesitabas su SDK. Si querías uno de Ant Media, otro SDK. No había interoperabilidad.

Con WHEP, cualquier reproductor compatible puede conectarse a cualquier servidor compatible. Es como lo que HLS hizo por los reproductores HTTP: un estándar que todos hablan.

El pipeline completo WHIP → WHEP

Encoder (OBS/Larix/FFmpeg)
    │
    ├── WHIP POST (SDP Offer) ──→ Media Server (OME/Janus/SRS)
    │                                     │
    │                                     ├── Transcoding (opcional)
    │                                     ├── Grabación (opcional)
    │                                     │
    ├─── WHEP ──→ Espectador WebRTC (sub-segundo)
    ├─── HLS ───→ Espectador HLS (3-30 seg)
    └─── DASH ──→ Espectador DASH (3-30 seg)

La belleza de este pipeline es que puedes ingestar en WebRTC via WHIP y distribuir simultáneamente en WebRTC (via WHEP) para quienes necesitan ultra baja latencia, y en HLS/DASH para el público masivo que no la necesita.

OBS Studio incorporó soporte nativo para WHIP a partir de la versión 30. Aquí te explicamos cómo configurarlo:

Configuración en OBS Studio

1. Abre Ajustes → Emisión
2. En "Servicio", selecciona "WHIP"
3. En "Servidor", ingresa la URL del endpoint WHIP de tu media server:

   https://tu-servidor.com/whip/tu-stream-key

4. Si el servidor requiere autenticación, agrega el Bearer Token en el campo correspondiente
5. Haz clic en "Iniciar transmisión"

Ajustes de encoding recomendados para WHIP

Parámetro	Recomendación	Por qué
Codec de video	H.264 (más compatible)	VP8/VP9 también funcionan pero H.264 tiene soporte universal
Bitrate	2,500-6,000 kbps	WebRTC adapta automáticamente, pero define un techo razonable
Resolución	1080p (1920x1080)	El ABR WebRTC ajustará si la red no alcanza
Keyframe	1 segundo	Clave para que nuevos espectadores se conecten rápido
Preset	veryfast / Max Performance	Priorizar velocidad sobre eficiencia de compresión
Codec de audio	Opus	Codec nativo de WebRTC, mejor latencia que AAC

Latencia esperada con WHIP vs RTMP

Método de ingesta	Latencia de ingesta	Latencia total al espectador
RTMP → HLS	1-3 seg	15-30 seg
RTMP → LL-HLS	1-3 seg	3-6 seg
SRT → HLS	0.5-1 seg	10-25 seg
WHIP → WHEP	0.1-0.3 seg	0.3-0.8 seg

LL-HLS en XtreamCast: su disponibilidad requiere un origen preparado y habilitación del canal. Confirma con soporte la configuración y la compatibilidad antes de presupuestarlo. No está disponible como compra directa general en el checkout y no debe combinarse en el mismo canal con WebRTC.

La respuesta corta: depende de tu caso de uso. La respuesta larga:

Cuándo WHIP/WHEP es la mejor opción

• Necesitas latencia sub-segundo (subastas, apuestas, Q&A)
• Tus espectadores usan navegadores modernos
• Necesitas cifrado end-to-end obligatorio
• Quieres usar codecs modernos como VP9 o AV1
• Tu servidor soporta WHIP (OvenMediaEngine, Janus, Cloudflare)

Cuándo RTMP sigue siendo válido

• Tu infraestructura está basada en RTMP y funciona bien
• Usas restream a YouTube/Facebook/Twitch (todos esperan RTMP)
• No necesitas latencia sub-segundo
• Tu hardware encoder solo soporta RTMP
• Distribuyes en HLS de todas formas (la latencia de ingesta no es el cuello de botella)

Comparativa directa

Aspecto	RTMP	WHIP/WHEP
Estándar	Propietario (Adobe, 2002)	IETF RFC 9725 (2025)
Latencia ingesta	1-3 segundos	100-300 ms
Cifrado	Opcional (RTMPS)	Siempre (DTLS/SRTP)
Codecs video	H.264	H.264, VP8, VP9, H.265*
Codec audio	AAC, MP3	Opus (menor latencia)
Soporte en OBS	Desde siempre	Desde v30
Soporte redes sociales	Universal	Limitado
Madurez	20+ años	~1 año como RFC

Recomendación práctica: Si transmites a redes sociales (YouTube, Facebook, Twitch), sigue usando RTMP: es lo que esperan. Si transmites a tu propia plataforma o a un media server que controlas y necesitas baja latencia, prueba WHIP. No es "migrar". Es agregar una opción más eficiente a tu toolkit.

El futuro: Media over QUIC (MoQ) es el siguiente paso en la evolución. Construido sobre el protocolo QUIC (el mismo que usa HTTP/3), promete combinar la baja latencia de WebRTC con la escalabilidad de HLS. Aún está en desarrollo, pero vale la pena tenerlo en el radar.