STIR/SHAKEN e autenticação de chamadas

STIR/SHAKEN não é mais opcional para a maioria dos provedores de serviços de voz nos EUA. O mandato de implementação da FCC, reforçado pela regra de certificado próprio de setembro de 2025, exige que cada provedor originador tenha infraestrutura capaz de assinar chamadas com seu próprio certificado, atribuir o nível de atestação correto por chamada e funcionar de forma adequada quando o serviço de assinatura estiver indisponível.

O Controlador de Borda de Sessão (SBC) é onde tudo isso acontece. Ele fica na borda originadora da rede, o último ponto de controle antes de uma chamada sair do seu domínio. Porém, os SBCs diferem significativamente na forma como lidam com STIR/SHAKEN. Alguns oferecem uma integração estática e proprietária vinculada a um único parceiro de assinatura. Outros expõem um motor de roteamento configurável que dá ao provedor controle total sobre a lógica de atestação, seleção de parceiro e comportamento de fallback.

Esta página explica o que acontece na camada do SBC durante a assinatura e verificação STIR/SHAKEN, por que o roteamento configurável é importante para a conformidade e como a arquitetura aberta do ProSBC resolve isso.

Como o STIR/SHAKEN funciona na camada do SBC

O framework STIR/SHAKEN atribui dois papéis distintos aos provedores de serviço: o provedor originador assina a chamada, e o provedor terminador verifica a assinatura. O SBC é o ponto de execução para ambos.

Assinatura (lado originador)

Quando uma chamada entra no SBC a partir de um tronco de cliente, o SBC coleta os detalhes necessários para o token PASSporT: o número originador (do P-Asserted-Identity ou From header), o número de destino (do To header) e o timestamp (do Date header). Ele determina o nível de atestação apropriado para a chamada e então envia uma requisição de assinatura a um Serviço de Autenticação STIR/SHAKEN externo (STI-AS). O STI-AS usa o certificado do provedor para gerar uma assinatura criptográfica, encapsula-a em um token PASSporT e retorna um Identity header assinado. O SBC injeta esse Identity header no SIP INVITE de saída antes de encaminhar a chamada.

Verificação (lado terminador)

Quando o SBC recebe uma chamada de entrada com um Identity header, ele encaminha esse cabeçalho a um Serviço de Verificação STIR/SHAKEN (STI-VS). O serviço de verificação valida a assinatura criptográfica contra o certificado do provedor originador, verifica se o token não expirou e confirma que os números chamador e chamado correspondem às declarações do PASSporT. O resultado retorna ao SBC, que roteia a chamada de acordo.

Níveis de atestação

Toda chamada assinada carrega um dos três níveis de atestação, determinado pelo provedor originador:

• A (Atestação completa): O provedor autentica a parte chamadora e confirma que ela está autorizada a usar o número de origem.
• B (Atestação parcial): O provedor pode autenticar a origem da chamada, mas não consegue verificar a autorização do chamador para usar o número específico.
• C (Atestação gateway): A chamada entrou na rede a partir de uma fonte externa que o provedor não consegue autenticar.

O nível de atestação não é decorativo. Ele afeta diretamente como provedores downstream e plataformas de analytics tratam a chamada. Chamadas de nível A passam normalmente, enquanto chamadas de nível C são sinalizadas ou bloqueadas. Errar nessa configuração tem consequências reais para as taxas de completamento de chamadas.

Para uma análise detalhada de cada nível de atestação e quando utilizá-los, consulte nosso guia sobre Níveis de atestação STIR/SHAKEN explicados (em breve).

Por que o controle de atestação pertence à camada de roteamento

A atestação é uma decisão por chamada. Ela depende do que você sabe sobre a origem da chamada, e esse conhecimento está na sua lógica de roteamento.

Considere um ISP operando um único SBC que lida com três tipos de tráfego: clientes de SIP Trunking varejo (você emitiu os números e autentica o assinante), trânsito wholesale de uma operadora regional (você sabe de onde veio, mas não consegue verificar o chamador) e tráfego gateway de um parceiro internacional (fonte não confiável). O nível de atestação correto é A para o primeiro, B para o segundo e C para o terceiro. Todos os três passam pelo mesmo SBC.

