Dépannage réseau structuré: de l'identification à la résolution

Bonjour !

Dans la leçon précédente, nous avons vu comment utiliser OVOC pour passer d'une vue d'ensemble de la santé de votre système à l'identification d'un appel problématique spécifique. Vous savez maintenant corréler les alarmes et les indicateurs de performance avec un incident, ce qui est la première étape cruciale du dépannage à grande échelle.

Aujourd'hui, nous allons assembler toutes les pièces du puzzle que nous avons construites au fil de ce cours. Des fondamentaux du SIP à la configuration d'AudioCodes, en passant par l'analyse avec Wireshark et la supervision avec OVOC, tout va converger vers un seul objectif : vous doter d'une méthode de travail infaillible.

L'objectif de cette dernière leçon du module est de vous apprendre à appliquer une méthodologie de dépannage structurée en six étapes claires : Symptôme -> Capture -> Analyse SIP -> Analyse Média -> Correction -> Validation. C'est le plan d'action que vous appliquerez pour chaque incident, vous permettant de résoudre les problèmes de manière efficace, prévisible et professionnelle.

La Méthodologie de Dépannage Structurée

Face à un problème de VoIP, qu'il s'agisse d'un appel qui n'aboutit pas, d'une qualité audio médiocre ou d'un comportement inattendu, la tentation est grande de se jeter sur les configurations. Une approche structurée est cependant beaucoup plus efficace. Elle garantit que vous ne manquez aucune piste et que vous comprenez la cause racine avant d'appliquer une correction.

Voici le processus que nous allons détailler :

1. Symptôme : Comprendre et caractériser le problème.
2. Capture : Rassembler toutes les données nécessaires (logs, traces).
3. Analyse SIP : Suivre la signalisation pour trouver les erreurs de protocole.
4. Analyse Média : Si la signalisation est correcte, inspecter les flux audio (RTP).
5. Correction : Appliquer le correctif approprié sur le SBC.
6. Validation : Vérifier que le problème est résolu et qu'aucun nouvel incident n'a été créé.

---

Étape 1 : Symptôme - Comprendre et Caractériser le Problème

Avant toute action technique, vous devez devenir un détective. La qualité de votre diagnostic dépendra de la précision des informations que vous collecterez à ce stade.

L'objectif est de répondre à des questions précises pour délimiter le périmètre de l'incident.

En résumé, votre checklist pour caractériser le symptôme doit inclure :

• Quoi ? Description précise du problème (ex: "échec de l'appel avec une annonce vocale", "pas de son dans un sens", "voix robotique").
• Qui ? Qui est impacté ? Un seul utilisateur, un groupe d'utilisateurs, tous les utilisateurs d'un site ?
• Quand ? Le problème est-il permanent ou intermittent ? A-t-il commencé à une heure précise ?
• Où ? Le problème concerne-t-il les appels internes, sortants vers un opérateur spécifique, entrants depuis Teams ?
• Exemples concrets : Obtenez toujours des exemples d'appels ayant échoué, avec au minimum :
  • Numéro appelant
  • Numéro appelé
  • Date et heure exacte de l'appel

Comme nous l'avons vu dans la leçon précédente, les tableaux de bord d'OVOC sont parfaits pour quantifier le symptôme à ce stade. Une chute de l'ASR (Answer-Seizure Ratio) sur un IP Group spécifique peut immédiatement confirmer et localiser le problème.

---

Étape 2 : Capture - Rassembler les Données

Une fois le problème bien défini, vous devez le capturer "en flagrant délit". Sans données, vous ne faites que des suppositions. Votre objectif est de reproduire l'incident tout en enregistrant tout ce qui se passe sur le SBC.

Il existe deux sources de données principales et complémentaires :

1. Syslog du SBC : Ce sont les logs internes du SBC. Ils sont essentiels pour comprendre les décisions de routage, les erreurs de traitement interne et obtenir une vue rapide des messages SIP échangés.
2. Capture de paquets (PCAP) : C'est la vérité absolue de ce qui transite sur le réseau. Elle contient l'intégralité des messages SIP et des paquets RTP.

Le guide de dépannage officiel d'AudioCodes explique comment activer ces outils.

