Resumo

  • A RFC 3322 calculou 4.131 ms para uma sequência SIP/SDP com enlace de 9,6 kbit/s e RTT de 140 ms, reconhecendo que a aproximação ignorava retransmissões e era grosseira.
  • O modelo serviu para escolher requisitos de uma futura solução; não mediu uma chamada real, não comprovou adoção do SigComp e não prometeu um ganho específico.

O atalho que mudava a mensagem

Protocol stripping parecia sedutor: se os cabeçalhos e campos de SIP ou SDP eram grandes, bastaria retirar parte deles. A RFC 3322 rejeitou a ideia porque ela sacrificava transparência e feria o princípio fim a fim. O mecanismo de otimização passaria a decidir quais partes da mensagem podiam desaparecer. Compressão oferecia uma alternativa mais estreita: alterar a representação no enlace e devolver exatamente os mesmos bits ao aplicativo.

Essa escolha nasceu de um ambiente concreto. Sinalização textual precisava atravessar rádio de capacidade limitada. SIP, SDP e RTSP usavam várias rodadas de solicitação e resposta, muitas delas antes do tráfego útil. Proteção contra erro, interleaving e ARQ tornavam o canal utilizável, mas podiam acrescentar atraso. A quantidade de bytes por usuário afetava espera e capacidade da célula.

Outras alternativas também tinham custos. Aumentar a taxa de um usuário podia reduzir quantos usuários a célula atendia. Diminuir RTT exigia mudanças no sistema de rádio. Enviar múltiplas solicitações antes das respostas alterava a lógica dos protocolos. A compressão foi considerada atraente porque preservava a mensagem e podia permanecer invisível para a aplicação.

De onde vieram os 4.131 ms

A fórmula dividia o tamanho de cada mensagem em bits por 9.600 bit/s e acrescentava 70 ms, metade de um RTT de 140 ms. Aplicada ao fluxo ilustrado de INVITE, respostas provisórias, PRACKs, respostas finais e ACK, a soma dava 4.131 ms. RSVP, gestão de sessão e estabelecimento do bearer de rádio acrescentariam estimativas separadas.

O próprio texto classificou a aproximação WCDMA como bastante grosseira. Não incluiu atraso de possíveis retransmissões por erro, supôs apenas um enlace celular e simplificou a rede IP intermediária. Os tamanhos eram típicos. A comparação citada de cerca de 3,6 segundos para GSM e 7,9 segundos para um caso SIP era motivação histórica, não telemetria de SigComp.

Logo, as casas decimais pertencem à aritmética, não à universalidade da evidência. O número é reproduzível quando as premissas permanecem. Fora delas, deve ser recalculado ou abandonado.

Requisitos não eram resultados

Publicada em janeiro de 2003 como Informational, a RFC 3322 não especificava um padrão da Internet. Ela dizia que a futura solução deveria produzir mensagem bit a bit idêntica, coexistir com ROHC, manter compatibilidade, aceitar fluxos arbitrários, operar em rotas unidirecionais e servir tanto UDP quanto TCP.

O uso da compressão seria negociado pelo protocolo que gerava as mensagens, não pelo próprio esquema. Essa fronteira impede que capacidade vire obrigação. Ter software SigComp num terminal não prova negociação numa sessão. Um “must” no documento tampouco prova que um produto foi testado e aprovado.

Os requisitos de desempenho tratavam terminais com memória e CPU diferentes, atraso adicional, erros residuais, propagação de falhas, perda e reordenação moderada. Esperar várias mensagens para obter ratio melhor era desaconselhado, pois recriaria a demora que motivara o trabalho.

RFC 3320, RFC 3485, RFC 3486, RFC 4077 e RFC 5049 mostram a evolução posterior da arquitetura, do dicionário e da operação com SIP. Eles não fornecem sozinhos percentual de adoção nem melhoria observada. Essas afirmações exigem registros de negociação, versões, condições e comparação real.

A lição da RFC 3322 é manter quatro coisas separadas: o modelo que revela um problema, o requisito que restringe soluções, o código que implementa uma escolha e a medição que julga seu efeito. Comprimir essas camadas numa única narrativa apaga justamente a transparência que o protocolo queria proteger.

Sources