Table des matières
- Comment résoudre les problèmes de voix unidirectionnels / sans audio
- Qu'est-ce que c'est?
- Comment le réparer?
- Comment vérifier très rapidement si les téléphones envoient / reçoivent le RTP (audio)
- Comment identifier les problèmes les plus courants
- Problèmes aléatoires
- Que faire si c’est aléatoire et qu'aucune capture d’écran n'a pas été prise pour les téléphones présentant ce problème?
- Que se passe-t-il si un téléphone ne transmet pas?
Comment résoudre les problèmes de voix unidirectionnels / sans audio
Si vous rencontrez des problèmes de voix unidirectionnels / sans audio, voici ce que vous devez faire pour réparer cela facilement.
Vérifiez également et repérez la page principale de ces séries "Comment procéder" qui est mise à jour de manière régulière, avec les ressources de collaboration unifiée (Unified Collaboration Resources).
cf. One Stop, Unified Collaboration Tech Resources - Publié et constamment mis à jour par cnuche.
Maintenant, revenons aux problèmes d'audio.
Qu'est-ce que c'est?
Un appel de voix unidirectionnel (one-way) se produit lorsque vous avez un appel entre 2 téléphones (interne-interne ou interne-externe) et que l'un d'entre eux ne peut pas entendre l'autre bout.
Un appel sans audio (no-way) se produit lorsque vous avez un appel entre 2 téléphones (interne-interne ou interne-externe) et aucun d'entre eux ne peut s'entendre.
Comment le réparer?
Avant de commencer à penser comment résoudre ce problème, vous devez comprendre ce qui se passe, comment cela fonctionne et quelles sont les causes du problème.
Tout d’abord, vous pouvez obtenir les rapports des utilisateurs finaux sur l’audio one-way ou no-way, ou peut-être des « appels fantômes » (ghost calls).
Parfois, les utilisateurs nomment ces appels des « appels abandonnés » (dropped calls), car ils reçoivent un appel qui n'a pas de son et après quelques secondes, ils entendent une tonalité de renumérotation (vite occupé). Cela se produit parce que l'appelant n'entend pas le téléphone appelé et il reçoit l'air mort et raccroche, ou peut-être il peut entendre l'autre bout, mais il se rend compte que le téléphone appelé ne peut pas l'entendre et il raccroche.
OK, voici une description détaillée de la façon dont cela fonctionne:
- Le téléphone A appelle le téléphone B.
- L'agent d'appel (CUCM, VCS, CME ou un autre PBX) reçoit une demande du téléphone A, indiquant qu'il souhaite appeler le téléphone B.
- L'agent d'appel indique au téléphone B qu'un appel est reçu du téléphone A.
- Si le téléphone B décroche l’auriculaire ou s’il appuie sur le bouton du haut-parleur, l'agent d'appel demandera aux deux téléphones le port qu'ils souhaitent utiliser pour recevoir l’audio et enverra ces informations à l'autre bout.
- À ce stade, vous constaterez que l'appel est 'connecté' (et que le niveau de signalisation est correct). Veuillez noter qu'il ne s'agit que de téléphones qui communiquent avec le CUCM ou le PBX.
- Ensuite, les deux téléphones ouvrent le canal d'audio et commencent à émettre et à recevoir des paquets RTP. Veuillez noter que ce Tx et ce Rx des paquets d'audio (paquets RTP) est une transmission point à point entre les téléphones, l’audio ne passe pas par CUCM, (sauf s’il y a un MTP ou un CFB du serveur lui-même impliqué), s’il s’agit d’un appel externe, l’audio passe directement du téléphone au GW d’entrée / sortie.
Les causes possibles de ces problèmes sont les suivantes:
- Le trafic RTP est bloqué ou consommé par un pare-feu (FireWall ou FW), ou un autre périphérique de sécurité.
- Le trafic RTP est mal acheminé (par une route récemment ajoutée / apprise, ou par un VRF ou un WAN).
- Problèmes de signalisation (l'agent d'appel ne transmet pas les ports ou le codec appropriés, ou la transmission est étiquetée en tant que « envoi seulement » ou « uniquement récepteur »).
- Le trafic RTP est corrompu.
- Un côté ne transmet pas.
Comment vérifier très rapidement si les téléphones envoient / reçoivent le RTP (audio)
Ouvrez la page Web pour 2 téléphones test, puis cliquez sur le lien "flux 1" situé sur le côté gauche de la page et vérifiez si l'adresse IP et le port correspondent aux informations des deux côtés. Continuez à appuyer le lien du "flux 1" et vous remarquerez que les statistiques Tx et Rx ne cessent d'augmenter.
- Ici, vous pouvez vérifier les adresses IP locale et à distance (remote), puis vous verez le port, si l’information est la même de l'autre côté, (l'IP locale doit correspondre à l'IP à distance de l'autre côté), alors la signalisation est bonne.
- Vous pouvez également vérifier que le codec est effectivement le codec attendu. Sinon, modifiez la liste des préférences du codec ou le BW disponible dans la région.
De l'autre côté, vous devriez voir la même information inversée:
Comment identifier les problèmes les plus courants
- Si vous constatez que les statistiques Tx augmentent, les téléphones sont en train de transmettre, par contre, si vous ne pouvez pas voir que les statistiques Rx augmentent ou qu’elles sont même à zéro, cela veut dire que l'une des extrémités n'entend rien.
- Cela signifie que le téléphone est en train de transmettre, mais que l'autre extrémité ne reçoit pas ces paquets. À ce stade, vous pouvez arrêter de chercher un problème de système téléphonique, car il s’agit d'un problème de réseau.
- Si cela se produit avec des appels externes, effectuez une capture de paquet ou une capture PCM auprès du GW pour voir si vous recevez l’audio de l'extrémité à distance.
Le problème le plus courant est le trafic bloqué ou consommé par un FW. Si le FW utilise l'inspection SIP ou l'inspection SCCP, cela peut entraîner ce problème, ainsi que d'autres. Afin de prouver ou de rejeter ceci, désactivez SIP ou le SCCP et examinez en fonction de ce que vous utilisez, voir ci-dessous:
Désactivation de l'inspection SIP / SCCP sur Cisco ASA
- Vérifiez d'abord quelle est la policy-map: Affichez et exécutez la policy-map
- Là vous devriez voir quelque chose comme: policy-map global_policy class inspection_default inspect sip
- Une fois que vous savez quelle est la policy-map, entrez ensuite la configuration du policy-map: policy-map global_policy class inspection_default
- Et enfin, désactivez l’inspection: no inspect SIP
Si cela résout le problème, vous devrez peut-être ajuster l'inspection SIP (ouvrir un cas TAC avec l'équipe de sécurité ASA) ou le laisser désactivé.
Un autre problème courant est que les ports RTP ne sont pas ouverts ou ils sont explicitement bloqués. Pour cela vérifiez les éléments suivants:
Ports RTP:
16384 - 32767 / UDP
Protocole en temps réel (RTP), protocole en temps réel sécurisé (SRTP)
Remarque: Cisco Unified Communications Manager utilise uniquement 24576-32767 bien que les autres périphériques utilisent la gamme complète.
Cisco Unified Communications Manager TCP and UDP Port Usage
S'il n'y a pas de périphériques de sécurité et que le trafic RTP frappe un routeur mais ne se dirige pas de l'autre côté, le trafic pourrait être mal acheminé. Si un VRF est impliqué, vous pouvez essayer de le désactiver ou d'obtenir des captures de paquets de l'interface sortante pour vérifier si le trafic quitte le routeur sur l'interface attendue.
Si vous ne savez pas comment obtenir les captures du routeur, consultez la documentation suivante:
Le TAC m'a demandé des captures, maintenant
Si cela traverse un réseau WAN, assurez-vous d’obtenir une capture de paquet à partir des interfaces entrante et sortante du routeur et assurez-vous aussi que la taille du paquet entrant est inférieure à la taille spécifiée pour la liaison WAN, (cela peut poser problème si est une réinvite à mi appel avec un grand SDP, ce qui pourrait entraîner des problèmes de renégociation d’audio).
Enfin, si vous voyez que le téléphone reçoit des paquets mais que vous ne pouvez rien entendre sur le téléphone, vous devrez obtenir une capture de paquet à partir du téléphone pour analyser davantage le flux RTP. Si les paquets ont la mauvaise séquence, le téléphone ne les lira pas ; ou si le Wireshark indique que les paquets sont corrompus ou mal formés, le téléphone risque de ne pas les lire. Si les paquets RTP sont présents et que vous pouvez les exécuter avec le Wireshark (G.711 non crypté), vous ne pouvez rien entendre, les paquets peuvent être en blancs ou vides. Cela peut être occasionné par un FW consommant les paquets, ou le MTP / Xcoder d'un périphérique.
Voici un document indiquant comment enregistrer la capture d’écran d’un paquet, à partir d’un téléphone:
Collecting a packet capture from a Cisco IP Phone
Problèmes aléatoires
- Si c'est un problème aléatoire, vous devez configurer une capture SPAN sur le commutateur et laisser un PC avec la capture Wireshark jusqu'à ce que cela puisse être reproduit. Idéalement, vous devez configurer la capture Wireshark sans filtres (il existe des filtres par défaut, ne les utilisez pas), et assurez-vous de définir la capture pour créer un nouveau fichier tous les 50 ou 100 Mo, et obtenir les adresses IP, MAC, date et heure du test, ainsi que le fuseau horaire du périphérique, L'heure changera si vous utilisez un PC avec un autre fuseau horaire pour le vérifier.
Effacez les filtres Wireshark par défaut (ou ne les utilisez pas)
Configurez Wireshark pour créer un nouveau fichier tous les 50 Mo et conservez une mémoire tampon de 15 fichiers (après quoi les fichiers commencent à être écrasés):
Que faire si c’est aléatoire et qu'aucune capture d’écran n'a pas été prise pour les téléphones présentant ce problème?
- Vous pouvez rassembler les traces détaillées du CCM (celles-ci doivent être activées avant que cela ne se produise, sinon l'information sera perdue).
- Sur les traces CCM, vous pouvez vérifier les statistiques RTP pour SIP ou SCCP et vérifier si l'un d'entre eux ne reçoit pas ou n'envoie pas de paquets. Notez que les ressources média CCM telles que MTP n'envoient pas de statistiques RTP.
Voici donc ce que vous recherchez sur les traces de CCM:
Cet exemple montre l’audio à sens unique, le flux d'appels est un appel de téléphone SIP vers un téléphone SCCP.
Les informations pertinentes du téléphone SIP sont marquées en bleu
Les informations pertinentes du téléphone SCCP sont marquées en orange
Puisque le CUCM envoie correctement l'adresse IP et le port à chaque téléphone, il ne s'agit pas d'un problème de signalisation / CUCM.
Sur le 200 OK pour le message BYE, le téléphone SIP envoie des statistiques RTP, le téléphone SCCP envoie un message ConnectionStatisticsRes.
Cela montre que le téléphone SCCP n'a pas reçu le flux RTP du téléphone SIP, cela a été perdu sur le réseau, cela s'avére être un FW bloquant le flux, ce problème a été résolu en permettant le trafic sur le FW.
Mais cela aurait pu être un pare-feu bloquant non seulement le flux mais modifiant l’information d’entêtes (inspection SIP et / ou SCCP), ou un périphérique L3 ayant mal acheminé le trafic depuis le périphérique SIP, ou problème de transporteur (carrier) d’un WAN / MPLS.
Que se passe-t-il si un téléphone ne transmet pas?
Si vous ne voyez pas un téléphone transmettant, alors obtenez des traces détaillées du CCM ou une capture de paquet à partir du téléphone afin de pouvoir vérifier si le téléphone reçoit un message « envoi unique »/« réception unique » SDP.
Publié par: cnuche / Version originale en anglais