Summary

  • draft-ietf-mlcodec-opus-extension-06 uses Opus padding to carry optional extensions while requiring old and extended decoders to preserve the base layer.
  • A packet that produces base audio does not prove that an extension was negotiated, parsed within bounds, associated with the intended frame, admitted by local policy, applied or heard.
  • Operators need separate receipts for the base decode, extension framing, identifier semantics, offer/answer state, per-frame application and output observation.

The useful ambiguity

Imagine a call in which the sound never stops. Packets arrive, the legacy decoder keeps producing audio and an upgraded decoder produces the same base waveform. The service dashboard marks the media path healthy. Yet a promised optional enhancement is absent. Nothing in the uninterrupted base sound identifies whether the sender omitted the extension, the receiver did not support its identifier, a length crossed the packet boundary, a frame index was out of range, local policy ignored a supported extension or the enhancement ran without producing the expected output.

That is not a defect in the compatibility design. It is the consequence of succeeding at it. The draft updates the Opus format by using a property already present in RFC 6716: encoders set padding bytes to zero, while decoders accept any padding-byte value. Non-zero padding can therefore carry extension framing. A decoder that predates the extension mechanism discards those bytes and continues with the base Opus packet. An extended decoder must also behave like a non-extended decoder when no extension is present.

The minimum promise is graceful coexistence. The old path should keep working. The promise is not that every extension reaches its final effect.

What the packet actually says

An extension instance begins with a seven-bit identifier and the one-bit L flag. It may then carry a length indicator and extension data. Short identifiers from 3 through 31 have zero or one data byte. Long identifiers from 32 through 127 can carry arbitrary-length data. For a long extension, L=0 normally consumes the rest of the padding; L=1 introduces an explicit length. A length byte of 255 extends the length into another byte, and that pattern may continue only while the packet boundary is respected.

Those details are not merely compact encoding choices. They determine what a receiver is entitled to read. If a signalled length would cross the packet boundary, if the length itself cannot be decoded inside that boundary, or if Repeat These Extensions lacks enough bytes for the repeated payloads, the offending material must be ignored. The base packet remains available. “The packet decoded” can therefore be true at the same time as “the optional data was rejected.”

Extensions also belong to frames, not just packets. ID 1 is a frame separator. Its flag either advances one frame or uses a following byte to advance farther. An association beyond the number of Opus frames is ignored. A parser can recognize the extension grammar perfectly and still decline an instance because its asserted destination does not exist.

ID 2, Repeat These Extensions, compresses a pattern that recurs over later frames. It repeats selected identifiers while carrying new payloads. This makes the complete collection for one frame potentially non-contiguous in the packet. Extension order within a frame can matter, definitions can restrict multiplicity, and only the reordering produced by the repeat mechanism receives the specified equivalence. Seeing all expected identifiers is therefore weaker than reconstructing the expected per-frame sequence.

Ignore is a compatibility action, not an application receipt

The draft requires a decoder to ignore extensions it does not support and continue as though they were absent. More unusually—and operationally more important—it permits a decoder to ignore an extension even when it technically supports it. Support is not the same as admission. A local build may contain code that remains disabled. A resource budget may reject work. An application profile may decline an optional feature. An implementation may treat support as conditional on a negotiated parameter or another extension.

The encoder has a corresponding duty: it must not change the non-extension part in a way that noticeably reduces quality for a non-extended decoder. This protects the compatibility floor. It does not establish an enhancement ceiling. A good base result proves that the floor held for the observed output; it says nothing by itself about the optional path.

That distinction should shape telemetry. A single “decode success” counter collapses two materially different results. One receipt should say whether RFC 6716 base data decoded. Another should record whether non-zero padding was recognized as extension framing. Further receipts should state which identifiers were found, which instances passed bounds and frame-association checks, which definition and experiment version governed them, which were admitted, and which actually changed decoder state or output.

Negotiation remains declarative

The draft proposes extensions to list receiver-supported IDs and sprop-extensions to list sender-supported IDs in the audio/opus media type. Extension-specific parameters use extN-* and sprop-extN-*. Structural identifiers 0, 1 and 2 are mandatory for any receiver that recognizes the extension mechanism and need not appear in those lists.

These declarations narrow expectations; they do not execute an extension. Unknown extension-specific parameters are ignored unless the corresponding ID is listed. SDP parameters must be specified explicitly and must not be copied blindly from another offer or answer. Even if negotiation fails, the receiver must still decode packets containing unknown or non-negotiated extensions by safely skipping what it cannot use.

That fallback is essential to interoperability, but it makes a successful session a poor substitute for negotiation evidence. A call can continue because the base layer is designed to continue. To establish extension use, the record must bind the offer, answer, chosen parameter set, local implementation state and the actual packet instances to the same session and time.

Registry labels do not supply running semantics

The draft proposes a new seven-bit Opus Extension IDs registry. IDs 0, 1 and 2 are structural. IDs 3 through 119 are unassigned under Standards Action. IDs 120 through 126 are for experiments, with a recommended experiment-and-version prefix and a recommendation to avoid collisions. ID 127 is reserved so a future mechanism can be skipped using an already defined length rule.

A number in any of those ranges is not a portable verdict. An experimental value can collide. A stable assignment can be implemented incorrectly. Two endpoints can recognize the same number under different experimental versions. The registry can establish which public specification owns a value; it cannot show what bytes a running endpoint interpreted or what effect followed.

The adjacent Opus HD draft illustrates the separation. It proposes a scalable quality layer with added resolution and content above 20 kHz. It also points to code and a build option. Those facts establish a specification and an implementation surface. They do not prove that a particular endpoint enabled the option, negotiated the extension, received valid enhancement data or produced a 96 kHz result. This Article does not assess Opus HD performance; it uses the draft only to show why the generic container’s receipts matter.

Draft status and uncertainty

Revision 06 is an active mlcodec Working Group Internet-Draft dated 23 July 2026, last updated 27 August, in WG Last Call with intended status Proposed Standard. It expires on 24 January 2027 and is not an RFC. The text may change, be replaced or never be published. WG Last Call does not prove implementation or deployment.

No encoder, decoder, browser, endpoint, vendor, operator or live session was tested for this report. The evidence contains no malformed-packet incident, crash, downgrade, identifier collision, CPU or memory measurement, bitrate result, frequency-response test or listening study. The scenarios are analytical. They identify the proof required; they do not allege a failure.

The most defensible conclusion is narrow: if base audio played, the compatibility floor was observed. Any claim about an extension needs the rest of the ladder.

Sources