Media over QUIC — MoQ — es el protocolo emergente de streaming más comentado de 2025-2026. Las publicaciones en blogs se multiplican, las charlas en conferencias se acumulan y los proveedores de CDN compiten por anunciar su soporte. Si trabajas en streaming en vivo, probablemente te hayan preguntado: ¿deberíamos pasarnos a MoQ?
La respuesta corta, para la mayoría de productos en producción hoy, es no — todavía no. Pero vale la pena entender MoQ, porque los problemas que resuelve son reales, y el plazo para que esté listo para producción ya se mide en trimestres, no en años.
Este artículo explica qué es realmente MoQ, en qué punto se encuentra a marzo de 2026, qué cambia respecto a HLS, WebRTC y SRT — y si tendría sentido para dos productos reales que hemos desplegado: WeSpeakSports (comentarios de audio en vivo de aficionados sobre WebRTC) y DJing Stream (audio de DJ con calidad broadcast sobre SRT y HLS Lossless).
Qué es realmente MoQ
MoQ significa Media over QUIC. Es un esfuerzo del grupo de trabajo del IETF iniciado en 2022, para definir un nuevo protocolo de entrega de medios construido sobre QUIC (la capa de transporte detrás de HTTP/3).
La especificación principal de transporte, draft-ietf-moq-transport, alcanzó la versión 17 en marzo de 2026. Una especificación de formato de streaming (draft-ietf-moq-msf) también está en desarrollo, junto con borradores complementarios para empaquetado CMAF y compresión de cabeceras. Ninguno de estos son RFC finalizados todavía.
En esencia, MoQ es un protocolo publish/subscribe. Un publicador envía objetos de medios con nombre (tramas de audio, tramas de vídeo, metadatos) a relays, y los suscriptores los reciben suscribiéndose a pistas con nombre. Esto es fundamentalmente diferente tanto de HLS (petición/respuesta HTTP para segmentos) como de WebRTC (negociación de sesión peer-to-peer con SDP/ICE).
MoQ se ejecuta sobre flujos QUIC y datagramas, ya sea de forma nativa o mediante WebTransport (la API del navegador para QUIC). Esto le da acceso a las funciones de multiplexación, priorización y fiabilidad parcial de QUIC — lo que significa que el protocolo puede, por diseño, descartar una trama de vídeo retrasada en lugar de detener todo el flujo esperando la retransmisión.
Qué pretende reemplazar MoQ
Como dice Cullen Jennings de Cisco (participante del grupo de trabajo MoQ), el mundo del streaming actualmente tiene dos silos. Por un lado, servicios como Netflix y YouTube entregan medios a gran escala a través de CDN basados en HTTP, pero con segundos de latencia. Por otro lado, herramientas de videoconferencia como Zoom y plataformas basadas en WebRTC entregan medios casi en tiempo real, pero no pueden escalar de forma rentable para grandes audiencias.
MoQ pretende unir estos dos mundos con un único protocolo que pueda servir tanto para casos de uso en tiempo real como casi en tiempo real, desde la contribución (ingesta) hasta la distribución (entrega a los espectadores), con infraestructura de relays compatible con CDN en el medio.
Dónde se encuentra MoQ hoy (marzo 2026)
Seamos precisos sobre el estado actual:
La especificación está cerca pero no terminada. El borrador de transporte está en la versión 17, iterando rápidamente. El borrador del formato de streaming se publicó en enero de 2026. Hay trabajo complementario activo sobre empaquetado CMAF y compresión de cabeceras. Pero aún no hay ningún RFC ratificado.
La brecha de Safari/WebTransport se está cerrando. MoQ en el navegador depende de WebTransport, que requiere HTTP/3 y QUIC. Chrome y Firefox ya soportan WebTransport. Safari era la excepción — pero Apple añadió soporte de WebTransport en la beta de Safari 26.4 (febrero de 2026), y es un compromiso oficial de Interop 2026 por parte de WebKit. A marzo de 2026, esto aún no se ha lanzado en una versión estable de Safari, pero ya no es una cuestión de si — solo de cuándo en el próximo ciclo del sistema operativo. Para productos dirigidos a usuarios de iPhone y iPad a través del navegador, la brecha está casi cerrada.
Existen despliegues tempranos en producción pero son limitados. Nanocosmos demostró la entrega MoQ de extremo a extremo (ingesta desde OBS a audiencia global) en el MonteVIDEO Summer Project. Cloudflare lanzó una beta de MoQ. Red5 anunció soporte de MoQ para finales de 2026. Pero estos son despliegues de adoptantes tempranos, no infraestructura generalizada.
La comunidad es honesta sobre la madurez. Incluso Luke Curley, quien construyó una de las primeras implementaciones de MoQ en Twitch (ahora Discord) y es autor del borrador de simplificación moq-lite, afirma explícitamente que la especificación completa de transporte MoQ "se ha vuelto demasiado complicada" con "demasiados mensajes, modos opcionales y características a medio desarrollar." Su borrador moq-lite es una respuesta a esa complejidad.
Los veteranos de la industria son prudentes. Tsahi Levent-Levi de BlogGeek.me predijo que en 2026, los desarrolladores se quejarían más de WebRTC que de MoQ — no porque MoQ sea mejor, sino porque los usuarios de MoQ son todavía adoptantes tempranos que esperan asperezas. WebRTC es el que está en producción en todas partes, soportando el peso de las expectativas del mundo real.
Qué cambia MoQ respecto a HLS
HLS (HTTP Live Streaming) funciona dividiendo los medios en segmentos, escribiéndolos en un servidor HTTP, y haciendo que los reproductores consulten nuevos segmentos a través de listas de reproducción. Es maduro, compatible con CDN, ampliamente desplegado y bien documentado en el RFC 8216 y en la Especificación de Autoría HLS de Apple. Low-Latency HLS (LL-HLS) reduce la latencia a aproximadamente 2-4 segundos.
MoQ cambia el modelo de entrega de varias maneras:
De consultas a envío directo. Los reproductores HLS solicitan segmentos. Los suscriptores de MoQ reciben objetos a medida que se publican. Esto elimina la latencia de consulta.
De segmentos a objetos. HLS opera con segmentos de varios segundos (o segmentos parciales en LL-HLS). MoQ puede operar a nivel de trama. Una sola trama de vídeo o de audio puede ser un objeto individualmente direccionable e individualmente entregable.
De TCP a QUIC. HLS se ejecuta sobre HTTP/TCP. Cuando se pierde un paquete TCP, todo lo que está detrás se detiene (bloqueo de cabeza de línea). MoQ se ejecuta sobre QUIC, donde los flujos son independientes — un paquete perdido en un flujo no bloquea a los demás.
Priorización explícita. El borrador de transporte de MoQ define la prioridad y el orden de entrega a nivel de protocolo. Durante la congestión, un relay puede descartar objetos de menor prioridad (por ejemplo, B-frames) en lugar de retrasar todo por igual.
Ingesta y distribución unificadas. Hoy en día, la mayoría de los flujos de trabajo en vivo utilizan un protocolo para la contribución (RTMP, SRT, WHIP) y otro para la distribución (HLS, DASH). MoQ puede potencialmente servir ambas rutas con un único protocolo, eliminando el paso de reempaquetado en el servidor de origen.
Cuándo HLS sigue siendo la mejor opción
Nada de esto significa que HLS esté obsoleto. HLS sigue siendo la opción más fuerte cuando:
- Unos segundos de latencia son perfectamente aceptables
- La amplia compatibilidad de dispositivos es esencial (todos los teléfonos, televisores y decodificadores reproducen HLS)
- La inversión existente en CDN y herramientas está funcionando bien
- La simplicidad operativa y la fiabilidad probada en batalla importan más que reducir la latencia al mínimo
Para la entrega estándar de OTT en vivo y VOD — que constituye la abrumadora mayoría del tráfico de streaming — HLS no está roto, y MoQ no soluciona un problema que exista.
Qué cambia MoQ respecto a WebRTC
WebRTC fue diseñado para la comunicación peer-to-peer en tiempo real: videollamadas, compartir pantalla, conversaciones uno a uno o en grupos pequeños. La industria lo ha extendido mucho más allá de ese alcance original, utilizando arquitecturas SFU (Selective Forwarding Unit) para escalar WebRTC a audiencias más grandes.
MoQ se diferencia de WebRTC en varios aspectos importantes:
Arquitectura. WebRTC es fundamentalmente un protocolo peer-to-peer orientado a sesiones, incluso cuando está mediado por SFUs. MoQ es un protocolo publish/subscribe cliente-servidor diseñado desde el principio en torno a relays y distribución al estilo CDN.
Modelo de escalabilidad. Escalar WebRTC requiere infraestructura SFU construida a propósito y costosa. Los relays de MoQ están diseñados para integrarse con la infraestructura CDN existente — los servidores HTTP/3 pueden ampliarse para manejar tráfico MoQ, razón por la cual proveedores de CDN como Akamai y YouTube están activamente involucrados.
Complejidad. WebRTC conlleva una complejidad significativa: negociación de oferta/respuesta SDP, recopilación de candidatos ICE, servidores STUN/TURN para traversal de NAT, SRTP para cifrado, SCTP para canales de datos. La configuración de conexión de MoQ es más simple — un handshake QUIC seguido de mensajes de subscribe/publish.
Flexibilidad de códecs. La negociación de códecs de WebRTC está estrechamente acoplada al protocolo. MoQ es agnóstico en cuanto a códecs a nivel de transporte — el formato de medios se gestiona en la capa de aplicación (MSF, LOC o contenedores personalizados).
Dependencia del navegador. Ambos protocolos dependen de APIs del navegador para la entrega basada en web. WebRTC tiene soporte universal en navegadores. MoQ depende de WebTransport, que Safari acaba de añadir en beta (26.4, febrero de 2026) y aún no ha lanzado en versión estable. Esta brecha se está cerrando pero sigue siendo una consideración práctica para MoQ hoy.
Cuándo WebRTC sigue siendo la mejor opción
WebRTC sigue siendo la mejor elección cuando:
- Se necesita comunicación bidireccional en tiempo real verdadera (videollamadas, videoconferencias)
- Se requiere compatibilidad de navegador en todas las plataformas, incluido Safari/iOS
- El caso de uso es peer-to-peer o de grupos pequeños sin necesidad de distribución a escala CDN
- La madurez de herramientas y SDK probados en producción es importante
Qué cambia MoQ respecto a SRT
SRT (Secure Reliable Transport) destaca en mover medios de alta calidad del punto A al punto B sobre redes impredecibles. Proporciona cifrado AES, recuperación de pérdida de paquetes mediante ARQ (Automatic Repeat Request) y soporte de bitrate adaptativo. SRT es ampliamente adoptado para flujos de trabajo de ingesta (cámaras a estudios, producción remota a codificadores en la nube), pero también sirve como protocolo de distribución punto a punto — como demuestra DJing Stream.
MoQ y SRT sirven para propósitos superpuestos pero diferentes:
SRT es punto a punto; MoQ es publish/subscribe. SRT conecta un emisor con un receptor. MoQ soporta de forma nativa la distribución de uno a muchos a través de relays.
SRT garantiza la entrega; MoQ puede elegir no hacerlo. El mecanismo ARQ de SRT retransmite cada paquete perdido, lo que asegura una entrega sin pérdidas pero añade latencia en caso de pérdida de paquetes. MoQ puede configurarse para fiabilidad parcial — descartando objetos tardíos en lugar de retransmitirlos — lo cual es mejor para la entrega en vivo sensible a la latencia, pero inaceptable cuando cada muestra importa.
SRT es maduro y desplegado; MoQ es emergente. SRT tiene amplio soporte de hardware y software (OBS, vMix, FFmpeg, Haivision, todos los principales codificadores). MoQ tiene implementaciones en fase temprana.
Cuándo SRT sigue siendo la mejor opción
SRT es la opción más fuerte cuando:
- El caso de uso es punto a punto (fuente a codificador, codificador a origen, o distribución directa al lugar)
- La entrega sin pérdidas importa más que la latencia mínima absoluta
- El flujo de trabajo involucra equipos de broadcast profesional que ya hablan SRT
- La fidelidad de audio a nivel de bit es innegociable
Caso de estudio: WeSpeakSports — comentarios en vivo de aficionados sobre WebRTC
WeSpeakSports es una plataforma de comentarios de audio en vivo de aficionados. Los aficionados crean o escuchan comentarios de audio en tiempo real durante partidos deportivos — fútbol, baloncesto, rugby, F1 y más. La aplicación está disponible en iPhone, iPad, Mac (Apple Silicon) y Vision Pro.
La arquitectura actual utiliza WebRTC para la transmisión de audio. Un aficionado comentarista transmite audio desde su dispositivo, y los oyentes lo reciben casi en tiempo real. El audio es de calidad vocal, no de calidad musical — la inteligibilidad y la baja latencia importan mucho más que la fidelidad audiófila.
¿Tendría sentido MoQ para WeSpeakSports?
En teoría, sí — es un excelente encaje para este caso de uso. WeSpeakSports es una transmisión de audio en vivo de 1 a muchos con expectativas de tiempo real. Este es precisamente el hueco que MoQ está diseñado para llenar: demasiados oyentes para escalar WebRTC de forma eficiente, pero demasiado sensible a la latencia para HLS.
El modelo publish/subscribe de MoQ se adapta naturalmente a la arquitectura de WeSpeakSports: un comentarista publica una pista de audio, los oyentes se suscriben a ella y los relays CDN gestionan la distribución. Esto sería más simple y más barato de escalar que la infraestructura SFU de WebRTC.
En la práctica, todavía no — por dos razones de peso:
- Safari/iOS está casi listo, pero aún no. WeSpeakSports requiere iOS 18.0. La audiencia principal de la aplicación está en iPhone. MoQ en el navegador depende de WebTransport, que Apple añadió en la beta de Safari 26.4 pero aún no ha lanzado en versión estable. Incluso para aplicaciones nativas de iOS, no existe hoy un SDK de MoQ listo para producción en plataformas Apple. La pila WebRTC en iOS (a través del soporte integrado de WebKit de Apple y SDKs de terceros maduros) está probada y funciona.
- Madurez. WeSpeakSports es un producto lanzado con usuarios reales. Cambiar la capa de transporte de un protocolo probado a una especificación pre-1.0 sería prematuro. WebRTC está manejando la escala actual. El coste de complejidad de la migración no se justifica con la base de usuarios actual.
Cuándo reevaluar
MoQ merece ser evaluado para WeSpeakSports cuando:
- WebTransport se lance en la versión estable de Safari — lo cual es ahora inminente dada la beta de Safari 26.4 — y surja un SDK nativo maduro de MoQ para iOS/macOS
- La base de usuarios crezca a una escala donde los costes del SFU de WebRTC se conviertan en una restricción significativa
- La infraestructura de relays MoQ esté disponible en al menos dos proveedores de CDN con compromisos de SLA
- La especificación de transporte MoQ alcance el estatus de RFC
En ese momento, MoQ podría simplificar significativamente la arquitectura de distribución y reducir el coste por oyente. El modelo comentarista-a-relay-a-oyentes es un caso de uso de libro de texto para MoQ. Es una cuestión de momento, no de encaje.
Caso de estudio: DJing Stream — audio de DJ con calidad broadcast sobre SRT
DJing Stream es una aplicación de macOS diseñada para un caso de uso muy específico: transmitir audio con calidad broadcast desde la configuración de un DJ al sistema de sonido de un local, por internet, en tiempo real. La arquitectura prioriza la calidad de audio por encima de todo lo demás.
La pila actual utiliza SRT para la distribución en tiempo real — entregando audio estéreo PCM de 24 bits a 48 kHz (aproximadamente 2,3 Mbps) desde el Mac del DJ al sistema de sonido del local. Para una distribución más amplia a oyentes remotos, el audio también puede servirse sobre HLS con audio lossless. Toda la filosofía de diseño es que el audio de un DJ merece la misma fidelidad que una conexión por cable físico.
¿Tendría sentido MoQ para DJing Stream?
No — y esto no es una cuestión de momento. MoQ está fundamentalmente desalineado con los requisitos de DJing Stream.
He aquí por qué:
- La entrega sin pérdidas es innegociable. DJing Stream envía audio PCM sin comprimir. Cada muestra importa. La retransmisión ARQ de SRT garantiza que cada paquete llega — añadirá latencia en caso de pérdidas antes que descartar audio. El modelo de fiabilidad parcial de MoQ, que es una de sus ventajas clave para el vídeo en vivo, es exactamente la compensación equivocada para audio con calidad broadcast. Una trama de audio descartada es un fallo audible en el sistema de sonido de un club. Eso no es aceptable.
- El punto a punto es el caso de uso principal. El escenario central de DJing Stream es un DJ transmitiendo a un local. Este es un enlace punto a punto, no un problema de distribución. El modelo de relay publish/subscribe de MoQ añade complejidad sin beneficio para esta topología.
- No hay requisito de navegador. DJing Stream es una aplicación nativa de macOS que se conecta a hardware del local. No hay ningún navegador web en el circuito. La brecha de WebTransport/Safari es irrelevante, pero también lo es la ventaja principal de MoQ de entrega nativa en el navegador.
- SRT ya es la herramienta correcta. SRT fue diseñado exactamente para esto: transporte fiable, cifrado y de baja latencia de medios de alta calidad sobre redes impredecibles. Está probado en batalla en la producción broadcast. Cada codificador y servidor de medios lo habla. Reemplazar SRT con MoQ para el enlace de distribución DJ-a-local significaría renunciar a la entrega garantizada sin ninguna ganancia significativa.
- HLS Lossless se encarga del lado de la distribución. Para el caso de uso secundario de distribuir a una audiencia más amplia (oyentes web), HLS con códecs de audio lossless está probado y es compatible con todos los dispositivos. La tolerancia a la latencia para oyentes remotos es mayor que para el propio local, por lo que el modelo basado en segmentos de HLS es perfectamente adecuado.
Cuándo reevaluar
¿Sinceramente? Probablemente nunca para el enlace central DJ-a-local. SRT hace exactamente lo que DJing Stream necesita, y los objetivos de diseño de MoQ (distribución escalable con pérdida de calidad aceptable bajo congestión) se oponen a los objetivos de diseño de DJing Stream (entrega sin ninguna pérdida de cada muestra de audio).
El único escenario donde MoQ podría ser relevante para DJing Stream es si el producto se expande hacia la distribución a gran escala para fans con expectativas de fidelidad más bajas — por ejemplo, transmitir una versión comprimida de una sesión de DJ a miles de oyentes simultáneamente. Aun así, HLS o LL-HLS probablemente seguirían siendo más simples y más ampliamente compatibles.
El marco de decisión
Después de investigar MoQ exhaustivamente — los borradores del IETF, comentarios de la industria de Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho y Nanocosmos — esta es la regla de decisión más simple que puedo ofrecer:
Mantén tu pila actual cuando
- Tu producto está en producción hoy y tu protocolo actual funciona
- Necesitas soporte de navegador en Safari/iOS hoy (WebTransport está en beta de Safari pero aún no es estable)
- Unos segundos de latencia son aceptables (→ HLS/LL-HLS)
- Necesitas entrega garantizada sin pérdidas (→ SRT)
- Necesitas comunicación bidireccional en tiempo real verdadera (→ WebRTC)
Empieza a evaluar MoQ cuando
- La latencia ultra-baja para grandes audiencias es fundamental para el valor de tu producto (apuestas en vivo, subastas, experiencias sincronizadas de segunda pantalla)
- Controlas toda la pila desde la ingesta hasta la reproducción y puedes absorber un nuevo protocolo
- Los costes de escalado de WebRTC se están convirtiendo en un problema real de negocio
- Estás construyendo un nuevo producto que no se lanzará hasta finales de 2026 o 2027
- Puedes aceptar que la especificación aún puede cambiar antes de alcanzar el estatus de RFC
Sigue de cerca MoQ si
- Operas infraestructura CDN o de relays (MoQ está diseñado para funcionar con CDNs HTTP/3)
- Construyes productos de deportes en vivo con requisitos de sincronización
- Quieres convergir la ingesta y la distribución en un único protocolo
- Estás frustrado por la sobrecarga de reempaquetado de la ingesta RTMP/SRT → distribución HLS
La conclusión
MoQ es real, está bien diseñado y aborda limitaciones genuinas en el panorama actual de protocolos de streaming. La ambición — un único protocolo tanto para tiempo real como para casi tiempo real, desde la ingesta hasta la distribución, con soporte de relays a escala CDN — es convincente.
Pero ambición no es lo mismo que madurez. La especificación no está finalizada. Safari tiene WebTransport en beta pero aún no en una versión estable. Los despliegues en producción se limitan a adoptantes tempranos. El ecosistema de SDKs, herramientas y conocimiento operativo que hace que HLS, WebRTC y SRT sean fiables en producción simplemente no existe todavía para MoQ.
Para la mayoría de productos de streaming que se lanzan en 2026, MoQ es algo que seguir de cerca — no algo que adoptar. Cuando madure, y lo hará, tiene el potencial de simplificar arquitecturas que actualmente unen múltiples protocolos con capas de reempaquetado en el medio.
Hasta entonces: si HLS funciona para tu entrega, mantenlo. Si WebRTC funciona para tus necesidades en tiempo real, mantenlo. Si SRT funciona para tus enlaces punto a punto, mantenlo. El mejor protocolo es el que está en producción y funcionando, no el que resulta más emocionante en una diapositiva de conferencia.
Fuentes
- Borrador de transporte MoQ del IETF (v17, marzo 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- Carta del grupo MoQ del IETF: datatracker.ietf.org/group/moq/about
- Borrador de moq-lite: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- Blog del IETF — ¿Qué pasa con MoQ?: ietf.org/blog/moq-overview
- BlogGeek.me — MOQ: Cómo redefinirá los medios en tiempo real: bloggeek.me/moq-redefine-realtime
- webrtcHacks — WebRTC vs. MoQ por caso de uso: webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS): rfc-editor.org/rfc/rfc8216.html
- Visión general de HLS de Apple: developer.apple.com/streaming
- WebKit — Anuncio de Interop 2026 (compromiso con WebTransport): webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz