Contrôleur de session en bordure (SBC) : guide complet pour évaluer un SBC logiciel

Un contrôleur de session en bordure est l’élément réseau positionné à la frontière entre deux réseaux voix IP. Il gouverne chaque session SIP qui le traverse : il termine la signalisation et les flux médias côté entrant, applique les politiques de sécurité et de protocole, puis re-génère une nouvelle session côté sortant.

Ce guide s’adresse aux ingénieurs et aux décideurs qui évaluent leurs options en matière de SBC. Il couvre les capacités fondamentales qu’un SBC de production doit fournir, les raisons pour lesquelles le secteur migre des appareils matériels vers les contrôleurs de session en bordure logiciels, les modèles de déploiement disponibles, les segments d’acheteurs qui en bénéficient le plus, et les fonctionnalités à prioriser lors de la comparaison de fournisseurs.

Qu’est-ce qu’un contrôleur de session en bordure ?

Dans son essence, un contrôleur de session en bordure est un B2BUA (Back-to-Back User Agent) déployé à la frontière entre deux réseaux SIP. Il termine intégralement chaque session entrante, applique les politiques de sécurité et d’interopérabilité, puis re-génère une nouvelle session côté sortant, donnant à l’opérateur un contrôle indépendant sur la signalisation, les médias et le chiffrement sur chaque côté. Pour une explication complète des fondamentaux des SBC, du fonctionnement de l’architecture B2BUA et des différences entre les SBC, les pare-feu et les proxys SIP, consultez Qu’est-ce qu’un contrôleur de session en bordure (SBC) ?

Les sections suivantes se concentrent sur ce qui compte lors de l’évaluation d’un SBC pour la production : les cinq domaines de capacités essentielles, les compromis opérationnels entre matériel et logiciel, les modèles de déploiement disponibles aujourd’hui, et les fonctionnalités qui distinguent une plateforme de qualité opérateur d’un simple dispositif de périphérie SIP.

Que fait un contrôleur de session en bordure ?

Les fonctions d’un SBC se répartissent en cinq catégories. Lors de l’évaluation des fournisseurs, ce sont les domaines où la qualité de mise en œuvre varie le plus et où les différences ont le plus grand impact sur la fiabilité en production.

Sécurité et contrôle d’accès

La sécurité est la raison la plus fréquente pour laquelle les organisations déploient un SBC. En périphérie du réseau, le SBC constitue le point d’entrée unique pour tout le trafic SIP, ce qui en fait l’emplacement naturel pour appliquer la politique de sécurité.

La protection contre les attaques DoS et DDoS détecte et bloque les attaques volumétriques (inondations SIP, tempêtes d’enregistrement, tentatives de déni de service distribué) avant qu’elles n’atteignent l’infrastructure de traitement des appels derrière le SBC. La liste noire dynamique permet au SBC de bloquer automatiquement les adresses IP ou les numéros appelants présentant un comportement suspect, tandis que les listes de contrôle d’accès statiques définissent quelles sources sont autorisées à envoyer du trafic. La protection contre le balayage d’enregistrements SIP identifie et bloque les tentatives d’enregistrement par force brute, précurseur courant de la fraude au péage. Le masquage de la topologie garantit que les adresses IP internes ne se retrouvent jamais dans les en-têtes SIP externes, empêchant les attaquants de cartographier votre réseau.

Lorsque le SBC fonctionne en mode B2BUA, il fournit également une démarcation naturelle pour le chiffrement. Il peut terminer la signalisation SIP chiffrée par TLS sur un côté et la re-générer sur l’autre, avec un certificat différent, une suite de chiffrement différente, voire sans chiffrement du tout, selon ce que chaque côté exige. Il en va de même pour les médias : le SBC assure la passerelle entre SRTP et RTP ordinaire de façon transparente, permettant à un opérateur qui livre des médias non chiffrés de se connecter à une plateforme qui impose le chiffrement sans que l’une ou l’autre partie ne modifie sa configuration.

Interopérabilité SIP et normalisation

