Opções de SBC open source: o que realmente existe e quando é a escolha certa

A expressão “SBC open source” sugere um único projeto que você baixa, instala e coloca na borda da sua rede de voz, do mesmo jeito que implantaria um Controlador de Borda de Sessão (SBC) comercial. Esse produto não existe. O que existe é um conjunto de motores de sinalização SIP, motores de mídia e ferramentas de apoio open source que, bem montados e protegidos, conseguem fazer o mesmo trabalho. O custo de licença dessa stack é zero. O custo de engenharia e de operação, não.

Esta página mapeia as opções open source realistas, descreve o que cada uma realmente faz, mostra o que você precisa construir por conta própria para alcançar paridade de recursos com um SBC comercial e ajuda você a decidir se construir, comprar ou seguir um caminho híbrido é a escolha certa para a sua equipe.

Por que não existe um único SBC open source

Um SBC comercial é um produto empacotado. Sinalização SIP, tratamento de mídia, segurança, roteamento, detecção de fraude, integração com STIR/SHAKEN, monitoramento e alta disponibilidade são projetados e testados em conjunto, entregues como um único artefato e suportados por um único fornecedor.

As telecomunicações open source evoluíram de outro jeito. A camada de sinalização e a camada de mídia nasceram como projetos separados, escritos em linguagens diferentes, cada um com sua própria cadência de lançamentos, sua comunidade e sua filosofia de projeto. OpenSIPS e Kamailio descendem diretamente do SIP Express Router original e são otimizados para processar SIP em altas taxas. RTPengine e rtpproxy foram criados como componentes de mídia complementares, porque os servidores SIP não lidam com o RTP de forma alguma. FreeSWITCH e Asterisk foram projetados como plataformas de telefonia que tratam mídia, e não como SBCs de borda, embora ambos possam ser configurados para desempenhar o papel de SBC.

Um “SBC open source” é, portanto, uma stack que o próprio operador monta. O custo de licença de cada componente é zero. O trabalho de integração, o hardening operacional, as atualizações em vários projetos, a cadência de segurança, a integração com a assinatura STIR/SHAKEN e o suporte em produção são trabalho de engenharia que fica por conta do operador.

As opções realistas de SBC open source

Os seis projetos abaixo são os que as equipes realmente procuram quando querem rodar um SBC em software open source. Eles se dividem em dois grupos: motores de sinalização SIP que precisam de um motor de mídia separado e plataformas com capacidade de mídia que conseguem atuar sozinhas como SBC no modelo de Agente de Usuário Back-to-Back (B2BUA).

OpenSIPS

O OpenSIPS é um proxy SIP e motor de roteamento otimizado para sinalização em escala de operadora. Ele cuida de registro, roteamento, balanceamento de carga, travessia de NAT e políticas básicas de segurança com altas taxas de transações. O modelo de configuração usa uma linguagem de script própria, poderosa, mas pouco familiar para equipes sem experiência anterior com OpenSIPS.

O OpenSIPS não trata RTP. Para ancorar mídia, transcodificar codecs ou terminar SRTP, você o combina com o RTPengine ou o rtpproxy no mesmo host ou em hosts vizinhos. A substituição de implantações de OpenSIPS em fim de vida é um motivo recorrente para avaliar SBCs comerciais, porque a complexidade operacional se acumula à medida que a implantação cresce.

Kamailio

O Kamailio tem a mesma origem e a mesma arquitetura do OpenSIPS. É um servidor SIP, não um B2BUA, com outro ecossistema de módulos e um estilo de configuração um pouco diferente. O Kamailio é muito usado como front-end SIP em grandes implantações de operadoras e de CPaaS, muitas vezes em pares ativo/standby com IPs flutuantes para redundância.

Assim como o OpenSIPS, o Kamailio depende de um motor de mídia complementar para o RTP. Equipes que operam o Kamailio em escala costumam escrever suas próprias bibliotecas de configuração, implantar fail2ban ou limitadores de taxa personalizados para proteção contra DoS e integrar sistemas externos para assinatura STIR/SHAKEN e pontuação de fraude. A camada de sinalização é robusta; tudo o que está em volta dela é responsabilidade do operador.

drachtio

O drachtio oferece um servidor SIP programável, controlado a partir de aplicações Node.js. Em vez de editar um arquivo de configuração em uma linguagem de script dedicada, o operador escreve uma aplicação em JavaScript ou TypeScript que recebe eventos SIP e decide o que fazer com eles. Para a mídia, o drachtio é combinado com o RTPengine ou o FreeSWITCH.

