SIP Call Flow explicado: um passo a passo de cada mensagem

Toda chamada VoIP bem-sucedida é uma curta sequência de mensagens SIP trocadas em uma ordem rigorosa. Quando algo quebra (áudio unidirecional, sem tom de chamada, chamadas que caem na marca dos quatro minutos, chamadas que completam com o codec errado), a resposta quase sempre está visível nessa sequência. Ler um trace SIP é uma habilidade fundamental para qualquer pessoa que projeta, implanta ou soluciona problemas em redes de voz, e o primeiro passo é saber exatamente como cada mensagem se parece, para onde vai e o que carrega.

Este artigo percorre cada mensagem em uma chamada SIP típica, desde o INVITE inicial até o 200 OK final no BYE, incluindo o offer/answer SDP que negocia o caminho de áudio. Em seguida, cobrimos os fluxos de falha mais comuns que você verá em traces de produção (ocupado, desafio de autenticação, CANCEL durante o toque) e as modificações em chamada usadas para espera, mudanças de codec e transferência. Se você deseja primeiro a visão conceitual, o artigo complementar Fundamentos de sinalização SIP cobre os papéis do protocolo e a arquitetura em um nível mais alto.

As três fases de uma chamada SIP

Toda chamada SIP passa por três fases, e cada mensagem que você verá em um trace pertence a uma delas. As fases são úteis porque mapeiam diretamente o que deveria estar acontecendo na rede em um dado momento.

Estabelecimento cobre as mensagens que criam o diálogo: INVITE, as respostas provisórias (100, 180, às vezes 183 com early media), o 200 OK final e o ACK que fecha o handshake. Aproximadamente 90% dos problemas de chamada aparecem nesta fase.

Troca de mídia é o período após o ACK durante o qual os pacotes RTP fluem diretamente entre os terminais (ou através de um B2BUA que ancora a mídia). Nenhuma mensagem SIP é trocada durante esta fase, a menos que algo mude na sessão.

Encerramento fecha o diálogo com um BYE de qualquer lado e um 200 OK confirmando o recebimento. Uma vez que ambas as mensagens são trocadas, o diálogo deixa de existir e quaisquer mensagens posteriores com o mesmo Call-ID serão rejeitadas.

Fase 1: estabelecimento da chamada, mensagem por mensagem

É aqui que a chamada nasce. Alice (em company.com) está ligando para Bob (em provider.com). Vamos examinar cada mensagem na rede, cabeçalho por cabeçalho, para que você possa associar o que vê em um trace com o que o protocolo está realmente fazendo.

Passo 1: O INVITE

O telefone de Alice constrói um INVITE e o envia em direção ao domínio de Bob. A primeira linha é a linha de requisição, nomeando o método (INVITE), o URI de destino e a versão do SIP. Os cabeçalhos que seguem identificam as partes, o diálogo, o caminho e o corpo.

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 142

Vários pontos merecem atenção. O cabeçalho From possui um tag gerado pelo telefone de Alice; o cabeçalho To ainda não tem um tag porque o diálogo ainda não foi estabelecido (o UAS de Bob adicionará um To-tag na resposta). O parâmetro branch do Via começa com z9hG4bK, que é o magic cookie que marca a mensagem como compatível com RFC 3261. O Call-ID permanece constante durante toda a vida do diálogo. O CSeq começa em um inteiro arbitrário e incrementa a cada novo método de requisição dentro do diálogo.

Passo 2: 100 Trying

O próximo hop responde quase imediatamente com um 100 Trying provisório. Este é um acknowledgment hop-by-hop, não end-to-end, e seu único propósito é parar a retransmissão do INVITE pelo telefone de Alice enquanto o próximo hop faz seu trabalho.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 314159 INVITE
Content-Length: 0

Note que os cabeçalhos Via, From, To, Call-ID e CSeq são copiados da requisição. O roteamento SIP depende dessa consistência: a resposta viaja de volta pela mesma cadeia Via em ordem reversa, e os cabeçalhos correspondentes vinculam a resposta à requisição que ela responde. Um 100 Trying nunca chega à tela do chamador, e não há ACK para nenhuma resposta 1xx.

Passo 3: 180 Ringing

Quando o INVITE chega ao telefone de Bob, o dispositivo começa a alertar (o telefone toca) e envia de volta um 180 Ringing. Esta é a mensagem que aciona o tom de chamada no lado de Alice.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Length: 0

