Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 7

Architecture logicielle des SBC AudioCodes Mediant

Recommended resources

Bonjour, et bienvenue dans ce deuxième module de notre formation. Après avoir solidement établi les fondamentaux du protocole SIP dans le premier module, nous allons maintenant nous concentrer sur l'équipement qui met en œuvre ces concepts : le SBC AudioCodes.

Dans la leçon précédente, nous avons conclu notre exploration de SIP en apprenant à capturer et analyser le trafic avec Wireshark, y compris la méthode Debug Recording spécifique à AudioCodes. Cette fonctionnalité est notre premier contact avec le logiciel interne du SBC. Aujourd'hui, nous allons aller plus loin en examinant ce logiciel de l'intérieur. L'objectif est de décrire l'architecture logicielle des SBC AudioCodes Mediant.

Comprendre comment un SBC est structuré — ses composants, leurs rôles et leurs interactions — est fondamental. C'est cette connaissance qui vous permettra de configurer, de dimensionner, de sécuriser et de dépanner efficacement ces systèmes. Pour un expert comme vous, passer de la connaissance du "quoi" (le protocole) à la maîtrise du "comment" (l'architecture interne) est une étape essentielle pour combler les lacunes et atteindre une expertise approfondie.

1. Le Principe Fondamental : Séparation des Plans

L'architecture logicielle de tous les SBC Mediant, qu'ils soient physiques ou virtualisés, repose sur un principe fondamental hérité du monde des télécommunications : la séparation des plans de traitement. Un appel VoIP se compose de deux types de trafic distincts, et le SBC les gère avec des composants spécialisés :

  1. Le Plan de Signalisation (Signaling Plane) : Il traite le protocole SIP. C'est le "cerveau" de l'opération. Il gère l'établissement, la modification et la terminaison des sessions d'appel. C'est ici que s'appliquent les règles de routage, la manipulation des messages SIP, et les politiques de sécurité.
  2. Le Plan Média (Media Plane) : Il traite les flux audio/vidéo réels (RTP/SRTP). C'est le "muscle" du SBC. Il est responsable du transfert des paquets média, du transcodage (conversion entre codecs), de la gestion du DTMF et de la sécurisation des flux (SRTP).

Cette séparation est la clé de la performance et de la scalabilité des SBC. Elle permet à chaque plan d'être optimisé pour sa tâche spécifique sans que l'un n'affecte les performances de l'autre.

2. Une Architecture Flexible : Matériel, Virtuel et Cloud

AudioCodes a conçu son logiciel Mediant pour être extrêmement flexible. La même logique architecturale peut être déployée de différentes manières, ce qui est un avantage considérable dans des projets de communications unifiées complexes.

[PDF] AudioCodes Mediant SBCs for Service Providers

Ce document marketing fournit une excellente vue d'ensemble de la philosophie produit d'AudioCodes. Il met en évidence la flexibilité de déploiement qui est au cœur de leur architecture logicielle.

Lisez l'introduction qui présente la famille Mediant et souligne que le logiciel est disponible sur du matériel propriétaire, des serveurs COTS (Commercial Off-The-Shelf) ou en tant que solution virtualisée. Ensuite, consultez la section "Flexibility and Scalability" qui renforce ce point, en garantissant une parité de fonctionnalités quel que soit le mode de déploiement.

Comme vous l'avez lu, que vous travailliez sur une appliance matérielle dédiée, une machine virtuelle (VM) sur un hyperviseur comme VMware/Hyper-V, ou un conteneur dans un cloud public (AWS, Azure), l'architecture logicielle de base reste cohérente.

3. L'Architecture du Mediant Cloud Edition (CE)

Le modèle qui illustre le plus clairement cette séparation des composants est le Mediant Cloud Edition (CE). Il est conçu comme une application "cloud-native" composée de microservices, ce qui rend sa structure explicite.

Ce diagramme illustre l'architecture du Mediant CE. On y distingue clairement la séparation entre les Signaling Components (SC) pour SIP et les Media Components (MC) pour RTP. Le Stack Manager gère le déploiement et l'élasticité de l'ensemble.

Analysons les éléments de ce diagramme en nous appuyant sur la documentation.

Overview of Elastic Media Cluster Mode - AudioCodes

Cette page du manuel utilisateur détaille précisément les composants du Mediant CE et leur mode de fonctionnement. C'est la description technique de référence de l'architecture que nous étudions.

Veuillez lire l'intégralité de cette page. Portez une attention particulière aux points suivants : La définition du Signaling Component (SC), qui gère la signalisation SIP et le load balancing du média. La définition des Media Components (MC), qui traitent le trafic média. La description des modèles de haute disponibilité (HA) : le mode Actif/Passif pour les SC et le mode Actif/Actif pour les MC. Le rôle du Stack Manager dans la gestion du cycle de vie de la solution.

