Options SBC open source : ce qui existe vraiment et quand c’est le bon choix

L’expression « SBC open source » suggère un projet unique que l’on peut télécharger, installer et placer en bordure de son réseau voix comme on déploierait un Session Border Controller commercial. Ce produit n’existe pas. Ce qui existe, c’est un ensemble de moteurs de signalisation SIP open source, de moteurs média et d’outils complémentaires qui, correctement assemblés et renforcés, peuvent remplir la même fonction. Le coût de licence de cette pile est nul. Le coût d’ingénierie et d’exploitation ne l’est pas.

Cette page cartographie les options open source réalistes, décrit ce que chaque composant fait réellement, détaille ce que vous devez construire vous-même pour atteindre la parité fonctionnelle avec un SBC commercial, et vous aide à déterminer si construire, acheter ou adopter une approche hybride est le bon choix pour votre équipe.

Pourquoi il n’existe pas de SBC open source unique

Un SBC commercial est un produit intégré. La signalisation SIP, le traitement média, la sécurité, le routage, la détection de fraude, l’intégration STIR/SHAKEN, la surveillance et la haute disponibilité sont conçus et testés ensemble, livrés sous forme d’un seul artefact et supportés par un unique fournisseur.

L’open source télécom a évolué différemment. La couche de signalisation et la couche média se sont développées comme des projets séparés, écrits dans des langages différents, avec des cadences de publication, des communautés et des philosophies de conception distinctes. OpenSIPS et Kamailio sont des descendants directs du SIP Express Router original, optimisés pour le traitement SIP à haut débit. RTPengine et rtpproxy ont été conçus comme des gestionnaires média complémentaires, car les serveurs SIP ne touchent pas du tout au RTP. FreeSWITCH et Asterisk ont été conçus comme des plateformes de téléphonie orientées média, et non comme des SBC de bordure, bien que les deux puissent être configurés pour remplir ce rôle.

Un « SBC open source » est donc une pile que l’opérateur assemble. Le coût de licence de chaque composant est nul. Le travail d’intégration, le renforcement opérationnel, les mises à jour à travers de multiples projets, la cadence de sécurité, l’intégration de la signature STIR/SHAKEN et le support en production sont tous du travail d’ingénierie que l’opérateur assume.

Les options SBC open source réalistes

Les six projets ci-dessous sont ceux vers lesquels les équipes se tournent concrètement lorsqu’elles veulent exploiter un SBC sur un logiciel open source. Ils se répartissent en deux groupes : les moteurs de signalisation SIP qui nécessitent un moteur média séparé, et les plateformes capables de gérer le média qui peuvent assurer seules le rôle de SBC en mode B2BUA.

OpenSIPS

OpenSIPS est un proxy et moteur de routage SIP optimisé pour la signalisation à l’échelle des opérateurs. Il gère l’enregistrement, le routage, la répartition de charge, la traversée NAT et les politiques de sécurité de base à des taux de transactions élevés. Le modèle de configuration utilise son propre langage de script, puissant mais peu familier pour les équipes sans expérience préalable d’OpenSIPS.

OpenSIPS ne gère pas le RTP. Pour ancrer le média, transcoder les codecs ou terminer le SRTP, vous l’associez à RTPengine ou rtpproxy sur le même hôte ou un hôte adjacent. Le remplacement en fin de vie des déploiements OpenSIPS est un facteur récurrent des évaluations de SBC commerciaux, car la complexité opérationnelle s’accumule au fur et à mesure que le déploiement grandit.

Kamailio

Kamailio partage la lignée et l’architecture d’OpenSIPS. C’est un serveur SIP, pas un B2BUA, avec un écosystème de modules différent et un style de configuration légèrement distinct. Kamailio est largement utilisé comme frontal SIP dans les déploiements de grande envergure chez les opérateurs et les plateformes CPaaS, souvent en paires actif/passif avec des IP flottantes pour la redondance.

Comme OpenSIPS, Kamailio s’appuie sur un moteur média compagnon pour le RTP. Les équipes exploitant Kamailio à grande échelle écrivent généralement leurs propres bibliothèques de configuration, déploient fail2ban ou des limiteurs de débit personnalisés pour la protection DoS, et intègrent des systèmes externes pour la signature STIR/SHAKEN et le scoring de fraude. La couche de signalisation est solide ; tout ce qui l’entoure est la responsabilité de l’opérateur.

drachtio

drachtio offre un serveur SIP programmable contrôlé depuis des applications Node.js. Au lieu de modifier un fichier de configuration dans un langage de script dédié, l’opérateur écrit une application JavaScript ou TypeScript qui reçoit les événements SIP et décide quoi en faire. drachtio est associé à RTPengine ou FreeSWITCH pour le média.

