Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les méthodes de dépannage et d'isolation des problèmes de qualité vocale dans un environnement Cisco Unified Communications Manager (CUCM).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document ne sont pas basées sur des versions logicielles ou matérielles spécifiques :
Une des étapes les plus importantes du dépannage des problèmes de qualité vocale est de les isoler, soit sur un téléphone, un ensemble de téléphones, un commutateur, une passerelle, etc. Cela permet un dépannage ciblé et une résolution plus rapide du problème. Une analogie qui illustre l'importance de l'isolement de la question est une voiture perdue dans un parking d'aéroport. Trouver une voiture perdue dans un parking d'aéroport est une tâche difficile, lorsque vous savez que la voiture se trouve dans une section spécifique du parking (section 1 par exemple), rend la tâche moins intimidante, mais lorsque vous avez aussi la section et la rangée (section 5, ligne D), cela réduit considérablement le temps nécessaire pour trouver la voiture.
Une fois le problème identifié par des utilisateurs qui signalent des problèmes, des enregistrements détaillés des appels (CDR) ou d'autres moyens, il est important de collecter des données pour l'isoler. Les problèmes de qualité vocale se classent généralement dans l'une des trois catégories suivantes : réseau (inclut les problèmes de passerelle (GW) et RTPC), de modèle téléphonique/micrologiciel ou d'équipement (par exemple, casque). Il est important de recueillir des données pour déterminer de quelles catégories découlent les problèmes de qualité vocale. Ces données permettent de comparer les téléphones sans problèmes de qualité vocale et les téléphones avec des problèmes de qualité vocale pour trouver les différences entre eux, ce qui est une étape cruciale pour résoudre de nombreux problèmes de qualité vocale.
Étape 1. La première étape pour isoler le problème de qualité de la voix consiste à savoir exactement quels utilisateurs l'utilisent et à leur parler, en personne ou par téléphone, pour obtenir une description exacte de ce problème. S'il y a un grand nombre d'utilisateurs qui signalent le problème, parlez à un échantillon (peut-être 5-10) d'entre eux pour obtenir une description exacte des symptômes. Si seulement quelques utilisateurs signalent le problème, parlez-en aux personnes qui les entourent pour voir s'ils rencontrent également un problème, car le problème peut être plus répandu qu'il ne le semble, car de nombreux utilisateurs ne le signaleront pas.
Étape 2. Prenez note de l'emplacement physique (ex. Site A, Étage 2), nom d'utilisateur (du téléphone de l'utilisateur), numéros de répertoire (DN), modèle de téléphone (ex 8865), micrologiciel du téléphone (ex. 11.5.1) et les adresses IP des téléphones qui rencontrent des problèmes de qualité vocale. Créez une feuille de calcul avec ces informations triées par emplacement physique. Les 30 minutes (ou moins) nécessaires à la création de cette feuille de calcul lorsque vous commencez à dépanner, peuvent vous faire économiser des heures, voire des jours de temps de dépannage.
Étape 3. Une fois la feuille de calcul créée, jetez un coup d'oeil à la liste des téléphones et voyez ce qu'ils ont en commun et ce qui est différent d'eux et d'autres téléphones qui n'ont pas de problèmes de qualité vocale. Après cela, vous pouvez vous rendre compte que tous les téléphones ayant le problème se trouvent dans le même bâtiment et au même étage, vous pouvez réaliser que les téléphones qui ont des problèmes sont connectés aux commutateurs qui ont été récemment mis à niveau ou vous pouvez voir que tous les téléphones qui ont le problème se trouvent sur un microprogramme particulier.
Ces questions permettent de restreindre le chemin vocal des appels affectés.
1. Le problème se produit-il uniquement sur les appels externes, uniquement les appels internes ou les deux ?
Le son des appels externes et internes emprunte généralement différents chemins. Un appel externe quitte généralement le réseau vocal Cisco via un (GW) ou un CUBE connecté au RTPC ou à un fournisseur SIP. Si le problème concerne les appels internes, vous pouvez exclure le GW dans la plupart des cas, car le GW n'est pas impliqué dans l'appel. L'exception à cette règle serait si les ressources multimédias (Media Termination Point (MTP) ou Transcoder (Xcoder) qui résident sur le GW sont appelées.
2. Le problème n'a-t-il qu'un effet sur les données audio sortantes qui quittent le téléphone (de l'utilisateur à la personne à laquelle il parle), les données audio entrantes au téléphone (de la personne à laquelle il parle, de l'utilisateur) ou les deux ?
3. L'appel est-il un appel téléphonique IP de base vers IP (Utilisateur A —> Commutateur —> Utilisateur B) ou un appel IP vers RTPC (Utilisateur —> Commutateur —> GW —> RTPC) ou l'appel est-il plus complexe ?
Par exemple, le cluster EMCC (Extension Mobility Cross Cluster) est-il utilisé ? s'agit-il d'un environnement de centre d'appels avec Unified Contact Center (UCC) ou Unified Contact Center Express (UCCX) ? etc. Si vous supprimez la complexité de l'appel lorsque vous placez un téléphone IP de base sur un téléphone IP ou un téléphone IP sur un appel RTPC, le problème persiste-t-il ?
4. Si le flux d'appels avec le problème de qualité vocale signalé est complexe, un appel UCCX par exemple, l'utilisateur/le téléphone rencontre-t-il le problème de qualité vocale s'ils passent/reçoivent un appel de base (interne et externe) ?
Si le problème concerne un utilisateur, collaborez avec lui pour déterminer les points suivants :
Étape 1. Vérifiez que le téléphone avec le problème exécute le même micrologiciel que les autres téléphones connus qui fonctionnent correctement, si le micrologiciel est différent, une mise à niveau du micrologiciel peut résoudre le problème.
Étape 2. L'utilisateur rencontre-t-il le problème lorsqu'il utilise son combiné, son haut-parleur, son casque, les trois ?
a. Si le problème concerne uniquement le combiné, vérifiez les connexions du combiné, s'il y a toujours un problème, remplacez le combiné par un autre téléphone qui n'a pas signalé de problème, si le problème persiste, il peut y avoir un problème avec le micrologiciel du téléphone/téléphone.
b. Si le problème concerne le haut-parleur, essayez d'ajuster le volume, si le problème persiste, remplacez le téléphone par un téléphone de travail connu, si le problème persiste, il peut y avoir un problème avec le micrologiciel du téléphone/téléphone.
c. En cas de problème avec le casque, vérifiez que toutes les connexions entre le téléphone et le casque (base du casque) sont correctes, les autres utilisateurs ayant la même marque/modèle du casque sont-ils libres de tout problème ? S'ils testent un casque connu qui fonctionne correctement avec le téléphone avec le problème signalé, s'il n'y a pas de problème audio lorsque vous utilisez le casque connu qui fonctionne correctement, le problème est probable avec le casque et vous pouvez avoir besoin de contacter le fabricant du casque, s'il y a un problème avec le casque connu qui fonctionne correctement, il peut y avoir un problème avec le micrologiciel du téléphone/téléphone.
Étape 3. Si le téléphone se trouve sur le même micrologiciel que les autres téléphones sans problème et que l'utilisateur rencontre des problèmes avec le casque, le haut-parleur et le casque, le problème est probablement lié au téléphone physique lui-même ou au câblage réseau du téléphone au commutateur. Pour le tester, vous pouvez débrancher le câble de raccordement à l'arrière du téléphone (afin de ne pas raccorder un câble de raccordement potentiellement défectueux de l'emplacement de l'utilisateur à un emplacement de test), trouver un téléphone de travail connu et brancher le câble de raccordement du téléphone de travail sur le téléphone de travail et effectuer un test. Si les problèmes audio sont toujours présents, il y a probablement un problème avec le téléphone physique. S'il n'y a pas de problème audio, essayez de remplacer le câble de raccordement (par un câble de raccordement fonctionnel connu) qui a été branché sur le téléphone qui rencontre des problèmes, s'il persiste, vérifiez le câblage réseau et toutes les connexions/connexions entre la prise Ethernet de l'utilisateur et le commutateur.
Si les étapes précédentes n’ont pas isolé la source de la mauvaise qualité vocale, l’étape suivante consiste à capturer les paquets le long du chemin réseau suivi par les paquets RTP. Les captures de paquets Wireshark (ou un autre outil capable de décoder les flux RTP) peuvent nous aider à affiner la source du problème avec ces étapes.
Étape 1. Créez une topologie simple qui affiche le chemin emprunté par les paquets RTP. Cet exemple utilise cette topologie, le problème est que le client côté RTPC a des problèmes de qualité audio quand il écoute l'utilisateur, l'utilisateur peut entendre le client sans problème. Avec ces informations, vous savez vous concentrer uniquement sur les paquets RTP qui circulent du côté utilisateur au côté client.
Étape 2. Une fois la topologie écrite, la première étape consiste à capturer des paquets d’un côté de la topologie et à vous diriger vers l’autre extrémité de la topologie.
a. Prenez la première capture avec une plage de ports du port de commutateur auquel le téléphone IP est connecté. Utilisez Wireshark pour décoder le flux RTP et lire le son. En cas de problème avec le son (la voix de l'utilisateur n'est pas claire), vous pouvez mettre l'accent sur le câblage du téléphone au commutateur, sur l'équipement téléphonique (combiné, casque, haut-parleur) et sur le téléphone lui-même. En l'absence de problème avec le son (la voix de l'utilisateur est claire), vous pouvez éliminer le téléphone, le câblage du téléphone au commutateur et l'équipement téléphonique (combiné, casque, haut-parleur) comme source de la mauvaise qualité. À ce stade, passez à l'étape b) s'il n'y a aucun problème avec le son.
b. Prenez une capture de paquets au niveau du routeur A (entrée et sortie), puis décodez et lisez les flux audio. En cas de problème avec l'audio en entrée, vous avez isolé le problème, car vous savez que l'audio a entré switch_A sans problème mais a entré router_A avec un problème. S'il n'y a aucun problème avec l'audio en entrée et que la qualité audio est médiocre en sortie, vous avez isolé le problème au routeur A. Si aucun problème n'est survenu lors du transfert audio vers l'étape (c), continuez à collecter des captures de paquets le long du chemin RTP.
c. Prenez une capture de paquets au niveau du routeur B (entrée et sortie), puis décodez et lisez les flux audio. Si un problème audio se produit à l'entrée du routeur B et que vous savez qu'il n'y a pas eu de problème audio à la sortie du routeur A à partir des captures de paquets précédentes, vous avez isolé le problème et savez que le problème se situe entre le routeur A et le routeur B (le WAN dans cet exemple). S'il n'y a aucun problème avec l'audio en entrée et que la qualité audio est médiocre en sortie, vous avez isolé le problème au routeur B. S'il n'y a aucun problème avec le transfert audio à l'étape (d) pour collecter plus de captures de paquets.
d. À ce stade du processus de dépannage, vous avez déterminé que la qualité audio est bonne à partir du téléphone IP, du commutateur A, du routeur A, du WAN et de la sortie du routeur B. La capture de paquet suivante doit être prise à partir de la GW. En cas de problème avec l'audio à l'entrée de la GW, le problème a été isolé sur switch_B. S'il y a un problème audio avec la qualité audio en sortie, vous avez isolé le problème au GW. S'il n'y a aucun problème de qualité audio en sortie, le problème est probablement du côté RTPC/Fournisseur, contactez votre Fournisseur, fournissez-lui une capture de paquets avec l'audio qui laisse la GW sans problème serait l'étape suivante du processus de dépannage.
1. Collecte d'une capture de paquets à partir d'un téléphone IP Cisco
2. Dépannage UC avec Wireshark (méthode de lecture audio RTP)
4. Identification et classement par catégorie des symptômes des problèmes de qualité vocale