Resumo

  • No RFC 3515, uma resposta bem-sucedida ao REFER dizia que o destinatário aceitou processar a instrução e relatar seu estado; não dizia que o pedido indicado havia terminado com sucesso.
  • A assinatura implícita, os NOTIFY com message/sipfrag e a ação indicada tinham ciclos de vida separados. Parar de observar não cancelava a execução, e assinaturas resultantes de bifurcação não podiam ser fundidas.

A narrativa mais conhecida para REFER parece instantânea: Alice pede que Bob entre em contato com Carol, Bob aceita e Carol atende. O protocolo publicado em abril de 2003 não juntava esses momentos. Ele criava registros diferentes justamente para que uma instrução aceita não apagasse tudo o que ainda precisava acontecer.

O RFC 3515, então no Standards Track, definiu o método REFER, o cabeçalho Refer-To e o pacote de eventos refer. A Request-URI identifica quem recebe a ordem; o único valor Refer-To identifica o recurso a ser contatado. O destinatário usa o mecanismo normal do esquema daquela URI. Se for uma URI SIP, isso pode originar um INVITE. Se for outro esquema, outra operação pode ocorrer.

Essa abrangência impede reduzir o documento a uma especificação de transferência telefônica. O REFER podia carregar um corpo, porém o RFC não lhe atribuía um significado universal. O destinatário podia interpretar o conteúdo segundo seu Content-Type, mas essa interpretação local não transformava qualquer texto anexado em uma instrução padronizada.

Antes de agir, o destinatário decidia se aceitaria o pedido. Sintaxe inválida, esquema não suportado, falha de autenticação ou política podiam produzir rejeição. Um REFER bem formado exigia aprovação do usuário ou uma política configurada que a substituísse. Na ausência de outra resposta final, a especificação original mandava devolver 202 Accepted antes que a transação expirasse.

“Accepted” tinha alcance estreito. Confirmava que o agente aceitou a responsabilidade de processar o REFER. Não afirmava que o INVITE subsequente recebeu 200, que um recurso fora de SIP respondeu, que mídia circulou, que uma pessoa participou ou que o objetivo operacional foi alcançado. O novo pedido talvez nem tivesse sido enviado naquele instante.

No contrato original, uma resposta 2xx também criava uma assinatura implícita do evento refer. O agente aceitante passava a enviar NOTIFY. Esse canal não era decoração: ele carregava as evidências de progresso que a resposta ao REFER ainda não tinha.

O primeiro NOTIFY podia chegar antes de a própria transação REFER terminar. Uma implementação precisava aceitar essa inversão aparente. O fluxo de observação podia começar enquanto a troca de aceitação ainda se encerrava. Um relato pendente podia conter somente SIP/2.0 100 Trying. Era uma fotografia de estado, não prova de contato com o alvo.

Cada NOTIFY usava Event: refer e um corpo message/sipfrag iniciado por uma linha de status SIP. A classe da resposta representava o estado da ação indicada naquele ponto. O corpo era uma declaração completa de estado, não um delta cujo sentido dependesse de remontar todas as notificações anteriores.

Uma implementação mínima podia usar 100 para pendência, 200 para sucesso, 503 para falha ou 603 para recusa de aprovação ocorrida depois do aceite do REFER. Essa sequência explica a prudência do 202 inicial: a delegação podia ser aceita, a autorização humana podia falhar depois e o resultado final podia contrariar a expectativa criada pelo primeiro recibo.

Também havia dois “200” diferentes. Quem recebia um NOTIFY respondia à transação NOTIFY com seu próprio 200 OK. Esse 200 confirmava a entrega do relatório. O código contido dentro do message/sipfrag descrevia outra transação, a ação indicada. Resumir ambos como “200” numa tela de operação destrói a fronteira de evidência.

