Kamailio vs OpenSIPS vs FreeSWITCH: Como Escolher uma Plataforma SIP (e Por Que Geralmente Você Precisa de Mais de Uma)

Essa comparação é pesquisada como um confronto entre três plataformas, mas na prática não é bem assim. Kamailio e OpenSIPS são motores de roteamento SIP: proxies focados em sinalização, construídos para throughput muito alto de Chamadas por Segundo (CPS). FreeSWITCH é um Agente de Usuário Back-to-Back (B2BUA) com uma pilha completa de mídia cobrindo transcoding, IVR, conferência e gravação. As plataformas costumam ser discutidas juntas porque tratam de decisões de engenharia sobrepostas no ecossistema de voz open-source, mas tratá-las como três produtos equivalentes distorce a pergunta real.

A pergunta real não é “qual dessas três devo implantar”. É “como esses componentes devem se combinar e onde cada um se encaixa na minha arquitetura?” Em uma implantação de produção típica atendendo milhares de chamadas simultâneas, Kamailio ou OpenSIPS fica na frente lidando com registros, balanceamento de carga e roteamento SIP de alto volume, enquanto FreeSWITCH cuida das chamadas que precisam de inteligência de mídia. Nenhuma das três plataformas é um Controlador de Borda de Sessão (SBC), e assumir que qualquer uma delas pode preencher esse papel na borda da rede é um dos erros arquiteturais mais comuns em voz open-source.

Este artigo aborda o que cada plataforma foi construída para fazer, como Kamailio e OpenSIPS realmente diferem, por que o padrão híbrido com FreeSWITCH domina implantações de produção, e o que a pilha SBC feita por conta própria cobre e não cobre.

A Divisão Arquitetural: Proxies vs Servidores de Mídia

Kamailio e OpenSIPS são proxies e motores de roteamento SIP. No modo padrão, processam sinalização SIP, tomam decisões de roteamento, modificam cabeçalhos, aplicam políticas e encaminham a requisição adiante, mas não tocam no caminho de mídia. O áudio (RTP) flui entre os terminais diretamente, ou através de um processo separado de relay de mídia como RTPengine ou RTPproxy que o proxy controla.

FreeSWITCH é um B2BUA. Ele termina uma chamada SIP de um lado, origina uma nova chamada do outro lado, e fica tanto no caminho de sinalização quanto no caminho de mídia durante toda a duração da chamada. Essa posição é o que permite ao FreeSWITCH fazer coisas que os proxies não conseguem nativamente: transcodificar codecs, reproduzir prompts, gravar áudio, mixar conferências, ancorar criptografia e executar lógica de IVR sobre o fluxo de mídia ao vivo.

Essa diferença arquitetural determina quase todo o restante sobre as plataformas. Um SIP proxy é rápido e leve porque não transporta a mídia. Um servidor de mídia é mais pesado por chamada porque transporta. Cobrimos os detalhes mais profundos da mecânica proxy-versus-B2BUA (Via, Route, Record-Route, stateless versus stateful, o que um proxy pode e não pode reescrever) na nossa análise da arquitetura de SIP proxy. Resumindo: encaminhar é um conjunto de operações, terminar é outro, e as possibilidades disponíveis para cada caso são fundamentalmente diferentes.

Kamailio vs OpenSIPS: O Que Realmente Difere

Para engenheiros escolhendo entre os dois, eis o que importa na prática.

Modelo de scripting é a primeira divergência. A linguagem de configuração nativa do Kamailio mais o KEMI dá à plataforma uma ponte limpa para Lua, Python, JavaScript e Ruby. Se sua equipe escreve ferramental operacional em Python e quer que a camada de roteamento viva na mesma linguagem, Kamailio é a opção mais natural. OpenSIPS mantém a lógica de roteamento em sua própria linguagem e pede que a equipe a aprenda; equipes que valorizam um formato procedural único e consistente dentro do servidor SIP costumam preferir essa abordagem.

