Resumo

  • draft-ietf-mlcodec-opus-extension-06 propõe listas de capacidade para emissor e receptor, mas mantém a obrigação de decodificar a base mesmo diante de extensões desconhecidas ou não negociadas.
  • Uma sessão que continua não comprova que os parâmetros vieram da oferta correta, que o código estava habilitado, que a instância passou pelos limites nem que alterou a saída.
  • A cadeia de evidência precisa separar declaração, parsing, admissão, aplicação por quadro e resultado observado.

A oferta que sobreviveu mais que sua origem

Imagine um serviço que copia parâmetros SDP de uma sessão anterior. A nova chamada anuncia o mesmo conjunto de IDs; o receptor recebe pacotes com a extensão e o áudio básico sai normalmente. O operador vê a lista e a chamada ativa e presume que a função opcional foi negociada. O rascunho proíbe exatamente o atalho de carregar parâmetros cegamente de outra oferta ou resposta. Eles devem ser especificados de forma explícita.

Mesmo uma negociação malsucedida não precisa derrubar a chamada. O receptor deve conseguir decodificar extensões desconhecidas ou não negociadas, descartando-as com segurança e preservando a base. A continuidade, portanto, não corrige a proveniência do SDP. Ela mascara a ausência da função opcional por desenho.

Um contêiner dentro do preenchimento

O RFC 6716 determina zeros no preenchimento produzido pelo codificador, mas exige que o decodificador aceite qualquer valor. O rascunho usa preenchimento não zero como moldura de extensão. Um decodificador antigo simplesmente o descarta. Um decodificador novo reconhece a moldura, mas deve se comportar como o antigo quando não houver extensão.

O codificador tampouco pode piorar de modo perceptível a parte não estendida para receptores antigos. Essa regra conserva um piso comum de qualidade. Ela não garante a camada extra. Se o áudio básico está bom, o que foi observado é o piso.

Cada instância começa com ID de sete bits e a bandeira L. IDs curtos levam zero ou um byte; IDs longos podem levar dados de comprimento arbitrário. Para um longo, L=0 normalmente ocupa o restante do preenchimento e só pode ter esse papel uma vez no pacote. L=1 traz um indicador explícito, extensível por bytes 255 dentro do limite do pacote.

Comprimento além da borda, indicador incompleto ou dados insuficientes para RTE obrigam o descarte da parte ofensora. O receptor não deve ultrapassar memória nem fabricar conteúdo. A base pode continuar. “Pacote aceito” e “extensão rejeitada” são resultados simultâneos, não contraditórios.

Quadro, ordem e repetição

Extensões pertencem a quadros Opus. O ID estrutural 1 é o separador: pode avançar um quadro ou uma quantidade indicada. O índice resultante precisa permanecer abaixo da quantidade de quadros; associações fora desse intervalo são ignoradas.

O ID 2, Repeat These Extensions, repete uma sequência em quadros posteriores com novos payloads. Isso economiza identificadores e separadores, mas torna a reconstrução indispensável. O conjunto de um quadro pode não ser contíguo. A ordem dentro do quadro é significativa, e a definição da extensão pode limitar multiplicidade e posição. A equivalência prevista para a reordenação de RTE não autoriza qualquer ordem.

Encontrar IDs esperados não comprova a linha temporal esperada. O recibo precisa mostrar a sequência original, a sequência expandida, o quadro destino, os bytes consumidos e a decisão de aplicação.

Implementado não quer dizer admitido

Extensões não suportadas devem ser ignoradas. O texto também permite ignorar uma extensão tecnicamente suportada. A distinção é operacional: o módulo pode existir, mas estar desabilitado; um limite de CPU pode vetá-lo; o perfil do aplicativo pode excluí-lo; outro parâmetro pode faltar.

Por isso, um catálogo de capacidades não substitui telemetria de execução. É preciso diferenciar código disponível, recurso habilitado, sessão autorizada, instância válida, instância aplicada e efeito produzido. O mesmo vale para segurança: recuar sem ultrapassar memória prova um comportamento defensivo, não a correção da extensão.

O que as listas SDP realmente dizem

O parâmetro extensions enumera IDs suportados pelo receptor; sprop-extensions, pelo emissor. Parâmetros próprios usam extN-* e sprop-extN-*. Receptores que reconhecem o mecanismo devem suportar os IDs estruturais 0, 1 e 2, sem precisar listá-los.

Parâmetros desconhecidos associados a uma extensão são ignorados quando o ID correspondente não está na lista. Isso ajuda a limitar interpretação, mas não executa nada. Para provar uso, o operador deve ligar oferta, resposta, valores escolhidos, build, configuração, pacote e resultado ao mesmo contexto.

A pergunta profissional não é “a chamada ficou ativa?”. É “entre as chamadas elegíveis, em quantas a extensão foi explicitamente acordada, validada, admitida e observada?”. Sem esses denominadores, a disponibilidade da base vira uma cobertura estatística para a camada opcional.

Número público e experiência local

O rascunho propõe um registro de IDs de sete bits. Zero, um e dois são estruturais. De 3 a 119, a política é Standards Action. De 120 a 126, Experimental Use, com prefixo recomendado de experimento e versão e recomendação de evitar colisões. O 127 fica reservado para evolução do mecanismo.

O número organiza documentação; não materializa semântica no processo. Experimentos podem colidir, versões podem discordar, uma atribuição estável pode não existir no build local. O estado do registro, a definição, a versão, o binário e a decisão precisam ser separados.

O rascunho adjacente Opus HD exemplifica uma função que usaria o contêiner: mais resolução, conteúdo acima de 20 kHz e processamento a 96 kHz. Ele cita código e uma opção de compilação. Isso não comprova ativação em um endpoint, negociação em uma sessão nem melhoria percebida. Este texto não mede Opus HD; usa o caso para mostrar a distância entre formato e resultado.

Estado e incerteza

A revisão 06 é um Internet-Draft ativo do grupo mlcodec, datado de 23 de julho de 2026, atualizado no Datatracker em 27 de agosto, em WG Last Call, com status pretendido Proposed Standard e expiração em 24 de janeiro de 2027. Não é RFC e pode mudar ou não ser publicado.

Nenhum codificador, decodificador, navegador, produto, operadora ou chamada real foi testado. Não há incidente, ataque, colisão observada, medição de memória, CPU, taxa, espectro ou escuta. Os exemplos são analíticos.

Se o áudio básico tocou, há observação do áudio básico. Para a extensão, a prova começa de novo.

Fontes