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 2

Interaction CUCM, SME et SBCs : Signalisation et Média

Recommended resources

Bonjour ! J'espère que la première leçon sur l'analyse des traces SIP vous a été utile. Vous avez maintenant les compétences pour "lire" un appel individuel. C'est comme savoir lire une phrase. Aujourd'hui, nous allons apprendre à lire le paragraphe entier, puis le chapitre.

L'objectif de cette leçon est de vous apprendre à schématiser l'interaction entre CUCM, SME et les SBCs, en détaillant les chemins de signalisation et de média.

À la fin de cette session, vous serez capable de dessiner une carte précise de votre infrastructure vocale. Cette carte est le document le plus important de votre audit. Sans elle, toute tentative de modification est hasardeuse. En comprenant où et comment la signalisation et la voix transitent, vous pourrez anticiper les impacts de chaque changement et planifier une migration sécurisée.

Nous allons d'abord solidifier la distinction fondamentale entre le chemin de la signalisation (SIP) et celui du média (RTP), puis nous examinerons comment chaque équipement (CUCM, SME, SBC) contribue à définir ces deux chemins.

1. Les Deux Chemins : Signalisation vs. Média

Dans la leçon précédente, nous avons établi que SIP gère la signalisation (établir, modifier, terminer l'appel) et que RTP transporte le média (la voix, la vidéo). Il est crucial de comprendre que ces deux flux ne suivent pas toujours le même chemin.

  • Chemin de Signalisation (Signaling Path) : C'est le trajet des messages SIP (INVITE, 200 OK, BYE, etc.). Ce chemin passe obligatoirement par tous les contrôleurs d'appel. Dans votre cas : CUCM -> SME -> SBC AudioCodes -> Opérateur PSTN. Chaque équipement sur ce chemin peut lire et modifier les messages SIP pour prendre des décisions de routage.

  • Chemin du Média (Media Path) : C'est le trajet des paquets RTP. Ce chemin est négocié via le protocole SDP (contenu dans les messages SIP). Le média peut, dans de nombreux cas, être plus direct. Par exemple, il peut s'établir directement entre le téléphone IP et le SBC, en contournant le CUCM et le SME une fois l'appel établi.

La différence majeure entre vos équipements est la suivante :

  • CUCM / SME : Agissent comme des "proxies" SIP. Ils routent la signalisation mais tentent de rester en dehors du chemin média autant que possible pour optimiser les ressources. On parle de media bypass.
  • SBC AudioCodes : Agit comme un Back-to-Back User Agent (B2BUA). Par définition, il se place au milieu des deux chemins. Il termine la session SIP et le flux RTP d'un côté (ex: côté LAN) et en initie une toute nouvelle de l'autre (ex: côté WAN). Le SBC est donc toujours dans le chemin de la signalisation ET du média. C'est son rôle de point de contrôle et de sécurité.
AudioCodes SBC Call Flow and CUCM Integration
Ce schéma illustre parfaitement le rôle du B2BUA. La partie supérieure montre qu'un appel est composé de deux "jambes" (legs) distinctes, une entrante (Inbound) et une sortante (Outbound). Le SBC se trouve au milieu, traitant à la fois la signalisation (SIP) et le média (RTP) pour chaque jambe.

2. L'Interaction vue du monde Cisco (CUCM & SME)

Pour comprendre comment le CUCM et le SME dirigent les appels, il faut maîtriser le concept de Trunk SIP et la manière dont les médias sont négociés.

Le document de référence de Cisco (SRND) est la meilleure source pour cela. Il explique en détail le fonctionnement des Trunks SIP sur le CUCM.

Cisco Collaboration System 12.x Solution Reference ...

Ce document, 'Cisco Collaboration System Solution Reference Network Design (SRND)', est la bible de l'architecture Cisco. Nous allons nous concentrer sur le chapitre dédié aux Trunks.

Veuillez lire les sections suivantes pour comprendre comment le CUCM gère les interactions : 'Unified CM Trunks Solution Architecture' (section 1) : Comprenez le rôle du Trunk comme canal de communication vers d'autres serveurs. 'SIP Offer/Answer Model' (section 3) et ses sous-sections 'SIP Delayed Offer' (section 4) et 'SIP Early Offer' (section 5) : C'est le cœur de la négociation média. Retenez qu'un 'Early Offer' (INVITE avec SDP) est souvent requis par les opérateurs, alors qu'un 'Delayed Offer' (INVITE sans SDP) est plus flexible en interne. 'Media Termination Points' (section 12) et 'DTMF Transport over SIP Trunks' (section 13) : Comprenez ce qu'est un MTP et pourquoi le CUCM peut être forcé d'en insérer un dans le chemin média (pour générer un Early Offer ou pour résoudre des incompatibilités DTMF).

Synthétisons les points clés de cette lecture pour notre objectif de schématisation :

  • Le Trunk SIP est la "porte de sortie" : Toute communication du CUCM/SME vers un autre système (un autre cluster, le SBC) passe par un Trunk SIP.
  • Offer/Answer définit le chemin média :
    • Le dialogue Offer/Answer dans le SDP échange les adresses IP (c=IN IP4 ...) et les ports (m=audio ...) que les équipements utiliseront pour s'envoyer le flux RTP.
    • Le CUCM essaie de passer les informations SDP de l'appelant directement dans le Trunk SIP. Si cela réussit, le chemin média est direct (téléphone <-> SBC).
  • L'insertion d'un MTP change le chemin média :
    • Si le terminal appelant ne peut pas fournir les informations SDP à temps (ex: un vieux téléphone SCCP, ou un appel arrivant via un Trunk H.323), et que le Trunk SIP de sortie exige un Early Offer, le CUCM insère un MTP (Media Termination Point).
    • Le MTP est une ressource média du CUCM. Son rôle est de "prêter" son adresse IP et son port pour l'Offer SDP.
    • Conséquence : Le chemin média n'est plus direct. Il passe par le MTP. Le flux RTP devient : téléphone <-> MTP sur CUCM <-> SBC. C'est ce qu'on appelle un "media hairpinning". Savoir si des MTP sont utilisés est donc essentiel pour cartographier le chemin média.
Cisco CUCM and SME Call Flow with Early and Delayed Offer
Ce schéma, tiré du SRND, est une excellente représentation visuelle. Les lignes jaunes représentent la signalisation SIP, qui passe toujours par le SME. Les lignes rouges représentent le média RTP. Notez comment, dans un cas, le média peut contourner le SME, alors que dans un autre (où un MTP ou un transcodeur est nécessaire), il est ancré sur un composant du cluster.

3. L'Interaction vue du monde AudioCodes (SBC)

Maintenant, regardons de l'autre côté de la barrière. Le SBC reçoit la signalisation et le média du monde Cisco et doit les acheminer vers le PSTN. Votre connaissance de l'administration AudioCodes est un avantage ici. Nous allons formaliser les concepts pour les intégrer dans notre schéma.

Configuration Note

Cette note de configuration AudioCodes, bien que spécifique à un opérateur, est parfaite pour nous. Elle détaille la configuration d'un SBC pour interconnecter un CUCM et un Trunk SIP externe, en expliquant chaque brique de configuration.

Parcourez les sections de configuration suivantes pour identifier les concepts clés qui définissent les chemins : Figure 2-1: Interoperability Test Topology (section 0) : Visualisez l'architecture globale CUCM -> SBC -> Opérateur. Step 1: IP Network Interfaces Configuration (section 1) : Comprenez la séparation physique/logique des interfaces (LAN/WAN). Step 3: Signaling Routing Domains Configuration (section 2) : C'est un point crucial. Lisez attentivement les sous-sections sur les Media Realms et les SIP Interfaces. Un Media Realm est lié à une interface réseau et définit où le média peut aller. Une SIP Interface est liée à une interface réseau et définit où la signalisation peut être écoutée. Step 5: Configure IP Groups (section 3) : L'IP Group représente une entité avec qui le SBC communique (le SME, l'opérateur...). C'est un objet logique fondamental pour le routage. Step 9: Configure IP-to-IP Call Routing Rules (section 4) : Observez comment une règle de routage prend un appel depuis un 'Source IP Group' et le dirige vers un 'Destination IP Group'. C'est ce qui matérialise le chemin de signalisation à travers le SBC.

