Resumo

  • A RFC 3323 definiu privacidade em relação às partes das quais se ocultam informações; não prometeu que uma solicitação SIP deixaria de carregar dados identificáveis.
  • O serviço podia ocultar cabeçalhos e ainda guardar e restaurar o estado de roteamento do diálogo: a fronteira de confiança mudava de lugar, mas não sumia.

Anônimo para quem?

Em 2002, privacidade na SIP não era um botão entre “identificado” e “anônimo”. A RFC 3323 a tratou como a retenção de informações diante de uma ou mais partes do diálogo. Quem liga podia impedir que o destinatário visse seu nome real e, ao mesmo tempo, permitir que um serviço confiável conhecesse sua identidade. Outra arquitetura podia esconder detalhes da rede do usuário. A pergunta essencial era: invisível para quem?

Um valor From anônimo não significava que a solicitação não pudesse conter endereços úteis. A especificação recomendou anonymous.invalid para um URI SIP anônimo, mas as solicitações seguintes do diálogo ainda precisavam alcançar o terminal correto. A mensagem podia ocultar uma identidade pessoal e manter Contact, Via, Record-Route ou informações de sessão necessárias ao roteamento. Privacidade controlava a apresentação do estado do protocolo; não apagava o estado.

O serviço precisava lembrar o que ocultava

A RFC separou a privacidade pedida pelo usuário daquela fornecida pela rede. O cabeçalho Privacy permite solicitar user, header ou session; none impede ações de privacidade pelo serviço, enquanto critical exige que a solicitação falhe se o nível pedido não estiver disponível. Esses valores expressam intenção, não autenticação, autorização, criptografia de mídia ou prova de que todos os intermediários obedeceram.

A privacidade de cabeçalho expunha o custo operacional. Um serviço podia atuar como B2BUA, remover ou alterar cabeçalhos identificadores, substituir Contact por seu próprio endereço e guardar localmente as rotas originais. Quando mensagens posteriores voltavam, precisava restaurar os valores necessários à continuação. O destinatário via menos; o serviço retinha mais estado privilegiado. O chamador não era anônimo para esse serviço.

A privacidade de sessão exigia ainda um B2BUA e um intermediário de mídia ou anonimizador de tráfego. Como o serviço entrava no caminho da comunicação, a RFC 3323 recomendava cautela sem proteção de mídia de ponta a ponta, como SRTP. É um alerta arquitetural, não uma conclusão sobre adoção.

Ocultar a identidade cria outro ponto de controle

A tensão histórica é direta: quanto menos o destinatário aprende, maior pode ser sua dependência do componente que faz a ocultação. O serviço decide o que remover, reter, alterar e restaurar; para preservar a continuidade do diálogo, precisa ser confiável.

A RFC 3261 dá o contexto de diálogos SIP e conjuntos de rotas. A RFC 3325 aborda a identidade afirmada dentro de redes confiáveis e declara que não define um modelo geral entre domínios de confiança. São fronteiras próximas, não uma solução universal. A RFC 3323 não prova adoção nem interoperabilidade. Ela registra uma escolha de projeto: reduzir o que uma parte vê, preservar o estado necessário à chamada e explicitar o intermediário responsável por esse equilíbrio.

Fontes