FreeSWITCH vs Asterisk : une comparaison honnête pour les ingénieurs VoIP

FreeSWITCH et Asterisk sont les deux plateformes de téléphonie open source les plus déployées en production aujourd’hui. Les deux sont gratuites, les deux fonctionnent dans de véritables réseaux opérateurs et entreprises, et les deux peuvent gérer aussi bien un PBX de dix postes qu’une plateforme de conférence à plusieurs milliers d’appels. Si vous devez choisir entre les deux, la question est rarement de savoir laquelle est meilleure dans l’absolu. Il s’agit de déterminer laquelle correspond au profil de déploiement qui se trouve devant vous.

Cette comparaison s’adresse aux ingénieurs et aux architectes qui doivent prendre cette décision. Nous aborderons les différences architecturales qui influencent réellement le comportement, les limites d’échelle et le territoire protocolaire que chaque plateforme gère bien, les compromis en matière de licences et d’écosystème, ainsi que la partie de la pile voix qu’aucune des deux plateformes n’a jamais été conçue pour être : la bordure réseau.

Architecture : la différence fondamentale qui conditionne tout le reste

La divergence architecturale entre Asterisk et FreeSWITCH est fondamentale, et la plupart des différences pratiques en découlent.

Asterisk : moteur PBX étroitement intégré

Asterisk a été conçu comme un remplacement de PBX, un processus logiciel unique qui gère la signalisation SIP, le traitement des médias, l’exécution du plan de numérotation et la logique applicative en un seul ensemble étroitement intégré. Le modèle est multithread mais fortement couplé. La configuration passe par des fichiers texte (extensions.conf, sip.conf ou pjsip.conf), et le plan de numérotation est l’abstraction centrale que tout le routage d’appels utilise.

FreeSWITCH : événementiel et modulaire

FreeSWITCH est arrivé plus tard, conçu par des développeurs qui avaient travaillé avec Asterisk et souhaitaient résoudre des limitations architecturales spécifiques. Le résultat est un système événementiel et modulaire où chaque segment d’appel s’exécute dans son propre thread dédié à travers une machine à états (init, routing, execute, hangup, reporting, destroy). La signalisation et le traitement des médias s’effectuent dans des threads séparés. Ce threading par segment d’appel confère à FreeSWITCH un avantage structurel en matière de concurrence que le modèle fortement couplé d’Asterisk ne peut égaler sans compromis significatifs.

Évolutivité et performances

C’est ici que la différence architecturale devient mesurable.

Capacité d’Asterisk

Asterisk a été testé à environ 4 500 appels simultanés sur un serveur bare metal de 48 cœurs à environ 46 % d’utilisation CPU dans un test de charge VitalPBX publié. Le code source contient une limite intégrée proche de ce chiffre, qui peut être relevée par recompilation. En pratique, la plupart des déploiements Asterisk en production fonctionnent bien en dessous de ce plafond. Un PBX exécutant de la conférence, de la messagerie vocale et des applications IVR est généralement à l’aise dans la fourchette de quelques centaines à un petit millier d’appels par serveur, selon le matériel et la complexité du plan de numérotation.

Capacité de FreeSWITCH

FreeSWITCH gère régulièrement des milliers d’appels simultanés sur du matériel correctement dimensionné. Le goulot d’étranglement pratique n’est généralement pas FreeSWITCH lui-même, mais le chemin média RTP sous-jacent : la bande passante disponible et les paquets par seconde sur l’interface réseau. Sur un seul port Ethernet gigabit avec G.711, la limite théorique supérieure se situe autour de 10 500 flux média simultanés, point à partir duquel la capacité réseau cède avant le CPU.

Correspondance profil de déploiement

Asterisk convient aux PBX de petites et moyennes entreprises, aux systèmes IVR, aux serveurs de messagerie vocale, aux standards automatiques et aux applications de file d’attente d’appels où les appels simultanés restent dans les centaines. Cela couvre la majorité de la téléphonie d’entreprise, et Asterisk le gère de manière fiable.

