Níveis de atestação STIR/SHAKEN explicados: A, B e C

O framework STIR/SHAKEN atribui um de três níveis de atestação a cada chamada assinada: A (Completa), B (Parcial) ou C (Gateway). Essas três letras são debatidas em fóruns do setor, mal interpretadas por engenheiros de operações e silenciosamente atribuídas incorretamente por provedores que nunca precisaram pensar nelas até que uma operadora upstream rebaixou seu tráfego de A para C. As letras parecem simples. Os critérios, as consequências e a forma como elas trafegam pelas redes downstream não são.

Este artigo é uma referência. Ele explica o que cada nível realmente significa conforme o padrão ATIS-1000074, onde o nível existe no fio, quem atribui o quê em cada cenário, como uma atestação recebida se comporta downstream, e os erros comuns de atestação que silenciosamente prejudicam a completação de chamadas. Se você precisa do manual operacional para mover seu tráfego para o nível A, o Guia de Atestação Nível A cobre isso. Se você precisa do passo a passo de configuração do SBC, o Guia de Implementação cobre isso. Este artigo é para a pergunta que está por trás de ambos: o que cada nível significa, e o que um provedor de origem realmente declara quando assina em A, B ou C?

O que atestação realmente é (e três coisas que ela não é)

Antes de percorrer os três níveis, é útil esclarecer o que atestação realmente representa. A palavra é usada de forma imprecisa, e esse uso impreciso é a causa da maior parte da confusão.

Atestação é uma autodeclaração do provedor de origem. Quando seu SBC assina uma chamada de saída, o certificado do seu provedor é o que cria a assinatura, e seu provedor escolhe a letra que vai no claim attest. Ninguém mais verifica se você escolheu corretamente no momento da assinatura. O nível que você marca é sua declaração sobre seu conhecimento da chamada.

Atestação não é uma verificação. Uma chamada nível A foi assinada pelo provedor de origem, não validada por um terceiro independente. A verificação acontece depois, no lado de terminação, e a verificação apenas confirma que a assinatura é criptograficamente válida e que a cadeia de certificados é confiável. Ela não questiona a decisão de atestação do provedor de origem. Se um provedor assina uma chamada no nível A quando não tinha base para fazê-lo, a verificação ainda passará. A responsabilidade fica com o provedor de origem, aplicada pela supervisão da FCC e não pela validação criptográfica.

Atestação não é uma pontuação de spam. Analytics engines (os sistemas que exibem “Scam Likely” ou “Spam Risk” no telefone do destinatário) consomem a atestação como uma entrada, mas a combinam com dados de padrão de chamadas, histórico de reputação, idade do bloco de números e dezenas de outros sinais. Uma chamada assinada no nível A ainda pode ser marcada por um analytics engine se o número de origem tiver uma reputação ruim. Uma chamada assinada no nível C ainda pode completar normalmente se a política da operadora de recebimento for permissiva. O nível é um sinal em uma decisão multissinal.

Atestação não reside no cabeçalho SIP From ou no PAI. O nível é transportado dentro de um token JSON assinado (o PASSporT) dentro do cabeçalho SIP Identity. Os cabeçalhos From e P-Asserted-Identity ainda são onde o número chamador aparece, mas são não assinados e trivialmente falsificáveis. O objetivo do STIR/SHAKEN é vincular o número chamador e o nível de atestação criptograficamente para que não possam ser editados em trânsito. Se sua equipe de engenharia está depurando um problema de atestação olhando o cabeçalho From, está olhando no lugar errado.

Onde o nível reside: o claim attest dentro do PASSporT

O nível de atestação é um campo dentro do PASSporT, o token assinado no coração de toda chamada assinada por STIR/SHAKEN. O PASSporT é um JSON Web Token (JWT) que contém cinco claims principais definidos pelo ATIS-1000074:

O payload decodificado de um PASSporT real se parece aproximadamente com isto:

{
  "attest": "A",
  "dest": { "tn": ["14165550100"] },
  "iat": 1748964123,
  "orig": { "tn": "14165550199" },
  "origid": "ab37e29c-4c84-4f6e-bb50-1f9f8e2dc4ad"
}