O cabeçalho To agora tem um tag adicionado pelo UAS de Bob (tag=314259). A partir deste ponto, a combinação de Call-ID, From-tag e To-tag identifica exclusivamente o diálogo. Uma variante deste passo é o 183 Session Progress, que carrega uma resposta SDP e é usado para entregar early media (ringback in-band ou anúncios da rede antes que a chamada seja atendida).

Passo 4: 200 OK

Quando Bob atende, seu telefone envia um 200 OK com sua própria resposta SDP. Esta é a mensagem mais importante de todo o fluxo: ela aceita a chamada e define os parâmetros de mídia.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 139

v=0
o=bob 2890844527 2890844527 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000

O corpo após a linha em branco é o SDP. A linha m=audio declara que Bob receberá áudio na porta UDP 49170 e suporta os codecs 0 (PCMU) e 8 (PCMA). A linha c= fornece o endereço IP. O telefone de Alice começará a enviar RTP para 198.51.100.20:49170 assim que processar esta mensagem.

Passo 5: ACK

O telefone de Alice confirma o 200 OK com uma requisição ACK. O ACK é único no SIP porque é uma requisição que fecha uma transação em vez de abrir uma.

ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK4321
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314159 ACK
Content-Length: 0

Dois detalhes merecem destaque. O número CSeq permanece em 314159 (corresponde ao INVITE), mas o método muda para ACK. O Request-URI agora é o endereço de Contact de Bob do 200 OK em vez do sip:[email protected] original, porque o ACK viaja diretamente ao terminal de Bob, contornando proxies que possam ter estado no caminho original. O diálogo agora está totalmente estabelecido.

O modelo offer/answer do SDP

O SIP apenas negocia a chamada. A mídia real usa RTP, e os parâmetros dessa sessão RTP são negociados dentro dos corpos SDP transportados pelas mensagens SIP. O mecanismo é chamado offer/answer, definido na RFC 3264.

O INVITE de Alice carrega um SDP offer listando cada codec que seu telefone suporta, em ordem de preferência. O 200 OK de Bob carrega um SDP answer listando apenas os codecs que ele está disposto a usar, na ordem que prefere, mais o endereço IP e a porta onde deseja receber RTP. A interseção dessas duas listas é o codec que a chamada realmente usará.

Um offer simples pode ser assim:

m=audio 49172 RTP/AVP 0 8 9 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=sendrecv

Alice está oferecendo G.711 µ-law (0), G.711 A-law (8), G.722 (9) e G.729 (18). A resposta de Bob reduz isso a um codec, tipicamente a opção de maior prioridade na lista de preferências de Bob que também está no offer de Alice. O atributo a=sendrecv indica que a mídia é bidirecional; outros valores incluem sendonly, recvonly e inactive, que se tornam importantes durante a espera de chamada.

Duas falhas comuns residem no SDP. A primeira é a ausência de sobreposição entre as listas de codecs oferecidos, o que produz uma resposta 488 Not Acceptable Here e a chamada nunca conecta. A segunda é um problema de Network Address Translation (NAT) onde o endereço c= dentro do SDP é um IP privado que o outro lado não consegue alcançar, produzindo uma chamada conectada sem áudio em uma ou ambas as direções. Um SBC corrige ambos os problemas normalizando o SDP antes de encaminhá-lo.

Fase 2: mídia fluindo sobre RTP

Uma vez que o ACK é enviado, o diálogo SIP fica silencioso e o RTP assume. Os pacotes RTP são pequenos datagramas UDP carregando 20 ms de áudio codificado cada, fluindo a cada 20 ms em cada direção. Para uma chamada estabelecida de 30 minutos sem modificações, você pode esperar aproximadamente 180.000 pacotes RTP no total e exatamente zero mensagens SIP.

O RTP funciona junto com o RTCP (RTP Control Protocol), que transporta relatórios de qualidade em uma porta separada (geralmente a porta RTP + 1). Os pacotes RTCP são como os terminais trocam estatísticas de jitter, perda de pacotes e atraso de ida e volta. Muitos SBCs usam dados RTCP para gerar pontuações MOS e alertas de qualidade de chamada, mesmo sem gerar o áudio eles mesmos.