Aucune implémentation SIP n’est identique à une autre. Les opérateurs, les fournisseurs de PBX et les plateformes de collaboration interprètent chacun le RFC SIP différemment, ajoutent des en-têtes propriétaires et gèrent les cas limites à leur manière. Le SBC résout ces incompatibilités grâce à la manipulation d’en-têtes SIP, en inspectant et en réécrivant les en-têtes par groupe de jonctions afin que chaque partie reçoive un SIP qu’elle comprend.

Les tâches de normalisation courantes comprennent la correction des en-têtes Via et Contact qui contiennent des adresses IP privées, le remappage des en-têtes P-Asserted-Identity (PAI) pour la présentation de l’identification de l’appelant, la suppression des extensions propriétaires qu’une partie ne reconnaît pas, et l’ajustement des paramètres de minuterie de session (RFC 4028) qui provoqueraient sinon des coupures d’appel prématurées.

Gestion des médias et transcodage

Le SBC contrôle le plan médias en plus de la signalisation. Il ancre les médias via sa propre adresse IP, garantissant que les paquets RTP traversent le SBC plutôt que de circuler directement entre les terminaux, ce qui est indispensable pour le pont de chiffrement, l’interception légale, l’enregistrement des appels et la surveillance de la qualité.

Lorsque deux terminaux utilisent des codecs incompatibles, le SBC effectue le transcodage pour convertir entre eux. Pour les déploiements IP-vers-IP, cela peut signifier une conversion entre codecs bande étroite (G.711, G.729) et codecs large bande (AMR-WB, Opus) afin que les terminaux mobiles et WebRTC puissent interopérer avec l’infrastructure PSTN traditionnelle.

Routage des appels et application des politiques

Au-delà du routage SIP de base, un SBC fournit un moteur de routage programmable qui prend des décisions en fonction du numéro appelant, du numéro appelé, de l’heure, de l’utilisation du groupe de jonctions et de consultations de données externes. Le contrôle d’admission d’appels prévient la sursouscription en limitant le nombre de sessions simultanées par groupe de jonctions ou à l’échelle du système. Le routage au moindre coût dirige les appels vers le chemin disponible le moins coûteux, avec basculement automatique vers des routes alternatives lorsqu’un opérateur est indisponible.

Les SBC avancés exposent une couche API qui permet aux opérateurs d’intégrer une logique externe (consultations CRM, bases de données de portabilité des numéros, moteurs de scoring de fraude et systèmes de facturation) directement dans la décision de routage des appels, exécutée pendant la phase de signalisation sans impact sur la qualité des médias.

Conformité réglementaire

Les télécommunications sont un secteur réglementé, et le SBC est souvent le point d’application des exigences de conformité. L’authentification de l’identification de l’appelant STIR/SHAKEN, imposée par la FCC en vertu du TRACED Act, exige des fournisseurs de services voix qu’ils signent cryptographiquement les appels sortants et vérifient les appels entrants. Le SBC s’intègre à des services de signature externes pour attacher ou valider des jetons d’identité numérique dans l’en-tête SIP INVITE.

Les capacités de détection de fraude permettent au SBC d’inspecter les schémas d’appels en temps réel, d’évaluer les appels selon leur niveau de risque et de bloquer le trafic frauduleux avant qu’il ne génère des frais. La génération d’enregistrements de détails d’appels (CDR) fournit la piste d’audit et de facturation exigée par les régulateurs et les équipes financières.

SBC matériel ou SBC logiciel : l’évolution du secteur

Pendant la majeure partie de l’histoire des SBC, le dispositif était un appareil matériel propriétaire : une boîte dédiée d’AudioCodes, Oracle (Acme Packet), Ribbon Communications ou Cisco, avec des puces DSP dédiées au transcodage et une capacité maximale fixée par le matériel acheté.

Ce modèle est en train de changer. Les SBC logiciels qui s’exécutent sur des machines virtuelles standard, des instances cloud et des serveurs génériques offrent désormais les mêmes capacités de sécurité, d’interopérabilité et de routage de qualité opérateur, sans les dépenses d’investissement, les cycles de renouvellement matériel et la dépendance fournisseur associés aux appareils dédiés.

Pourquoi les opérateurs migrent vers les SBC logiciels

La transition du matériel vers les contrôleurs de session en bordure logiciels est portée par cinq réalités opérationnelles.

