WebTransport y RTP sobre QUIC: qué podría venir después de WebRTC
El post anterior de esta serie terminó con una promesa: el medio de WebRTC no funciona hoy sobre QUIC, en ningún navegador ni servidor de medios, pero el trabajo real de conexión entre ambos mundos está ocurriendo en el IETF. Hay tres esfuerzos que merece la pena conocer - WebTransport, RTP sobre QUIC y Media over QUIC - y no son lo mismo, aunque a menudo se mencionen juntos. Esto es lo que es cada uno en realidad, y hasta dónde ha llegado cada uno, a fecha de esta entrada.
WebTransport: los streams y datagramas de QUIC, en manos del navegador
WebTransport es una API de navegador que expone las primitivas de transporte propias de QUIC - streams multiplexados y datagramas no fiables - directamente a las aplicaciones web, construida sobre HTTP/3. Ya funciona en Chrome y Firefox; Safari todavía no lo soporta. La propia especificación sigue siendo un borrador de trabajo tanto en el W3C como en el IETF, no un estándar terminado, así que todavía puede cambiar.
Merece la pena ser precisos sobre lo que WebTransport no es: no es un sustituto de WebRTC,
y no tiene ningún concepto integrado de RTP, códecs de medios, buffers de jitter ni
cancelación de eco. Se parece más a "fetch() para streams y datagramas QUIC" que a una pila
de medios; una base sobre la que se puede construir otras cosas, no una API de
videollamadas por sí misma.
RTP sobre QUIC: la pila de medios de hoy, el transporte de mañana
RTP sobre QUIC (RoQ) es un borrador del IETF que hace algo deliberadamente acotado: define cómo transportar paquetes RTP y RTCP normales -los mismos que ya habla la pila de WebRTC actual- dentro de QUIC, usando streams QUIC o datagramas no fiables.
El atractivo está en la continuidad. RTP es lo que ya entienden los SFU, los navegadores y los servidores de medios de hoy; RoQ no pide reinventar nada de ese ecosistema. Pide que cambie el transporte de debajo, mientras la capa de medios de arriba sigue siendo la conocida; ganando por el camino migración de conexión, control de congestión intercambiable y multiplexación sin head-of-line blocking. Sigue siendo un Internet-Draft activo, todavía no un RFC, así que es trabajo real del IETF en curso, no un estándar ya publicado.
Media over QUIC: no es un envoltorio, es un diseño nuevo
Media over QUIC (MoQ) toma el enfoque contrario. En lugar de transportar RTP dentro de QUIC, el grupo de trabajo MoQ - constituido en el IETF en 2022 - está diseñando desde cero un modelo de entrega de medios nativo de QUIC, construido en torno a un modelo de publicación/suscripción sobre streams QUIC, con el objetivo de unificar el streaming en directo y las videoconferencias en tiempo real bajo un único protocolo, en lugar de tratarlos como problemas separados.
Es una tarea mucho más grande que la de RoQ, y se nota en el calendario: MoQ ha llegado a pruebas de interoperabilidad entre implementaciones distintas en reuniones del IETF, pero sigue siendo trabajo de borrador activo, no un estándar terminado, y "todavía no listo para producción" es una descripción justa de dónde se encuentra.
Qué significa esto realmente, hoy
Nada de esto es un sustituto directo de WebRTC ahora mismo. WebTransport por sí solo no habla de medios; RoQ y MoQ son ambos todavía borradores del IETF, no RFCs. Para un servidor de medios construido en torno a la pila actual de WebRTC/RTP, adoptar cualquiera de estos supondrá trabajo real de integración más adelante, no activar una opción de configuración.
Pero la dirección es legible, que ya es más de lo que se podía decir hace un par de años: un transporte futuro que puede llevar consigo lo que ya funciona (el propio ecosistema de RTP, vía RoQ) o abrir la puerta a algo construido de forma nativa sobre QUIC desde cero (MoQ), con WebTransport como la base expuesta al navegador sobre la que cualquiera de los dos podría apoyarse.