Resumo

  • O RFC 3261 identifica um diálogo com Call-ID, tag local e tag remota. A perspectiva se inverte no outro agente: a tag local de um lado é a remota do par.
  • Um INVITE bifurcado pode criar vários diálogos iniciais ou confirmados. Todos compartilham o Call-ID e a tag do iniciador, enquanto cada respondente acrescenta uma To-tag diferente.
  • O diálogo conserva sequência, rota e destino para transações posteriores. Seu identificador correlaciona contexto; não autentica pessoas nem comprova a entrega da mídia.

O endereço era um; os estados podiam ser muitos

A linguagem da telefonia sugere uma unidade simples. Alguém chama um endereço, outro alguém atende e começa uma conversa. O encaminhamento do SIP permitia uma realidade diferente. Um proxy podia enviar o mesmo INVITE ao telefone de mesa, ao softphone e a um gateway. Mais de um aparelho tocava; mais de um podia responder.

O identificador da transação inicial não resolvia o que vinha depois. Uma transação associava a solicitação, suas retransmissões e respostas durante uma troca. Depois do atendimento, ACK, renegociação ou BYE iniciariam transações novas. Qualquer ponta poderia emitir a próxima solicitação; proxies talvez precisassem continuar no trajeto; um dispositivo poderia mudar o endereço de contato.

O SIP precisava, portanto, de um nome para memória compartilhada, não apenas para uma troca de mensagens.

Em março de 1999, o RFC 2543 chamou a relação contínua de call leg e a identificou por Call-ID, To e From. A especificação já enxergava o problema do fork: quando uma solicitação pudesse chegar a vários UAS, cada resposta deveria trazer uma To-tag para que o originador distinguisse os destinos. Respostas diferentes ao mesmo INVITE representavam call legs distintos.

O modelo, porém, ainda dependia dos campos de endereço como um todo. A From-tag era opcional e a construção de Route e Record-Route permanecia incompleta. O SIP 2.0 manteve o fork, mas delimitou melhor o estado que ele criava.

O chamador escrevia apenas metade do nome

Publicado em junho de 2002, o RFC 3261 substituiu call leg por diálogo: uma relação SIP ponto a ponto entre dois agentes de usuário que persiste por algum tempo. Esse contexto ordena mensagens e guarda informações para encaminhar novas solicitações entre os pares.

Em cada UA, o dialog ID tem três componentes: Call-ID, tag local e tag remota. “Local” e “remota” dependem do observador. A tag local de Alice é a remota para Bob; a local de Bob é a remota para Alice. Os valores opacos são os mesmos, mas a orientação se inverte.

A solicitação inicial oferece Call-ID e From-tag, metade do identificador na explicação do RFC. A resposta capaz de criar diálogo acrescenta a To-tag. Para o iniciador, sua From-tag é local e a To-tag recebida é remota; o respondente vê o contrário.

Essa divisão resolveu a bifurcação. Cada ramificação herdava Call-ID e tag do originador, mas cada terminal contribuía com sua própria To-tag. O chamador agrupava sinalização relacionada sem fundir o estado de vários pares.

O Call-ID, por escolha de projeto, não era suficiente. Tags também não eram nomes de usuário nem credenciais. O RFC 3261 exigiu que uma tag gerada fosse globalmente única e criptograficamente aleatória, com pelo menos 32 bits de aleatoriedade. A regra reduzia colisões de contexto; não autenticava Alice, autorizava Bob ou confirmava um nome exibido.

O diálogo podia nascer enquanto o telefone tocava

Para INVITE, uma resposta provisória de 101 a 199 com To-tag cria um early dialog. O originador já pode guardar estado específico daquele respondente antes da decisão final. Um 2xx confirma o diálogo correspondente. Uma falha, ou a ausência de sucesso naquela ramificação, encerra o diálogo inicial conforme as regras centrais.

Num fork, vários early dialogs podem coexistir: um aparelho toca, outro informa progresso, um terceiro recusa. Eles compartilham a contribuição inicial e se diferenciam pelas tags remotas. Mais de um 2xx pode chegar e gerar vários diálogos confirmados que a aplicação precisa reconhecer e depois resolver.

