Integração de Roteamento de Chamadas via REST API no SBC: Arquitetura, Casos de Uso e Implementação

Tabelas de rotas estáticas funcionavam quando as redes de voz eram simples: um punhado de operadoras, um conjunto previsível de números e uma lógica de roteamento que mudava uma vez por trimestre. Essa não é a realidade da maioria dos provedores de serviços e empresas hoje. Redes de voz modernas roteiam tráfego por múltiplas operadoras, aplicam regras de detecção de fraude em tempo real, consultam bancos de dados de portabilidade numérica em cada chamada e se integram com sistemas de faturamento e CRM que existem totalmente fora do Controlador de Borda de Sessão (SBC).

É aqui que a integração de roteamento de chamadas via REST API faz a diferença. Em vez de depender de tabelas de rotas configuradas manualmente, o SBC consulta sistemas externos durante a configuração da chamada, recebe instruções de roteamento como dados estruturados e as aplica antes de encaminhar a chamada. O resultado é uma rede de voz onde as decisões de roteamento são tão dinâmicas quanto os sistemas que as alimentam.

Este guia explica como o roteamento REST API no SBC funciona, a arquitetura por trás dele, os problemas reais que ele resolve e o que avaliar ao escolher um SBC para roteamento orientado por API.

O Que É Roteamento de Chamadas via REST API no SBC?

Em sua essência, o roteamento de chamadas via REST API no SBC é um mecanismo pelo qual o Controlador de Borda de Sessão envia uma requisição HTTP ou HTTPS para um mecanismo de roteamento externo durante a configuração da chamada. O sistema externo avalia os parâmetros da chamada, aplica a lógica de negócios que contém e retorna uma resposta estruturada (geralmente JSON) informando ao SBC como rotear a chamada.

Isso é fundamentalmente diferente das duas abordagens tradicionais de roteamento que a maioria dos SBCs oferece. O roteamento estático depende de tabelas de rotas configuradas manualmente: “chamadas para o prefixo 1-212 vão para a Operadora A, chamadas para o prefixo 1-310 vão para a Operadora B.” O roteamento baseado em padrões adiciona correspondência por regex, permitindo regras mais flexíveis, mas a lógica ainda reside na configuração do SBC e requer atualizações manuais quando algo muda.

O roteamento via REST API transfere a tomada de decisão para fora do SBC. O SBC continua tratando a sinalização SIP, o controle de mídia e a segurança para os quais foi projetado. Porém, a pergunta “para onde esta chamada deve ir?” é respondida por um sistema externo que pode acessar dados em tempo real que o SBC não possui: taxas atuais de operadoras, registros de portabilidade numérica, scores de risco de fraude, status de conta do cliente ou qualquer outra fonte de dados acessível via HTTP.

O motivo pelo qual isso funciona bem em um SBC, ao contrário de um SIP proxy, é a arquitetura de Agente de Usuário Back-to-Back (B2BUA). Como o SBC termina completamente a sessão SIP de entrada e re-origina uma nova em direção ao destino, existe um ponto de inserção natural entre os dois segmentos onde o SBC pode pausar, consultar um sistema externo, receber uma resposta e aplicar as instruções de roteamento antes de completar o segmento de saída. Um SIP proxy não possui essa capacidade porque encaminha mensagens sem terminar nenhuma das sessões.

Por Que Tabelas de Rotas Estáticas Não São Suficientes

Tabelas de rotas estáticas atingem seus limites de maneiras previsíveis, e a maioria dos provedores de serviços encontra pelo menos dois ou três desses problemas simultaneamente.

Escala

Quando você roteia chamadas para 200.000 ou mais números de Discagem Direta a Ramal (DID), manter esses mapeamentos na configuração local de um SBC típico se torna impraticável. Principalmente se os dados mudam com frequência, os arquivos de configuração crescem de forma descontrolada e cada atualização requer um reload ou, pior, uma janela de manutenção. Uma API de roteamento externa permite manter os mapeamentos DID-para-rota em um banco de dados dedicado e consultá-lo a cada chamada.

Atualidade dos dados

