Guia de implementação STIR/SHAKEN no SBC: como assinar, atestar e verificar chamadas

Se você gerencia serviços de voz nos Estados Unidos, o STIR/SHAKEN é um requisito básico para suas operações. A FCC agora exige que a maioria dos provedores assine chamadas de saída com seus próprios certificados, mantenha o cadastro atualizado no Robocall Mitigation Database (RMD) e cumpra as recertificações anuais. Como operadoras downstream estão cada vez mais sinalizando ou bloqueando chamadas não assinadas, implementar isso corretamente é a melhor forma de garantir que as chamadas dos seus clientes realmente cheguem ao destino.

A boa notícia é que seu Controlador de Borda de Sessão (SBC) é o aliado perfeito para essa tarefa. Como ele fica na borda da sua rede atuando como Agente de Usuário Back-to-Back (B2BUA), possui a visibilidade necessária para gerenciar cada sessão SIP. Essa arquitetura permite que ele colete facilmente os cabeçalhos SIP específicos (números de origem e destino, timestamps e níveis de atestação) necessários para construir um token PASSporT válido.

Criamos este guia para orientar você no processo de implementação. Começaremos pelos pré-requisitos da FCC e aquisição de certificado, passando pela configuração do SBC, integração com o serviço de assinatura e lógica de atestação, finalizando com verificação e testes em produção.

Como o STIR/SHAKEN funciona no nível do SBC

O STIR (Secure Telephone Identity Revisited) define o protocolo criptográfico para assinatura da identidade de chamadas. O SHAKEN (Signature-based Handling of Asserted information using toKENs) define o framework da indústria para como os provedores de serviços implementam o STIR em redes de produção.

Lado de origem (assinatura)

Quando seu SBC recebe uma chamada de saída, ele intercepta o SIP INVITE antes de encaminhá-lo ao próximo salto. O SBC extrai o número de origem (do cabeçalho P-Asserted-Identity ou do cabeçalho From), o número de destino (do cabeçalho To) e o timestamp (do cabeçalho Date). Ele empacota esses dados em uma requisição de assinatura e a envia a um serviço externo de assinatura, também chamado de STI Authentication Service (STI-AS). Essa requisição é entregue via SIP (TCP, porta 5060), com o serviço de assinatura atuando como um servidor de redirecionamento SIP. O ProSBC também suporta assinatura via HTTPS para provedores STI-AS que exigem esse formato. O serviço de assinatura cria um token PASSporT, assina com a chave privada do seu certificado e retorna um cabeçalho Identity completo. Seu SBC injeta esse cabeçalho Identity no SIP INVITE de saída.

Lado de terminação (verificação)

Quando seu SBC recebe uma chamada de entrada com um cabeçalho Identity, ele pode encaminhar a chamada a um serviço de verificação (STI-VS) via SIP. O serviço de verificação valida a assinatura, verifica a cadeia de certificados, confirma que o token não expirou nem foi adulterado, e retorna um SIP 302 com o parâmetro Verstat no cabeçalho P-Asserted-Identity (ou 404/503 se não houver sinal disponível). O ProSBC obtém a string Verstat desse 302 e a encaminha ao próximo destino. Com base no resultado da verificação, você aplica a política: aceitar, sinalizar ou rejeitar.

O PASSporT (Personal Assertion Token) contém cinco campos principais: orig (número de telefone de origem), dest (número de destino), iat (timestamp de emissão), origid (identificador único da chamada) e attest (nível de atestação).

Os três níveis de atestação

A atestação comunica seu relacionamento com a chamada e com o originador. Não é uma pontuação de confiança nem uma classificação de spam. Para uma referência detalhada sobre o que cada nível significa na prática, veja Níveis de atestação STIR/SHAKEN explicados. É uma declaração do provedor de serviços de origem sobre quanto ele sabe a respeito da chamada.

A (atestação completa)

A atestação nível A se aplica quando você autenticou o originador da chamada, sabe quem ele é e ele está autorizado a usar o número de origem. Este é o nível que você atribui quando o chamador é seu assinante direto ou um cliente cuja identidade você verificou.

B (atestação parcial)

