Resumo

  • A RFC 3486 vinculou comp=sigcomp ao dado que comandava a próxima ação: URI para a requisição, Via para a resposta e Contact ou Record-Route para mensagens futuras.
  • O marcador declarava suporte e disposição naquele momento. A compressão efetiva, a análise SIP, a entrega, a autenticação e a sessão continuavam sendo provas distintas.

Uma maneira ruim de resumir RFC 3486 seria dizer que ela “ligou SigComp em SIP”. A especificação fez algo mais cuidadoso: ensinou cada mensagem a descobrir se o receptor imediato queria compressão. A unidade de decisão era o enlace seguinte, e cada direção tinha seu próprio registro.

O problema vinha do DNS. NAPTR e SRV já ajudavam um cliente SIP a escolher UDP, TCP ou SCTP. Se cada transporte ainda tivesse variantes para TLS e SigComp, o número de registros cresceria em combinações. A alternativa foi sinalizar compressão dentro de SIP. Mensagens comuns e comprimidas podiam chegar à mesma porta, distinguidas pelos bits de cookie no início de SigComp.

O parâmetro comp=sigcomp tinha a mesma grafia em lugares com funções diferentes. Numa URI SIP ou SIPS do próximo salto, indicava que a requisição deveria ser comprimida. No Via do topo, indicava que a resposta deveria voltar comprimida. Ler apenas o token, sem guardar o cabeçalho e o sentido, eliminaria metade da evidência.

A RFC afirmou ainda que o parâmetro reunia suporte e disposição para receber compressão. Um equipamento poderia implementar SigComp e ainda assim não anunciar vontade de usá-lo em determinado momento. Capacidade instalada não era uma autorização eterna. O receptor influenciava a escolha publicando ou retirando o parâmetro.

Daí a proibição central: sem saber se o servidor do próximo salto entendia SigComp, o cliente não podia enviar uma requisição comprimida. Ele podia, entretanto, enviar a requisição comum com comp=sigcomp no próprio Via. Se o servidor tivesse suporte, a resposta poderia ser comprimida. A ida permanecia comum enquanto a volta ganhava uma autorização própria.

O primeiro INVITE aparecia antes de existir um conjunto de rotas do diálogo. Para descobrir o proxy de saída, o cliente podia usar configuração manual ou enviar OPTIONS sem compressão. O proxy podia responder com uma URI alternativa em Contact contendo o marcador. A resposta documentava uma oferta; não documentava os bytes do pedido seguinte.

Contact e Record-Route transportavam a preferência para o futuro. Um agente colocava o parâmetro em Contact se quisesse receber novas requisições comprimidas. Um proxy que quisesse permanecer no caminho usava Record-Route. Na resposta, ele examinava o próximo salto ascendente e podia incluir ou remover o marcador em sua própria entrada. O diálogo acumulava instruções locais, não uma propriedade única.

O exemplo normativo deixa isso visível. Há quatro participantes, mas somente as mensagens 1, 6 e 7 são comprimidas. Um proxy recebe o INVITE comprimido e o encaminha em formato comum. A resposta atravessa um trecho comum e depois um trecho comprimido. O ACK muda outra vez. Suporte em vários nós não cria uma linha uniforme.

O duplo Record-Routing, comum num proxy entre duas redes, também permitia assimetria. Duas entradas representavam duas interfaces e evitavam reescrita, sem exigir que os lados usassem a mesma codificação. Se o próximo salto fosse o próprio proxy e não houvesse transmissão pela rede, ele podia dispensar compressão apesar do parâmetro.

O comportamento de erro revela por que silêncio não basta para diagnosticar. Um servidor sem SigComp talvez não conseguisse analisar nem o Via e, portanto, não tivesse endereço para enviar erro SIP. Depois do timeout da transação, o cliente deveria repetir a mesma requisição sem compressão. O timeout justificava o recuo, mas não provava a causa.

Em TCP, a recomendação era fechar a conexão antiga e abrir outra. Caso contrário, o servidor incompatível poderia não localizar o início da nova mensagem comum dentro do fluxo que começou comprimido. Tentativa, timeout, forma do reenvio e conexão nova deveriam permanecer eventos separados.

O marcador também não autenticava quem o inseriu. Um atacante capaz de acrescentá-lo poderia levar uma entidade a enviar compressão para outra sem suporte; por isso a integridade do SIP importava. E a descompressão exigia processamento adicional, ampliando um pouco o custo de um ataque de negação de serviço.

O registro da IANA estabilizou o nome, não sua execução. RFC 3320 definiu a arquitetura SigComp, RFC 3485 o dicionário estático e RFC 5049 atualizou a ligação com SIP, acrescentando recursos mínimos e compartimentos. RFC 4077, RFC 4896, RFC 5112 e RFC 5626 tratam de outros limites. Nenhum desses registros mede adoção.

Uma auditoria precisa preservar URI, Via, Contact, Route, Record-Route, sentido, integridade, bytes no fio, transporte e conexão. A descoberta por OPTIONS deve ficar separada do uso posterior. Se houver silêncio, também se registram timeout, reenvio comum e nova conexão TCP. Só depois vêm descompressão, análise SIP, autenticação, diálogo e experiência do usuário.

A contribuição histórica de RFC 3486 foi evitar uma explosão de combinações sem fabricar uma promessa de ponta a ponta. A marca viajava, mas sua autoridade terminava no próximo salto. Essa limitação não era defeito: era o que tornava a decisão verificável.

Fontes