Mensagem SIP INVITE: Estrutura e Cabeçalhos

Toda chamada SIP começa com um INVITE. É a requisição que um agente de usuário chamador envia para iniciar uma sessão, e também é a mensagem que os engenheiros passam mais tempo lendo quando algo dá errado. Um INVITE carrega as identidades do chamador e do chamado, o rastro de roteamento que a chamada percorreu até o momento, os codecs e parâmetros de transporte que o chamador está oferecendo, e uma longa lista de campos opcionais que influenciam tudo, desde a exibição do identificador de chamadas até a atestação STIR/SHAKEN.

Este artigo é uma referência estrutural para o próprio INVITE. Ele percorre as três seções da mensagem, cada cabeçalho obrigatório que um INVITE deve conter, o corpo SDP, e os cabeçalhos opcionais que aparecem com mais frequência em traces de produção. Para uma visão geral mais ampla de como o SIP funciona como protocolo, consulte fundamentos de sinalização SIP.

As Três Seções de um INVITE

A RFC 3261 define uma mensagem SIP como três partes separadas por sequências de retorno de carro/alimentação de linha: uma linha inicial, um conjunto de campos de cabeçalho e um corpo opcional. A linha inicial de um INVITE é a linha de requisição. Os cabeçalhos transportam informações de roteamento, identidade e capacidade. O corpo, se presente, carrega a oferta SDP que descreve a mídia que o chamador deseja negociar.

A linha em branco entre o último cabeçalho e o corpo é estrutural. É assim que um analisador sabe que os cabeçalhos terminaram. A ausência de um CRLF aqui é uma das razões mais comuns pelas quais um INVITE malformado é rejeitado por uma pilha SIP rigorosa antes mesmo de chegar à lógica de roteamento.

A Linha de Requisição

A linha de requisição é uma única linha no formato METHOD Request-URI SIP-Version. Para um INVITE, ela sempre começa com a palavra literal INVITE, seguida do Request-URI, seguida de SIP/2.0.

O método indica à pilha receptora o que fazer. INVITE significa “estabelecer uma sessão.” Outros métodos que compartilham a maior parte da mesma estrutura de cabeçalhos incluem ACK, BYE, CANCEL, OPTIONS, REGISTER, REFER, NOTIFY, SUBSCRIBE, UPDATE, INFO, MESSAGE e PRACK. INVITE é o método SIP mais comum que cria um diálogo. Outros métodos como SUBSCRIBE também podem estabelecer diálogos dependendo da extensão em uso.

O Request-URI indica para onde a requisição está sendo enviada no momento. Este não é necessariamente o destino original. À medida que o INVITE viaja através de proxies e SBCs, o Request-URI pode ser reescrito para que o próximo salto saiba para onde encaminhar. O cabeçalho To representa a identidade de destino lógico da chamada e é normalmente preservado durante o trânsito, mesmo quando o Request-URI é reescrito para fins de roteamento. Confundir o Request-URI com o cabeçalho To é um dos erros mais comuns ao ler um trace; o Request-URI responde “para onde isso está indo agora”, enquanto o cabeçalho To responde “para quem isso foi originalmente destinado.”

A versão do SIP é SIP/2.0 desde que a RFC 3261 foi publicada em 2002. Não existe SIP/3.0 em produção.

Os Cabeçalhos Obrigatórios

A RFC 3261 exige seis cabeçalhos em cada requisição SIP: Via, Max-Forwards, To, From, Call-ID e CSeq. Requisições INVITE quase sempre incluem Contact, porque ele fornece o destino para requisições subsequentes dentro do diálogo, como BYE e re-INVITE. Quando a mensagem carrega um corpo, Content-Type e Content-Length também se tornam obrigatórios.

Via

O cabeçalho Via registra o caminho de rede que a requisição percorreu. Cada salto que encaminha um INVITE adiciona um novo Via no topo. As respostas seguem a cadeia Via em ordem reversa para retornar ao remetente. O parâmetro branch dentro de cada Via identifica exclusivamente aquela transação naquele salto. A RFC 3261 determina que os valores de branch comecem com o cookie mágico z9hG4bK.