A atestação nível B cobre chamadas em que você sabe de onde a chamada se originou (veio de um tronco ou peer conhecido e autenticado), mas não pode verificar se o chamador específico está autorizado a usar o número de origem. Isso é comum para provedores de trânsito e operadoras wholesale que repassam tráfego de parceiros upstream conhecidos.

C (atestação de gateway)

A atestação nível C é o nível para chamadas que entraram na sua rede por uma origem não confiável ou não verificável. Você é o primeiro salto IP, mas não consegue confirmar nada sobre a identidade do chamador. Isso se aplica em gateways PSTN-para-IP, interconexões internacionais ou ao receber tráfego de provedores que não autenticam seus usuários.

Pré-requisitos antes de começar

Antes de tocar na configuração do seu SBC, você precisa concluir vários pré-requisitos administrativos e técnicos.

Requisitos administrativos da FCC

• Obtenha um Operating Company Number (OCN). Seu OCN é atribuído pela National Exchange Carrier Association (NECA). Se você já se registrou como provedor de serviços de voz, provavelmente já possui um.
• Preencha um Form 499-A atualizado. O FCC Telecommunications Reporting Worksheet deve estar atualizado e arquivado.
• Registre-se no Robocall Mitigation Database (RMD). Você deve certificar a implementação completa do STIR/SHAKEN ou seu programa de mitigação de robocalls. A recertificação anual é obrigatória (o prazo mais recente foi 1 de março de 2026). Para um detalhamento completo das obrigações de pequenos provedores, veja Conformidade STIR/SHAKEN da FCC para pequenos provedores VoIP. A FCC agora impõe multas de $10.000 por informações falsas ou imprecisas no RMD e $1.000 por não atualizar o banco de dados em até 10 dias úteis após uma mudança relevante.
• Obtenha seu token SPC. Solicite um token de Service Provider Code (SPC) ao administrador de políticas STIR/SHAKEN (atualmente a iconectiv nos EUA). Esse token comprova sua identidade ao solicitar um certificado.
• Adquira seu certificado STI. Apresente seu token SPC a uma autoridade certificadora STIR/SHAKEN (STI-CA) para obter seu certificado digital. Sob a regra de certificado próprio, todas as chamadas devem ser assinadas com seu certificado, não de terceiros. Você pode contratar um terceiro para realizar a assinatura técnica, mas o certificado e as decisões de atestação devem ser seus.

Pré-requisitos técnicos

• Escolha um parceiro de serviço de assinatura. O ProSBC não realiza a assinatura criptográfica por conta própria. Ele se integra com um STI Authentication Service (STI-AS) externo. O ProSBC envia um SIP INVITE, o serviço de assinatura retorna um 302 com o cabeçalho Identity no P-Asserted-Identity, e o ProSBC avança a rota para o próximo destino com o cabeçalho Identity anexado. O ProSBC também suporta provedores STI-AS baseados em HTTPS que preferem uma troca HTTP POST/JSON.
• Confirme a conectividade. Seu SBC deve ser capaz de alcançar o serviço de assinatura. Para provedores STI-AS baseados em SIP, isso significa SIP sobre TCP na porta 5060 para o FQDN do provedor (por exemplo, sip.clearip.com). Verifique a resolução DNS, a conectividade TCP e se os firewalls entre o SBC e o serviço de assinatura permitem tráfego SIP de saída. Para provedores baseados em HTTPS, permita HTTPS de saída para o endpoint de assinatura configurado.
• Ative o pré-requisito SIP. No ProSBC, ative “Publish raw SIP to Routing Script” em SIP Stack > Quirks. Essa configuração é necessária para que o parâmetro iat (timestamp de emissão) seja preenchido corretamente a partir do cabeçalho SIP Date. Sem ela, a requisição de assinatura ficará sem um campo obrigatório.

Configuração passo a passo do SBC para assinatura STIR/SHAKEN

Esta seção usa o mecanismo de roteamento Ruby configurável do ProSBC como implementação de referência. O padrão arquitetural (SBC consulta serviço externo de assinatura via SIP, injeta cabeçalho Identity) se aplica a qualquer SBC, mas os passos específicos de configuração são do ProSBC.

1. Configure os parâmetros do serviço de assinatura

