Test de Connectivité SIP : Réaliser des Appels.

Bonjour,

Au cours des leçons précédentes, nous avons méticuleusement assemblé les briques de configuration pour divers scénarios de trunks SIP : un opérateur ITSP, Microsoft Teams et un PBX interne de type Oracle. Chaque configuration, bien que suivant une méthodologie constante, a présenté ses propres particularités. Il est maintenant temps de passer de la construction à la validation. Comment savoir si ces trunks sont réellement opérationnels ?

Cette leçon répond à cette question en vous présentant un outil essentiel de l'arsenal AudioCodes : la fonctionnalité d'appels de test (Test Call). Nous allons apprendre à utiliser le SBC lui-même comme un téléphone SIP simulé pour initier et recevoir des appels, vous permettant ainsi de valider la connectivité de la signalisation et du média sans dépendre d'équipements externes. C'est une étape fondamentale avant toute mise en production, et une compétence de base pour le diagnostic.

Nous verrons comment configurer une règle d'appel de test sortant pour valider un trunk, puis comment analyser les résultats, d'abord via les journaux système (Syslog) du SBC, puis en ayant un premier aperçu de l'analyse de paquets avec Wireshark.

1. La Fonctionnalité "Test Call Rules" : Votre Téléphone SIP Intégré

Plutôt que de devoir systématiquement brancher un téléphone physique ou lancer un softphone pour tester une configuration, le SBC AudioCodes intègre une fonctionnalité puissante qui lui permet de simuler un ou plusieurs terminaux SIP. Cette simulation est gérée par les Test Call Rules.

Chaque règle que vous créez agit comme un "mini-script" d'appel : elle définit un point de terminaison SIP (une URI, comme testeur_01@sbc.local), spécifie s'il doit être l'appelant ou l'appelé, et détermine comment l'appel doit être routé.

L'interface de configuration 'Test Call Rules' du SBC AudioCodes. C'est ici que nous allons définir nos scénarios de test, en spécifiant les URI de l'appelant et de l'appelé, ainsi que la méthode de routage.

Pour bien saisir l'étendue de cette fonctionnalité, je vous invite à lire l'introduction de la documentation officielle.

Configuring Test Call Endpoints - AudioCodes

Ce document est le guide de référence pour la configuration des appels de test. L'introduction résume parfaitement le concept.

Lisez la section d'introduction, depuis le début jusqu'à la fin du troisième paragraphe. Notez bien que l'outil permet de tester non seulement la signalisation SIP (établissement de l'appel) mais aussi le média (par exemple, les tonalités DTMF).

2. Initier un Appel de Test Sortant

Le cas d'usage le plus courant est de valider un trunk que vous venez de configurer. Par exemple, après avoir créé l'IP Group IG_ITSP_Trunk pour votre opérateur, vous voulez vous assurer qu'un appel peut bien être envoyé vers cet opérateur.

Pour ce faire, nous allons configurer une règle où le SBC agit en tant qu'appelant (Caller).

La configuration se fait dans le menu Troubleshoot > Troubleshoot > Test Call > Test Call Rules. Voici les paramètres essentiels à configurer pour un appel sortant :

Endpoint URI : L'identifiant de votre téléphone simulé. C'est ce qui apparaîtra dans le header From du message INVITE. Par exemple : testeurSBC.
Called URI : Le numéro ou l'URI que vous souhaitez appeler. Par exemple, un numéro de mobile +33612345678.
Call Party : Défini sur Caller.
Route By : Défini sur IP Group. C'est la méthode la plus flexible, car elle s'appuie sur toute la logique de configuration que nous avons déjà mise en place.
IP Group : C'est ici que vous sélectionnez le trunk de destination à tester, par exemple IG_ITSP_Trunk. Le SBC utilisera alors les Proxy Sets et IP Profiles associés à cet IP Group pour router l'appel.

Le document ci-dessous vous guidera à travers la liste complète des paramètres et vous donnera un exemple concret.

Configuring Test Call Endpoints - AudioCodes

Cette lecture vous détaillera les paramètres clés pour la création d'une règle d'appel.

D'abord, familiarisez-vous avec la procédure de création en lisant le paragraphe numéroté de la section "Configuring Test Call". Ensuite, dans le tableau "Test Call Rules Table Parameter Descriptions", concentrez-vous sur les paramètres suivants : Dans la section "Common", lisez les descriptions de Endpoint URI et Called URI, puis de Route By et IP Group. Dans la section "Test Setting", lisez la description de Call Party. Enfin, pour voir un exemple concret, consultez le document suivant.

Test Call Rules Configuration Examples - AudioCodes

Cet extrait de la documentation fournit un exemple simple et direct pour un appel sortant.