Le CAPEX versus l’OPEX est le facteur le plus immédiat. Un SBC matériel nécessite un achat initial conséquent, un contrat de maintenance et un renouvellement matériel tous les cinq à sept ans. Un SBC logiciel s’exécute sur une infrastructure déjà possédée ou louée, avec une tarification par abonnement qui s’adapte à l’utilisation réelle. Pour les opérateurs gérant des dizaines ou des centaines de clients, la différence en coût total de possession est significative.

La rapidité de déploiement est déterminante sur les marchés concurrentiels. Un SBC virtuel peut être déployé sur VMware, KVM/Proxmox, AWS ou Azure en quelques minutes, et non en semaines ou en mois comme l’exige l’approvisionnement, l’expédition, l’installation en rack et la configuration d’un appareil matériel. Pour les MSP qui intègrent de nouveaux clients ou les ISP qui répondent à une demande d’interconnexion opérateur, cette rapidité se traduit directement en revenus.

La scalabilité élastique supprime les approximations de la planification de capacité. Un SBC cloud fait évoluer la capacité de sessions à la hausse ou à la baisse sans changer de matériel. Quand le trafic augmente, on monte en tier de licence. Quand un projet se termine, on réduit. Les appareils matériels n’offrent aucune de cette flexibilité ; vous payez pour la capacité de pointe qu’elle soit utilisée ou non.

L’indépendance de la plateforme supprime la dépendance à un fournisseur unique qui a caractérisé le marché des SBC pendant des décennies. Un SBC logiciel s’exécute sur l’hyperviseur, le fournisseur cloud ou le serveur bare-metal choisi par l’opérateur, et la migration entre plateformes ne nécessite pas de remplacer du matériel.

Les mises à jour continues comblent l’écart entre les cycles de publication. Les SBC logiciels reçoivent des mises à jour de fonctionnalités et des correctifs de sécurité via des pipelines de déploiement logiciel standard, et non par des mises à jour de firmware liées au matériel qui nécessitent des fenêtres de maintenance et parfois un accès physique.

Quand le matériel reste pertinent

Les SBC matériels conservent des avantages dans des scénarios spécifiques. Les déploiements nécessitant un transcodage à très haute densité (des milliers de conversions simultanées entre AMR-WB et G.711, par exemple) bénéficient encore de puces DSP dédiées. Certains environnements réglementaires imposent des appareils physiques sur site. Les organisations disposant d’investissements matériels existants peuvent choisir de continuer à exploiter leurs appareils jusqu’en fin de vie avant de migrer vers le logiciel.

La voie pratique pour la plupart des opérateurs est une approche hybride : des SBC logiciels pour les nouveaux déploiements, les instances cloud et les charges de travail élastiques, avec des ressources de transcodage matérielles ajoutées uniquement là où la conversion de codecs à grande échelle l’exige.

Fonctionnement d’un contrôleur de session en bordure dans un réseau VoIP

Un SBC opère en périphérie d’un réseau voix, positionné entre l’infrastructure interne de confiance et les réseaux externes non fiables. Dans un environnement d’opérateur, cela signifie généralement une ou plusieurs instances SBC placées entre la plateforme de commutation centrale du fournisseur et le monde extérieur : les interconnexions opérateurs d’un côté, les terminaux abonnés de l’autre.

Le SBC de peering

Un SBC de peering gère l’interconnexion entre deux opérateurs ou entre un opérateur et un opérateur PSTN. Chaque appel entrant ou sortant du réseau traverse ce SBC. Il applique la sécurité au niveau de la jonction SIP (TLS, SRTP, contrôle d’accès), normalise le SIP entre les systèmes des deux opérateurs, génère des CDR pour la facturation inter-opérateurs et applique le contrôle d’admission d’appels pour éviter qu’un seul pair ne consomme plus de capacité que celle contractuellement prévue.

Le SBC d’accès

Un SBC d’accès se place entre les terminaux abonnés (téléphones IP, PBX, plateformes de centre de contacts, outils de collaboration) et l’infrastructure centrale de l’opérateur. Il gère la traversée NAT pour les terminaux situés derrière les pare-feu des clients, applique des limites de sessions par abonné, assure le pont de chiffrement entre le réseau de l’abonné et le cœur de l’opérateur, et protège contre les équipements clients compromis ou mal configurés.