Capacidade B2BUA é a segunda. OpenSIPS tem um módulo B2BUA nativo mais desenvolvido. Se seus requisitos de roteamento incluem comportamento B2BUA para fluxos específicos (tratamento de re-INVITE, manipulação de pernas de chamada, forking estruturado), OpenSIPS lida com mais disso sem componentes externos. Kamailio é mais puramente proxy e se combina com ferramentas separadas quando a semântica B2BUA é necessária.

Integração externa cobre o terceiro eixo. Ambas as plataformas podem consultar sistemas externos via HTTP para decisões de roteamento. Os módulos REST do OpenSIPS são maduros nativamente; as capacidades equivalentes do Kamailio são igualmente capazes, mas mais comumente acessadas através de scripts KEMI que encapsulam o cliente HTTP da sua linguagem.

Filosofia de módulos define o quarto eixo. Kamailio é modular e delega agressivamente a componentes externos (RTPengine para mídia, bancos de dados separados para estado, KEMI para lógica não trivial). OpenSIPS incorpora mais funcionalidade em seu conjunto nativo de módulos. Nenhuma filosofia está errada, mas cada uma empurra as equipes para padrões operacionais diferentes.

Comunidade e cadência de releases são aproximadamente comparáveis. Ambos os projetos têm comunidades ativas, releases regulares e suporte comercial consistente através de serviços de treinamento e consultoria. Listas de discussão, palestras em conferências e documentação são saudáveis para ambos.

Na nossa experiência, a escolha entre Kamailio e OpenSIPS raramente se resume a um recurso que um tem e o outro não. Trata-se de qual modelo mental se alinha com o da sua equipe, com o que seu ferramental operacional já parece, e o que você quer que a camada de roteamento assuma versus delegue.

O Padrão Híbrido: Proxy na Frente, Servidor de Mídia Atrás

Esta é a arquitetura para a qual a maioria das grandes plataformas de voz open-source converge, e é a conclusão prática mais importante da comparação entre essas três plataformas.

O padrão funciona assim. Um par de instâncias Kamailio ou OpenSIPS roda em ativo-standby com IP flutuante no ponto de entrada SIP. Eles gerenciam registros, autenticam assinantes, aplicam políticas por conta, realizam balanceamento de carga e roteiam a maioria das chamadas. Para chamadas que precisam de serviços de mídia (IVR, conferência, gravação, transcoding), o Kamailio encaminha a chamada para um pool de servidores de mídia FreeSWITCH e distribui a carga entre eles. A camada proxy carrega o peso da sinalização em CPS muito alto; a camada de mídia escala horizontalmente adicionando instâncias FreeSWITCH.

O padrão aparece consistentemente em produção. Uma operadora latino-americana de terceirização de processos de negócio com quem conversamos recentemente roda infraestrutura IBM Cloud com Kamailio em pares ativo-standby, na frente de 31 servidores de mídia FreeSWITCH dedicados que juntos tratam cerca de 60.000 chamadas simultâneas a aproximadamente 1.000 chamadas por segundo para um único grande cliente. O pico total da plataforma é de aproximadamente 300.000 chamadas por minuto. A separação entre Kamailio para sinalização e FreeSWITCH para mídia é o que permite à arquitetura escalar: nenhuma plataforma é requisitada para trabalho que a outra faz melhor, e cada uma pode ser escalada horizontalmente em seu próprio eixo.

Operadoras menores rodam o mesmo padrão com números menores. A razão pela qual a arquitetura sobrevive em diferentes escalas é que a divisão de trabalho está correta: sinalização e mídia têm perfis de desempenho diferentes, modos de falha diferentes e comportamentos de escala diferentes, e tentar tratar ambos dentro de um único processo gera contenção.

Escolhendo Entre Elas por Caso de Uso

Para equipes tomando a decisão de plataforma, a escolha geralmente se mapeia de forma clara ao papel que cada componente desempenha.