Um SBC que suporta apenas um nível de atestação fixo por tronco força você a escolher um. Atribuir A a tudo significa fazer declarações falsas de atestação, o que viola as regras da FCC. Atribuir C a tudo faz com que as chamadas dos seus clientes varejo sejam sinalizadas como não verificadas, prejudicando suas taxas de completamento.

É aqui que o roteamento configurável se torna um requisito de conformidade, não apenas uma conveniência. O motor de roteamento avalia cada chamada contra sua lógica de negócio e atribui o nível de atestação dinamicamente. Cliente varejo em um tronco que você provisionou? Nível A. Trânsito wholesale onde você conhece a operadora originadora? Nível B. Tráfego gateway de um peer internacional não confiável? Nível C.

A regra de certificado próprio da FCC, em vigor desde 18 de setembro de 2025, reforça isso. Sua organização deve tomar as decisões de nível de atestação. Um serviço de assinatura pode realizar o ato técnico de assinatura, mas não pode atribuir a atestação de forma independente. (Para uma análise detalhada da regra de certificado próprio e seus requisitos, consulte nossa página sobre a Regra de certificado próprio FCC STIR/SHAKEN.)

Se seu SBC trata a atestação como uma configuração estática em vez de uma decisão de roteamento, você terá dificuldades para manter a conformidade à medida que seu mix de tráfego evolui.

Para provedores que precisam migrar da atestação nível C para nível A com seu próprio certificado, consulte nosso guia sobre Autoatestação STIR/SHAKEN nível A (em breve).

Modelo de parceiro aberto vs. STIR/SHAKEN proprietário

Nem todos os fabricantes de SBC lidam com a integração STIR/SHAKEN da mesma forma. Alguns, incluindo Ribbon e AudioCodes, oferecem implementações proprietárias de STIR/SHAKEN que restringem qual serviço de assinatura você pode usar. A integração é embutida no firmware do SBC, o que simplifica a configuração inicial, mas limita suas opções se você quiser trocar de parceiro de assinatura, adicionar scoring de fraude ou integrar serviços adicionais de conformidade.

O ProSBC adota uma abordagem diferente. Seu motor de roteamento configurável se integra com qualquer serviço de assinatura baseado em HTTP ou SIP por meio de módulos Ruby API. TransNexus ClearIP, Neustar ou qualquer outro STI-AS que aceite requisições de assinatura HTTP padrão ou SIP INVITE: a integração está na camada de roteamento, não embutida no firmware.

Na prática, o módulo StirShakenapi envia uma requisição de assinatura HTTP ou SIP INVITE ao serviço de assinatura configurado, levando seu token de autorização e os detalhes da chamada (número originador, destino, timestamp, nível de atestação). O serviço de assinatura retorna um Identity header assinado, e o SBC o injeta no INVITE de saída.

Três vantagens arquiteturais resultam dessa abordagem:

Redundância

O ProSBC suporta provedores de serviço de assinatura primário e secundário. Se o primário estiver inacessível, a requisição automaticamente faz failover para o secundário. Se ambos estiverem fora do ar, um cabeçalho P-Identity-Bypass é adicionado à chamada, sinalizando aos provedores downstream que a assinatura estava indisponível para aquela chamada específica. A chamada é completada normalmente.

Flexibilidade de parceiro

Trocar de serviço de assinatura significa atualizar um provedor (SIP NAP na configuração do ProSBC) e o token de autorização na configuração de roteamento. Sem atualização de firmware, sem envolvimento do fabricante, sem janela de manutenção. Se a TransNexus aumentar os preços ou a Neustar adicionar uma funcionalidade que você precisa, a migração é uma alteração de configuração.

Composabilidade

Como a requisição de assinatura é uma chamada HTTP ou SIP dentro do script de roteamento, você pode combiná-la com outras integrações de API no mesmo fluxo de chamada. A TransNexus ClearIP, por exemplo, suporta LCR (Least Cost Routing), scoring de fraude e assinatura STIR/SHAKEN em uma única consulta. O motor de roteamento do ProSBC pode avaliar o score de fraude, tomar uma decisão de roteamento e assinar a chamada em uma única passagem.