Dados de portabilidade numérica, taxas de operadoras e inteligência contra fraude mudam constantemente. Um número que foi roteado corretamente para a Operadora A ontem pode ter sido portado para a Operadora B hoje de manhã. Um mecanismo de scoring de fraude pode ter sinalizado um padrão de número chamador na última hora, algo que sua tabela de rotas estática desconhece. O roteamento baseado em API consulta a fonte autoritativa a cada chamada, garantindo que o SBC sempre atue com dados atualizados.

Integração

A lógica de negócios que deveria informar as decisões de roteamento frequentemente reside em sistemas com os quais o SBC não possui conexão nativa: plataformas de faturamento que determinam qual operadora oferece a menor tarifa para um dado destino, sistemas CRM que identificam chamadores de alto valor, mecanismos de detecção de fraude que pontuam cada chamada em tempo real, ou sistemas de conformidade que aplicam regras regulatórias como atestação STIR/SHAKEN. REST APIs são a forma padrão pela qual esses sistemas se comunicam, e um SBC que suporta consultas HTTP durante a configuração da chamada pode participar desse ecossistema.

Multi-tenancy

Provedores de serviços gerenciados que operam um único SBC para 50 ou mais clientes precisam de lógica de roteamento que varie por tenant. O Tenant A roteia pela Operadora X com assinatura STIR/SHAKEN. O Tenant B roteia pela Operadora Y sem ela. O Tenant C precisa de roteamento pelo menor custo entre três operadoras. Tabelas de rotas estáticas podem tecnicamente lidar com isso, mas a complexidade de configuração escala linearmente com o número de tenants, e um único erro de configuração pode desviar o tráfego de um cliente inteiro. Um mecanismo de roteamento externo lida com a lógica por tenant de forma nativa e mantém a configuração do SBC limpa.

Como Funciona o Roteamento de Chamadas via REST API: Arquitetura

O fluxo de chamada para roteamento integrado com API segue um padrão consistente independentemente da implementação específica do SBC. Veja como funciona, passo a passo.

Passo 1: SIP INVITE de entrada chega

Uma chamada chega ao SBC em um de seus Pontos de Acesso de Rede (NAPs). O SBC extrai os parâmetros da chamada: número chamador, número chamado, NAP de origem ou grupo de troncos, headers SIP e quaisquer outros metadados disponíveis no INVITE.

Passo 2: Script de roteamento dispara uma consulta HTTP

O mecanismo de roteamento do SBC, em vez de fazer correspondência imediatamente contra uma tabela de rotas local, dispara uma requisição HTTP para um sistema externo. A requisição inclui os parâmetros de chamada que o sistema externo precisa para tomar uma decisão de roteamento. Dependendo do padrão de integração, pode ser uma simples requisição GET com o número chamado no caminho da URL, ou uma requisição POST com um payload JSON completo contendo o NAP de origem, número chamador, número chamado e qualquer contexto adicional.

Passo 3: Sistema externo processa a requisição

O mecanismo de roteamento externo, serviço de scoring de fraude, banco de dados LNP ou aplicação de negócios recebe a requisição e aplica sua lógica. Isso pode significar consultar o número chamado em um banco de dados de portabilidade, calcular um score de risco de fraude, consultar tabelas de tarifas de operadoras para roteamento pelo menor custo, ou verificar um CRM para o status da conta do chamador.

Passo 4: Sistema externo retorna uma resposta JSON

A resposta indica ao SBC o que fazer. No caso mais simples, fornece um número chamado remapeado (por exemplo, após uma consulta LNP). Em integrações mais complexas, retorna uma lista priorizada de rotas de destino, cada uma com nome de NAP, valor de prioridade e peso para balanceamento de carga. Também pode incluir flags como NPDI (Indicador de Banco de Dados de Portabilidade Numérica) para sinalização downstream.

Passo 5: SBC aplica as instruções de roteamento

O mecanismo de roteamento recebe a resposta, a valida e aplica as instruções. Se a resposta fornece múltiplas rotas, o SBC as ordena por prioridade e tenta cada uma em sequência até que uma seja bem-sucedida. Se o sistema externo estiver inacessível ou retornar um erro, o SBC recorre às suas rotas estáticas configuradas localmente.

Dois Padrões de Integração

Na prática, o roteamento REST API no SBC se enquadra em dois padrões comuns.

Consulta Simples (requisição GET)