• Registrar, balanceador de carga SIP ou front end de roteamento de alto CPS: Kamailio ou OpenSIPS. Ambos funcionam. Escolha com base em qual modelo de scripting e filosofia operacional se encaixa na sua equipe.
• IVR, conferência, gravação, transcoding ou qualquer função de mídia ancorada: FreeSWITCH. Combine com um proxy na frente para escalar.
• Normalização de sinalização de nível operadora com scripting rico em Python ou Lua: Kamailio com KEMI.
• Roteamento SIP com recursos B2BUA nativos e linguagem procedural de scripts de roteamento: OpenSIPS.
• Plataforma estilo CPaaS com controle programável de chamadas e alta concorrência: Kamailio ou OpenSIPS na borda, FreeSWITCH para mídia, sua lógica de aplicação conversando com ambos via Event Socket e HTTP.
• Plataforma puramente de controle de chamadas sem carga de trabalho de mídia: um proxy sozinho é suficiente. Isso é raro em produção, mas existe para algumas implantações específicas voltadas exclusivamente para roteamento.

Nenhuma Delas É um SBC: A Realidade do SBC Feito por Conta Própria

Kamailio combinado com RTPengine, ou OpenSIPS combinado com RTPproxy, é frequentemente descrito como um SBC construído por conta própria. Para uma definição estreita de SBC (roteamento de sinalização, travessia básica de NAT, relay de mídia), essa descrição se sustenta. A pilha funciona, e para algumas implantações é a arquitetura correta.

Para implantações que precisam fazer o que um SBC de produção realmente deve fazer, a lacuna entre a pilha feita por conta própria e um SBC construído para esse fim se amplia rapidamente. As funções que precisam ser engenheiradas, integradas, mantidas e suportadas por conta própria incluem as seguintes.

Assinatura, atestação e verificação STIR/SHAKEN com failover primário e secundário do STI-AS, decisão de nível de atestação por chamada e o mapeamento de razão-causa necessário quando o serviço de assinatura retorna uma resposta de não-sucesso. O padrão de integração com SIP redirect-server usado por TransNexus ClearIP e Neustar (que é como toda implantação real de STIR/SHAKEN funciona hoje) requer lógica de roteamento que trate 302 (avançar rota com cabeçalho Identity), 404 e 503 (continuar chamada) e 603 (parar chamada) de forma consistente.

Pontuação de fraude programável em tempo real contra serviços externos. Avaliação de risco por chamada, lista de bloqueio dinâmica, integração com APIs de pontuação da TransNexus, YouMail e SecureLogix, e lógica de roteamento para tomar decisões durante a chamada antes que ela se estabeleça.

Mitigação de DoS e DDoS de nível operadora. Limitação de taxa consciente de SIP por origem, por tronco e por método; validação de protocolo que descarta mensagens malformadas antes que toquem sua lógica de roteamento; detecção de varredura de registro que distingue padrões de re-registro legítimos de ataques; greylisting baseado em porcentagem para resposta gradual durante investigação.

Normalização SIP multi-vendor alimentada por um motor de manipulação de cabeçalhos que pode ser reconfigurado por grupo de troncos sem edições de script. Combinações de vendors mudam conforme operadoras atualizam suas plataformas, e o custo de manutenção de uma camada de reescrita de cabeçalhos artesanal atualizada para dezenas de peers se acumula rapidamente.

Ocultação de topologia consistente entre sinalização e mídia. CDRs por perna com métricas de qualidade, traps SNMP, API RESTful de gerenciamento, captura Wireshark ao vivo e o ferramental operacional que o suporte de produção realmente utiliza.

Suporte do vendor, contratos de nível de serviço (SLA), propriedade do ciclo de vida de certificados e responsabilidade de roadmap. Nada disso existe quando a equipe que opera a plataforma é a mesma que recebe chamados às 3 da manhã.

O padrão que vemos com mais frequência é o de operadoras que construíram uma camada de SBC por conta própria anos atrás e eventualmente a substituíram porque o custo de manutenção superou a economia. A decisão geralmente se cristaliza quando STIR/SHAKEN, uma nova integração de operadora ou uma auditoria de segurança cria uma carga de trabalho que a pilha existente não consegue absorver sem um projeto de engenharia de vários trimestres.

Onde o ProSBC Se Encaixa

ProSBC é um SBC B2BUA da TelcoBridges. Ele não compete com Kamailio ou OpenSIPS pelo papel de motor de roteamento, e não compete com FreeSWITCH para IVR ou funções de servidor de mídia. Ele fica na borda da rede na frente de qualquer uma dessas plataformas que sua arquitetura use, tratando as funções de segurança, normalização e conformidade que a pilha open-source deixa por sua conta.