Implementação STIR/SHAKEN do ProSBC

O ProSBC suporta três tipos de requisição STIR/SHAKEN por meio de seus módulos Ruby API:

Assinatura

O SBC envia uma requisição de ASSINATURA ao STI-AS configurado. Ele popula as declarações do PASSporT a partir da mensagem SIP: orig do P-Asserted-Identity ou From header, dest do To header e iat do Date header. O serviço de assinatura retorna um Identity header assinado contendo a assinatura digital e o nível de atestação, que o SBC injeta no INVITE de saída.

Atestação

Para implantações que separam a decisão de atestação da operação de assinatura, o SBC pode enviar uma requisição de ATESTAÇÃO. Isso permite que a lógica de atestação do provedor seja executada independentemente do serviço de assinatura.

Verificação

No lado terminador, o SBC envia uma requisição de VERIFICAÇÃO, encaminhando o Identity header de entrada ao STI-VS. O resultado da verificação informa as decisões de roteamento downstream.

Abaixo estão informações adicionais configuradas por padrão no ProSBC:

Timeout configurável. Cada consulta HTTP ou SIP ao serviço de assinatura tem um timeout configurável. A configuração padrão é de 10 segundos. Isso evita que a latência da assinatura bloqueie o estabelecimento da chamada quando o serviço de assinatura está lento ou sem resposta.

Provedores primário e secundário (Network Access Points no ProSBC). Tanto os serviços de assinatura quanto de verificação suportam provedores duplos para failover automático.

Fallback P-Identity-Bypass. Se o serviço de assinatura estiver inacessível após tentativas em ambos os provedores, o SBC adiciona um cabeçalho P-Identity-Bypass em vez de bloquear a chamada. A chamada é completada, e o cabeçalho fornece transparência sobre por que o Identity header está ausente.

Roteamento baseado em domínio. Para redes que lidam com tráfego de Mobile Origination (MO) e Mobile Termination (MT), a implementação suporta roteamento baseado em domínio para aplicar diferentes comportamentos STIR/SHAKEN por direção de chamada.

Integrações validadas com parceiros. O ProSBC possui integrações documentadas com TransNexus ClearIP (LCR combinado, scoring de fraude e STIR/SHAKEN) e Neustar (autenticação, verificação e processamento de redirecionamento 302). São integrações validadas e testadas em produção, não declarações genéricas de API.

Como começar

Se você está avaliando como seu SBC lida com STIR/SHAKEN, ou implantando STIR/SHAKEN pela primeira vez, comece com o Guia de implementação STIR/SHAKEN para SBC para o passo a passo completo de configuração. O ProSBC oferece vários caminhos para começar.

ProSBC Lab

O ProSBC Lab é uma licença gratuita e permanente de 3 sessões para uso em laboratório e testes. É autoatendimento e leva aproximadamente 20 minutos para configurar. Você pode configurar a assinatura e verificação STIR/SHAKEN em ambiente de laboratório antes de migrar para produção.

Teste gratuito de 30 dias

O teste gratuito de 30 dias do ProSBC oferece 500 sessões simultâneas para avaliação em produção. Se sua implementação STIR/SHAKEN precisa de testes em escala antes de entrar em operação, o teste cobre isso.

Serviço gerenciado

O ProSBC Managed Service está disponível para provedores que desejam que a TelcoBridges cuide da configuração, monitoramento e gerenciamento contínuo da conformidade STIR/SHAKEN. O serviço gerenciado pode ser implantado na sua própria infraestrutura (AWS, Azure, VMware, KVM, on-premises) ou hospedado pela TelcoBridges. Sua organização mantém acesso total.

Para provedores que já operam um SBC com integração STIR/SHAKEN proprietária e buscam mais flexibilidade, ou para aqueles implantando STIR/SHAKEN pela primeira vez sob pressão regulatória, a combinação de controle configurável de atestação, seleção aberta de parceiros e redundância integrada é o que faz essa abordagem funcionar.