Resumen

  • draft-ietf-mlcodec-opus-extension-06 convierte el relleno no nulo en un contenedor opcional sin impedir que los decodificadores anteriores reproduzcan la capa base.
  • Un identificador reconocido no prueba una asociación válida con la trama, una decisión de admisión, una aplicación ni una mejora observada.
  • La compatibilidad, la negociación y el resultado deben conservar recibos distintos.

La trama equivocada

Supongamos que un paquete contiene varias tramas Opus. El receptor reconoce el identificador opcional, resuelve su longitud y no encuentra un desbordamiento. Sin embargo, el separador lo asocia con un índice que ya no existe. La norma propuesta exige ignorar todas las instancias asignadas a ese índice. El audio base puede salir sin interrupción. Un registro que diga únicamente «paquete decodificado» es verdadero, pero no responde la pregunta que importa: ¿qué ocurrió con la extensión?

La diferencia nace del diseño, no de una excepción accidental. RFC 6716 hace que el codificador escriba ceros en el relleno y que el decodificador acepte cualquier valor. El proyecto utiliza relleno no nulo para transportar extensiones. Un decodificador antiguo desecha esos bytes y procesa el flujo base. Uno extendido debe producir el mismo comportamiento que uno no extendido cuando no hay extensiones.

El objetivo es que una innovación opcional no rompa el formato establecido. Por eso la reproducción de base demuestra, como máximo, que el suelo de compatibilidad resistió. No demuestra que el techo funcional se alcanzó.

Límites que deciden el significado

Cada instancia comienza con un identificador de siete bits y la bandera L. Las extensiones cortas, de los IDs 3 a 31, llevan cero o un byte de datos. Las largas, de 32 a 127, pueden llevar una longitud arbitraria. En una extensión larga, L=0 suele consumir todo el relleno restante y solo puede aparecer una vez con ese significado. L=1 introduce una longitud explícita; el valor 255 permite continuarla en otro byte mientras el límite del paquete no se exceda.

Si la longitud anunciada sale del paquete, si ni siquiera puede leerse completa o si RTE necesita más carga de la disponible, el receptor debe ignorar el material infractor. No está autorizado a leer memoria vecina ni a inventar bytes. Esa regla de seguridad conserva la base, pero también crea un resultado parcial que debe quedar visible: el contenedor llegó y la extensión no se aplicó.

El ID estructural 1 separa asociaciones de trama. Sin carga avanza una posición; con carga puede avanzar varias. El índice jamás puede superar el número de tramas menos uno. La comprobación convierte una secuencia sintáctica en una afirmación temporal. Hasta que pasa, los datos opcionales no pertenecen a un lugar válido del audio.

Repetir no equivale a reconstruir sin prueba

El ID 2, Repeat These Extensions, evita repetir identificadores y separadores cuando un patrón reaparece en tramas posteriores. Después del marcador llegan nuevas cargas para las instancias repetidas. La colección de una sola trama puede quedar dividida en zonas no contiguas del paquete. Algunas extensiones cortas deben conservar el mismo uso de L; las largas repetidas tienen reglas específicas sobre longitudes explícitas y el último elemento.

El orden dentro de una trama es significativo y la definición de cada extensión puede limitar cantidad y posición. La equivalencia concedida al reordenamiento propio de RTE no autoriza cualquier permutación. Por ello, «encontré todos los IDs» no prueba que el receptor reconstruyó la misma secuencia que quiso enviar el codificador.

La telemetría debe conservar la secuencia antes y después de expandir RTE, la trama destino y el motivo de descarte. Sin ese recibo, un fallo temporal puede parecer una ausencia voluntaria de mejora.

Ignorar también es una decisión local

El proyecto obliga a ignorar extensiones no soportadas y seguir decodificando la base. Además, permite ignorar una extensión aunque el receptor la soporte técnicamente. Esa frase separa implementación de política. El código puede existir, pero estar desactivado; el presupuesto de CPU puede excluirlo; el perfil de aplicación puede no admitirlo; otra condición negociada puede faltar.

El codificador, por su parte, no puede degradar de forma perceptible la parte no extendida para un receptor antiguo. Se protege así la calidad base. Una salida aceptable no puede reutilizarse como prueba de que la capa opcional funcionó: el formato fue diseñado para que esa salida sobreviva justo cuando la capa opcional no funciona.

Los estados operativos mínimos son cinco: base aceptada; marco de extensión detectado; instancia validada; instancia admitida; efecto observado. Fusionarlos en «éxito» favorece una ilusión de cobertura.

Oferta y respuesta no son ejecución

El tipo audio/opus recibe dos listas propuestas. extensions declara IDs soportados por el receptor y sprop-extensions los del emisor. Los parámetros específicos usan extN-* y sprop-extN-*. Quien reconoce el mecanismo debe soportar los IDs estructurales 0, 1 y 2, aunque no aparezcan en las listas.

Los parámetros SDP deben especificarse de forma explícita y no copiarse ciegamente desde otra oferta o respuesta. Incluso ante un fallo de negociación, el receptor debe poder decodificar paquetes con extensiones desconocidas o no negociadas. Lo hace omitiéndolas, no ejecutándolas.

Así, que la sesión siga viva no demuestra acuerdo. Hace falta unir la oferta y la respuesta correctas con la versión del binario, su configuración, el paquete y la decisión por instancia. La capacidad declarada tiene fecha y propietario; no es una propiedad eterna del endpoint.

Registro, experimento y código

El proyecto propone un registro de IDs Opus. Cero, uno y dos son estructurales. Del 3 al 119 quedan sin asignar bajo Standards Action. Del 120 al 126 son experimentales, con una recomendación de anteponer número de experimento y versión y de evitar colisiones. El 127 reserva una extensión futura del propio mecanismo.

El número ayuda a coordinar, pero no transporta por sí solo una semántica ejecutable. Dos pruebas pueden colisionar o interpretar versiones distintas. Una asignación estable puede faltar en el binario. Un binario capaz puede mantenerla apagada. El registro aporta autoridad documental; la ejecución necesita evidencia local.

El borrador vecino de Opus HD muestra una posible aplicación: más resolución y una capa por encima de 20 kHz, con procesamiento a 96 kHz. Cita código y una opción de compilación. Nada de ello prueba que una sesión concreta lo haya habilitado o que un oyente haya recibido una mejora. Este artículo no juzga su calidad; conserva la frontera entre el contenedor y su consumidor.

Estado y límites de la investigación

La revisión 06 es un Internet-Draft activo de mlcodec, fechado el 23 de julio de 2026 y actualizado en Datatracker el 27 de agosto. Está en última llamada del grupo, pretende ser Proposed Standard y expira el 24 de enero de 2027. No es un RFC y puede cambiar o no publicarse.

No se probó ningún codificador, decodificador, navegador, producto, operador ni sesión. No hay en el paquete de evidencia incidentes, ataques, colisiones observadas ni mediciones de memoria, procesador, tasa, espectro o escucha. Los ejemplos son construcciones analíticas.

La afirmación permitida es estrecha: la reproducción base observa la compatibilidad base. Cualquier afirmación sobre una extensión debe ascender por su propia cadena de pruebas.

Fuentes