Exemplo: Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9

Max-Forwards

Um contador de saltos que previne loops de roteamento. Definido como 70 por padrão; decrementado a cada salto; rejeitado com 483 Too Many Hops quando chega a zero.

To

O destino lógico da chamada, expresso como uma URI. Não é alterado em trânsito. O Servidor de Agente de Usuário (UAS) que atende adiciona um To-tag na resposta 200 OK, e essa tag vincula o diálogo no lado do chamado.

From

A identidade declarada do chamador. Sempre carrega uma tag definida pelo UA chamador. A URI do From é o que o chamador afirma ser, que não é o mesmo que o provedor upstream autenticou (isso é P-Asserted-Identity).

Call-ID

Um identificador globalmente único para todo o diálogo. Cada requisição e resposta dentro do diálogo carrega o mesmo Call-ID.

CSeq

Sequência de Comando: um número seguido do nome de um método (ex.: CSeq: 314159 INVITE). Incrementa a cada nova requisição dentro de um diálogo; reutilizado para retransmissões.

Contact

Destino de roteamento direto para requisições dentro do diálogo, como BYE e re-INVITE, tipicamente usado junto com qualquer conjunto de Route estabelecido por Record-Route. Quase sempre contém o IP e porta reais do endpoint, razão pela qual a ocultação de topologia em um SBC quase sempre envolve reescrever o Contact.

Content-Type e Content-Length

Quando o INVITE carrega um corpo, ambos são obrigatórios. Content-Type é quase sempre application/sdp; Content-Length é o tamanho do corpo em bytes.

Um INVITE Completo na Prática

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
To: "Bob" <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
P-Asserted-Identity: <sip:[email protected]>
Identity: eyJhbGciOiJFUzI1NiI...JSON-WEB-SIGNATURE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 156

v=0
o=alice 2890844526 2890844526 IN IP4 198.51.100.10
s=SIP Call
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

A linha de requisição está na primeira linha, os cabeçalhos obrigatórios e opcionais seguem, a linha em branco marca o fim do bloco de cabeçalhos, e a oferta SDP preenche o corpo. Os valores são ilustrativos; INVITEs reais variam na ordem dos campos e no conjunto exato de cabeçalhos opcionais, mas todo INVITE em conformidade carrega os mesmos campos obrigatórios e a mesma estrutura de três seções.

O Corpo SDP

O corpo é quase sempre uma oferta do Protocolo de Descrição de Sessão (SDP) (RFC 8866, que tornou obsoleta a RFC 4566 em 2021). Linhas principais:

• v= versão do protocolo (sempre 0)
• o= origem: ID da sessão + endereço do originador
• s= nome da sessão
• c= conexão: IP onde o originador espera receber mídia
• t= tempo (quase sempre 0 0 para SIP em tempo real)
• m= linha de mídia: tipo, porta, transporte, lista de payload-type
• a= atributos: rtpmap, fmtp, sendrecv/sendonly/recvonly/inactive, crypto (SDES), fingerprint (DTLS-SRTP)

O SDP segue o modelo de oferta/resposta (RFC 3264). O INVITE carrega a oferta; o 200 OK carrega a resposta. Uma implantação usando SRTP com chaveamento SDES deve proteger o caminho de sinalização com TLS, caso contrário as chaves mestras cruzam a rede em texto claro dentro da linha a=crypto.

Cabeçalhos Opcionais Importantes em um INVITE

O INVITE carrega mais cabeçalhos opcionais do que qualquer outra mensagem SIP porque está estabelecendo o diálogo, negociando capacidades e afirmando identidade, tudo ao mesmo tempo. A referência completa de cabeçalhos SIP cobre cada cabeçalho campo por campo; aqui focamos nos que afetam especificamente o processamento do INVITE.

Negociação de capacidades: Allow enumera os métodos que o UA suporta, Supported lista as extensões que ele entende, e Require lista as extensões que o lado remoto deve suportar ou o INVITE falha (comumente timer, 100rel, replaces). Estes três cabeçalhos determinam se o diálogo pode ser estabelecido.

