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 3

Comprendre le routage d'appels : CUCM, SME et SBC AudioCodes.

Recommended resources

Bonjour !

Dans la leçon précédente, nous avons dessiné la carte conceptuelle de votre infrastructure, en distinguant les chemins de signalisation (SIP) et de média (RTP) et en clarifiant le rôle de chaque équipement. Vous avez maintenant une vue d'ensemble de l'architecture.

Aujourd'hui, nous allons passer de la théorie à la pratique. L'objectif de cette leçon est de vous apprendre à documenter la logique de routage actuelle en extrayant et interprétant les configurations de CUCM (Route Plan Report), SME et des SBCs AudioCodes. Nous allons transformer notre carte conceptuelle en un document technique précis, basé sur les configurations réelles de vos systèmes. C'est une étape indispensable de l'audit : sans une compréhension parfaite de l'état actuel, planifier le décommissionnement serait comme naviguer sans carte.

1. Décrypter la Logique de Routage de Cisco (CUCM & SME)

Le cœur du routage dans l'univers Cisco est le Route Plan. Il s'agit d'un ensemble d'objets de configuration qui fonctionnent en tandem pour décider où envoyer un appel. Votre expérience en administration CUCM vous sera précieuse ici ; notre but est de systématiser l'analyse pour votre audit.

Comprendre les Composants du Route Plan

Avant d'extraire les données, il est essentiel de maîtriser le rôle de chaque composant. Un appel est routé sur CUCM/SME en répondant à deux questions : "Qui a le droit d'appeler ce numéro ?" (Analyse) et "Où envoyer l'appel ?" (Routage).

Call Routing and Path Selection > Configuring Globalized ...

Pour solidifier ces concepts, nous allons nous appuyer sur un excellent article de Cisco Press qui décompose la logique de routage du CUCM. Il servira de référence pour interpréter les configurations que vous allez extraire.

Veuillez lire les sections suivantes pour bien assimiler l'enchaînement logique : Lisez l'introduction et la section 'Call Routing and Path Selection' pour revoir les concepts de base du routage et la différence entre sources et cibles. Concentrez-vous sur la logique de 'closest-match' et le fonctionnement des timeouts inter-chiffres décrits au début. C'est la base de l'analyse. Parcourez les sections 'Route Groups', 'Route Lists', et 'Route Patterns'. C'est la structure hiérarchique à 3 niveaux (Pattern -> List -> Group) qui matérialise le chemin de sortie. Retenez bien leur interaction. Enfin, examinez la Table 19-4 qui liste les caractères spéciaux (@, !, X, ., etc.). Savoir les interpréter est crucial pour lire un Route Pattern.

Synthétisons la logique de routage que vous devez documenter :

  1. Route Pattern (le "SI") : C'est le motif (ex: 9.0[1-7]!) qui doit correspondre au numéro composé. Il vit dans une Partition.
  2. Partition (la "pièce") : C'est un conteneur logique pour les Route Patterns. Elle permet de segmenter le plan de numérotation.
  3. Calling Search Space (CSS - le "passe-partout") : C'est une liste ordonnée de Partitions. Le CSS est assigné à un appareil (téléphone, trunk) et définit les "pièces" (Partitions) qu'il a le droit de regarder pour trouver un Route Pattern correspondant.
  4. Route List (le "carnet d'adresses") : Une fois qu'un Route Pattern est trouvé, il pointe vers une Route List. Celle-ci contient une liste priorisée de chemins possibles.
  5. Route Group (la "porte de sortie") : Chaque chemin dans la Route List pointe vers un Route Group. Le Route Group contient la ou les destinations finales : les Trunks SIP ou les gateways.
CUCM Call Routing Examples with Failover and Transformations
Ce schéma illustre parfaitement cette hiérarchie. Un Route Pattern (en haut, `882XXX`) pointe vers une Route List (`RL-BB-CMS-Failover`). Cette liste contient plusieurs Route Groups (`RG-BB-CMS-LOCAL` et `RG-HQ-CMS-REMOTE`) qui eux-mêmes contiennent les Trunks SIP menant aux systèmes distants. C'est cet enchaînement que vous devez reconstituer.

