Controlador de Borda de Sessão (SBC): o guia completo para avaliar um SBC por software

Um session border controller é o elemento de rede posicionado na fronteira entre duas redes de voz IP, governando cada sessão SIP que a atravessa: terminando sinalização e mídia de um lado, aplicando políticas de segurança e protocolo, e reoriginando uma nova sessão do outro lado.

Este guia é para engenheiros e tomadores de decisão que estão avaliando suas opções de SBC. Ele abrange as capacidades essenciais que um SBC de produção deve oferecer, por que a indústria está migrando de appliances de hardware para controladores de borda de sessão baseados em software, os modelos de implantação disponíveis, quais segmentos de compradores mais se beneficiam, e os recursos a priorizar ao comparar fornecedores.

O que é um Session Border Controller?

Em sua essência, um session border controller é um Agente de Usuário Back-to-Back (B2BUA) implantado na fronteira entre duas redes SIP. Ele termina completamente cada sessão recebida, aplica políticas de segurança e interoperabilidade, e reorigina uma nova sessão do outro lado, dando ao operador controle independente sobre sinalização, mídia e criptografia em cada perna. Para uma explicação completa dos fundamentos do SBC, como funciona a arquitetura B2BUA e como os SBCs diferem de firewalls e proxies SIP, consulte What Is a Session Border Controller (SBC)?

As seções abaixo focam no que importa quando você está avaliando um SBC para produção: as cinco áreas de capacidades essenciais, os trade-offs operacionais entre hardware e software, os modelos de implantação disponíveis atualmente, e os recursos que separam uma plataforma de classe operadora de um dispositivo de borda SIP básico.

O que faz um Session Border Controller?

As funções que um SBC desempenha se enquadram em cinco categorias. Ao avaliar fornecedores, estas são as áreas onde a qualidade da implementação mais varia e onde as diferenças têm o maior impacto na confiabilidade de produção.

Segurança e Controle de Acesso

Segurança é a razão mais comum pela qual as organizações implantam um SBC. Na borda da rede, o SBC atua como ponto único de entrada para todo o tráfego SIP, o que o torna o local natural para aplicar políticas de segurança.

Proteção contra DoS e DDoS detecta e bloqueia ataques volumétricos (floods SIP, tempestades de registro e tentativas de negação de serviço distribuída) antes que alcancem a infraestrutura de processamento de chamadas por trás do SBC. Blacklisting dinâmico permite que o SBC bloqueie automaticamente endereços IP ou números de chamada que exibam comportamento suspeito, enquanto listas de controle de acesso estáticas definem quais fontes são permitidas para enviar tráfego. Proteção contra varredura de registro SIP identifica e bloqueia tentativas de registro por força bruta, um precursor comum de fraude tarifária. Ocultação de topologia garante que endereços IP internos nunca vazem nos cabeçalhos SIP externos, impedindo que atacantes mapeiem sua rede.

Quando o SBC opera como B2BUA, ele também fornece uma demarcação natural para criptografia. Ele pode terminar a sinalização SIP criptografada com TLS em uma perna e reoriginá-la na outra, com um certificado diferente, um conjunto de cifras diferente, ou nenhuma criptografia, dependendo do que cada lado requer. O mesmo se aplica à mídia: o SBC faz a ponte entre SRTP e RTP simples de forma transparente, para que uma operadora entregando mídia não criptografada possa se conectar a uma plataforma que exige criptografia sem que nenhum dos lados altere sua configuração.

Interoperabilidade e Normalização SIP

Nenhuma implementação SIP é idêntica. Operadoras, fornecedores de PBX e plataformas de colaboração interpretam o RFC do SIP de maneiras diferentes, adicionam cabeçalhos proprietários e lidam com casos extremos à sua própria maneira. O SBC resolve essas incompatibilidades através da manipulação de cabeçalhos SIP, inspecionando e reescrevendo cabeçalhos por grupo de troncos para que cada lado receba SIP que compreende.

Tarefas comuns de normalização incluem corrigir cabeçalhos Via e Contact que contêm endereços IP privados, remapear cabeçalhos P-Asserted-Identity (PAI) para apresentação de identificação de chamadas, remover extensões proprietárias que um lado não reconhece, e ajustar parâmetros de temporizador de sessão (RFC 4028) que de outra forma causariam quedas prematuras de chamadas.

Manipulação de Mídia e Transcodificação

