Migration de Sonus SBC vers ProSBC : pourquoi les ingénieurs voix quittent l’infrastructure Sonus héritée
Le nom Sonus figure encore sur un grand nombre de session border controllers installés dans des baies de production. L’entreprise à l’origine de ces équipements n’existe plus en tant qu’entité indépendante depuis 2017. Sonus Networks a fusionné avec GENBAND cette année-là et l’entité combinée a été renommée Ribbon Communications, ce qui signifie que les plateformes SBC 5100, 5200, 5110 et 5210 que les ingénieurs appellent encore « les boîtiers Sonus » sont désormais du matériel hérité sur une feuille de route contrôlée par Ribbon, et non par Sonus.
Pour les ingénieurs voix, la question porte rarement sur la capacité du matériel à acheminer les appels. C’est généralement le cas. La question se pose lorsque la plateforme atteint sa fin de support, lorsqu’un audit de sécurité signale un équipement qui ne reçoit plus de correctifs, ou lorsque Ribbon propose un remplacement complet vers sa gamme actuelle SBC 5400, 7000 ou SWe. À ce point de décision, un nombre croissant d’équipes profitent de ce changement imposé pour évaluer si rester dans l’écosystème Ribbon est réellement le bon choix.
Cette page couvre ce que signifie concrètement exploiter une infrastructure Sonus héritée aujourd’hui, le calendrier précis de fin de support de la gamme SBC héritée, et ce qu’implique une migration d’un Sonus SBC vers ProSBC. Si vous comparez ProSBC à la gamme actuelle de Ribbon plutôt que de planifier une migration hors du matériel hérité, la comparaison ProSBC et Ribbon SBC est un meilleur point de départ, et cette page suppose que vous l’avez déjà lue ou que vous le ferez.
Comment Sonus est devenu Ribbon, et pourquoi votre SBC affiche encore Sonus
La confusion de marque mérite d’être clarifiée car elle conditionne la conversation sur le support. Sonus Networks a annoncé sa fusion avec GENBAND en mai 2017, dans un accord qui donnait aux actionnaires de chaque entreprise environ la moitié de l’entité combinée et valorisait la nouvelle structure à environ 745 millions de dollars. La fusion a été finalisée plus tard cette année-là et l’entreprise a adopté le nom Ribbon Communications.
Le portefeuille de produits Sonus n’a pas disparu à ce moment-là. Les plateformes SBC de la série 5000, les passerelles média GSX et le serveur de politiques PSX ont tous été maintenus sous le nom Ribbon, et les équipes d’ingénierie ont continué à les entretenir pendant des années. C’est pourquoi un équipement acheté en 2015 ou 2016 démarre toujours avec la marque Sonus alors que chaque bulletin de support, avis de fin de vie et devis de renouvellement arrive désormais sur papier à en-tête Ribbon.
La conséquence pratique est que « nous utilisons Sonus » et « nous sommes client Ribbon » décrivent la même situation. Les décisions de feuille de route, le cycle de vie du support et la tarification des mises à niveau pour ce matériel hérité sont tous déterminés par Ribbon aujourd’hui.
La réalité opérationnelle d’une infrastructure Sonus non supportée
La fin de support n’est pas une échéance indicative. Lorsqu’une plateforme la dépasse, le fabricant cesse de livrer des mises à jour logicielles, cesse de publier des correctifs de sécurité et cesse d’accepter des demandes de support. Pour la gamme Sonus héritée, ces dates sont déjà passées : les SBC 5100 et 5200 ne sont plus supportés depuis février 2020, et les SBC 5110 et 5210 ont suivi en octobre 2023.
Ribbon elle-même présente la situation en termes de sécurité. Sa notification de fin de support pour les 5110 et 5210 indique clairement que les organisations qui exploitent encore ces plateformes disposent de réseaux vulnérables aux cyberattaques, et cite les rançongiciels, l’exposition à la conformité et le risque de gouvernance des données comme préoccupations spécifiques. Cette évaluation provient du fabricant qui a conçu le matériel, et c’est le signal le plus clair qu’un ingénieur voix peut invoquer en interne pour justifier un budget de migration.
L’exposition se cumule de plusieurs façons. Un SBC se trouve en bordure de réseau et fait office de frontière de sécurité pour tout le trafic SIP, donc un SBC non corrigé est un pare-feu non corrigé pour le réseau voix. Le matériel en service depuis huit ou dix ans accumule également un risque physique : les alimentations, ventilateurs et supports de stockage vieillissent, et les pièces de rechange pour un châssis en fin de support deviennent plus difficiles à trouver. Côté conformité, les cadres de sécurité et les audits clients exigent de plus en plus que l’infrastructure en bordure de réseau fonctionne avec un logiciel supporté et un cycle de correctifs à jour, et une gamme de produits retirée ne peut pas satisfaire cette exigence, quelle que soit la stabilité de l’équipement.
Rien de tout cela ne signifie qu’un Sonus SBC hérité va tomber en panne demain. Beaucoup fonctionnent pendant des années au-delà de leur date de fin de support sans incident. Le point essentiel est que le risque n’est plus activement géré par quiconque, et que le coût de ce risque repose entièrement sur l’équipe qui exploite l’équipement.
Le carrefour : remplacement par du Ribbon actuel ou migration vers un autre fournisseur
Une fois le délai de support expiré, le parcours recommandé par Ribbon est un remplacement complet vers sa gamme actuelle, généralement l’appliance SBC 5400 ou 7000 ou l’édition logicielle SBC SWe. Ce parcours maintient le modèle de configuration familier et préserve les connaissances opérationnelles existantes, ce qui a une vraie valeur pour une équipe qui a investi des années dans l’outillage Sonus.
Il rouvre également toutes les questions commerciales et architecturales qui accompagnaient l’achat initial. Passer au SBC SWe place le déploiement sur une plateforme logicielle actuelle, mais pour de nombreux opérateurs de taille intermédiaire, cette plateforme a historiquement fonctionné sur VMware, qui suit sa propre trajectoire de coûts après les changements de licences Broadcom. Le STIR/SHAKEN de Ribbon passe par un composant PSX séparé plutôt que d’être intégré au SBC. La tarification reste sur devis plutôt que publiée. Ce ne sont pas des critiques nouvelles, et elles sont couvertes en détail dans la comparaison ProSBC et Ribbon SBC, donc cette page ne les répète pas. Le point pertinent pour une décision de migration est qu’un remplacement complet est lui-même un projet avec un laboratoire, une exploitation en parallèle et une bascule, ce qui signifie que l’effort supplémentaire pour évaluer un autre fournisseur pendant cette même fenêtre est faible.
C’est le raisonnement que suivent de nombreux ingénieurs voix. Le remplacement matériel va avoir lieu de toute façon. Si l’équipe met déjà en place une nouvelle infrastructure, l’exploite en parallèle et bascule le trafic, faire ce travail vers ProSBC plutôt que vers une nouvelle appliance Ribbon coûte peu d’effort supplémentaire et élimine les points de friction récurrents en même temps. Pour une vue plus large des forces qui poussent les opérateurs des appliances fixes vers le logiciel, le guide de remplacement des SBC matériels par du logiciel expose le cas général, et l’analyse TCO SBC matériel versus logiciel chiffre le tout.
Ce qu’implique une migration hors de Sonus
Une migration Sonus vers ProSBC est davantage un problème de traduction de configuration qu’un problème réseau. Les deux plateformes remplissent les mêmes fonctions SBC mais les décrivent avec des objets différents, donc la première tâche consiste à construire un modèle mental de la correspondance entre la configuration Sonus et ProSBC.
Le tableau ci-dessous couvre les objets qui apparaissent dans pratiquement tous les déploiements Sonus. Aucune des correspondances n’est exacte, donc la troisième colonne est celle qui compte : elle décrit comment chaque concept Sonus se comporte différemment une fois reconstruit sur ProSBC.
| Objet Sonus SBC | Équivalent ProSBC | Ce qui change en pratique |
|---|---|---|
| Zone (Address Context) | Groupement NAP et logique de routage | ProSBC n’a pas de conteneur de domaine séparé. La séparation par tenant ou unité métier est gérée par le nommage des NAPs, la logique de script de routage et les ACLs plutôt que par un objet Zone parent. |
| SIP Signaling Port | Interface de signalisation NAP | L’interface de signalisation est une propriété du NAP sur ProSBC, et non une ressource gérée séparément et partagée entre les groupes de trunks. |
| SIP Trunk Group | NAP (Network Access Point) | La correspondance la plus directe. Un seul NAP porte le transport, le proxy, la liste de codecs et les paramètres ACL que Sonus répartit entre le groupe de trunks et ses attributs associés. |
| IP Peer | Proxy NAP et adresse distante | L’adresse distante que Sonus référence dans un routing label devient une propriété du NAP de destination. |
| ERE (Embedded Routing Engine) | Script de routage | La logique de routage local est transférée dans le moteur de routage ProSBC. Les décisions de routage statiques se traduisent directement ; la logique conditionnelle devient du code procédural exécuté par appel. |
| PSX (Policy Server) | Script de routage avec requêtes HTTP externes | Aucun serveur de politiques séparé n’est requis. La politique centralisée qui résidait dans le PSX est réimplémentée comme logique de script de routage, capable d’interroger des systèmes externes en HTTP pour les mêmes décisions que le PSX prenait. |
| Routing Labels | Table de routage et Script de routage | Les entrées de routage simples correspondent à la table de routage ; le basculement, le routage horaire et le routage au moindre coût sont déplacés dans le script. |
| STIR/SHAKEN via PSX | Module de signature du script de routage | La signature et la vérification passent par le moteur de routage et s’intègrent avec tout service de signature externe, avec des points de terminaison primaire et secondaire et un chemin de repli. L’attestation devient une décision par appel plutôt qu’un paramètre par trunk. |
| EMA / gestion Ribbon | Portail Web ProSBC et API | La gestion des éléments est consolidée dans le Portail Web ProSBC, avec l’orchestration multi-éléments gérée via l’API. |
Les phases qui suivent cette correspondance ne sont pas spécifiques à Sonus. Auditer le déploiement actuel, dimensionner le remplacement selon le trafic réel, monter un laboratoire, exploiter les deux SBC en parallèle, migrer les groupes de trunks un par un et décommissionner l’ancienne plateforme après validation est la même séquence quel que soit le fournisseur que vous quittez. Plutôt que de la répéter ici, le guide de remplacement des SBC matériels par du logiciel détaille ce cadre en cinq étapes, y compris comment extraire quatre-vingt-dix jours de CDR pour déterminer les pics réels de sessions simultanées et comment maintenir un chemin de retour arrière pendant la bascule.
Considérations spécifiques à la migration Sonus
Quelques éléments tendent à être spécifiques aux migrations Sonus plutôt que communs à tout changement de SBC, et ils méritent d’être identifiés lors de l’audit plutôt que découverts lors de la bascule.
Où réside réellement la logique de routage est la première question. Si le déploiement utilise un PSX externe, une grande partie de l’intelligence de routage et de politique se trouve sur le PSX plutôt que sur le SBC lui-même, et c’est cette logique qui doit être reproduite dans le script de routage ProSBC. Une équipe qui audite uniquement la configuration du SBC et néglige le PSX manquera la partie la plus importante de la migration. La cartographie de la politique PSX est généralement le poste de travail le plus important dans une migration Sonus.
Le cas ERE seul est plus simple. Les déploiements Sonus de plus petite taille qui n’ont jamais déployé de PSX conservent tout le routage dans le moteur intégré, et cette logique se traduit assez directement dans la table de routage et le script ProSBC. Savoir quel modèle le déploiement utilise, ERE seul ou avec PSX, permet de définir le périmètre du projet dès le début.
L’âge des certificats et du logiciel compte sur du matériel en service depuis avant le changement de nom vers Ribbon. Les certificats TLS sur un équipement vieux de dix ans peuvent utiliser des longueurs de clés vieillissantes ou des chaînes que les pairs en amont ne privilégient plus, et la migration est le moment naturel pour les renouveler plutôt que de porter du matériel obsolète.
L’export de configuration se fait en ligne de commande sur le Sonus SBC. La configuration en cours est capturée de manière la plus complète via la CLI plutôt que par des captures d’écran de l’interface de gestion, donc prévoyez de l’exporter en texte et de travailler à partir de ce fichier comme inventaire de référence.
Questions fréquentes
Mon Sonus SBC est-il encore supporté ?
Pour la gamme matérielle héritée, presque certainement pas. Les Sonus SBC 5100 et 5200 ont atteint leur fin de support le 2 février 2020, et les SBC 5110 et 5210 ont atteint leur fin de support le 15 octobre 2023, y compris les versions US Federal. Au-delà de ces dates, Ribbon ne publie plus de mises à jour logicielles, de correctifs de sécurité ni n’accepte de demandes de support pour ces plateformes. Si vous n’êtes pas certain du modèle que vous exploitez, l’étiquette du châssis et la version logicielle l’identifieront, et Ribbon publie les bulletins de fin de support pour chacun.
Quelle est la différence entre Sonus et Ribbon ?
Ce sont le même lignage de produits sous deux noms. Sonus Networks a fusionné avec GENBAND en 2017 et l’entreprise combinée a été renommée Ribbon Communications. Les plateformes SBC qui portent encore la marque Sonus ont été intégrées au catalogue de Ribbon, donc le support, la feuille de route et la tarification de ce matériel hérité sont tous gérés par Ribbon aujourd’hui.
Dois-je obligatoirement migrer vers le Ribbon SBC 5400 ou SWe ?
Non. Un remplacement vers la gamme actuelle de Ribbon est une option, mais ce n’est pas la seule. Parce que tout départ du matériel hérité nécessite de monter un nouveau SBC, de l’exploiter en parallèle et de basculer le trafic, le même effort de projet peut migrer vers ProSBC à la place. De nombreuses équipes traitent le remplacement matériel imposé comme le moment de réévaluer le fournisseur plutôt que de renouveler automatiquement dans l’écosystème Ribbon.
ProSBC peut-il remplacer un Sonus SBC 5100, 5200, 5110 ou 5210 ?
Oui. ProSBC est un SBC logiciel qui monte jusqu’à 60 000 sessions par serveur et fonctionne sur VMware, KVM, Proxmox, AWS, Azure ou bare metal, ce qui couvre la capacité de sessions de la gamme matérielle Sonus héritée avec une marge confortable. La migration est un exercice de traduction de configuration, faisant correspondre les Zones, groupes de trunks et la logique de routage aux NAPs et scripts de routage ProSBC, plutôt qu’un remplacement matériel à l’identique.
Qu’advient-il de la logique de routage de mon PSX ?
Les décisions de politique et de routage qui résident dans un PSX Sonus externe sont réimplémentées dans le script de routage ProSBC. Le script peut interroger des systèmes externes en HTTP pour les mêmes consultations que le PSX effectuait, donc la logique centralisée comme le routage au moindre coût, la traduction de numéros ou le scoring de fraude est transférée sans nécessiter de serveur de politiques séparé. L’audit de la configuration PSX est généralement la tâche la plus importante de la migration, et devrait être planifié tôt.
Comment la tarification de ProSBC se compare-t-elle au maintien chez Ribbon ?
ProSBC utilise une tarification par abonnement annuel publiée et peut descendre à 1,40 dollar par session par an, sans frais d’installation. Ribbon ne publie pas sa tarification, et un remplacement complet vers du matériel actuel implique à la fois de nouveaux coûts d’appliance ou de licence et les services associés. La comparaison commerciale et architecturale complète est couverte dans la comparaison ProSBC et Ribbon SBC.
Commencez la migration Sonus avec un laboratoire, pas un engagement
Le moyen le plus sûr de déterminer si ProSBC convient à un environnement Sonus existant est de déployer une instance ProLab et de reconstruire un groupe de trunks face à un opérateur réel. La licence ProLab est gratuite de façon permanente, offre trois sessions simultanées et se provisionne en environ vingt minutes, ce qui suffit pour valider la correspondance de configuration avec le SIP que vos opérateurs envoient réellement avant de vous engager.
Pour les équipes qui préfèrent ne pas gérer le projet en interne, le Service Managé couvre la migration de bout en bout : audit de la configuration Sonus et PSX existante, correspondance vers ProSBC, déploiement, gestion de l’exploitation en parallèle et exécution de la bascule, avec haute disponibilité 1+1 et support 24×7 inclus.
Vous préférez évaluer par vous-même d’abord ? Démarrez votre essai gratuit de 30 jours.