Resumo

  • A RFC 3952 não transmitia o número de quadros iLBC no payload RTP; o receptor dividia seu comprimento por 38 ou 50 conforme o modo acertado em SDP.
  • Uma errata de 2026 ainda em estado Reported propõe trocar 32/50 por 38/50, mostrando que comprimento, contrato da sessão, proteção e reprodução são recibos diferentes.

O campo sumiu, a dependência ficou

O modo de 20 ms produzia quadros de 38 octetos; o de 30 ms, quadros de 50. A RFC 3952 permitia concatená-los sem escrever quantos havia. Conhecido o modo, bastava dividir.

Assim, 76 octetos podiam ser dois quadros de 20 ms e 100, dois de 30 ms. A precisão vinha de uma relação entre plano de mídia e plano de controle. A captura tinha o dividendo; a negociação guardava o divisor. Excluir a segunda parte deixava bytes exatos com significado incompleto.

Para proteger essa aritmética, um quadro não podia ser cortado entre pacotes, nem modos diferentes podiam coexistir no mesmo payload. A agregação também não deveria ultrapassar o MTU. Menos quadros diminuíam atraso e aumentavam overhead; mais quadros economizavam cabeçalhos, mas ampliavam espera e fala perdida por datagrama.

O modo era uma decisão bilateral

SDP anunciava iLBC/8000; a=fmtp carregava o mode. Sem o parâmetro, valia 30 ms. As duas pontas de uma sessão bidirecional tinham de usar o mesmo resultado.

A oferta indicava preferência e a resposta podia escolher o outro valor. O resultado comum era o modo de menor largura de banda. Cinquenta octetos a cada 30 ms consomem menos por segundo do que 38 a cada 20; por isso, os dois exemplos mistos terminavam em mode 30.

A forma vinha da RFC 2327, e a negociação, da RFC 3264. A RFC 3550 dava sequência e tempo ao RTP. Nenhuma camada podia responder pelas demais: acordo de SDP não provava conformidade de cada pacote; ordem RTP não declarava tamanho de quadro.

O número errado apareceu justamente na fórmula

As seções 2 e 3.1 registram 38 octetos para 20 ms, coerentes com a definição do codec na RFC 3951. Já a seção 3.2 imprime 32/50 ao explicar o cálculo.

A página de errata contém a ID 8866, enviada em 3 de abril de 2026, propondo 38/50. Seu estado é Reported. Há evidência interna robusta para 38, mas proposta e verificação formal não são sinônimos.

Também não há base para atribuir uma falha real a essa linha. O que a fonte permite concluir é menor e mais útil: ler o documento inteiro oferece correção cruzada; copiar uma frase isolada pode incorporar 32. O erro potencial está no contexto usado pelo intérprete, não necessariamente no pacote transmitido.

Divisão exata não era chamada concluída

Sob mode 20, 114 octetos dão três quadros sem resto. Isso demonstra coerência de tamanho. Não demonstra validade dos blocos, identidade, autenticação SRTP, aceitação no jitter buffer, decodificação, reprodução nem compreensão humana.

A RFC 3711 trata SRTP separadamente. Proteção válida não corrige modo desatualizado; divisibilidade sem proteção não identifica remetente. Um resto pode revelar divergência de modo, payload type incorreto, corrupção ou falha da captura, mas ainda não escolhe a causa.

O registro do RFC Editor classifica a RFC 3952 como Experimental, publicada em dezembro de 2004. Seu valor histórico está em mostrar o destino do estado removido: quando um formato fica menor, algum sistema externo passa a carregar mais autoridade. Se esse sistema não for preservado, a economia se torna dívida de evidência.

Fontes