Assemblons les pièces du puzzle AudioCodes :

  • Chemin de Signalisation : Un appel arrive du SME.

    1. Il est reçu sur une SIP Interface configurée sur l'interface réseau côté LAN.
    2. Le SBC identifie l'appelant comme appartenant à l'IP Group "SME".
    3. Une règle dans la table IP-to-IP Routing correspond à la source "IP Group SME".
    4. Cette règle indique que la destination est l'IP Group "Opérateur PSTN".
    5. Le SBC envoie un nouvel INVITE vers l'opérateur via la SIP Interface côté WAN.
      Le chemin de signalisation est donc défini par la chaîne SIP Interface (LAN) -> IP Group (SME) -> IP-to-IP Routing Rule -> IP Group (Opérateur) -> SIP Interface (WAN).

  • Chemin du Média :

    1. Dans l'INVITE venant du SME, le SDP indique une adresse IP source pour le RTP (celle du téléphone ou du MTP). Cette adresse doit être joignable depuis le SBC.
    2. Le SBC, en traitant la règle de routage, sait que l'appel provient de l'IP Group "SME", qui est associé à un Media Realm "LAN". Il s'attend donc à recevoir le média sur les ports et l'interface définis dans ce Realm.
    3. En créant le nouvel INVITE vers l'opérateur, le SBC insère sa propre information SDP. L'adresse IP et le port qu'il propose à l'opérateur sont tirés du Media Realm "WAN".
      Le chemin média est donc défini par la "couture" que le SBC réalise entre le Media Realm (LAN) et le Media Realm (WAN).