O drachtio é indicado para equipes que já usam uma stack Node.js e querem que a camada SIP funcione como uma aplicação própria. Por padrão, ele não oferece ferramentas de segurança de nível de operadora, monitoramento nem proteção contra DoS. Construir essas camadas continua sendo tarefa do operador.

RTPengine

O RTPengine é o complemento de mídia mais comum para o Kamailio e o OpenSIPS. Ele roda como um daemon separado, acionado pelo servidor SIP com instruções para retransmitir ou transcodificar a mídia de cada chamada. O RTPengine cuida de SRTP, ICE, transcodificação básica e captura de pacotes. É um componente de mídia, não um SBC completo.

FreeSWITCH como SBC

O FreeSWITCH é uma plataforma de telefonia centrada em mídia que opera como B2BUA. Ele trata SIP, RTP, SRTP, WebRTC e transcodificação de codecs de forma nativa, o que o deixa, como projeto único, mais próximo do papel de SBC do que o OpenSIPS ou o Kamailio. Provedores de serviços na América Latina e em outras regiões já implantaram o FreeSWITCH na borda para tráfego em escala de operadora.

A contrapartida é que o FreeSWITCH foi projetado como servidor de mídia e plataforma de conferência. Usá-lo como SBC exposto à internet pública significa blindar a configuração contra ataques de flood SIP, construir por conta própria a limitação de taxa e a proteção contra varredura de registros, integrar um serviço externo de assinatura STIR/SHAKEN e escrever a camada de monitoramento de que sua equipe de operações precisa. Se você já escolheu o FreeSWITCH para a stack da sua plataforma, reaproveitá-lo como SBC é razoável. Se não escolheu, partir do FreeSWITCH por causa do custo de licença é um compromisso maior do que a página de download dá a entender.

Asterisk como SBC

O Asterisk é a plataforma de telefonia open source mais implantada do mundo. Ele funciona como B2BUA e trata tanto a sinalização quanto a mídia. Existem configurações de SBC baseadas no Asterisk, muitas vezes construídas em torno do driver de canal chan_pjsip, e o ecossistema FreePBX já empacotou parte dessa funcionalidade.

Em implantações de baixo volume, com um único tenant e com o Asterisk já presente na stack, usar o próprio Asterisk como SBC mantém a arquitetura simples. Em escala de operadora, em ambientes multi-tenant ou quando a proteção contra DoS e o isolamento de roteamento por tenant são importantes, o Asterisk exige um trabalho externo significativo para chegar ao perfil operacional com que um SBC comercial já vem de fábrica.

O que você constrói vs. o que você recebe

Recurso	Stack open source	SBC comercial (ex.: ProSBC)
Sinalização SIP	Incluída	Incluída
Arquitetura B2BUA	FreeSWITCH/Asterisk sim; Kamailio/OpenSIPS não	B2BUA completo
Ancoragem de mídia, SRTP, transcodificação	Componente separado ou nativo no FS/Asterisk	Nativo
Motor de manipulação de cabeçalhos SIP	Via script na linguagem de configuração	Motor de regras por NAP
Proteção contra DoS/DDoS	O operador constrói	Nativo
Proteção contra varredura de registros SIP	O operador constrói	Nativo
Lista de bloqueio dinâmica, ACLs, greylisting	Módulos + trabalho personalizado	Nativo
Integração com assinatura STIR/SHAKEN	O operador integra um STI-AS externo	Módulos prontos para TransNexus / Neustar
Alta disponibilidade 1+1	VRRP/keepalived + replicação de estado personalizada	Pronta para uso no ProSBC+
API de roteamento programável	Nativo (scripts de configuração)	Motor de roteamento em Ruby
Monitoramento, MOS, CDRs, captura de pacotes	Exige integração com ferramentas externas	Nativo, com opção de MaaS
Suporte do fornecedor e SLAs	Comunidade ou suporte comercial pago de OSS	Contratos de suporte 9×5 ou 24×7
Custo de licença	Zero	Assinatura por sessão com preço público

Os pontos em que a coluna open source está vazia ou parcial não são falhas dos projetos. São decisões de escopo: OpenSIPS, Kamailio, drachtio, RTPengine, FreeSWITCH e Asterisk não foram criados para substituir diretamente um SBC comercial. Chegar a um SBC pronto para produção significa construir, integrar e operar as camadas listadas acima.

Quando o SBC open source é a resposta certa