PRACK trata de uma questão próxima, mas não igual. RSeq e RAck tornam certas respostas provisórias confiáveis e ordenadas; as tags dizem a qual contexto de par elas pertencem. A confiabilidade funciona dentro de um early dialog já nomeado, sem substituir sua identidade.

A Via branch também está em outra camada. Ela identifica a transação e suas retransmissões. A tupla do diálogo permanece após o fim da transação e aparece em outras novas. Confundi-las apaga cedo demais a relação ou combina solicitações diferentes como se fossem a mesma troca.

A tupla guardava uma máquina de estado

O diálogo não armazenava apenas três valores de cabeçalho. O RFC 3261 inclui números de sequência local e remoto, URIs das pontas, remote target, indicador seguro e route set ordenado.

Cada direção tem seu CSeq. Um agente incrementa a sequência local ao gerar uma nova solicitação no diálogo; o par conserva a sequência remota e pode rejeitar um valor menor. Um salto não é necessariamente defeito: uma tentativa anterior pode ter parado num desafio de autenticação antes de chegar ao UAS. O número fornece ordem relativa, não a garantia de que todo inteiro apareceu.

O route set registra os proxies que pediram permanência no caminho. O UAS o aprende dos Record-Route da solicitação; o UAC, da resposta em ordem inversa. Os fluxos completos do RFC 3665 mostram Call-ID e as duas tags reaparecendo em ACK, BYE e respostas, enquanto Route mantém os proxies selecionados.

O remote target responde a outra pergunta: para qual Contact atual enviar a próxima solicitação. Ele nasce na criação do diálogo e uma target-refresh request bem-sucedida pode alterá-lo. Num diálogo criado por INVITE, o RFC 3261 define re-INVITE como atualização básica.

Mudar Contact não muda Call-ID ou tags e não reescreve o route set. A tupla indica “qual contexto”; a rota, “por quais intermediários”; o alvo, “qual endereço atual”. Separar as três respostas impediu que um único campo acumulasse correlação, política de caminho e mobilidade.

Sinalização não era som

Depois do estabelecimento, qualquer ponta pode iniciar nova transação. O emissor se torna UAC e o receptor UAS para aquela operação, independentemente dos papéis no INVITE original. A relação contínua ultrapassa uma única assimetria cliente-servidor.

O RFC 3264 deixa a negociação de mídia para SDP offer/answer. Oferta e resposta descrevem streams, codecs, endereços e portas, enquanto um protocolo superior como SIP associa as trocas. Ofertas posteriores podem acrescentar, remover ou modificar mídia no mesmo diálogo.

Um diálogo confirmado não prova que o áudio chegou, não identifica uma fonte RTP e não certifica qualidade. Ele organiza o contexto de sinalização; o plano de mídia precisa produzir evidência própria.

O RFC 4028 acrescentou timers negociados e atualizações com re-INVITE ou UPDATE. Diálogos nascidos do mesmo INVITE podem ter intervalos diferentes, ou nenhum timer. Cada refresh é nova transação no contexto existente. O sucesso prolonga a sessão; a ausência pode levar a BYE. A tupla não concede permanência.

Um diálogo podia conter vários usos

Extensões mostraram por que “um diálogo, uma chamada” também era simplificação. INVITE cria um invite usage; SUBSCRIBE ou REFER dentro dele pode criar usos extras. O RFC 5057 explica que eles compartilham Call-ID, tags, CSeq, route set, contatos, remote target e indicador seguro, mas guardam estado específico, como o prazo de cada assinatura.

Encerrar um uso normalmente não elimina os demais. BYE pode terminar o invite usage enquanto uma assinatura de eventos permanece. Encerrar a assinatura não precisa destruir o convite. O diálogo é contêiner comum de sinalização, não destino único de toda relação de aplicação.

O RFC 6665 torna o limite concreto. SUBSCRIBE e NOTIFY usam o diálogo, mas Event também participa da correspondência da assinatura específica. Um SUBSCRIBE bifurcado pode estabelecer diálogos independentes, atualizados separadamente. A tupla encontra o contexto comum; não é a chave completa de todo uso.

A força do identificador veio de seu escopo estreito. Ele nomeou o contexto entre pares enquanto transações terminavam, o Contact mudava, a rota ficava, a mídia se transformava e aplicações adicionavam estado. Não tentou identificar esses fenômenos no lugar deles.