Em produção, esse posicionamento se manifesta em um de três padrões. Na frente do FreeSWITCH para interconexão com operadoras, onde o ProSBC termina SIP externo, executa assinatura e verificação STIR/SHAKEN, normaliza os cabeçalhos SIP que cada operadora exige e entrega SIP limpo para a plataforma de mídia. Ao lado do Kamailio quando a equipe quer Kamailio para roteamento interno mas não quer construir a camada SBC em script. Substituindo o padrão “Kamailio fazendo trabalhos demais” quando uma única instância acumulou responsabilidades de segurança, fraude e conformidade para as quais nunca foi projetada.

As capacidades verificadas do ProSBC cobrem as lacunas que a pilha feita por conta própria deixa abertas. Arquiteturalmente é um B2BUA, com terminação SIP completa e re-originação em ambas as pernas e ocultação de topologia consistente entre sinalização e mídia. Números de escala do folheto atual listam até 60.000 sessões simultâneas por servidor, até 350.000 registros de terminais e até 1.024 Pontos de Acesso de Rede (grupos de troncos) por servidor. As funções de segurança cobrem SIP sobre TLS, SRTP, proteção contra DoS e DDoS, lista de bloqueio dinâmica com greylisting baseado em porcentagem e proteção contra varredura de registro SIP. STIR/SHAKEN é implementado através de integração baseada em SIP com TransNexus ClearIP e Neustar, com failover primário e secundário e a lógica de roteamento de razão-causa que implantações de produção precisam. O motor de roteamento programável em Ruby expõe mais de 100 parâmetros de chamada e suporta consultas externas via HTTP para pontuação de fraude, portabilidade numérica, CNAM e qualquer outro sistema que fale REST.

ProSBC roda em VMware, KVM e Proxmox, AWS e Microsoft Azure, e bare metal, o que significa que pode ser implantado junto a uma pilha existente de Kamailio ou FreeSWITCH sem nova infraestrutura. O preço de assinatura começa a partir de US$ 1,40 por sessão por ano conforme o folheto atual, e um teste gratuito de 30 dias com ativação online permite que a equipe teste o ProSBC na frente da plataforma existente em seu próprio ambiente. A licença ProSBC Lab (permanentemente gratuita, três sessões, sem limite de tempo) estende esse acesso para trabalho contínuo de laboratório e integração.

Uma observação para equipes considerando o ProSBC como substituto direto da função de registrar do Kamailio: o ProSBC não é um registrar SIP independente. Ele escala o encaminhamento de registros e trata a segurança relacionada a registros, mas para grandes bases de dados de registro ou gerenciamento de usuários no lado do PBX, os clientes o combinam com Asterisk, FreePBX ou qualquer PBX que sua arquitetura já utilize. Esta é uma fronteira deliberada entre a camada SBC e a camada PBX, não uma lacuna a ser contornada.

Perguntas Frequentes

Conclusão

Kamailio, OpenSIPS e FreeSWITCH resolvem problemas diferentes na pilha de voz open-source. Kamailio e OpenSIPS são motores de roteamento SIP para sinalização de alto CPS, registro e balanceamento de carga. FreeSWITCH é uma plataforma de mídia B2BUA para IVR, conferência, transcoding e gravação. A arquitetura correta para a maioria das plataformas de produção não é uma das três, é uma combinação: um proxy na frente para sinalização, servidores de mídia atrás para mídia, e um SBC na borda para tudo que toca o mundo externo.

Se você está dimensionando uma nova plataforma, comece pelo papel que cada componente desempenha na sua arquitetura em vez da comparação entre plataformas. Quando você souber quais tarefas está delegando a um proxy e quais a um servidor de mídia, a escolha entre Kamailio e OpenSIPS se torna uma questão de adequação à equipe, e a escolha de onde traçar a linha entre sua camada open-source e a camada SBC se torna uma decisão de construir-versus-comprar que é muito mais fácil de tomar a partir de um ponto de partida arquitetural do que de uma lista de recursos.