Synthétisons ce que nous apprend cette lecture :

  • Signaling Components (SC) : Au nombre de deux, ils fonctionnent en mode 1+1 Actif/Passif.

    • Le SC Actif traite toute la signalisation SIP. Il reçoit les requêtes INVITE, applique les règles de routage et de manipulation, puis décide quel MC sera utilisé pour le flux média de cet appel. C'est également lui qui expose l'interface de gestion (Web, SSH).
    • Le SC Redondant (ou Standby) est une copie passive, prête à prendre le relais en cas de défaillance du SC actif, assurant ainsi la haute disponibilité du service de signalisation et de la gestion.

  • Media Components (MC) : Ils sont multiples et fonctionnent en mode N+1 Actif/Actif.

    • Chaque MC est un "moteur média" qui peut gérer un certain nombre de sessions RTP. Il s'occupe du transcodage, du traitement DTMF, du chiffrement SRTP, etc.
    • Le modèle N+1 signifie qu'il y a N composants actifs pour fournir la capacité requise, plus 1 composant de rechange. Le trafic est réparti sur les N composants. Si l'un d'eux tombe en panne, le composant de rechange devient actif et prend sa part de la charge, préservant ainsi la capacité média globale. Cette architecture permet également une élasticité : on peut ajouter des MCs pour augmenter la capacité média du SBC à la volée.

  • Stack Manager : C'est un outil externe qui orchestre l'ensemble. Il est responsable du déploiement initial des SCs et MCs dans l'environnement cloud (par ex. sur AWS via son API), de leur surveillance ("healing"), et de l'ajout ou du retrait de MCs en fonction de la charge (scaling). En tant que chef de projet, vous pouvez voir le Stack Manager comme l'outil d'automatisation de déploiement et d'opérations (DevOps) pour le SBC.

4. Des Composants Fondamentaux à Travers Toute la Gamme

Même si le modèle Mediant CE rend cette architecture très visible, les mêmes briques logicielles fondamentales sont présentes dans toute la gamme Mediant. AudioCodes s'appuie sur des composants développés en interne et éprouvés sur le terrain.

[PDF] AudioCodes Mediant SBCs for Service Providers

Revenons au document de présentation générale pour comprendre sur quoi reposent ces composants SC et MC.

Lisez la section qui commence par "AudioCodes SBCs are based on...". Elle explique que le SBC repose sur une pile SIP maison ("home-grown SIP stack") et un moteur média riche ("rich media engine").

Ce que cela signifie est simple :

  • Le Signaling Component (SC) est l'implémentation de leur pile SIP propriétaire.
  • Le Media Component (MC) est l'implémentation de leur moteur média, capable de transcodage et d'autres manipulations sur les flux RTP.

Sur une appliance matérielle (ex: Mediant 4000), ces deux fonctions logicielles tournent sur le même châssis, utilisant des processeurs généralistes pour la signalisation et souvent des processeurs de signal numérique (DSP) dédiés pour les tâches intensives du média. Sur une appliance virtuelle (ex: Mediant VE), elles tournent sur le même OS invité au sein d'un hyperviseur. Le modèle CE est simplement la désagrégation de ces deux fonctions en microservices indépendants et scalables.

Conclusion

Cette leçon nous a permis de "soulever le capot" du SBC AudioCodes pour en comprendre la mécanique interne. Vous êtes maintenant en mesure de décrire son architecture logicielle.

Points clés à retenir :

  • Séparation des plans : L'architecture distingue le plan de signalisation (SIP), géré par le Signaling Component (SC), du plan média (RTP), géré par le Media Component (MC).
  • Composants de base : Le SC est le cerveau (routage, manipulation SIP, gestion), tandis que les MCs sont les muscles (transcodage, flux RTP).
  • Haute Disponibilité et Scalabilité : La signalisation est redondée en mode 1+1 Actif/Passif. Le média est scalable et redondé en mode N+1 Actif/Actif, ce qui permet une grande élasticité.
  • Flexibilité de déploiement : Cette architecture logicielle peut être déployée sur des appliances matérielles, des serveurs COTS, des machines virtuelles ou dans le cloud, avec une parité de fonctionnalités.
  • Orchestration : Pour les éditions cloud (CE), un Stack Manager gère le cycle de vie complet de l'infrastructure du SBC.

Maintenant que nous avons une vision claire de l'architecture logicielle interne, nous sommes prêts pour la prochaine étape. Dans la leçon suivante, nous allons comparer les différents modèles de la gamme AudioCodes Mediant. Nous verrons comment cette architecture est déclinée en produits concrets, des petites appliances de bureau aux solutions de cœur de réseau pour opérateurs, afin de répondre à des besoins variés en termes de capacité et de cas d'usage.