Comment choisir un SBC : guide d’achat en 6 étapes pour les décideurs réseau voix

Un processus pratique pour présélectionner, évaluer et sélectionner le bon contrôleur de session en bordure (SBC) pour votre réseau.

Le contrôleur de session en bordure (SBC) que vous choisissez sera déployé en périphérie de votre réseau voix pour les cinq prochaines années. Il acheminera chaque appel, terminera chaque négociation TLS, appliquera chaque règle anti-fraude et absorbera chaque attaque SIP dirigée contre votre infrastructure. Se tromper dans la sélection coûte bien plus qu’une simple ligne budgétaire. Le prix se cumule : chaque problème d’interopérabilité, chaque panne nocturne, chaque incident de fraude remonte à cette unique décision d’achat.

Ce guide propose un processus en six étapes pour présélectionner, évaluer et choisir le bon SBC. Chaque étape renvoie vers une ressource plus détaillée, vous permettant de vous arrêter à la page qui répond réellement à votre question.

Ce contenu s’adresse aux ingénieurs réseau, directeurs informatiques et architectes télécom à qui l’on a demandé de déployer un SBC et qui doivent maintenant prendre la décision. Le guide suppose que vous savez déjà ce qu’est un SBC et pourquoi vous en avez besoin. Si vous souhaitez d’abord comprendre ce qu’est un SBC, commencez par notre hub d’apprentissage SBC et revenez quand vous serez prêt à évaluer.

Pourquoi la sélection d’un SBC est plus complexe qu’il n’y paraît

La plupart des acheteurs de SBC regrettent l’un de ces trois points après la signature. Ils ont surdimensionné ou sous-dimensionné la capacité (suraché de la capacité jamais utilisée, ou sous-aché pour atteindre un plafond en deuxième année). Ils ont choisi un modèle de déploiement qui n’a pas survécu à un changement de personnel. Ou ils ont accepté une couche de routage fermée qui les a empêchés d’intégrer des services de fraude, de facturation ou de conformité dont ils avaient besoin par la suite.

Les six étapes ci-dessous sont conçues pour révéler chacun de ces risques pendant l’évaluation, pas après le déploiement. Elles s’inspirent des scénarios observés dans les POC et les appels de déploiement ProSBC réels : ce que les acheteurs expérimentés testent, dans quel ordre, et ce qu’ils négligent à leurs dépens.

Si vous évaluez plusieurs fournisseurs en parallèle, suivez les étapes dans l’ordre pour chacun. Passer directement aux démonstrations fournisseurs avant d’avoir documenté les étapes 1 et 3 est le meilleur moyen de biaiser la décision en faveur de l’ingénieur commercial le plus convaincant, plutôt que des exigences qui comptent vraiment.

Étape 1 : profiler votre charge de trafic réelle

La première erreur de la plupart des acheteurs est de dimensionner le SBC en fonction d’un chiffre marketing du fournisseur plutôt que du comportement réel du réseau. L’infrastructure voix a une charge en pics, et c’est le pic qui compte, pas la moyenne.

Profilez quatre dimensions avant de demander un devis à un fournisseur.

Sessions simultanées en pointe sont le chiffre le plus cité dans la tarification SBC, et celui le plus souvent estimé de manière erronée. Extrayez 90 jours de CDR de votre infrastructure voix actuelle et observez le 99e percentile d’appels actifs simultanés. C’est votre chiffre de dimensionnement. La moyenne annuelle est sans importance ; c’est le mardi à 17 h en novembre qui fait tomber l’équipement.

CPS (appels par seconde) importent dès que le volume d’appels est élevé mais que la durée moyenne est courte. Les centres de contact, les composeurs prédictifs et les plateformes SMS-vers-voix peuvent atteindre un plafond de CPS bien avant d’atteindre un plafond de sessions. Si vous n’avez pas mesuré votre CPS en pointe, faites-le avant de dimensionner.

Enregistrements de terminaux représentent un plafond distinct des sessions simultanées. Si vous exploitez un PBX hébergé, des téléphones IP via votre SBC ou des clients SIP pour travailleurs à distance, le nombre d’enregistrements est souvent la limite atteinte en premier. Certains SBC publient un chiffre unique de sessions qui inclut discrètement les enregistrements dans la même limite. Demandez au fournisseur directement, par écrit.