O SBC controla o plano de mídia assim como a sinalização. Ele ancora a mídia através de seu próprio endereço IP, garantindo que os pacotes RTP passem pelo SBC em vez de fluir diretamente entre os endpoints, o que é essencial para ponte de criptografia, interceptação legal, gravação de chamadas e monitoramento de qualidade.

Quando dois endpoints usam codecs incompatíveis, o SBC realiza transcodificação de mídia para converter entre eles. Para implantações IP-para-IP, isso pode significar converter entre codecs de banda estreita (G.711, G.729) e codecs de banda larga (AMR-WB, Opus) para que endpoints móveis e WebRTC possam interoperar com infraestrutura PSTN tradicional.

Roteamento de Chamadas e Aplicação de Políticas

Além do roteamento SIP básico, um SBC fornece um mecanismo de roteamento programável que toma decisões com base em número chamador, número chamado, horário do dia, utilização do grupo de troncos e consultas de dados externos. O controle de admissão de chamadas previne a sobrecarga limitando o número de sessões simultâneas por grupo de troncos ou em todo o sistema. O roteamento de menor custo direciona chamadas pela rota mais econômica disponível, com failover automático para rotas alternativas quando uma operadora está indisponível.

SBCs avançados expõem uma camada de API que permite aos operadores integrar lógica externa (consultas de CRM, bancos de dados de portabilidade numérica, mecanismos de pontuação de fraude e sistemas de faturamento) diretamente na decisão de roteamento de chamadas, executada durante a fase de sinalização para que não haja impacto na qualidade da mídia.

Conformidade Regulatória

Telecomunicações é uma indústria regulamentada, e o SBC é frequentemente o ponto de aplicação para requisitos de conformidade. A autenticação de identificação de chamadas STIR/SHAKEN, exigida pela FCC sob o TRACED Act, requer que os provedores de serviços de voz assinem criptograficamente as chamadas de saída e verifiquem as de entrada. O SBC se integra com serviços externos de assinatura para anexar ou validar tokens de identidade digital no cabeçalho SIP INVITE.

As capacidades de detecção de fraude permitem que o SBC inspecione padrões de chamadas em tempo real, pontue chamadas por risco e bloqueie tráfego fraudulento antes que gere cobranças. A geração de registros detalhados de chamadas (CDR) fornece a trilha de faturamento e auditoria que reguladores e equipes financeiras exigem.

SBC de Hardware vs. SBC de Software: a mudança na indústria

Durante a maior parte da história do SBC, o dispositivo era um appliance de hardware proprietário: uma caixa construída especificamente por AudioCodes, Oracle (Acme Packet), Ribbon Communications ou Cisco, com chips DSP dedicados para transcodificação e um teto de capacidade fixo determinado pelo hardware adquirido.

Esse modelo está mudando. Software de session border controller que roda em máquinas virtuais padrão, instâncias de nuvem e servidores commodity agora entrega as mesmas capacidades de segurança, interoperabilidade e roteamento de classe operadora, sem o investimento de capital, ciclos de atualização de hardware e dependência de fornecedor que acompanham os appliances.

Por que os provedores de serviços estão migrando para SBCs de software

A mudança de hardware para controladores de borda de sessão baseados em software é impulsionada por cinco realidades operacionais.

Capital versus despesa operacional é o fator mais imediato. Um SBC de hardware requer uma grande compra inicial, um contrato de manutenção e uma atualização de hardware a cada cinco a sete anos. Um SBC de software roda em infraestrutura que você já possui ou aluga, com preços por assinatura que escalam com o uso real. Para provedores de serviços gerenciando dezenas ou centenas de clientes, a diferença no custo total de propriedade é significativa.

Velocidade de implantação importa em mercados competitivos. Um session border controller virtual pode ser implantado em VMware, KVM/Proxmox, AWS ou Azure em minutos, não nas semanas ou meses necessários para adquirir, enviar, instalar e configurar um appliance de hardware. Para MSPs integrando novos clientes ou ISPs respondendo a uma solicitação de interconexão com operadora, essa velocidade se traduz diretamente em receita.

Escalabilidade elástica elimina as suposições no planejamento de capacidade. Um SBC na nuvem escala a capacidade de sessões para cima ou para baixo sem trocar hardware. Quando o tráfego cresce, você aumenta o nível de licença. Quando um projeto termina, você reduz. Appliances de hardware não oferecem essa flexibilidade; você paga pela capacidade de pico quer a utilize ou não.

Independência de plataforma remove a dependência de fornecedor único que definiu o mercado de SBC por décadas. Um SBC de software roda no hypervisor, provedor de nuvem ou servidor bare-metal que o operador escolher, e migrar entre plataformas não requer substituição de hardware.