Caminho de roteamento: Route pré-define os saltos que o INVITE percorre; Record-Route marca os intermediários que desejam permanecer no diálogo para requisições subsequentes. Um SBC B2BUA remove ambos e reorigina o roteamento no trecho de saída.

Identidade do chamador: P-Asserted-Identity (RFC 3325) carrega o identificador do chamador atestado pela operadora, P-Preferred-Identity é o que o UA solicita. O cabeçalho Identity do STIR/SHAKEN (RFC 8224) adiciona um PASSporT assinado vinculando o número do chamador a uma identidade criptográfica. Privacy (RFC 3323) controla o que é ocultado a jusante.

Histórico de encaminhamento de chamadas: Diversion e History-Info (RFC 4244) carregam o histórico de redirecionamento quando uma chamada foi encaminhada. Dois padrões concorrentes; os fornecedores preferem formatos diferentes, e o SBC frequentemente normaliza entre eles.

Ciclo de vida da sessão: Session-Expires e Min-SE (RFC 4028) definem o intervalo de atualização que previne sessões fantasma semi-fechadas. User-Agent identifica o software chamador, útil para correlação de traces.

Do INVITE ao Diálogo

Um INVITE que chega ao destino dispara uma sequência de respostas: 100 Trying imediatamente, depois uma ou mais respostas provisórias 18x (180 Ringing, 183 Session Progress), depois 200 OK com o To-tag definido quando o chamado atende. O chamador confirma com ACK, e o diálogo está totalmente confirmado.

Re-INVITEs dentro de um diálogo existente reutilizam o mesmo Call-ID, To-tag e From-tag com um CSeq mais alto, modificando a sessão (mudança de codec, espera, transferência). Os códigos de resposta provisórios, de sucesso e de falha que completam a transação INVITE seguem o mesmo padrão 1xx a 6xx usado em todo o restante do SIP.

Onde os SBCs Modificam o INVITE

Um Controlador de Borda de Sessão (SBC) B2BUA termina o INVITE de entrada e constrói um novo INVITE de saída no outro trecho. Cada cabeçalho na mensagem de saída é construído do zero, o que significa que um SBC pode remover campos proprietários, reescrever cabeçalhos de identidade, normalizar Diversion para History-Info (ou vice-versa), injetar o cabeçalho Identity do STIR/SHAKEN de um serviço de assinatura externo, e reescrever Contact e Via para ocultar a topologia interna do originador. A mecânica dessas reescritas é coberta em manipulação de cabeçalhos SIP; a razão arquitetural pela qual um proxy não pode fazer o mesmo é coberta em SIP proxy vs SBC.

Perguntas Frequentes

Por que um INVITE tem tanto From quanto P-Asserted-Identity?

O cabeçalho From carrega a identidade que o chamador afirma ter. PAI carrega a identidade que o provedor upstream está disposto a atestar após autenticar o usuário.

Qual é a diferença entre o Request-URI e o cabeçalho To?

O Request-URI é o endereço para o qual a requisição está atualmente direcionada (muda conforme proxies/SBCs a encaminham). O cabeçalho To é o destino lógico original (não muda em trânsito).

Um INVITE pode não ter corpo?

Sim. Um INVITE com “oferta atrasada” não tem SDP. O chamado responde com sua oferta SDP no 200 OK; o ACK do chamador carrega a resposta. Incomum em implantações de operadoras modernas, mas ainda visto em alguns cenários legados de click-to-call.

Por que o Max-Forwards é inicializado em 70?

Convenção da RFC 3261. Alto o suficiente para percorrer qualquer caminho SIP realista, baixo o suficiente para que loops sejam detectados e interrompidos rapidamente.

Para que serve o parâmetro branch no cabeçalho Via?

Identifica uma única transação SIP em um único salto. Cada salto insere um novo branch ao encaminhar. Branches SIP/2.0 em conformidade devem começar com z9hG4bK.