Géographie et croissance façonnent à la fois vos besoins en support et votre topologie de déploiement. Un MSP nord-américain avec un seul PoP dans us-east-1 a des besoins différents d’un ILEC régional déployé sur site dans sept pays. Projetez où sera votre trafic dans 24 et 36 mois, pas seulement où il se trouve aujourd’hui.

Une fois les quatre chiffres établis, notez-les. Chaque étape suivante y fait référence.

Étape 2 : choisir le format et le modèle de déploiement

Il y a ici trois décisions orthogonales, et les confondre est la deuxième erreur la plus courante dans la sélection d’un SBC.

Appliance matérielle vs SBC logiciel est la décision de format. Les appliances matérielles sont livrées comme des boîtiers à installer en rack. Les SBC logiciels s’installent sur des plateformes de virtualisation ou des instances cloud. La structure de coût de chaque option est très différente. Le matériel ajoute le rack, l’alimentation, le refroidissement, les contrats de maintenance fournisseur et un cycle de remplacement de 5 ans en plus du prix d’achat. Le logiciel transfère tout en OPEX sur une infrastructure que vous exploitez déjà. L’analyse complète se trouve dans la comparaison TCO SBC matériel vs SBC logiciel, et le parcours de migration pratique est couvert dans le guide de remplacement matériel vers logiciel.

Auto-hébergé vs géré couvre la décision de responsabilité opérationnelle. Auto-hébergé signifie que votre équipe configure, surveille, met à jour et dépanne. Géré signifie qu’un fournisseur de services assume cette charge opérationnelle à votre place, souvent avec HA et support 24×7 inclus. La question pivot n’est pas la capacité technique, mais l’endroit où le temps de votre équipe crée le plus de valeur. La comparaison SBC géré vs auto-hébergé examine les deux côtés.

Sur site vs cloud vs hybride règle la question de l’emplacement d’hébergement. Les exigences réglementaires (résidence des données RGPD, mandats gouvernementaux sur site), les interconnexions opérateurs sensibles à la latence et l’infrastructure existante poussent chacune la décision dans des directions différentes. La bonne nouvelle est que les SBC logiciels modernes fonctionnent sur les trois ; les décisions de format et de modèle opérationnel règlent généralement la question d’hébergement plutôt que l’inverse. Pour un examen plus approfondi de l’option cloud, consultez SBC pour les communications cloud.

Notez la réponse à chaque décision avant de parler aux fournisseurs. Si vous laissez une démonstration fournisseur répondre à la question, c’est la démonstration qui gagne.

Étape 3 : définir vos exigences non négociables

Avant d’examiner un seul fournisseur, notez les exigences qui disqualifient tout SBC ne les respectant pas. Faire cela en premier vous évite de vous laisser convaincre d’un contournement plus tard par une démonstration séduisante.

Plancher de sécurité pour tout SBC en production inclut TLS pour la signalisation SIP, SRTP pour le chiffrement média, la protection DoS et DDoS orientée SIP, la liste de blocage dynamique et la défense contre le balayage d’enregistrements SIP. Le guide de sécurité SBC couvre chaque couche en détail, et le guide de prévention des attaques DoS SIP couvre les défenses spécifiques. Tout SBC manquant l’une de ces couches n’est pas réellement prêt pour la production ; c’est un équipement de laboratoire vendu au prix de la production.

Posture de conformité dépend de votre géographie et de votre secteur. Les fournisseurs de services nord-américains ont besoin de la signature et vérification STIR/SHAKEN avec leur propre jeton SPC après la règle de certificat propre de la FCC. Les clients de la santé et de la finance ont besoin de preuves de chiffrement pour HIPAA et PCI DSS. Les déploiements en Europe et au Moyen-Orient exigent souvent la souveraineté des données, ce qui signifie que le SBC doit fonctionner sur une infrastructure sous votre contrôle direct. Les défaillances de conformité apparaissent dans les audits, pas dans les comparaisons de produits. Intégrez-les à la liste des exigences dès maintenant.