Do seu provedor de serviço de assinatura você precisa de:

• FQDN do serviço de assinatura: O destino SIP para onde o ProSBC encaminhará as requisições de assinatura. Para o ClearIP, é sip.clearip.com (ou o FQDN regional fornecido pelo ClearIP). Você criará um ou dois NAPs apontando para esse FQDN, dependendo se deseja um único NAP para todo o tráfego ou NAPs separados para entrada e saída.
• Credenciais de identificação de origem: O ClearIP identifica sua conta pelos cabeçalhos de origem que o ProSBC envia no INVITE. Esses são configurados no routing script ClearIP_Query e fornecidos pelo serviço de assinatura quando você provisiona sua conta.
• Timeout de Route Retry: O temporizador SIP que controla quanto tempo o ProSBC espera por uma resposta SIP do serviço de assinatura antes de avançar a rota. O padrão é 10 segundos.

2. Configure o routing script

Para implantações baseadas em SIP com o ClearIP, o ProSBC se integra através do routing script ClearIP_Query (ClearIP_Query.rb), que se conecta à cadeia de filtros do routing script. O módulo é incluído na sua classe de roteamento principal e registrado como before_filter, o que significa que ele executa cedo o suficiente para adicionar cabeçalhos de identificação de origem ao INVITE que o ProSBC enviará ao NAP do ClearIP. O Neustar usa um filtro dedicado equivalente; provedores STI-AS baseados em HTTPS usam o módulo StirShakenSapi, registrado como after_remap_filter.

Para o ClearIP, a integração é configurada no nível do routing script em vez de via parâmetros de URL de assinatura:

1. Importe o ClearIP_Query.rb como filter scriptFaça o upload pelo painel de routing scripts e marque “Load on startup”.
2. Inclua o módulo no seu routing script principalNo seu routing script principal (padrão simple_routing_sbc.rb), adicione require 'ClearIP_Query' unless defined?(ClearIPQuery) no topo.
3. Inclua o módulo na sua classe de roteamentoNa sua classe de roteamento principal, adicione include ClearIPQuery.
4. Registre o before_filterNa mesma classe de roteamento, adicione before_filter :method => :ClearIP_query. Se você já usa label routing ou outros before_filters, coloque o ClearIP_query por último.

A atestação no modelo SIP não é uma configuração de URL separada. O NAP do ClearIP carrega o papel de atestação através da coluna service_type (coberta abaixo). Se você precisa diferenciar autenticação e verificação, crie NAPs e rotas separados em vez de endpoints de URL separados.

3. Configure as colunas do NAP

No ProSBC, o papel que cada NAP desempenha no fluxo STIR/SHAKEN é definido por uma coluna do NAP chamada service_type. Crie a coluna uma vez com os valores permitidos NORMAL | AUTHENTICATION | VERIFICATION e o padrão NORMAL, depois atribua o valor apropriado a cada NAP:

4. Entenda o fluxo interno de assinatura

Quando uma chamada atinge uma rota que chega a um NAP com service_type=AUTHENTICATION, aqui está o que acontece com o ClearIP:

1. O before_filter inspeciona o INVITEO before_filter ClearIP_Query inspeciona o INVITE e adiciona os cabeçalhos de identificação de origem que o ClearIP precisa para autenticar a requisição.
2. O ProSBC envia o SIP INVITE para o NAP do ClearIPA requisição vai via TCP/5060 para o FQDN do ClearIP.
3. O ClearIP retorna uma das quatro respostas SIP302 Moved Temporarily (sucesso: cabeçalho Identity no PAI), 404 Not Found (nenhuma fraude detectada e nenhuma assinatura realizada), 503 Service Unavailable (mesmo efeito que 404) ou 603 Decline (fraude detectada: interrompa a chamada).
4. O ProSBC avança a rota com base no Reason Cause MappingO comportamento de avanço de rota para cada uma dessas respostas é controlado pelo Reason Cause Mapping (configurado no próximo passo). A própria lista de rotas é a cadeia de failover no modelo SIP.

Para verificação (service_type=VERIFICATION), o fluxo é idêntico, exceto que o ClearIP retorna o parâmetro Verstat no PAI em vez de um cabeçalho Identity.