Atualizações contínuas fecham a lacuna entre os ciclos de lançamento. SBCs de software recebem atualizações de recursos e patches de segurança através de pipelines de implantação de software padrão, não através de upgrades de firmware vinculados a hardware que requerem janelas de manutenção e às vezes acesso físico.

Quando o hardware ainda faz sentido

SBCs de hardware mantêm vantagens em cenários específicos. Implantações que requerem transcodificação de alta densidade (milhares de conversões simultâneas de codec entre AMR-WB e G.711, por exemplo) ainda se beneficiam de hardware DSP dedicado. Alguns ambientes regulatórios exigem appliances físicos on-premises. E organizações com investimentos existentes em hardware podem optar por manter seus appliances atuais até o fim de vida antes de migrar para software.

O caminho prático para a maioria dos provedores de serviços é uma abordagem híbrida: SBCs de software para novas implantações, instâncias na nuvem e cargas de trabalho elásticas, com recursos de transcodificação por hardware adicionados apenas onde a conversão de codec em escala exige.

Como funciona um Session Border Controller em uma rede VoIP

Um SBC opera na borda de uma rede de voz, posicionado entre a infraestrutura interna confiável e redes externas não confiáveis. Em um ambiente de provedor de serviços, isso tipicamente significa uma ou mais instâncias de SBC posicionadas entre a plataforma de comutação central do provedor e o mundo externo: interconexões com operadoras de um lado, endpoints de assinantes do outro.

O SBC de Peering

Um SBC de peering gerencia a interconexão entre dois provedores de serviços ou entre um provedor de serviços e uma operadora PSTN. Cada chamada que entra ou sai da rede passa por este SBC. Ele aplica segurança no nível de tronco (TLS, SRTP, controle de acesso), normaliza o SIP entre os sistemas dos dois provedores, gera CDRs para faturamento entre operadoras e aplica controle de admissão de chamadas para impedir que qualquer peer único consuma mais capacidade do que o contratado.

O SBC de Acesso

Um SBC de acesso fica entre os endpoints dos assinantes (telefones IP, PBXs, plataformas de contact center, ferramentas de colaboração) e a infraestrutura central do provedor de serviços. Ele lida com NAT traversal para endpoints atrás de firewalls de clientes, aplica limites de sessão por assinante, faz ponte de criptografia entre a rede do assinante e o core do provedor, e fornece uma camada de proteção contra equipamentos de clientes comprometidos ou mal configurados.

Fluxo de chamada VoIP no SBC

Quando uma chamada chega ao SBC, a sequência de processamento segue um caminho previsível. O SBC primeiro valida a origem contra sua lista de controle de acesso e verifica padrões de DoS. Em seguida, inspeciona o SIP INVITE, aplicando regras de manipulação de cabeçalhos para o grupo de troncos de entrada. Se a verificação STIR/SHAKEN estiver configurada, o SBC envia o cabeçalho Identity para o serviço de verificação. O mecanismo de roteamento determina o caminho de saída com base em regras configuradas, consultas de dados externos ou lógica orientada por API. O SBC constrói um novo SIP INVITE para a perna de saída, aplicando as regras de manipulação de cabeçalhos para o grupo de troncos de destino, negociando codecs e estabelecendo criptografia se necessário. Uma vez que a parte chamada atende, o SBC ancora a mídia através de seu próprio endereço, fazendo ponte entre quaisquer formatos de criptografia e codec que cada lado utilize.

Ao longo da chamada, o SBC monitora a qualidade (scores MOS, jitter, perda de pacotes), gera estatísticas em tempo real e escreve um CDR quando a sessão termina.

Modelos de implantação de SBC

Software moderno de session border controller suporta múltiplos modelos de implantação, cada um adequado a diferentes requisitos operacionais.

SBC virtual on-premises

O SBC roda como uma máquina virtual no hypervisor do próprio operador (VMware ESXi, KVM ou Proxmox). Este modelo dá ao operador controle total sobre o hardware hospedeiro, a configuração de rede e o caminho de dados. É o modelo preferido para provedores de serviços com infraestrutura de data center existente, para implantações em ambientes regulamentados que requerem processamento de dados on-premises, e para organizações que precisam integrar o SBC com equipamentos TDM na mesma instalação.

SBC na nuvem