Intégrations sont les exigences liées à votre pile technique spécifique. Les déploiements Microsoft Teams en routage direct (Direct Routing) nécessitent un SBC capable de gérer le dialecte SIP de Teams, le mTLS et le SRTP correctement. Les plateformes cloud de centres de contact (Genesys, Five9, NICE) nécessitent un SBC BYOC validé en interopérabilité. Les systèmes PBX existants (NetSapiens, PortaOne, FreePBX, 3CX, Cisco UCM) nécessitent une compatibilité confirmée. Les systèmes de fraude, facturation ou CRM existants nécessitent un accès API depuis le SBC. Chaque élément devient un filtre oui/non sur votre liste restreinte.

Programmabilité est l’exigence la plus sous-estimée à ce stade et la plus regrettée par la suite. Les tables de routage statiques suffisent pour un appairage simple, mais tout ce qui va au-delà (attestation STIR/SHAKEN par appel, sélection dynamique d’opérateur, scoring de fraude en temps réel, routage piloté par CRM, interrogation LNP sur plus de 200 000 DID) nécessite un SBC avec une couche programmable ouverte. Le guide d’intégration API REST pour le routage SBC couvre le modèle architectural en détail.

Étape 4 : construire la matrice d’évaluation

Une matrice de notation est le seul moyen de maintenir une comparaison honnête une fois que les démonstrations et les devis commencent à arriver. Construisez-la avant de parler aux fournisseurs pour éviter que les critères ne soient ajustés rétroactivement en fonction de la démonstration qui a le plus impressionné votre équipe.

Incluez ces catégories pondérées dans la matrice :

• Qualité d’appel est le critère numéro un. Si la voix n’est pas claire et stable à travers le SBC, rien d’autre dans la matrice n’a d’importance. Effectuez des appels de test en laboratoire avec de l’audio réel, puis mesurez la gigue, la perte de paquets, le MOS, l’écho et la transmission DTMF à travers votre SBC candidat.
• Fiabilité et stabilité couvrent la haute disponibilité (HA), la géo-redondance entre centres de données, le CPS soutenu sous charge et le comportement du SBC lors du basculement. Le système doit rester fonctionnel le lendemain de l’installation, pas seulement pendant la démonstration.
• Sécurité englobe le chiffrement de la signalisation et du média (TLS, SRTP), le contrôle d’accès au SBC lui-même, la liste de blocage dynamique, la défense contre le balayage d’enregistrements SIP et la protection contre les attaques DoS/DDoS, le tout superposé. La sécurité est multifacette, pas une fonctionnalité unique.
• Interopérabilité mesure à la fois la normalisation SIP (gestion des RFC SIP en constante évolution et des dialectes spécifiques aux fournisseurs) et les capacités API (la capacité du SBC à se connecter à des services tiers comme la signature STIR/SHAKEN, les listes do-not-originate, le scoring de fraude, l’appel marqué et les listes de blocage dynamiques). La facilité de configuration compte autant que la capacité brute ; un SBC où chaque modification d’interopérabilité prend une semaine de travail expert est un coût à long terme.
• Évolutivité et flexibilité de déploiement examinent les sessions, le CPS, les enregistrements et les NAP/groupes de jonctions par rapport à vos chiffres de l’étape 1 avec une marge de croissance de 36 mois, ainsi que les hyperviseurs et clouds supportés et la capacité de la licence à évoluer de manière fluide à la hausse comme à la baisse selon votre trafic.
• Support et expertise signifient savoir qui répond quand quelque chose tombe en panne. L’équipe qui vous a aidé à configurer le SBC est-elle la même équipe qui le supporte au jour 90 et au jour 900 ? Les tickets sont-ils traités directement par des ingénieurs séniors, ou rebondissent-ils entre les niveaux avant d’atteindre quelqu’un capable de résoudre un problème d’interopérabilité SIP ?
• Modèle tarifaire compare par session vs forfaitaire, OPEX vs CAPEX, tarification publiée transparente vs devis uniquement, et le niveau de support inclus au prix affiché.
• Accès d’essai et d’évaluation dépend de la mise à disposition par le fournisseur d’une licence de laboratoire gratuite, d’un essai de production limité dans le temps et d’une configuration en libre-service, plutôt que de conditionner chaque évaluation à un appel commercial.

