Resumo

  • No RFC 2543, branch separava sobretudo as cópias produzidas por um proxy que bifurcava uma chamada; no RFC 3261, tornou-se obrigatório e quase sempre único no espaço e no tempo.
  • z9hG4bK não autentica ninguém. O prefixo avisa que o valor foi criado sob a regra nova e permite evitar a correspondência legada, mais ampla e ambígua.
  • Uma retransmissão conserva o branch; uma nova tentativa de encaminhamento recebe outro. CANCEL e o ACK de resposta não 2xx o reutilizam de propósito, pois precisam reencontrar uma transação precisa.

Antes do prefixo, branch queria dizer “esta cópia do fork”

Uma solicitação SIP pode atravessar vários proxies. Cada salto acrescenta um Via e, quando mantém estado, abre uma transação cliente para cada destino que resolve tentar. A pilha de Via fornece o caminho de volta das respostas.

O primeiro padrão completo do protocolo, o RFC 2543, já definia o parâmetro branch. Seu alcance era modesto: um proxy que produzisse várias cópias isomórficas precisava distingui-las. Entre essas cópias, o token tinha de ser único. Um proxy sem bifurcação podia omiti-lo.

Por isso, o branch não bastava para declarar “esta é a mesma transação”. A correspondência também percorria To, From, Call-ID, CSeq e o primeiro Via. O sistema funcionava, mas o receptor precisava reunir vários sinais e ainda saber com qual geração de implementação estava conversando.

O problema histórico não era apenas economizar comparações. Ao ampliar o significado de um campo existente, o novo protocolo precisava provar localmente que o emissor aceitara a nova obrigação. Sem essa prova, o receptor teria de inferir modernidade pelo fornecedor, pela rede ou pelo comportamento — fontes frágeis de autoridade.

O RFC 3261 marcou a mudança dentro do próprio valor

O RFC 3261, publicado em 2002, tornou o Via superior e seu branch obrigatórios para clientes SIP. Salvo exceções definidas, o valor passou a ser único no espaço e no tempo entre todas as solicitações produzidas pelo agente.

A nova regra veio acompanhada de uma assinatura visível: todo branch conforme deveria começar com z9hG4bK. O padrão escolheu uma sequência de sete caracteres improvável de aparecer por acaso em implementações do RFC 2543. Não há data, rota, fabricante ou identidade codificada ali. O prefixo apenas seleciona um regime de interpretação.

Chamá-lo de “magic cookie” pode sugerir senha, cookie de navegador ou desafio criptográfico. Ele não é nada disso. É uma testemunha de versão. O resto do token afirma unicidade; os sete primeiros caracteres dizem sob qual contrato essa afirmação foi construída.

A correspondência moderna ficou curta porque a promessa ficou mais forte

Quando o cookie está presente, uma transação de servidor confronta o branch do Via superior, o sent-by desse Via e o método. O ACK tem uma exceção estreita: quando reconhece uma resposta final não 2xx, pertence à transação INVITE que procura. sent-by continua relevante porque dois emissores podem repetir um token, acidentalmente ou não.

Quando o prefixo falta, o receptor não finge que a promessa moderna existe. Ele usa o procedimento compatível com o RFC 2543, combinando Request-URI, tags, Call-ID, CSeq e Via conforme o caso. Assim, SIP manteve duas populações de tráfego sem atribuir retroativamente uma garantia nova à população antiga.

Na direção das respostas, branch e método do CSeq trabalham juntos. Isso importa porque CANCEL utiliza o branch da solicitação que pretende cancelar, mas constitui outra transação. O token reduz a área de busca; os demais campos preservam a semântica.

Os fluxos do RFC 3665 tornam a escala dessa identidade evidente: cada proxy empilha seu Via ao enviar e remove a camada correspondente no retorno. Branch nomeia a relação transacional entre vizinhos, não a chamada inteira.

Repetir uma tentativa exige repetir sua evidência

Um proxy com estado cria um branch novo para cada tentativa de saída. Se o primeiro destino falha e o proxy tenta outro, nasce outra transação cliente. Se a mensagem volta ao mesmo proxy após uma mudança relevante nos parâmetros de processamento, pode haver uma espiral legítima; uma implementação que detecte loops pode incorporar esses parâmetros numa parte separável do branch.

Retransmissão é o caso oposto. O pacote repetido representa a mesma tentativa e precisa carregar o mesmo branch. Só assim o servidor encontra o estado já existente e devolve a resposta armazenada, em vez de executar novamente a operação.