FreeSWITCH convient aux services d’interconnexion opérateur et de jonctions SIP, aux plateformes PBX hébergées multi-tenant, à la conférence à grande échelle incluant la vidéo, aux passerelles WebRTC, et à tout déploiement qui doit planifier des milliers de sessions simultanées sur un seul serveur.

Protocoles, codecs et WebRTC

Les deux plateformes prennent en charge la pile SIP/SDP/RTP et les codecs importants pour la téléphonie d’entreprise, gèrent toutes les deux le DTMF (in-band et RFC 2833), le fax T.38 et la négociation standard de codecs. L’écart se manifeste dans la voix basée sur le navigateur.

Support WebRTC

FreeSWITCH dispose d’un support WebRTC natif et mature, nettement plus complet que celui d’Asterisk. Pour les appels depuis le navigateur, le click-to-call depuis des applications web ou la vidéoconférence intégrée, c’est la fondation la plus solide. Asterisk prend en charge WebRTC via son pilote de canal PJSIP avec SRTP, mais l’implémentation est moins mature et demande plus d’effort de configuration pour atteindre le même résultat. L’analyse détaillée des compromis se trouve dans notre comparaison WebRTC vs SIP.

Vidéoconférence

FreeSWITCH a été conçu avec le traitement des médias comme préoccupation de premier plan, incluant le mixage vidéo multi-participants. Asterisk gère bien la conférence audio (MeetMe, ConfBridge), mais la vidéoconférence à grande échelle n’est pas son point fort.

Pour la jonction SIP traditionnelle voix uniquement, la connexion aux opérateurs, la terminaison PSTN ou l’exécution d’un IVR, les deux plateformes couvrent les protocoles nécessaires sans lacunes significatives.

Expérience développeur et programmabilité

Interfaces d’intégration d’Asterisk

Asterisk expose trois interfaces d’intégration principales : AMI pour la surveillance des événements et l’injection de commandes, ARI pour le contrôle externe des canaux par des applications, et AGI pour le scripting du plan de numérotation. Le plan de numérotation lui-même, écrit dans extensions.conf, est un langage dédié (DSL) dans lequel la plupart des administrateurs deviennent productifs en une à deux semaines.

Le plus grand multiplicateur de force dans l’univers Asterisk est FreePBX, l’interface graphique web open source construite au-dessus d’Asterisk. FreePBX permet aux administrateurs de configurer des jonctions, des postes, des IVR, des groupes d’appels, des conditions horaires et des dizaines d’autres fonctions PBX sans jamais ouvrir un fichier de configuration. Pour les organisations qui veulent un PBX sans expertise approfondie en plan de numérotation, FreePBX réduit considérablement la barrière à l’entrée. Il n’existe pas d’interface graphique équivalente de type FreePBX pour FreeSWITCH.

Programmabilité de FreeSWITCH

FreeSWITCH expose l’Event Socket Library (ESL), qui fournit un contrôle bidirectionnel en temps réel des sessions d’appels depuis n’importe quel langage capable d’ouvrir un socket TCP. Les plans de numérotation peuvent être écrits en Lua, JavaScript, Python ou XML. Le modèle est fondamentalement plus flexible que celui d’Asterisk. Pour une logique de routage d’appels complexe, une intégration en temps réel avec des bases de données externes, ou la construction d’un service de type CPaaS personnalisé, FreeSWITCH offre un contrôle programmatique supérieur avec moins de friction.

Licences, communauté et support commercial

Asterisk : GPL

Asterisk est distribué sous la licence publique générale GNU. Modifier Asterisk et distribuer la version modifiée déclenche l’obligation GPL de rendre le code source disponible sous la même licence. Sangoma, qui a acquis Digium (le créateur original d’Asterisk), propose une option de double licence pour les cas d’utilisation commerciale où les obligations GPL posent problème, ainsi que du support commercial, le produit PBX commercial Switchvox et des modules commerciaux FreePBX.

La communauté Asterisk est la plus importante de la téléphonie open source : des décennies d’archives de listes de diffusion, de publications sur les forums, de tutoriels, de réponses Stack Overflow et de modules tiers. Pour les schémas de déploiement courants, quelqu’un a presque certainement déjà résolu votre problème.

FreeSWITCH : MPL

