Resumo

  • History-Info conserva os Request-URI declarados por intermediários compatíveis quando uma requisição inicial é redirecionada ou bifurcada. O hi-index forma uma árvore ordenada; rc, mp e np descrevem tipos específicos de mudança.
  • A extensão é opcional. A árvore pode conter linhas legadas ou inseridas para marcar lacunas, omitir um ramo ainda pendente e anonimizar destinos por privacidade. TLS/SIPS não transforma intermediários confiáveis em testemunhas incontestáveis.
  • Para justificar a decisão, o operador precisa associar o cabeçalho à regra executada, ao proprietário, à fonte consultada, ao estado dos ramos, à transformação de privacidade e ao resultado real. O histórico explica o caminho; não dá permissão para escolhê-lo.

Quando o relatório chama rastreabilidade de aprovação

Uma operadora de saúde oferece um número para triagem clínica. Certo atendimento chega a uma central terceirizada que não deveria receber aquele tipo de caso. O relatório técnico mostra uma árvore History-Info limpa: número público, serviço regional, fila terceirizada. Os índices são válidos e o destino final respondeu.

O relatório encerra a análise com “encaminhamento autorizado”. Essa palavra não veio da sinalização.

A árvore mostra os alvos que os sistemas participantes deixaram visíveis naquele ponto. Não identifica automaticamente quem alterou a regra, se o contrato do terceiro cobria o caso, qual versão do cadastro foi consultada, se outro ramo ficou pendente ou privado, se algum intermediário reescreveu a lista, se houve mídia, se um profissional atendeu ou se o resultado clínico ocorreu.

RFC 7044 resolve um problema menor e bem definido. Uma mudança normal de Request-URI apaga do pedido encaminhado o destino anterior. History-Info conserva esse histórico para requisições iniciais ou fora de diálogo. A RFC não converte política local de seleção em norma universal.

A decisão existe antes do cabeçalho

Pela RFC 3261, um proxy determina o próximo destino a partir de serviço de localização, resposta de redirecionamento, Route ou configuração. Ele envia a requisição com o Request-URI atual. Sem uma extensão, o próximo nó pode não saber os alvos anteriores.

A RFC 7044 chama de retargeting o ato de mudar o Request-URI conforme regras de determinação de alvo e encaminhar a mensagem. O código em execução no proxy, PBX, B2BUA ou aplicativo toma a decisão. History-Info registra uma parte do resultado.

O registro de parâmetros SIP da IANA aloca History-Info, histinfo, history, rc, mp e np. A alocação confirma a linguagem compartilhada. Não confirma que uma rede a usa, que os dados são completos ou que a entidade tinha mandato para direcionar a chamada.

O limite temporal também importa. O campo vale para requisições iniciais ou fora de diálogo. Não é um diário de tudo o que ocorre depois: sinalização dentro do diálogo, mídia, gravação, interface, faturamento e experiência do usuário continuam separados.

O índice desenha parentesco, não tempo

Uma entrada contém obrigatoriamente o URI-alvo e um hi-index. Números inteiros não negativos separados por pontos posicionam a entrada. Um filho estende o índice do pai; um fork cria irmãos. A lista usa percurso em pré-ordem para que o receptor recupere a árvore.

Esse desenho evita que ramos simultâneos pareçam redirecionamentos sucessivos. Mas não cria um relógio. O índice não mede duração, não sincroniza equipamentos e não prova qual ramo terminou primeiro.

Os marcadores de mecanismo refinam o relato:

  • rc diz que o Request-URI mudou, porém o nó considera o usuário-alvo o mesmo, como na resolução de um endereço para um Contact;
  • mp diz que houve mapeamento para outro usuário-alvo ou outro endereço de registro;
  • np diz que só mudou o próximo salto, sem mudança do Request-URI.

São afirmações do nó que insere a entrada. rc não demonstra que duas identidades tenham a mesma responsabilidade institucional. mp não prova que o mapeamento foi aprovado. np não garante que o próximo salto seja confiável. A classificação deve ser confrontada com a regra e os dados que a produziram.

Uma árvore válida pode chegar incompleta

O suporte é opcional. histinfo é anunciado em Supported e não força toda a rota por Require ou Proxy-Require. Um único equipamento sem a extensão já pode deixar um vazio.

Há também linhas do padrão substituído, a RFC 4244. A RFC 7044 exige interoperabilidade, mas proíbe um nó de inventar rc, mp ou np para uma operação antiga que ele não observou. Ausência de marcador pode significar legado, não ausência de redirecionamento.

Se o receptor notar que o Request-URI atual não coincide com a última entrada, ele acrescenta uma linha em nome do intermediário anterior. A mudança é observável; o mecanismo não. Por isso, a linha de lacuna não deve ganhar classificação imaginada.

O fork produz outra limitação. Um exemplo da RFC 7044 tem um ramo que responde 200 enquanto o irmão ainda não respondeu. A resposta vencedora não consegue carregar o futuro do ramo pendente. Uma coleta feita só no caminho vencedor pode ser correta e ainda não cobrir a tentativa inteira.