Em um número significativo de situações, o open source é de fato a escolha certa.

Você tem uma equipe interna forte de engenharia SIP, com vários anos de experiência operando OpenSIPS, Kamailio, FreeSWITCH ou Asterisk em produção. A equipe tem um repositório de configuração documentado, um caminho de atualização comprovado e pelo menos dois engenheiros que podem ser acionados às 2h da manhã sem pânico.

Seu perfil de tráfego é bem definido e estável, com picos previsíveis e um conjunto conhecido de peers SIP. As vantagens de personalização do open source compensam quando a implantação é estável o bastante para que o trabalho sob medida dure.

Você precisa fazer algo que um SBC comercial não permite, como uma ponte para um protocolo fora do padrão, um experimento de sinalização personalizado ou uma integração que nenhum fornecedor criou nem vai criar.

Sua situação de conformidade permite que você mesmo faça o suporte, porque você não está preso a um SLA de operadora, a uma exigência regulatória de disponibilidade nem a um processo de compras corporativo que exija um fornecedor no contrato.

Quando a conta sem licença deixa de fechar

Custo total de engenharia

No mercado norte-americano, um engenheiro de redes ou de voz com experiência em SBC custa de US$ 60.000 a US$ 100.000 por ano, com todos os encargos. Mesmo com apenas 20% do tempo de um engenheiro dedicado ao SBC, são de US$ 12.000 a US$ 20.000 por ano só em custo de pessoal. Uma assinatura ProSBC Essentials de 500 sessões custa US$ 5.000 por ano, com alta disponibilidade e suporte 24/7 de Nível 3 incluídos.

Cadência de segurança

Um SBC exposto à internet enfrenta o tempo todo varreduras SIP, ataques de flood de registro, sondagens com pacotes malformados e tentativas de DDoS. Um SBC comercial já vem com essas mitigações integradas e corrigidas no ritmo de atualizações do fornecedor.

Conformidade com STIR/SHAKEN

Configurar o motor de sinalização open source para consultar um STI-AS externo e obter atestação nível A, tratar falhas de assinatura, gerenciar o fallback com P-Identity-Bypass e sobreviver a uma queda do serviço de assinatura sem derrubar chamadas é trabalho de engenharia original.

Disciplina de atualização

Uma stack open source com vários projetos sai de sincronia. O OpenSIPS lança versões no próprio calendário, o RTPengine em outro, o kernel Linux e as bibliotecas TLS em um terceiro. Coordenar atualizações, fazer testes de regressão da integração e reverter de forma limpa quando algo quebra é um trabalho de engenharia de verdade.

A realidade do plantão

Voz é tempo real. Um rodízio de duas pessoas é a estrutura mínima sustentável de plantão para infraestrutura de SBC, e três é o número realista se você quiser evitar o burnout.

Caminhos híbridos: programabilidade sem a stack

Muitas equipes que olham para o open source não estão apaixonadas pela carga operacional. O que elas buscam é programabilidade.

O motor de roteamento do ProSBC é configurado em Ruby, com uma cadeia de filtros documentada (before_filter, after_filter, after_remap_filter) e módulos prontos para assinatura STIR/SHAKEN com TransNexus ClearIP e Neustar, pontuação de fraude com SecureLogix e YouMail e integrações externas de roteamento via REST API sobre HTTP. A equipe escreve os scripts. O fornecedor mantém o núcleo do SBC, a stack de segurança e a disciplina de atualização.

Para as equipes que pensavam em open source em busca de controle, esse caminho híbrido costuma ser o meio-termo prático.

Perguntas frequentes

Conclusão

“SBC open source” é uma stack que o operador monta, não um produto que se baixa. OpenSIPS, Kamailio e drachtio cuidam da sinalização SIP; o RTPengine trata a mídia para esses motores de sinalização; FreeSWITCH e Asterisk podem rodar como B2BUAs que fazem as duas coisas. Nenhum deles foi projetado para substituir diretamente um SBC comercial.

Para uma equipe com um time forte de engenharia SIP, tráfego estável e baixa carga de conformidade, o open source é uma escolha defensável e, às vezes, a escolha certa. Para uma equipe que queria open source pela programabilidade, um SBC comercial com uma API de roteamento de verdade muitas vezes entrega o mesmo controle sem o custo operacional. Para todos os demais, a conta do tempo de engenharia costuma apontar para um SBC comercial com um preço inicial pequeno em comparação com os salários das pessoas que, de outra forma, construiriam e manteriam a stack.