Servidores SIP de código aberto são frequentemente agrupados como se resolvessem os mesmos problemas da mesma forma. Na prática, ocupam posições bem diferentes em uma arquitetura de comunicações em tempo real. Alguns são otimizados para sinalização SIP, registro, roteamento e controle de políticas na borda da rede. Outros são projetados para entregar lógica de PBX, serviços de mídia, conferências, IVR e fluxos de comunicação programáveis. Por isso, uma comparação útil não pode se limitar apenas a listas de funcionalidades. É preciso analisar também o papel arquitetônico de cada plataforma, o tipo de carga de trabalho que ela melhor suporta e sua forma de escalabilidade em ambientes de produção.
Entre as plataformas mais discutidas, Kamailio, OpenSIPS, Asterisk e FreeSWITCH são todas importantes, mas não são intercambiáveis. Kamailio e OpenSIPS são geralmente escolhidos quando há demanda por roteamento SIP de alto desempenho, registro e controle de políticas na camada de sinalização. O Asterisk é amplamente utilizado onde predominam aplicativos de telefonia, serviços de PBX, IVR, filas de chamadas e fluxos de chamadas empresariais. O FreeSWITCH é frequentemente adotado para manipulação de mídia altamente programável, conferências e lógica de comunicação orientada a eventos. Uma comparação justa deve considerar o papel, o perfil de carga e a estratégia de implantação, e não apenas o reconhecimento da marca.