Para provedores STI-AS baseados em HTTPS, o fluxo equivalente é um HTTPS POST com um corpo de resposta JSON contendo os campos Identity_header, origination_id e attestation_info; o failover e a mecânica de políticas nesse caminho são diferentes e estão fora do escopo deste guia.

5. Configure a Route Retry Action para os Reason Causes

Como o modelo SIP usa avanço de rota como mecanismo de failover e política, você precisa definir a Route Retry Action para cada código de reason cause que o ClearIP pode retornar. Em Profiles → Edit Reason Cause Mapping, defina:

Resposta SIP	Route Retry Action	Padrão do ProSBC
302 Moved Temporarily	Process call routing	Já correto
404 Not Found	Continue call	Padrão é “Stop call”; altere
503 Service Unavailable	Continue call	Já correto
603 Decline	Stop call	Padrão é “Continue call”; altere

Implementando a atestação

A distinção entre os tipos de requisição SIGNING e ATTESTATION importa para provedores que desempenham diferentes papéis no caminho da chamada.

Use SIGNING quando você é o provedor de serviços de origem e precisa criar um novo cabeçalho Identity do zero. O serviço de assinatura gera o PASSporT, assina com seu certificado e retorna o cabeçalho Identity completo.

Use ATTESTATION quando uma chamada chega com informações de identidade existentes (talvez um origination_id ou attestation_info de um provedor upstream) e você precisa aplicar ou modificar o nível de atestação. O endpoint de atestação usa o nome de método identity_attestation e envia os dados de identidade existentes junto com sua decisão de atestação.

Tomando decisões de atestação

Seu nível de atestação deve refletir com precisão seu relacionamento com a chamada. A FCC responsabiliza o provedor assinante pela precisão da atestação. Aqui está um framework prático:

• Atribua nível A quando o chamador é seu assinante direto, você verificou a identidade dele e ele está autorizado a usar o número de origem que está apresentando. Para um MSP, isso significa que a chamada se origina de um cliente cujas credenciais SIP você gerencia e cujas atribuições de DID você controla.
• Atribua nível B quando a chamada vem de um tronco upstream autenticado (você conhece o provedor), mas não pode verificar independentemente o direito do chamador de usar o número específico. Isso é típico para provedores VoIP que recebem tráfego de parceiros wholesale ou revendedores.
• Atribua nível C quando a chamada entra na sua rede por uma origem não verificável: um gateway PSTN, uma interconexão internacional ou um provedor upstream que não autentica seus usuários.

O cenário de autoatestação

Algumas operadoras upstream reduziram o nível de atestação que fornecem a provedores downstream. Por exemplo, operadoras que anteriormente ofereciam atestação nível A agora fornecem apenas nível C, pressionando provedores menores a obter seus próprios certificados e autoatestar. Se sua operadora upstream fornece apenas atestação nível C e você pode verificar independentemente a identidade do chamador e a autorização do número, você pode e deve assinar a chamada por conta própria no nível mais alto apropriado usando seu próprio certificado. Veja nosso guia sobre como passar da atestação nível C para a autoatestação nível A para o framework operacional completo.

Verificação no lado de terminação

No lado de terminação, seu SBC recebe chamadas de entrada que podem ou não incluir um cabeçalho Identity.

Quando o NAP de entrada roteia para um NAP com service_type=VERIFICATION, o ProSBC encaminha a chamada (com seu cabeçalho Identity) ao serviço de verificação via SIP. O serviço de verificação verifica a assinatura digital contra o certificado, valida a cadeia de certificados, confirma que o token não expirou e retorna o resultado como um SIP 302 com o parâmetro Verstat no cabeçalho P-Asserted-Identity (ou 404/503 se nenhum sinal estiver disponível). O ProSBC obtém a string Verstat e a encaminha ao próximo destino, onde as políticas downstream podem atuar sobre ela.

Com base no resultado da verificação, você define políticas na sua lógica de roteamento:

• Verificado, atestação nível A: Alta confiança. Encaminhe normalmente.
• Verificado, atestação nível B ou C: Confiança menor, mas devidamente assinado. Encaminhe normalmente, mas você pode optar por sinalizar a chamada ou aplicar triagem adicional de fraude através de integrações como TransNexus ClearIP, SecureLogix ou YouMail.
• Verificação falhou ou sem cabeçalho Identity: A chamada não está assinada ou a assinatura é inválida. Dependendo da sua tolerância a riscos, você pode encaminhar normalmente (muitas chamadas legítimas de provedores menores ainda não são assinadas), sinalizar a chamada para monitoramento, aplicar triagem adicional ou rejeitar a chamada.

O ProSBC suporta integração com o Neustar como caminho dedicado de verificação. Ao usar o Neustar, você configura a coluna service_type do NAP como VERIFICATION no NAP de entrada relevante, e o filtro nuestar_query lida automaticamente com a requisição de verificação.

Arquitetura de redundância e failover

A disponibilidade do serviço de assinatura impacta diretamente a completude das chamadas se sua implementação não considerar falhas. O módulo STIR/SHAKEN do ProSBC inclui um design de failover em três camadas expresso através da própria lista de rotas:

Camada 1: NAP primário do ClearIP

Todas as requisições de assinatura para aquela classe de tráfego vão aqui primeiro. O primeiro Remapped NAP de prioridade da rota é o NAP primário.

Camada 2: NAP secundário do ClearIP (ou STI-AS alternativo)

Uma segunda rota com prioridade menor aponta para um NAP secundário: o FQDN redundante do ClearIP, uma região diferente ou um provedor STI-AS completamente diferente. Se o primário retornar um SIP 503 ou expirar o tempo, o ProSBC avança a rota para o secundário com base no Reason Cause Mapping configurado acima.

Camada 3: Rota de bypass

Uma rota final com a menor prioridade envia a chamada ao seu destino sem passar por nenhum STI-AS. Se tanto a Camada 1 quanto a Camada 2 falharem, a chamada ainda é completada. Para implantações baseadas em HTTPS, o fallback equivalente é o cabeçalho P-Identity-Bypass que o módulo StirShakenSapi anexa após esgotar ambas as URLs; no modelo SIP, o mesmo resultado é alcançado pela ordenação de rotas.

Considerações de monitoramento

Monitore essas métricas para garantir que sua implementação STIR/SHAKEN permaneça saudável:

• Taxa de sucesso de assinatura é a porcentagem de chamadas assinadas com sucesso versus aquelas que caíram no bypass. Um aumento repentino nos eventos de bypass indica um problema no serviço de assinatura.
• Latência de assinatura mede o tempo desde a consulta HTTP ou SIP até a resposta. Latência crescente pode indicar degradação do serviço de assinatura antes que se torne uma indisponibilidade.
• Distribuição de atestação é a divisão dos níveis de atestação A, B e C no seu tráfego. Mudanças inesperadas (por exemplo, um aumento repentino em chamadas nível C) podem indicar uma alteração nos padrões de tráfego upstream.
• Taxa de falha de verificação no lado de terminação é a porcentagem de chamadas em que a verificação falha. Taxas altas podem indicar problemas de certificado, desvio de relógio ou tráfego falsificado.

A saída de CDR do ProSBC, traps SNMP e a capacidade de rastreamento de logs (defina o nível de trace 2 para eventos STIR/SHAKEN) fornecem os dados necessários para esse monitoramento. Para provedores que desejam monitoramento automatizado, a TelcoBridges oferece o Monitoring as a Service (MaaS) como um produto independente.

Erros comuns de implementação

Estes são os erros que mais frequentemente atrasam ou quebram implantações STIR/SHAKEN:

Testando sua implementação

Use um ambiente de laboratório primeiro

ProSBC Lab é uma licença gratuita e permanente de 3 sessões projetada exatamente para esse tipo de teste. Você pode implantar uma instância de laboratório em aproximadamente 20 minutos, configurar a assinatura STIR/SHAKEN contra o ambiente de teste do seu serviço de assinatura e validar o fluxo completo antes de tocar na produção.

Etapas de verificação

