Resumo

  • Um registrador pode devolver uma lista Service-Route ordenada na resposta de sucesso ao REGISTER; o agente do usuário pode armazená-la e aplicá-la como Route em uma solicitação futura.
  • O sucesso do registro e a entrega do serviço vivem em relógios diferentes. A resposta não comprova uso posterior, resolução de nomes, travessia de proxies, execução de política nem resultado de sessão.

Publicado na trilha de padrões em outubro de 2003, RFC 3608 define uma extensão SIP e seu ciclo de vida; não é uma observação da rede atual de qualquer operadora.

Dois eventos podem aparecer na mesma tela e continuar separados por toda a arquitetura. O primeiro é um registro SIP aceito. O segundo é uma comunicação futura que recebe um serviço do domínio de origem. RFC 3608 liga os eventos por uma sugestão de rota, não por uma garantia de resultado.

O registrador conhece um proxy de serviço e pode incluir sua URI — ou uma sequência de URIs — na resposta 2xx ao REGISTER. O terminal associa a informação ao seu address-of-record. Mais tarde, se decidir usá-la, coloca os valores como Route preloaded em uma requisição inicial e preserva a ordem. É uma solução de descoberta elegante: o terminal não precisa nascer com toda a topologia do domínio configurada.

Mas uma informação aprendida não é uma ação executada. Pode não haver requisição futura. O aplicativo pode escolher outra conta ou outra política. Uma rota local necessária para sair da rede visitada pode ser acrescentada. Um outbound proxy configurado pode alterar a composição. RFC 3608 entrega uma peça da decisão; o código do dispositivo entrega a decisão real.

O estado também vence. Uma nova resposta de registro substitui a rota armazenada. Se a resposta de sucesso não contém Service-Route, a rota anterior deve ser limpa. Se o registro falha ou expira sem renovação, o terminal deve descartá-la. Uma lista sem o REGISTER que a criou, a validade e a cadeia de refresh não é “a rota do usuário”; é um fragmento sem versão.

Path, de RFC 3327, resolve outro lado do problema. Proxies podem acumular Path enquanto o REGISTER segue para o registrador, permitindo que pedidos do domínio de origem encontrem depois o contato. Service-Route viaja de volta como proposta para pedidos originados no terminal. Misturar os dois registros elimina direção, finalidade e responsabilidade.

Quando uma requisição existe, Route mostra intenção de encaminhamento. Via cresce à medida que elementos SIP encaminham a transação e define o caminho de volta da resposta. Encontrar um nome em Route não é observar a passagem. Encontrar um salto em Via melhora a evidência de trânsito, porém ainda não prova que o módulo de serviço dentro do proxy aplicou a política prevista.

Entre URI e máquina há resolução. RFC 3263 permite que DNS, prioridade, peso e transporte produzam destinos candidatos. TTL expira, um endpoint falha, outro é tentado, a política local interfere. O mesmo texto de Service-Route pode levar a IPs, portas e conexões diferentes. Sem guardar a resposta DNS e a escolha final, não existe reconstrução fiel.

RFC 5626 registra fluxos outbound e tokens que ajudam a manter a alcançabilidade. RFC 5923 permite reutilizar conexões. São mecanismos importantes, mas não eliminam a necessidade de correlacionar uma requisição específica com um fluxo específico. Uma conexão viva é evidência de transporte disponível, não recibo automático de todos os serviços supostamente prestados sobre ela.

Também há uma fronteira de segurança. RFC 3608 reconhece que um intermediário pode alterar ou inserir Service-Route e recomenda integridade e autenticação. Se a resposta é protegida, fica mais forte a afirmação de que o registrador publicou aquele vetor. A proteção não certifica o futuro. DNS, disponibilidade, política e código de serviço continuam podendo mudar.

Uma trilha auditável precisa de seis recibos. O primeiro conserva a resposta REGISTER, identidade, contact, Call-ID, CSeq, vetor ordenado, autenticação, data e expiração. O segundo conserva a requisição realmente montada após as regras locais. O terceiro registra DNS, TTL, endpoint, transporte e tentativas alternativas.

O quarto reúne observações de cada salto, correlacionadas por transação e tempo. O quinto vem do serviço: política, versão, decisão e erro. O sexto descreve o resultado: resposta SIP, estabelecimento do diálogo e, quando a pergunta exigir, mídia ou efeito na aplicação. Session-ID de RFC 7989 ajuda a juntar evidências existentes; não cria evidência que nunca foi registrada.

Separar os relógios esclarece o incidente. O registrador pode ter entregue o vetor errado. O cliente pode ter guardado uma geração expirada. DNS pode ter escolhido um destino indisponível. O proxy pode ter encaminhado e deixado de executar o serviço. A sinalização pode ter funcionado e a mídia falhado. Em todos os casos o REGISTER 200 continua historicamente verdadeiro — e operacionalmente insuficiente.

Não é necessário armazenar pacotes indefinidamente. É possível limitar retenção, amostrar, pseudonimizar e restringir acesso. A obrigação é ajustar a afirmação ao recibo preservado. Se a organização manteve apenas a resposta de registro, não pode transformar esse arquivo em prova de uma chamada.

RFC 3608 mostra uma boa divisão de poder técnico. A especificação comum define como publicar uma rota e como seu estado deve mudar. As escolhas posteriores ficam com participantes executando código. O problema nasce quando o indicador central “registrado” ganha autoridade para declarar saudável uma cadeia inteira que ele nunca observou.