Protocolo SIP: o guia técnico direto ao ponto

O SIP tem fama de complicado por um motivo injusto: a maioria dos textos sobre ele ou fica na analogia rasa ou mergulha na RFC 3261 inteira. Este guia fica no meio útil — o que você precisa dominar para operar um tronco em produção e ler um trace sem pânico: métodos, respostas, a divisão SIP/SDP/RTP e os pontos exatos onde as coisas quebram.

A anatomia de uma chamada SIP

Uma chamada bem-sucedida é um diálogo curto e formal:

Grave essa sequência: 90% da leitura de trace é procurar qual passo não aconteceu. INVITE sem 100? Sinalização não chega. 200 OK sem ACK? Resposta não volta (quase sempre NAT). Chamada cai aos 30 segundos exatos? ACK perdido — o destino desliga por timeout de confirmação.

Os métodos que você vai encontrar

• REGISTER — apresenta credenciais e diz ao servidor onde você está. É o método por trás do modelo de autenticação por registro;
• INVITE / ACK / BYE — o trio do ciclo de vida da chamada;
• OPTIONS — ping de camada SIP; troncos o usam como keep-alive e teste de vida;
• CANCEL — desiste de um INVITE que ainda não foi atendido;
• re-INVITE — renegocia uma sessão ativa (mudança de codec, hold, transferência de mídia). Vilão frequente: equipamentos que atendem o primeiro INVITE e engasgam no segundo.

Códigos de resposta: os que importam

Como HTTP, o SIP responde em classes — 1xx informativo, 2xx sucesso, 4xx erro do cliente, 5xx do servidor, 6xx global. Na operação diária, meia dúzia resolve o diagnóstico:

SDP e RTP: onde mora o áudio

O SIP não transporta áudio — ele negocia. Dentro do INVITE e do 200 OK viaja o SDP (Session Description Protocol), o "contrato" da mídia: quais codecs cada lado aceita (G.711, G.729, Opus), em qual IP e porta cada um quer receber o RTP — o fluxo UDP que carrega a voz de fato.

Essa separação explica o bug mais famoso da telefonia IP: chamada completa, sem áudio. A sinalização (porta 5060) atravessou a rede; o RTP (faixa dinâmica, tipicamente 10000–20000/UDP) não. As causas quase sempre envolvem NAT reescrevendo — ou deixando de reescrever — os IPs dentro do SDP, tema do nosso guia de NAT e SIP ALG. E a escolha de codec negociada ali define banda e qualidade percebida, assunto do artigo sobre codecs e QoS.

Registro × peer: como o tronco autentica

Troncos SIP autenticam de duas formas: registro (o PABX se apresenta com usuário/senha via REGISTER, funciona de qualquer IP) ou peer por IP fixo (o provedor confia no seu endereço, sem registro). A escolha afeta segurança, failover e comportamento atrás de NAT — o comparativo completo está em registro ou IP fixo.

Nos dois modelos, o transporte da sinalização merece atenção: UDP é o default histórico, TCP evita fragmentação de pacotes grandes (INVITEs com SDP gordo) e TLS na 5061 criptografa a sinalização — que, combinado com SRTP na mídia, fecha o pacote mínimo de segurança do artigo sobre fraude toll.

Onde quebra em produção

A lista honesta, por frequência real de suporte:

1. NAT — áudio mudo, unidirecional, chamada que cai aos 30 s. Sempre o suspeito nº 1;
2. SIP ALG do roteador — "ajuda" reescrevendo pacotes e corrompe a sinalização. Desligue-o, sempre;
3. Codecs incompatíveis — 488 ou áudio de robô: as pontas não têm codec comum de qualidade;
4. Formato de discagem — 404 em massa: o provedor espera E.164 ou 0+DDD e o dialplan manda outra coisa;
5. Fragmentação UDP — INVITE grande que some no caminho: mude a sinalização para TCP.

Repare que nenhum dos cinco é "o SIP é complicado" — são detalhes de borda entre o protocolo e a sua rede. Quem domina a anatomia da chamada e sabe ler um trace resolve qualquer um deles antes do café esfriar. E se o seu caso é consumir voz sem operar tronco nenhum — disparar chamadas de um sistema, por exemplo —, a camada acima do SIP já vem pronta em plataformas com API de voz: o protocolo continua lá embaixo, mas vira problema de outra pessoa.