Flux d’appel VoIP sur un SBC

Lorsqu’un appel arrive au SBC, la séquence de traitement suit un chemin prévisible. Le SBC valide d’abord la source par rapport à sa liste de contrôle d’accès et vérifie les schémas DoS. Il inspecte ensuite le SIP INVITE en appliquant les règles de manipulation d’en-têtes pour le groupe de jonctions entrant. Si la vérification STIR/SHAKEN est configurée, le SBC envoie l’en-tête Identity au service de vérification. Le moteur de routage détermine le chemin sortant en fonction des règles configurées, des consultations de données externes ou d’une logique pilotée par API. Le SBC construit un nouveau SIP INVITE pour le tronçon sortant, en appliquant les règles de manipulation d’en-têtes pour le groupe de jonctions de destination, en négociant les codecs et en établissant le chiffrement si nécessaire. Une fois le correspondant en ligne, le SBC ancre les médias via sa propre adresse, assurant le pont entre les formats de chiffrement et de codecs utilisés de chaque côté.

Tout au long de l’appel, le SBC surveille la qualité (scores MOS, gigue, perte de paquets), génère des statistiques en temps réel et écrit un CDR à la fin de la session.

Modèles de déploiement d’un SBC

Les SBC logiciels modernes prennent en charge plusieurs modèles de déploiement, chacun adapté à des exigences opérationnelles différentes.

SBC virtuel sur site

Le SBC s’exécute en tant que machine virtuelle sur l’hyperviseur propre à l’opérateur (VMware ESXi, KVM ou Proxmox). Ce modèle donne à l’opérateur un contrôle total sur le matériel hôte, la configuration réseau et le chemin des données. C’est le modèle privilégié pour les opérateurs disposant d’une infrastructure de centre de données existante, pour les déploiements dans des environnements réglementés qui exigent un traitement des données sur site, et pour les organisations qui doivent intégrer le SBC avec des équipements TDM dans la même installation.

SBC cloud

Un contrôleur de session en bordure natif cloud s’exécute sur AWS, Microsoft Azure ou un autre fournisseur de cloud public. Ce modèle élimine entièrement les contraintes liées aux centres de données et permet des déploiements géo-redondants sur plusieurs régions cloud pour une résilience maximale. Les SBC cloud sont la solution naturelle pour les opérateurs desservant des bases clients distribuées, pour les intégrations CPaaS où la plateforme voix réside déjà dans le cloud, et pour les organisations qui souhaitent éviter tout engagement matériel.

SBC bare-metal

Pour les opérateurs qui souhaitent des performances maximales sans couche hyperviseur, le SBC peut s’exécuter directement sur des serveurs x86 génériques. Ce modèle extrait la densité de sessions la plus élevée possible d’une empreinte matérielle donnée et est courant dans les déploiements de peering à haute capacité où chaque session compte.

Déploiements hybrides

De nombreux opérateurs combinent les modèles : un SBC sur site pour les interconnexions opérateurs locales et l’intégration TDM, associé à des instances SBC cloud pour les sites distants, la reprise après sinistre ou la capacité de débordement élastique. L’utilisation de la même image logicielle et de la même syntaxe de configuration sur tous les modèles de déploiement rend cela pratique.

Qui a besoin d’un contrôleur de session en bordure ?

Toute organisation exploitant un réseau voix SIP à la frontière entre deux domaines de confiance a besoin d’un SBC. Que vous déployiez un contrôleur de session en bordure d’entreprise pour protéger un environnement voix d’entreprise ou un SBC de qualité opérateur pour gérer des dizaines de milliers de sessions sur un réseau d’opérateur, les exigences fondamentales sont les mêmes : sécurité, interopérabilité et application des politiques. En pratique, quatre segments d’acheteurs représentent la grande majorité des déploiements SBC.

Fournisseurs d’accès à Internet (ISP)