O token completo é assinado com a chave privada do provedor de origem, codificado como JWT e colocado dentro do cabeçalho SIP Identity no INVITE de saída. As redes downstream leem o cabeçalho Identity, decodificam o PASSporT e agem com base no campo attest. Qualquer que seja o caractere único que o provedor colocou ali, é a atestação que toda a cadeia downstream vê.

Os três níveis de atestação conforme ATIS-1000074

O padrão publicado define três níveis discretos. Cada um responde a duas perguntas: o provedor sabe quem é a parte chamadora, e o provedor sabe que a parte chamadora está autorizada a usar o número chamador? A combinação das respostas determina o nível.

A (Atestação Completa)

Os critérios são rigorosos. O nível A se aplica quando o provedor de origem autenticou a parte chamadora, tem um relacionamento direto com essa parte e verificou que a parte está autorizada a usar o número chamador apresentado no identificador de chamadas. Todas as três condições devem ser verdadeiras. Um relacionamento direto com o cliente sem autorização de número não é nível A. Autorização de número sem identidade autenticada não é nível A.

Na prática, o nível A é o patamar que um provedor de voz de varejo pode atingir para seus próprios assinantes, que um fornecedor de IP-PBX pode atingir para os DIDs que atribuiu, e que um provedor de serviços gerenciados pode atingir para os números verificados de seus clientes gerenciados. É o patamar que uma operadora wholesale que transporta tráfego de trânsito não pode atingir para tráfego que não se originou em sua rede.

B (Atestação Parcial)

Os critérios são mais flexíveis. O nível B se aplica quando o provedor sabe por onde a chamada entrou em sua rede (veio de um tronco ou peer conhecido e autenticado), mas não verificou independentemente que a parte chamadora específica está autorizada a usar o número chamador específico. O provedor está atestando o tronco, não a vinculação número-chamador.

Este é o nível que uma operadora wholesale atribui ao tráfego de um revendedor conhecido cujos registros de autorização de cliente final a operadora não pode ver. A operadora conhece o revendedor. A operadora não pode confirmar independentemente que o revendedor realizou KYC e verificações de autorização de número em cada chamada. O nível B é a resposta honesta para esse cenário.

C (Atestação de Gateway)

Os critérios são mínimos. O nível C se aplica quando o provedor está atuando como gateway para tráfego originado fora de seu domínio de confiança. O provedor pode identificar o ponto onde a chamada entrou em sua rede, mas não pode autenticar a parte chamadora original nem verificar a autorização para o número chamador.

Este é o nível que se aplica em gateways PSTN-para-IP, em interconexões internacionais onde o provedor upstream não autentica seus usuários, e em alguns casos em provedores de varejo que recebem tráfego de um tenant cujos registros de clientes não mantêm. O nível C representa o nível preciso para uma fonte não confiável honestamente descrita, e tratá-lo como um modo de falha é interpretar mal a intenção do padrão.

Os três níveis lado a lado

Reduzidos às duas perguntas que cada nível responde:

A diferença deliberada entre A e B é a verificação da autorização de número. A diferença entre B e C é a verificação do tronco ou peer em si. Dois obstáculos distintos, três níveis distintos.

Cenários práticos: quem deve atribuir o quê

O nível honesto para uma determinada chamada depende do relacionamento do provedor com o originador. Os cenários a seguir são representativos dos tipos de chamada que chegam a um Controlador de Borda de Sessão (SBC) típico em produção.

Cenário 1: um provedor VoIP de varejo assinando tráfego de assinantes

Um provedor VoIP residencial recebe uma chamada de saída de um assinante cuja identidade foi verificada no cadastro, em um DID atribuído de seu próprio inventário. O provedor sabe quem é o chamador. Sabe que o número é dele para atribuir. Nível A é a atestação correta.

Cenário 2: um MSP entregando Microsoft Teams Direct Routing

Um provedor de serviços gerenciados hospeda Microsoft Teams Direct Routing para um cliente cujo tenant ele gerencia, em números portados com LOAs documentadas. O MSP autentica o cliente no nível do tronco do SBC e mantém os registros de portabilidade. Nível A é a atestação correta para esses números. Se o mesmo MSP termina chamadas de uma faixa de numeração que o cliente trouxe sem documentação de portabilidade, essas chamadas caem para nível B até que a autorização seja confirmada.