Os exemplos de privacidade da RFC 4244 mostram uma consequência prática: se um ramo privado fica invisível ao upstream, ele pode tentar de novo um alvo que não sabe já ter sido chamado. Privacidade e otimização podem apontar em direções diferentes. A aplicação deve ter comportamento seguro para dados parciais.

Assim, a declaração auditável inclui local e mensagem: “neste ponto, esta cópia continha estas entradas”. Chamar a cópia de história total ultrapassa a evidência.

Reason registra uma explicação de protocolo

History-Info pode carregar Reason no componente headers do URI. A RFC 3326 define causas SIP e Q.850 e admite vários espaços de protocolo. A RFC 7044 usa o dado em respostas de falha e timeouts pertinentes.

É útil saber que um ramo indicou ocupado ou expirou. O valor não revela a intenção humana, a legitimidade da política, a veracidade do equipamento nem a causa comercial. Sem integridade, Reason pode ser alterado ou removido. O registro deve manter a mensagem, o emissor e o ponto de observação.

O cadastro de erratas da RFC 7044 traz três itens Reported — sobre índice de lacuna, classes de resposta para Reason e uma referência editorial — e dois Rejected. Reported não é Verified. São pontos para teste, não correções normativas já adotadas.

Privacidade produz uma verdade deliberadamente menor

O histórico pode expor dispositivo pessoal, alias, departamento interno, caixa postal e topologia. A RFC 3323 mostra por que a privacidade SIP muitas vezes depende de intermediários: eles mesmos acrescentam informação de rota.

A RFC 7044 define a privacidade history. A proteção pode alcançar o conjunto ou uma entrada. Um domínio pode ocultar sua rota interna mesmo se a requisição não pedir privacidade. O UAS pode não revelar ao originador o alvo final. Um serviço de borda pode substituir o URI por endereço sob anonymous.invalid.

Essa anonimização pode ser a execução correta da política. Não é prova automática de adulteração hostil. Mas limita o que o observador externo consegue sustentar. É preciso guardar a fronteira, a versão da regra, a transformação e uma correspondência protegida para revisão autorizada, quando a política permitir.

Quem pode escolher o destino e quem pode ocultá-lo exercem poderes diferentes. Um evento genérico de “normalização” não deve apagar os dois.

TLS protege o canal, não o caráter do mensageiro

A RFC 7044 recomenda fortemente TLS ou ambiente seguro. SIPS protege contra interferência arbitrária fora do caminho dentro do seu modelo. Já os intermediários no caminho precisam ler e acrescentar History-Info.

Um intermediário malicioso ou comprometido pode apagar, reordenar ou reescrever entradas. A RFC diz expressamente que a extensão não impede nem detecta esse comportamento. O cabeçalho recebe a mesma segurança que os demais cabeçalhos SIP, nada além.

Uma coleta séria registra o par TLS, o resultado do certificado, o domínio de confiança, a impressão da mensagem e o ponto de captura. “Passou por SIPS” não equivale a “foi atestado ponta a ponta”.

Cada aplicativo precisa assumir sua interpretação

A RFC 7044 manda as aplicações definirem defaults para história ausente ou incompleta. Serviços diferentes podem usar posições rc diferentes.

Um PBX empresarial e uma caixa postal de consumo podem procurar identidades distintas. Se a chamada foi redirecionada antes de entrar na empresa, a regra “pegue o primeiro rc” pode escolher alguém de fora. A RFC 4458 mostra que, em correio de voz, target e cause podem estar no Request-URI atual ou em History-Info conforme suporte e trajeto.

O aplicativo deve declarar o objetivo, os domínios confiáveis, a reação a lacunas e privacidade e o critério de escolha. Isso respeita a ideia de Heng Lu de uma especificação inicial mínima: a camada comum coordena, mas decisões futuras comuns ficam com os participantes que têm contexto e assumem a perda. A regra local precisa, porém, ser versionada e contestável.

Um dossiê que separa relato de autoridade

Primeiro, preserve método, Request-URI recebido e enviado, Call-ID, CSeq, Via branch, horário, ponto de observação e impressão controlada.

Depois, mantenha árvore recebida e emitida separadas: ordem, índice, URI, referência rc/mp/np, Reason, privacidade, legado, resultado de parse e lacuna inserida. Nunca preencha o desconhecido com inferência oculta.

Registre a decisão: ID e versão da regra, fonte consultada, resposta de redirecionamento, candidatos, escolha, fallback, criação de ramos, identidade de serviço, tenant, proprietário, aprovação e período de vigência.

Registre confiança e privacidade: domínio de entrada e saída, par TLS, transformação, política, mapa protegido, acesso e retenção.

Por fim, relacione transações dos ramos, respostas, timeout, CANCEL, vencedor, pernas do B2BUA, diálogo, mídia, aplicação, gravação, cobrança e reclamação.

Não elimine conflitos. Um vencedor pode não trazer um irmão conhecido. Um rc pode contrariar a fronteira de tenant. Reason pode divergir do log da aplicação. O B2BUA pode ter árvore válida e mapa de pernas perdido. Pode haver 200 sem áudio. Esses desacordos localizam a quebra; resumi-los como “rota aprovada” dá soberania ao agregador.

Fontes