Les ISP qui offrent des services voix ont besoin d’un SBC pour s’interconnecter avec les opérateurs en amont, protéger leur infrastructure de commutation contre les menaces externes, assurer la conformité STIR/SHAKEN et gérer la normalisation SIP requise lors de l’agrégation de trafic provenant de plusieurs pairs opérateurs. Pour les ISP qui remplacent des plateformes héritées (déploiements OpenSIPS qui ont dépassé leur périmètre initial, systèmes MetaSwitch/Perimeter dépourvus de mitigation DDoS, ou matériel en fin de vie de Ribbon ou Oracle), un SBC logiciel offre un chemin de remplacement moderne et rentable.

Fournisseurs de services gérés (MSP)

Les MSP qui fournissent de la voix hébergée, de l’UCaaS ou du Microsoft Teams Direct Routing à leurs clients professionnels ont besoin d’un SBC comme point central de gestion du trafic et de sécurité. Un seul déploiement SBC peut desservir des dizaines ou des centaines de clients finaux, avec des groupes de jonctions, des règles de routage et des politiques de sécurité par locataire. Le SBC permet également au MSP de proposer des services à valeur ajoutée (enregistrement des appels, protection contre la fraude, application de la conformité) qui différencient son offre de la simple revente de voix.

Éditeurs de plateformes UCaaS et CCaaS

Les éditeurs de logiciels qui construisent des plateformes de communications unifiées ou de centres de contacts ont besoin d’un SBC pour gérer la couche de jonctions SIP, de sécurité et d’interopérabilité, afin que leurs équipes de développement puissent se concentrer sur la logique applicative plutôt que sur l’intégration opérateur. Dans les architectures CPaaS et BYOC, où la plateforme s’intègre à Twilio, RingCentral, Genesys ou des solutions similaires, le SBC normalise le trafic provenant de plusieurs opérateurs et fournit le périmètre de sécurité que la plateforme elle-même n’inclut pas.

Centres de contacts

Les centres de contacts, qu’ils soient sur site ou en cours de migration vers des plateformes cloud comme Genesys Cloud, Five9 ou NICE, déploient des SBC pour sécuriser leur infrastructure voix, gérer un nombre élevé de sessions simultanées, garantir la qualité de service pour les appels en contact client et maintenir la conformité avec les exigences d’enregistrement et d’audit. Pour les déploiements de centres de contacts cloud en mode BYOC (Bring Your Own Carrier), le SBC est le pont entre les opérateurs choisis par l’organisation et la plateforme cloud.

Fonctionnalités clés à évaluer pour un SBC

Lors de la comparaison des fournisseurs de SBC, voici les capacités qui ont le plus d’impact direct sur la fiabilité en production, le coût opérationnel et la flexibilité à long terme.

Architecture B2BUA

Une implémentation B2BUA complète, où le SBC termine et re-génère la signalisation et les médias sur chaque côté, est incontournable pour les déploiements en production. Un proxy SIP ne peut pas effectuer la manipulation d’en-têtes, le chiffrement indépendant par côté, le masquage de la topologie ou l’ancrage des médias. Si le SBC que vous évaluez fonctionne comme un proxy plutôt qu’un B2BUA, il ne peut pas assurer les fonctions de sécurité et d’interopérabilité décrites dans ce guide.

Profondeur de la sécurité

Ne vous arrêtez pas aux affirmations de surface. Évaluez si le SBC fournit une mitigation DoS/DDoS en temps réel (pas seulement de la limitation de débit), une liste noire dynamique qui réagit automatiquement aux schémas de trafic, une protection contre le balayage d’enregistrements SIP et des listes de contrôle d’accès granulaires au niveau du groupe de jonctions. La prise en charge du chiffrement doit inclure TLS pour la signalisation et SRTP pour les médias, avec la capacité de faire le pont entre les côtés chiffrés et non chiffrés de façon transparente.

Moteur de manipulation d’en-têtes SIP

La qualité du moteur de manipulation d’en-têtes SIP détermine l’efficacité avec laquelle le SBC gère les environnements multi-fournisseurs. Évaluez si les règles peuvent être appliquées par groupe de jonctions, si le moteur prend en charge la correspondance de modèles par expressions régulières, et s’il peut gérer des transformations complexes comme l’insertion conditionnelle d’en-têtes en fonction des paramètres de l’appel.

API et programmabilité