FreeSWITCH est distribué sous la licence publique Mozilla. La MPL permet l’utilisation dans des produits propriétaires sans les obligations de divulgation du code source de la GPL, une différence significative pour les FSI, les fournisseurs de services gérés et les éditeurs de logiciels construisant des services vocaux commerciaux. SignalWire, fondé par les développeurs originaux de FreeSWITCH, fournit du support commercial, des services FreeSWITCH hébergés dans le cloud et la plateforme SignalWire.

La communauté FreeSWITCH est plus petite que celle d’Asterisk, mais elle tend vers les déploiements de type fournisseur de services et à grande échelle. La documentation s’est considérablement améliorée, bien que la profondeur du contenu communautaire favorise encore Asterisk.

Asterisk ou FreeSWITCH : lequel correspond à votre déploiement ?

Aucune des deux plateformes n’est universellement meilleure. La réponse honnête vient toujours du profil de déploiement. Le tableau ci-dessous associe les profils courants à la plateforme qui leur correspond.

Profil de déploiement	Asterisk	FreeSWITCH
PBX de bureau PME (centaines d’utilisateurs)	Très adapté	Capable, souvent surdimensionné
IVR, messagerie vocale, file d’attente, standard automatique	Éprouvé	Capable
PBX géré par FreePBX	Natif	Pas d’équivalent GUI
PBX hébergé multi-tenant	Échelle limitée	Conçu pour cela
Service de jonctions SIP à haute densité	Plafond plus bas	Architecture adaptée
Vidéoconférence à grande échelle	Limité	Prise en charge native
Passerelle WebRTC	Moins mature	Natif
CPaaS personnalisé / application temps réel	AMI / ARI / AGI	ESL plus flexible
Produit commercial avec licence permissive	GPL contraignante	MPL le permet

Si le délai de déploiement compte plus que la flexibilité architecturale, Asterisk associé à FreePBX vous donne un système téléphonique fonctionnel en une journée. Si la concurrence, la vidéo, WebRTC ou la posture en matière de licences sont la contrainte, FreeSWITCH est la fondation qui ne vous freinera pas par la suite.

Ce qu’aucune des deux plateformes n’a été conçue pour être : un SBC

C’est la partie que la plupart des comparaisons FreeSWITCH vs Asterisk omettent, et elle importe plus que plusieurs des points de comparaison précédents.

FreeSWITCH et Asterisk sont tous deux des moteurs de traitement des appels. Des plateformes PBX conçues pour gérer les plans de numérotation, la logique de routage, la conférence, l’IVR, la messagerie vocale et la gestion applicative des appels. Aucune des deux n’a été conçue pour être un contrôleur de session en bordure (SBC), l’équipement de bordure réseau qui se situe entre l’infrastructure vocale et le monde extérieur.

Lorsque vous connectez l’une ou l’autre plateforme directement aux fournisseurs de jonctions SIP, aux interconnexions opérateurs ou à l’internet public, vous exposez votre moteur de traitement des appels au trafic SIP non fiable. Avalanches d’enregistrements, attaques de balayage SIP, tentatives DDoS, messages SIP malformés provenant d’implémentations opérateurs incompatibles, tentatives d’appels frauduleux pouvant générer des milliers de dollars en charges d’interconnexion avant que quiconque ne s’en aperçoive. Un PBX n’a pas été architecturé pour gérer tout cela.

Ce qu’un SBC dédié gère et qu’un PBX ne peut pas

Le masquage de topologie dissimule les adresses réseau internes aux pairs externes. Sans un SBC dans le chemin, chaque INVITE SIP quittant le PBX expose la topologie IP interne à l’opérateur.

La normalisation SIP traduit entre les implémentations SIP incompatibles des opérateurs. Les formats d’en-têtes, les séquences de négociation de codecs, les méthodes de signalisation DTMF et le comportement des temporisateurs de session varient selon le fournisseur. Le SBC délivre un SIP propre et cohérent au PBX, quel que soit l’opérateur d’où provient l’appel.

La protection DoS et DDoS arrête les avalanches SIP, le balayage d’enregistrements et les attaques volumétriques à la bordure du réseau. Asterisk et FreeSWITCH exposent des ACL basiques, mais aucun des deux n’est renforcé contre les attaques SIP applicatives soutenues comme l’est un SBC conçu à cet effet.