Por que comparar servidores SIP de código aberto é importante
Em muitos projetos, o primeiro erro de arquitetura acontece antes mesmo da implantação. Equipes buscam saber qual é o melhor servidor SIP de código aberto, quando a pergunta correta é qual plataforma se adapta a uma camada específica do sistema. Uma borda de roteamento SIP em larga escala, serviço de registro multi-tenant hospedado, PBX empresarial, núcleo de conferências e plataforma de comunicação orientada a aplicativos impõem demandas diferentes ao software subjacente. Uma plataforma com excelente desempenho como proxy SIP pode não ser a melhor opção para implantações de conferência com alta demanda de mídia, enquanto um sistema voltado para PBX pode não ser a alternativa mais leve ou eficiente para recebimento massivo de sinalização.
Essa distinção se torna ainda mais relevante à medida que o sistema cresce. Implantações pequenas geralmente toleram que uma única plataforma execute múltiplas funções. Já ambientes maiores se beneficiam da separação de responsabilidades. A sinalização SIP, autenticação, registro, controle de topologia e distribuição de carga podem ficar na borda, enquanto servidores de aplicativos e plataformas de mídia operam em segundo plano. Quando as equipes adotam essa abordagem em camadas desde o início, tomam decisões de projeto mais assertivas, evitam expectativas irreais de desempenho e criam sistemas mais fáceis de escalar e manter.
A comparação mais prática de servidores SIP de código aberto não é “qual servidor é o melhor?”, e sim “qual componente pertence a qual parte da arquitetura?”.
O que é considerado um servidor SIP de código aberto
Plataformas de sinalização SIP
Algumas plataformas SIP de código aberto são projetadas principalmente para processar sinalização de forma eficiente. Seus pontos fortes incluem registro, roteamento, aplicação de políticas, balanceamento de carga, normalização SIP e comportamento na borda da rede. Nessa categoria, Kamailio e OpenSIPS são os nomes mais relevantes. São especialmente úteis quando a implantação precisa gerenciar um grande volume de registros, distribuir tráfego SIP entre serviços downstream, aplicar lógica de roteamento personalizada ou impor políticas na borda de um ambiente VoIP.
Essas plataformas são escolhidas por serem altamente configuráveis via scripts e se adaptarem bem a estratégias de escalabilidade horizontal. Em vez de embutir toda a lógica de negócio e funções de mídia em um único nó, atuam como camada frontal de sinalização em ambientes de comunicação maiores. Nesse papel, protegem sistemas PBX e de mídia downstream, normalizam o tráfego de múltiplos provedores ou tipos de dispositivos e ajudam operadores a estabelecer uma separação clara entre sinalização de entrada e execução de serviços.
Plataformas de PBX e aplicativos de comunicação
Outra categoria reúne plataformas voltadas para a criação de aplicativos de telefonia e sistemas de comunicação empresarial. O Asterisk é o exemplo mais claro desse grupo. Não é apenas um servidor com suporte a SIP, mas também um framework de comunicação que alimenta sistemas IP PBX, gateways VoIP, serviços de conferência, lógica de filas, correio de voz, IVR e controle personalizado de chamadas. Para organizações focadas em telefonia de escritório, sistemas de filiais, atendimento de chamadas no estilo contact center e fluxos de voz programáveis, esse tipo de plataforma costuma ser mais adequado do que um roteador de sinalização puro.
O tradeoff é simples: o Asterisk oferece funcionalidades de telefonia e comportamento de aplicativos mais ricos em um único ambiente, mas essa conveniência também significa que pode assumir mais responsabilidades relacionadas ao estado das chamadas e mídia do que um proxy SIP puro. Para muitas implantações empresariais e de pequeno e médio porte, essa é a decisão correta. Para sistemas muito grandes com foco intenso em sinalização, é mais eficiente deixar o Asterisk concentrado na lógica de PBX e serviços, enquanto outra plataforma cuida da distribuição SIP frontal.
Motores de comunicação centrados em mídia
Algumas plataformas de código aberto se destacam quando o controle aprofundado de mídia é um requisito central. O FreeSWITCH se encaixa perfeitamente nessa categoria. É amplamente valorizado pela modularidade, padrões de integração orientados a eventos, flexibilidade em conferências e suporte a aplicativos complexos de comunicação em tempo real. Em ambientes onde orquestração de mídia, controle de conferências, lógica de aplicativos personalizada e integração externa são mais importantes do que ser o proxy SIP mais leve possível, o FreeSWITCH se torna uma excelente alternativa.
Isso não significa que o FreeSWITCH se limite apenas a conferências. Ele suporta diversos casos de uso de comunicação mais amplos. O ponto principal é que equipes costumam escolhê-lo quando buscam um motor de telecomunicações programável com forte desempenho em mídia e aplicativos, e não uma plataforma cujo principal diferencial é processar massivamente cargas de sinalização SIP frontal com máxima eficiência.
Comparação de funcionalidades entre as principais plataformas
A comparação direta se torna mais simples quando as plataformas são avaliadas pelo propósito para o qual foram projetadas. A tabela abaixo é elaborada com foco arquitetônico, e não em argumentos de marketing.
| Plataforma | Papel principal | Principais vantagens | Limitações típicas | Ambientes mais adequados |
|---|---|---|---|---|
| Kamailio | Proxy SIP, registrador, camada de roteamento e distribuição | Sinalização de alto desempenho, lógica flexível de scripts de roteamento, balanceamento de carga via dispatcher, controle de borda escalável | Geralmente não é a primeira opção para entrega completa de funcionalidades PBX ou serviços com alta demanda de mídia de forma isolada | Borda de operadora, agregação de troncos SIP, grandes plataformas de registro, roteamento frontal para serviços downstream |
| OpenSIPS | Servidor SIP de nível operacional com foco em clusterização | Sinalização de alta taxa de transferência, lógica modular de roteamento, opções de clusterização, serviços SIP escaláveis | Assim como o Kamailio, destaca-se mais como infraestrutura de sinalização do que como plataforma PBX/mídia all-in-one | Grandes plataformas SIP, sinalização distribuída, cenários de provedores de serviço, roteamento e registro em cluster |
| Asterisk | Framework de aplicativos de comunicação e motor PBX | Lógica de dialplan, IVR, filas de chamadas, correio de voz, serviços PBX, telefonia empresarial, desenvolvimento de aplicativos personalizados | Normalmente não é a opção mais leve para distribuição massiva de SIP frontal quando comparado a plataformas focadas em proxy | PBX empresarial, telefonia para pequenos e médios negócios, aplicativos de fluxo de chamadas, serviços de contact center |
| FreeSWITCH | Motor modular de comunicação em tempo real e mídia | Serviços de conferência, controle de mídia, expansão modular, integração orientada a eventos, fluxos de telecomunicações programáveis | Pode introduzir maior complexidade arquitetônica do que a necessária para implantações simples de PBX | Plataformas de conferência, serviços intensivos em mídia, aplicativos de telecom programáveis, ambientes RTC personalizados |
Roteamento, registro e controle de borda
Kamailio e OpenSIPS se destacam claramente quando o assunto é roteamento, registro e aplicação de políticas na borda da rede. São plataformas utilizadas por operadores para finalizar a sinalização SIP na borda, autenticar requisições, manter dados de localização de usuários, controlar fluxo de tráfego, distribuir carga e direcionar requisições para sistemas de aplicativos ou mídia downstream. Em sistemas grandes, esse papel frontal pode ser mais importante do que qualquer funcionalidade isolada de PBX, pois define a eficiência com que o ambiente absorve carga, isola falhas e aplica regras de roteamento.
Na prática, são frequentemente escolhidos para grandes fazendas de registro, ambientes de interconexão SIP, camadas de sinalização adjacentes a SBC ou plataformas multi-nó, onde a sinalização precisa ser separada da lógica de processamento de chamadas. Seus scripts e módulos permitem alto grau de personalização de políticas, sendo um dos motivos de sua popularidade em implantações de provedores de serviço e plataformas corporativas.
Controle de chamadas, serviços de telefonia e lógica de negócio
O Asterisk se sobressai quando o conjunto de funcionalidades necessário é de um sistema de telefonia, e não apenas uma borda de sinalização. Atendentes automáticos, grupos de toque, filas de chamadas, correio de voz, roteamento por dialplan, comportamento de ramais, gravação de chamadas e integração aos padrões de chamadas empresariais internas são áreas onde o Asterisk permanece extremamente relevante. Ele oferece às equipes um framework maduro para criar serviços de comunicação funcionais rapidamente, especialmente quando o objetivo não é apenas transmitir mensagens SIP, mas moldar a experiência de telefonia voltada ao usuário.
O FreeSWITCH também suporta serviços de chamadas ricos, mas costuma ser escolhido quando o projeto demanda maior programabilidade de mídia, orquestração complexa de chamadas ou comportamento centrado em conferências. Em outras palavras, tanto Asterisk quanto FreeSWITCH vão além do processamento básico de SIP, mas são selecionados por motivos distintos: Asterisk pela familiaridade com fluxos de PBX e aplicativos, FreeSWITCH pela programabilidade centrada em mídia e controle orientado a eventos.
Extensibilidade e integração para desenvolvedores
Todas as quatro plataformas são extensíveis, mas expõem essa capacidade de formas diferentes. Kamailio e OpenSIPS geralmente são expandidos por meio de scripts de roteamento, módulos e integrações com sistemas externos, como bancos de dados, motores de faturamento, servidores de aplicativos e sistemas de provisionamento. Seu diferencial está em permitir que operadores moldem o comportamento da sinalização com alta precisão. Para arquitetos que precisam de lógica SIP personalizada, direcionamento de tráfego, roteamento com reconhecimento de inquilinos ou controle de interoperabilidade frontal, essa flexibilidade costuma ser o fator decisivo.
Por outro lado, Asterisk e FreeSWITCH são frequentemente avaliados por suas interfaces de desenvolvedor e padrões de construção de aplicativos. O modelo de desenvolvimento orientado a REST do Asterisk e a abordagem Event Socket do FreeSWITCH atraem equipes que criam serviços de comunicação personalizados e precisam de controle externo rigoroso. Como resultado, a experiência do desenvolvedor não pode ser comparada de forma genérica entre esses projetos; depende se a equipe precisa estender o comportamento de sinalização ou construir serviços de chamadas e mídia em nível de aplicativo.