Pondérez chaque catégorie en fonction de votre activité spécifique. Un MSP évaluant le multi-tenant et la tarification par session classera les fournisseurs différemment d’un centre de contact évaluant le support 24×7 et la flexibilité des partenaires STIR/SHAKEN. La matrice vous appartient ; les catégories sont universelles.

Étape 5 : réaliser une véritable preuve de concept

Le principal facteur de regret post-achat est l’omission du POC. Les fournisseurs avec d’excellentes présentations et une expérience de déploiement médiocre remportent des contrats chaque trimestre. Le POC est le seul filtre qui détecte cet écart.

Un vrai POC teste, avec du trafic réel et des intégrations réelles :

• TLS et SRTP entre le SBC et au moins deux de vos pairs en amont réels.
• Normalisation des en-têtes SIP entre votre PBX ou opérateur existant et le nouveau SBC, avec au moins un cas d’interopérabilité problématique connu (en-têtes spécifiques au fournisseur, préférences de codec, gestion de fax T.38). Consultez la manipulation des en-têtes SIP pour les scénarios à tester.
• Signature STIR/SHAKEN via votre partenaire STI-AS choisi (TransNexus ClearIP, Neustar ou autre), avec les parcours d’attestation et de vérification exercés.
• Basculement HA si la redondance est une exigence. Débranchez le nœud actif et mesurez ce qui arrive réellement aux appels en cours.
• Comportement en charge de pointe à environ 1,5× vos sessions simultanées et CPS de pointe de l’étape 1. Le CPU, la mémoire et les taux d’erreur SIP sous charge vous révèlent ce qu’aucune fiche technique ne vous dira.
• Règles de fraude et de sécurité exercées dans des conditions réelles : liste de blocage dynamique lors d’un balayage SIP simulé, limites de débit DoS lors d’une inondation SIP, protection contre le balayage d’enregistrements face à des schémas de bourrage d’identifiants.

Tout fournisseur qui conditionne l’accès au POC à un appel commercial et à un NDA signé envoie un signal sur la nature de la relation à venir. Recherchez l’accès en libre-service. Le ProSBC Lab (gratuit, permanent, trois sessions) et l’essai de production de 30 jours fonctionnent sans appel commercial. Testez-les avec votre propre trafic avant de vous engager ailleurs.

Conservez l’environnement de test après la mise en production. Les opérateurs SBC les plus expérimentés maintiennent un laboratoire permanent en parallèle de la production, puis le soumettent à chaque mise à jour du soft-switch, chaque nouvel opérateur et chaque changement réglementaire avant que ces modifications n’atteignent le trafic de production. Le ProSBC Lab est permanent et gratuit précisément pour cette raison : les clients ne devraient pas avoir à choisir entre payer un second niveau de licence et entrer en production sans tests pour les modifications impactantes.

Si le POC révèle un déficit de capacité, ne supposez pas qu’il pourra être corrigé par logiciel avant la signature. Si le déficit est réel, la feuille de route du fournisseur est désormais votre risque de livraison.

Étape 6 : tester la tarification, le support et les conditions de sortie

La comparaison tarifaire est l’étape où la plupart des acheteurs pensent exceller, et celle où les fournisseurs avec des modèles de prix opaques extraient le plus de valeur. Trois règles s’appliquent.

Comparez sur le coût annualisé à votre nombre réel de sessions, support et HA inclus. Un prix affiché à partir de 1,40 $ par session par an et un prix « contactez le service commercial » ne sont pas comparables tant que vous n’avez pas obtenu le second par écrit. Exigez un devis écrit incluant le niveau de support dont vous avez réellement besoin (24×7 ou 9×5), la HA si nécessaire, chaque complément tarifaire par session (Teams DR, DNO, STIR/SHAKEN) et la progression tarifaire pluriannuelle. Si le fournisseur refuse de le mettre par écrit, c’est votre indicateur. La page de tarification ProSBC liste chaque niveau et chaque option publiquement. Utilisez-la comme référence lors de la lecture de tout autre devis fournisseur.

