Tester et valider une règle de routage

Bonjour !

Dans la leçon précédente, nous avons configuré une brique essentielle pour la résilience de nos communications : le routage alternatif (Alternative Routing). Nous savons maintenant, en théorie, comment faire basculer un appel vers une destination de secours en cas d'échec sur la route principale.

Introduction

Aujourd'hui, nous allons passer de la théorie à la pratique et aborder une compétence qui est au cœur de votre objectif de maîtrise du troubleshooting. Configurer des règles est une chose, mais comment être absolument certain qu'elles fonctionnent comme prévu ? Comment le prouver ?

L'objectif de cette leçon est de vous apprendre à passer un appel de test et à vérifier les traces pour valider le fonctionnement d'une règle de routage. Nous allons voir comment utiliser les outils intégrés à l'AudioCodes pour générer un appel et comment capturer et analyser les logs SIP pour "voir" le chemin que l'appel emprunte à travers le SBC. Cette compétence est fondamentale pour le dépannage quotidien et la validation de toute configuration de routage.

1. Préparation : Capturer les Traces avec Syslog

Avant même de passer un appel, nous devons nous assurer que nous pouvons "écouter" ce que le SBC a à nous dire. L'outil principal pour cela est le Syslog. Le SBC peut envoyer des messages de log très détaillés, y compris l'intégralité des messages SIP échangés, à un serveur d'écoute. Nous utiliserons le logiciel gratuit AudioCodes Syslog Viewer pour cette tâche.

La première étape consiste donc à configurer le SBC pour qu'il envoie ses logs vers votre ordinateur.

Une fois le SBC configuré, il vous suffit de lancer le Syslog Viewer sur votre PC. Il se mettra automatiquement en écoute et affichera en temps réel les messages provenant du SBC.

2. Action : Lancer un Appel de Test avec le Test Agent

Maintenant que nous sommes prêts à capturer les traces, nous avons besoin de générer du trafic pour tester nos règles. Il n'est pas toujours pratique d'avoir deux téléphones SIP à portée de main. Heureusement, le SBC dispose d'un outil intégré pour simuler un appel : le Test Agent.

Cet outil vous permet de "fabriquer" un appel en définissant l'appelant, l'appelé et le groupe d'IP source, ce qui vous donne un contrôle total pour cibler et valider une règle de routage spécifique.

Pour créer un appel de test, voici les étapes :

1. Allez dans Troubleshooting > Troubleshooting > Test Call > Test Call Rules.
2. Cliquez sur New pour créer une nouvelle règle de test.
3. Configurez les paramètres clés :
   • Test Name : Donnez un nom descriptif (ex: Test_Route_Vers_ITSP).
   • Caller Party Number : Le numéro de l'appelant que vous simulez (ex: +33123456789). Le SBC l'utilisera pour sa décision de routage.
   • Destination Number : Le numéro que vous appelez (ex: 0611223344). C'est ce qui sera utilisé pour matcher le Destination Phone Prefix dans votre table de routage.
   • Source IP Group : C'est un paramètre essentiel. Sélectionnez l'IP Group qui doit être considéré comme la source de l'appel (ex: IG_Teams, IG_PBX). Cela permet de simuler un appel arrivant d'un trunk spécifique.
4. Une fois la règle créée, sélectionnez-la et dans le menu Action, choisissez Dial.

L'appel est maintenant lancé ! Vous devriez voir une avalanche de messages apparaître dans votre fenêtre Syslog Viewer.

3. Vérification : Analyser les Traces

C'est ici que votre travail de détective commence. Le flux de logs peut paraître intimidant, mais AudioCodes fournit des outils puissants pour y voir clair.

A. Isoler l'appel avec le SID

La première chose à savoir est que chaque session d'appel sur le SBC est identifiée par un identifiant unique, le Session ID (SID). C'est la clé pour filtrer le bruit et se concentrer uniquement sur votre appel de test.

Dans le Syslog Viewer, chaque ligne de log relative à un appel contient cet identifiant. Par exemple : [SID=2ed1c8:96:5].

B. Visualiser le flux avec le SIP Flow Diagram

Plutôt que de lire des centaines de lignes de texte, le plus simple est de visualiser l'appel. Le Syslog Viewer peut générer un diagramme de séquence (ou "échelle") de l'appel.

1. Dans le Syslog Viewer, cliquez sur l'icône SIP Flow Diagram.
2. Une nouvelle fenêtre s'ouvre. Sur la gauche, vous verrez la liste de toutes les sessions SIP capturées. Trouvez votre appel de test en vous basant sur les numéros From et To que vous avez configurés.
3. Sélectionnez votre appel. Le diagramme de flux apparaît au centre.

