Entendendo os cabeçalhos SIP: uma referência completa
Os cabeçalhos SIP carregam cada peça de metadados que uma sessão de voz ou vídeo precisa. De onde a chamada veio, para onde deve ir, quais codecs estão sendo oferecidos no corpo SDP, quem afirma estar ligando, se o tronco foi autenticado, por quanto tempo a sessão é válida. O protocolo de sinalização entrega tudo isso como uma pilha de campos nomeados dentro de cada mensagem SIP, e o valor em cada campo controla um comportamento específico no próximo salto. Ler e interpretar esses campos é a diferença entre uma interconexão funcional e uma tarde inteira analisando traces.
Esta página é a referência campo a campo. Ela agrupa os cabeçalhos que você encontrará em categorias práticas, mostra a sintaxe de cada um e explica o que ele realmente faz no fio. Se você quer a visão conceitual de como o SIP funciona no nível de protocolo, o artigo complementar Fundamentos de Sinalização SIP cobre papéis e arquitetura; Fluxo de Chamada SIP Explicado Passo a Passo percorre cada mensagem em uma chamada típica, em ordem. Esta página é a que você consulta quando já conhece o fluxo e precisa conhecer os campos.
Field-Name: field-value. Cada cabeçalho carrega uma peça discreta de informação de roteamento, identidade, conteúdo ou capacidade.sip:user@domain ou sips:user@domain (protegido por TLS). A maioria dos cabeçalhos de endereçamento carrega um SIP URI entre colchetes angulares, frequentemente com parâmetros.f para From, t para To, v para Via).A anatomia de uma mensagem SIP
Toda mensagem SIP tem três partes: uma linha inicial, um bloco de campos de cabeçalho e um corpo opcional separado dos cabeçalhos por uma única linha em branco. A linha inicial é uma linha de requisição (por exemplo, INVITE sip:[email protected] SIP/2.0) ou uma linha de status (por exemplo, SIP/2.0 200 OK). O bloco de cabeçalhos é uma sequência de linhas Field-Name: field-value, uma por cabeçalho lógico. O corpo, quando presente, é descrito pelos cabeçalhos de conteúdo (mais comumente SDP para negociação de mídia).
Algumas regras mecânicas se aplicam a todo o bloco de cabeçalhos. Nomes de campos não diferenciam maiúsculas de minúsculas: From, FROM e from são o mesmo cabeçalho. Muitos cabeçalhos também possuem uma forma compacta de uma única letra para uso em transportes com restrição de espaço; f equivale a From, t equivale a To, v equivale a Via, m equivale a Contact, i equivale a Call-ID, l equivale a Content-Length e c equivale a Content-Type. Valores de cabeçalho podem se estender por várias linhas começando a continuação com espaço em branco, e múltiplos valores para o mesmo cabeçalho podem ser enviados como um único cabeçalho com valor separado por vírgulas ou como vários cabeçalhos separados com o mesmo nome.
A ordem dos cabeçalhos geralmente não afeta o comportamento do protocolo. A ordem dos parâmetros dentro de um único valor de cabeçalho às vezes importa, particularmente em Via, Route e Record-Route. Muitos endpoints e intermediários assumem uma ordenação típica de cabeçalhos ao analisar, então uma implementação defensiva tolera qualquer ordem, mas produz uma familiar.
Cabeçalhos de diálogo e endereçamento
Esses cabeçalhos identificam quem está envolvido na chamada, identificam o próprio diálogo e informam a cada parte para onde enviar mensagens subsequentes.
From identifica o originador lógico da requisição. O valor é um nome de exibição mais um SIP URI entre colchetes angulares, com um parâmetro tag obrigatório que identifica exclusivamente esta ponta do diálogo: From: "Alice" <sip:[email protected]>;tag=1928301774. O From-tag permanece constante para toda requisição e resposta no diálogo. Note que From não é necessariamente o chamador real; em muitas topologias corporativas e de operadoras, ele é reescrito ou atestado separadamente através do P-Asserted-Identity (abordado abaixo).
To nomeia o destinatário lógico da requisição e segue a mesma sintaxe do From: To: "Bob" <sip:[email protected]>. O lado originador envia a requisição sem tag; o destinatário adiciona um To-tag na primeira resposta diferente de 100 e, a partir desse ponto, o To-tag passa a fazer parte do identificador do diálogo. O Request-URI na linha inicial pode diferir do URI do To conforme a requisição é roteada.
Call-ID é uma string globalmente única que, combinada com o From-tag e o To-tag, identifica um único diálogo SIP em todas as mensagens que ele produz: Call-ID: [email protected]. É gerado pelo endpoint originador e nunca muda durante a vida do diálogo. Um B2BUA produz dois Call-IDs separados, um por perna, porque opera dois diálogos independentes.
Contact informa ao outro lado para onde enviar futuras requisições dentro do diálogo para esta sessão: Contact: <sip:[email protected]:5060>. O valor normalmente é o endereço de transporte real do endpoint, não um nome de domínio, porque o roteamento precisa alcançar uma instância específica após a configuração inicial. Os Controladores de Borda de Sessão (SBCs) frequentemente reescrevem o Contact durante a ocultação de topologia, substituindo o endereço interno pelo endereço público do próprio SBC.
Reply-To indica um endereço alternativo que deve ser usado para qualquer resposta que o chamador queira direcionar a um lugar diferente do URI do From. É raro na prática e amplamente informativo.
Cabeçalhos de roteamento
Os cabeçalhos de roteamento ditam o caminho explícito que uma requisição deve percorrer pela rede e garantem que as respostas possam retroceder com precisão pelo mesmo caminho.
Via registra cada salto que uma requisição percorreu. Cada proxy adiciona um cabeçalho Via antes de encaminhar a requisição. Um B2BUA gera uma nova requisição com sua própria cadeia Via independente na perna de saída. As respostas percorrem os Vias em ordem reversa para alcançar o originador. Um Via típico se parece com Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds. O parâmetro branch é o identificador da transação; valores que começam com z9hG4bK são compatíveis com o RFC 3261. Múltiplos cabeçalhos Via aparecem empilhados quando vários intermediários estão no caminho.
Max-Forwards limita quantos saltos uma requisição pode dar antes de ser rejeitada: Max-Forwards: 70. Cada proxy decrementa o valor em um e descarta a requisição quando ele chega a zero, retornando 483 Too Many Hops.
Route carrega uma lista explícita de intermediários pelos quais uma requisição deve transitar. O endpoint originador escreve um cabeçalho Route para cada salto que foi instruido a usar, e cada salto remove sua própria entrada do topo antes de encaminhar. É assim que o roteamento solto (loose routing) funciona na prática e como os SBCs direcionam tráfego que, de outra forma, seria livre para escolher seu próprio caminho.
Record-Route funciona na direção oposta: um proxy ou B2BUA que deseja que requisições subsequentes dentro do diálogo percorram o mesmo caminho se insere no Record-Route da requisição inicial. Cada endpoint então copia a lista Record-Route para cabeçalhos Route nas requisições subsequentes, ancorando o diálogo a esse caminho. Record-Route é essencial para qualquer intermediário que precise permanecer na sinalização para contabilização, ancoragem de mídia ou aplicação de políticas após o estabelecimento da chamada.
Cabeçalhos de transação e sequência
O SIP sobrepõe um modelo de transação sobre transportes não confiáveis, e um pequeno conjunto de cabeçalhos e parâmetros mantém requisições e respostas corretamente associadas.
CSeq carrega um número de sequência mais um nome de método: CSeq: 314159 INVITE. O número incrementa em um para cada nova requisição que o originador envia dentro do diálogo, e o método corresponde à requisição sendo enviada (ou à requisição original, no caso do ACK, que mantém o número CSeq do INVITE mas altera o método). CSeq é como um endpoint respondente associa um 200 OK ao INVITE correto quando vários estão em andamento, e como ele sabe que um re-INVITE é uma nova requisição e não uma retransmissão de uma antiga.
O parâmetro tag em From e To identifica exclusivamente uma ponta de um diálogo. O From-tag é gerado pelo originador no momento do INVITE; o To-tag é gerado pelo destinatário na primeira resposta diferente de 100. As duas tags mais o Call-ID juntos formam o identificador do diálogo; qualquer requisição que carregue esses três valores é tratada como pertencente ao diálogo.
O parâmetro branch no Via identifica uma única transação. Cada requisição recebe um valor de branch novo, e a resposta correspondente copia o branch de volta para que o originador possa associá-la.
Cabeçalhos de conteúdo
Quando uma mensagem SIP carrega um corpo, os cabeçalhos de conteúdo o descrevem. O corpo em si é mais frequentemente SDP para negociação de mídia, mas o SIP pode carregar qualquer tipo MIME, incluindo text/plain, application/pidf+xml para presença, multipart/mixed para vários corpos em uma mensagem, e image/jpeg ou message/sipfrag para usos menos comuns.
Content-Type declara o tipo MIME do corpo: Content-Type: application/sdp. Para corpos multipart, o tipo também nomeia um parâmetro boundary que separa as partes.
Content-Length informa o tamanho do corpo em octetos: Content-Length: 142. Um Content-Length incorreto sobre um transporte de fluxo quebra o enquadramento da mensagem.
Content-Disposition indica ao destinatário como tratar o corpo. Valores como session (o corpo descreve a sessão, o padrão para SDP), render (exibir isso ao usuário) e signal (um corpo que afeta a sinalização, como um URI referenciado) ajudam os endpoints a direcionar conteúdos multipart ao subsistema correto.
Content-Encoding descreve qualquer codificação (compressão, tipicamente gzip) aplicada ao corpo. O destinatário reverte a codificação antes de analisar.
Accept anuncia quais tipos de corpo o remetente aceitará em uma resposta. Accept-Encoding e Accept-Language desempenham os papéis de negociação correspondentes. Esses cabeçalhos são mais relevantes para descoberta de capacidades via OPTIONS.
Cabeçalhos de capacidade
Os cabeçalhos de capacidade permitem que cada lado descreva o que pode fazer e o que exige que o outro lado faça. Eles são o mecanismo pelo qual as extensões SIP permanecem retrocompatíveis.
Allow lista os métodos SIP que o remetente suporta: Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, NOTIFY, UPDATE. Publicado em respostas OPTIONS, respostas 405 e no 200 OK que estabelece um diálogo.
Supported anuncia extensões SIP opcionais que o remetente entende por nome (por exemplo, timer, 100rel, replaces), permitindo que dispositivos a jusante ativem dinamicamente esses recursos para a sessão.
Require vai além e exige que o destinatário entenda uma extensão nomeada. Se o destinatário não a suporta, responde com 420 Bad Extension e lista as opções não reconhecidas em Unsupported.
Unsupported aparece apenas em respostas 420 e lista as extensões nomeadas em Require que o destinatário não pode atender.
User-Agent identifica o software ou dispositivo de origem. Server desempenha o mesmo papel nas respostas. Ambos são informativos.
Cabeçalhos de identidade e privacidade do chamador
A identidade no SIP é organizada em camadas. O cabeçalho From é o que o chamador diz; os cabeçalhos nesta seção são o que os intermediários atestam sobre o chamador, quem tem permissão para ver essa informação e que tratamento histórico ocorreu ao longo do caminho. Esses campos controlam a exibição do identificador de chamadas, o comportamento de interconexão entre operadoras e a atestação STIR/SHAKEN, e são os alvos mais comuns de manipulação de cabeçalhos SIP na borda do SBC.
P-Asserted-Identity (PAI) transmite a identidade da parte chamadora conforme atestada por um intermediário confiável, tipicamente a operadora de origem: P-Asserted-Identity: <sip:[email protected]>. Muitos PBXs receptores leem o identificador de chamadas a partir do PAI em vez do From quando ambos estão presentes.
P-Preferred-Identity (PPI) é o lado de requisição da mesma relação. Um endpoint que possui várias identidades válidas envia PPI para indicar qual delas deseja que a rede ateste.
Privacy solicita a ocultação de informações de identidade. Valores comuns são id (remover PAI de mensagens que deixam o domínio de confiança), header (remover cabeçalhos que revelam a identidade do usuário) e none.
Diversion registra que a chamada foi redirecionada, nomeando o destino original e o motivo: Diversion: <sip:[email protected]>;reason=no-answer.
History-Info serve ao mesmo propósito que Diversion, mas é a substituição padronizada (standards-track), com tratamento estruturado de cadeias de redirecionamento em múltiplas etapas. Ambos coexistem em redes de produção atualmente.
Remote-Party-ID é anterior ao PAI e carregava tanto informação de identidade quanto de privacidade em um único cabeçalho. Ainda é encontrado em implantações legadas; interconexões modernas esperam PAI mais Privacy.
Cabeçalhos de autenticação
A autenticação SIP utiliza HTTP Digest, com um par de cabeçalhos para desafios de endpoint e um par paralelo para desafios de proxy.
WWW-Authenticate aparece em uma resposta 401 Unauthorized e desafia o solicitante a se autenticar. Carrega um realm, nonce e algoritmo.
Authorization carrega a resposta na requisição reenviada. O endpoint calcula um hash digest a partir do nonce, do URI da requisição, do método e de seu segredo compartilhado.
Proxy-Authenticate e Proxy-Authorization funcionam de forma idêntica, mas são usados quando um proxy SIP emite o desafio com 407 Proxy Authentication Required.
Cabeçalhos de temporizador de sessão, assinatura e notificação
Esses cabeçalhos governam por quanto tempo uma sessão ou assinatura é válida e o que cada lado faz conforme a expiração se aproxima.
Session-Expires define o tempo de vida máximo de uma sessão estabelecida: Session-Expires: 1800;refresher=uac. O parâmetro refresher indica qual lado enviará a atualização.
Min-SE declara o intervalo mínimo de sessão aceitável. Um destinatário que recebe Session-Expires menor que seu próprio Min-SE rejeita com 422 Session Interval Too Small.
Expires aparece em REGISTER, SUBSCRIBE e ocasionalmente em INVITE. Os valores são inteiros em segundos.
Event nomeia o pacote de evento em SUBSCRIBE e NOTIFY (presence, message-summary, refer).
Subscription-State acompanha todo NOTIFY e descreve o estado da assinatura: active, pending ou terminated com um motivo.
Cabeçalhos de transferência e referência
A transferência de chamada no SIP é implementada através do método REFER, que utiliza um pequeno conjunto de cabeçalhos para nomear o alvo e reportar o progresso.
Refer-To nomeia o alvo de uma transferência em uma requisição REFER: Refer-To: <sip:[email protected]>. Para transferência assistida, o URI carrega um parâmetro Replaces.
Referred-By registra a parte que iniciou a transferência.
Replaces é incorporado como um parâmetro de URI escapado dentro da string de destino do Refer-To e é subsequentemente elevado a seu próprio cabeçalho independente no INVITE de saída resultante para sinalizar a substituição de um diálogo existente.
Reason carrega um motivo de status em BYE ou CANCEL, tipicamente um código de causa Q.850 ou um status SIP, explicando por que o diálogo está terminando.
O cabeçalho Identity (STIR/SHAKEN)
Identity é o cabeçalho que carrega o PASSporT assinado na autenticação de chamadas STIR/SHAKEN. O valor é um objeto PASSporT serializado como uma JSON Web Signature (JWS) mais parâmetros que nomeiam a URL do certificado e o nível de atestação que o provedor de origem reivindica: Identity: eyJhbGciOi...<signature>;info=<https://...cer>;alg=ES256;ppt=shaken.
O cabeçalho Identity é grande pelos padrões SIP (frequentemente 1 a 2 KB) e é uma das principais razões pelas quais interconexões modernas precisam de transportes que suportem mensagens SIP acima do limite típico de fragmentação UDP. TCP ou TLS é preferível para qualquer tronco que assine ou verifique.
Cabeçalhos personalizados, de fornecedor e P-Headers
O SIP permite que qualquer parte introduza seus próprios cabeçalhos, e na prática quase todos os fornecedores o fazem. Duas convenções de nomenclatura cobrem a maioria dessas extensões.
P-headers usam o prefixo P- e são destinados para uso dentro de uma rede privada ou entre redes cooperantes sob acordo explícito. Vários são padronizados (P-Asserted-Identity, P-Preferred-Identity, P-Charging-Vector, P-Access-Network-Info).
X-headers carregam o prefixo X- e sinalizam uma extensão de fornecedor ou aplicação não padronizada. Embora os X-headers permaneçam comuns em equipamentos legados, o IETF oficialmente descontinuou a convenção do prefixo X- no RFC 6648; implementações modernas registram novos cabeçalhos diretamente com nomes descritivos (por exemplo, Company-Header em vez de X-Company-Header). Qualquer sistema que não entenda um determinado cabeçalho personalizado simplesmente o ignora.
A regra prática para ambas as categorias é que cabeçalhos personalizados devem ser removidos antes que uma chamada deixe o ambiente controlado.
Como os SBCs tratam os cabeçalhos SIP
Um Controlador de Borda de Sessão em modo B2BUA opera dois diálogos SIP unidos por lógica de roteamento interna, o que significa que os cabeçalhos na perna de entrada não são os mesmos cabeçalhos na perna de saída. Cada perna tem seu próprio Call-ID, sua própria cadeia Via, seu próprio Contact e seu próprio contador CSeq. O SBC reconstrói cada cabeçalho na perna de saída a partir de política: o que o sistema upstream precisa ver, independentemente do que chegou no lado de entrada.
Esta é a base da normalização SIP. Uma operadora que entrega a identidade do chamador em P-Asserted-Identity pode ser conectada a um PBX que lê From; o SBC lê PAI na perna de entrada e reescreve From na perna de saída. O panorama completo desses tratamentos é abordado em Manipulação de Cabeçalhos SIP com um SBC.
Perguntas frequentes
Os nomes dos campos de cabeçalho SIP diferenciam maiúsculas de minúsculas?
Não. Os nomes dos campos não diferenciam maiúsculas de minúsculas, então From, FROM e from se referem ao mesmo cabeçalho. Os valores dos campos, no entanto, podem diferenciar maiúsculas de minúsculas dependendo do cabeçalho específico (por exemplo, nomes de esquema como sip: não diferenciam, mas a parte de usuário de um URI tipicamente diferencia).
Quando devo usar a forma compacta dos nomes de cabeçalho?
As formas compactas (f para From, t para To, v para Via, entre outras) existem para reduzir o tamanho da mensagem sobre UDP, onde manter-se abaixo do MTU evita fragmentação. Implantações modernas usando TCP ou TLS raramente precisam delas, e a forma longa é mais legível em traces. Ambas são corretas e aceitas em toda parte; apenas não misture formas desnecessariamente na mesma mensagem.
Por que alguns traces SIP mostram múltiplos cabeçalhos Via empilhados?
Cada proxy SIP adiciona um cabeçalho Via antes de encaminhar a requisição. B2BUAs geram suas próprias cadeias Via nas requisições de saída.
Qual é a diferença entre um P-header e um X-header?
P-headers são destinados para uso privado entre redes cooperantes sob acordo explícito, e vários deles (P-Asserted-Identity, P-Preferred-Identity, P-Charging-Vector) são padronizados. X-headers são extensões de fornecedor ou aplicação sem significado padronizado; qualquer sistema que não os entenda os ignora. A orientação prática é a mesma para ambos: remova-os no limite de confiança, a menos que o próximo domínio tenha concordado em consumi-los.
Se um cabeçalho é exigido por uma extensão que meu sistema não entende, o que acontece?
Um cabeçalho Require que nomeia uma extensão não suportada pelo destinatário aciona uma resposta 420 Bad Extension, com as opções não suportadas listadas em um cabeçalho Unsupported. O originador pode então tentar novamente sem a extensão problemática, ou recorrer a um caminho diferente. Supported, por outro lado, é informativo e nunca causa uma falha.
Conclusão
Os cabeçalhos SIP são a camada de metadados que faz tudo na sinalização de voz funcionar. Roteamento, identidade, negociação de capacidades, autenticação, ciclo de vida da sessão, transferência e STIR/SHAKEN vivem como campos nomeados dentro de mensagens cuja estrutura é simples. Fluência nesses campos é o que transforma um trace SIP de uma parede ilegível de texto em uma sequência de decisões que você pode acompanhar e analisar, e é a base de toda correção de interoperabilidade, toda regra de normalização e toda integração com operadoras.
A mecânica conceitual está em Fundamentos de Sinalização SIP; o passo a passo por mensagem está em Fluxo de Chamada SIP Explicado Passo a Passo; e o motor baseado em regras que reescreve cabeçalhos em produção está em Manipulação de Cabeçalhos SIP com um SBC.
Como o ProSBC trata cada cabeçalho desta referência
O ProSBC é um verdadeiro B2BUA, o que significa que cada cabeçalho na página acima é algo que ele constrói do zero na perna de saída de cada chamada. From, To, Contact, PAI, Diversion e History-Info de entrada podem ser analisados, reescritos, trocados ou removidos por regras por NAP. O mesmo motor realiza assinatura e verificação STIR/SHAKEN no cabeçalho Identity, ocultação de topologia em Via e Record-Route, e tratamento de Authorization em desafios Digest.
Para interconexões com operadoras, Roteamento Direto do Microsoft Teams e qualquer ambiente multi-fornecedor onde dois endpoints falam dialetos ligeiramente diferentes de SIP, esse controle no nível de cabeçalho é o que transforma “quase interoperável” em “produção”. O ProSBC suporta até 1.024 grupos de troncos por servidor com regras de cabeçalho independentes em cada um.
Prefere avaliar por conta própria primeiro? Inicie seu teste gratuito de 30 dias.