En pratique, voici votre plan pour l'étape de capture :

1. Configurez le Syslog : Assurez-vous que votre SBC envoie ses logs à un serveur Syslog avec un Debug Level à 5.
2. Préparez la capture de paquets :
   • Méthode standard : Utilisez un port miroir (SPAN) sur le switch où le SBC est connecté pour copier le trafic vers un PC exécutant Wireshark.
   • Méthode intégrée : Utilisez le Debug Recording (DR) via la CLI du SBC. C'est extrêmement pratique car cela ne nécessite aucune modification physique du câblage. Vous pouvez diriger le flux de capture directement vers votre PC qui exécute Wireshark.
3. Reproduisez l'incident : Demandez à l'utilisateur de passer un nouvel appel test qui reproduit le problème. Notez précisément l'heure, l'appelant et l'appelé.
4. Arrêtez la capture : Une fois l'appel terminé, arrêtez le Syslog et la capture de paquets. Vous avez maintenant toutes les données nécessaires pour l'analyse.

---

Étape 3 : Analyse SIP - La Piste de la Signalisation

La grande majorité des problèmes d'établissement d'appel se trouvent dans la signalisation SIP. Votre première analyse doit donc se concentrer sur les traces SIP.

Wireshark est votre outil principal ici. La vidéo suivante est un excellent tutoriel pratique sur la façon d'analyser un appel SIP dans Wireshark.

Votre workflow d'analyse SIP est le suivant :

1. Ouvrez le PCAP dans Wireshark.
2. Visualisez l'appel : Allez dans Telephony -> VoIP Calls, sélectionnez l'appel que vous avez capturé, et cliquez sur Flow Sequence.
3. Analysez le flux :
   • L' INVITE initial part-il bien du bon équipement et vers la bonne destination ?
   • Le SBC reçoit-il une réponse ? Laquelle ?
   • Recherchez les codes d'erreur (4xx, 5xx, 6xx). Un 404 Not Found indique un problème de routage. Un 401 Unauthorized ou 407 Proxy Authentication Required pointe vers un problème d'authentification. Un 415 Unsupported Media Type indique un problème de négociation de codecs dans le SDP.
4. Examinez les headers clés : Si le flux semble incorrect, plongez dans les messages. Les headers From, To, Contact, Via et P-Asserted-Identity sont-ils conformes à ce que l'équipement de destination attend ?

Le guide AudioCodes (LINK) contient des tableaux de dépannage très utiles (par exemple, la Table 4-11 : "Tel-to-IP Call Setup Advanced Troubleshooting") qui listent les causes possibles pour chaque code d'erreur SIP. Ils sont une excellente ressource pour cette étape.

---

Étape 4 : Analyse Média - La Piste de l'Audio (RTP)

Si l'analyse SIP montre que l'appel s'établit correctement (par exemple, un 200 OK suivi d'un ACK), mais que le symptôme est lié à l'audio (pas de son, son dans un seul sens, mauvaise qualité), alors le problème se situe dans le flux média (RTP).

Votre workflow d'analyse Média :

1. Problèmes de "No Audio" ou "One-Way Audio" :

   • Vérifiez le SDP : Dans l' INVITE et le 200 OK, regardez les lignes c= (connection data) et m= (media description). Les adresses IP et les ports indiqués sont-ils corrects et joignables ? C'est souvent ici que les problèmes de NAT apparaissent.
   • Vérifiez le flux RTP : Appliquez le filtre rtp dans Wireshark. Y a-t-il des paquets RTP qui circulent dans les deux sens, entre les bonnes adresses IP et ports négociés dans le SDP ?

2. Problèmes de mauvaise qualité audio (hachée, robotique, etc.) :

   • Utilisez l'analyseur de flux RTP : Allez dans Telephony -> RTP -> RTP Streams. Cette fenêtre est votre meilleur outil. Elle vous montre tous les flux RTP de la capture.
   • Analysez les statistiques : Sélectionnez un flux et cliquez sur Analyze. Wireshark vous montrera des statistiques vitales :
     • Packet Loss : Le pourcentage de paquets perdus. Tout ce qui est supérieur à 1-2% est audible et problématique.
     • Jitter : La variation du délai de livraison des paquets. Un jitter élevé est une cause fréquente de voix hachée.

