Resumen

  • En RFC 5372, mh_id=0 ordena al receptor no guardar la cabecera principal y no compensar una cabecera perdida. Convertir cero en ausencia o en un valor por defecto revierte esa decisión.
  • Los valores activos del uno al siete tampoco son identidades permanentes. El contador vuelve a uno y seis actualizaciones perdidas pueden hacer coincidir una cabecera antigua con un valor nuevo.
  • Negociar mhc, recibir una cabecera completa, conservar su procedencia, intentar decodificar y producir una imagen son pruebas separadas. La prioridad clasifica importancia, pero no garantiza entrega.

Cero era una negativa operativa

Muchos sistemas tratan cero como inicialización, vacío o equivalente de “sin dato”. RFC 5372 no lo hace. Dentro del mecanismo de compensación de cabecera principal, cero tiene una instrucción concreta: no guardar la cabecera y no reutilizar una cabecera anterior cuando la actual se pierda.

La diferencia importa porque una capa de normalización puede borrar la intención antes de que llegue al decodificador. Si un colector convierte 0 en null, otra capa puede rellenar el campo con el último valor conocido. Si una base de datos aplica un valor predeterminado, el panel puede mostrar continuidad donde el emisor indicó abstención. Si un algoritmo interpreta cero como la primera entrada de una tabla, crea una identidad que el protocolo reservó para impedir la compensación.

La regla no afirma por qué el emisor eligió cero. No prueba que el flujo sea inseguro ni que el decodificador vaya a fallar. Define el límite de una técnica: en ese estado, la recuperación mediante una cabecera guardada no está autorizada por el mecanismo.

Un sistema de evidencia debe mantener cero como valor significativo. Debe distinguirlo de campo no aplicable, extensión no soportada, negociación rechazada, cabecera completa aún no recibida y caché invalidada después de una incoherencia. Todos pueden terminar sin compensación, pero no dicen lo mismo.

La caché empezaba con una cabecera completa

El mecanismo existe porque las imágenes sucesivas de vídeo JPEG 2000 suelen mantener parámetros de codificación. Cuando una cabecera se pierde, el receptor puede usar la última cabecera completa si el identificador coincide.

La palabra “completa” impide convertir cualquier paquete en autoridad. RFC 5372 indica que, al recibir la cabecera principal entera, el receptor debe conservar el número de secuencia RTP, mh_id y la propia cabecera. Solo debería guardar la última cabecera recibida completamente.

Una captura del campo no demuestra que ese estado exista. Tampoco lo hace el último fragmento de una cabecera, una autenticación correcta del paquete o una respuesta SDP que acepte la funcionalidad. El objeto reutilizable nace cuando se han recibido los bytes necesarios y se conserva su procedencia.

El registro mínimo incluye la sesión y fuente RTP, el número de secuencia, el identificador, una huella local de la cabecera, el momento de recepción y la causa de cada reemplazo o borrado. Sin esos datos, una fila que diga mh_id=4 conserva una coordenada pero no el objeto al que apuntaba.

La regla de cero refuerza este modelo. Incluso una cabecera completa no debe entrar en la caché bajo ese valor. La disponibilidad de bytes no crea por sí sola permiso para reutilizarlos.

Del uno al siete no había siete identidades eternas

El campo ocupa tres bits, pero RFC 5372 utiliza siete valores activos. Empieza en uno. El emisor mantiene la misma cifra mientras los parámetros definidos no cambian. Cuando cambia la cabecera y se transmite una nueva, incrementa el valor. Después de siete, vuelve a uno.

La especificación aclara que el identificador y los parámetros de codificación no tienen una relación uno a uno. La cifra señala continuidad respecto del cuadro anterior; no es una huella de contenido.

El conjunto de parámetros incluye SIZ y los segmentos funcionales COD, COC, RGN, QCD, QCC y POC. Una coincidencia numérica no contiene esos segmentos. No demuestra igualdad de bytes ni actualidad del estado guardado. Solo activa una comparación eficiente dentro de un historial que el receptor debe haber observado.

El reciclaje es seguro cuando la historia está presente. Si cada cambio llega con su cabecera completa, el receptor sustituye el estado anterior. El problema surge cuando desaparecen precisamente los eventos que habrían invalidado la caché.

Seis cambios invisibles hicieron reaparecer el pasado

La sección de seguridad describe el límite: si una pérdida severa, aleatoria o intencionada, elimina seis actualizaciones sucesivas de la cabecera, el decodificador puede intentar trabajar con una cabecera incorrecta.

Supongamos que la caché contiene el valor uno. El emisor cambia parámetros y envía dos; ese paquete se pierde. Hace lo mismo con tres, cuatro, cinco, seis y siete. Cada ausencia oculta una transición de autoridad. En el siguiente cambio, el contador regresa a uno. El receptor observa igualdad con su caché, aunque entre ambos unos exista un ciclo completo que no vio.

No es una colisión criptográfica. Es reutilización deliberada de un espacio pequeño combinada con evidencia ausente. El protocolo la reconoce y limita su afirmación.

Por eso una tasa general de pérdida resulta insuficiente. Lo relevante es qué se perdió. Seis paquetes de datos repartidos pueden degradar la imagen. Seis cabeceras de transición consecutivas pueden conservar una falsa continuidad de estado.

La protección de integridad también tiene un alcance específico. Puede verificar los paquetes que llegan y su origen según el mecanismo utilizado. No certifica eventos que faltan. Un atacante capaz de suprimir selectivamente actualizaciones no necesita modificar el valor que finalmente vuelve a uno.

La igualdad permitía probar, no declarar frescura

Cuando falta la cabecera actual y el identificador coincide con el guardado, el receptor puede usar la cabecera previa para decodificar. Esa autorización es una optimización basada en continuidad probable.

