SIP (Session Initiation Protocol)

SIP (Session Initiation Protocol)

Definição

SIP é o protocolo de sinalização que governa como sessões de comunicação multimídia — chamadas de voz, vídeo, mensagens — são criadas, modificadas e encerradas em redes IP. Publicado originalmente pela IETF em 1999 e definido hoje pela RFC 3261, SIP é intencionalmente modular: ele cuida apenas da sinalização, delegando o transporte de mídia ao RTP e a negociação de formatos de mídia ao SDP (Session Description Protocol). Essa separação de responsabilidades é o princípio que estrutura qualquer arquitetura de telefonia VoIP.

A analogia mais precisa é HTTP: SIP usa texto simples, segue o modelo requisição/resposta com códigos de status similares (100–699), e é stateless por natureza. Quem mantém estado é o proxy ou o softswitch à frente — o protocolo em si não carrega sessão entre transações. Isso tem implicações práticas diretas: problemas de estado em produção (chamadas que não desligam, troncos que travam) geralmente não são falhas do protocolo SIP, mas de quem gerencia esse estado acima dele.

Por que ainda importa em 2025

Toda abstração em cloud — Twilio, Telnyx, Amazon Chime, a própria integração AudioSocket do Asterisk com LLMs — senta sobre SIP ou sobre alguma camada que termina em SIP em algum ponto. Quando o voicebot não atende, quando o áudio chega de um lado só, quando a chamada cai depois de 32 segundos: o diagnóstico começa nos logs SIP. Engenheiro que não lê um SIP/2.0 488 Not Acceptable Here no ngrep vai escalar para o fornecedor e esperar dias. O que pode ser resolvido em 10 minutos.

Além disso, integrar Asterisk com modelos de linguagem via AudioSocket ou ARI ExternalMedia ainda exige que o canal SIP esteja configurado corretamente antes do áudio chegar ao LLM. Aplicando a lente de latência OWD: o jitter buffer e o processamento de codec acontecem no canal SIP/RTP — se esse trecho está mal configurado, você adiciona latência mesmo antes da requisição ao modelo. Não existe engenharia de voice AI sem entender o transporte.

Mensagens e cabeçalhos fundamentais

SIP define um conjunto de métodos (requests) e respostas numéricas. Os principais para operação de call center:

Métodos:

  • INVITE — inicia uma sessão. Carrega SDP no corpo com os parâmetros de mídia (codec, IP, porta RTP).
  • ACK — confirma recebimento de resposta final a um INVITE. Completação do three-way handshake de estabelecimento de chamada.
  • BYE — encerra uma sessão estabelecida. Pode partir de qualquer lado da chamada.
  • REGISTER — registra a localização atual de um UA (User Agent) num registrar. Base de como o PBX sabe onde o ramal 4201 está fisicamente.
  • OPTIONS — consulta capacidades de um peer SIP, ou serve como keep-alive de tronco. Tronco que não responde 200 OK a OPTIONS está fora antes da primeira chamada tentar.
  • CANCEL — cancela um INVITE ainda em andamento, antes da resposta final.
  • UPDATE / re-INVITE — renegocia parâmetros de uma sessão em curso. Usado em transferências de chamada e hold.

Cabeçalhos fundamentais da RFC 3261:

  • From — URI e display name do originador. Pode ter tag= que identifica o dialog.
  • To — URI do destino. Ganha tag= após estabelecimento da sessão.
  • Via — registra o caminho percorrido pelo request. Cada proxy insere seu Via, que é usado para roteamento das respostas. Múltiplos Via indicam múltiplos hops.
  • Contact — URI direta para o UA — onde respostas subsequentes e requests in-dialog devem ir. Esse cabeçalho é a fonte clássica do problema de NAT.
  • CSeq — sequence number da transação. Incrementado a cada novo request no dialog.
  • Call-ID — identificador único do dialog. Essencial para correlacionar logs entre sistemas diferentes.

Fluxo de uma chamada: SIP + SDP + RTP separados

Entender que SIP não carrega áudio é central. O fluxo simplificado de um INVITE básico:

UA A (192.168.1.10)          Proxy/PBX          UA B (192.168.1.20)
       |                         |                        |
       |--- INVITE (SDP offer) ->|                        |
       |                         |--- INVITE (SDP offer)->|
       |                         |<-- 180 Ringing --------|
       |<-- 180 Ringing ---------|                        |
       |                         |<-- 200 OK (SDP answer)-|
       |<-- 200 OK (SDP answer) -|                        |
       |--- ACK ---------------->|                        |
       |                         |--- ACK --------------->|
       |                                                   |
       |<=========== RTP (áudio direto, peer-to-peer) ====>|
       |                                                   |
       |--- BYE ---------------->|                        |
       |                         |--- BYE --------------->|
       |                         |<-- 200 OK -------------|
       |<-- 200 OK --------------|                        |

Trade-offs de produção

chan_sip vs. chan_pjsip

chan_sip é o driver legado, deprecated oficialmente no Asterisk 21. chan_pjsip (baseado na biblioteca pjproject) é o driver atual — suporta múltiplos registros por endpoint, transporte TLS nativo, melhor handling de re-INVITE e UPDATE, e é a única opção com suporte ativo.

SIP sobre UDP vs. TCP vs. TLS

UDP é o transporte padrão do SIP e do mercado de trunking: baixa overhead, sem handshake, retransmissão gerenciada pelo próprio SIP via Timer A/B/D. TLS sobre TCP é obrigatório em qualquer instalação onde o tronco SIP atravessa internet pública, especialmente com voicebots que trafegam dados de clientes (LGPD, Art. 46).

NAT e SIP: o problema clássico

O Contact header de um UA atrás de NAT reporta o IP privado. Soluções em ordem de preferência para call center:

  1. SBC na borda: faz NAT traversal transparente. É a arquitetura certa para produção.
  2. STUN: o UA descobre seu IP público antes de montar o Contact. Frágil em redes corporativas com NAT simétrico.
  3. nat=yes / force_rport no Asterisk: solução de emergência, não de produção.
  4. TURN: relay de mídia quando STUN falha. Adiciona latência (30–80ms dependendo de localização).

Exemplo prático: diagnóstico de one-way audio com sngrep

# Instalar no Debian/Ubuntu
apt install sngrep

# Capturar tráfego SIP na interface eth0, filtrar por número
sngrep -I eth0 -f "host 203.0.113.10" port 5060

# Salvar captura para análise offline
sngrep -O captura-problema.pcap -I eth0 port 5060

Termos relacionados

  • SIP Trunk — conexão SIP com operadora de telefonia para chamadas PSTN
  • RTP — protocolo de transporte de áudio/vídeo que complementa o SIP
  • Asterisk — PBX open source que implementa SIP via chan_pjsip
  • PABX — central telefônica que frequentemente usa SIP como protocolo de ramais

Fontes primárias