La vidéo (LINK) et le guide de dépannage (LINK) expliquent tous deux comment utiliser ces outils et interpréter les résultats.

---

Étape 5 : Correction - Mettre en Œuvre la Solution

L'analyse vous a donné la cause racine. La correction consiste à traduire ce diagnostic en une modification de configuration sur le SBC AudioCodes. C'est ici que toute votre connaissance des modules précédents entre en jeu.

Voici quelques exemples de corrélations Diagnostic -> Correction :

• Diagnostic : L'appel échoue avec 404 Not Found. L'analyse du Syslog montre "No route found".

  • Correction : Vérifiez vos IP-to-IP Routing Rules. La règle est-elle trop spécifique ? Le Source IP Group est-il correct ?

• Diagnostic : L'opérateur rejette l'appel avec 401 Unauthorized.

  • Correction : Allez dans la configuration du Proxy Set de l'opérateur et vérifiez que l'authentification (par IP ou par credentials) est correcte. Si l'enregistrement est requis, vérifiez son statut.

• Diagnostic : L'appel vers Teams échoue car le header Contact n'est pas au bon format FQDN.

  • Correction : Créez une Message Manipulation Rule (MMR) pour réécrire le header Contact et appliquez ce Manipulation Set à l'IP Group ou à la règle de routage concernée.

• Diagnostic : L'analyse RTP montre "One-way audio". L'IP dans le SDP est une adresse privée au lieu de publique.

  • Correction : Allez dans le Media Realm associé à l'interface réseau et configurez correctement l'adresse IP publique dans le champ NAT Address.

---

Étape 6 : Validation - Vérifier la Résolution

Cette dernière étape est souvent négligée mais elle est fondamentale. Ne supposez jamais qu'un problème est résolu sans le prouver.

1. Testez à nouveau : Effectuez un appel de test dans les conditions exactes de l'incident initial.
2. Confirmez la réussite : L'appel doit maintenant aboutir sans erreur et avec une qualité audio correcte.
3. Vérifiez les effets de bord : Assurez-vous que votre correction n'a pas cassé autre chose. Si vous avez modifié une règle de routage pour les appels sortants, faites un test rapide des appels entrants.
4. Surveillez les indicateurs : Retournez sur OVOC. Les KPIs (ASR, Failed Calls) que vous aviez identifiés à l'étape 1 doivent revenir à la normale.

La validation est la preuve finale de votre compétence et de la rigueur de votre travail.

Conclusion

Vous disposez maintenant d'une méthodologie complète et structurée qui vous servira de fil conducteur pour chaque intervention de dépannage. Ce processus en six étapes — Symptôme, Capture, Analyse SIP, Analyse Média, Correction, Validation — transforme une situation potentiellement chaotique en une séquence d'actions logiques et maîtrisées.

Points Clés à Retenir (Méthodologie de Dépannage) :

1. Symptôme : Définissez précisément le problème (Qui, Quoi, Quand, Où) et trouvez un exemple concret.
2. Capture : Enregistrez simultanément les Syslogs du SBC et une capture de paquets (PCAP) complète (SIP+RTP) pendant la reproduction de l'incident.
3. Analyse SIP : Commencez toujours par la signalisation. Utilisez VoIP Calls -> Flow Sequence dans Wireshark pour identifier le point de rupture et le code d'erreur.
4. Analyse Média : Si la signalisation est bonne, analysez le RTP. Vérifiez la négociation SDP et utilisez RTP Streams pour quantifier la perte de paquets et le jitter.
5. Correction : Appliquez la modification de configuration AudioCodes qui cible directement la cause racine identifiée (Routage, MMR, Media Realm, etc.).
6. Validation : Testez, re-testez, et vérifiez que votre correction a résolu le problème sans en créer de nouveaux.

Cette méthodologie est le point culminant de votre formation. En la maîtrisant, vous serez en mesure d'aborder avec confiance les défis les plus complexes, que ce soit pour le dépannage au quotidien ou la mise en œuvre de nouveaux projets. Félicitations d'avoir complété ce parcours intensif