Diagnostiquer le chemin de communication unidirectionnel ou inexistant

Dernière mise à jour : Mar 19, 2025 |
Informations sur le prologue
Préambules
Pour la résolution de ce symptôme, désactivez le shuffling (s'il est activé), ce qui force le trafic à utiliser le processeur multimédia et simplifie l'analyse du réseau. Entre autres étapes, vérifiez si les téléphones IP impliqués dans l'appel peuvent recevoir de l'audio ou un ton de composition. Au besoin, la passerelle multimédia peut vérifier la connectivité des téléphones IP et de leur sous-réseau local à l'aide de pings. Les erreurs de couche 1 peuvent également être contrôlées.
Suivez cette procédure pour diagnostiquer un problème de voie de communication unidirectionnelle ou de non-communication.
  1. Si l'évaluation du réseau a été effectuée récemment et que le réseau n'a pas été modifié après l'évaluation, il se peut qu'il y ait un problème de réseau ou que le téléphone IP ait un logiciel obsolète.
    INFORMATIONS SUPPLÉMENTAIRES :
    Passez à l'étape 2. Sinon, le réseau peut ne pas être conforme aux exigences de réseau d'Avaya. Si le problème ne peut pas être résolu en suivant les procédures décrites ci-dessous, une (ré)évaluation pourrait être nécessaire.
  2. Si les téléphones IP sur le même VLAN/sous-réseau/étage rencontrent le même problème, il peut y avoir un problème de réseau ou plusieurs téléphones IP peuvent avoir un logiciel obsolète.
    INFORMATIONS SUPPLÉMENTAIRES :
    Si la version du microprogramme du téléphone IP est obsolète, téléchargez et installez le microprogramme approprié (voir la mise à jour du logiciel, du microprogramme et du BIOS ou le site Web d'assistance Avaya http://support.avaya.com). Si cela résout le problème, aucune autre étape n'est nécessaire, sinon vérifiez si l'appel est mélangé. Reportez-vous à la section Vérification si l'appel est mélangé.
  3. Si l'appel est mélangé, désactivez le mélange avec la commande change station ext#.
  4. Réglez le champ Connexions audio IP-IP directes sur n.
    INFORMATIONS SUPPLÉMENTAIRES :
    Si cela résout le problème, alors il y a un problème de réseau qui empêche les deux téléphones IP de communiquer directement. Reportez-vous à Vérification si le module multimédia peut envoyer un ping aux téléphones IP.
    Remarque :
    Les commandes PING et trace-route à distance peuvent être utilisées pour aider à localiser l'emplacement dans le réseau où les appels mélangés rencontrent des problèmes.
    Si cela ne résout pas le problème, il pourrait y avoir un problème de réseau ou de module multimédia. Bien qu’un problème de réseau soit toujours très probable, gardez le défilement désactivé.
  5. Vérifiez si le téléphone IP reçoit une tonalité de composition.
    INFORMATIONS SUPPLÉMENTAIRES :
    Si le téléphone IP reçoit une tonalité de composition, vérifiez s'il y a des erreurs Communication Manager enregistrées pour le module multimédia ou le téléphone IP. Si le téléphone IP ne reçoit pas de tonalité de composition, reportez-vous à la section Diagnostiquer le problème de non-tonalité de composition.
  6. Exécutez la commande display errors pour vérifier s'il existe un journal des erreurs matérielles et un journal des événements de refus pour les erreurs concernant le téléphone IP avec l'extension particulière.
  7. Si des erreurs existent, utilisez les informations du journal des erreurs et du Alarmes, événements et référence des fichiers journal Avaya Aura® Communication Manager pour corriger les erreurs.
    INFORMATIONS SUPPLÉMENTAIRES :
    Si cela résout le problème, aucune autre étape n'est nécessaire. Sinon, vérifiez si le module multimédia reçoit l'audio vocal des deux téléphones IP lors de l'appel. Reportez-vous à Vérification si le module multimédia peut envoyer un ping aux téléphones IP.
  8. Si le téléphone IP envoie de l'audio, allez à l'étape 5. Si le téléphone IP n'envoie pas d'audio ou si le réseau bloque les paquets audio, échangez le téléphone IP.
    INFORMATIONS SUPPLÉMENTAIRES :
    S'il ne résout pas le problème, il y a un problème de réseau que le client doit régler.
  9. Vérifiez si le module multimédia fonctionne correctement et si les ressources audio du module multimédia sont suffisantes.
  10. S'il y a un module média attribué dynamiquement à l'appel téléphonique IP, accédez au formulaire Station (statut poste ext#) et vérifiez le champ Last Tx Sequence.
    INFORMATIONS SUPPLÉMENTAIRES :
    Ce champ indique le numéro de séquence RTP du dernier paquet envoyé par le module multimédia au téléphone IP. Ce numéro de séquence doit augmenter à un rythme régulier lorsque vous exécutez la commande status station ext# plusieurs fois. S'il n'augmente pas, il y a probablement un problème de matériel ou de logiciel du module média. Utilisez le Alarmes, événements et référence des fichiers journal Avaya Aura® Communication Manager pour résoudre l'incident. Si les paquets sont transmis normalement, reportez-vous à Vérification si le module média reçoit l'audio vocal des deux téléphones IP dans l'appel..
  11. Si la section CANAL AUDIO du formulaire de station d'état est vide, cela peut être dû au fait que le module média ne peut pas allouer de ressources pour l'appel.
  12. Exécutez la commande list measurements ip dsp-resource pour déterminer s'il y a suffisamment de ressources de module multimédia dans le système.
  13. Vérifiez s’il y a des refus, des blocages et une condition de dérangement.
    INFORMATIONS SUPPLÉMENTAIRES :
    Si l'une de ces mesures est supérieure à 0, cela peut indiquer qu'il pourrait y avoir un problème avec le module multimédia. Reportez-vous à Problèmes de module multimédia pour obtenir la liste des problèmes qui pourraient survenir avec le module média.
  14. S’il n’y a aucun problème de module média, vérifiez si le téléphone IP qui rencontre le problème unidirectionnel ou les deux téléphones IP qui rencontrent le problème bidirectionnel peuvent être pingés à partir du module média.
  15. Si le ping est envoyé, déterminez l'emplacement où le ping s'est terminé en exécutant la commande trace-route ip 135.9.42.105 board 07D17.
    INFORMATIONS SUPPLÉMENTAIRES :
    Le client doit résoudre le problème de réseau dans le routeur qui a terminé la commande de traceroute. Passez à l'étape 21 après que le problème a été résolu.
  16. Vérifiez si l'appel traverse un pare-feu/ACL. Reportez-vous à la vérification si l'appel passe par un pare-feu/ACL.
  17. Si l'appel traverse, assouplissez les contraintes de filtrage de paquets/ports dans le pare-feu si elles sont trop strictes.
  18. Vérifiez s'il y a des erreurs de couche 1 détectées dans le téléphone IP, les commutateurs/routeurs intermédiaires ou dans le module média, en vous connectant aux commutateurs et aux routeurs.
  19. Vérifiez les statistiques du port.
    INFORMATIONS SUPPLÉMENTAIRES :
    Remarque :
    Certains clients ne permettront pas cela. Dans un tel cas, le client devrait être invité à fournir cette information.
  20. S'il y a des erreurs, il y a un problème de réseau (responsabilité du client).
    INFORMATIONS SUPPLÉMENTAIRES :
    S’il n’y a aucune erreur, placez un analyseur de protocole aux deux extrémités de l’appel en utilisant la mise en miroir de port du commutateur pour voir où les paquets sont perdus et résoudre le problème. Passez à l'étape 21 après que le problème a été résolu.
  21. Au besoin, retournez à l'état initial en activant le mélange/la rotation.
    INFORMATIONS SUPPLÉMENTAIRES :
    Reportez-vous à la section Retour à un état mélangé. Cependant, le retour à un état mélangé peut ramener le problème. Cependant, le retour à un état mélangé peut ramener le problème.