drachtio convient aux équipes qui utilisent déjà une pile Node.js et veulent que la couche SIP ressemble à une application qu’elles maîtrisent. Il ne fournit pas d’outillage de sécurité, de surveillance ou de protection DoS de niveau opérateur par défaut. Ces couches restent à construire par l’opérateur.

RTPengine

RTPengine est le compagnon de traitement média le plus courant pour Kamailio et OpenSIPS. Il fonctionne comme un démon séparé auquel le serveur SIP envoie des signaux, lui indiquant de relayer ou de transcoder le média pour chaque appel. RTPengine gère le SRTP, ICE, le transcodage de base et la capture de paquets. C’est un composant média, pas un SBC complet.

FreeSWITCH comme SBC

FreeSWITCH est une plateforme de téléphonie orientée média qui fonctionne comme un B2BUA. Elle gère nativement SIP, RTP, SRTP, WebRTC et le transcodage de codecs, ce qui en fait la correspondance la plus proche d’un SBC mono-projet par rapport à OpenSIPS ou Kamailio. Des fournisseurs de services en Amérique latine et ailleurs ont déployé FreeSWITCH en bordure de réseau pour du trafic à l’échelle opérateur.

Le compromis est que FreeSWITCH a été conçu comme un serveur média et une plateforme de conférence. L’utiliser comme SBC exposé sur l’internet public implique de renforcer la configuration contre les attaques par inondation SIP, de construire soi-même la limitation de débit et la protection contre le balayage d’enregistrement, d’intégrer un service externe de signature STIR/SHAKEN et de développer la couche de surveillance dont votre équipe d’exploitation a besoin. Si vous avez déjà choisi FreeSWITCH pour votre pile, le réutiliser comme SBC est raisonnable. Si ce n’est pas le cas, commencer par FreeSWITCH pour son coût de licence représente un engagement plus important que ce que la page de téléchargement laisse entendre.

Asterisk comme SBC

Asterisk est la plateforme de téléphonie open source la plus déployée au monde. Elle fonctionne comme un B2BUA et gère à la fois la signalisation et le média. Des configurations SBC basées sur Asterisk existent, souvent construites autour du pilote de canal chan_pjsip, et l’écosystème FreePBX a intégré une partie de cette fonctionnalité.

Pour les déploiements mono-locataire à faible volume où Asterisk est déjà dans la pile, traiter Asterisk comme le SBC garde l’architecture simple. À l’échelle opérateur, dans les environnements multi-locataires ou là où la protection DoS et l’isolation du routage par locataire comptent, Asterisk nécessite un travail externe significatif pour atteindre le profil opérationnel qu’un SBC commercial offre d’emblée.

Ce que vous construisez vs ce que vous obtenez

Fonctionnalité	Pile open source	SBC commercial (ex. : ProSBC)
Signalisation SIP	Incluse	Incluse
Architecture B2BUA	FreeSWITCH/Asterisk oui ; Kamailio/OpenSIPS non	B2BUA complet
Ancrage média, SRTP, transcodage	Composant séparé ou natif à FS/Asterisk	Natif
Moteur de manipulation d’en-têtes SIP	Scripté dans le langage de configuration	Moteur de règles par NAP
Protection DoS/DDoS	L’opérateur construit	Native
Protection contre le balayage d’enregistrement SIP	L’opérateur construit	Native
Liste noire dynamique, ACL, liste grise	Modules + travail personnalisé	Natif
Intégration de la signature STIR/SHAKEN	L’opérateur intègre un STI-AS externe	Modules préintégrés TransNexus / Neustar
Haute disponibilité 1+1	VRRP/keepalived + réplication d’état personnalisée	Intégré dans ProSBC+
API de routage programmable	Natif (script de configuration)	Moteur de routage Ruby
Surveillance, MOS, CDR, capture de paquets	Nécessite l’intégration d’outils externes	Natif plus option MaaS
Support fournisseur et SLA	Communauté ou support commercial OSS payant	Contrats de support 9×5 ou 24×7
Coût de licence	Zéro	À partir de 1,40 $/session/an

Les zones où la colonne open source est vide ou partielle ne sont pas des lacunes des projets. Ce sont des choix de périmètre : OpenSIPS, Kamailio, drachtio, RTPengine, FreeSWITCH et Asterisk n’ont pas été conçus pour être des SBC commerciaux clés en main. Atteindre un profil de production SBC signifie construire, intégrer et exploiter les couches ci-dessus.

Quand un SBC open source est la bonne réponse