Um session border controller cloud-native roda em AWS, Microsoft Azure ou outro provedor de nuvem pública. Este modelo elimina totalmente a sobrecarga do data center e permite implantações geo-redundantes em múltiplas regiões de nuvem para máxima resiliência. SBCs na nuvem são a opção natural para provedores que atendem bases de clientes distribuídas, para integrações CPaaS onde a plataforma de voz já reside na nuvem, e para organizações que querem evitar qualquer compromisso com hardware.

SBC bare-metal

Para operadores que desejam máximo desempenho sem uma camada de hypervisor, o SBC pode rodar diretamente em servidores x86 commodity. Este modelo extrai a maior densidade de sessões possível de uma determinada capacidade de hardware e é comum em implantações de peering de alta capacidade onde cada sessão conta.

Implantações híbridas

Muitos provedores de serviços combinam modelos: um SBC on-premises para interconexões locais com operadoras e integração TDM, combinado com instâncias de SBC na nuvem para sites remotos, recuperação de desastres ou capacidade de overflow elástica. A mesma imagem de software e sintaxe de configuração em todos os modelos de implantação torna isso prático.

Quem precisa de um Session Border Controller?

Qualquer organização operando uma rede de voz baseada em SIP na fronteira entre dois domínios de confiança precisa de um SBC. Seja implantando um session border controller empresarial para proteger um ambiente de voz corporativo ou um SBC de classe operadora para gerenciar dezenas de milhares de sessões em uma rede de provedor de serviços, os requisitos essenciais são os mesmos: segurança, interoperabilidade e aplicação de políticas. Na prática, quatro segmentos de compradores representam a grande maioria das implantações de SBC.

Provedores de Internet (ISPs)

ISPs que oferecem serviços de voz precisam de um SBC para interconectar com operadoras upstream, proteger sua infraestrutura de comutação contra ameaças externas, garantir conformidade com STIR/SHAKEN, e gerenciar a normalização SIP necessária ao agregar tráfego de múltiplos peers de operadoras. Para ISPs substituindo plataformas legadas (implantações de OpenSIPs que cresceram além de seu escopo original, sistemas MetaSwitch/Perimeter que carecem de mitigação DDoS, ou hardware em fim de vida da Ribbon ou Oracle), um SBC de software fornece um caminho de substituição moderno e econômico.

Provedores de Serviços Gerenciados (MSPs)

MSPs que entregam voz hospedada, UCaaS ou Microsoft Teams Direct Routing para clientes empresariais precisam de um SBC como ponto central de gerenciamento de tráfego e segurança. Uma única implantação de SBC pode atender dezenas ou centenas de clientes finais, com grupos de troncos por tenant, regras de roteamento e políticas de segurança. O SBC também permite que o MSP ofereça serviços de valor agregado (gravação de chamadas, proteção contra fraude, aplicação de conformidade) que diferenciam sua oferta da revenda de voz commodity.

Fornecedores de plataformas UCaaS e CCaaS

Fornecedores de software construindo plataformas de comunicações unificadas ou contact center precisam de um SBC para lidar com a camada de SIP trunking, segurança e interoperabilidade para que suas equipes de desenvolvimento possam focar na lógica de aplicação em vez da integração com operadoras. Em arquiteturas CPaaS e BYOC, onde a plataforma se integra com Twilio, RingCentral, Genesys ou similares, o SBC normaliza o tráfego de múltiplas operadoras e fornece o perímetro de segurança que a própria plataforma não inclui.

Contact Centers

Operações de contact center, seja on-premises ou migrando para plataformas na nuvem como Genesys Cloud, Five9 ou NICE, implantam SBCs para proteger sua infraestrutura de voz, gerenciar altas contagens de sessões simultâneas, garantir qualidade de serviço para chamadas voltadas ao cliente e manter conformidade com requisitos de gravação e auditoria. Para implantações de contact center na nuvem com BYOC (Bring Your Own Carrier), o SBC é a ponte entre as operadoras escolhidas pela organização e a plataforma na nuvem.

Principais recursos de Session Border Controller a avaliar

Ao comparar fornecedores de SBC, estas são as capacidades que mais diretamente afetam a confiabilidade de produção, o custo operacional e a flexibilidade a longo prazo.

Arquitetura B2BUA

Uma implementação completa de B2BUA, onde o SBC termina e reorigina tanto a sinalização quanto a mídia em cada perna, é inegociável para implantações de produção. Um proxy SIP não pode realizar manipulação de cabeçalhos, criptografia independente por perna, ocultação de topologia ou ancoragem de mídia. Se o SBC que você está avaliando opera como proxy em vez de B2BUA, ele não pode entregar as funções de segurança e interoperabilidade descritas neste guia.

