Options de SBC open source : ce qui existe réellement et quand c’est le bon choix

L’expression « SBC open source » laisse imaginer un projet unique que vous pourriez télécharger, installer et placer en bordure de votre réseau voix, comme vous déploieriez un contrôleur de session en bordure (SBC) commercial. Ce produit n’existe pas. Ce qui existe, c’est un ensemble de moteurs de signalisation SIP, de moteurs média et d’outils complémentaires open source qui, correctement assemblés et durcis, peuvent remplir la même fonction. Cette pile ne coûte rien en licences. Le coût d’ingénierie et le coût opérationnel, eux, ne sont pas nuls.

Cette page recense les options open source réalistes, décrit ce que fait réellement chacune d’elles, détaille ce que vous devez construire vous-même pour atteindre la parité fonctionnelle avec un SBC commercial, et vous aide à décider s’il vaut mieux construire, acheter ou opter pour une approche hybride dans le cas de votre équipe.

Pourquoi il n’existe pas de SBC open source unique

Un SBC commercial est un produit intégré. Signalisation SIP, traitement des médias, sécurité, routage, détection de la fraude, intégration STIR/SHAKEN, supervision et haute disponibilité y sont conçus et testés ensemble, livrés sous la forme d’un seul logiciel et pris en charge par un seul fournisseur.

Les télécoms open source ont suivi un autre chemin. La couche de signalisation et la couche média se sont développées comme des projets distincts, écrits dans des langages différents, avec chacun son rythme de publication, sa communauté et sa philosophie de conception. OpenSIPS et Kamailio descendent directement du SIP Express Router d’origine et sont optimisés pour traiter le SIP à des débits élevés. RTPengine et rtpproxy sont nés comme 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 qui traitent les médias, et non comme des SBC de bordure, même si tous deux peuvent être configurés pour jouer le rôle de SBC.

Un « SBC open source » est donc une pile que l’opérateur assemble lui-même. Chaque composant a un coût de licence nul. Le travail d’intégration, le durcissement opérationnel, les mises à niveau de plusieurs projets, le rythme des correctifs de sécurité, l’intégration de la signature STIR/SHAKEN et le support en production représentent autant de travail d’ingénierie à la charge de l’opérateur.

Les options réalistes de SBC open source

Les six projets ci-dessous sont ceux vers lesquels les équipes se tournent réellement lorsqu’elles veulent faire tourner un SBC sur des logiciels open source. Ils se répartissent en deux groupes : les moteurs de signalisation SIP, qui ont besoin d’un moteur média séparé, et les plateformes capables de traiter les médias, qui peuvent assurer seules un rôle de SBC de type B2BUA.

OpenSIPS

OpenSIPS est un proxy SIP et un moteur de routage optimisé pour la signalisation à l’échelle d’un opérateur. Il gère l’enregistrement, le routage, la répartition de charge, la traversée de NAT et les politiques de sécurité de base avec des volumes de transactions élevés. Sa configuration repose sur un langage de script propre, puissant mais peu familier pour les équipes qui n’ont jamais travaillé avec OpenSIPS.

OpenSIPS ne traite pas le RTP. Pour ancrer les médias, transcoder les codecs ou terminer le SRTP, vous l’associez à RTPengine ou à rtpproxy, sur le même hôte ou sur des hôtes voisins. Le remplacement de déploiements OpenSIPS en fin de vie est un motif récurrent d’évaluation de SBC commerciaux, car la complexité opérationnelle s’accumule à mesure que le déploiement grandit.

Kamailio

Kamailio partage la filiation et l’architecture d’OpenSIPS. C’est un serveur SIP, et non un B2BUA, avec son propre écosystème de modules et un style de configuration légèrement différent. Kamailio est largement utilisé comme frontal SIP dans les grands déploiements d’opérateurs et de CPaaS, souvent en paires actif/veille avec des adresses IP flottantes pour la redondance.

Comme OpenSIPS, Kamailio s’appuie sur un moteur média complémentaire pour le RTP. Les équipes qui gèrent Kamailio à grande échelle écrivent généralement leurs propres bibliothèques de configuration, déploient fail2ban ou des limiteurs de débit maison pour se protéger des attaques DoS, et intègrent des systèmes externes pour la signature STIR/SHAKEN et l’évaluation du risque de fraude. La couche de signalisation est solide ; tout ce qui l’entoure relève de l’opérateur.

