Resumo

  • A RFC 3087 permitiu que cliente ou proxy SIP escolhesse uma Request-URI distinta para iniciar depósito, saudação específica, recuperação de mensagens ou solicitação de PIN.
  • A URI selecionava um comportamento provisionado localmente. Ela não provava a identidade de quem ligou, a autorização sobre a caixa, o motivo real do desvio nem o armazenamento ou a audição da mensagem.

O destino lógico ficou; o serviço corrente mudou

Um sistema tradicional de correio de voz podia observar o número chamado, o número de origem e a causa do encaminhamento. Com esses sinais, abria a saudação de ocupado, a de falta de atendimento, uma caixa determinada ou o menu de consulta do assinante. A facilidade dependia de uma rede em que cada sinal conservasse um significado aceito pelo operador.

No SIP, uma solicitação podia atravessar vários proxies e ser redirecionada mais de uma vez. O campo To ainda podia apontar para a pessoa chamada no início, embora outro serviço devesse atender a etapa atual. A RFC 3087 ilustra a falha: A liga para B; B encaminha tudo para C; C encaminha para o próprio correio de voz. Se a aplicação usar To: B como seletor da caixa, procurará o assinante errado.

Publicada como Informational em abril de 2001, a RFC 3087 não criou método nem cabeçalho SIP. Ela explorou uma diferença já existente na RFC 2543: o proxy podia reescrever a Request-URI, ao contrário do To. A identidade de serviço usada como destino atual também podia selecionar o estado inicial da aplicação.

A mudança relevante era de responsabilidade. Em vez de o correio de voz adivinhar o contexto a partir de restos de uma trajetória, a decisão de roteamento entregava uma escolha explícita.

Uma aplicação, várias portas

O documento prevê várias identidades SIP para o mesmo assinante. Uma aceita depósito com saudação normal; outra reproduz a mensagem de ocupado; uma terceira usa uma saudação especial. Na recuperação, uma entrada pode esperar autenticação SIP já concluída e outra pode pedir um PIN por áudio. Entradas genéricas perguntam qual caixa deve ser usada.

Um proxy do tipo “encontre-me” podia escolher entre as portas. Se todos os contatos expirassem sem resposta, apontava para o depósito comum. Se recebesse ocupado em todos, selecionava a saudação correspondente. Um estado de não perturbe podia levar a outra identidade. O correio de voz recebia o alvo operacional escolhido, sem reconstituir a decisão por To, From e costumes da rede telefônica.

Mas as palavras legíveis na URI não formavam uma linguagem do protocolo. A RFC 3087 advertiu a aplicação a não impor regras semânticas a nomes mnemônicos. O operador podia provisionar deposit, um número, um parâmetro ou qualquer URI SIP válida. A tabela que associava identidade e comportamento era uma configuração local controlada pelo dono do sistema.

Por isso, encontrar busy numa captura não comprova que houve ocupado. Comprova que aquela sequência apareceu como destino em um salto. Para conhecer seu significado e a razão da escolha, ainda são necessários a versão da tabela e o registro da reescrita.

Chegar à porta não concedia acesso

Os cenários de recuperação separam seleção e admissão. Uma fonte confiável podia delegar autenticação por meio de uma relação segura com o serviço. Uma autenticação SIP válida podia liberar o fluxo previsto. Se falhasse ou não existisse, o correio de voz ou seu proxy protetor podia redirecionar para uma URI que solicitasse o PIN na própria chamada.

Assim, uma URI específica de consulta escolhia o processo, mas não concedia a leitura. A confiança entre sistemas, as credenciais SIP ou o PIN decidiam a autorização. Mesmo o reconhecimento de um número vindo da PSTN era uma suposição aceita pelo provedor, não prova criptográfica de quem falava.

Todos os fluxos detalhados no RFC pressupõem um proxy de proteção e confiança entre ele e o correio de voz. A seção de segurança não acrescentou defesa: remeteu aos riscos e mecanismos do SIP.

Uma trilha de rede permite, portanto, afirmações limitadas. Um INVITE chegou; o proxy escolheu certa Request-URI; a aplicação aceitou o alvo; um ramo de autenticação foi executado; o RTP começou. Nenhum fato isolado prova que a pessoa era titular da caixa, que a causa anterior era verdadeira, que o áudio foi persistido ou que alguém o ouviu depois.

Configuração local ainda não era vocabulário comum

A RFC 3261 substituiu a primeira especificação SIP e preservou o mecanismo: a Request-URI nomeia o usuário ou serviço atualmente endereçado e o proxy a troca ao selecionar outro alvo. Mais tarde, History-Info passou a transportar o histórico de redirecionamento. Esses documentos explicam as camadas; não demonstram o uso numa instalação da RFC 3087.

Em 2006, a RFC 4458 definiu os parâmetros target e cause para correio de voz e resposta interativa. Sua motivação torna a fronteira visível. Cada fabricante podia permitir mapas locais configuráveis, mas isso não oferecia uma representação interoperável para controle de chamadas, gateways e mensageria unificada de fornecedores diferentes.

A RFC 3087 mostrou como a URI podia servir de superfície de controle dentro de uma arquitetura. A RFC 4458 criou nomes compartilhados para transportar caixa e causa entre implementações. A necessidade do segundo texto não mede implantação, êxito ou fracasso do primeiro.

O legado está na cadeia de evidências. Destino original, Request-URI corrente, razão da reescrita, mapa local, resultado da autenticação, menu, mídia e recibo de armazenamento são fatos relacionados, não equivalentes. Colocar contexto na rota reduz suposições; não transforma roteamento em identidade.

Fontes

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html