Considerações de desempenho em implantações reais
Taxa de sinalização versus carga de mídia
Comparações de desempenho frequentemente enganam por ignorar o tipo de carga de trabalho. Uma plataforma que processa roteamento SIP sem estado ou com leve estado resolve um problema diferente de um sistema que executa aplicativos IVR, faz ponte de chamadas, hospeda conferências ou manipula fluxos de mídia. Plataformas focadas em proxy se saem melhor quando a carga é dominada por taxa de sinalização SIP, processamento de registros ou roteamento de políticas. Já plataformas de PBX e mídia naturalmente consomem mais recursos quando precisam executar mais tarefas relacionadas a estado de chamadas e mídia.
Por isso, afirmações de benchmark devem sempre ser analisadas com cautela. Um servidor pode processar taxas de criação de chamadas muito altas em testes focados em sinalização, enquanto outro pode parecer mais lento apenas porque a carga inclui mais lógica de telefonia ou envolvimento de mídia. A interpretação correta não é que uma arquitetura é universalmente melhor, mas que cada uma atende a responsabilidades distintas. Em produção, o desempenho segue o papel da plataforma.
Comportamento de recursos e sobrecarga arquitetônica
Kamailio e OpenSIPS são geralmente vistos como mais leves para processamento SIP frontal, pois costumam ser implantados com foco em tarefas de sinalização, e não na entrega completa de serviços de telefonia. Asterisk e FreeSWITCH normalmente assumem mais responsabilidades funcionais por nó quando usados para lógica de PBX, conferências, aplicativos de mídia ou execução de serviços. Essa diferença afeta o uso de CPU, padrões de memória, comportamento de latência sob carga e formato dos planos de escalabilidade horizontal.
Para arquitetos, a lição importante é alinhar o perfil do servidor à carga de trabalho esperada. Se o requisito principal é recebimento SIP frontal, registro e distribuição de requisições, uma camada focada em sinalização geralmente entrega um design mais limpo e eficiente. Se for necessário executar funcionalidades de telefonia, lógica de filas, prompts, pontes ou serviços de conferência, as responsabilidades adicionais de aplicativo ou mídia passam a ser um custo esperado da plataforma.
Complexidade operacional e observabilidade
Desempenho não se resume apenas a chamadas por segundo. Envolve também a facilidade de observar, solucionar falhas e manter a plataforma sob carga real. Um proxy de sinalização altamente eficiente ainda precisa de lógica de roteamento bem estruturada, rastreamento e visibilidade operacional. Uma plataforma de PBX ou mídia necessita de controle claro de dialplan ou aplicativos, reconhecimento de codecs e monitoramento de eventos. À medida que os ambientes crescem, a clareza operacional se torna um fator próprio de escalabilidade.
Equipes devem avaliar não apenas a eficiência bruta, mas também a disciplina de configuração, práticas de atualização, maturidade da documentação e adequação da plataforma aos hábitos operacionais da equipe. Uma arquitetura teoricamente mais rápida, mas consistentemente difícil de operar pela equipe, pode não entregar o melhor resultado no mundo real.
Na infraestrutura SIP, o desempenho deve ser medido de acordo com a responsabilidade assumida. Um servidor que executa mais tarefas de telefonia ou mídia não está falhando por consumir mais recursos; ele simplesmente assume uma parte diferente do sistema.
Modelos de escalabilidade e design de alta disponibilidade
Escalabilidade horizontal para sinalização SIP
Quando uma implantação precisa escalar a sinalização SIP de forma horizontal, Kamailio e OpenSIPS são opções especialmente atraentes. Seus padrões de design suportam distribuição de tráfego, compartilhamento ou replicação de informações de localização e criação de camadas SIP frontais que distribuem carga por múltiplos nós downstream. Isso permite que o operador trate a sinalização como uma função escalável de borda, e não como um efeito colateral da própria PBX.
Essa distinção é importante pois o crescimento da sinalização nem sempre exige o mesmo ritmo de crescimento da mídia. O volume de registros pode subir rapidamente, o tráfego de troncos SIP pode se expandir por regiões ou o número de inquilinos pode aumentar enquanto a carga de aplicativos permanece irregular. Uma camada dedicada de sinalização oferece mais liberdade para escalar exatamente onde há pressão de carga.
Escalabilidade de cargas de PBX e mídia
Asterisk e FreeSWITCH também escalam com sucesso, mas a forma de escalabilidade costuma ser diferente. Em vez de simplesmente adicionar mais nós de roteamento frontal, equipes podem distribuir a lógica de serviços por múltiplos servidores de aplicativos, separar funcionalidades específicas ou posicionar esses sistemas atrás de uma camada de sinalização que controla o recebimento e distribuição de requisições. Isso ajuda a manter os nós de PBX ou mídia focados nas tarefas que justificam sua maior densidade funcional.
Por exemplo, uma plataforma de telefonia empresarial em crescimento pode posicionar o Asterisk atrás de proxies SIP, para que o registro de usuários, políticas de entrada e distribuição de troncos upstream não sobrecarreguem a camada de PBX. Da mesma forma, uma plataforma de conferência pode colocar nós FreeSWITCH atrás de uma frontal com reconhecimento de sinalização, para que os recursos de conferência escalem conforme o uso real, enquanto a visão SIP externa permanece controlada e resiliente.
Arquiteturas em camadas para ambientes de produção
Em muitas implantações corporativas sérias, a solução mais escalável é uma arquitetura híbrida. Uma camada focada em sinalização, como Kamailio ou OpenSIPS, fica na borda, cuidando de registro, roteamento, balanceamento de carga e normalização de tráfego. Em segundo plano, o Asterisk entrega lógica de PBX e serviços de telefonia empresarial, enquanto o FreeSWITCH disponibiliza conferências e comportamento de aplicativos centrados em mídia. Esse modelo em camadas reduz conflitos de funções e permite que cada plataforma execute o que faz de melhor.
Essas arquiteturas são comuns pois se alinham aos limites operacionais reais. A camada de borda gerencia políticas SIP e distribuição de tráfego. A camada de serviços cuida de funcionalidades de telefonia ou execução de mídia. Bancos de dados e camadas de provisionamento permanecem separados. Em vez de forçar uma única ferramenta a fazer tudo, o sistema se torna mais fácil de escalar componente por componente.

