Resumo

  • O RFC 3327 permitiu que proxies escolhidos inserissem valores Path no REGISTER; o registrador armazenava o vetor ordenado com o endereço de registro e um Contact específico, e o proxy doméstico o carregava em Route para pedidos futuros.
  • Path era uma instrução de entrega futura, não histórico exaustivo: um proxy atravessado podia não aparecer, outro nó podia ser declarado, o registrador podia transformar o vetor e a política posterior podia acrescentar rotas.

A associação de localização ainda não entregava uma chamada

Um dispositivo registra sua identidade SIP pública enquanto está em uma rede de acesso. O Contact descreve o destino corrente, e o registrador aceita a associação. Ainda assim, o dispositivo pode estar atrás de um proxy de borda, de uma fronteira operacional ou de um serviço que todas as chamadas precisam atravessar. Mandar a solicitação diretamente ao Contact pode contornar a política necessária ou não funcionar fora daquele caminho.

O REGISTER acabara de passar pelos intermediários corretos. A dificuldade era preservar esse conhecimento depois do fim da transação. O registro SIP básico mantinha a resposta para “qual é o Contact?”, mas não obrigava o sistema a manter “qual sequência torna esse Contact alcançável?”. O pacote chegava e levava consigo o plano da próxima entrega.

Path deu forma ao plano. Um proxy que processava REGISTER podia adicionar a URI que deveria participar de solicitações futuras dirigidas ao dispositivo. Os valores formavam um vetor ordenado. O registrador o guardava junto ao endereço de registro e ao Contact específico e o refletia na resposta bem-sucedida. Quando o proxy doméstico escolhia aquele Contact, preenchia Route com o vetor antes de encaminhar.

A granularidade evitava misturas. A mesma identidade podia registrar celular, computador e gateway por acessos diferentes. Cada Contact precisava carregar sua própria rota e seu próprio prazo. Uma atualização a partir de outra borda podia trocar o vetor; a expiração retirava o destino e a instrução de chegada. Tratar Path como propriedade estática do usuário aplicaria a topologia de um dispositivo a outro.

O RFC 3263 usava DNS para localizar servidores SIP de um domínio. Isso encontrava a entrada do serviço, não a cadeia temporária do domínio doméstico até um Contact individual. Path preservava uma informação posterior à descoberta e específica da associação.

O nome Path não o tornava uma trilha observada

Uma lista ordenada de URIs parece um relato dos saltos do REGISTER. A especificação evitou essa promessa. Um proxy que recebeu e enviou REGISTER podia optar por não inserir a própria URI. Um proxy consciente da topologia podia indicar outro nó para o tráfego futuro. O registrador podia transformar o vetor. O proxy doméstico podia combiná-lo com uma Route já presente ou uma saída padrão.

Path era, portanto, prescritivo. Indicava restrições para uma solicitação posterior, não a sequência forense da anterior. Uma captura prova os valores vistos naquele ponto. Não prova que todos os nós atravessados foram listados, que todos os nós listados foram atravessados nem que a mesma sequência seria executada no futuro.

Uma trilha de auditoria precisa separar quatro recibos: o percurso observado do REGISTER, o Path declarado, a versão aceita ou transformada no armazenamento e a Route efetivamente observada depois. O que muda entre essas etapas revela política, falha ou abuso. Fundir tudo em uma linha elimina justamente a evidência relevante.

Via pertence à transação e conduz respostas de volta. Record-Route estabelece o conjunto de rota do diálogo que está sendo aberto. Path é aprendido no registro para possíveis diálogos futuros. Service-Route, do RFC 3608, informa ao agente de usuário como enviar solicitações futuras para fora; Path informa ao lado doméstico como enviar para dentro, em direção ao Contact. Eles ocupam momentos e autoridades diferentes.

Refletir o vetor permitia conferir, não confiar

O registrador devolvia os valores Path na resposta positiva. O agente de usuário comum não os usava para construir a própria rota e podia ignorá-los, mas conseguia inspecionar o que fora aceito. Um proxy inesperado podia denunciar uma tentativa de ocupar todas as chamadas futuras daquela associação.

Uma inserção maliciosa tinha efeito duradouro. Enquanto o registro existisse, o nó poderia interceptar solicitações dirigidas ao Contact. A remoção de uma URI podia evitar uma função obrigatória; a mudança da ordem alterava quem via o tráfego primeiro; uma normalização sem recibo ocultava a diferença entre o que foi declarado e o que foi armazenado.

O RFC recomendou integridade e autenticação mútua adequadas. A garantia é limitada: uma verificação pode mostrar que os bytes protegidos não mudaram entre pares identificados, mas não que o nó seja honesto, esteja disponível, tenha autoridade para representar outro ou seja atravessado mais tarde. A reflexão expõe a decisão do registrador; não certifica a realidade externa.

O documento ainda alertou contra a inserção de Path pelo próprio agente de usuário. Outros proxies poderiam interpretar a URI como instrução de um par e esperar que o dispositivo funcionasse como proxy no futuro. A origem e o papel de quem fala fazem parte do significado, embora o valor isolado pareça perfeitamente válido.

As extensões seguintes organizaram o entorno

Publicado em dezembro de 2002, o RFC 3327 foi atualizado pelo RFC 5626. SIP Outbound tratou de fluxos mantidos por dispositivos atrás de fronteiras e da participação dos proxies de borda. Isso refinou a relação entre registro, fluxo e caminho utilizável, mas não transformou Path em histórico integral.

O RFC 5627 definiu GRUU para identificar uma instância de agente de forma roteável. O RFC 3680 definiu notificações de eventos de registro. O RFC 5922 especificou certificados de domínio SIP. O registro de parâmetros SIP da IANA documenta atribuições padronizadas. Essas fontes comprovam contratos e evolução; não comprovam adoção, implantação, disponibilidade ou confiança atual.

A contribuição duradoura do RFC 3327 foi separar identidade, localizador, rota obrigatória e história observada. Conhecer identidade e localizador não bastava para entregar. Conhecer uma rota futura não bastava para narrar o passado. Path tornou explícito o estado que faltava e também deixou um limite: uma declaração operacional só permanece útil enquanto não for promovida a prova que nunca foi.

Fontes