Resumo

  • O RFC 3555 reuniu uma regra geral de registro, um mapa de tipos de mídia para SDP e registros concretos do perfil RTP; seus sucessores separaram esses objetos sem apagar o mecanismo.
  • A continuidade do nome no catálogo não prova que uma implementação aceita os parâmetros, que a sessão vinculou corretamente o número dinâmico ou que o fluxo foi decodificado.

Em julho de 2003, o RFC 3555 fez duas tarefas. Explicou como registrar formatos de payload RTP como subtipos de mídia e, no mesmo texto, registrou os formatos do perfil de áudio e vídeo do RFC 3551. Também estabeleceu como uma expressão de tipo de mídia seria transformada em SDP.

Essa combinação era prática, mas juntava três autoridades. A regra de cadastro dizia o que uma proposta precisava declarar. As entradas concretas atribuíam nomes a formatos existentes. A especificação de cada payload mantinha o significado dos parâmetros no fio. Quando os procedimentos gerais de tipos de mídia mudaram, não era necessário reinventar todos os codecs para atualizar o primeiro objeto.

O mesmo mecanismo em documentos separados

Em 2007, o RFC 4855 e o RFC 4856 tornaram o RFC 3555 obsoleto. O RFC 4855 reteve a regra de registro e o mapa para SDP. O RFC 4856 recebeu os registros concretos do perfil e afirmou que a atualização de formato não fazia mudança técnica neles. Alguns registros ficaram fora desse companheiro porque seus próprios RFCs de payload deveriam mantê-los; isso não significava que a simples omissão os tivesse apagado.

A divisão tornou a proveniência mais legível. Uma entrada atual pode apontar ao RFC 4856, enquanto o procedimento está no RFC 4855 e a sintaxe atual de SDP no RFC 8866. Reconstruir a autoridade exige seguir as referências, não presumir que o documento mais recente controla todas as camadas.

O catálogo IANA congelado para esta pesquisa, atualizado em 6 de outubro de 2026, tem 165 entradas de áudio e 97 de vídeo. Vinte citam diretamente o RFC 4856. audio/L16, audio/PCMA e audio/PCMU são exemplos. Esses fatos mostram continuidade administrativa; não medem uso, instalação ou interoperabilidade.

Um nome desmontado em campos

O exemplo histórico começa com audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15. O mapa não copia essa linha. audio vai para a linha m=. L16, a frequência do relógio RTP e os dois canais formam a=rtpmap:97 L16/48000/2. emphasis entra em a=fmtp:97. A recomendação de duração vira a=ptime:5.

O 97 pertence à sessão. Ele não é o número universal de L16. Outra sessão pode atribuir 97 a outro formato ou usar outro número para o mesmo L16. Sem a descrição da sessão, um arquivo de pacotes que preserve só o número perdeu parte da identidade operacional.

O fmtp também não é uma área livre. Os parâmetros permitidos vêm da especificação do payload. O registro do subtipo pode explicar o transporte do valor, mas não aumentar o conjunto sem uma revisão correspondente do RFC do formato. Um operador que introduz uma chave privada pode obter compatibilidade bilateral, porém não converte essa chave em padrão.

Compartilhar o subtipo exigia compartilhar o contrato

O RFC 4855 esclareceu uma situação que o texto de 2003 deixava menos delimitada. Um mesmo nome de subtipo não deve servir ao RTP e a um formato de arquivo não RTP se os dados não forem equivalentes pelo teste definido ou se os parâmetros obrigatórios forem diferentes. Nesses casos, são necessários tipos separados; o sufixo +rtp é sugerido para um nome relacionado.

Isso impede que a identidade nominal force uma equivalência inexistente. Um nome comum só é seguro quando o conteúdo e as condições mínimas permanecem comuns. Caso contrário, o nome encobre uma bifurcação.

A evidência operacional continua depois do registro. É preciso validar o modo de transporte, aplicar o mapa correto, confirmar a associação local do número de payload, verificar que ambos os extremos implementam o mesmo formato, observar os pacotes e obter resultado do decodificador. Nem ptime confirma a duração efetiva de cada pacote, nem a presença de rate confirma reprodução, nem a linha IANA confirma software.

O legado do RFC 3555 é, portanto, uma arquitetura de passagem responsável. Nomes podem sobreviver à reorganização de documentos e atravessar protocolos. Para isso, cada transformação precisa deixar recibos suficientes para que ninguém confunda manutenção do catálogo com execução do sistema.

Fontes