• Verifique a injeção do cabeçalho Identity. Use a captura Wireshark em tempo real do ProSBC ou o rastreamento de chamadas para inspecionar os SIP INVITEs de saída. O cabeçalho Identity deve estar presente em cada chamada assinada, contendo o PASSporT completo com a referência do seu certificado.
• Valide os níveis de atestação. Verifique se os níveis de atestação A, B e C estão sendo atribuídos corretamente com base na configuração de rotas e na origem da chamada. Seu provedor de serviço de assinatura pode oferecer um painel de teste que mostra a distribuição de atestações.
• Teste o failover. Bloqueie a conectividade SIP para o NAP primário do ClearIP (bloqueie o IP de destino no firewall ou desative o NAP no ProSBC) e confirme que o ProSBC avança a rota para o NAP secundário e a chamada ainda é completada com um cabeçalho Identity. Depois bloqueie ambos os NAPs e confirme que a chamada avança para sua rota de bypass. Para implantações baseadas em HTTPS, o estado final equivalente é o cabeçalho P-Identity-Bypass no INVITE de saída.
• Teste ponta a ponta. Origine uma chamada assinada do seu SBC e verifique no lado de terminação que o cabeçalho Identity está presente e a assinatura é válida. Se você tiver um segundo SBC ou uma conta de teste com um provedor de terminação, pode verificar a cadeia completa.
• Revise os logs. O módulo STIR/SHAKEN do ProSBC registra no nível de trace 2. Entradas de log importantes: “Send to first signing domain”, “HTTP server returned 200”, “Added Identity header” e o corpo completo da resposta JSON. Se você vir “This is the third iteration, send call anyway adding Bypass SIP header”, seu serviço de assinatura está falhando.

Escolhendo uma arquitetura de serviço de assinatura aberta vs. proprietária

Nem todos os SBCs implementam o STIR/SHAKEN da mesma forma. A escolha arquitetural do fabricante do seu SBC determina sua flexibilidade como provedor. Para uma visão mais ampla de como os modelos de assinatura abertos e proprietários se comparam, veja STIR/SHAKEN e autenticação de chamadas.

Implementações proprietárias

Implementações proprietárias (comuns com Ribbon, Oracle) acoplam fortemente o SBC a um serviço de assinatura específico ou exigem o servidor de políticas do próprio fabricante como intermediário. Isso simplifica a implantação inicial, mas prende você ao ecossistema do fabricante para serviços de assinatura, preços e disponibilidade de funcionalidades.

Modelo de API aberta (ProSBC)

O modelo de API aberta trata o serviço de assinatura como um componente externo e intercambiável conectado via SIP ou HTTPS, conforme a preferência do provedor STI-AS. O mecanismo de roteamento configurável do ProSBC se integra hoje com TransNexus ClearIP e Neustar via SIP, e suporta HTTPS POST/JSON para provedores STI-AS que exigem esse formato. Isso significa que você pode escolher TransNexus, Neustar ou qualquer outro provedor STI-AS. Pode trocar de provedor sem alterar a configuração do SBC além de atualizar URLs e credenciais. Pode até usar serviços de assinatura diferentes para tipos de tráfego diferentes (por exemplo, um provedor para doméstico e outro para tráfego de gateway internacional).

Esse modelo aberto de parceiros também torna sua implantação à prova de futuro. Conforme o ecossistema STIR/SHAKEN evolui e novas funcionalidades de serviços de assinatura surgem (análise avançada de caller ID, integração de pontuação de fraude, dados de reputação em tempo real), você pode adotá-las escolhendo um provedor que as ofereça, em vez de esperar que o fabricante do seu SBC construa uma integração proprietária.

Perguntas frequentes

Conclusão

A implementação do STIR/SHAKEN no nível do SBC é um exercício de configuração simples uma vez que os pré-requisitos administrativos estejam em ordem e você tenha escolhido um parceiro de serviço de assinatura. Os passos essenciais são: obter seu certificado, configurar NAPs de assinatura primário e secundário, definir sua lógica de atestação, ativar o módulo de roteamento e testar.

As escolhas de implementação que mais importam são aquelas que a regra de certificado próprio da FCC reforça: seu certificado, sua decisão de atestação, sua responsabilidade. A assinatura técnica pode ser delegada a terceiros, mas o sinal de confiança que uma operadora downstream ou um SBC de terminação vê no cabeçalho Identity sempre remonta ao provedor de origem.