Lisez le premier exemple, "Outgoing Test Call". Il résume parfaitement la configuration que nous venons de décrire, en utilisant un IP Group nommé MyTest comme destination.

Une fois la règle configurée et enregistrée, une nouvelle option "Dial" apparaît à côté de votre règle dans la table. En cliquant sur "Dial", le SBC initie immédiatement l'appel SIP. Mais comment savoir ce qu'il se passe ?

3. Valider le Succès de l'Appel

Lancer l'appel n'est que la première étape. La validation consiste à observer les messages de signalisation pour confirmer que l'appel a été correctement établi.

3.1. Le Syslog : Votre Vue en Temps Réel

L'outil de premier niveau pour le diagnostic sur un SBC AudioCodes est le Syslog Viewer. Il affiche en temps réel les journaux de l'équipement, y compris une trace détaillée des messages SIP entrants et sortants.

Pour y accéder, naviguez vers Troubleshoot > Troubleshoot > Syslog.

Exemple de sortie du Syslog Viewer. On peut y voir clairement les messages SIP échangés, tels qu'un INVITE, un 200 OK et un ACK, avec leurs en-têtes détaillés. C'est l'endroit idéal pour une vérification rapide.

Après avoir lancé votre appel de test, vous devriez observer dans le Syslog une séquence qui vous est familière depuis le premier module de ce cours :

Un message INVITE sortant, envoyé par le SBC vers la destination (votre opérateur).
Une ou plusieurs réponses provisoires (par ex., 100 Trying, 180 Ringing).
Une réponse finale de succès, 200 OK, venant de l'opérateur.
Un message ACK envoyé par le SBC pour confirmer la réception du 200 OK.

Si vous voyez cette séquence, la connectivité de la signalisation est validée ! Si l'appel échoue (par exemple, vous recevez une réponse 404 Not Found ou 503 Service Unavailable), le Syslog vous donnera le premier indice sur la cause de l'échec.

3.2. Wireshark : Pour une Analyse Approfondie

Le Syslog est excellent pour la signalisation, mais il ne montre pas le trafic média (RTP). Si vous rencontrez des problèmes de type "pas de son" ou "son dans un seul sens", ou si vous avez besoin d'une vue plus graphique des échanges, un analyseur de protocole comme Wireshark devient indispensable.

Le dépannage avancé avec Wireshark fait l'objet d'un module ultérieur, mais il est utile d'avoir dès maintenant un aperçu de sa puissance. La vidéo suivante est une excellente introduction à l'analyse d'appels SIP dans Wireshark.

Lecture - 8 | How to Analyze SIP calls in Wireshark | SIP Calls troubleshooting | Analyze RTP Stream

Cette vidéo, bien que très complète, contient des sections clés qui vous montreront comment visualiser rapidement et efficacement un flux d'appel.

Concentrez-vous sur les passages suivants pour comprendre les bases de l'analyse : Filtrer le trafic : Regardez comment appliquer des filtres pour n'afficher que les paquets SIP et RTP pertinents. C'est la première étape de toute analyse. Visionnez de cette section. Visualiser le flux d'appel : Wireshark peut générer un diagramme de séquence de votre appel. C'est un outil visuel extrêmement puissant pour comprendre les interactions. Regardez d'abord l'explication théorique, puis la démonstration pratique. Vous y reconnaîtrez immédiatement le flux INVITE / 180 Ringing / 200 OK / ACK.

Cette compétence de corréler une action de configuration (créer un trunk) à sa validation (via un appel de test) et à son observation (via Syslog/Wireshark) est au cœur du métier d'expert en communications unifiées.

Conclusion

Aujourd'hui, nous avons franchi une étape cruciale en passant de la configuration à la validation active. Vous savez désormais comment utiliser l'outil Test Call Rules pour simuler des appels et vérifier la connectivité de vos trunks SIP.

Les points clés à retenir sont :

La fonction "Test Call Rules" permet au SBC de se comporter comme un point de terminaison SIP, capable d'émettre (Caller) et de recevoir (Called) des appels.
Pour tester un trunk sortant, on crée une règle Caller et on la route vers l'IP Group correspondant à ce trunk.
La validation initiale se fait via le Syslog Viewer, en recherchant la séquence de messages SIP (INVITE, 200 OK, ACK) qui confirme l'établissement de l'appel.
Pour une analyse plus poussée, notamment sur le média (RTP) ou pour obtenir une vue graphique, des outils comme Wireshark et sa fonction de diagramme de flux sont indispensables.

Maintenant que nous avons validé la connectivité de base de nos trunks, nous pouvons commencer à construire une logique de routage plus intelligente. La prochaine leçon inaugurera notre quatrième module et portera sur la configuration des règles de classification, une technique qui permet au SBC d'identifier la source d'un appel entrant pour appliquer des politiques de routage ou de sécurité spécifiques.