L’open source est véritablement le bon choix dans un nombre significatif de situations.

Vous disposez d’une équipe d’ingénierie SIP solide en interne avec plusieurs années d’expérience en exploitation d’OpenSIPS, Kamailio, FreeSWITCH ou Asterisk en production. L’équipe dispose d’un dépôt de configuration documenté, d’un chemin de mise à jour éprouvé et d’au moins deux ingénieurs pouvant être sollicités à 2 h du matin sans panique.

Votre profil de trafic est bien défini et stable, avec des pics prévisibles et un ensemble connu de pairs SIP. Les avantages de la personnalisation open source sont rentables lorsque le déploiement est suffisamment stable pour que le travail sur mesure dure.

Vous devez faire quelque chose qu’un SBC commercial ne vous permettra pas, comme un pont protocolaire non standard, une expérimentation de signalisation personnalisée ou une intégration qu’aucun fournisseur n’a construite ni ne construira.

Votre posture de conformité vous permet de vous auto-supporter parce que vous n’êtes pas lié à un SLA opérateur, à une exigence réglementaire de disponibilité ou à un processus d’approvisionnement d’entreprise qui exige un fournisseur au contrat.

Quand le calcul « zéro licence » ne tient plus

Coût d’ingénierie complet

Un ingénieur réseau ou voix avec une expérience de niveau SBC coûte entre 60 000 $ et 100 000 $ par an, charges comprises, sur le marché nord-américain. Même à 20 % du temps d’un ingénieur consacré au SBC, cela représente 12 000 $ à 20 000 $ par an en coût de personnel seul. Un déploiement ProSBC de 500 sessions commence à partir de 1 250 $ par an.

Cadence de sécurité

Un SBC exposé sur Internet subit en permanence des balayages SIP, des attaques par inondation d’enregistrement, des sondes de paquets malformés et des tentatives de DDoS. Un SBC commercial intègre ces protections et les met à jour selon la cadence du fournisseur.

Conformité STIR/SHAKEN

Configurer le moteur de signalisation open source pour interroger un STI-AS externe afin d’obtenir une attestation de niveau A, gérer les échecs de signature, gérer le contournement P-Identity-Bypass et survivre à une panne du service de signature sans perdre d’appels est un travail d’ingénierie original.

Discipline de mise à jour

Une pile open source multi-projets dérive. OpenSIPS publie selon son propre calendrier, RTPengine selon un autre, le noyau Linux et les bibliothèques TLS selon un troisième. Coordonner les mises à jour, tester les régressions de l’intégration et revenir en arrière proprement quand quelque chose casse est un véritable travail d’ingénierie.

La réalité de l’astreinte

La voix est du temps réel. Une rotation à deux personnes est la structure d’astreinte minimale viable pour une infrastructure SBC, et trois est réaliste si vous voulez éviter l’épuisement.

Approches hybrides : la programmabilité sans la pile

Beaucoup d’équipes qui s’intéressent à l’open source ne sont pas séduites par la charge opérationnelle. Elles recherchent la programmabilité.

Le moteur de routage de ProSBC est configuré en Ruby, avec une chaîne de filtres documentée (before_filter, after_filter, after_remap_filter) et des modules préintégrés pour la signature STIR/SHAKEN avec TransNexus ClearIP et Neustar, le scoring de fraude avec SecureLogix et YouMail, et les intégrations de routage externe via API REST HTTP. L’équipe écrit des scripts. Le fournisseur maintient le cœur du SBC, la pile de sécurité et la discipline de mise à jour.

Pour les équipes dont la raison d’envisager l’open source était le contrôle, cette approche hybride est souvent le juste milieu pratique.

Foire aux questions

Conclusion

« SBC open source » désigne une pile que l’opérateur assemble, pas un produit à télécharger. OpenSIPS, Kamailio et drachtio gèrent la signalisation SIP ; RTPengine gère le média pour ces moteurs de signalisation ; FreeSWITCH et Asterisk peuvent fonctionner comme des B2BUA qui font les deux. Aucun d’entre eux n’a été conçu pour être un SBC commercial clé en main.

Pour une équipe dotée d’une solide expertise SIP, d’un trafic stable et de faibles contraintes de conformité, l’open source est un choix défendable et parfois le bon. Pour une équipe qui voulait l’open source pour sa programmabilité, un SBC commercial avec une véritable API de routage offre souvent le même contrôle sans la charge opérationnelle. Pour tous les autres, le calcul du temps d’ingénierie pointe généralement vers un SBC commercial dont le prix de départ est faible par rapport aux salaires des personnes qui devraient autrement construire et maintenir la pile.