No equivale a un recibo de frescura. RFC 5372 dice expresamente que identificador y parámetros no son una asociación permanente. Tampoco promete que toda combinación incorrecta será rechazada antes de consumir recursos o producir salida.

El decodificador podría detectar una incoherencia. En ese caso se recomienda borrar el identificador y la cabecera guardados. El borrado evita nuevas decisiones sobre estado sospechoso, pero no recupera la cabecera correcta.

El seguimiento necesita separar:

  1. la coincidencia del identificador;
  2. la decisión de compensar;
  3. la admisión de la combinación por el decodificador;
  4. el final del proceso sin error expuesto;
  5. la producción de un cuadro;
  6. la entrega o visualización del cuadro cuando ese sea el resultado requerido.

Una sola métrica de “éxito de caché” no puede representar esas etapas. Si cuenta la igualdad, incluye intentos fallidos. Si cuenta solo ausencia de error, puede omitir salidas degradadas. Si cuenta cuadros producidos, aún no prueba que llegaron al consumidor final.

Borrar estado no restauraba historia

La recomendación de limpiar la caché después de una incoherencia es un mecanismo de contención. Conviene registrar la acción como tal.

El evento debería indicar qué cabecera se usó, de qué secuencia procedía, qué identificador actual provocó la selección, qué error informó el decodificador y si el borrado se completó. Después debe observarse la adquisición de una nueva cabecera completa.

Sin esa última prueba, un contador “caché limpiada” puede parecer recuperación aunque el receptor siga sin contexto útil. La disponibilidad vuelve cuando llega autoridad nueva, no cuando desaparece la antigua.

También conviene invalidar en límites que el protocolo de tres bits no puede describir por sí solo: cambio de fuente, reinicio, nueva negociación, sustitución del codificador o discontinuidad de sesión. La política exacta es local y debe presentarse como tal, no atribuirse a la RFC.

mhc negociaba posibilidad, no inventario

El parámetro mhc lleva la técnica a SDP. La oferta usa uno cuando propone compensación. Una respuesta que la acepta refleja esa capacidad. Los ejemplos de RFC 5372 muestran además que el receptor puede contestar cero y aceptar otras propiedades del formato.

El intercambio demuestra una decisión de interoperabilidad. No contiene la lista de cabeceras recibidas ni la huella del estado local. Dos receptores que aceptaron la misma oferta pueden encontrarse en situaciones diferentes: uno tiene una cabecera completa reciente; otro perdió la inicial; un tercero invalidó la suya después de un error.

Los informes deben enlazar el acuerdo SDP con el contexto RTP exacto y con los eventos del receptor. Si una renegociación cambia el payload o reinicia la fuente, la caché antigua no debe heredar autoridad por mera proximidad temporal.

Configuración, ejecución y resultado son capas distintas. mhc=1 responde a la primera.

La prioridad cero era importante, no invulnerable

RFC 5372 también activa el byte de prioridad. El valor cero se reserva para cargas que contienen una cabecera principal o de tile-part. Del uno al 255, un número menor representa mayor importancia.

Esta prioridad no debe confundirse con mh_id=0. Son campos y semánticas diferentes. En el identificador, cero desactiva guardar y compensar. En prioridad, cero marca contenido de cabecera como lo más importante.

La tabla predeterminada sigue el número de paquete JPEG 2000 y debe ser soportada por las implementaciones de la extensión. Las tablas por progresión, capa, resolución y componente son opcionales. El parámetro pt permite proponer varias y seleccionar una.

El valor describe el codestream bajo esa tabla. No reserva capacidad de red. Una cabecera de prioridad cero puede perderse. Su clasificación explica por qué merece protección, no prueba que esa protección existió o funcionó.

Cuando varias unidades comparten un payload RTP, se usa la menor cifra, es decir, la mayor importancia entre ellas. Esa agregación tampoco convierte el paquete en un recibo de todas las contribuciones. Indica cómo tratar el conjunto.

Compatibilidad no significaba observación uniforme

La extensión es opcional sobre RFC 5371. Un receptor básico ignora de forma segura mh_id y prioridad. En un grupo multicast, el emisor puede usar los mecanismos aunque un miembro no los soporte.

La misma captura produce entonces significados diferentes según el receptor. Uno interpreta cero como prohibición de caché y otro no activa semántica alguna para el campo. Uno aplica la tabla pt y otro procesa el flujo sin ella.

No debe inferirse comportamiento de receptor a partir de intención del emisor. La telemetría necesita versión de implementación, capacidad negociada y decisión real. Un informe por grupo debe conservar las diferencias en lugar de promediar resultados incompatibles.

Un modelo de estados que no pierde el cero

La automatización puede usar una máquina de estados explícita:

  • extensión no activa;
  • activa sin cabecera completa;
  • activa con mh_id=0, sin almacenamiento ni compensación;
  • activa con cabecera completa y valor no nulo;
  • transición observada, esperando nueva cabecera completa;
  • compensación intentada;
  • incoherencia detectada y caché invalidada;
  • nueva cabecera completa adquirida.

Cada transición debe estar respaldada por un evento. La ausencia de un evento no autoriza saltar a continuidad. Un hueco de secuencia mantiene incertidumbre sobre cambios no observados.

Antes de compensar, el sistema debe comprobar la sesión, la fuente, el acuerdo mhc, el valor no nulo, la existencia de una cabecera completa, la ausencia de invalidación y la procedencia del objeto. Después debe capturar el resultado del decodificador y la salida.

El propósito no es impedir toda reutilización. Es impedir que la eficiencia del mecanismo amplíe silenciosamente la autoridad de sus señales.