Para um proxy sem estado, esse requisito cria uma tensão real. Ele não guarda uma tabela de pacotes anteriores, mas também não pode sortear outro valor a cada chegada. O RFC 3261 determina que a parte estável seja derivada de campos e configuração que não mudem entre retransmissões. Unicidade sem reprodutibilidade fragmentaria a transação; reprodutibilidade sem unicidade misturaria tentativas.

CANCEL compartilha a pista, não o desfecho

CANCEL precisa percorrer o mesmo caminho salto a salto e localizar exatamente a solicitação ainda pendente. Ele copia Request-URI, Call-ID, tags, número de CSeq, Via superior e branch; apenas o método do CSeq muda para CANCEL. Até um proxy sem estado consegue repetir a decisão de encaminhamento.

Isso não transforma CANCEL e INVITE numa única transação. O servidor pode responder 200 ao CANCEL e, separadamente, encerrar o INVITE com 487. Também pode existir uma resposta final que venceu a corrida antes do cancelamento. O 200 prova que o pedido de cancelar foi entendido e processado, não que a chamada original foi apagada da história.

O RFC 3261 separou formalmente esses destinos depois de o RFC 2543 tê-los tratado de modo mais entrelaçado. Reutilizar branch fornece correlação suficiente para encontrar o alvo, sem fundir os resultados.

O tipo de resposta final divide dois ACKs

Quando INVITE termina com uma resposta não 2xx, o ACK permanece dentro da transação. Ele reutiliza o Via superior e o branch do INVITE, muda o método e é absorvido pela máquina de estados do salto. A mesma cadeia que tratou o fracasso encerra suas retransmissões.

Depois de uma resposta 2xx, a topologia muda. Um fork pode produzir mais de um diálogo aceito, e todos os sucessos precisam alcançar quem iniciou a chamada. O núcleo do agente do usuário envia o ACK de ponta a ponta, seguindo a rota do diálogo e construindo um Via com branch novo. Esse ACK fica fora da transação INVITE original.

A diferença protege informação. O ACK de falha deve localizar uma máquina de estados existente; o ACK de sucesso não pode ser engolido por um intermediário antes de alcançar outro destino que também aceitou.

As correções posteriores mexeram no tempo, não na identidade

Uma chave de correspondência melhor não eliminou defeitos das máquinas de estado. O RFC 4320 corrigiu comportamentos de resposta e timeout para transações não INVITE. O RFC 6026 criou o estado Accepted e o Timer L, preservando estado suficiente para absorver retransmissões após uma resposta 2xx.

O RFC 6026 ainda mantém tratamento especial para ACK legado cujo branch não traz o cookie. A permanência desse detalhe mostra o limite da reforma: é possível corrigir por quanto tempo o estado vive, mas o receptor continua precisando saber quais suposições de identidade vieram do emissor. O RFC 5359 registra fluxos posteriores que utilizam a convenção; é evidência da gramática especificada, não um levantamento do parque instalado.

O que sete caracteres jamais provaram

Qualquer remetente pode escrever z9hG4bK. O marcador não autentica usuário ou equipamento, não autoriza uma chamada, não protege integridade e não demonstra que o sufixo seja realmente único. TLS pode proteger um salto; autenticação digest pode sustentar uma alegação de credencial; política local pode aceitar ou recusar a mensagem. Nenhuma dessas autoridades nasce do branch.

Transação também não é diálogo. Call-ID e tags descrevem a relação de diálogo; route sets guiam solicitações posteriores; SDP e RTP mantêm outras formas de estado. Uma correspondência correta diz somente que a mensagem recebida pertence à transação local encontrada pelas regras aplicáveis.

O feito durável foi introduzir uma obrigação mais forte sem exigir fé na procedência. O emissor marcou o conjunto de compatibilidade; o receptor conseguiu verificar a marca e executar uma regra delimitada. O prefixo tinha pouca semântica justamente para não receber mais poder do que podia sustentar.

Fontes e limites da evidência

O conjunto fechado de fontes reúne RFC 2543, RFC 3261, RFC 3665, RFC 4320, RFC 5359 e RFC 6026. Eles sustentam a evolução normativa, as regras de correspondência, os fluxos exemplares e as correções. Não medem participação atual, conformidade de produtos, qualidade de chamada nem frequência real de colisões.