Um aspecto que surpreende engenheiros iniciantes é que o RTP é apenas portador e não tem conceito do diálogo SIP. Se um telefone para de receber RTP, ele não tem como saber no nível SIP se o outro lado desligou, congelou ou simplesmente perdeu a conectividade de rede. Por isso, a maioria dos user agents implementa um session timer (RFC 4028): eles enviam periodicamente um re-INVITE ou UPDATE durante chamadas longas para confirmar que o diálogo ainda está ativo. Se a atualização falhar, o lado que detectou a falha encerra a chamada com um BYE.

Fase 3: encerramento da chamada com BYE

Quando qualquer parte desliga, esse lado envia um BYE dentro do mesmo diálogo.

BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK998
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314160 BYE
Content-Length: 0

O CSeq avançou em um (agora 314160) porque BYE é uma nova requisição dentro do diálogo. O outro lado responde com 200 OK confirmando o BYE. O RTP para em ambas as direções e o estado do diálogo é destruído em ambos os terminais. Qualquer mensagem SIP subsequente com este Call-ID produzirá um 481 Call/Transaction Does Not Exist.

Clique para ampliar.

Quando a chamada não conecta: cenários de falha

A maioria das chamadas reais é bem-sucedida, mas quando falham, o modo de falha é geralmente um de quatro padrões comuns. Reconhecer o código de resposta na rede indica imediatamente o que investigar.

Desafio de autenticação: 401 ou 407

Se o próximo hop requer autenticação (um provedor de SIP Trunking, um PBX corporativo com imposição de registro), ele responde ao primeiro INVITE com um 401 Unauthorized (quando o próprio terminal desafia) ou 407 Proxy Authentication Required (quando um proxy intermediário desafia). O desafio inclui um cabeçalho WWW-Authenticate ou Proxy-Authenticate contendo um realm e um nonce.

O user agent do chamador então envia um segundo INVITE com o mesmo Call-ID, mas um CSeq incrementado, contendo um cabeçalho Authorization com um digest computado a partir do nonce, do URI e do segredo compartilhado. Se o digest for validado, o fluxo continua normalmente com 100 Trying, 180 Ringing e 200 OK. Se falhar, um 403 Forbidden encerra o diálogo. Strings de realm incompatíveis entre o SBC e o provedor upstream são uma das causas mais comuns de tickets do tipo “registro funciona, mas chamadas falham”.

Ocupado: 486

Um 486 Busy Here significa que o terminal chamado está em outra chamada e não pode aceitar esta. O diálogo termina imediatamente, e o user agent do chamador tipicamente reproduz um tom de ocupado. Um 600 Busy Everywhere indica que o usuário está globalmente indisponível, o que encerra tentativas de fork em qualquer proxy de encaminhamento.

Sem resposta: 408 ou 480

Se Bob nunca atende, a chamada termina de duas maneiras. Um 480 Temporarily Unavailable é enviado pelo próprio telefone de Bob quando o timer de toque expira (frequentemente após 30 a 60 segundos). Um 408 Request Timeout é gerado pela rede se nenhuma resposta de qualquer tipo retorna dentro do Timer B (padrão de 32 segundos para UDP). Cada um conta uma história diferente: 480 significa que a chamada chegou ao terminal e foi rejeitada pela política do terminal; 408 significa que a chamada nunca obteve uma resposta utilizável de nada downstream.

CANCEL: chamador desliga durante o toque

Se Alice desliga enquanto ainda ouve o tom de chamada (antes que o telefone de Bob atenda), seu user agent envia um CANCEL referenciando o mesmo parâmetro branch do INVITE original. CANCEL é uma requisição, não uma resposta. O lado de Bob responde com duas mensagens: um 200 OK para o próprio CANCEL, e um 487 Request Terminated para o INVITE original. O user agent de Alice confirma o 487 com um ACK, e o diálogo é destruído antes de ter sido totalmente estabelecido. Interpretar erroneamente um fluxo CANCEL como uma chamada falhada é uma fonte frequente de métricas ASR incorretas em análises de CDR brutos.

Mudanças durante a chamada: re-INVITE, UPDATE e REFER

Uma vez que o diálogo é estabelecido, a chamada não fica congelada. Qualquer parte pode enviar uma nova requisição dentro do diálogo existente para modificar a sessão. Três métodos fazem a maior parte do trabalho.