O fragmento podia trazer outros cabeçalhos da resposta SIP indicada, algo útil para diagnóstico e perigoso para segurança. O RFC advertiu que essa divulgação poderia ter consequências graves. Informações de topologia, identidade ou política não se tornam seguras apenas porque ajudam a depurar. Observabilidade extensa não equivale a autoridade para receber todos os detalhes.

Quando o recurso não era SIP, o notificador ainda mapeava o resultado para uma linha de status SIP. A tradução permitia usar o pacote de eventos, mas era a versão do adaptador sobre o que ocorreu. Um SIP 200 no relatório não preservava necessariamente os recibos nativos, o alvo exato, os efeitos colaterais ou a consequência física do outro protocolo.

A assinatura tinha duração própria. O REFER não levava uma expiração para ela. O agente aceitante escolhia a duração e a informava no primeiro NOTIFY, normalmente por tempo suficiente para acompanhar o pedido indicado. O emissor podia renovar ou terminar essa assinatura.

Terminar a observação, porém, não terminava a ação. O RFC afirma que cancelar a assinatura ou rejeitar NOTIFY não instrui o agente a retirar nem abandonar o pedido indicado. Não se devia enviar CANCEL apenas porque o emissor deixou de acompanhar o evento. O canal de monitoramento e a operação executada eram superfícies de controle distintas.

Essa decisão continua relevante fora do SIP. Sistemas confundem “não envie mais atualizações” com “pare o trabalho” e tratam o desaparecimento de uma linha no painel como prova de que o processo acabou. O desenho do RFC 3515 rejeitava essa suposição: a assinatura governava os relatos; a transação indicada mantinha suas próprias regras de cancelamento.

A bifurcação introduzia mais uma separação. Dentro de um diálogo existente, o REFER não se bifurcava sob as regras do documento. Fora de diálogo, ele podia alcançar vários agentes que aceitassem o pedido e criassem assinaturas diferentes. O emissor precisava administrar cada uma separadamente e não podia fundir seus estados. O 200 de um ramo e o 503 de outro descreviam ações realizadas por destinatários diferentes.

Identificadores de diálogo correlacionavam NOTIFY e assinatura, mas correlação não substituía autorização. O destinatário precisava decidir quem podia obrigá-lo a contatar qual recurso. Uma política frouxa poderia transformar REFER num caminho indireto para alvos SIP, HTTP ou de outro tipo que estariam protegidos. A construção de Refer-To e a decisão local tinham de limitar esses recursos.

Documentos posteriores mudaram as opções de observação. O RFC 4488 permitiu solicitar a supressão da assinatura implícita. O RFC 7614 definiu assinatura explícita. O RFC 7647 esclareceu REFER no quadro de eventos atualizado pelo RFC 6665, e o RFC 8217 ajustou sintaxe relacionada. Nada disso fez aceite e resultado virarem a mesma coisa. Quanto mais opcional o canal, mais necessário registrar qual contrato regeu cada traço.

A distinção de Heng Lu entre realidade simbólica e operacional ajuda a ler essa história. O 202 é um recibo simbólico de responsabilidade delimitada. O NOTIFY é a declaração de um notificador identificável. O pedido indicado roda em outro contexto. Mídia, fala, consentimento e conclusão comercial ficam em camadas posteriores. Uma mensagem correta numa camada não fabrica os recibos da camada seguinte.

A escada de evidência começa no REFER válido e no emissor autorizado. Passa pela resposta ao REFER, pela identidade da assinatura ou sua ausência negociada, pelo pedido exato gerado, por cada relatório correlacionado e pela resposta final. Só depois chega à observação da aplicação ou da pessoa. Pular um degrau transforma fato protocolar limitado numa alegação que o traço não sustenta.

O legado do RFC 3515 não é que delegação seja frágil. É que delegar exige registros separados para instrução, observação e execução. O REFER foi aceito — um fato útil e verdadeiro. A ação ainda precisava ocorrer em outro lugar, e seu sucesso precisava de prova própria.

Fontes