Auditez le modèle de support de la même manière que vous auditez la tarification. Temps de réponse moyen, parcours d’escalade, qui répond au téléphone à 3 h du matin, si le personnel de niveau 1 peut réellement résoudre un problème d’interopérabilité SIP ou se contente d’escalader. Demandez la localisation géographique de l’équipe de support et le niveau d’expérience de l’ingénieur le plus susceptible de traiter votre ticket. Puis posez une question supplémentaire : l’équipe qui vous aide à déployer le SBC est-elle la même qui le supporte au jour 90 et au jour 900 ? Si l’installation est gérée par un ingénieur de déploiement qui vous transfère ensuite à une file d’attente de tickets de premier niveau, l’expérience de support et l’expérience de déploiement sont en réalité deux produits différents vendus sous un même logo. Les chiffres publiés par les fournisseurs sur leurs sites web et ceux vécus par les acheteurs après signature divergent souvent, et les clients de référence sont le moyen de découvrir lequel est vrai.

Comprenez la sortie avant de comprendre le début. Qu’advient-il de votre configuration si vous migrez vers un autre SBC dans trois ans ? La logique de routage est-elle portable, ou verrouillée dans un environnement de scripting propriétaire ? Vos données sont-elles exportables dans des formats standard ? Existe-t-il une clause contractuelle de coopération pour les migrations ? Ces questions semblent prématurées dans un cycle de vente. C’est précisément la raison de les poser à ce moment-là.

Si vous souhaitez également examiner de plus près les coûts opérationnels cachés derrière une licence, la page le vrai coût de la gestion de votre propre SBC détaille les sept coûts cachés qui dominent les déploiements autogérés.

Pièges courants et signaux d’alarme

Les six étapes détectent la plupart des erreurs d’évaluation. Quelques anti-patrons spécifiques sont suffisamment fréquents pour être signalés séparément.

• Changer le SBC d’une manière que l’utilisateur final remarque transforme un déploiement techniquement réussi en crise de support client. Le pire scénario est de devoir changer les numéros de poste ou les plans de numérotation pour chaque utilisateur final après une migration. Le deuxième pire est une dégradation de la qualité d’appel dès le premier jour. L’objectif est une transition où l’utilisateur final ne réalise pas que le SBC a été changé.
• Surdimensionner en fonction du chiffre marketing du fournisseur plutôt que de votre pic réel. Plus gros n’est pas plus sûr quand vous payez par session chaque année.
• Considérer « la démo a fait X » comme un engagement crée un risque de livraison réel. Si la fonctionnalité n’est pas inscrite dans le contrat ou la documentation, supposez qu’elle n’existe pas.
• Acheter STIR/SHAKEN auprès d’un fournisseur avec un seul partenaire de signature propriétaire vous lie à l’économie d’un second fournisseur. Votre service de signature est un marché avec plusieurs prestataires (TransNexus, Neustar et autres), et un SBC qui vous limite à un seul partenaire contraint une relation distincte pour vous.
• Ne pas tester le basculement transforme la HA en affirmation fondée sur la confiance. Une HA jamais testée en basculement est une HA que vous allez découvrir défaillante lors de la panne où vous en avez réellement besoin.
• Engagement pluriannuel pour un déploiement de cinq ans ressemble à une remise et agit comme un piège. Le marché de la voix évolue plus vite que cela, et l’abonnement annuel avec renouvellement automatique est la norme moderne.
• Évaluations pilotées par les achats sans POC d’ingénierie produisent systématiquement le mauvais résultat. Le devis le moins cher qui coche les cases de la matrice est rarement le bon SBC ; l’équipe technique doit valider l’adéquation avant que les achats ne finalisent le contrat.

Où ProSBC se positionne dans votre évaluation

ProSBC est conçu pour un profil d’acheteur précis : le fournisseur de services, le MSP, l’ISP ou le centre de contact qui a besoin d’une capacité SBC de classe opérateur sans la complexité d’approvisionnement de niveau entreprise. Face aux six mêmes critères d’évaluation utilisés ci-dessus :