drachtio

drachtio propose un serveur SIP programmable, piloté 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 de leur traitement. Pour les médias, drachtio est associé à RTPengine ou à FreeSWITCH.

drachtio convient aux équipes qui utilisent déjà une pile Node.js et veulent que la couche SIP se comporte comme une application qui leur appartient. Il ne fournit pas par défaut d’outils de sécurité de classe opérateur, de supervision ni de protection DoS. Ces couches restent à construire par l’opérateur.

RTPengine

RTPengine est le compagnon de traitement média le plus courant de Kamailio et d’OpenSIPS. Il tourne comme un démon séparé, auquel le serveur SIP indique, appel par appel, s’il doit relayer ou transcoder les médias. RTPengine gère le SRTP, l’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 centrée sur les médias, qui fonctionne comme un B2BUA. Elle gère nativement le SIP, le RTP, le SRTP, le WebRTC et le transcodage de codecs, ce qui en fait, à elle seule, un candidat plus proche du rôle de SBC qu’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 d’un opérateur.

La contrepartie, c’est que FreeSWITCH a été conçu comme serveur média et plateforme de conférence. L’utiliser comme SBC exposé à l’internet public implique de durcir la configuration contre les attaques par inondation SIP, de construire vous-même la limitation de débit et la protection contre le balayage des enregistrements, d’intégrer un service externe de signature STIR/SHAKEN et d’écrire la couche de supervision dont vos équipes opérationnelles ont besoin. Si vous avez déjà choisi FreeSWITCH pour votre plateforme, le réutiliser comme SBC est raisonnable. Sinon, partir de FreeSWITCH pour son coût de licence représente un engagement plus lourd que ne le laisse penser la page de téléchargement.

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 les médias. Il existe des configurations SBC basées sur Asterisk, souvent construites autour du pilote de canal chan_pjsip, et l’écosystème FreePBX a intégré une partie de ces fonctionnalités.

Pour les déploiements mono-locataires à faible volume où Asterisk fait déjà partie de la pile, l’utiliser comme SBC permet de garder une architecture simple. À l’échelle d’un opérateur, dans les environnements multi-locataires, ou lorsque la protection DoS et l’isolation du routage par locataire comptent, Asterisk exige un important travail externe pour atteindre le profil opérationnel qu’un SBC commercial offre d’emblée.

Ce que vous construisez et ce que vous obtenez

Fonctionnalité	Pile open source	SBC commercial (p. ex. ProSBC)
Signalisation SIP	Inclus	Inclus
Architecture B2BUA	FreeSWITCH/Asterisk oui ; Kamailio/OpenSIPS non	B2BUA complet
Ancrage des médias, SRTP, transcodage	Composant séparé, ou natif dans FS/Asterisk	Natif
Moteur de manipulation des en-têtes SIP	Scripté dans le langage de configuration	Moteur de règles par NAP
Protection DoS/DDoS	À construire par l’opérateur	Natif
Protection contre le balayage des enregistrements SIP	À construire par l’opérateur	Natif
Listes de blocage dynamiques, ACL, listes grises	Modules + développement sur mesure	Natif
Intégration de la signature STIR/SHAKEN	L’opérateur intègre un STI-AS externe	Modules TransNexus / Neustar prêts à l’emploi
Haute disponibilité 1+1	VRRP/keepalived + réplication d’état sur mesure	Fournie clés en main dans ProSBC+
API de routage programmable	Native (scripts de configuration)	Moteur de routage Ruby
Supervision, MOS, CDR, capture de paquets	Nécessite l’intégration d’outils externes	Natifs, avec l’option MaaS
Support fournisseur et SLA	Support communautaire, ou support commercial OSS payant	Contrats de support 9×5 ou 24×7
Coût de licence	Nul	Abonnement par session à tarifs publiés

Les cases vides ou partielles de la colonne open source 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 remplacer directement un SBC commercial. Atteindre le niveau d’un SBC prêt pour la production implique de construire, d’intégrer et de gérer les couches ci-dessus.

Quand un SBC open source est la bonne réponse

Dans bon nombre de situations, l’open source est réellement le bon choix.