Cenário 3: uma operadora wholesale transportando tráfego de revendedores

Uma operadora wholesale recebe tráfego de um revendedor downstream que tem seus próprios relacionamentos com clientes finais. A operadora autenticou o tronco do revendedor e conhece o revendedor, mas não mantém registros KYC dos clientes finais do revendedor e não pode confirmar autorizações de números individuais. Nível B é a resposta honesta. O revendedor, se assinar a mesma chamada upstream da operadora com seu próprio certificado, pode legitimamente marcá-la como A.

Cenário 4: um gateway IP recebendo tráfego internacional

Um provedor de gateway termina tráfego chegando por uma interconexão internacional de uma operadora estrangeira que não implementa STIR/SHAKEN e não autentica seus usuários downstream. O provedor de gateway pode confirmar que o tronco veio da operadora estrangeira, mas nada mais. Nível C é a atestação correta para o tráfego que chega nessa interconexão.

Cenário 5: um BPO de contact center originando campanhas de saída

Um BPO de contact center origina chamadas de saída em nome de múltiplos clientes finais, usando DIDs atribuídos por um provedor de voz upstream. O BPO autentica seus agentes e sabe a qual campanha e cliente cada chamada pertence. A questão da atestação é se o provedor de voz upstream (aquele cujo certificado assina as chamadas) considera o BPO um cliente autenticado com autorização de número verificada. Se sim, o upstream assina o tráfego de saída no nível A. Se o upstream não pode confirmar a autorização do BPO para o número específico apresentado, o nível cai para B.

Cenário 6: um PBX empresarial chamando por um tronco de operadora

Um cliente empresarial com seu próprio PBX realiza chamadas de saída por um tronco SIP fornecido por uma operadora. A operadora autenticou o tronco para a empresa e tem a documentação de portabilidade dos números da empresa. Nível A é apropriado para chamadas realizadas a partir de números autorizados na faixa atribuída. Chamadas realizadas com identificador de chamadas fora da faixa atribuída caem para B ou falham na autorização e não devem ser assinadas em A.

Como uma atestação assinada chega às redes downstream

O nível de atestação é definido uma vez, na assinatura, pelo provedor de origem. A partir desse momento, ele viaja por cada hop downstream dentro do PASSporT assinado. O PASSporT é assinado usando o certificado STIR/SHAKEN do provedor de origem, então qualquer adulteração no campo attest invalida a assinatura.

A jornada downstream funciona assim:

1. O SBC de origem solicita a assinatura ao STI-AS, que cria o PASSporT com o valor attest escolhido, assina-o com o certificado do provedor e retorna o cabeçalho Identity.
2. O SBC de origem injeta o cabeçalho Identity no SIP INVITE de saída e encaminha a chamada para o próximo hop.
3. Cada operadora intermediária encaminha o SIP INVITE adiante, preservando o cabeçalho Identity. Elas não podem legitimamente modificar o campo attest sem quebrar a assinatura.
4. O SBC de terminação recebe o INVITE, extrai o cabeçalho Identity e o encaminha para o serviço de verificação (STI-VS).
5. O STI-VS valida a assinatura contra o certificado público do provedor de origem, verifica a cadeia de certificados até a Autoridade Certificadora STIR/SHAKEN e confirma que o token está atualizado e não foi modificado. Ele retorna o resultado da verificação junto com o valor attest original (tipicamente via o parâmetro verstat no cabeçalho P-Asserted-Identity).
6. O mecanismo de políticas do provedor de terminação lê o verstat e o attest verificado, então aplica decisões de roteamento: rotear normalmente, sinalizar, fazer triagem adicional ou rejeitar.
7. Se um analytics engine estiver posicionado na frente do aparelho de destino (uma configuração comum para operadoras móveis nos EUA), ele consome a atestação verificada como uma entrada em sua pontuação “Scam Likely” ou “Spam Risk”.

O cabeçalho Identity é o único artefato no fio que transporta a atestação. Se ele estiver ausente, as redes downstream tratam a chamada como não assinada, o que é funcionalmente semelhante ao nível C para fins de analytics. Se ele estiver presente mas a verificação falhar, as redes downstream sabem que a chamada foi adulterada ou assinada por um certificado não confiável, o que tipicamente é pior do que nenhuma assinatura.

