Integração de SBC com Bandwidth.com: como conectar um Controlador de Borda de Sessão aos SIP Trunks da Bandwidth

Bandwidth.com é um dos maiores provedores de SIP Trunk (tronco de voz sobre IP) e CPaaS da América do Norte. Se você é um Provedor de Serviços Gerenciados (MSP), central de atendimento, Provedor de Serviços de Internet (ISP) ou empresa que termina tráfego de voz da Bandwidth na sua rede, a integração de SIP Trunk parece simples no papel: aponte seu tronco para os IPs da operadora e comece a enviar chamadas. Na prática, a Bandwidth tem requisitos específicos de transporte, tamanho de pacote e redundância que precisam corresponder exatamente no lado do cliente, ou as chamadas falham na camada SIP sem erro aparente.
Um Controlador de Borda de Sessão (SBC) é o que faz a integração funcionar. O SBC fica na fronteira entre a rede da Bandwidth e seu PBX, central de atendimento ou plataforma UC downstream, normalizando SIP, ancorando mídia e aplicando política de segurança em cada chamada. Este artigo cobre o que a Bandwidth.com exige do seu SBC, por que cada requisito existe, como configurar cada um deles, e o que planejar em relação à atestação STIR/SHAKEN e fraude na borda. Construídos com mais de 20 anos de experiência em implantação SIP, SBCs modernos baseados em software executam essa função em infraestrutura virtual ou cloud commodity.

Por que você precisa de um SBC para SIP Trunking com Bandwidth.com

A Bandwidth.com termina o tráfego do lado do cliente em um par de SBCs de operadora. Ambos os IPs estão ativos para sinalização e mídia: chamadas podem chegar de qualquer um deles, e chamadas de saída vão para qualquer um deles. Esse padrão de SBC duplo é construído para redundância, mas transfere complexidade para o lado do cliente. Cada sistema downstream precisa conhecer ambos os IPs da Bandwidth, precisa autorizá-los e precisa lidar com failover limpo quando um deles para de responder.
Um SBC do lado do cliente absorve essa complexidade. Ele apresenta um ponto de interconexão único e controlado upstream para a Bandwidth, normaliza SIP em cada chamada conforme definido no RFC 3261, ancora mídia para que qualidade e política de gravação sejam aplicadas em um único ponto, oculta a topologia interna da operadora e bloqueia fraude e tráfego DoS antes que alcance seu core de telefonia.
Sem um SBC, seu PBX, central de atendimento ou plataforma UC absorve o dialeto SIP da Bandwidth diretamente e fica exposto ao tráfego da internet pública. Uma sonda REGISTER malformada ou uma campanha de fraude telefônica alcança diretamente o seu switch.

Requisitos de transporte e rede da Bandwidth.com

A Bandwidth.com publica regras específicas de rede e protocolo para qualquer SBC que integre com seus SIP Trunks. São inegociáveis: tráfego que não corresponder irá falhar.

Transporte exclusivamente UDP

A Bandwidth exige sinalização SIP e áudio via UDP. TCP não é suportado no produto padrão de SIP Trunk, e TLS não é o transporte padrão para o lado do tronco. Seu SBC deve terminar UDP/5060 no grupo de troncos voltado para a Bandwidth, independentemente do transporte que você usa downstream.

Tamanho máximo de mensagem SIP de 1.350 bytes

Mensagens SIP, especialmente INVITEs com longas cadeias de cabeçalhos, corpos SDP grandes ou metadados injetados pela operadora, podem exceder esse limite e serem fragmentadas ou descartadas. O SBC precisa gerenciar o tamanho da mensagem de saída: remover P-headers desnecessários, manter o SDP compacto e eliminar extensões proprietárias antes que a mensagem chegue ao fio.

Conformidade com RFC 3261

O stack da Bandwidth rejeita comportamento SIP não padronizado. Cabeçalhos proprietários customizados, entradas Via ou Record-Route malformadas, ou tratamento de métodos fora do RFC causarão falhas de INVITE. O mecanismo de manipulação de cabeçalhos do SBC precisa garantir um perfil de mensagem limpo e compatível com os padrões na perna voltada para a Bandwidth.

