Resumo

  • O RFC 3119 mandava usar mp3 como nome no SDP, mas o subtipo registrado e o exemplo rtpmap adjacente usavam mpa-robust; o RFC 5219 tornou o nome da codificação consistente.
  • O sucessor manteve o projeto de payload RTP baseado em ADU e descreveu as alterações do pseudocódigo como esclarecimentos menores e não normativos. O registro dos padrões não mostra se algum software em operação adotou o nome divergente ou se uma sessão falhou.

Dois nomes no mesmo trecho

A contradição é fácil de não perceber. Publicado em 2001, o RFC 3119 registra mpa-robust como subtipo de mídia para seu formato MP3 sobre RTP. Mas a seção de uso do SDP determina que o nome da codificação seja mp3. Logo em seguida, o exemplo atribui o tipo de payload dinâmico 121 e escreve a=rtpmap:121 mpa-robust/90000.

As linhas descrevem o mesmo formato em pontos diferentes. O RTP transporta números de tipo de payload; para um número dinâmico, o atributo SDP rtpmap informa ao outro lado qual codificação e frequência de relógio ele representa. O RFC 4566 define esse mapeamento. Assim, o RFC 3119 apresentava dois nomes incompatíveis para a descrição da sessão, embora o subtipo de mídia e o exemplo de mapeamento concordassem entre si.

Não é apenas uma questão de grafia. Um número dinâmico não explica sozinho o conteúdo dos pacotes. As pontas precisam compartilhar o mapeamento entre o número carregado pelos pacotes RTP e a codificação esperada pelo receptor. O formato do payload pode ser coerente, mesmo quando a negociação que o descreve não é. O documento comprova um defeito na especificação, não a reação de equipamentos reais.

Por que outro formato RTP

O projeto original tratava de uma propriedade específica do MP3 Layer III. Um frame pode apontar para dados codificados em frames anteriores e, por isso, nem sempre é uma unidade independente para decodificação. O RFC 3119 argumentava que alinhar pacotes RTP aos frames podia tornar inúteis dados de outros frames que chegaram intactos quando um pacote se perdia.

A alternativa reorganizava o fluxo em unidades de dados de aplicação (ADUs). Cada ADU era precedida por um descritor com seu tamanho e a indicação de que os dados continuavam de outro pacote. O emissor também podia intercalar ADUs para distribuir unidades consecutivas por pacotes não consecutivos. Não era simplesmente acrescentar redundância: a proposta reposicionava os limites dos pacotes em relação às unidades que o decodificador processa, preservando os dados codificados.

Publicado em fevereiro de 2008, o RFC 5219 manteve essa abordagem básica. Sua introdução volta a explicar o ponteiro para trás, as ADUs, os descritores e a intercalação opcional. O resumo informa que ele obsoleta o RFC 3119 para corrigir erros tipográficos na seção SDP e nos apêndices de pseudocódigo. O Apêndice C detalha: a principal mudança é corrigir o nome da codificação no SDP; os Apêndices A e B recebem pequenos consertos e esclarecimentos em pseudocódigo não normativo.

A correção é explícita. O RFC 5219 exige mpa-robust, em linha com o subtipo de mídia registrado, e seu exemplo continua mapeando o tipo dinâmico 121 para mpa-robust/90000. Uma errata verificada pelo editor dos RFCs também registra a discrepância anterior e reparos em exemplos: backpointer é valor, não tamanho; uma variável deve ser prevADU, e não curADU; e dois limites de array na seção B.2 passam de 32 para 256. São ajustes na receita escrita, não evidência de que payloads em uso mudaram em 2008.

Número de RFC não é relatório de incidente

O RFC 5219 é um registro útil de como padrões podem ser corrigidos em mais de uma camada. O nome SDP integra a orientação normativa de descrição de sessão: a revisão corrige como os participantes devem chamar a codificação. As mudanças nos apêndices tratam de pseudocódigo que o próprio RFC 5219 classifica como não normativo. Nenhum desses fatos mede a dimensão de um problema operacional.

Os documentos não trazem um levantamento de implementações, captura de pacotes, registro de chamadas malsucedidas, nota de versão de fornecedor nem teste comparativo. Não dizem que algum equipamento anunciou mp3, que outro o rejeitou ou que a grafia corrigida melhorou a interoperabilidade em implantações medidas. A aceitação de uma errata pelo editor comprova um defeito documental, não a frequência com que um software o reproduziu.

Esse é o limite histórico que importa. O RFC 5219 substituiu o anterior porque a instrução sobre descrição de sessão precisava ser corrigida e parte da orientação de implementação precisava de precisão. O modelo de payload com ADU foi mantido. O histórico de padrões mostra o que os autores corrigiram; saber se isso fez diferença em sistemas reais exige evidências separadas, vindas de implementações e sessões.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3119.html
  2. https://www.rfc-editor.org/info/rfc3119/
  3. https://www.rfc-editor.org/rfc/rfc5219.html
  4. https://www.rfc-editor.org/info/rfc5219/
  5. https://datatracker.ietf.org/doc/rfc5219/
  6. https://www.rfc-editor.org/errata/eid331
  7. https://www.rfc-editor.org/rfc/rfc4566.html
  8. https://www.rfc-editor.org/rfc/rfc2250.html
  9. https://www.rfc-editor.org/rfc/rfc3550.html
  10. https://www.rfc-editor.org/rfc/rfc3551.html
  11. https://www.rfc-editor.org/rfc/rfc2736.html