Resumo

  • Os valores user, header, session, id e history selecionavam superfícies diferentes. O cabeçalho Privacy não concedia poder geral para reescrever qualquer dado sensível.
  • Alterar Call-ID exigia manter a relação entre o valor antigo e o novo e reparar referências posteriores, até mesmo quando a mensagem posterior não trouxesse um novo pedido de privacidade.
  • A operação confiável precisa provar separadamente o pedido, a classificação do alvo, a causa de cada mutação, o estado preservado, a continuidade do diálogo e a exposição vista por cada observador.

A transformação terminou; a obrigação começou

Um INVITE chega com Call-ID C1 e Privacy:user. O serviço substitui C1 por C2 e encaminha a mensagem. Se o monitor observa apenas o pacote de saída, o trabalho parece concluído. Mas uma transferência posterior pode carregar C1 em Replaces; outra perna da chamada pode conhecer C2; um Target-Dialog pode chegar sem cabeçalho Privacy. A decisão inicial ainda está ativa.

Esse é um caso em que o tempo do log não corresponde ao tempo do protocolo. A linha «Call-ID anonimizado com sucesso» descreve a mutação, não a obrigação que ela criou. Sem a tabela C1–C2, a colocação correta do serviço no caminho e uma vida útil suficiente, mensagens válidas deixam de se reconhecer.

A RFC 5379, publicada em fevereiro de 2010 como contribuição Informational do Independent Stream, organizou esse problema. Ela não criou um novo mecanismo normativo. Declarou que esclarecia a operação prática da RFC 3323 e de extensões das RFCs 3325 e 4244. A sua autoridade era explicativa: reduzir interpretações incompatíveis, não transformar uma orientação em licença ampla para o intermediário.

Valores diferentes, objetos diferentes

user tratava informações inseridas pelo usuário. header tratava informações de sinalização adicionadas pela rede. session se aplicava à descrição da sessão. id tratava P-Asserted-Identity no domínio de confiança da RFC 3325. history tratava History-Info. none e critical resolviam outras escolhas.

Não era uma escala na qual cada valor superior englobava os anteriores. A RFC 5379 mostrou uma matriz com Call-ID, Contact, From, History-Info, P-Asserted-Identity, Record-Route, Via e outros campos. As células distinguiam excluir, não adicionar, anonimizar, tratar condicionalmente ou não agir. A direção — pedido ou resposta — também fazia parte da regra.

Para SDP, Privacy:session indicava as linhas c, m, o, i, u, e e p. A palavra sessão não autorizava varrer todos os cabeçalhos relacionados à chamada. O valor tinha um conjunto técnico definido.

Um sistema que reduz tudo a privacy=true perde o tipo da instrução. Para executar com controle, precisa conservar o valor solicitado, a direção, o campo, a ação, a condição e a especificação que sustenta aquela ação.

O mapa também dizia onde não agir

Identity/Identity-Info, Path, Replaces, Route, Service-Route e Target-Dialog foram descritos como não alvos dos valores listados. Não deveriam ser anonimizados ou alterados apenas por causa do priv-value recebido.

Isso não os tornava públicos ou inofensivos. Path pode expor um domínio visitado; Route revela proxies; Identity-Info aponta para dados do signatário; Replaces e Target-Dialog relacionam diálogos. A sensibilidade, porém, não cria por si só a autoridade de alterar.

Path ajuda uma chamada a chegar ao agente registrado no domínio visitado. Ocultá-lo sem substituição funcional prejudica a alcançabilidade. Route força o pedido por uma sequência de proxies; trocar seu conteúdo por algo apenas «anônimo» pode destruir o encaminhamento. Replaces identifica o diálogo que deve ser substituído; uma limpeza sem estado faz o receptor procurar um diálogo inexistente.

Se o provedor precisa esconder topologia, deve declarar uma política e uma técnica próprias. Não pode atribuir essa escolha à voz do usuário. A pergunta correta é: qual regra alcança este campo, qual propriedade precisa sobreviver e qual evidência provará o resultado?

A não alvo que podia precisar desaparecer

Identity mostra por que «não alvo» não significa imutável. Na discussão histórica baseada na RFC 4474, a assinatura protegia From, To, Call-ID, CSeq, Date, Contact e o corpo. Uma alteração legítima de privacidade sobre esses dados tornava a assinatura inválida.

Identity não passava a ser alvo do valor Privacy. Mesmo assim, o serviço podia precisar removê-la porque a evidência de integridade já não correspondia à mensagem. A causa era derivada: primeiro houve uma transformação autorizada; depois a transformação invalidou uma prova dependente.