Vous disposez d’une solide équipe interne d’ingénierie SIP, qui gère depuis plusieurs années OpenSIPS, Kamailio, FreeSWITCH ou Asterisk en production. Elle tient un dépôt de configuration documenté, maîtrise un processus de mise à niveau éprouvé et compte au moins deux ingénieurs que l’on peut appeler à 2 h du matin sans qu’ils paniquent.

Votre profil de trafic est bien défini et stable, avec des pics prévisibles et un ensemble connu de pairs SIP. La personnalisation qu’offre l’open source porte ses fruits lorsque le déploiement est assez stable pour que le travail sur mesure reste valable dans la durée.

Vous devez faire quelque chose qu’un SBC commercial ne vous permettra pas de faire, comme une passerelle entre protocoles non standard, une expérimentation de signalisation sur mesure ou une intégration qu’aucun fournisseur n’a développée ni ne développera.

Votre situation de conformité vous permet d’assurer votre propre support, car vous n’êtes lié ni par un SLA d’opérateur, ni par une exigence réglementaire de disponibilité, ni par un processus d’achat d’entreprise qui impose un fournisseur au contrat.

Quand le calcul sans licence ne tient plus

Coût d’ingénierie toutes charges comprises

Sur le marché nord-américain, un ingénieur réseau ou voix ayant une expérience des SBC coûte de 60 000 $ à 100 000 $ par an, toutes charges comprises. Même s’il ne consacre que 20 % de son temps au SBC, cela représente de 12 000 $ à 20 000 $ par an en seuls coûts de personnel. Un abonnement ProSBC Essentials de 500 sessions coûte 5 000 $ par an, haute disponibilité et support 24/7 de niveau 3 inclus.

Rythme des correctifs de sécurité

Un SBC exposé à internet subit en continu des balayages SIP, des attaques par inondation d’enregistrements, des sondes à base de paquets malformés et des tentatives de DDoS. Un SBC commercial est livré avec ces protections intégrées, corrigées au rythme des mises à jour du fournisseur.

Conformité STIR/SHAKEN

Configurer le moteur de signalisation open source pour qu’il interroge un STI-AS externe afin d’obtenir une attestation de niveau A, gère les échecs de signature, assure le repli P-Identity-Bypass et survive à une panne du service de signature sans perdre d’appels représente un travail d’ingénierie à réaliser de toutes pièces.

Discipline des mises à niveau

Une pile open source composée de plusieurs projets dérive avec le temps. OpenSIPS publie ses versions selon son propre calendrier, RTPengine selon un autre, le noyau Linux et les bibliothèques TLS selon un troisième. Coordonner les mises à niveau, soumettre l’intégration à des tests de non-régression et revenir proprement en arrière en cas de panne est un vrai travail d’ingénierie.

La réalité de l’astreinte

La voix fonctionne en temps réel. Une rotation à deux personnes est le minimum tenable pour l’astreinte d’une infrastructure SBC, et il en faut trois, de façon 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. Ce qu’elles recherchent, c’est la programmabilité.

Le moteur de routage de ProSBC se configure en Ruby, avec une chaîne de filtres documentée (before_filter, after_filter, after_remap_filter) et des modules prêts à l’emploi pour la signature STIR/SHAKEN avec TransNexus ClearIP et Neustar, l’évaluation du risque de fraude avec SecureLogix et YouMail, et des intégrations de routage externes par API REST sur HTTP. L’équipe écrit des scripts ; le fournisseur maintient le cœur du SBC, la pile de sécurité et la discipline des mises à niveau.

Pour les équipes qui envisageaient l’open source afin de garder le contrôle, cette approche hybride constitue souvent un juste milieu pragmatique.

Questions fréquentes

Conclusion

Un « SBC open source » est une pile que l’opérateur assemble, pas un produit qu’il télécharge. OpenSIPS, Kamailio et drachtio gèrent la signalisation SIP ; RTPengine prend en charge les médias pour ces moteurs de signalisation ; FreeSWITCH et Asterisk peuvent fonctionner comme des B2BUA qui assurent les deux. Aucun d’eux n’a été conçu pour remplacer directement un SBC commercial.

Pour une équipe dotée de solides compétences en ingénierie 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 doté d’une véritable API de routage offre souvent le même contrôle, sans le fardeau opérationnel. Pour tous les autres, le calcul du temps d’ingénierie penche généralement en faveur d’un SBC commercial dont le prix d’entrée reste modeste au regard des salaires des personnes qui, sinon, construiraient et maintiendraient la pile.