Resumen

  • En RFC 9725, 201 Created confirma que el endpoint aceptó la oferta SDP, generó una respuesta y devolvió la ubicación de un recurso de sesión. Todavía no confirma conectividad, claves ni paquetes.
  • La operación de un directo necesita conservar por separado la pareja ICE seleccionada, la asociación DTLS, el flujo RTP/RTCP observado, el avance del procesamiento, la entrega y el resultado del reproductor.
  • Un DELETE reconocido no basta para afirmar que terminó el efecto: el estado de medios, las credenciales temporales y la capacidad dependiente también deben quedar cerrados.

El recibo llegó antes que la señal

En la sala de producción se puede ver una contradicción perfectamente válida: el servicio de control responde en cientos de milisegundos y el monitor de contribución sigue sin audio ni vídeo. El recibo no es falso; la conclusión es demasiado grande.

RFC 9725 define WHIP como un intercambio único de oferta y respuesta SDP mediante HTTP. El productor o codificador hace POST con application/sdp; el endpoint devuelve 201 Created, otra carga SDP y un encabezado Location que identifica el recurso de esa sesión. El registro del RFC Editor y el Datatracker documentan su publicación como Proposed Standard en marzo de 2025. La búsqueda de erratas no mostraba registros al cerrar esta investigación, algo que no dice si un despliegue concreto funciona.

El 201 acredita una operación acotada del plano de control. Conforme a RFC 9110, el servidor creó el recurso indicado. En WHIP, además, produjo una respuesta inicial coherente con JSEP. No observó por ello una comprobación STUN, el final de un handshake DTLS ni un frame decodificado.

Una sesión con reglas estrechas

La sencillez de WHIP no es vaguedad. El protocolo reutiliza las reglas de oferta/respuesta de JSEP, impone un único MediaStream, agrupa medios, multiplexa RTP/RTCP y orienta el flujo hacia la ingestión. El cliente debería ofrecer sendonly y el servidor responde recvonly. No hay renegociación general posterior: los cambios de ICE tienen un canal, los cambios de secciones de medios no.

También se recomienda evitar una aceptación parcial. Si una sección de audio o vídeo no puede procesarse, rechazar toda la solicitud es menos engañoso que crear una ingestión a medias. Pero una aceptación íntegra solo demuestra que la descripción fue aceptada. El codificador todavía puede carecer de ruta, enviar un formato inútil para el siguiente componente o dejar de producir segundos después.

La operación debe conservar al menos cinco identidades que suelen perderse: la solicitud inicial, el recurso Location, la generación ICE, la asociación DTLS/SRTP y el objeto de producción que continúa hacia distribución. Si se correlacionan solo por hora o nombre de evento, un reinicio o reintento puede unir la evidencia equivocada.

ICE decide por dónde, no qué llegó

RFC 8445 describe cómo ICE forma parejas de candidatos, ejecuta comprobaciones, nomina y selecciona una pareja. La lista SDP es material para decidir; no es el resultado de la decisión.

Con Trickle ICE, la oferta puede salir con una lista incompleta o vacía. El cliente almacena los candidatos que aparecen mientras espera el 201, porque aún no conoce la URL de sesión y quizá tampoco el ETag que identifica esa generación. Después los envía por PATCH, método definido en RFC 5789, como fragmento application/trickle-ice-sdpfrag conforme a RFC 8840.

Aquí existe una trampa operacional importante. El servidor devuelve 204 No Content al procesar una incorporación de candidatos, pero puede descartar silenciosamente un candidato con transporte no admitido o dirección no resoluble. Contar PATCH 204 no equivale a contar rutas utilizables. El comprobante posterior debe nombrar la pareja seleccionada, si fue directa o TURN, cuándo fue nominada y durante cuánto tiempo conservó consentimiento.

Los reinicios ICE cambian credenciales y candidatos sin renegociar lo demás. Los ETags fuertes ayudan a distinguir generaciones cuando varios PATCH se cruzan. Un 412 o un 428 descubre ciertos errores de condición; un 200 de reinicio con ETag nuevo solo crea una descripción vigente. Las nuevas comprobaciones aún deben tener éxito.

La criptografía tampoco muestra una imagen

RFC 5764 emplea DTLS para derivar material de claves de SRTP. RFC 8835 fija los transportes WebRTC y RFC 8834 trata el uso de RTP y RTCP. El final del handshake prueba una asociación protegida sobre un transporte. No prueba que el codificador esté enviando el programa correcto.

La evidencia de medios tiene dirección y duración. El emisor registra progresión de paquetes, octetos y marcas de tiempo, así como SSRC, MID o RID. El receptor registra primer y último paquete, secuencia, pérdidas, jitter, bitrate y feedback RTCP dentro de un intervalo. Las obligaciones de control de congestión añaden otra pregunta: ¿el flujo se adaptó a la capacidad o mantuvo una cifra que dañó la ruta?