O SBC envia o número chamado para um sistema externo e recebe um número chamador ou chamado remapeado em retorno. Esse padrão é típico para serviços de tradução de números, consultas de portabilidade numérica móvel (MNP) e consultas simples a bancos de dados. A requisição HTTP é leve, a resposta é um único objeto JSON com um ou dois campos, e a latência é mínima.

Por exemplo, o SBC envia uma requisição GET para https://routing-engine.example.com/v1/lookup/14155551234 e recebe:

{
  "callerNumber": "14155551234",
  "destinationNumber": "12125559876"
}

O SBC substitui o número chamado pelo valor da resposta e prossegue com a correspondência normal de rotas.

Composição Dinâmica de Rotas (requisição POST)

O SBC envia o contexto completo da chamada para um mecanismo de roteamento externo e recebe um conjunto de rotas de destino. Esse padrão é usado para roteamento pelo menor custo, seleção dinâmica de operadoras, balanceamento de carga e qualquer cenário em que o sistema externo precisa avaliar múltiplos fatores para determinar o melhor caminho.

O SBC envia uma requisição POST com o NAP de origem, número chamador e número chamado:

{
  "SRCNAP": "NAP_CARRIER_A",
  "SRCNUM": "14155551234",
  "DESTNUM": "442071234567"
}

O sistema externo responde com até quatro rotas priorizadas:

{
  "npdi": "yes",
  "ported_number": "442071234567",
  "route1": "NAP_UK_PRIMARY",
  "priority": 5,
  "weight": 100,
  "route2": "NAP_UK_SECONDARY",
  "priority": 6,
  "weight": 100,
  "route3": "NAP_UK_TERTIARY",
  "priority": 7,
  "weight": 50
}

O SBC cria rotas dinâmicas a partir dessa resposta, atribui os valores de prioridade e peso fornecidos, e as combina com quaisquer rotas estáticas já configuradas. A chamada tenta a rota de maior prioridade primeiro e faz failover para a próxima se essa rota estiver indisponível.

Timeout e Failover

As consultas REST API acontecem durante a configuração da chamada, então a latência importa. Um SBC bem projetado permite configurar o timeout por consulta de API, tipicamente entre 500 milissegundos e 2.500 milissegundos. Se o sistema externo não responder dentro do timeout configurado, o SBC deve ter um comportamento de fallback definido: rotear usando tabelas estáticas, rejeitar a chamada com um código de resposta SIP apropriado, ou aplicar uma rota padrão.

As melhores implementações também suportam endpoints de API primários e secundários. Se a URL primária falhar, o SBC automaticamente tenta a secundária antes de recorrer ao roteamento local. Essa redundância é essencial para ambientes de produção onde o mecanismo de roteamento externo é um ponto único de falha.

Casos de Uso Reais para Roteamento via API no SBC

O roteamento de chamadas via REST API não é uma capacidade teórica. Estes são os cenários de integração que provedores de serviços e empresas implantam em produção.

Detecção de Fraude e Scoring de Chamadas em Tempo Real

A fraude telefônica custa à indústria de telecomunicações bilhões de dólares por ano. Um SBC com roteamento via REST API pode consultar um mecanismo de detecção de fraude em cada chamada, receber um score de risco e rotear, bloquear ou redirecionar a chamada com base nesse score.

A integração funciona assim: o SBC envia o número chamador, número chamado e metadados da chamada para um serviço de scoring de fraude (como TransNexus ClearIP, SecureLogix ou YouMail) via HTTP. O serviço avalia a chamada contra sua inteligência de fraude, incluindo fontes conhecidas de robocalls, padrões de fraude telefônica, anomalias de velocidade de chamadas e bancos de dados de números falsificados, e retorna um score de risco. O script de roteamento do SBC age com base no score: chamadas de baixo risco são roteadas normalmente, chamadas de risco médio são roteadas com registro, e chamadas de alto risco são bloqueadas ou desviadas para uma fila de análise de fraude.

Esse não é um processo em lote ou uma análise posterior. Acontece durante a configuração da chamada, adicionando apenas algumas centenas de milissegundos de latência, e avalia cada chamada individualmente, não uma amostra.

Assinatura e Verificação STIR/SHAKEN

