Resumen
- Si ninguna trama de la gama solicitada permanece en la ventana del receptor, este devuelve la longitud cero. La respuesta acredita que el estado individual ya no está retenido, no una causa de pérdida ni un resultado de decodificación.
- La señal sólo adquiere valor operativo cuando conserva su pareja de SSRC, época, tiempos, ventana, semántica exacta y la comprobación separada de que el emisor aún guarda una referencia utilizable.
El sistema de alarmas recibió una respuesta con Feedback Length = 0 y abrió un incidente de pérdida total. Minutos después, otro tablero concluyó lo contrario: como no había bits en cero, todas las tramas debían de haber sido reconocidas. Las dos lecturas parecían razonables si se ignoraba el contrato. Las dos eran falsas.
La longitud cero no clasifica las tramas. Clasifica la disponibilidad del recuerdo.
El borrador RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement dota al receptor de una ventana contigua y acotada de estados. El tamaño predeterminado es 255 identificadores de trama; mediante negociación puede situarse entre 1 y 32.767. Cuando nuevas unidades desplazan la ventana, las entradas más antiguas se descartan en orden FIFO.
Si una solicitud se solapa parcialmente con lo que aún se conserva, la respuesta adelanta su Start Frame ID y describe sólo la intersección. Si no queda ninguna coincidencia, devuelve el comienzo pedido y una longitud cero. El emisor debe entender que el receptor ya no conserva esos estados y no debe emplear las tramas antiguas como referencias. El protocolo no dice que fueran perdidas. Tampoco dice que fueran decodificadas.
La revisión estudiada es la 01, fechada el 6 de julio de 2026 y con caducidad el 7 de enero de 2027. Es un Internet-Draft activo del grupo AVTCORE, destinado a ser Informational. Datatracker lo mantiene en I-D Exists: carece todavía de shepherd, Area Director responsable, evaluación IESG, número RFC y asignación IANA completada. El mensaje RTCP emplea PT 205 y deja el FMT como TBD, sugiriendo 12. Hablar del mecanismo como si ya fuese una práctica desplegada añadiría una evidencia que las fuentes no contienen.
Un bit compacto no puede responder a todas las preguntas
El mecanismo identifica las unidades mediante un Frame ID de 16 bits que aumenta de uno en uno en el orden de envío y vuelve a cero al agotarse. La extensión debería aparecer en el último paquete de la unidad y nunca más de una vez por trama. El receptor debe aceptar cualquier punto inicial.
“Trama” tiene aquí un sentido ligado al estado del códec: una unidad decodificable que actualiza información referenciable por unidades futuras. Puede ser una imagen completa, una imagen no mostrada, una tesela o una porción independiente. Por ello, incluso un reconocimiento perfecto de la unidad no demuestra que un usuario viera una imagen.
El vector de estado emplea un solo bit. Uno significa recibida y ya decodificada, o recibida y comprometida para un intento de decodificación. El borrador permite enviar el positivo antes de terminar para reducir la latencia. Si el intento falla, el receptor debe pedir una imagen clave, aun cuando se trate de una capa descartable. Cero reúne tres situaciones: no recibida, no decodificada o no prevista para decodificación.
El analista no puede recuperar de ese bit una distinción que el emisor no transmitió. Necesita hechos posteriores: fin de decodificación, error, solicitud de clave, entrega de recuperación, presentación y calidad percibida.
La ventana puede moverse mientras RTCP espera
Las reglas temporales y presupuestarias de RTCP pueden diferir la respuesta. La ventana no se congela durante esa espera. El borrador exige formar el mensaje con el estado existente en el momento de enviarlo, no con una instantánea del momento de recibir la solicitud.
Una petición para las tramas 1 a 4 puede terminar en una respuesta que sólo cubra 3 y 4 si, antes de la emisión, la ventana avanzó a 3–6. No hay contradicción. La solicitud preguntó por un pasado más amplio del que el receptor aún podía describir cuando habló.
Además, si llega una petición más nueva mientras la anterior sigue pendiente, el receptor debería abandonar la primera y responder a la última. De ese modo evita una cola de respuestas obsoletas. Pero la recepción de una solicitud deja de ser promesa de contestar exactamente esa gama.
Por eso un registro de control necesita al menos la hora de recepción de cada petición, la hora de construcción y envío de cada respuesta, los límites de la ventana en ese instante y la relación de sustitución entre solicitudes. Una marca temporal recogida lejos del endpoint no basta para reconstruir la causalidad.
El comienzo también puede retirar historia
Las dos posiciones FFR del encabezado RTP permiten identificar sin pedir (00), pedir implícitamente una sola trama (01) o expresar una gama independiente (10); 11 queda reservada. Una longitud cero puede usarse incluso para establecer un punto de reconocimiento más nuevo sin solicitar estados individuales.
Avanzar Feedback Start reconoce implícitamente y elimina la obligación de conservar valores anteriores. Esa operación mantiene acotado el protocolo. No certifica cada resultado previo. Si un repositorio convierte automáticamente todo identificador anterior en decoded=true, sustituye una regla de jubilación por una afirmación de ejecución.
La respuesta correcta del incidente inicial habría sido: “el estado solicitado ya no estaba disponible; no se puede determinar la causa con este mensaje”. Sólo una traza previa, un contador de paquetes, un evento del decodificador o una observación de presentación podrían estrechar la conclusión.
Reanudar exige una referencia en ambos extremos
El indicador R permite solicitar resincronización. El receptor puede indicar su última trama correctamente decodificada y extender los estados hasta la última recibida dentro del espacio disponible. Es una contribución necesaria para elegir desde dónde reconstruir la cadena.
Sin embargo, el emisor debe comprobar que todavía conserva esa referencia en su propio búfer. Debería codificar desde ella, o desde otra referencia cuya disponibilidad en el receptor conozca. Si ninguna sigue presente, debería emitir una imagen clave. La buena referencia del receptor no reaparece por decreto en el codificador.
El parámetro resync-timeout, de 1 a 65.535 milisegundos, expresa cuándo la falta de decodificación puede disparar una petición. No garantiza cuándo concluirá la recuperación. Del mismo modo, status-window-size limita el estado del receptor y el número pendiente; no promete un búfer de referencias equivalente en el emisor.
La prueba completa separa el informe del receptor, la disponibilidad del emisor, la elección de referencia, la codificación de recuperación, la entrega, la decodificación y la presentación. Agrupar esos pasos bajo una sola palabra —“recuperado”— borra el lugar exacto donde falló la cadena.
Épocas, cadenas y audiencias
El estado es único para cada pareja de SSRC de emisor y receptor. Si cambia cualquiera de los dos, la secuencia se reinicia y se descarta todo lo anterior. Fuera de ese cambio no se permiten saltos ni reinicios. El mismo número en dos épocas no designa el mismo hecho.
También pueden intercalarse cadenas de dependencia independientes dentro de un SSRC. Que una trama posterior de una cadena tenga estado positivo no demuestra el destino de una trama anterior de otra. De ahí la utilidad de gamas y vectores frente a un simple máximo.
En una topología con SFU o SFM, el intermediario puede reescribir identificadores para mantener secuencias continuas hacia cada receptor. Normalmente no debería reconocer hacia arriba hasta que lo hayan hecho todos los receptores activos. El conjunto activo, su cambio en el tiempo y la correspondencia de identificadores forman parte de la evidencia. Un acuse agregado sin denominador sólo prueba que el intermediario produjo un acuse.
La negociación SDP del URI de extensión y de rtcp-fb tampoco demuestra uso ni éxito. Anuncia capacidad. Es distinta de una petición emitida, un estado conservado o una recuperación observada.
Diseñar para lo que el mensaje no sabe
La separación de capas de realidad propuesta por Heng Lu evita pedirle a la coordinación que suplante a la observación. Frame ID, gama y vector son símbolos intercambiados. Ventana y búfer de referencias son estado ejecutable y perecedero. Entrega, decodificación terminada, presentación y experiencia son resultados posteriores.
Una especificación inicial mínima debería guardar pareja de SSRC, época, identificador, FFR, gama, tiempos, ventana retenida, respuesta exacta, resincronización y referencia disponible en ambos extremos. Debe expresar “desconocido” cuando la ventana ya no sabe, en lugar de elegir pérdida o éxito por conveniencia.
Las pruebas con código real deben atrasar RTCP hasta superar la ventana, producir solapamientos parciales y nulos, envolver los 16 bits, fallar después de un positivo, cambiar SSRC, entrelazar cadenas, expulsar referencias y variar la audiencia de un SFU. Una herramienta que supera sólo el camino feliz todavía no ha probado la semántica que más importa durante una avería.
La respuesta de longitud cero no fue inútil. Informó con precisión del límite de memoria del receptor y evitó que el emisor confiara en referencias demasiado antiguas. El error fue pedirle que declarase un destino que ya no podía recordar. Los sistemas gobernables no rellenan ese silencio: lo preservan como incertidumbre verificable.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-avtcore-frame-acknowledgement/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/references/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-avtcore-frame-acknowledgement-01.txt
- https://www.ietf.org/archive/id/draft-ietf-avtcore-frame-acknowledgement-01.html
- https://www.ietf.org/archive/id/draft-ietf-avtcore-frame-acknowledgement-01.xml
- https://www.ietf.org/archive/id/draft-sprang-avtcore-frame-acknowledgement-02.txt
- https://datatracker.ietf.org/wg/avtcore/about/
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc4585.html
- https://www.rfc-editor.org/rfc/rfc8285.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.rfc-editor.org/rfc/rfc7656.html
- https://www.rfc-editor.org/rfc/rfc5104.html
- https://www.rfc-editor.org/rfc/rfc9627.html
- https://www.rfc-editor.org/rfc/rfc8083.html
- https://www.rfc-editor.org/rfc/rfc7201.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