Un SBC moderne doit exposer une API REST pour la gestion de la configuration, la surveillance de l’état et la récupération des CDR. Au-delà de cela, évaluez si le SBC prend en charge le routage programmable : la capacité d’exécuter une logique personnalisée (consultations HTTP externes, requêtes de base de données, scoring de fraude) pendant la phase de signalisation de chaque appel. Cette capacité transforme le SBC d’un dispositif d’application de politiques statiques en une périphérie programmable qui s’adapte aux exigences métier en temps réel.

Flexibilité de déploiement

Confirmez que le SBC s’exécute sur les plateformes que votre infrastructure utilise aujourd’hui et pourrait utiliser demain : VMware, KVM/Proxmox, AWS, Azure et bare-metal. Un SBC logiciel qui vous lie à un seul hyperviseur ou fournisseur cloud introduit le même type de dépendance fournisseur qu’impose un appareil matériel.

Haute disponibilité

Pour une infrastructure voix en production, la haute disponibilité 1+1 actif/veille est une exigence de base. Évaluez le mécanisme de basculement, l’état préservé lors d’un basculement et la disponibilité de la HA à toutes les tailles de déploiement, pas seulement pour les licences de niveau entreprise.

Modèle de tarification

Les SBC matériels impliquent d’importants coûts d’investissement initiaux et une maintenance annuelle. Les SBC logiciels utilisent généralement une tarification par abonnement (par session, par serveur ou par mois). Évaluez le coût total de possession sur trois à cinq ans, en incluant les contrats de support, la licence HA et les fonctionnalités complémentaires. Une tarification transparente et publiée est un signal fort que le fournisseur est confiant dans la valeur de son offre.

Intégration STIR/SHAKEN

Les règles FCC exigeant désormais que les opérateurs signent leurs appels avec leurs propres certificats STIR/SHAKEN : évaluez la façon dont le SBC s’intègre aux services de signature. Un modèle d’intégration ouvert, où le SBC fonctionne avec n’importe quel service de signature tiers (TransNexus, Neustar, et d’autres) plutôt que de vous lier à un partenaire choisi par le fournisseur, offre la flexibilité de changer de prestataire si les tarifs ou les capacités évoluent.

Capacité	SBC matériel	SBC logiciel
Rapidité de déploiement	Semaines à mois	Minutes à heures
Scalabilité élastique	Fixée par le matériel	À la demande
Modèle de tarification	CAPEX élevé + maintenance	Abonnement OPEX
Choix de la plateforme	Matériel fournisseur uniquement	VMware, KVM, AWS, Azure, bare-metal
Haute disponibilité à petite échelle	Souvent réservée au niveau entreprise	Disponible à tous les niveaux
Transcodage matériel	DSP intégré	DSP externe ou logiciel (selon le codec)
Cycle de mise à jour	Firmware + fenêtres de maintenance	Déploiement logiciel standard

Questions fréquentes

Qu’est-ce qu’un contrôleur de session en bordure en termes simples ?

Un contrôleur de session en bordure est un dispositif ou un logiciel positionné en périphérie d’un réseau voix qui contrôle chaque appel franchissant la frontière : il sécurise le trafic, traduit entre les implémentations SIP, chiffre les médias et applique les politiques de routage. Pour une introduction détaillée, consultez Qu’est-ce qu’un contrôleur de session en bordure (SBC) ?

Quelle est la différence entre un SBC et un pare-feu ?

Un pare-feu opère au niveau de la couche réseau : il filtre les paquets en fonction des adresses IP, des ports et des protocoles. Un SBC opère au niveau de la couche applicative : il comprend la signalisation SIP et les médias RTP, peut inspecter et modifier le contenu des sessions voix, appliquer des politiques spécifiques aux appels et faire le pont entre différents standards de chiffrement. Un pare-feu ne peut pas effectuer la normalisation SIP, le transcodage, le masquage de la topologie ou le contrôle d’admission d’appels. Dans les réseaux voix en production, les deux sont nécessaires : le pare-feu pour la sécurité réseau générale, le SBC pour la sécurité et l’interopérabilité spécifiques à la voix.

Ai-je besoin d’un SBC pour Microsoft Teams ?