La terminaison TLS et SRTP s’effectue au niveau du SBC, qui chiffre vers les opérateurs et les fournisseurs de jonctions sans obliger le PBX à gérer les chaînes de certificats et la surcharge de chiffrement par session. La référence détaillée se trouve dans notre guide de configuration TLS et SRTP pour SBC.

La protection en temps réel contre la fraude applique une évaluation du risque par appel, une mise en liste noire dynamique et une intégration avec les services de renseignement sur la fraude. Cela relève de la bordure réseau, pas de l’intérieur du PBX.

Pour l’analyse plus large de la frontière entre les moteurs de signalisation SIP open source et les plateformes B2BUA (dont FreeSWITCH et Asterisk) et un SBC commercial, consultez notre panorama des options SBC open source.

L’architecture de référence : PBX + SBC travaillant ensemble

Le déploiement de référence pour tout service vocal en production utilisant Asterisk ou FreeSWITCH place un SBC dédié dans la DMZ. Une interface fait face au WAN (fournisseurs de jonctions SIP, opérateurs, utilisateurs distants), l’autre fait face au LAN protégé où le PBX s’exécute.

Les fournisseurs de jonctions SIP se connectent au SBC, pas au PBX. Le SBC gère la terminaison TLS, la normalisation des en-têtes SIP, la détection de fraude et le contrôle d’accès, puis délivre un SIP propre à l’instance Asterisk ou FreeSWITCH pour le traitement des appels. Le PBX ne voit jamais le SIP externe brut, et la topologie du réseau interne n’est jamais exposée.

Comment ProSBC s’intègre dans cette architecture

ProSBC est un contrôleur de session en bordure (SBC) logiciel de classe opérateur conçu exactement pour ce schéma de déploiement. Il s’exécute sur la même infrastructure que vous utilisez déjà, notamment VMware, KVM/Proxmox, AWS, Microsoft Azure et baremetal, et se déploie donc aux côtés d’une instance Asterisk ou FreeSWITCH existante sans matériel supplémentaire. Avec une capacité allant jusqu’à 60 000 sessions simultanées par serveur et 1 024 NAP (Network Access Points), une seule instance ProSBC peut protéger plusieurs serveurs PBX sur l’ensemble d’un réseau vocal.

Le moteur de routage programmable basé sur Ruby s’intègre à tout système externe via HTTP. Les plateformes de détection de fraude comme TransNexus ClearIP, les services de signature STIR/SHAKEN, les bases de données LNP, ou vos propres systèmes de facturation et de provisionnement s’intègrent tous dans le flux d’appels. La couche SBC devient une partie active et programmable du pipeline de traitement des appels, gérant la sécurité, la conformité et la normalisation multi-opérateur avant que le trafic n’atteigne le PBX.

La tarification par abonnement commence à seulement 1,40 $ par session par an, sans matériel à acheter. L’essai gratuit de 30 jours avec téléchargement immédiat et activation en ligne vous permet d’évaluer ProSBC aux côtés d’un déploiement Asterisk ou FreeSWITCH existant dans votre propre infrastructure. La licence permanente ProLab, qui offre trois sessions sans limite de temps, prolonge cet accès pour les travaux de laboratoire et d’intégration continus.

Questions fréquemment posées

Conclusion

FreeSWITCH et Asterisk sont deux excellentes plateformes de téléphonie open source qui répondent à des profils de déploiement différents. Asterisk est le chemin le plus rapide vers un PBX fonctionnel avec l’écosystème communautaire le plus riche. FreeSWITCH est la plateforme sur laquelle construire lorsque l’échelle de classe opérateur, WebRTC ou le contrôle programmatique complet du traitement des appels sont les exigences.

Quelle que soit la plateforme choisie, connectez-la au monde extérieur via un SBC dédié. Le PBX gère les plans de numérotation et les applications. Le SBC gère la sécurité, la normalisation, la conformité et la prévention de la fraude à la bordure du réseau. Cette séparation est la façon dont les réseaux vocaux de production restent sécurisés et fiables.