Testez votre compréhension !

Un appel sortant échoue. Dans les traces du SBC AudioCodes, vous voyez bien l'INVITE arriver du SME, mais aucun INVITE ne repart vers l'opérateur PSTN. En revanche, le SBC envoie une réponse 503 Service Unavailable au SME. En vous basant sur les concepts AudioCodes que nous venons de voir, quelle pourrait être la cause la plus probable de ce comportement au niveau du SBC ?

Voir la réponse

La cause la plus probable est un problème dans la table IP-to-IP Routing. Le SBC a bien reçu l'appel et l'a classifié comme venant de l'IP Group du SME, mais il n'a trouvé aucune règle de routage correspondant à cet appel pour l'acheminer vers l'IP Group de l'opérateur. Ne sachant où envoyer l'appel, il le rejette avec une erreur 503 Service Unavailable, indiquant que le service de routage pour cette destination n'est pas disponible.

4. Synthèse : Construire votre Schéma

Vous avez maintenant tous les éléments pour créer un schéma complet. Prenez une feuille de papier ou un outil de diagramme et commencez à dessiner.

Voici une trame que vous pouvez suivre pour un appel sortant standard :

  1. Dessinez les boîtes : Une pour chaque cluster CUCM, une pour le SME, une pour chaque SBC, et une pour chaque opérateur PSTN.
  2. Tracez le chemin de signalisation (par exemple, en ligne pleine) :
    • Départ : Téléphone IP -> CUCM.
    • CUCM -> Trunk SIP -> SME.
    • SME -> Trunk SIP -> SBC (notez l'IP Group et la SIP Interface d'entrée).
    • SBC -> Trunk SIP Opérateur (notez l'IP Group et la SIP Interface de sortie).
    • Ajoutez les adresses IP/ports clés à chaque jonction.
  3. Tracez le chemin du média (par exemple, en ligne pointillée) :
    • Cas 1 (Optimal) : Téléphone IP -> SBC (notez le Media Realm d'entrée). Puis SBC (notez le Media Realm de sortie) -> Opérateur PSTN. Le média contourne CUCM/SME.
    • Cas 2 (Avec MTP) : Téléphone IP -> MTP (sur CUCM/SME) -> SBC. Puis SBC -> Opérateur PSTN. Le chemin média est différent.
  4. Répétez pour les autres flux : Faites le même exercice pour un appel entrant (PSTN -> Téléphone IP) et pour un appel inter-sites (Téléphone A sur CUCM 1 -> Téléphone B sur CUCM 2, via SME).

Ce schéma visuel sera votre guide tout au long du projet. Il matérialise les dépendances entre les systèmes.

Conclusion

Félicitations ! Vous avez franchi une étape cruciale. Vous ne vous contentez plus de suivre un appel, vous êtes capable de cartographier l'ensemble des autoroutes de communication de votre infrastructure.

Points clés à retenir :

  • La distinction Signalisation vs. Média est fondamentale pour comprendre les flux réels.
  • Côté Cisco, les SIP Trunks et la négociation Offer/Answer (avec l'éventuelle insertion de MTP) définissent la manière dont un appel quitte le système.
  • Côté AudioCodes, le SBC agit en B2BUA, où les IP Groups et les IP-to-IP Routing Rules définissent le chemin de signalisation, tandis que les Media Realms définissent le chemin du média.
  • Un schéma complet doit représenter ces deux chemins distinctement pour chaque type de flux d'appel majeur.

Prochaine étape :
Maintenant que nous avons le plan architectural, il est temps de le remplir avec des données réelles. Dans la prochaine leçon, nous allons voir comment documenter la logique de routage actuelle en extrayant et interprétant les configurations concrètes du CUCM (via le Route Plan Report), du SME, et des SBCs AudioCodes. Nous allons passer du "quoi" au "comment".