Lendo uma atestação recebida: o que um A realmente lhe diz

Quando seu SBC verifica uma chamada de entrada e lê attest=A, esse único caractere está fazendo uma declaração específica. Traduzido em linguagem simples: o provedor de origem declara que autenticou a parte chamadora e verificou que a parte chamadora está autorizada a usar o número chamador.

Essa é a declaração. A verificação confirma apenas duas coisas: a assinatura é válida e o certificado remonta a uma Autoridade Certificadora confiável. Ela não confirma que os procedimentos KYC do provedor de origem são sólidos. Não confirma que o provedor de origem verificou a autorização de número corretamente. Não confirma que a parte chamadora é realmente quem diz ser. Todas essas são promessas do provedor de origem, respaldadas por responsabilidade regulatória da FCC e não por prova criptográfica.

A consequência prática é que um A de uma operadora de varejo norte-americana respeitável é um sinal muito mais forte do que um A de um provedor desconhecido. O conteúdo criptográfico é idêntico. O respaldo reputacional por trás dele não é. É por isso que algumas operadoras de terminação mantêm suas próprias listas de reputação de provedores junto com os níveis de atestação, e por que analytics engines ponderam a atestação como uma entrada entre muitas.

A mesma lógica se aplica a B e C. Uma chamada nível B recebida traz um reconhecimento explícito do provedor de origem de que ele pôde atestar o tronco, mas não a autorização específica do número. Uma chamada nível C recebida traz um reconhecimento explícito de que o provedor é um gateway sem conhecimento direto do chamador. O valor informativo da atestação vem da honestidade sobre o relacionamento com a chamada, e essa honestidade é o que as redes downstream recompensam ou punem por meio de política de roteamento.

Erros comuns de atestação e o que revelam

Erros de atestação acontecem em ambas as direções: sobre-atestação (declarar um nível mais alto do que os critérios suportam) e sub-atestação (declarar um nível mais baixo do que os critérios suportam). Cada um revela algo útil sobre o provedor de origem.

Sobre-atestar tráfego C como A

Um provedor que assina tráfego de gateway no nível A está fazendo uma declaração que não pode defender. A FCC tem aumentado a aplicação de medidas contra atestação imprecisa, e analytics engines downstream que detectam um padrão de chamadas nível A de um provedor que consistentemente se comporta como gateway irão reduzir o peso das atestações futuras desse provedor. A sobre-atestação tende a ser uma estratégia de curta duração. Ela ou convida escrutínio regulatório ou é neutralizada por sistemas de reputação.

Sub-atestar tráfego A como C

Este é o padrão que provocou a onda de auto-atestação em 2024 e 2025. Uma operadora wholesale upstream cujos registros KYC e de autorização de número dos revendedores downstream estão incompletos pode decidir que B ou C é o único nível honesto para todo o tráfego de revendedores, independentemente de quanto KYC o próprio revendedor tenha feito. Os clientes do revendedor então veem suas chamadas sinalizadas ou bloqueadas, mesmo que as chamadas se qualificassem para A se assinadas diretamente pelo revendedor. A solução, coberta no Guia de Atestação Nível A, é o revendedor obter seu próprio certificado e assinar seu próprio tráfego no nível que pode defender.

Misturar níveis no mesmo tronco

Um único SBC frequentemente lida com tráfego misto: tráfego de assinantes de varejo que se qualifica para A, tráfego wholesale que se qualifica para B e tráfego de gateway que se qualifica para C. A decisão de atestação é por chamada, não por tronco. Um SBC que atribui um nível genérico a tudo em um tronco vai sobre-atestar o tráfego de gateway ou sub-atestar o tráfego de varejo. Ambos estão errados. A capacidade de atestação por chamada de um SBC programável é o que permite que a mesma instância lide com os três honestamente.

Assinar com certificado de terceiros

Isso não é mais uma escolha de atestação; é uma violação de conformidade. A regra de certificado próprio da FCC exige que todo provedor com obrigação STIR/SHAKEN assine com seu próprio certificado. Uma chamada assinada no nível A usando o certificado de um upstream não está em conformidade, independentemente de quão precisa a atestação em si seja. Redes downstream que detectam esse padrão cada vez mais tratam-no da mesma forma que nenhuma assinatura.

