Migrer depuis AudioCodes Mediant : guide pour les fournisseurs de services
Les déploiements AudioCodes Mediant fonctionnent. C’est rarement le problème. La question de la migration se pose lorsque quelque chose d’autre change : un Mediant 4000 ou 9000 reçoit un avis de fin de vie, une politique d’approvisionnement exclusivement OPEX arrive sur le bureau, l’unité centre de contact demande pourquoi le fournisseur de SBC inscrit également ses clients entreprise via Operator Connect, ou le poste de transcodage sur le devis de renouvellement n’a plus de sens. Aucun de ces déclencheurs n’exige de remplacer le reste de la pile AudioCodes. Le SBC est un composant unique en périphérie, et il peut être remplacé seul.
Cette page est la version opérationnelle de la comparaison avec l’alternative à AudioCodes. Elle suppose que la décision d’évaluer un remplacement a été prise et détaille ce à quoi ressemble concrètement une migration d’AudioCodes Mediant vers ProSBC : comment auditer la configuration Mediant existante, comment les objets de configuration AudioCodes correspondent à ceux de ProSBC, comment faire fonctionner les deux SBC en parallèle en toute sécurité, et comment planifier un basculement avec un véritable plan de retour arrière.
Ce qui déclenche une migration AudioCodes Mediant en 2026
Le déclencheur de migration est généralement l’un de quatre événements spécifiques, et non une insatisfaction générale envers la plateforme. Identifier lequel s’applique à un environnement donné détermine la portée du projet.
La fin de vie du matériel est le déclencheur le plus prévisible. AudioCodes a publié des avis de fin de vente et de fin de support pour des châssis Mediant plus anciens, y compris certaines révisions de processeurs de la série 4000 et des cartes antérieures de la série 1000. Lorsque l’appliance atteint la fin de support, le choix se résume à un remplacement chez le même fournisseur ou une migration propre vers un SBC logiciel fonctionnant sur du matériel standard.
La politique d’approvisionnement OPEX est le deuxième déclencheur. Les fournisseurs de services et les opérateurs de centres de contact qui ont fait passer toutes les autres catégories d’infrastructure en facturation par abonnement se retrouvent face à un engagement CapEx pour leur SBC. AudioCodes propose des tarifs par abonnement et à l’usage, mais le cycle de négociation et l’absence de tarifs publiés par session rendent difficile la modélisation des marges avant réception d’un devis.
Le conflit de canal concerne spécifiquement les MSP et les opérateurs de centres d’appel qui revendent les services d’appel Teams. AudioCodes est un partenaire Microsoft Premier et un fournisseur Operator Connect, ce qui signifie que le même fournisseur qui fournit le SBC vend également des services d’appel Teams aux clients potentiels du MSP. Migrer le SBC vers un fournisseur d’infrastructure sans programme Operator Connect élimine ce conflit au niveau technologique.
L’économie du transcodage est le quatrième déclencheur, et c’est celui qui tend à émerger tardivement. La licence de transcodage d’AudioCodes est facturée par canal et par codec, et à grande échelle, le poste sur un devis de renouvellement devient significatif. Les fournisseurs de services ayant besoin de la conversion Opus vers G.711 pour le trafic mobile et WebRTC sont les plus affectés.
Si le déclencheur s’applique à un seul Mediant dans un parc multi-SBC, la migration peut être limitée à cet élément. Le PBX, les opérateurs, le plan de numérotation et le reste de la flotte Mediant restent en place.
Phase 0 : inventorier ce qui tourne sur le Mediant aujourd’hui
Toute migration SBC réussie commence par un audit honnête de la configuration actuelle. Sauter cette étape est la cause la plus fréquente de surprises lors du basculement. Le résultat n’est pas une capture d’écran de l’interface Web AudioCodes, mais une liste structurée qui correspond proprement à ce dont le SBC de remplacement a besoin pour être configuré.
Extrayez les éléments suivants du Mediant existant avant de toucher à quoi que ce soit d’autre.
Nombre réel de sessions. Exportez 90 jours de CDR et identifiez le pic réel de sessions concurrentes, pas le maximum autorisé par la licence. La plupart des déploiements Mediant fonctionnent bien en dessous de leur capacité nominale, et le SBC de remplacement doit être dimensionné selon l’usage réel. ProSBC monte jusqu’à 60 000 sessions par serveur, donc la question pratique de dimensionnement porte généralement sur la licence, pas sur le matériel.
L’inventaire des IP Groups. Listez chaque IP Group sur le Mediant : trunks opérateurs, PBX, locataires Teams Direct Routing ou Operator Connect, plateformes d’enregistrement ou d’analyse SIP, et points de terminaison de test internes. Pour chacun, relevez le transport (UDP, TCP, TLS), l’adresse proxy, l’IP Profile attaché et le SRD auquel il appartient.
Le catalogue des IP Profiles. Documentez les préférences de codecs, les exigences de transcodage, la politique SRTP et TLS, les intervalles de keep-alive OPTIONS, la gestion des médias anticipés et toute particularité par côté pour chaque profil. Un déploiement Mediant réel comporte généralement moins de profils distincts que d’IP Groups, et un même profil est souvent réutilisé pour plusieurs pairs.
Manipulation Sets et tables de routage IP-to-IP. Exportez chaque règle de Manipulation Set et chaque entrée de routage. C’est la partie de la configuration qui porte le plus de logique métier : réécritures de P-Asserted-Identity pour des opérateurs spécifiques, normalisation de l’en-tête From, transformations du plan de numérotation, balisage d’attestation pour STIR/SHAKEN, etc. Tout ce qui ne survit pas à la migration est perdu au basculement.
Certificats, ACL et politique de sécurité. Relevez chaque certificat TLS et sa date d’expiration, chaque liste d’autorisation ou de blocage IP, chaque règle de classification et tout seuil DDoS. Le TLS en particulier exige une gestion minutieuse, car la chaîne de certificats sur le nouveau SBC doit satisfaire les mêmes pairs en amont et en aval sans rompre l’authentification mutuelle.
Intégrations STIR/SHAKEN et anti-fraude. Si le Mediant signe ou vérifie via le STIR/SHAKEN intégré d’AudioCodes, documentez le service de signature, le certificat et la politique d’attestation. Idem pour toute intégration anti-fraude téléphonique liée au SBC. Ces composants sont les plus susceptibles de nécessiter un choix architectural différent sur ProSBC, où la signature et la détection de fraude sont des fonctions natives du moteur de routage plutôt que des options de configuration.
Phase 1 : correspondance des objets AudioCodes Mediant avec les objets ProSBC
La principale source de friction lors d’une migration n’est pas le réseau, c’est le modèle de configuration. AudioCodes et ProSBC décrivent les mêmes fonctions SBC sous-jacentes avec des objets différents, et les ingénieurs chargés de la migration ont besoin d’un modèle mental fonctionnel de la correspondance avant de commencer la construction en laboratoire.
Le tableau ci-dessous couvre les objets présents dans chaque déploiement Mediant. La correspondance est conceptuelle, pas une équivalence ligne par ligne, et la colonne de droite capture la différence pratique qui affecte la façon dont la configuration est traduite.
| Objet AudioCodes Mediant | Équivalent ProSBC | Ce qui change en pratique |
|---|---|---|
| IP Group | NAP (Network Access Point) | Correspondance directe. Le NAP porte le transport, le proxy, la liste de codecs, les paramètres SRTP et ACL que le Mediant répartit entre l’IP Group et son IP Profile attaché. |
| SRD (SIP Realm Definition) | Regroupement de NAP dans la logique de routage | ProSBC n’a pas de conteneur de domaine séparé. La ségrégation par locataire ou unité d’affaires est gérée par le nommage des NAP, la logique du script de routage et les ACL, plutôt que par un objet de configuration parent. |
| IP Profile | Champs de configuration NAP et SIP Profiles | Le comportement SIP et média par côté est intégré au NAP ou aux Profiles. Tout ce qui dépasse la configuration NAP ou Profile sur ProSBC est commun à tous les NAP et trunks SIP. |
| Media Realm | Liaison d’interface média du NAP | La sélection de l’interface média est définie directement sur le NAP. Il n’y a pas d’objet de domaine à maintenir séparément. |
| SIP Interface | Transport NAP et interface de signalisation | Intégré au NAP. ProSBC traite l’interface de signalisation comme une propriété du NAP, pas comme une ressource partagée. |
| Message Manipulation Set | Routing Script (module Ruby) | Le changement conceptuel le plus important. Les listes de règles statiques deviennent du code procédural exécuté appel par appel. Les ingénieurs accèdent à des requêtes HTTP externes, de la logique conditionnelle sur n’importe quel paramètre d’appel et la possibilité d’intégrer la fraude, le LNP et STIR/SHAKEN dans la décision de routage elle-même. |
| Table de routage IP-to-IP | Table de routage plus Routing Script | Les entrées de routage simples se transposent directement. Le routage conditionnel (basculement opérateur, routage horaire, moindre coût) est implémenté dans le Routing Script plutôt que comme lignes supplémentaires dans la table. |
| Classification Rules | Correspondance IP source du NAP plus ACL | La classification entrante est gérée par la correspondance de l’IP source et des caractéristiques SIP avec la définition du NAP. |
| Coder Group | Liste de codecs du Profile | Les Profiles portent la liste de codecs, pas les NAP. Un seul Profile peut être assigné à plusieurs NAP, mais chaque NAP n’utilise qu’un seul Profile. |
| TLS Context | Configuration TLS du NAP et magasin de certificats | Les certificats sont téléversés une fois et référencés par NAP. Le mTLS pour Teams Direct Routing suit le même schéma que sur le Mediant. |
| STIR/SHAKEN (intégré) | Module de signature Routing Script | Le STIR/SHAKEN de ProSBC passe par le moteur de routage et s’intègre avec des fournisseurs STI-AS externes (TransNexus ClearIP, Neustar, ou tout service de signature HTTP) avec des points de terminaison primaire et secondaire et un repli P-Identity-Bypass. L’attestation devient une décision par appel plutôt qu’un paramètre par trunk. |
| OVOC / Routing Manager | Portail Web ProSBC plus API | La gestion centralisée se consolide dans le portail Web ProSBC. L’orchestration multi-éléments est gérée par l’API plutôt que par un produit de gestion séparé. |
La correspondance n’est pas la migration. C’est le contrat sur lequel s’appuient les deux phases suivantes.
Phases 2 à 4 : le plan de migration
Le plan ci-dessous suppose un seul Mediant remplacé par une seule instance ProSBC. Les déploiements Mediant multi-éléments suivent le même schéma élément par élément. La séquence complète dure généralement de quatre à huit semaines, du laboratoire au basculement, selon le nombre d’opérateurs et d’intégrations PBX concernés.
Phase 2 : construction en laboratoire
Déployez une instance ProLab sur le même segment réseau que le Mediant. La licence ProLab est gratuite de façon permanente, offre trois sessions concurrentes et se provisionne en une vingtaine de minutes. Utilisez le laboratoire pour répliquer un IP Group côté opérateur, un IP Group côté PBX et toutes les règles de Manipulation Set associées. L’objectif de la phase de laboratoire est de valider la correspondance du tableau de configuration ci-dessus par rapport au dialecte SIP spécifique que l’opérateur actuel envoie, et non de recréer la configuration de production complète.
Si Teams Direct Routing est concerné, testez le mTLS, le SRTP et le flux OPTIONS SBC-vers-Teams sur un locataire de test. La certification Teams compte comme critère d’achat dans certaines organisations : ProSBC prend en charge Teams Direct Routing et est déployé dans des environnements Teams DR en production, mais n’a pas obtenu la certification formelle Microsoft. Si une exigence de certification stricte existe, la liste publiée par Microsoft fait référence.
Phase 3 : réplication
Une fois la construction en laboratoire validée, construisez la configuration de production complète sur l’instance ProSBC. Répliquez chaque NAP à partir de l’inventaire des IP Groups, transposez les listes de codecs des IP Profiles et convertissez les Manipulation Sets en logique de module Ruby. C’est là que le temps est investi, et c’est la phase qui bénéficie le plus d’un inventaire Phase 0 propre.
Téléversez les certificats TLS et configurez les paramètres TLS au niveau du NAP. Si TLS et SRTP sont requis de bout en bout, validez les suites de chiffrement et les suites cryptographiques SRTP par rapport à ce que les opérateurs et le PBX négocient réellement, et non ce que la configuration du Mediant semble indiquer. Les écarts entre la politique configurée et le trafic observé sont la deuxième cause la plus fréquente de surprises au basculement.
Si la signature STIR/SHAKEN est concernée, pointez le script de routage vers le même service de signature externe utilisé par le Mediant, ou vers un autre fournisseur si la migration est le bon moment pour changer. Configurez les URL de signature primaire et secondaire et confirmez le comportement de repli P-Identity-Bypass.
Phase 4 : fonctionnement en parallèle
Maintenez le Mediant en production. Acheminez un trunk opérateur via ProSBC pendant que tous les autres trunks restent sur le Mediant. Deux à quatre semaines de fonctionnement en parallèle permettent généralement de détecter les cas limites que les tests en laboratoire ne peuvent reproduire : un en-tête P-Charge-Info inhabituel d’un opérateur spécifique, un comportement de renégociation de codecs aux heures de pointe, un intervalle OPTIONS qui diffère de la valeur documentée, ou un code de réponse SIP spécifique que le Mediant gère silencieusement et pour lequel ProSBC a besoin d’une règle explicite.
Comparez les taux de complétion d’appels, les scores MOS, la précision des CDR et les niveaux d’attestation STIR/SHAKEN entre les deux chemins pendant la période de parallèle. Si une règle de routage Mediant fait un travail que personne n’avait documenté, le découvrir sur cinq pour cent du trafic vaut bien mieux que le découvrir sur cent pour cent.
Basculement
Planifiez le basculement pendant une fenêtre de maintenance avec le Mediant sous tension et prêt. Déplacez les trunks opérateurs restants un par un, en validant chacun avant de passer au suivant. Mettez à jour les enregistrements DNS et toute référence de routage en amont pour pointer vers le ProSBC.
Laissez le Mediant sous tension et accessible pendant au moins trente jours. C’est le plan de retour arrière. Si un problème impactant les clients apparaît après le basculement, réacheminer le trafic vers le Mediant est un changement réseau plutôt qu’un projet de restauration. Une fois la fenêtre de validation passée, décommissionnez le châssis ou l’instance virtuelle Mediant et annulez le poste de support.
Validation post-basculement
Les soixante-douze premières heures après le basculement constituent la fenêtre de validation la plus productive. Trois vérifications comptent avant tout.
La réconciliation des CDR vérifie si les enregistrements d’appels sur le nouveau SBC correspondent au volume et au profil de l’ancien. Comparez les volumes d’appels heure par heure, la durée moyenne des appels et la répartition des codes de disposition entre la dernière semaine complète sur le Mediant et les trois premiers jours sur ProSBC. Une divergence pointe généralement vers une règle de routage qui n’a pas survécu à la transposition plutôt que vers un problème réseau.
La validation des seuils anti-fraude est particulièrement importante car les règles de détection de fraude téléphonique ajustées au comportement du Mediant peuvent soit se déclencher de manière excessive, soit manquer des schémas sur le nouveau SBC. Si un scoring de fraude en temps réel est intégré via TransNexus ClearIP, SecureLogix ou YouMail, surveillez la première semaine de décisions attentivement et ajustez les seuils en fonction des faux positifs observés.
La continuité de la supervision couvre toute la télémétrie qui sortait du Mediant : traps SNMP, flux syslog, flux CDR RADIUS, ou une intégration avec le produit de gestion d’éléments du Mediant. ProSBC expose des métriques par NAP et par appel qui peuvent alimenter Datadog, Prometheus, un SIEM ou un service de supervision géré. Confirmez que les tableaux de bord lisent le nouveau flux avant de déclarer le basculement terminé.
Pièges courants de migration
À travers les migrations de MSP, de FAI et de centres de contact, quatre pièges reviennent plus que tous les autres. Aucun n’est une surprise technique en soi, mais chacun tend à coûter un à deux jours s’il n’est pas anticipé.
Logique de Manipulation Set non documentée. Les déploiements Mediant accumulent des règles de réécriture d’en-têtes au fil des années, souvent ajoutées par des personnes qui ont depuis quitté l’équipe. Traiter les règles existantes comme faisant autorité sans comprendre pourquoi chacune existe est le moyen le plus sûr de casser un opérateur spécifique au basculement. La bonne approche est de revoir chaque règle de Manipulation Set pendant la Phase 0 et d’identifier celles dont le but n’est pas évident pour des tests explicites en Phase 4.
Hypothèses sur le transcodage. Les Mediant AudioCodes font du transcodage assisté par matériel pour un large ensemble de codecs, y compris Opus, G.729 et AMR. Le transcodage logiciel de ProSBC couvre actuellement G.711 ALAW et ULAW ; le transcodage de codecs plus larges est sur la feuille de route mais nécessite une confirmation soigneuse avant une migration qui en dépend. Le trafic mobile et WebRTC qui repose actuellement sur le transcodage Mediant nécessite un plan confirmé, pas une supposition.
Transfert des chaînes de certificats TLS. Les Mediant et leurs pairs en amont négocient parfois des chaînes de certificats incluant des intermédiaires que le Mediant sert automatiquement. Lorsque le même certificat est déplacé vers ProSBC, la configuration de la chaîne doit être explicite. Testez le mTLS pour Teams Direct Routing et tout trunk opérateur sécurisé par TLS en laboratoire avant de vous y fier en production.
Compatibilité d’hyperviseur pour la haute disponibilité Azure. ProSBC fonctionne sur VMware, KVM, Proxmox, AWS, Azure et matériel natif. La haute disponibilité native 1+1 sur Azure nécessite une configuration supplémentaire par rapport au comportement par défaut sur VMware ou KVM. Si le Mediant existant tourne sur Azure avec la haute disponibilité, identifiez cette exigence en Phase 2 plutôt que de la découvrir en Phase 4.
Foire aux questions
Combien de temps dure généralement une migration AudioCodes Mediant ?
De quatre à huit semaines, de l’audit Phase 0 au basculement complet, pour une migration à élément unique. La Phase 0 et la Phase 1 (audit et correspondance) prennent généralement une à deux semaines, la Phase 2 (construction en laboratoire) environ une semaine, la Phase 3 (réplication complète de la configuration) deux à trois semaines selon la complexité des Manipulation Sets, et la Phase 4 (fonctionnement en parallèle) deux à quatre semaines. Le basculement lui-même se fait en une seule fenêtre de maintenance. Les déploiements multi-éléments évoluent de façon linéaire : chaque Mediant remplacé ajoute son propre travail de Phase 3 et Phase 4.
Faut-il modifier notre PBX, notre plan de numérotation ou nos contrats opérateurs pour migrer ?
Non. Le SBC se situe en périphérie entre les opérateurs et l’infrastructure vocale interne, et le remplacer ne nécessite aucune modification du PBX, du plan de numérotation ni des contrats de trunk SIP avec les opérateurs. Le PBX continue de communiquer en SIP avec l’adresse IP que le SBC présente, et les opérateurs continuent de terminer les trunks vers l’adresse IP que le SBC leur présente. Seul l’équipement au milieu change.
Qu’advient-il de notre configuration STIR/SHAKEN pendant la migration ?
ProSBC implémente la signature et la vérification STIR/SHAKEN via son moteur de routage Ruby, en s’intégrant avec des fournisseurs STI-AS externes (TransNexus ClearIP, Neustar, ou tout service de signature HTTP) plutôt que via un module de signature intégré. Pendant la migration, le service de signature peut rester le même, ou cela peut être le moment d’évaluer un autre fournisseur. Les points de terminaison de signature primaire et secondaire assurent la redondance, et un repli P-Identity-Bypass garantit que les appels ne sont pas interrompus si le service de signature est brièvement indisponible. L’attestation devient une décision par appel dans le script de routage plutôt qu’une configuration par trunk.
ProSBC peut-il fonctionner sur le même hyperviseur que notre Mediant VE ?
Mediant VE prend en charge VMware, KVM, Hyper-V, OpenStack, AWS, Azure, GCP et les environnements conteneurisés. ProSBC fonctionne sur VMware, KVM, Proxmox, AWS, Azure et matériel natif. Si le déploiement Mediant VE existant est sur VMware, KVM, AWS ou Azure, ProSBC fonctionne sur la même plateforme. Hyper-V, GCP et les déploiements conteneurisés ne sont pas pris en charge actuellement sur ProSBC et nécessiteraient une décision de plateforme avant la migration. La haute disponibilité native sur Azure nécessite également une configuration supplémentaire sur ProSBC par rapport au comportement par défaut sur VMware et KVM.
Que faire si nous n’avons pas d’expertise SBC interne pour gérer la migration ?
TelcoBridges propose un service géré qui prend en charge la migration de bout en bout : audit Phase 0, correspondance de configuration, déploiement ProSBC, gestion du fonctionnement en parallèle et exécution du basculement. Le service géré inclut ProSBC+ avec haute disponibilité 1+1, support 24h/24 et 7j/7, et supervision continue. Il est hébergé soit sur l’infrastructure TelcoBridges, soit sur une plateforme choisie par le client. Pour les équipes sans ingénieurs SBC dédiés, c’est généralement la bonne voie : le coût d’une migration gérée représente une fraction du coût d’embauche d’un spécialiste SBC interne.
Quel est le plan de retour arrière en cas de problème après le basculement ?
Le Mediant reste sous tension et accessible pendant au moins trente jours après le basculement. Si un problème impactant les clients apparaît pendant cette fenêtre, réacheminer le trafic vers le Mediant est un changement réseau plutôt qu’un projet de restauration. Le plan en quatre phases est spécifiquement conçu autour de ce plan de retour arrière : le Mediant n’est jamais décommissionné tant que ProSBC n’a pas été validé sous du vrai trafic de production pendant plusieurs semaines. La plupart des migrations n’ont jamais besoin du retour arrière, mais l’avoir en place est ce qui rend le fonctionnement en parallèle et le basculement sûrs à exécuter.
Commencez la migration AudioCodes Mediant par un laboratoire, pas un engagement
Le moyen le moins risqué d’évaluer si ProSBC convient à un environnement AudioCodes Mediant existant est de déployer une instance ProLab et de répliquer un IP Group face à un véritable opérateur. La licence ProLab est gratuite de façon permanente, offre trois sessions concurrentes et se provisionne en une vingtaine de minutes. Aucun engagement commercial nécessaire pour commencer.
Pour les équipes qui préfèrent une évaluation guidée, le service géré couvre la migration complète : audit, correspondance, déploiement, fonctionnement en parallèle, basculement et opérations continues.
Vous comparez les fournisseurs ? Consultez la comparaison complète ProSBC vs. AudioCodes ou Remplacer un SBC matériel par un logiciel.