• Qualité d’appel est au cœur de l’héritage de ProSBC en tant que plateforme d’interconnexion SIP de classe opérateur. Le produit a été conçu d’abord pour le trafic SIP des fournisseurs de services, là où les exigences de qualité d’appel sont les plus strictes.
• Fiabilité repose sur la HA 1+1 actif/passif dans ProSBC+ et le déploiement géo-redondant sur plusieurs centres de données lorsque les exigences de disponibilité le justifient.
• Sécurité est multicouche : TLS pour la signalisation, SRTP pour le média, liste de blocage dynamique, protection contre le balayage d’enregistrements SIP, limites de débit DoS/DDoS et les profils de chiffrement requis par les clients des secteurs financier et assurance.
• Interopérabilité progresse à chaque version. Les améliorations de normalisation SIP sont livrées en continu, et une couche de routage programmable ouverte fournit des modules prêts à l’emploi (STIR/SHAKEN, do-not-originate, scoring de fraude) ainsi que la possibilité de créer des modules personnalisés pour toute intégration tierce.
• Évolutivité fonctionne dans les deux sens. ProSBC est licencié par session par an à partir de 1,40 $, la licence évolue de manière fluide à la hausse comme à la baisse selon votre trafic, et le déploiement est supporté sur AWS, Azure, VMware, KVM/Proxmox ou bare metal.
• Support sans niveaux. La couverture 24×7 dans chaque fuseau horaire va directement aux ingénieurs télécom de niveau 3 au siège de TelcoBridges, pas à un centre d’appels de premier niveau qui redirige vers le haut. L’équipe qui vous aide à configurer votre SBC est la même qui le supporte trois ans plus tard.
• Opérations incluent un tableau de bord de surveillance qui compare les modèles de trafic actuels aux moyennes historiques glissantes, avec des alertes d’anomalie acheminees vers votre application de messagerie préférée. Un service entièrement géré est également disponible, hébergé sur votre plateforme AWS, Azure, VMware ou KVM, ou hébergé par TelcoBridges si vous souhaitez décharger entièrement les opérations SBC de votre équipe.
• Évaluation en libre-service est disponible sans appel commercial, via le ProSBC Lab (gratuit, permanent, trois sessions) et l’essai de production de 30 jours. Les MSP, ISP et centres de contact recherchant des conseils spécifiques à leur segment devraient également lire le guide SBC pour les MSP.

ProSBC n’est pas le bon choix pour les acheteurs liés à une pile UC mono-fournisseur avec une intégration propriétaire profonde. Un environnement entièrement Cisco exécutant CUBE sur IOS XE, par exemple, tirera davantage parti de rester dans l’écosystème que d’une alternative orientée logiciel. Les pages de comparaison honnêtes ci-dessus montrent où chaque acteur en place a l’avantage.

Le moyen le plus rapide de valider l’adéquation est de faire fonctionner le ProSBC Lab avec votre propre trafic pendant une semaine. L’essai de production de 30 jours couvre les scénarios de POC plus approfondis de l’étape 5.

Foire aux questions

Combien de temps devrait prendre un processus de sélection de SBC ?

Pour un acheteur PME ou MSP, quatre à huit semaines du lancement à la signature est typique, incluant un POC de 30 jours. Une entreprise de taille moyenne avec un appel d’offres formel prend généralement deux à quatre mois. Un opérateur de niveau 1 avec un sandbox de 6 semaines et des exigences de clients de référence prend souvent six à 18 mois. Ne compressez le processus en dessous de la limite inférieure de ces fourchettes que si vous avez déjà réalisé un déploiement très similaire.

Quel est le critère le plus important lors du choix d’un SBC ?

L’adéquation avec votre segment d’acheteur. Un SBC conçu pour l’UC d’entreprise résout les problèmes d’UC d’entreprise et crée des frictions dans un déploiement MSP multi-tenant. Un SBC conçu pour les fournisseurs de services surpasse un SBC d’entreprise à 1 000 tenants et paraît sous-dimensionné dans un environnement Cisco UC à intégration profonde. Commencez l’évaluation en identifiant clairement la catégorie à laquelle vous appartenez.

Ai-je vraiment besoin d’un POC, ou puis-je me fier à une démonstration fournisseur ?