Profundidade de segurança

Vá além de afirmações de checklist. Avalie se o SBC fornece mitigação de DoS/DDoS em tempo real (não apenas limitação de taxa), blacklisting dinâmico que reage automaticamente a padrões de tráfego, proteção contra varredura de registro SIP e listas de controle de acesso granulares no nível do grupo de troncos. O suporte a criptografia deve incluir TLS para sinalização e SRTP para mídia, com a capacidade de fazer ponte entre pernas criptografadas e não criptografadas de forma transparente.

Motor de manipulação de cabeçalhos SIP

A qualidade do motor de manipulação de cabeçalhos do SBC determina a eficácia com que ele lida com ambientes multi-fornecedor. Avalie se as regras podem ser aplicadas por grupo de troncos, se o motor suporta correspondência de padrões baseada em regex e se ele consegue lidar com transformações complexas como inserção condicional de cabeçalhos baseada em parâmetros de chamada.

API e programabilidade

Um SBC moderno deve expor uma REST API para gerenciamento de configuração, monitoramento de status e recuperação de CDR. Além disso, avalie se o SBC suporta roteamento programável: a capacidade de executar lógica personalizada (consultas HTTP externas, consultas a bancos de dados, pontuação de fraude) durante a fase de sinalização de cada chamada. Essa capacidade transforma o SBC de um dispositivo estático de aplicação de políticas em uma borda programável que se adapta a requisitos de negócios em tempo real.

Flexibilidade de implantação

Confirme que o SBC roda nas plataformas que sua infraestrutura utiliza hoje e poderá utilizar amanhã: VMware, KVM/Proxmox, AWS, Azure e bare metal. Um SBC de software que o prende a um único hypervisor ou provedor de nuvem introduz o mesmo tipo de dependência de fornecedor que os appliances de hardware impõem.

Alta Disponibilidade

Para infraestrutura de voz em produção, alta disponibilidade 1+1 ativo/standby é um requisito mínimo. Avalie como o failover funciona, qual estado é preservado durante o failover e se HA está disponível em todos os tamanhos de implantação, não apenas para licenças de nível empresarial.

Modelo de preços

SBCs de hardware possuem grandes custos iniciais de capital mais manutenção anual. SBCs de software tipicamente usam preços por assinatura (por sessão, por servidor ou por mês). Avalie o custo total de propriedade ao longo de três a cinco anos, incluindo contratos de suporte, licenciamento de HA e recursos adicionais. Preços transparentes e publicados são um forte sinal de que o fornecedor confia em sua proposta de valor.

Integração STIR/SHAKEN

Com as regras da FCC agora exigindo que provedores assinem chamadas usando seus próprios certificados STIR/SHAKEN, avalie como o SBC se integra com serviços de assinatura. Um modelo de integração aberto, onde o SBC funciona com qualquer serviço de assinatura de terceiros (TransNexus, Neustar, entre outros) em vez de prendê-lo a um parceiro escolhido pelo fornecedor, oferece a flexibilidade de trocar de provedor se os preços ou capacidades mudarem.

Capacidade	SBC de Hardware	SBC de Software
Velocidade de implantação	Semanas a meses	Minutos a horas
Escalabilidade elástica	Fixa pelo hardware	Escale sob demanda
Modelo de preços	Grande CAPEX + manutenção	Assinatura OPEX
Escolha de plataforma	Somente hardware do fornecedor	VMware, KVM, AWS, Azure, bare metal
Alta disponibilidade em pequena escala	Frequentemente apenas nível empresarial	Disponível em todos os níveis
Transcodificação por hardware	DSP integrado	DSP externo ou software (depende do codec)
Ciclo de atualização	Firmware + janelas de manutenção	Implantação de software padrão

Perguntas Frequentes

O que é um session border controller em termos simples?

Um session border controller é um dispositivo ou software que fica na borda de uma rede de voz e controla cada chamada que cruza a fronteira: protegendo o tráfego, traduzindo entre implementações SIP, criptografando mídia e aplicando políticas de roteamento. Para uma introdução detalhada, consulte What Is a Session Border Controller (SBC)?

Qual é a diferença entre um SBC e um firewall?

