Identity header no SIP: o que muda para engenheiros de voz após o Despacho 82/2026
O Despacho Decisório Anatel nº 82/2026, publicado em 17 de agosto de 2026, estabelece parâmetros para identificação e mitigação de chamadas massivas, com vigência imediata. Na prática, sua operação precisa inserir o SIP Identity header em todas as chamadas que cruzam o SBC, sob pena de bloqueio na interconexão. Para engenheiros de voz, o Identity header é o mecanismo técnico para autenticar a origem; a conformidade exige implementação correta no SIP/SBC, observando critérios de proporcionalidade e transparência. Sem ele, operadoras destinatárias podem classificar seu tráfego como suspeito e derrubar taxas de completamento.
O custo de não agir aparece rápido: chamadas legítimas de cobrança, confirmação de agendamento ou alerta de fraude passam a ser etiquetadas como spam. A distinção entre camadas é essencial — filtro anti-spam e autenticação de chamadas operam em níveis diferentes, e confundi-los atrasa sua adequação. CTOs, gestores de telecom, integradores, provedores SIP e equipes técnicas de contact center devem avaliar se o SBC suporta assinatura PASSporT e se a operadora de interconexão já validou o formato exigido pela Anatel. A ausência de autenticação gera risco regulatório direto, queda de completamento e bloqueio de chamadas legítimas. STIR/SHAKEN autentica a origem; RCD e Origem Verificada adicionam nome e logotipo — nenhum deles é filtro antispam. Consulte o Despacho Decisório nº 82/2026 e a página de autenticação e identificação de chamadas da Anatel para validar os próximos passos de interconexão.
Como avaliar se sua rede SIP está pronta para o Identity header?
| Perfil de operação | Sinal de alerta | Requisito técnico | Ação recomendada |
|---|---|---|---|
| Operadora com interconexão SIP | Queda de completamento em rotas de destino; chamadas legítimas bloqueadas por filtros | SBC com suporte nativo a STIR/SHAKEN, certificados de assinatura e validação no INVITE | Ativar assinatura no SBC de borda e monitorar completamento antes e depois da mudança |
| Provedor SIP revendendo troncos | Clientes reportando bloqueio de chamadas legítimas; falta de autenticação na origem | SBC com logging do Identity header; suporte a RCD (Rich Call Data) e Origem Verificada | Extrair e registrar o Identity header; testar chamadas com operadoras que validam assinatura |
| Contact center com discagem ativa | Número de origem reprovado; baixa taxa de atendimento; chamadas caindo em spam | Autenticação do número principal; ajuste de pacing; monitoramento de bloqueios por operadora | Autenticar o número mestre e reduzir picos de discagem que disparam filtros anti-spam |
| Empresa com PABX virtual | Chamadas saindo sem identidade verificada; risco de inadequação regulatória | SIP trunk via operadora que assina chamadas; SBC ou roteador SIP compatível | Contratar operadora com autenticação ativa e testar chamadas para móvel e fixo |
A prontidão para o Identity header depende de dois fatores: o SBC precisa processar o cabeçalho sem quebrar a sinalização SIP e a operadora de interconexão precisa assinar ou validar chamadas. Sem essas condições, a implementação pode aumentar a queda de completamento em vez de reduzi-la.
A Anatel definiu regras para autenticação de chamadas e combate a chamadas abusivas, conforme o comunicado oficial e a página de orientação ao consumidor. Redes que ignoram o padrão tendem a sofrer bloqueios progressivos por operadoras que já adotaram STIR/SHAKEN.
Para contact centers, autenticação sem ajuste de pacing ainda gera reprovação.
Quais são os critérios técnicos para autenticar chamadas com STIR/SHAKEN?
Para engenheiros de voz, integradores e provedores SIP, a autenticação com STIR/SHAKEN depende de uma cadeia técnica sem folgas: certificado digital válido, assinatura aplicada no SIP Identity header e verificação dessa assinatura no SBC de destino. A falta de autenticação expõe a operação ao risco de bloqueio pelas operadoras receptoras, especialmente em interconexões que já exigem origem verificada.
Os critérios práticos para validar a implementação são:
- Certificado emitido por autoridade reconhecida no ecossistema STIR/SHAKEN — sem isso, a assinatura é rejeitada antes mesmo da verificação do header.
- Assinatura aplicada no tronco SIP de origem — o Identity header precisa ser inserido antes do encaminhamento para a interconexão; assinar após o roteamento invalida a cadeia.
- SBC de destino com suporte à validação do Identity header — equipamentos de gerações diferentes podem exigir licença adicional ou apresentar degradação de performance ao processar assinaturas.
- Política definida para chamadas não autenticadas — o SBC precisa decidir entre bloquear, marcar ou encaminhar chamadas sem assinatura antes de ativar a verificação em produção.
- Gestão do ciclo de renovação do certificado — certificado expirado derruba chamadas legítimas, mesmo com número correto e reputação limpa.
- Compatibilidade com a operadora de destino — se a receptora ainda não valida o header, a autenticação não traz benefício imediato naquela rota.
O Despacho Decisório Anatel nº 82/2026 estabelece parâmetros para identificação de chamadas no Brasil e cria a base regulatória para essa autenticação, conforme detalhado na página oficial da Anatel sobre autenticação e identificação de chamadas. Provedores SIP e integradores que operam interconexão com operadoras exigentes precisam tratar o STIR/SHAKEN como requisito de completamento, não como melhoria opcional.
Antes de implementar, valide em ambiente controlado com volume reduzido de chamadas e monitore taxa de rejeição e completamento.
O que é o Identity header no SIP e como ele se relaciona com RCD e Origem Verificada?
O Identity header é o campo do protocolo SIP que transporta a assinatura criptográfica STIR/SHAKEN, comprovando que a chamada foi autenticada por uma operadora autorizada. Para engenheiros de voz, integradores e operadoras, a falta de clareza sobre os mecanismos costuma gerar falsas expectativas: a assinatura garante a integridade da origem, mas não assegura completamento nem exibição de dados comerciais.
Na prática, o STIR/SHAKEN autentica quem originou a chamada; o RCD (Rich Call Data) usa esse mesmo header para anexar nome, logotipo e motivo ao display. A Origem Verificada é o resultado visível dessa combinação: identidade autenticada + dados enriquecidos. São camadas complementares, não intercambiáveis.
O ponto crítico para provedores SIP e SBCs é operacional: uma chamada com Identity header válido pode ser bloqueada por filtro antispam baseado em reputação; uma chamada sem assinatura pode ser exibida com nome se o destino confiar na interconexão. O prefixo 0303 identifica telemarketing, e o serviço Não Me Perturbe bloqueia chamadas publicitárias independentemente da autenticação — a Anatel regula ambos os mecanismos em combate às chamadas abusivas e direitos sobre chamadas publicitárias.
O Identity header comprova a origem, mas a decisão de completar, exibir ou bloquear pertence ao destino. Para avaliar sua operação, verifique três pontos: o SBC anexa o header em todas as chamadas de saída? O certificado é do tipo apropriado (A, B ou C) para o perfil de tráfego? O destino valida a assinatura ou apenas confia no IP de interconexão? Essas respostas separam problema de configuração de política do destino.
Implementar STIR/SHAKEN sem configurar RCD é autenticar um documento sem preencher o conteúdo: a assinatura é válida, mas a informação útil não chega ao usuário final.
Onde a adoção de SIP Identity header STIR SHAKEN costuma falhar?
Os erros abaixo concentram a maioria dos incidentes de queda de completamento e bloqueio de chamadas legítimas relatados por engenheiros de voz, integradores e provedores SIP. Cada falha tem correção conhecida, desde que a autenticação seja tratada como sistema de reputação, não como firewall binário.
- Validar certificados de forma incompleta: aceitar qualquer certificado sem conferir a cadeia até a raiz, a validade temporal e o CN/SAN contra o domínio do provedor de origem gera rejeição silenciosa de chamadas legítimas no destino, sem log útil para diagnóstico.
- Aplicar o mesmo critério para tráfego intrarrede e inter-rede: chamadas entre ramais do mesmo SBC não exigem verificação STIR/SHAKEN plena. Políticas distintas no SBC evitam latência desnecessária e pontos de falha adicionais na interconexão SIP.
- Bloquear sem proporcionalidade: rejeitar toda chamada com Identity header ausente ou inválido derruba o completamento de operadoras menores ainda em migração. O Despacho Decisório Anatel nº 82/2026 estabelece parâmetros, mas não obriga bloqueio imediato de todo tráfego não autenticado. Use gradiente: aceitar com marcação, reduzir prioridade e bloquear somente após falhas recorrentes do mesmo tronco.
- Ignorar comunicação prévia e opt-out: bloquear sem notificar o provedor de origem gera disputa de interconexão e retrabalho. Documente cada bloqueio com timestamp, IP de origem e motivo técnico, permitindo ajuste antes da política restritiva.
- Não monitorar reputação e pacing: autenticação resolve identidade, não volume. Número assinado que dispara milhares de chamadas por hora continua sendo spam na prática. Monitore taxa de chamadas por origem, índice de resposta e duração média para calibrar o pacing e evitar bloqueio manual pelo destino.
O erro mais caro é tratar o SIP Identity header STIR SHAKEN como chave liga/desliga, quando exige calibração fina por tronco e tipo de tráfego.
Como o Origem Verificada pode melhorar a reputação das suas chamadas?
O Origem Verificada (RCD) permite exibir nome, logotipo e o motivo da chamada na tela do consumidor antes do atendimento. Essa transparência reduz a probabilidade de o usuário rejeitar uma ligação legítima, porque ele reconhece a origem.
Quando sua operação usa autenticação STIR/SHAKEN combinada ao RCD, a chamada carrega identidade verificada e contexto visual. O consumidor vê "Banco X" e o motivo "Confirmação de compra", em vez de um número desconhecido.
O mecanismo não é filtro antispam e não garante que chamadas abusivas sejam completadas. Ele atua na camada de reputação, aumentando a chance de o usuário atender com confiança.
Conforme o Despacho 82/2026, prestadoras podem isentar origens autenticadas e identificadas pelo Origem Verificada de bloqueios e taxações adicionais. Isso reduz o atrito operacional para quem adota o padrão corretamente.
Chamadas com Origem Verificada e assinatura STIR/SHAKEN válida têm mais chance de serem exibidas com identificação completa e menos risco de bloqueio por filtros das operadoras. A implementação exige ajuste no SBC e na interconexão com a operadora, como mostramos no diagnóstico de Origem Verificada.
Próximos passos: como adequar sua operação às novas regras da Anatel
Para CTOs, gestores de telecom e engenheiros de voz, o caminho de adequação exige priorizar ações que reduzam o risco regulatório sem comprometer a taxa de completamento. A ordem abaixo considera complexidade de implantação, tempo até valor e integração com a infraestrutura SIP e SBC existente.
- Mapeie troncos SIP e cenários de bloqueio — Identifique quais rotas de saída concentram reclamações, chamadas curtas ou quedas de completamento. Esse diagnóstico define se a operação exige STIR/SHAKEN completo ou se o RCD resolve primeiro os casos de maior exposição.
- Implemente a assinatura do Identity header no SBC — Configure o SBC de borda para assinar o Identity header no SIP com certificados válidos do seu provedor de autenticação. Valide a interconexão com pelo menos uma operadora parceira antes de expandir para todo o tráfego.
- Ative o Origem Verificada nas rotas elegíveis — Após a autenticação, solicite a exibição de nome e logotipo via RCD. Essa camada depende da adoção pelas operadoras móveis, mas tende a melhorar a experiência do consumidor e reduzir rejeições por aparência de chamada abusiva.
- Monitore completamento e reputação por número — Acompanhe métricas operacionais após cada mudança. Se um número autenticado apresentar queda de atendimento ou aumento de bloqueio, revise a cadeia de sinalização antes de escalar o volume.
- Formalize opt-out e revisão de bloqueios — Mantenha processo documentado para números que solicitaram bloqueio e revisão periódica das listas. Isso reduz a exposição a novas medidas cautelares da Anatel e preserva a operação de chamadas legítimas.
O trade-off central está entre autenticar cedo e operar com segurança regulatória. A assinatura STIR/SHAKEN exige configuração técnica no SBC e certificados válidos, mas é o passo que mais reduz o risco de bloqueio por falta de autenticação.
Fontes e referências
Segundo as referências institucionais abaixo, a validação técnica deve considerar a documentação primária de cada padrão e serviço.
- WebRTC: Real-Time Communication in Browsers — World Wide Web Consortium (W3C)
- RFC 3261: SIP — Session Initiation Protocol — RFC Editor
Perguntas frequentes
O que é o SIP Identity header e como ele se relaciona com STIR/SHAKEN na prática para engenheiros de voz?
O Identity header é o campo do protocolo SIP que transporta a assinatura criptográfica STIR/SHAKEN, comprovando que a chamada foi autenticada por uma operadora autorizada. Ele garante a integridade da origem, mas não assegura completamento nem exibição de dados comerciais, que dependem do RCD.
Como o Despacho 82/2026 da Anatel impacta a obrigatoriedade do SIP Identity header para provedores SIP e operadoras?
O Despacho Decisório Anatel nº 82/2026, com vigência imediata, exige que sua operação insira o SIP Identity header em todas as chamadas que cruzam o SBC. Sem isso, operadoras destinatárias podem classificar seu tráfego como suspeito e bloquear chamadas legítimas, derrubando taxas de completamento.
Quais critérios técnicos devo avaliar para autenticar chamadas com STIR/SHAKEN usando o Identity header no meu SBC?
A autenticação depende de uma cadeia sem folgas: certificado digital válido emitido por autoridade reconhecida, assinatura aplicada no SIP Identity header e verificação dessa assinatura no SBC de destino. Sem certificado válido, a assinatura é rejeitada antes mesmo da verificação do header.
Como implementar a assinatura do Identity header no SBC para atender às novas regras da Anatel sem derrubar o completamento?
Priorize mapear troncos SIP e cenários de bloqueio, identificando rotas com reclamações ou quedas. Em seguida, configure o SBC de borda com suporte nativo a STIR/SHAKEN, aplicando a assinatura no INVITE. Monitore o completamento antes e depois da mudança para validar a implementação.
Quais requisitos de infraestrutura SIP e SBC são necessários para suportar o Identity header STIR/SHAKEN e evitar bloqueios?
O SBC precisa de suporte nativo a STIR/SHAKEN, certificados de assinatura e validação no INVITE. Para provedores SIP, é essencial ter logging do Identity header e suporte a RCD e Origem Verificada. Sem isso, chamadas legítimas podem ser bloqueadas por filtros no destino.
Quais erros de validação de certificados no Identity header STIR/SHAKEN causam bloqueio silencioso de chamadas legítimas?
Aceitar qualquer certificado sem conferir a cadeia até a raiz, a validade temporal e o CN/SAN contra o domínio do provedor de origem gera rejeição silenciosa no destino, sem log útil para diagnóstico. Aplicar o mesmo critério para tráfego intrarrede e inter-rede também é um erro comum.