O re-INVITE é o principal. Ele usa o mesmo Call-ID, From-tag e To-tag do INVITE original, mas carrega um novo SDP offer. O uso mais comum é a espera de chamada: a parte que coloca em espera envia um re-INVITE com a linha de mídia modificada (a=sendonly, ou o IP de conexão definido como 0.0.0.0 em implementações mais antigas), a parte em espera retorna um 200 OK com a resposta correspondente, e o áudio para em uma direção até que um segundo re-INVITE o restaure. Re-INVITEs também são usados para renegociação de codec (mudando de G.711 para G.729 quando as condições de rede se degradam) e para a mudança de voz para T.38 no SIP quando um fax é detectado.

UPDATE é semelhante ao re-INVITE, mas projetado para modificar a sessão antes que ela esteja totalmente estabelecida (durante o estado de diálogo inicial após um 180 Ringing). É bastante usado por algumas operadoras para atualizar session timers e detalhes do SDP sem esperar que a chamada seja atendida.

REFER implementa a transferência de chamada. A parte que transfere envia um REFER ao outro lado contendo um cabeçalho Refer-To nomeando o destino da transferência. O lado receptor envia um NOTIFY de volta conforme a transferência progride, indicando se a nova chamada conectou. Tanto a transferência assistida (consultar primeiro, depois transferir) quanto a transferência cega (transferir imediatamente) usam REFER; a diferença é apenas se a parte que transfere já estabeleceu um segundo diálogo com o destino.

O que um SBC faz em cada etapa

Um SBC fica no meio deste fluxo como um B2BUA, o que significa que a chamada que você vê em um lado dele não é o mesmo diálogo SIP que a chamada do outro lado. Para Alice, o SBC parece ser Bob; para Bob, o SBC parece ser Alice. Dois diálogos independentes existem, cada um com seu próprio Call-ID, From-tag, To-tag e contador CSeq, unidos pela lógica interna de roteamento do SBC.

Essa arquitetura muda o que cada mensagem no fluxo pode fazer. No INVITE, o SBC pode reescrever cabeçalhos para atender às expectativas do sistema downstream (é aqui que a manipulação de cabeçalhos SIP opera), remover endereços IP privados do Via e Contact para ocultação de topologia, e aplicar limitação de taxa ou regras antifraude antes do encaminhamento. No 200 OK, o SBC reescreve o SDP para que a mídia flua através do SBC em vez de diretamente entre os terminais, o que lhe dá a capacidade de transcodificar codecs (G.711 para G.729, ou AMR para G.711 em interconexões móvel-para-fixo), impor criptografia SRTP e aplicar monitoramento de qualidade a cada pacote RTP.

Nos fluxos de falha, o SBC pode mapear códigos de resposta entre dialetos: um 503 Service Unavailable downstream pode ser traduzido para um 486 Busy Here upstream para manter o comportamento de retry razoável. Em re-INVITEs para espera ou mudanças de codec, o SBC pode escolher passá-los adiante, terminá-los em seu próprio lado e absorver a mudança, ou acionar ajustes de transcodificação. Em um CANCEL, o SBC propaga o cancelamento downstream para que a parte chamada pare de alertar, e então limpa ambos os legs.

O resultado prático é que um SBC corretamente configurado remove a maior parte da variância que você veria entre implementações SIP. Dois fornecedores que não conseguem interconectar diretamente se interconectarão através do SBC, porque o SBC normaliza o fluxo de chamada em cada leg para corresponder ao que aquele leg espera.

Conclusão

O fluxo de chamada SIP é curto, determinístico e visível. Cinco mensagens levam uma chamada da discagem à conversa (INVITE, 100 Trying, 180 Ringing, 200 OK, ACK), duas mensagens a encerram (BYE, 200 OK), e um punhado de respostas de falha cobre quase todo problema do mundo real. Dentro dos corpos, o offer/answer SDP lida com a negociação de mídia, e o áudio em si flui sobre RTP em um canal separado que o SIP nunca toca.

Saber o que cada mensagem carrega, em que ordem, e o que muda entre requisição e resposta é a diferença entre adivinhar em um trace SIP e lê-lo. Para engenheiros integrando SIP Trunks, solucionando falhas durante chamadas, ou projetando interconexões multi-vendor, essa fluência é a base sobre a qual todo o resto se constrói.