O mandato da FCC para STIR/SHAKEN exige que provedores de serviços assinem criptograficamente chamadas de saída com sua identidade, fornecendo à parte receptora uma atestação verificada de quem originou a chamada. O SBC desempenha um papel central nesse processo ao consultar um serviço externo de assinatura STIR/SHAKEN durante a configuração da chamada.

Quando uma chamada de saída passa pelo SBC, o script de roteamento envia uma requisição de assinatura via HTTP para o serviço de assinatura STIR/SHAKEN. A requisição inclui o número de origem (do header P-Asserted-Identity ou From), o número de destino e o nível de atestação (A para atestação completa, B para parcial, C para gateway). O serviço de assinatura gera um token PASSporT, o assina com o certificado do provedor e retorna o token em um Identity header que o SBC insere no SIP INVITE de saída.

Para confiabilidade em produção, a implementação suporta URLs primárias e secundárias de serviço de assinatura. Se o serviço de assinatura primário estiver inacessível após o timeout configurado e as tentativas de retry, o SBC anexa um header P-Identity-Bypass para indicar que a assinatura foi tentada mas estava indisponível, em vez de bloquear completamente a chamada. Esse mecanismo de failover garante que uma interrupção do serviço de assinatura não pare o tráfego legítimo de chamadas.

Consultas de Portabilidade Numérica (LNP/MNP)

Quando um cliente porta seu número telefônico de uma operadora para outra, as chamadas para esse número devem ser roteadas para a nova operadora, não para aquela originalmente atribuída ao bloco numérico. Bancos de dados de Portabilidade Numérica Local (LNP) rastreiam esses mapeamentos, e um SBC com roteamento via REST API pode consultá-los em tempo real.

Durante a configuração da chamada, o SBC envia o número chamado para um serviço de consulta LNP. O serviço retorna o Número de Roteamento Local (LRN), que identifica a operadora correta para o número portado. O SBC substitui o número chamado pelo LRN para fins de roteamento, garantindo que a chamada chegue ao destino correto. Para ambientes de sinalização SS7, o SBC também lida com o flag NPDI (Indicador de Banco de Dados de Portabilidade Numérica), que informa aos switches downstream que o número já foi consultado e não precisa de uma segunda consulta.

Essa consulta por chamada elimina a necessidade de manter uma cópia local dos dados de portabilidade numérica, que mudam milhares de vezes diariamente no plano de numeração norte-americano.

Seleção Dinâmica de Operadora e Roteamento pelo Menor Custo

Provedores de serviços com múltiplas interconexões de operadoras precisam rotear cada chamada pelo caminho mais econômico, mantendo a qualidade. Um mecanismo de roteamento externo pode avaliar taxas de operadoras em tempo real, taxas de atendimento-ocupação (ASR) e disponibilidade de troncos, e então instruir o SBC sobre a rota ideal.

O SBC envia os detalhes da chamada para o mecanismo de roteamento via requisição POST. O mecanismo retorna uma lista priorizada de NAPs de destino com pesos. O SBC cria rotas dinâmicas a partir dessa resposta e as tenta em ordem de prioridade. Se a operadora de maior prioridade rejeitar a chamada ou estiver indisponível, o SBC automaticamente faz failover para a próxima rota da lista.

Esse padrão é particularmente valioso para tráfego internacional, onde as tarifas de operadoras podem variar significativamente por destino e horário do dia, e onde ter quatro ou mais opções de operadora por rota garante altas taxas de completamento.

Integração com CRM e Sistemas de Negócios

Contact centers e empresas usam roteamento via API no SBC para conectar tráfego de voz com seus sistemas de negócios. O SBC consulta um CRM durante a configuração da chamada para identificar o chamador, determinar o status de sua conta e aplicar regras de roteamento conforme necessário: chamadores VIP são roteados para uma equipe dedicada de agentes, contas em atraso são roteadas para cobrança, e chamadores de suporte são roteados para a fila correspondente ao seu produto.

Essa integração também possibilita enriquecimento de metadados. O SBC pode anexar dados derivados do CRM aos headers SIP ou registros CDR, para que a plataforma receptora (contact center, PBX ou sistema de comunicações unificadas) tenha contexto sobre o chamador antes que o agente atenda.

Melhores Práticas de Implementação

Colocar o roteamento REST API do SBC em produção exige atenção a algumas áreas críticas além da integração básica.

Defina timeouts realistas