Cenários mais adequados para cada plataforma
Quando o Kamailio é a melhor opção
O Kamailio é uma excelente escolha quando a prioridade é roteamento SIP de alto desempenho, processamento de registros, envio de tráfego e controle de políticas na borda de sinalização. Se adapta bem a infraestruturas de nível operacional, agregação de troncos SIP, grandes serviços de registro, camadas de interconexão WebRTC-SIP e ambientes de comunicação multi-nó, onde servidores de aplicativos downstream precisam de uma frontal de sinalização estruturada.
Também é uma alternativa natural quando engenheiros precisam de controle refinado sobre o comportamento de roteamento, sem transformar o nó frontal em um servidor completo de aplicativos de telefonia. Nesses casos, o valor do Kamailio vem da eficiência, flexibilidade e separação de responsabilidades.
Quando o OpenSIPS é a melhor opção
O OpenSIPS costuma ser atraente para equipes que buscam um servidor SIP de nível operacional com forte estrutura de clusterização, sinalização de alta taxa de transferência e composição flexível de serviços. Se adapta a infraestruturas SIP multi-nó, serviços de registro distribuídos, controle de entrada em larga escala e plataformas SIP personalizadas que se beneficiam de uma abordagem modular com suporte a clusters. É especialmente indicado onde escalabilidade e manipulação distribuída de estado são preocupações centrais de projeto.
Para equipes que avaliam Kamailio e OpenSIPS, a decisão raramente se resume a qual faz melhor roteamento SIP; geralmente depende da adequação ao projeto, preferência de script, familiaridade com módulos, ecossistema e modelo operacional que a equipe deseja adotar.
Quando o Asterisk é a melhor opção
O Asterisk geralmente é a alternativa mais adequada quando o objetivo é implementar uma PBX funcional ou aplicativo de comunicação, e não apenas uma camada de sinalização. Sistemas de voz corporativos, telefonia interna de escritórios, implantações em filiais, atendentes automáticos, filas de chamadas, correio de voz, casos simples de conferência, fluxos IVR e aplicativos de telefonia personalizados são ambientes onde o Asterisk permanece uma escolha prática.
Também é ideal para equipes que desejam criar serviços de telefonia empresarial rapidamente, com padrões maduros de controle de chamadas e amplo suporte da comunidade. Embora possa integrar-se a arquiteturas maiores, seu valor mais intuitivo aparece onde o comportamento de telefonia é o foco central do projeto.
Quando o FreeSWITCH é a melhor opção
O FreeSWITCH se destaca quando conferências, controle de mídia, comportamento programável de RTC e aplicativos de telecomunicações orientados a eventos são requisitos importantes. Se adapta perfeitamente a sistemas intensivos em mídia, serviços de comunicação multiparticipante, ambientes avançados de conferência e cenários onde aplicativos externos precisam de interação refinada com o motor de comunicação.
Também é a escolha correta quando o projeto precisa de uma pilha de software de telecomunicações versátil, em vez de um foco exclusivo em PBX de escritório. Nesses ambientes, sua modularidade e design voltado para mídia se tornam grandes diferenciais.
Como escolher um servidor SIP de código aberto
O primeiro critério de escolha deve ser o papel arquitetônico. Se o projeto precisa principalmente de sinalização SIP, registro, roteamento e controle de tráfego frontal, opte por Kamailio ou OpenSIPS. Se o requisito principal é funcionalidades de telefonia, lógica de chamadas empresariais e comportamento de PBX, o Asterisk costuma ser o ponto de partida mais natural. Se o projeto gira em torno de conferências, serviços de mídia ou comunicações altamente programáveis orientadas a eventos, vale a pena analisar de perto o FreeSWITCH.
O segundo critério é a estratégia de escalabilidade. Equipes devem analisar se o sistema deverá escalar principalmente em volume de sinalização, uso de mídia/conferências ou complexidade de aplicativos de chamadas ricos em funcionalidades. O terceiro critério é a prontidão operacional. A melhor plataforma é aquela que a equipe consegue implantar, monitorar, atualizar, solucionar falhas e estender de forma consistente ao longo do tempo.
Por fim, é preciso evitar a falsa escolha entre simplicidade de uma única plataforma e complexidade de múltiplas soluções. Em muitos casos, a melhor alternativa é uma arquitetura por etapas. Comece com a plataforma que resolve o gargalo atual e, conforme a carga, número de inquilinos, abrangência geográfica ou diversidade de serviços cresce, implemente a separação em camadas.
Conclusão
Não existe um vencedor universal no cenário de servidores SIP de código aberto, pois essas plataformas não competem pelas mesmas tarefas. Kamailio e OpenSIPS são fortes como infraestrutura de sinalização SIP. O Asterisk permanece eficaz como framework de aplicativos de comunicação e PBX. O FreeSWITCH se destaca por serviços modulares, centrados em mídia e orientados a eventos. A comparação mais confiável não se baseia em popularidade ou benchmarks isolados, e sim na adequação de cada plataforma ao papel arquitetônico que deve desempenhar.
Em ambientes pequenos, uma única plataforma pode atender à maioria dos requisitos de forma satisfatória. Em implantações maiores e mais exigentes, o design mais escalável e fácil de manter geralmente é em camadas. A sinalização é processada na borda por uma plataforma focada em proxy, enquanto funcionalidades de telefonia ou serviços de mídia executam em nós focados em aplicativos. Essa abordagem cria um caminho mais sólido para resiliência, observabilidade e crescimento de longo prazo.
Perguntas Frequentes
Qual a diferença entre Kamailio e OpenSIPS?
Ambos são fortemente voltados para sinalização SIP, roteamento, registro e comportamento escalável na borda da rede. Na prática, a diferença geralmente se resume à abordagem de clusterização, preferência de script, familiaridade com módulos, ecossistema e modelo operacional mais adequado para a equipe. Nenhum deles deve ser rotulado de forma simplista como “melhor ou pior” sem considerar os objetivos da implantação.
O Asterisk é um servidor SIP ou PBX?
O Asterisk suporta SIP, mas é mais corretamente compreendido como framework de comunicação e plataforma voltada para PBX. Seu valor não se limita apenas ao processamento de mensagens SIP. É amplamente utilizado para lógica de dialplan, IVR, filas de chamadas, correio de voz, gateways e serviços mais abrangentes de telefonia empresarial.
O FreeSWITCH é melhor para conferências?
O FreeSWITCH costuma ser uma excelente escolha quando conferências e controle de mídia são prioridades principais. Isso não o torna automaticamente a solução ideal para todo sistema de comunicação, mas é frequentemente preferido em projetos onde o comportamento de conferência, programabilidade de mídia e integração orientada a eventos importam mais do que a eficiência pura de sinalização SIP frontal.
Devo usar uma única plataforma ou combinar várias?
Para ambientes pequenos, uma única plataforma pode ser suficiente. Para implantações maiores ou especializadas, combinar uma plataforma focada em sinalização com nós de PBX ou mídia costuma gerar um design mais escalável. Isso permite que cada componente permaneça focado em suas maiores vantagens.
Qual servidor SIP de código aberto escala melhor?
A resposta honesta é que a escalabilidade depende do que precisa ser escalado. Para crescimento com foco em sinalização, Kamailio e OpenSIPS são excelentes opções. Para expansão de funcionalidades de PBX, o Asterisk pode ser muito eficaz quando inserido na arquitetura correta. Para crescimento centrado em conferências e mídia, o FreeSWITCH costuma ser a alternativa mais adequada. O sistema mais escalável é geralmente aquele cujas responsabilidades foram claramente separadas desde o início.