Resumo

  • O RFC 5577 substituiu a especificação anterior de payload RTP para aceitar o áudio de 14 kHz do Anexo C do G.722.1, o clock de amostragem de 32 kHz e uma taxa de 48 kbit/s.
  • Não determinou uma ruptura imediata: recomendou que a configuração antiga de 16 kHz continuasse sendo oferecida para interoperabilidade e exigiu a declaração, em SDP, de cada combinação de clock e taxa de bits que se pretendesse usar.

A especificação sucessora não apagou os terminais da anterior

Publicado em julho de 2009, o cabeçalho do RFC 5577 diz “Obsoletes: 3047”. A frase pode sugerir uma troca instantânea: uma especificação sai, outra entra. Mas a seção sobre interoperabilidade descreve uma transição mais cuidadosa. O RFC 3047 definia o G.722.1 com clock de amostragem de 16 kHz. A revisão seguinte acrescentou suporte ao áudio super-wideband do Anexo C da recomendação revisada da ITU-T: a largura de banda do áudio passou a 14 kHz, surgiu uma configuração com clock de 32 kHz e entrou a taxa de 48 kbit/s.

Esses números não medem a mesma coisa. Os 14 kHz descrevem a largura de banda do áudio codificado; 16 ou 32 kHz é o clock de amostragem usado nos timestamps RTP; 24, 32 ou 48 kbit/s é a taxa do codec. O RFC 5577 não os condensou em um único controle de “qualidade”. A sinalização da sessão serve para descrever uma combinação utilizável.

O fluxo de bits do codec não avisa, dentro da própria banda, quando a taxa muda. Por isso, o RFC 5577 exige sinalização separada e mantém constante a taxa de bits para cada valor de payload type RTP. Uma aplicação pode alternar configurações entre pacotes, mas precisa usar valores distintos de payload type. Em SDP, a=rtpmap identifica a codificação e o clock; a=fmtp informa a taxa de bits. Os dois campos definem a configuração que está sendo proposta ao outro lado.

O modelo Offer/Answer torna essa declaração operacional. O RFC 5577 exige que a oferta liste cada configuração que o emissor pretende usar. Em seguida, aponta a lacuna de compatibilidade sem rodeios: o RFC 3047 só oferecia o clock de 16 kHz, portanto um sistema que quisesse interoperar deveria oferecer também um payload type a 16 kHz. O exemplo separa a opção 16 kHz/24 kbit/s da opção 32 kHz/48 kbit/s por meio de payload types diferentes.

Isso não significa que todo terminal antigo pudesse negociar sem problemas, nem que a configuração nova recuasse automaticamente para a antiga. Uma oferta enumera possibilidades suportadas; não prova a resposta do outro terminal nem que o áudio chegou ao ouvinte. O receptor ainda precisa escolher uma configuração que suporte e a sessão precisa transportar o perfil acordado. O RFC 5577 preservou um caminho, mas não certificou quem o percorreu.

A estrutura do pacote manteve outra fronteira. Os quadros continuaram com 20 milissegundos. Nas taxas padronizadas, cada quadro ocupava 60, 80 ou 120 octetos. Um pacote podia agregar quadros consecutivos, desde que todos tivessem a mesma taxa e o mesmo clock; um quadro não podia ser dividido entre pacotes. O payload não trazia um campo adicional para a quantidade de quadros: o receptor a deduzia do total de octetos e do tamanho esperado por quadro. Para telefonia, em que o atraso importa, a recomendação era usar menos quadros por pacote; streaming e mensagens mais tolerantes poderiam agrupar mais.

O RFC não fixou um número universal de latência.

Como documento de migração, o RFC 5577 não conta a história de “um codec novo expulsando o antigo”. Ele mostra como manter as opções visíveis. A linha “Obsoletes” substituiu o texto da especificação; a oferta de 16 kHz deixou a fronteira de interoperabilidade anterior disponível. Nenhuma das duas informa quantos terminais implementaram cada configuração.

Fontes