As consultas de API acontecem durante a configuração da chamada, e os chamadores percebem atrasos. Configure seu timeout HTTP entre 500 e 2.000 milissegundos para a maioria das integrações. Para scoring de fraude e assinatura STIR/SHAKEN, onde a consulta é obrigatória, você pode estender até 2.500 milissegundos com um mecanismo de fallback. Acima disso, há risco de atraso pós-discagem que degrada a experiência do chamador.

Incorpore redundância em cada integração

Configure endpoints de API primários e secundários para cada sistema externo. Se seu mecanismo de fraude roda em AWS us-east-1, o secundário deve estar em uma região ou provedor diferente. O caminho de fallback do SBC (roteamento estático, rota padrão ou rejeição da chamada) deve ser explicitamente definido e testado, não assumido.

Use o estágio de filtro correto

Um SBC bem projetado oferece múltiplos pontos de inserção no pipeline de roteamento. Filtros de pré-roteamento (before-filters) são o lugar certo para decisões que devem acontecer antes de qualquer correspondência de rotas: autenticação, scoring de fraude e validação do chamador. Filtros pós-correspondência (after-filters) são apropriados para modificar rotas depois que o SBC determinou seu conjunto inicial: seleção de operadora, dips LNP e reordenação baseada em tarifas. Filtros por rota (after-remap-filters) se aplicam a rotas individuais após o remapeamento de números: definir headers SIP específicos por operadora, ajustar preferências de codec ou aplicar regras de normalização específicas da operadora.

Valide cada resposta

Nunca confie cegamente na resposta do sistema externo. Verifique o código de status HTTP (qualquer coisa diferente de 200 deve acionar o comportamento de fallback), valide a estrutura JSON e confirme que os nomes de NAP ou destinos de rota retornados realmente existem na configuração do seu SBC. Um nome de NAP com erro de digitação em uma resposta de API vai silenciosamente perder chamadas.

Registre decisões de API nos CDRs

Cada decisão de roteamento orientada por API deve ser registrada nos Registros de Detalhe de Chamada (CDR) do SBC. Isso não é opcional. Quando um cliente contesta uma cobrança, quando você precisa resolver o problema de uma chamada roteada incorretamente, ou quando deseja auditar a eficácia do seu mecanismo de fraude, o CDR é onde você consulta. Inclua a resposta do sistema externo (ou pelo menos os campos-chave) como campos customizados do CDR.

Mantenha payloads pequenos e conexões persistentes

A requisição e resposta HTTP devem conter apenas os campos necessários para a decisão de roteamento. Payloads grandes aumentam o tempo de serialização e o tempo de transferência pela rede, ambos adicionando atraso à configuração da chamada. Use conexões HTTP persistentes (HTTP keep-alive) quando seu SBC as suportar, para eliminar a sobrecarga do handshake TCP em consultas repetidas.

O Que Avaliar em um SBC com Roteamento via REST API

Nem todos os SBCs suportam roteamento via REST API e, entre os que suportam, a profundidade da implementação varia significativamente. Veja o que separa um hook de API básico de um framework de integração pronto para produção.

Cadeia de filtros configurável com múltiplos pontos de inserção

Você precisa da capacidade de disparar consultas de API em diferentes estágios do processo de roteamento: antes da correspondência (para autenticação e verificações de fraude), após a correspondência (para modificação de rotas e LNP) e após o remapeamento (para manipulação de headers por rota). Um SBC que oferece apenas um único hook de “roteamento externo” limita suas opções arquiteturais.

Suporte para métodos GET e POST

Consultas simples funcionam com GET. Composição dinâmica de rotas requer POST com corpo JSON. Seu SBC deve suportar ambos nativamente, sem soluções alternativas.

Parsing de resposta JSON com extração por campo

O SBC deve ser capaz de fazer parsing de uma resposta JSON estruturada e mapear campos individuais para parâmetros de roteamento (NAP de destino, número chamado, número chamador, prioridade, peso). Se o SBC trata a resposta inteira como um único valor opaco, você perde a capacidade de construir lógica de roteamento sofisticada a partir de dados externos.

Suporte a respostas com múltiplas rotas