Vous avez besoin d’un POC. Les démonstrations sont orchestrées dans des environnements contrôlés par le fournisseur. Les POC s’exécutent avec votre trafic, vos pairs, votre PBX et votre posture de sécurité. Pratiquement chaque regret post-achat de SBC remonte à un POC omis ou compressé.

Dois-je envisager des SBC open source (OpenSIPS, Kamailio, FreeSWITCH) ?

Uniquement si vous disposez d’une équipe d’ingénierie capable de construire et durcir un SBC de production et de la bande passante pour continuer à le faire pendant cinq ans. Les SBC open source n’ont aucun coût de licence ; le coût total de possession est dominé par les heures d’ingénierie qui remplacent le fournisseur. C’est un choix viable pour un petit sous-ensemble d’acheteurs et une référence budgétaire utile pour tous les autres.

Comment évaluer la qualité du support avant de signer ?

Posez trois questions spécifiques. Le temps de réponse moyen à votre niveau de support. La localisation géographique et l’ancienneté de l’ingénieur qui traiterait un ticket de niveau 3. Et un client de référence spécifique avec un déploiement de taille similaire au vôtre. Les fournisseurs qui répondent de manière crédible aux trois méritent d’être présélectionnés ; ceux qui esquivent l’une d’entre elles vous montrent l’avenir.

Une stratégie SBC multi-fournisseurs, réalité ou marketing ?

C’est réel dans deux scénarios. Les fournisseurs de services gérant à la fois le peering PSTN et la voix d’entreprise déploient souvent un SBC pour chaque rôle. Les opérateurs qui acquièrent un concurrent héritent du SBC de l’acteur en place et exploitent deux piles pendant la migration. En dehors de ces cas, le SBC multi-fournisseurs est de la complexité opérationnelle gratuite. Choisissez-en un et exploitez-le bien.

Si j’ai un SBC, ai-je quand même besoin d’un pare-feu ?

Oui. Un SBC et un pare-feu réseau résolvent des problèmes différents. Le pare-feu gère le filtrage du trafic en couche 3/4 et la sécurité périmétrique générale. Le SBC gère la sécurité de couche 7 orientée SIP : protection DoS au niveau des méthodes SIP, défense contre le balayage d’enregistrements SIP, liste de blocage dynamique, filtrage des messages SIP malformés, masquage de topologie et chiffrement média. Les déploiements voix en production utilisent les deux. Le SBC est ce que vous placez devant votre PBX pour qu’un balayage d’enregistrements SIP n’atteigne jamais votre contrôle d’appels ; le pare-feu est ce qui protège le reste de votre réseau.

Quelle est la différence entre un SBC et un proxy SIP ?

Un proxy SIP transmet les requêtes SIP sans terminer les sessions. Il ne peut pas modifier les en-têtes, appliquer le chiffrement média ou masquer la topologie. Un SBC B2BUA termine et réémet entièrement la signalisation et le média, permettant la manipulation des en-têtes SIP, le masquage de topologie, la renégociation de codec, le SRTP et la protection DoS. Consultez l’analyse détaillée dans qu’est-ce qu’un proxy SIP.

Par où commencer si je suis au tout début d’une évaluation ?

L’étape 1 de ce guide est le point de départ. Une fois votre profil de trafic établi, la comparaison de fournisseurs SBC est le moyen le plus efficace de parcourir le marché. Si vous savez déjà que vous souhaitez un SBC logiciel, le guide de migration matériel vers logiciel est la couche suivante.

Regardez le webinaire d’accompagnement

Ce guide développe un récent webinaire Choosing the Right SBC animé par le PDG de TelcoBridges, Maximilien Le Sieur, et le VP des ventes, Sébastien Boyer. La session couvre les mêmes six catégories d’évaluation, les signes précoces indiquant que votre réseau a besoin d’un SBC (ou que celui que vous avez devrait être remplacé), et un Q&R en direct sur la méthodologie de test, la question SBC-plus-pare-feu, les modèles de déploiement pour PBX d’entreprise et les erreurs les plus fréquentes commises sous pression de délai.

Si vous êtes au début d’une évaluation, l’enregistrement est le moyen le plus rapide d’entendre comment les acheteurs expérimentés mènent réellement le processus.

Regardez le webinaire Choosing the Right SBC