PK-SBC : un SBC open source pour interconnecter trunks SIP et IPBX
Interconnecter des trunks SIP d’opérateurs et des IPBX d’entreprise semble simple sur le papier. En pratique, c’est l’un des points de friction les plus coûteux d’une infrastructure VoIP : il faut sécuriser l’IPBX exposé sur Internet, gérer plusieurs opérateurs en parallèle, basculer en cas de panne, normaliser le routage, le tout sans grever le budget avec un SBC propriétaire opaque et fermé.
PK-SBC est une réponse open source à ce problème. Un Session Border Controller construit sur Kamailio, RTP Engine, Redis et PostgreSQL, conçu selon le principe KISS — Keep It Simple, Stupid — et éprouvé en production depuis 2012.
Le problème que PK-SBC résout
Les architectures SIP réelles accumulent les complexités : un opérateur qui doit raccorder ses propres fournisseurs à sa plateforme VoIP, une entreprise multi-sites qui mutualise des trunks tout en isolant ses filiales, un intégrateur qui veut industrialiser le déploiement de SBC chez ses clients.
Sur ces use cases, deux approches dominent le marché, et chacune a ses limites :
- Les SBC propriétaires (Cisco, AudioCodes, Oracle ACME, Sangoma) sont coûteux, fermés et souvent surdimensionnés pour le besoin réel. L’ajout d’un tenant ou d’une règle de routage nécessite une intervention experte.
- Kamailio nu est puissant et gratuit, mais sa configuration est un art : chaque déploiement devient un projet sur-mesure, non reproductible et coûteux à maintenir.
PK-SBC se positionne entre les deux : la puissance et la maturité de Kamailio, mais avec une couche d’administration et de supervision qui rend le SBC pilotable par un opérateur, pas seulement par un développeur Kamailio.
Qu’est-ce que PK-SBC
PK-SBC est un proxy SIP d’interconnexion trunks ↔ IPBX, distribué sous licence AGPL v3. Son moteur repose sur Kamailio pour la signalisation SIP et RTP Engine pour le média, avec Redis et PostgreSQL pour l’état et la configuration. Le déploiement se fait en conteneurs Docker, sur une machine virtuelle unique pour démarrer.
Quelques repères factuels sur la maturité :
- En production depuis 2012, d’abord comme projet interne, puis industrialisé.
- Le plus gros déploiement connu est un opérateur en wholesale VoIP qui a tenu 100 000 appels simultanés sur l’infrastructure.
- Sur une VM standard (2 vCPU / 2 Go de RAM), une instance gère couramment plus de 1 000 appels simultanés.
Pour qui
PK-SBC s’adresse aux acteurs qui ont besoin d’industrialiser l’interconnexion SIP sans s’enfermer dans un SBC propriétaire :
- Opérateurs télécoms alternatifs qui raccordent leurs propres opérateurs tiers à leur plateforme de commutation.
- Intégrateurs et MSP qui déploient et exploitent des SBC chez leurs clients et veulent un produit reproductible.
- DSI de grandes entreprises multi-sites ou multi-filiales qui mutualisent les trunks opérateur tout en isolant les contextes.
- Revendeurs VoIP qui veulent une brique SBC marquable et opérable.
Deux cas d’usage réels
Opérateur national : raccordement à une plateforme de Class 4
Un opérateur télécom national utilise PK-SBC comme point d’entrée unique de sa plateforme de Class 4. Chaque opérateur tiers est déclaré comme gateway fournisseur, avec ses propres limites d’appels simultanés et de CPS (appels par seconde). Les règles de routage dirigent le trafic sortant vers le bon opérateur selon le préfixe géographique, et le trafic entrant vers la plateforme de téléphonie. Le cockpit de supervision permet à l’équipe NOC de détecter en temps réel une dégradation du MOS ou une chute du taux de réponse sur une passerelle précise.
Entreprise nationale multi-sites multi-sociétés
Un grand compte utilise PK-SBC pour sécuriser et router le trafic VoIP dans un environnement multi-sites et multi-sociétés. Les IPBX des sites distants sont déclarés comme gateways clientes, chacun avec son tenant. Le mode multi-tenant permet à un seul trunk opérateur de desservir plusieurs IPBX en les distinguant par en-tête SIP. Le failover entre IPBX primaire et secondaire est géré par les priorités des listes de gateways. L’audit trail immuable garantit la traçabilité de chaque modification de configuration, exigence des directions sécurité et conformité.
Comment ça marche
Moteur et administration
PK-SBC sépare clairement le moteur de routage — Kamailio et RTP Engine, qui traitent la signalisation et le média en temps réel — de l’interface d’administration, qui génère les vues PostgreSQL consommées par Kamailio. Les modifications de configuration ne sont pas appliquées à chaud : un bandeau de rappel invite l’administrateur à recharger Kamailio, ce qui garantit qu’aucune modification partielle ne puisse altérer le routage en production.
Supervision en temps réel
Le Cockpit est le tableau de bord principal. Il affiche le nombre d’appels en cours, le taux de réponse et le MOS moyen sur la période sélectionnée, avec un rafraîchissement automatique configurable. Cinq alertes paramétrables (MOS bas, taux de réponse bas, pic d’échecs, chute de durée, hausse des appels manqués) permettent une détection proactive des incidents. Un vue par passerelle complète la vue pour identifier rapidement la gateway dégradée.
CDR et qualité audio
Chaque appel traité produit un CDR (Call Detail Record) documentant l’identité de l’appelant et de l’appelé, les passerelles source et destination, la cause de raccrochage SIP et — surtout — les métriques de qualité audio : MOS, jitter, packet loss, codec négocié. Les CDR sont en lecture seule et constituent la source de vérité pour l’analyse post-mortem et le reporting. Un export CSV est disponible pour l’analyse dans un outil de BI.
Routage déclaratif
Le routage repose sur trois briques : les gateways (points de terminaison SIP, opérateurs ou clients), les groupes de routage (conteneurs logiques référençant une liste ordonnée de gateways) et les règles de routage (conditions de correspondance sur le numéro appelé). Quatre types de règles couvrent les besoins courants : standard, géographique (avec génération automatique des préfixes régionaux), spécialisé et urgence (avec préréglages par pays : France, Espagne, Italie). Un Assistant Inbound guide l’administrateur pas à pas pour configurer un routage entrant complet en un seul flux, avec rollback automatique en cas d’erreur.
Sécurité
PK-SBC intègre nativement les protections attendues d’un SBC : blocage des scanners SIP, détection des tentatives de connexion frauduleuses, détection d’injection SQL, validation des en-têtes SIP. Les limites d’appels (appels simultanés max, CPS max) s’appliquent au niveau gateway, groupe de routage et tenant — la limite la plus restrictive l’emporte, ce qui protège l’infrastructure contre les pics de trafic et la fraude. L’authentification de l’interface d’administration supporte les comptes locaux et le SSO via OIDC (Keycloak, Okta, Microsoft Entra ID).
Traçabilité
Chaque action de configuration — création, modification, suppression, connexion — est enregistrée dans un journal d’audit immuable, avec l’identité de l’utilisateur, l’horodatage, l’adresse IP et un diff JSON des changements. Cette traçabilité est conçue pour la conformité réglementaire et l’investigation rétroactive des incidents de routage.
Fonctions premium
Une fonction Analytics IA est disponible sous licence. Elle permet de poser des questions en langage naturel sur le trafic téléphonique (« Combien d’appels ont échoué sur la gateway Paris la semaine dernière ? ») et d’obtenir un résumé accompagné de graphiques et de statistiques détaillées. Une seconde fonction analyse les logs SIP récents pour détecter des anomalies ou comprendre un incident. Le système de licence est hors-ligne, aucune connexion à un serveur distant n’est nécessaire pour valider une licence.
Pour aller plus loin
Si vous voulez évaluer la solution sur votre cas d’usage — opérateur, intégrateur ou entreprise — la meilleure entrée est de demander une démo à l’équipe de Célea Consulting, l’éditeur de PK-SBC, qui assure le support et le développement du produit depuis 2008.