Ce diagramme vous permet de valider d'un coup d'œil :

• Les acteurs de l'appel (l'IP du SBC et l'IP de la destination).
• La séquence des messages (établissement, réponse, libération).
• Le code de réponse final (ex: 200 OK pour un succès, 404 Not Found pour un échec).

Si l'adresse IP de destination dans le diagramme correspond à celle que vous aviez configurée dans le Proxy Set de votre règle de routage, vous avez validé votre règle !

C. Confirmer avec les Logs Détaillés

Pour une analyse plus profonde et une confirmation absolue, vous pouvez inspecter les messages de log du SBC qui décrivent ses décisions de routage.

En cliquant sur un message dans le SIP Flow Diagram, le Syslog Viewer vous positionne automatiquement sur la ligne correspondante dans la fenêtre de log principale. Recherchez les lignes suivantes, qui apparaissent juste après la réception de l'INVITE initial :

• Classification Succeeded - Source IP Group #[ID] ([Nom de l'IP Group]): Cette ligne confirme quel IP Group a été identifié comme source de l'appel.
• Routing: Rule #[Index], Name=[Nom de la règle], Matched: C'est la preuve irréfutable ! Cette ligne vous dit exactement quelle règle de votre table de routage a été utilisée.
• ---- Outgoing SIP Message to [Adresse_IP:Port] from SIPInterface #[ID] ... ----: Cette ligne confirme vers quelle adresse IP le SBC envoie l'appel. Vous pouvez vérifier que cette IP est bien celle du Proxy Set de destination de votre règle.

Pour faciliter cette analyse, vous pouvez filtrer les logs pour n'afficher que ceux de votre appel.

4. Scénario de Validation Complet

Reprenons le cas de la leçon précédente : le basculement d'un appel de Teams vers un CUCM sur une erreur 404 Not Found.

Votre plan de test :

1. Configurez et lancez le Syslog Viewer.
2. Dans le Test Agent, configurez un appel :
   • Source IP Group: Celui qui représente l'arrivée de l'appel (ex: IG_ITSP).
   • Destination Number: Un numéro qui n'existe pas sur Teams mais existe sur le CUCM.
3. Lancez l'appel avec Dial.
4. Ouvrez le SIP Flow Diagram.

Résultat attendu :
Le diagramme d'échelle montrera exactement la séquence que nous attendons :

1. Un INVITE du SBC vers l'adresse IP de Microsoft Teams.
2. Une réponse 404 Not Found de Teams vers le SBC.
3. Un ACK du SBC vers Teams pour clore ce dialogue.
4. Un nouvel INVITE (avec le même Call-ID) du SBC vers l'adresse IP du CUCM.
5. Une réponse 180 Ringing puis 200 OK du CUCM.
6. L'appel est établi, puis libéré avec BYE/OK.

Si vous voyez cette séquence, vous avez la preuve formelle que votre règle principale a été tentée, que le déclencheur de basculement (404) a fonctionné, et que la règle alternative a été correctement exécutée.

Conclusion

La validation par les traces n'est pas une option, c'est une partie intégrante du travail de configuration et de dépannage. En maîtrisant les outils présentés aujourd'hui, vous gagnez en autonomie et en précision pour diagnostiquer n'importe quel problème de routage.

Points Clés à Retenir

• Le Processus de Validation : Il se déroule en trois temps : 1. Configurer la capture (Syslog), 2. Lancer le test (Test Agent), 3. Analyser les résultats (SIP Flow Diagram et logs).
• Le Test Agent est votre allié : Il permet de simuler des appels de manière contrôlée pour tester des scénarios de routage spécifiques sans dépendre d'équipements externes.
• Le SIP Flow Diagram est votre meilleur ami : Il offre une vue d'ensemble claire et immédiate du chemin de l'appel et du résultat final. C'est votre premier outil d'analyse.
• Les logs du SBC ne mentent pas : Pour une preuve définitive, les messages Classification Succeeded et Routing: Rule #... Matched vous disent exactement ce que le SBC a décidé de faire.
• Le SID est la clé : Utilisez le Session ID pour isoler et suivre un appel spécifique dans la masse de logs.

Prochaine Étape

Nous avons maintenant une connaissance solide de la logique de routage et de sa validation. Dans le prochain module, nous allons mettre tout cela en pratique dans un des scénarios les plus courants : la Configuration d'un SIP Trunk Opérateur (ITSP). Nous appliquerons les concepts d'IP Group, de Proxy Set et de règles de routage pour connecter le SBC au monde extérieur, et vous utiliserez les compétences de validation d'aujourd'hui pour confirmer que la connexion est opérationnelle.