Contexte SME : Votre SME fonctionne sur les mêmes principes qu'un CUCM. Sa configuration est un "super" Route Plan dont le rôle principal est de recevoir des appels des clusters CUCM ("leafs") via des Trunks SIP et de les router vers d'autres clusters ou vers les SBCs. L'analyse est donc identique.

Comment Extraire la Configuration

Maintenant que la logique est claire, voyons comment obtenir les données.

Méthode 1 : Le Route Plan Report (L'approche visuelle)

C'est la méthode la plus simple et la plus directe pour avoir une vue d'ensemble. C'est une fonctionnalité native de l'interface d'administration du CUCM/SME.

  1. Naviguez vers Call Routing > Route Plan Report.
  2. Laissez le champ de recherche vide et cliquez sur Find pour voir tous les motifs configurés (Directory Numbers, Route Patterns, etc.).
  3. Vous obtenez une liste de tous les patterns, leur type, et la partition dans laquelle ils se trouvent.

Pour exporter ce rapport, utilisez l'option "View in file".

CUCM Route Plan Report Generation Interface
Cette capture d'écran vous montre l'interface du Route Plan Report. L'option cruciale pour votre documentation est le lien 'View in file' qui vous permet de télécharger le rapport complet au format CSV pour une analyse hors ligne.

Méthode 2 : L'Export de Configuration (L'approche exhaustive)

Pour une analyse en profondeur, le Bulk Administration Tool (BAT) est votre meilleur allié. Il permet d'exporter la quasi-totalité de la configuration sous forme de fichiers CSV, un par type d'objet.

Successfully Migrating to and deploying Webex Calling

La présentation Cisco Live suivante explique les différentes méthodes d'extraction de données. Nous allons nous concentrer sur la méthode 'Config Export' via BAT, qui est la plus pertinente pour un audit complet.

Veuillez consulter les diapositives suivantes : Diapositive 47 ('Config Export') : Cette diapositive explique ce qu'est l'export de configuration : un fichier TAR contenant un CSV pour chaque type d'objet (huntlist.csv, routepattern.csv, etc.). C'est la source de données la plus complète. Diapositive 49 ('Config Export Tar and CSV Files') : Notez le défi mentionné : la complexité de l'analyse manuelle de ces fichiers. Cela renforce l'idée qu'il faut savoir quoi chercher. Diapositive 60 ('Example: User Relations based on Hunt Pilots') : Cet exemple, bien que centré sur les utilisateurs, montre la méthodologie pour croiser les informations entre plusieurs fichiers CSV (huntpilot.csv -> huntlist.csv -> linegroup.csv...). C'est exactement l'approche que vous utiliserez pour le routage.

Pour votre audit de routage, les fichiers CSV les plus importants à extraire et analyser seront :

  • routepattern.csv
  • callingsearchspace.csv
  • partition.csv
  • routelist.csv
  • routegroup.csv
  • siptrunk.csv

En croisant les données de ces fichiers (par exemple, avec des fonctions de recherche dans Excel ou un petit script), vous pouvez reconstituer précisément n'importe quel flux d'appel.

Testez votre compréhension !

Un téléphone est configuré avec un CSS nommé CSS_Utilisateurs_Standard. Ce CSS contient, dans cet ordre, les partitions PT_Interne et PT_Externe.

Voici les Route Patterns configurés :

  1. Pattern : 8XXX, Partition : PT_Interne, Destination : Trunk_Intercluster_SME
  2. Pattern : 91XXXXXXXX, Partition : PT_Externe, Destination : RL_Sortant_PSTN
  3. Pattern : 9XXXXXXXXX, Partition : PT_Externe, Destination : RL_Sortant_National

Un utilisateur compose le 91408555123. Quel Route Pattern sera utilisé et pourquoi ?

Voir la réponse

Le Route Pattern utilisé sera le n°2 (91XXXXXXXX).

Voici pourquoi : le CUCM applique la logique du "correspondance la plus longue" (longest match).

  • Le numéro 91408555123 correspond à la fois au pattern n°2 (91XXXXXXXX) et au n°3 (9XXXXXXXXX).
  • Cependant, 91XXXXXXXX est plus spécifique (plus long) que 9XXXXXXXXX.
  • Le CUCM choisit donc toujours le pattern le plus précis. La priorité des partitions dans le CSS n'intervient que si deux patterns identiques existent dans des partitions différentes.