Como o tratamento downstream varia por nível

O tratamento downstream é política, não protocolo. Provedores de terminação e analytics engines decidem o que fazer com uma atestação verificada, e essas decisões variam por operadora, por dispositivo do destinatário e por padrão de chamada. Os padrões abaixo são representativos do que operadoras móveis norte-americanas e grandes provedores de terminação fazem hoje, não uma garantia.

Tratamento nível A

Chamadas assinadas no nível A por um provedor de origem respeitável tipicamente chegam ao destinatário sem rótulo de analytics engine e com um identificador de chamadas limpo. Se o número de origem tiver uma reputação ruim (histórico de reclamações, reciclagem recente de número, padrões de discagem em massa), a chamada ainda pode ser rotulada. Atestação é um sinal positivo, não uma substituição.

Tratamento nível B

Chamadas nível B geralmente chegam ao destinatário, mas podem receber um rótulo neutro (“Caller Verified” em vez do negativo “Scam Likely”), dependendo das convenções de interface da operadora de terminação. Algumas operadoras não diferenciam B e A em sua exibição ao usuário. Outras tratam B como inelegível para qualquer rótulo positivo.

Tratamento nível C

Chamadas nível C recebem o tratamento menos favorável. Elas têm maior probabilidade de serem rotuladas como “Scam Likely” ou “Spam Risk”, e um número crescente de operadoras de terminação direciona tráfego nível C para pipelines de triagem mais agressivos. Algumas operadoras rejeitam chamadas nível C diretamente sob condições específicas, particularmente para padrões de tráfego que se assemelham a robocalling.

Chamadas não assinadas ou com verificação falha

Chamadas que chegam sem cabeçalho Identity (não assinadas) ou com um cabeçalho Identity inválido (verificação falha) são tipicamente tratadas pior do que tráfego assinado no nível C. O nível C pelo menos representa uma declaração honesta de gateway; tráfego não assinado ou inválido representa um provedor não conforme ou adulteração ativa, e as redes downstream cada vez mais direcionam ambos para o mesmo bucket de triagem agressiva.

Referência rápida: qual nível atribuir em cenários comuns

A tabela abaixo resume a atestação honesta para cada função comum de provedor e tipo de tráfego. É um ponto de partida, não um substituto para julgamento caso a caso.

A lógica de decisão é consistente em todas as linhas: verificação de identidade produz sim ou não, verificação de autorização produz sim ou não, e a combinação determina o nível. Dois sins resultam em A, um sim resulta em B, zero sins resultam em C.

O papel do SBC na atribuição do nível correto

A decisão de atestação é do provedor, mas o SBC é onde a decisão é operacionalizada. Toda chamada de saída assinada passa pelo fluxo de assinatura do SBC, onde os metadados da chamada são empacotados em uma requisição de assinatura, enviados ao serviço de assinatura STIR/SHAKEN e retornados como um cabeçalho Identity. O nível que é marcado depende do que o SBC diz ao serviço de assinatura para declarar.

Uma configuração estática de atestação por tronco não consegue acertar quando o mesmo tronco transporta tráfego misto. Lógica de atestação por chamada no mecanismo de roteamento do SBC é o que permite que a mesma instância assine tráfego de assinantes de varejo em A, trânsito wholesale em B e tráfego de gateway em C, chamada por chamada, usando o mesmo certificado. ProSBC implementa isso por meio de seu mecanismo de roteamento Ruby configurável, onde a decisão de atestação pode incorporar qualquer dado que o script de roteamento possa acessar: o registro do número chamador no banco de dados de autorização de números, o tronco por onde chegou, o status KYC do cliente, o horário do dia ou qualquer outra entrada que o provedor escolha considerar.

Os detalhes de configuração para a integração do ProSBC baseada em SIP com TransNexus ClearIP e Neustar (o padrão de implantação em produção para a base de clientes da empresa) são cobertos no Guia de Implementação. O ponto relevante para atestação especificamente é que o nível é uma decisão por chamada que o mecanismo de roteamento toma, não um parâmetro global definido uma vez no SBC.

Perguntas frequentes