Redundância de SBC duplo

A Bandwidth fornece dois IPs de SBC para redundância de sinalização. Ambos devem ser configurados para tráfego de entrada e saída no lado do cliente. O grupo de troncos do SBC deve tratar o par como rota primária/secundária ou como par com balanceamento de carga, nunca como um único terminal com um único IP.

Configurando o SBC: passo a passo

Os menus exatos diferem entre fabricantes de SBC, mas a lógica de integração é a mesma em qualquer SBC compatível com RFC 3261.

1. Adicione os dois IPs de SBC da Bandwidth como destino upstream pareadoA maioria dos SBCs chama isso de Ponto de Acesso de Rede (NAP), grupo de troncos ou entrada de peer. Crie um NAP por SBC da Bandwidth.
2. Defina o transporte como UDP na porta 5060Configure ambas as entradas de peer com transporte UDP na porta 5060. Não habilite TLS ou TCP na perna voltada para a Bandwidth.
3. Limite o tamanho da mensagem SIP de saída abaixo de 1.350 bytesUse as regras de manipulação de cabeçalhos SIP do SBC para remover P-headers, extensões customizadas e qualquer campo que seu stack downstream injete e que a Bandwidth não aceite.
4. Configure o plano de discagem como E.164Use um + inicial em cada número chamado e chamador, de ponta a ponta. O identificador de chamadas de entrada e o número chamado de saída devem estar no formato E.164, conforme definido no ITU-T E.164.
5. Defina a ordem de rotas para failoverConfigure primário e secundário, ou ativo/ativo, para que o SBC mova o tráfego para o segundo IP automaticamente quando o primeiro parar de responder.
6. Habilite heartbeats SIP OPTIONSO SBC verifica continuamente a acessibilidade de ambos os SBCs da Bandwidth e aciona avanço de rota no momento em que um parar de responder.

Codecs e mídia

A Bandwidth suporta codecs PSTN padrão. G.711 µ-law e A-law estão universalmente disponíveis, e G.729 é suportado em algumas regiões. Confirme a lista exata de codecs no guia de integração mais recente da Bandwidth para o seu serviço.
O SBC negocia codec em cada perna através do Session Description Protocol (SDP). Ofertas de codec incompatíveis entre a Bandwidth e seu sistema downstream acionarão transcodificação no SBC ou, se a transcodificação não estiver configurada, rejeição da chamada na negociação SDP.
Ancorar mídia no SBC é o padrão correto. Terminar RTP no SBC mantém medição de qualidade, fronteira de criptografia e política de gravação aplicadas em um único ponto. Isso também permite que o SBC faça ponte de segurança de transporte: por exemplo, UDP sem criptografia voltado para a Bandwidth na perna da operadora, SRTP voltado para Microsoft Teams ou plataforma UCaaS na perna do cliente, com o SBC gerenciando troca de chaves independentemente em cada lado.
Se seu stack downstream usa codecs não-G.711 (Opus para WebRTC, AMR para clientes móveis), planeje capacidade de transcodificação adequadamente. Transcodificação por software para Opus e AMR não está disponível em toda plataforma de SBC e pode exigir suporte a transcodificação por hardware.

Segurança: o que o SBC precisa fazer na borda da Bandwidth

Um SIP Trunk acessível na internet pública é um alvo. O SBC é a defesa em camadas entre a rede da Bandwidth e o core de telefonia.

Whitelist de IP

Restrinja SIP de entrada apenas aos dois IPs de SBC da Bandwidth e descarte todo o resto no SBC. A maioria dos SBCs implementa isso através de listas de controle de acesso dinâmicas vinculadas à definição do grupo de troncos.

Proteção contra DoS e DDoS

Infraestrutura SIP voltada para o público atrai varredura SIP, floods de registro e ataques volumétricos de sinalização. O SBC precisa de limitação de taxa por IP de origem e por grupo de troncos com reconhecimento SIP, além de detecção e bloqueio automáticos de padrões de varredura de registro. Firewalls de rede genéricos não enxergam comportamento na camada SIP; proteção na camada do SBC é obrigatória.

Ocultação de topologia

