Kamailio vs OpenSIPS vs FreeSWITCH : choisir une plateforme SIP (et pourquoi vous avez généralement besoin de plus d’une)
Cette comparaison est recherchée comme un match à trois, mais ce n’en est pas vraiment un. Kamailio et OpenSIPS sont des moteurs de routage SIP : des proxies orientés signalisation, conçus pour un débit très élevé en appels par seconde. FreeSWITCH est un Back-to-Back User Agent (B2BUA) avec une pile média complète couvrant le transcodage, le SVI, la conférence et l’enregistrement. Les plateformes sont souvent évoquées ensemble parce qu’elles couvrent des décisions d’ingénierie qui se chevauchent dans l’écosystème voix open source, mais les traiter comme trois produits pairs déforme la vraie question.
La vraie question n’est pas « laquelle de ces trois devrais-je déployer ». C’est « comment ces composants doivent-ils se combiner, et où chacun s’insère-t-il dans mon architecture ? » Dans un déploiement de production typique servant des milliers d’appels simultanés, Kamailio ou OpenSIPS se trouve en façade, gérant les enregistrements, la répartition de charge et le routage SIP à haut volume, tandis que FreeSWITCH traite les appels nécessitant de l’intelligence média. Aucune des trois n’est un Session Border Controller (SBC), et supposer que l’une d’elles puisse remplir ce rôle en périphérie du réseau est l’une des erreurs architecturales les plus courantes dans la voix open source.
Cet article couvre ce pour quoi chaque plateforme est conçue, en quoi Kamailio et OpenSIPS diffèrent réellement, pourquoi le modèle hybride avec FreeSWITCH domine les déploiements de production, et ce que la pile SBC faite maison couvre et ne couvre pas.
La séparation architecturale : proxies vs serveurs média
Kamailio et OpenSIPS sont des proxies et des moteurs de routage SIP. Dans leur mode par défaut, ils traitent la signalisation SIP, prennent des décisions de routage, modifient les en-têtes, appliquent des politiques et transmettent la requête, mais ils ne touchent pas au chemin média. L’audio (RTP) circule entre les terminaux directement, ou à travers un processus de relais média séparé tel que RTPengine ou RTPproxy que le proxy contrôle.
FreeSWITCH est un B2BUA. Il termine un appel SIP d’un côté, génère un nouvel appel de l’autre côté, et se trouve à la fois dans le chemin de signalisation et dans le chemin média pendant toute la durée de l’appel. C’est cette position qui permet à FreeSWITCH de faire des choses que les proxies ne peuvent pas faire nativement : transcoder les codecs, jouer des annonces, enregistrer l’audio, mixer des conférences, ancrer le chiffrement et exécuter la logique SVI sur le flux média en direct.
Cette différence architecturale détermine presque tout le reste concernant les plateformes. Un proxy SIP est rapide et léger parce qu’il ne transporte pas les médias. Un serveur média est plus lourd par appel parce qu’il le fait. Nous avons couvert les mécanismes proxy-versus-B2BUA en profondeur (Via, Route, Record-Route, sans état versus avec état, ce qu’un proxy peut et ne peut pas réécrire) dans notre analyse de l’architecture proxy SIP. En résumé : transmettre est un ensemble d’opérations, terminer en est un autre, et les possibilités offertes par chacun sont fondamentalement différentes.
Kamailio en détail
Kamailio est issu du projet SIP Express Router (SER) en 2008 et est activement développé depuis. Il est largement déployé comme cœur de routage SIP dans les réseaux opérateur, les plateformes PBX hébergées et les piles Communications-Platform-as-a-Service (CPaaS) où la priorité de conception est de déplacer de très grands volumes de signalisation SIP avec une latence prévisible.
La plateforme est configurée via kamailio.cfg, un langage de script dédié qui se lit comme un programme contraint de style C : des blocs pour le traitement des requêtes, des blocs de route pour la logique de routage, des chargements de modules en tête de fichier. Pour les équipes qui souhaitent écrire la logique de routage d’appels dans un langage généraliste, Kamailio propose le Kamailio Embedded Interface (KEMI), qui expose le même modèle de routage à Lua, Python, JavaScript et Ruby. Une équipe disposant d’un outillage Python solide peut écrire l’intégralité de la couche de routage en Python tout en conservant les caractéristiques de performance de Kamailio.
L’écosystème de modules de Kamailio couvre les composants dont un fournisseur de services a besoin : un registrar SIP qui monte en charge vers de grandes bases d’utilisateurs, un module dispatcher pour la répartition de charge entre les serveurs média dorsaux, un module dialog pour le suivi des appels actifs, des modules de présence et de messagerie instantanée, des modules de comptabilité qui écrivent dans MySQL, PostgreSQL ou Kafka, et une intégration étroite avec RTPengine pour le traitement des médias. Les déploiements en haute disponibilité utilisent généralement des paires actif-passif avec une IP flottante gérée par Keepalived ou Pacemaker.
Les rôles courants de Kamailio incluent servir de registrar pour des centaines de milliers d’abonnés, agir comme frontal de signalisation à haut CPS pour une plateforme PBX hébergée ou CPaaS, et fournir le cerveau de routage devant une flotte de serveurs média. La réputation de performance de la plateforme est méritée, bien que les chiffres spécifiques d’appels par seconde dépendent fortement du matériel, de la configuration et de ce que chaque transaction doit faire.
OpenSIPS en détail
OpenSIPS est également issu de SER en 2008. Les deux projets ont divergé autant sur la philosophie que sur le code, et les différences se sont accentuées au fil du temps. OpenSIPS privilégie une approche plus intégrée et clé en main du routage SIP, avec des modules natifs couvrant un territoire que Kamailio laisse à des outils externes.
L’architecture d’OpenSIPS 3.x utilise un modèle multi-processus avec mémoire partagée pour l’état, similaire à Kamailio dans sa structure mais avec des valeurs par défaut différentes. La logique de routage est écrite dans le langage de script procédural propre à la plateforme, qui ressemble davantage à un petit langage de programmation impératif qu’au format de type configuration de Kamailio. Le script dispose d’un flux de contrôle explicite, de variables et d’appels de fonctions, et la plupart des ingénieurs qui travaillent avec les deux rapportent que les scripts de routage d’OpenSIPS sont plus faciles à lire sur la durée mais plus difficiles à interfacer avec des langages externes.
Deux éléments se distinguent dans l’ensemble de modules d’OpenSIPS. Le module B2BUA natif de la plateforme est plus développé que celui de Kamailio, ce qui signifie qu’OpenSIPS peut agir comme Back-to-Back User Agent pour des flux d’appels spécifiques sans ajouter un composant séparé. Les modules d’intégration HTTP et REST sont également riches, faisant d’OpenSIPS un choix confortable pour la logique de routage qui dépend d’appels API externes : vérifications de fraude, requêtes de portabilité des numéros, contrôles de facturation en temps réel. Le panneau de contrôle OpenSIPS fournit une interface de gestion web que certaines équipes trouvent utile pour la visibilité et les opérations de base, bien que les déploiements sérieux pilotent toujours la configuration via le script.
Les rôles d’OpenSIPS incluent le routage SIP à haut volume, le contrôle de session léger avec B2BUA natif lorsque l’architecture le demande, la signalisation pour les systèmes de comptabilité et de facturation, et tout déploiement où l’équipe préfère une plateforme plus autonome plutôt qu’une qui délègue des parties à des outils externes.
Kamailio vs OpenSIPS : ce qui diffère réellement
Pour les ingénieurs qui choisissent entre les deux, voici ce qui compte en pratique.
Le modèle de script est la première divergence. Le langage de configuration natif de Kamailio plus KEMI donne à la plateforme un pont propre vers Lua, Python, JavaScript et Ruby. Si votre équipe écrit ses outils opérationnels en Python et souhaite que la couche de routage vive dans le même langage, Kamailio est le choix le plus naturel. OpenSIPS conserve la logique de routage dans son propre langage et demande à l’équipe de l’apprendre ; les équipes qui apprécient un format procédural unique et cohérent à l’intérieur du serveur SIP lui-même préfèrent souvent cette approche.
La capacité B2BUA est la deuxième. OpenSIPS dispose d’un module B2BUA natif plus développé. Si vos exigences de routage incluent un comportement B2BUA pour des flux spécifiques (gestion des re-INVITE, manipulation des segments d’appel, forking structuré), OpenSIPS gère davantage de cela sans composants externes. Kamailio est plus purement proxy et s’associe à des outils séparés lorsque la sémantique B2BUA est nécessaire.
L’intégration externe couvre le troisième axe. Les deux plateformes peuvent interroger des systèmes externes via HTTP pour les décisions de routage. Les modules REST d’OpenSIPS sont matures dès l’installation ; les capacités équivalentes de Kamailio sont tout aussi capables mais plus couramment accédées via des scripts KEMI qui encapsulent le client HTTP de votre langage.
La philosophie des modules façonne le quatrième axe. Kamailio penche vers le modulaire et délègue agressivement aux composants externes (RTPengine pour les médias, bases de données séparées pour l’état, KEMI pour la logique non triviale). OpenSIPS intègre davantage de fonctionnalités dans son ensemble de modules natifs. Aucune des deux philosophies n’est erronée, mais elles orientent les équipes vers des modèles opérationnels différents.
Communauté et cadence de publication sont à peu près comparables. Les deux projets ont des communautés actives, des publications régulières et un soutien commercial stable à travers des services de formation et de conseil. Les listes de diffusion, les conférences et la documentation sont saines pour les deux.
D’après notre expérience, le choix entre Kamailio et OpenSIPS se résume rarement à une fonctionnalité que l’un possède et l’autre non. Il se résume au modèle mental avec lequel votre équipe s’aligne, à ce à quoi ressemble déjà votre outillage opérationnel, et à ce que vous voulez que la couche de routage prenne en charge elle-même ou délègue.
FreeSWITCH dans ce contexte
FreeSWITCH trouve sa place dans cette comparaison non pas comme une troisième option pour le même travail, mais comme la plateforme vers laquelle vous vous tournez quand les proxies ne peuvent pas faire le travail. FreeSWITCH termine le SIP, ancre les médias, transcode les codecs, exécute des dialplans, joue des annonces, mixe des conférences, enregistre les appels et expose l’Event Socket Library (ESL) pour un contrôle externe complet des sessions en cours. Rien de tout cela n’est ce pour quoi un proxy SIP est conçu.
Les caractéristiques architecturales et opérationnelles de FreeSWITCH (son modèle de threading, son enveloppe de montée en charge, le support WebRTC, la licence sous Mozilla Public License) sont bien documentées dans la littérature de la téléphonie open source. Plutôt que de répéter ce contenu ici, le point pertinent pour cet article est ce à quoi sert FreeSWITCH dans le contexte de Kamailio et OpenSIPS : le moteur média dorsal qui traite la petite fraction d’appels de toute plateforme donnée qui nécessitent une véritable intelligence média.
Le modèle hybride : proxy en façade, serveur média en arrière-plan
C’est l’architecture vers laquelle la plupart des grandes plateformes voix open source convergent, et c’est la leçon pratique la plus importante de la comparaison de ces trois plateformes.
Le modèle se présente ainsi. Une paire d’instances Kamailio ou OpenSIPS fonctionne en actif-passif avec une IP flottante au point d’entrée SIP. Elles gèrent les enregistrements, authentifient les abonnés, appliquent les politiques par compte, répartissent la charge et routent la plupart des appels. Pour les appels nécessitant des services média (SVI, conférence, enregistrement, transcodage), Kamailio transmet l’appel à un pool de serveurs média FreeSWITCH et répartit la charge entre eux. La couche proxy porte le poids de la signalisation à très haut CPS ; la couche média monte en charge horizontalement en ajoutant des instances FreeSWITCH.
Ce modèle apparaît de manière constante en production. Un opérateur d’externalisation de processus métier en Amérique latine avec qui nous avons échangé récemment exploite une infrastructure IBM Cloud avec Kamailio en paires actif-passif, devant 31 serveurs média FreeSWITCH dédiés qui gèrent ensemble environ 60 000 appels simultanés à environ 1 000 appels par seconde pour un seul grand client. Le pic total de leur plateforme est d’approximativement 300 000 appels par minute. La séparation entre Kamailio pour la signalisation et FreeSWITCH pour les médias est ce qui permet à l’architecture de monter en charge : aucune des deux plateformes n’est sollicitée pour un travail auquel l’autre est mieux adaptée, et chacune peut être dimensionnée horizontalement sur son propre axe.
Les opérateurs plus petits utilisent le même modèle à des volumes inférieurs. La raison pour laquelle l’architecture survit à toutes les échelles est que la division du travail est correcte : la signalisation et les médias ont des profils de performance différents, des modes de défaillance différents et des comportements de montée en charge différents, et essayer de gérer les deux dans un seul processus crée de la contention.
Architecture de référence pour une plateforme voix open source haute densité : ProSBC en périphérie côté opérateur gère la sécurité, la normalisation et STIR/SHAKEN ; Kamailio se place derrière comme frontal de routage SIP et registrar ; les instances FreeSWITCH derrière Kamailio gèrent les fonctions d’ancrage média. Cliquez pour agrandir.
Choisir entre eux selon le cas d’usage
Pour les équipes qui prennent la décision de plateforme, le choix se mappe généralement de manière nette au rôle que chaque composant joue.
- Registrar, répartiteur de charge SIP ou frontal de routage à haut CPS : Kamailio ou OpenSIPS. Les deux fonctionnent. Choisissez en fonction du modèle de script et de la philosophie opérationnelle qui conviennent à votre équipe.
- SVI, conférence, enregistrement, transcodage ou toute fonction d’ancrage média : FreeSWITCH. Associez-le à un proxy en amont pour la montée en charge.
- Normalisation de signalisation de niveau opérateur avec un scripting riche en Python ou Lua : Kamailio avec KEMI.
- Routage SIP avec fonctionnalités B2BUA intégrées et un langage de script de routage procédural : OpenSIPS.
- Plateforme de type CPaaS avec contrôle d’appel programmable et haute simultanéité : Kamailio ou OpenSIPS en périphérie, FreeSWITCH pour les médias, votre logique applicative communiquant avec les deux via Event Socket et HTTP.
- Plateforme de contrôle d’appel pur sans charge média du tout : un proxy seul suffit. C’est rare en production mais existe pour certains déploiements exclusivement de routage.
Aucun des trois n’est un SBC : la réalité du SBC fait maison
Kamailio associé à RTPengine, ou OpenSIPS associé à RTPproxy, est souvent décrit comme un SBC fait maison. Pour une définition étroite du SBC (routage de signalisation, traversée de NAT basique, relais média), cette description tient. La pile fonctionne, et pour certains déploiements c’est la bonne architecture.
Pour les déploiements qui ont besoin de faire ce qu’un Session Border Controller de production est réellement censé faire, l’écart entre la pile fait maison et un SBC construit à cet effet s’élargit rapidement. Les fonctions qui doivent être conçues, intégrées, maintenues et supportées par vos soins incluent les suivantes.
La signature, l’attestation et la vérification STIR/SHAKEN avec basculement STI-AS primaire et secondaire, la prise de décision par niveau d’attestation par appel, et le mappage raison-cause nécessaire lorsque le service de signature renvoie une réponse non réussie. Le modèle d’intégration par serveur de redirection SIP utilisé par TransNexus ClearIP et Neustar (qui est la manière dont tout déploiement STIR/SHAKEN réel fonctionne aujourd’hui) nécessite une logique de routage qui gère les codes 302 (avance de route avec en-tête Identity), 404 et 503 (poursuivre l’appel) et 603 (arrêter l’appel) de manière cohérente.
La notation de fraude programmable en temps réel contre des services externes. L’évaluation du risque par appel, la mise en liste noire dynamique, l’intégration avec les API de notation de TransNexus, YouMail et SecureLogix, et la logique de routage pour prendre des décisions en cours d’appel avant que l’appel ne s’établisse.
L’atténuation DoS et DDoS de niveau opérateur. La limitation de débit SIP par source, par trunk et par méthode ; la validation protocolaire qui rejette les messages mal formés avant qu’ils ne touchent votre logique de routage ; la détection de scan d’enregistrement qui distingue les schémas de ré-enregistrement légitimes des attaques ; le greylisting basé sur des pourcentages pour une réponse graduée pendant l’investigation.
La normalisation SIP multi-équipementier pilotée par un moteur de manipulation des en-têtes reconfigurable par groupe de trunks sans modifications de script. Les combinaisons d’équipementiers changent à mesure que les opérateurs mettent à jour leurs plateformes, et la charge de maintenance d’une couche de réécriture d’en-têtes artisanale, à jour sur des dizaines de pairs, s’accumule rapidement.
Le masquage de topologie cohérent entre signalisation et média. Les CDR par segment avec métriques de qualité, les traps SNMP, une API de gestion RESTful, la trace Wireshark en direct, et l’outillage opérationnel que le support de production utilise réellement.
Le support fournisseur, les accords de niveau de service, la gestion du cycle de vie des certificats et la responsabilité de la feuille de route. Rien de tout cela n’existe lorsque l’équipe qui exploite la plateforme est aussi celle qui est de garde à 3 heures du matin.
Le schéma que nous observons le plus souvent est celui d’opérateurs qui ont construit une couche SBC fait maison il y a des années et l’ont finalement remplacée parce que la charge de maintenance dépassait les économies réalisées. La décision se cristallise généralement lorsque STIR/SHAKEN, une nouvelle intégration opérateur ou un audit de sécurité crée une charge de travail que la pile existante ne peut pas absorber sans un projet d’ingénierie de plusieurs trimestres.
Où ProSBC s’insère
ProSBC est un Session Border Controller B2BUA de TelcoBridges. Il n’est pas en concurrence avec Kamailio ou OpenSIPS pour le rôle de moteur de routage, et il n’est pas en concurrence avec FreeSWITCH pour les fonctions SVI ou serveur média. Il se place en périphérie du réseau devant celle de ces plateformes que votre architecture utilise, gérant les fonctions de sécurité, de normalisation et de conformité que la pile open source vous laisse.
En production, ce positionnement se présente sous l’un de trois schémas. Devant FreeSWITCH pour l’interconnexion opérateur, où ProSBC termine le SIP externe, exécute la signature et la vérification STIR/SHAKEN, normalise les en-têtes SIP que chaque opérateur exige, et transmet du SIP propre à la plateforme média. À côté de Kamailio lorsque l’équipe veut Kamailio pour le routage interne mais ne veut pas construire la couche SBC en script. En remplacement du modèle « Kamailio qui fait trop de choses » lorsqu’une seule instance a accumulé des responsabilités de sécurité, de fraude et de conformité pour lesquelles elle n’a jamais été conçue.
Les capacités vérifiées de ProSBC couvrent les lacunes que la pile fait maison laisse ouvertes. Architecturalement, c’est un B2BUA, avec terminaison et régénération SIP complètes sur les deux segments et masquage de topologie cohérent entre signalisation et média. Les chiffres de capacité de la brochure actuelle indiquent jusqu’à 60 000 sessions simultanées par serveur, jusqu’à 350 000 enregistrements de terminaux et jusqu’à 1 024 Network Access Points (groupes de trunks) par serveur. Les fonctions de sécurité couvrent le SIP sur TLS, le SRTP, la protection DoS et DDoS, la mise en liste noire dynamique avec greylisting basé sur des pourcentages, et la protection contre le scan d’enregistrement SIP. STIR/SHAKEN est implémenté via une intégration basée sur SIP avec TransNexus ClearIP et Neustar, avec basculement primaire et secondaire et la logique de routage raison-cause dont les déploiements de production ont besoin. Le moteur de routage Ruby programmable expose plus de 100 paramètres d’appel et prend en charge les consultations externes via HTTP pour la notation de fraude, la portabilité des numéros, le CNAM et tout autre système qui parle REST.
ProSBC fonctionne sur VMware, KVM et Proxmox, AWS et Microsoft Azure, et en bare metal, ce qui signifie qu’il se déploie aux côtés d’une pile Kamailio ou FreeSWITCH existante sans nouvelle infrastructure. La tarification par abonnement démarre à partir de 1,40 $ par session par an selon la brochure actuelle, et un essai gratuit de 30 jours avec activation en ligne permet à une équipe de tester ProSBC devant sa plateforme existante dans son propre environnement. La licence ProSBC Lab (gratuite en permanence, trois sessions, sans limite de temps) prolonge cet accès pour les travaux de laboratoire et d’intégration continus.
Une remarque pour les équipes qui envisagent ProSBC comme un remplacement direct de la fonction registrar de Kamailio : ProSBC n’est pas un registrar SIP autonome. Il monte en charge le transfert d’enregistrement et gère la sécurité liée à l’enregistrement, mais pour les grandes bases d’enregistrement ou la gestion des utilisateurs côté PBX, les clients l’associent à Asterisk, FreePBX ou le PBX que leur architecture utilise déjà. C’est une frontière délibérée entre la couche SBC et la couche PBX, pas une lacune à contourner.
Questions fréquemment posées
Kamailio est-il meilleur qu’OpenSIPS ?
Ni l’un ni l’autre n’est universellement meilleur. Ils résolvent le même problème général avec des philosophies différentes. L’interface KEMI de Kamailio en fait le choix naturel pour les équipes qui souhaitent écrire la logique de routage en Lua, Python ou JavaScript. OpenSIPS dispose d’un module B2BUA natif plus développé et d’un langage de script de routage procédural que certaines équipes trouvent plus lisible. Le choix se résume généralement à l’alignement opérationnel, pas à la parité fonctionnelle.
Kamailio ou OpenSIPS peuvent-ils remplacer FreeSWITCH ?
Pas pour les fonctions d’ancrage média. Kamailio et OpenSIPS sont des proxies SIP orientés signalisation ; ils ne transcodent pas nativement, n’exécutent pas de SVI sur les médias en direct, ne mixent pas de conférences et n’enregistrent pas. Pour les charges purement de routage et d’enregistrement, ils n’ont pas besoin de FreeSWITCH ; pour tout ce qui nécessite de l’intelligence média, ils s’associent à lui.
Ai-je besoin d’un SBC si j’ai déjà Kamailio plus RTPengine ?
Pour de nombreux déploiements de production, oui. Kamailio plus RTPengine gère le routage de signalisation et le relais média, mais ne couvre pas nativement STIR/SHAKEN avec basculement STI-AS primaire et secondaire, la notation de fraude programmable en temps réel contre des services externes, l’atténuation DoS et DDoS de niveau opérateur avec mise en liste noire dynamique, ni l’outillage opérationnel et la responsabilité fournisseur qu’un SBC construit à cet effet fournit. L’importance de cette lacune dépend des réglementations auxquelles vous êtes soumis, des opérateurs avec lesquels vous vous interconnectez, et de la part de la couche SBC que votre équipe souhaite concevoir et maintenir.
FreeSWITCH peut-il gérer le SIP trunking seul ?
Techniquement oui, mais c’est rarement la bonne architecture pour un volume de production. FreeSWITCH comme seule couche SIP signifie que chaque appel, même ceux qui n’ont besoin d’aucun service média, passe par un B2BUA complet. Le modèle proxy-plus-média existe parce que la séparation de ces préoccupations monte mieux en charge et isole les modes de défaillance.
Quelle est l’architecture de production typique utilisant les trois ?
Kamailio ou OpenSIPS en paires actif-passif au point d’entrée SIP gérant les enregistrements, la répartition de charge et le routage à haut CPS ; des instances FreeSWITCH derrière eux pour tout appel nécessitant des services média ; un SBC en périphérie du réseau pour l’interconnexion opérateur, la sécurité, STIR/SHAKEN et la normalisation SIP. Chaque composant fait ce pour quoi il a été conçu, et chacun peut être dimensionné indépendamment.
Conclusion
Kamailio, OpenSIPS et FreeSWITCH résolvent des problèmes différents dans la pile voix open source. Kamailio et OpenSIPS sont des moteurs de routage SIP pour la signalisation à haut CPS, l’enregistrement et la répartition de charge. FreeSWITCH est une plateforme média B2BUA pour le SVI, la conférence, le transcodage et l’enregistrement. La bonne architecture pour la plupart des plateformes de production n’est pas l’une des trois, c’est une combinaison : un proxy en façade pour la signalisation, des serveurs média derrière pour les médias, et un SBC en périphérie pour tout ce qui touche au monde extérieur.
Si vous dimensionnez une nouvelle plateforme, commencez par le rôle que chaque composant joue dans votre architecture plutôt que par la comparaison de plateformes. Une fois que vous savez quels travaux vous confiez à un proxy et lesquels à un serveur média, le choix de Kamailio versus OpenSIPS devient une question d’adéquation d’équipe, et le choix de l’endroit où tracer la ligne entre votre couche open source et la couche SBC devient une décision construire-versus-acheter bien plus facile à prendre depuis un point de départ architectural que depuis une liste de fonctionnalités.
Testez ProSBC avec votre pile Kamailio, OpenSIPS ou FreeSWITCH
ProSBC est un Session Border Controller logiciel de niveau opérateur, conçu pour se placer devant la pile voix open source que vous exploitez déjà. Il fonctionne comme un B2BUA complet avec une configuration TLS/SRTP indépendante par groupe de trunks, la manipulation des en-têtes SIP, le masquage de topologie et la protection DoS/DDoS inclus dans chaque déploiement.
La plateforme prend en charge jusqu’à 60 000 sessions simultanées et 1 024 groupes de trunks (NAP) par serveur, avec un routage programmable en Ruby pour l’intégration HTTP avec la notation de fraude, les services de signature STIR/SHAKEN et les consultations de portabilité des numéros. ProSBC fonctionne nativement sur AWS et Microsoft Azure, sur VMware, KVM et Proxmox, et en bare metal, de sorte qu’il se déploie aux côtés d’une pile Kamailio ou FreeSWITCH existante sans nouvelle infrastructure.
La tarification par abonnement démarre à partir de 1,40 $ par session par an selon la brochure actuelle. La licence ProSBC Lab est gratuite en permanence avec trois sessions et sans limite de temps, utile pour tester la plateforme contre votre configuration Kamailio ou OpenSIPS existante avant de vous engager.
Vous préférez évaluer par vous-même d’abord ? Commencez votre essai gratuit de 30 jours.