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

WHIP (WebRTC-HTTP Ingestion Protocol) y WHEP (WebRTC-HTTP Egress Protocol) son dos protocolos estandarizados por la IETF que resuelven el problema más grande que tenía WebRTC para streaming: la falta de un estándar de señalización.

Para entender por qué importan, hay que entender el problema. WebRTC fue diseñado para videollamadas peer-to-peer. Funciona extraordinariamente bien para eso. Pero cuando intentas usarlo para streaming profesional (un encoder enviando video a un servidor que lo distribuye a miles), te encuentras con un obstáculo: WebRTC define cómo transportar el video, pero no define cómo negociar la conexión entre encoder y servidor.

Cada plataforma inventaba su propio método de señalización. Si querías enviar WebRTC desde OBS a tu servidor, necesitabas un plugin específico para ESE servidor. No había interoperabilidad. WHIP y WHEP solucionan exactamente eso:

• 📤 WHIP (Ingestion): Estandariza cómo un encoder envía video a un servidor WebRTC. Un simple POST HTTP con la oferta SDP, el servidor responde con la respuesta SDP, y la conexión WebRTC se establece. Así de simple
• 📥 WHEP (Egress): Estandariza cómo un reproductor solicita y recibe video de un servidor WebRTC. Mismo principio: un POST HTTP y la conexión se establece

📌 Analogía: RTMP fue el "idioma universal" que todos los encoders y servidores hablaban para streaming. Cuando RTMP empezó a quedar obsoleto, WebRTC no tenía un equivalente. WHIP y WHEP son ese equivalente — pero para la era de ultra baja latencia.

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); RTMP está atado a H.264
• 🔥 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.

💡 Dato clave: WHEP todavía está en fase de draft en la IETF (no es RFC final como WHIP), pero ya tiene implementaciones funcionales en OvenMediaEngine, Cloudflare y otros servidores. La adopción va en aumento.

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

⚡ XtreamCast y WHIP: XtreamCast soporta ingesta RTMP y SRT. Combinado con el addon de WebRTC Ultra Baja Latencia ($20/mes), tu stream se distribuye con latencia sub-segundo. Ideal para quienes buscan la mejor latencia sin complicaciones de configuración.

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.