Oui, si vous utilisez le Direct Routing pour connecter Teams à vos propres jonctions SIP. Microsoft exige un SBC certifié ou compatible qui prend en charge TLS 1.2 pour la signalisation, SRTP pour les médias, la configuration basée sur les FQDN et les pulsations SIP OPTIONS. Le SBC gère la traduction de protocoles entre le SIP de votre opérateur et le dialecte SIP de Teams, le pont de chiffrement entre le RTP de l’opérateur et le SRTP de Teams, ainsi que la normalisation d’en-têtes qu’exige Teams. Sans SBC, le Direct Routing ne fonctionne pas.

Quelle est la différence entre un SBC matériel et un SBC logiciel ?

Un SBC matériel est un appareil propriétaire avec une capacité fixe et des puces DSP dédiées. Un SBC logiciel s’exécute sur des machines virtuelles, des instances cloud ou des serveurs génériques, offrant une tarification par abonnement, une scalabilité élastique et une flexibilité de déploiement. Les deux fournissent les mêmes fonctions SBC essentielles : sécurité, interopérabilité, routage et conformité. Le choix dépend de votre modèle d’infrastructure, de votre préférence budgétaire (CAPEX ou OPEX) et de la nécessité d’un transcodage accéléré par matériel à grande échelle.

Combien de sessions un SBC logiciel peut-il gérer ?

Les SBC logiciels modernes de qualité opérateur peuvent gérer des dizaines de milliers de sessions simultanées sur une seule instance de serveur. La capacité réelle dépend des ressources CPU et mémoire du serveur, de l’activation du transcodage et de la complexité de la logique de routage appliquée par appel. Pour les déploiements nécessitant davantage de capacité, plusieurs instances SBC peuvent être déployées derrière un répartiteur de charge ou dans une configuration en cluster.

Un SBC est-il nécessaire pour la conformité STIR/SHAKEN ?

La FCC exige des fournisseurs de services voix qu’ils signent les appels sortants et vérifient les appels entrants via le cadre STIR/SHAKEN. Le SBC est le point d’application le plus courant pour cette exigence, car il traite déjà chaque SIP INVITE en périphérie du réseau. Le SBC s’intègre à un service de signature externe pour attacher des jetons d’identité cryptographique aux appels sortants et les vérifier sur les appels entrants. Les opérateurs doivent désormais utiliser leurs propres certificats STIR/SHAKEN pour la signature, plutôt que de s’appuyer sur le certificat d’un tiers.

Pour aller plus loin

Pour comprendre comment un SBC logiciel transforme les architectures de communications cloud, de la scalabilité élastique et de la haute disponibilité géo-redondante à la dérivation des médias et l’intégration CPaaS, lisez notre guide approfondi sur le SBC pour les communications cloud.

Pour comprendre comment le Microsoft Teams Direct Routing connecte Teams au PSTN via un SBC, notamment les exigences TLS, SRTP et de normalisation SIP qui le font fonctionner, lisez notre guide détaillé sur Qu’est-ce que le Teams Direct Routing ?

Déployer un SBC logiciel avec ProSBC

ProSBC est un contrôleur de session en bordure logiciel de qualité opérateur conçu pour les fournisseurs de services. Il fournit l’architecture B2BUA complète, le moteur de manipulation d’en-têtes SIP, la protection DoS/DDoS, la liste noire dynamique et les capacités de routage programmable décrites dans ce guide. Il s’exécute sur VMware, KVM/Proxmox, AWS, Azure ou bare-metal avec une tarification par abonnement à partir de 1,40 $ par session et par an.

ProSBC prend en charge Microsoft Teams Direct Routing, s’intègre aux services de signature STIR/SHAKEN dont TransNexus ClearIP, et expose une API REST ainsi que des scripts de routage en Ruby pour une logique d’appels personnalisée. La haute disponibilité (1+1 actif/veille) est disponible à chaque taille de déploiement, et le ProSBC Lab offre une licence permanente et gratuite de 3 sessions pour tester l’ensemble des fonctionnalités dans votre propre environnement avant de vous engager.

Pour les opérateurs qui préfèrent ne pas gérer le SBC eux-mêmes, le ProSBC Managed Service propose un déploiement entièrement géré avec HA 1+1, support 24h/24 et 7j/7, et une configuration de bout en bout, hébergé sur la plateforme de votre choix ou par TelcoBridges.