Resumo

  • A RFC 5368 faz o Refer-To apontar para uma lista e manda o destinatário criar um pedido SIP independente para cada alvo efetivo. Aceitar o REFER não comprova o resultado desses pedidos.
  • A especificação recomenda norefersub e Refer-Sub: false, retirando a assinatura implícita que normalmente envia estados message/sipfrag, porque ela não representa várias transações.
  • O receptor não pode ser um amplificador cego: deve entender método e aplicação, autenticar e autorizar o emissor. A prova ainda precisa ligar Content-ID, não bifurcação, normalização, filhos e observação específica do serviço.

O formato carregava mais possibilidades que a operação

A lista baseada na RFC 4826 e ampliada pela RFC 5364 pode marcar entradas como to, cc ou bcc, além de pedir anonimização. Em um convite, essas propriedades podem orientar o histórico de destinatários exposto a cada participante.

Uma solicitação BYE em um diálogo existente não possui a mesma semântica de cópia. O destinatário não ganha um papel de “cc” no encerramento de uma sessão. O fato de o XML aceitar o atributo não obriga o método a produzir um significado para ele.

Essa diferença protege contra um erro frequente em plataformas genéricas: validar o esquema e concluir que a operação é válida. A RFC 5368 diz que o destinatário deve aceitar REFER apenas no contexto de uma aplicação que compreende e não deve aceitar métodos que não compreende. Ele não é um servidor burro para espalhar mensagens aleatórias.

Antes de criar qualquer filho, o serviço autentica o emissor, verifica sua autorização, aplica regras de opt-in, identifica os diálogos ou recursos relevantes e decide se o método é permitido. A marca multiple-refer anuncia uma capacidade de protocolo; não resolve nenhuma dessas decisões.

Um REFER criou várias autoridades de transação

O emissor entrega uma ordem ao REFER-Recipient. Nesse primeiro vínculo, o destinatário atua como UAS. Depois ele se torna UAC de cada pedido direcionado aos REFER-Targets. Cada troca tem identificadores, políticas e resultados próprios.

No exemplo de conferência, uma resposta 202 Accepted volta antes de os BYE serem enviados. Logo, ela só pode atestar que o serviço aceitou tentar a ordem. Não atesta a existência do diálogo remoto, a emissão do BYE, a resposta do participante ou a mudança no estado da conferência.

Um modelo operacional fiel mantém um pai e vários filhos. O pai guarda a requisição REFER, a lista resolvida, autorização e resposta. Cada filho guarda alvo normalizado, método, contexto de diálogo, envio, respostas e encerramento. O pai pode estar aceito enquanto um filho é recusado, outro expira e um terceiro termina.

Duplicatas precisam de uma trilha própria. A lista original, o conjunto efetivo depois da comparação de URI e a quantidade de solicitações enviadas podem divergir legitimamente. Sem a regra aplicada, a redução parece perda; sem os três conjuntos, a perda pode parecer normalização.

O canal conhecido de resultado foi desligado

No REFER com um alvo, a assinatura implícita do evento refer envia NOTIFY com corpo message/sipfrag. Ela descreve a transação iniciada pelo receptor.

Com muitos alvos, não há uma única transação a descrever. Os resultados podem ocorrer fora de ordem e permanecer em fases diferentes. A RFC 5368 afirma que não oferece mecanismo para o emissor conhecer todos os resultados e recomenda suprimir a assinatura implícita.

O emissor usa Require: multiple-refer, norefersub e, quando apropriado, Refer-Sub: false. O receptor deve responder com false e não criar a assinatura. A falta de NOTIFY passa a ser comportamento contratado.

Silêncio, portanto, não é sucesso. Um sistema que recebe 2xx, não vê erro e fecha todos os filhos converte a ausência deliberada de um canal em prova inventada. O acompanhamento deve vir da aplicação: estado de conferência, evento específico ou registro de execução.

O false enviado não era o false concedido

Refer-Sub: false na requisição registra o pedido do emissor. A resposta registra a decisão do receptor. Se o 2xx omitir o campo ou trouxer true, a assinatura implícita surge normalmente.

Guardar apenas o lado de saída leva o monitor a esperar silêncio quando deveria esperar NOTIFY. Guardar apenas a resposta perde as opções exigidas, o ponteiro da lista e o método pretendido. Os dois pacotes formam o recibo de negociação.

Se o receptor não suporta norefersub exigido, responde 420. Isso comprova incompatibilidade da extensão naquele recurso, não rejeição dos alvos. Retirar a exigência e repetir pode mudar o diálogo e o plano de evidência; não deve ser uma correção automática invisível.

A ausência de fork sustentava a supressão

A assinatura implícita também revela diálogos quando REFER se bifurca. A RFC 4488 só permite pedir false quando o emissor tem certeza de que não haverá fork. A RFC 5368 usa uma GRUU no exemplo para garantir um destinatário.

O registro deve preservar Request-URI, rota, razão de não bifurcação, branch da resposta e identidade do receptor. Um balanceador que escolhe um processo não é necessariamente a mesma garantia; é preciso saber se o nível SIP poderia entregar a múltiplos agentes independentes.

Sem essa prova, suprimir notificações pode esconder vários executores e tornar uma resposta insuficiente para identificar quem multiplicou a lista.

Content-ID amarrava a ordem aos bytes

Refer-To carrega um URL cid: e o corpo carrega a lista. Para demonstrar o que foi autorizado, é preciso guardar o identificador, o objeto rotulado, tipo e disposição, limites MIME, bytes e hash.

A RFC 8262 revelou uma lacuna nos exemplos antigos. A RFC 5368 mostrava um corpo completo identificado, embora a regra anterior só definisse referência a uma parte. O texto posterior permitiu explicitamente apontar para uma parte ou para o corpo inteiro, usando Content-ID MIME ou SIP.

Uma captura histórica não pode ser julgada só pela regra atual. O verificador precisa saber o comportamento implementado e qual objeto o parser resolveu. Intermediários que reempacotam o corpo devem manter cabeçalho e conteúdo coerentes.

Estado de conferência não era recibo de rede

A RFC sugere observar o pacote de estado da conferência para saber quais participantes aparecem depois de INVITE ou BYE múltiplos. É uma fonte de estado da aplicação, não uma continuação oculta da resposta REFER.

Notificações de conferência são versionadas e podem ser completas ou parciais. Uma assinatura pode sofrer lacunas. O desaparecimento de um participante sustenta uma afirmação sobre a visão atual do focus, mas não prova sozinho que um BYE específico causou a saída.

Conciliar significa manter lado a lado pedido, filhos emitidos, respostas e estado observado. Um filho concluído sem mudança de estado e uma mudança sem filho correspondente são sinais diferentes e úteis.

Limite de evidência

Depois de um REFER múltiplo aceito, só é seguro dizer que certo receptor aceitou certa ordem, cuja referência Content-ID resolveu para certo conjunto efetivo, sob certa decisão de assinatura. Não se pode acrescentar que todos os alvos executaram a ação.

O conjunto mínimo inclui identidade e autorização do emissor; contexto da aplicação; base de não fork; pedido e resposta exatos; objeto Content-ID; lista submetida e normalizada; registro por pedido filho; resultado individual; estado do serviço com versão e horário; e resultado humano ou comercial separado.

A lista reduz mensagens do controlador. Ela não reduz o número de verdades que a operação pode produzir.