Um firewall opera na camada de rede: filtra pacotes com base em endereços IP, portas e protocolos. Um SBC opera na camada de aplicação: compreende sinalização SIP e mídia RTP, pode inspecionar e modificar o conteúdo de sessões de voz, aplicar políticas específicas de chamada e fazer ponte entre diferentes padrões de criptografia. Um firewall não pode realizar normalização SIP, transcodificação de mídia, ocultação de topologia ou controle de admissão de chamadas. Em redes de voz em produção, ambos são necessários: o firewall para segurança geral de rede, o SBC para segurança específica de voz e interoperabilidade.

Preciso de um SBC para Microsoft Teams?

Sim, se você está usando Direct Routing para conectar o Teams aos seus próprios troncos SIP. A Microsoft requer um SBC certificado ou compatível que suporte TLS 1.2 para sinalização, SRTP para mídia, configuração baseada em FQDN e heartbeats SIP OPTIONS. O SBC lida com a tradução de protocolo entre o SIP da sua operadora e o dialeto SIP do Teams, a ponte de criptografia entre RTP da operadora e SRTP do Teams, e a normalização de cabeçalhos que o Teams requer. Sem um SBC, o Direct Routing não funciona.

Qual é a diferença entre um SBC de hardware e um SBC de software?

Um SBC de hardware é um appliance proprietário com capacidade fixa e chips DSP dedicados. Um SBC de software roda em máquinas virtuais, instâncias de nuvem ou servidores commodity, oferecendo preços por assinatura, escalabilidade elástica e flexibilidade de implantação. Ambos fornecem as mesmas funções essenciais do SBC: segurança, interoperabilidade, roteamento e conformidade. A escolha depende do seu modelo de infraestrutura, preferência de orçamento (CAPEX vs. OPEX) e se você precisa de transcodificação acelerada por hardware em grande escala.

Quantas sessões um SBC de software consegue processar?

SBCs de software modernos de classe operadora podem processar dezenas de milhares de sessões simultâneas em uma única instância de servidor. A capacidade real depende dos recursos de CPU e memória do servidor, se a transcodificação está ativa e da complexidade da lógica de roteamento aplicada por chamada. Para implantações que requerem mais capacidade, múltiplas instâncias de SBC podem ser implantadas atrás de um load balancer ou em configuração clusterizada.

Um SBC é necessário para conformidade com STIR/SHAKEN?

A FCC exige que provedores de serviços de voz assinem chamadas de saída e verifiquem chamadas de entrada usando o framework STIR/SHAKEN. O SBC é o ponto de aplicação mais comum para este requisito porque já processa cada SIP INVITE na borda da rede. O SBC se integra com um serviço externo de assinatura para anexar tokens de identidade criptográficos às chamadas de saída e para verificar tokens nas chamadas de entrada. Os provedores agora devem usar seus próprios certificados STIR/SHAKEN para assinatura, em vez de depender do certificado de terceiros.

Leitura Adicional

Para explorar como um SBC de software transforma arquiteturas de comunicações na nuvem, desde escalabilidade elástica e alta disponibilidade geo-redundante até media bypass e integração CPaaS, leia nosso guia detalhado sobre SBC para comunicações na nuvem.

Para entender como o Microsoft Teams Direct Routing conecta o Teams à PSTN através de um SBC, incluindo os requisitos de TLS, SRTP e normalização SIP que o fazem funcionar, leia nosso passo a passo detalhado sobre O que é Teams Direct Routing?.

Implante um SBC de software com ProSBC

ProSBC é um session border controller de classe operadora, baseado em software, construído para provedores de serviços. Ele entrega a arquitetura B2BUA completa, motor de manipulação de cabeçalhos SIP, proteção contra DoS/DDoS, blacklisting dinâmico e capacidades de roteamento programável discutidas ao longo deste guia, rodando em VMware, KVM/Proxmox, AWS, Azure ou bare metal com preços por assinatura a partir de US$ 1,40 por sessão por ano.

ProSBC suporta Microsoft Teams Direct Routing, integra-se com serviços de assinatura STIR/SHAKEN incluindo TransNexus ClearIP, e expõe uma REST API e scripts de roteamento baseados em Ruby para lógica de chamadas personalizada. Alta Disponibilidade (1+1 ativo/standby) está disponível em todos os tamanhos de implantação, e o ProSBC Lab, uma licença gratuita permanente de 3 sessões que permite testar o conjunto completo de recursos em seu próprio ambiente antes de se comprometer.

Para operadores que preferem não gerenciar o SBC eles mesmos, o ProSBC Managed Service oferece uma implantação totalmente gerenciada com HA 1+1, suporte 24/7 e configuração ponta a ponta, hospedada na plataforma de sua escolha ou pela TelcoBridges.