Una muestra de bitrate puede coincidir con una pantalla congelada. Un contador de paquetes puede incluir relleno, retransmisiones o un SSRC distinto al esperado. Un informe RTCP describe lo que vio un receptor y bajo qué periodicidad; no representa por sí solo a la audiencia. Por eso el comprobante debe conservar contexto de codec, pistas, secuencia y ventana temporal.

La frontera de ingestión no es el borde del público

WHIP sirve para entregar contenido a un servicio de streaming o CDN, pero no estandariza el viaje completo al espectador. Tras la recepción SRTP pueden fallar la decodificación, transcodificación, creación de rendiciones, actualización de manifiestos, admisión en origen, llenado de caché, enrutamiento o reproducción.

El marco CDNI separa enrutamiento de solicitudes, metadatos, adquisición y distribución. La interfaz de logs CDNI contempla generación, agregación, filtrado, recogida y rectificación. Es un recordatorio de que incluso un log de entrega tiene una cadena de custodia y puntos ciegos.

El relevo correcto no consiste en que todos acepten una bandera live=true. Ingestión afirma qué paquetes observó. Procesamiento afirma qué entrada pudo decodificar y qué salidas siguen avanzando. Distribución afirma qué objetos y solicitudes observó, desde qué cobertura. Un probe de reproductor afirma si arrancó, reprodujo audio y vídeo y sufrió pausas desde una ubicación y dispositivo conocidos.

Cuando estas piezas discrepan, la discrepancia es el dato. Ausencia de quejas no es recepción. Ausencia de pérdidas en una muestra no es continuidad. Un manifiesto actualizado no es un frame presentado.

El coste de las sesiones que nunca conectan

RFC 9725 exige soporte de autenticación HTTP y del mecanismo de token bearer, pero deja fuera la semántica y distribución del token. Su aceptación no concede automáticamente un derecho ilimitado a evento, duración, codec, región, bitrate o gasto.

Un cliente con credenciales puede obtener recursos por POST y no iniciar ICE o DTLS. El RFC identifica el agotamiento por inundación de POST y recomienda límites de tasa y control de avalanchas. También advierte sobre PATCH y sobre URLs de sesión adivinables que permitirían DELETE hostiles.

Esto obliga a medir capacidad por estado. Las sesiones creadas sin pareja seleccionada consumen de forma distinta a un flujo activo. TURN, handshakes DTLS, receptores, decodificadores, transcodificadores, empaquetadores, origen y distribución tienen presupuestos separados. La edad de una sesión detenida entre dos estados puede revelar una fuga antes de que el total llegue al límite.

El endpoint puede usar un 307 para balancear el POST sin convertirlo en GET, y puede devolver 503 con Retry-After. No se exige que PATCH y DELETE sigan redirecciones. El registro de auditoría debe guardar la cadena inicial, la autoridad de la URL final y el servidor de medios elegido; una respuesta rápida en el frontal no mide la capacidad del destino.

Terminar exige saber qué se devuelve

El cliente envía DELETE al recurso indicado en Location. RFC 9725 describe la eliminación de la sesión, la terminación ICE/DTLS y la liberación de recursos del servidor de medios. RFC 7675 añade la frescura del consentimiento para detectar una desconexión no ordenada; ese consentimiento se refiere a tráfico sobre una sola tupla de red, no a personas ni al éxito del programa.

El cierre verificable responde más preguntas: ¿el URL opaco correspondía a esta generación?, ¿quién lo terminó y por qué?, ¿cesaron los contadores?, ¿se cerró DTLS o expiró el consentimiento?, ¿se soltaron TURN, decoder, transcoder, packager y origen?, ¿caducaron credenciales temporales?, ¿quedó algún manifiesto presentándose como vivo? Son controles propuestos para operación, no requisitos añadidos al RFC.

La primacía del código en ejecución de Lu Heng obliga a poner por delante el servicio que usa el público. Su diseño de especificación mínima y decisiones futuras localizadas explica por qué WHIP puede ser pequeño sin absorber la autorización, capacidad o respuesta a incidentes de cada operador. Y la realidad, no la defensa institucional, exige conservar el desacuerdo entre capas.

La disciplina no consiste en desconfiar del 201. Consiste en creer exactamente lo que prueba, y nada más.

Fuentes

Especificaciones y registros: RFC 9725, registro RFC Editor, Datatracker, erratas, RFC 8445, RFC 7675, RFC 5764, RFC 8834, RFC 8835, RFC 8836, RFC 8840, RFC 9429, RFC 9110, RFC 5789, RFC 8288, RFC 7336 y RFC 7937.

Marco analítico atribuido: Running-Code Primacy, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption y Why BTW.Media Exists — and Why Reality, Not Advocacy, Is the Product.