O registro deve manter essas duas etapas. Se escrever apenas «Privacy removeu Identity», ele amplia retrospectivamente o pedido. A RFC 4474 foi substituída pela RFC 8224, portanto o exemplo não é uma receita atual. Mas o princípio permanece: quem muda a entrada de uma prova deve revalidar, revogar ou regenerar essa prova sob uma regra separada.

Replaces cobrava a dívida

Os exemplos da RFC 5379 expõem o custo do Call-ID. Alice inicia um diálogo com C1; o serviço envia C2 a Bob. Mais tarde, um REFER leva uma referência para outro agente, que cria um INVITE com Replaces. Se esse INVITE usa o identificador que Bob conhece, mas chega a uma parte que conhece o outro, a substituição falha.

O mesmo serviço pode resolver a situação se permanecer no caminho e traduzir C1 e C2 corretamente. O detalhe decisivo é que a mensagem de reparo pode não pedir privacidade. A autoridade para a tradução vem do estado criado anteriormente, não de um novo token.

Essa diferença orienta a arquitetura. A tabela de correlação precisa sobreviver ao tempo do diálogo, a reinícios e a failover. Os nós redundantes precisam concordar. O roteamento precisa conduzir mensagens relevantes ao componente que conhece a relação. A expiração precisa considerar transferências atrasadas e chamadas longas.

Se nada disso pode ser garantido, talvez o serviço não deva alterar Call-ID. Reduzir uma exposição possível para produzir falhas não rastreáveis é uma troca operacional, não um sucesso automático de privacidade.

A política local tinha outro emissor

A RFC 5379 aceitava variações de implementação e política de rede. Também observava que alguns não alvos poderiam merecer tratamento independentemente do nível pedido. Esse espaço não deveria apagar a procedência.

Ocultação de topologia, retirada de P-Asserted-Identity numa fronteira não confiável, exclusão de uma assinatura inválida e restauração de Route após mudança de Record-Route são atos diferentes. Cada um precisa do próprio emissor, versão, escopo e resultado.

Um único estado «privacidade aplicada» impede responsabilização. Quando a chamada falha, não se sabe se a causa foi o pedido do usuário, a política do provedor, a limpeza de integridade ou a correlação. Quando há vazamento, não se sabe qual campo estava realmente no escopo.

O pedido deve continuar sendo evidência do pedido. Políticas institucionais devem aparecer em nome próprio. Reparos devem apontar para a transformação que os tornou necessários. Assim, o registro descreve a realidade sem fingir ter criado uma autoridade maior.

O observador definia o resultado

Uma mensagem processada pode chegar ao destino e ainda falhar no objetivo de privacidade. O destinatário não vê o nome, mas o serviço intermediário vê. O SDP conserva um endereço revelador. Sistemas de cobrança e diagnóstico mantêm correlação. Outro cabeçalho reintroduz o dado.

Por isso a afirmação precisa ser delimitada: qual informação, escondida de qual ator, em quais mensagens e fluxos, durante qual período? Quem ainda consegue correlacionar? Quanto tempo o estado permanece?

O teste deve percorrer registro, estabelecimento inicial, respostas, solicitações dentro do diálogo, transferência, retorno e encerramento. Em cada ponto, deve verificar não divulgação ao observador escolhido e continuidade das funções desejadas.

Conformidade com a matriz auxilia a execução, mas não certifica todo o ambiente. Chamada concluída não prova segredo. Campo ausente não prova chamada funcional.

Documento histórico, registro atual e comportamento real

O status Informational e Independent Stream da RFC 5379 faz parte do uso correto. O texto disse que a linguagem normativa derivava de RFCs existentes. Um produto pode usá-lo para organizar comportamento, mas deve ligar cada obrigação à fonte normativa pertinente.

As fontes também evoluíram: a RFC 4244 foi substituída pela RFC 7044, e a RFC 4474 pela RFC 8224. A lição arquitetural continua; a configuração atual deve consultar os sucessores.

O registro de parâmetros SIP da IANA comprova nomes e referências compartilhados. Não comprova que um serviço suporta o valor, mantém a correlação ou entrega privacidade.

O recibo mínimo deve preservar:

  • mensagem original, direção, solicitante e observador pretendido;
  • cada valor Privacy e a especificação aplicável;
  • decisão de alvo por campo;
  • política independente ou razão de protocolo;
  • estado antes e depois da transformação;
  • evidência derivada invalidada ou refeita;
  • mapeamentos, duração e nó responsável;
  • mensagens posteriores que consumiram o estado;
  • resultado de rota, diálogo, transferência e mídia;
  • teste de exposição por observador.

Essa cadeia impede que o token seja confundido com autoridade geral, que uma mutação seja confundida com sucesso e que uma chamada completa seja confundida com privacidade alcançada.