2. Décrypter la Logique de Routage des SBC AudioCodes

Passons maintenant aux SBCs. Comme nous l'avons vu, le SBC est un B2BUA. Sa logique de routage est plus directe mais tout aussi puissante. Votre familiarité avec l'administration AudioCodes va nous permettre d'aller droit au but.

Rappel des Composants Clés

La logique repose sur l'enchaînement que nous avons vu dans la leçon précédente :

  • Un appel arrive, son IP source le fait correspondre à un IP Group (ex: "IG_SME").
  • Une règle dans la table IP-to-IP Routing est recherchée, qui correspond au groupe source ("IG_SME") et potentiellement au numéro appelé.
  • Cette règle désigne un IP Group de destination (ex: "IG_PSTN_Orange").
  • L'appel est envoyé à la destination.

Les SIP Manipulation Rules (SMM) peuvent intervenir à n'importe quelle étape pour modifier le message SIP (numéro, en-têtes...). Elles font partie intégrante de la logique de routage.

Comment Extraire et Interpréter la Configuration

La méthode la plus fiable pour documenter un SBC AudioCodes est d'exporter sa configuration complète, le fichier .ini.

  1. Extraction : Depuis l'interface web du SBC, allez dans Troubleshoot > INI file. Vous pouvez y télécharger le fichier de configuration en cours. C'est un simple fichier texte.

  2. Interprétation : Ouvrez le fichier .ini dans un éditeur de texte. Voici où trouver les informations clés :

    • IP Groups : Cherchez la section [ProxySets]. Chaque bloc définit un IP Group avec son nom (ProxySetName), son ID (ProxySetID) et les adresses IP des serveurs qui le composent (ProxyAddress). Identifiez les IP Groups pour votre SME, vos opérateurs, etc.
    • IP-to-IP Routing Rules : Cherchez la section [IP2IPRouting]. C'est le cœur du routage. Chaque ligne est une règle. Les colonnes importantes sont :
      • SourceProxySet : L'ID de l'IP Group source.
      • DestProxySet : L'ID de l'IP Group de destination.
      • SourcePrefix / DestPrefix : Permettent de filtrer sur le numéro appelé/appelant.
      • MessageManipulationID : L'ID de la règle de manipulation à appliquer. Si différent de -1, c'est un point d'attention crucial.
    • SIP Manipulations : Si une règle de routage utilise une manipulation, trouvez la section [MessageManipulations] et la sous-section correspondante pour voir exactement ce qui est modifié.

Votre travail de documentation consiste à lire cette table [IP2IPRouting] et à la traduire en phrases logiques : "Si un appel arrive de l'IP Group 'SME' avec un numéro commençant par '0', alors il est envoyé vers l'IP Group 'Opérateur' après avoir appliqué la manipulation 'Supprimer_le_0'".

Conclusion de la Leçon

Félicitations ! Vous disposez maintenant d'une méthodologie claire pour auditer la pièce maîtresse de votre infrastructure : le routage des appels.

Points clés à retenir :

  • Documenter le routage n'est pas optionnel, c'est le fondement de votre plan de décommissionnement.
  • Pour CUCM/SME, la méthode consiste à extraire le Route Plan Report pour une vue d'ensemble, et l'export de configuration BAT pour une analyse détaillée, en suivant la chaîne logique CSS/Partition -> Route Pattern -> Route List -> Route Group -> Trunk.
  • Pour les SBC AudioCodes, l'export du fichier .ini est la source de vérité. L'analyse se concentre sur les sections [ProxySets] (le qui) et [IP2IPRouting] (le comment), sans oublier les [MessageManipulations] (les exceptions).

Avec ces compétences, vous pouvez désormais construire un document d'audit précis qui cartographie chaque flux d'appel, de son origine à sa destination finale.

Prochaine étape :
Nous avons analysé la configuration de chaque SBC individuellement. Cependant, vous m'avez indiqué que vous utilisiez également l'AudioCodes ARM (Routing Manager) pour une gestion centralisée. Dans la prochaine leçon, nous monterons d'un niveau et apprendrons à documenter les politiques de routage centralisées en exportant et analysant la configuration depuis l'ARM. Cela nous donnera la vue la plus complète sur votre routage PSTN.