Remova endereços IP privados dos cabeçalhos Contact, Via e Record-Route em cada mensagem de saída para a Bandwidth. A operadora nunca deve ver endereçamento interno, e seus sistemas internos nunca devem ver a infraestrutura upstream da Bandwidth.

Detecção de fraude telefônica

É aqui que o SBC se paga financeiramente. Discagem internacional para números premium é o maior risco de exposição a faturamento em qualquer SIP Trunk: um terminal SIP comprometido ou um SIP REGISTER com credenciais violadas pode gerar dezenas de milhares de dólares em tráfego fraudulento em horas. Pontuação de risco por chamada, considerando prefixo de destino, taxa de chamadas, horário do dia e padrão de chamadas, detecta anomalias antes que alcancem o tronco. Parceiros validados de detecção de fraude como TransNexus e YouMail se integram com o SBC via APIs padrão.

Atestação STIR/SHAKEN e Bandwidth.com

A Bandwidth.com é provedora de assinatura STIR/SHAKEN para clientes norte-americanos. Como provedora de serviço de origem, ela assina chamadas de saída com tokens de identidade PASSporT e níveis de atestação (A, B ou C) com base no seu conhecimento direto da parte chamadora, em linha com o framework de autenticação de chamadas da FCC.
Clientes que entregam chamadas à Bandwidth sem relacionamento direto próprio com o número chamador recebem uma atestação mais baixa do que poderiam esperar. A política de atestação se tornou mais rigorosa no último ano, e um rebaixamento de A para C tem impacto direto na receita: taxas de atendimento menores, mais rótulos de “Spam Provável” e pontuação de confiança reduzida nas operadoras de terminação.
O papel do SBC do lado do cliente no STIR/SHAKEN não é assinar. A Bandwidth faz a assinatura como provedora de serviço de origem. O trabalho do SBC é preencher cabeçalhos de identidade da parte chamadora (P-Asserted-Identity, From) com precisão para que a Bandwidth tenha as informações corretas para basear a atestação, e preservar qualquer cabeçalho Identity em chamadas que já possuam um. Remover ou reescrever informações de identidade no SBC degradará silenciosamente os resultados de atestação.

Monitoramento, CDRs e solução de problemas

A Bandwidth fornece Registros de Detalhe de Chamada (CDR) através do seu portal. Reconcilie esses CDRs com a saída de CDR do próprio SBC do lado do cliente para validar o faturamento. Discrepâncias entre os dois são o sinal mais rápido de que algo está sendo roteado ou contabilizado de forma diferente do esperado.
O SBC deve expor rastreamento SIP ao vivo e captura de pacotes estilo Wireshark para depuração de sinalização no nível do tronco. A grande maioria dos tickets de “chamadas falham intermitentemente” se resume a uma mensagem SIP específica que um lado está rejeitando, e a única forma de encontrá-la é olhar o tráfego no fio.
Pontuação MOS no SBC detecta áudio unidirecional, jitter e problemas de incompatibilidade de codec antes que apareçam em reclamações dos usuários. Dashboards dinâmicos e alertas baseados em limiares, disponíveis através de produtos como Monitoring as a Service, são requisitos padrão para qualquer implantação em produção.

Perguntas frequentes

Conclusão

A Bandwidth.com é uma provedora de SIP Trunk e CPaaS de alta qualidade e grande escala, e a integração é viável em qualquer SBC moderno. Mas a integração é específica. Transporte UDP, o teto de 1.350 bytes para mensagens SIP, conformidade com RFC 3261 e redundância de IP de SBC duplo precisam ser configurados corretamente no lado do cliente. Adicione ocultação de topologia, whitelist de IP, proteção contra DoS, pontuação de fraude na borda e consciência de como a atestação STIR/SHAKEN flui pela Bandwidth como provedora de serviço de origem, e você tem uma integração pronta para produção.
Ao avaliar um SBC para implantação com Bandwidth.com, os fatores-chave são arquitetura B2BUA completa, manipulação de cabeçalhos SIP configurável por grupo de troncos, segurança abrangente na camada SIP e a qualidade das ferramentas de depuração e monitoramento que permitem diagnosticar e ajustar a integração sob carga de produção.