O sistema externo deve poder retornar múltiplas rotas candidatas em uma única resposta, com valores de prioridade e peso para cada uma. O SBC deve criar rotas dinâmicas a partir desses candidatos e fazer failover através deles automaticamente. Respostas com destino único forçam o sistema externo a tomar a decisão de failover, o que adiciona latência e complexidade.

Timeout configurável com fallback explícito

Você deve poder definir o timeout da API por integração (não apenas um valor global), definir o comportamento de fallback quando o timeout é excedido e configurar endpoints de API primários/secundários para redundância.

HTTPS/TLS para transporte de API

As consultas de API carregam metadados de chamada (números chamadores, números chamados, informações de origem), que são dados sensíveis. O SBC deve suportar HTTPS para todas as consultas de API. Isso é inegociável em produção.

Integração de CDR para decisões de roteamento via API

O SBC deve registrar decisões de roteamento orientadas por API em sua saída de CDR, para que você possa auditar, resolver problemas e reconciliar faturamento.

Como o ProSBC Lida com Roteamento de Chamadas via REST API

O ProSBC, o SBC baseado em software da TelcoBridges, implementa roteamento de chamadas via REST API por meio de um mecanismo configurável de scripts de roteamento em Ruby com uma arquitetura de cadeia de filtros modular.

A base é a classe BaseRouting, que todos os scripts de roteamento estendem. Ela fornece um processo de roteamento estruturado em 11 passos: before-filters, correspondência de rotas, lookups de usuários registrados/DNS, ordenação de rotas, after-filters, remapeamento por rota e after-remap filters. Consultas HTTP podem ser disparadas em qualquer estágio de filtro por meio de uma RoutingException que pausa o pipeline de roteamento, executa a consulta HTTP e retoma o pipeline com os dados da resposta disponíveis para o script.

O mecanismo de roteamento do ProSBC expõe mais de 100 parâmetros de chamada por chamada, incluindo números chamador e chamado, NAP de origem, headers SIP, informações de codec e detalhes de transporte. Qualquer um desses parâmetros pode ser incluído em uma consulta de API para um sistema externo.

Dois padrões de integração HTTP estão disponíveis prontos para uso. Um módulo de consulta baseado em GET envia o número chamado para um sistema externo e aplica os mapeamentos de número retornados. Um módulo de roteamento dinâmico baseado em POST envia o contexto completo da chamada (NAP de origem, número chamador, número chamado) e recebe até quatro rotas de destino priorizadas com valores de peso. Ambos suportam timeouts configuráveis, transporte HTTPS e headers HTTP customizados.

Para integrações comuns, o ProSBC inclui módulos pré-construídos que lidam com os detalhes de protocolo:

• Assinatura, atestação e verificação STIR/SHAKEN com URLs de serviço de assinatura primárias/secundárias e fallback via P-Identity-Bypass.
• Integração TransNexus ClearIP para roteamento pelo menor custo, scoring de fraude e STIR/SHAKEN.
• Integração SecureLogix para scoring de risco de spam em tempo real com aplicação de estratégia de roteamento.
• Integração YouMail para avaliação de risco de spam e robocall.
• Integração Neustar para autenticação, verificação STIR/SHAKEN e tratamento de redirecionamento SIP 302.

Para integrações que não correspondem a um módulo pré-construído, o mecanismo de scripting em Ruby permite que você escreva lógica customizada que consulta qualquer sistema acessível via HTTP, faz parsing da resposta e aplica as decisões de roteamento conforme necessário. Isso não é programação de propósito geral; é uma camada de scripting configurável projetada especificamente para decisões de roteamento de chamadas.

O ProSBC também fornece uma API de gerenciamento RESTful para configuração remota, monitoramento de status e recuperação de CDRs, permitindo que sistemas externos tanto informem quanto gerenciem o SBC.

Perguntas Frequentes

Conclusão

O roteamento de chamadas via REST API transforma o SBC de um comutador de tráfego estático em um mecanismo inteligente de decisão de roteamento que participa do ecossistema mais amplo da sua rede de voz. À medida que as redes de voz se tornam mais complexas (mais operadoras, mais tenants, mais requisitos regulatórios e mais pontos de integração), a capacidade do SBC de consultar sistemas externos em tempo real é o que mantém as decisões de roteamento precisas, atualizadas e alinhadas com a lógica de negócios que existe fora do SBC.