TelePresence : Téléphone IP unifié de la gamme Cisco 7900

Utilisation des informations d'état des téléphones IP 79xx à des fins de dépannage

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document se concentre sur les informations d'état que tous les Téléphones IP de Cisco 79xx fournissent sur leur affichage pour dépannage des problèmes. Ces informations peuvent être utilisées pour déterminer le type de codecs en service pour un appel en cours. Il fournit également l'information en temps réel sur les caractéristiques du fonctionnement pour un appel en cours.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Affichage

L'affichage du téléphone IP 79xx de Cisco peut être utilisé pour dépannage des buts par l'intermédiaire du bouton de l'information (i) au téléphone d'afficher les informations à un appel en cours. Appuyez sur ce bouton deux fois pendant un appel actif pour lancer cette caractéristique.

/image/gif/paws/7415/telecaster-trouble_8.gif

Remarque: « Je » me boutonne ressemble à ceci /image/gif/paws/7415/telecaster-trouble_9.gif.

Ce menu fournit les informations suivantes :

  • RxType/TxType — Les codecs actuellement utilisés dans la conversation vocale active en cours.

  • RxSize/TxSize — La taille de la charge utile des codecs, dans ce cas 20 millisecondes de Voix/de paquet.

    Remarque: Le support de Téléphones IP 79xx MGCP seulement une taille de charge utile de 10-40 milliseconde.

  • RxCount/TxCount — Quantité de paquets envoyés/reçus.

  • AvgJtr — Le jitter moyen est le jitter moyen prévu observé dans les 16 derniers paquets de RTP (la fonction de établissement d'une moyenne est juste un filtre passe-bas simple).

  • MaxJtr — Le jitter maximum est le jitter maximum vu pendant la vie du RTP reçoivent le flot. Souvenez-vous que ce n'a pas lieu pour la vie de l'appel, mais pour le flot. Si vous mettez une personne sur l'attente, le flot part et doit être redémarré et par conséquent de nouvelles valeurs ici.

  • RxDisc — Le nombre de paquets a jeté d'arrivée sur ce téléphone IP 79xx de Cisco.

  • RxLost — Le nombre de paquets qui ne sont pas arrivés d'arrivée sur ce téléphone IP 79xx de Cisco.

Choses à focaliser en fonction pour le dépannage :

  • Le RxType/TxType t'indique quel codec est utilisé pour la conversation entre ce téléphone IP et l'autre périphérique. Voyez s'ils s'assortissent des deux côtés. S'ils ne s'assortissent pas, vérifiez que l'autre périphérique peut manipuler la conversation de codecs ou qu'un transcodeur est en place pour manipuler le service.

  • La taille des échantillons sains devrait s'assortir sur les deux périphériques. Ceci est trouvé dans les domaines RxSize/TxSize.

  • Le RxCount/TxCount est utile pour dépanner les paquets relâchés, les problèmes d'une Voix de manière, et la détection d'activité vocale (VAD).

Jitter

Dans le monde de Voix, le jitter associe à l'écart inter des paquets dans le réseau. Dans le meilleur des cas, des paquets vocaux devraient être reçus synchroniquement avec un retard constant (mais pas trop long). Malheureusement, la plupart des réseaux livrent des paquets vocaux asynchrone. En d'autres termes, il y a une variance dans le temps entre les paquets vocaux. Ceci désigné sous le nom du jitter. Quand le temps entre les paquets vocaux (jitter) varie au delà des tampons d'extraction sur le périphérique récepteur, l'appelé entendra des lacunes dans le flux voix.

Dans un monde idéal, un flot des paquets contenant la Voix arriverait au périphérique d'extrémité (appelé) avec exactement le même montant de l'écart inter de paquet. Ceci aurait comme conséquence une valeur de jitter de 0. Dans le monde réel, l'écart entre les paquets vocaux peut varier du paquet au paquet introduisant le jitter dans l'ordre.

Pour faire face à cette question, les téléphones 79xx contiennent une file d'attente du first-in, first-out (FIFO) qui agit en tant que tampon de paquets élastique. Il essaye de garder l'écoulement des paquets vocaux aux DSP constants en lisant les paquets avec un écart inter constant de paquet. Ceci aide à assurer la Qualité vocale acceptable. La mémoire tampon du jitter 79xx manipulera jusqu'à deux secondes de jitter. Le jitter est mesuré dans le ms.

Si l'écart inter de paquet d'un flux voix entrant varie entre 0 ms et 2 s, le tampon FIFO 79xx's pourra masquer cette variation et aucune lacune dans le flux voix entrant ne sera détectée par l'appelé. D'autre part, si un flux voix entrant éprouve un écart inter de paquet au-dessus de 2 s, le tampon FIFO 79xx's aura été vidé tout en attendant le prochain paquet vocal. Dans cette situation entaille dans le flux voix sera détecté. Ceci est expliqué plus en détail ci-dessous.

Dans l'exemple au-dessous de chaque paquet a exactement le même montant du retard entre lui et le paquet suivant dans l'ordre. Dans ce cas la valeur constante de retard entre les paquets (5 ms) a comme conséquence une valeur de jitter de 0.

/image/gif/paws/7415/telecaster_trouble_1.gif

Dans une situation de réseau réel le retard inter de paquet est rarement constant :

/image/gif/paws/7415/telecaster_trouble_2.gif

Car un flot des paquets vocaux traverse les mémoires tampons de tous les Routeurs et les Commutateurs qui existent entre la source et la destination, des lacunes sont insérées entre les paquets. Ces lacunes varieront dans la taille parce que le chargement sur les Routeurs et les Commutateurs entre la source et la destination changera constamment.

Dans le diagramme ci-dessus nous pouvons voir le paquet inter entailler la plage de 5 à 14 à 10. Les périphériques d'extrémité dans le réseau (Téléphones IP dans ce cas) doivent compenser ces variations de sorte que les paquets soient lus à l'auditeur (appelé) à un débit constant. Ceci exige que les tampons FIFO ont toujours des paquets vocaux disponibles pour jouer.

La taille d'un tampon FIFO 79xx's varie basé sur la quantité de jitter expérimentée dans le flux voix entrant. Si la valeur de jitter d'un flux voix entrant est basse, le 79xx utilisera un plus petit tampon FIFO que quand la la valeur de jitter d'un flux voix entrant est élevée. Il est possible cependant, cela que la vitesse de variation de la valeur de jitter sera plus rapide que le 79xx peut faire face à. Dans ce cas, l'auditeur (appelé) éprouvera un bref écart dans le flux voix tandis que le 79xx ajuste sa taille de tampon FIFO.

Remarque: Le téléphone IP 79xx de Cisco augmente la taille de tampon FIFO rapidement et la diminue lentement.

La taille du tampon FIFO exerce un effet direct sur le retard entre un paquet vocal envoyé et reçu par la destination. Pendant que le tampon FIFO se développe plus grand, le retard en paquets mobiles hors du tampon FIFO augmente. Voyez la section suivante sur le retard pour plus d'informations sur ce sujet.

Le diagramme suivant affiche un tampon FIFO enlevant le jitter d'un flux voix entrant.

telecaster_trouble_3.gif

Si vous éprouvez les lacunes dans vos communications voix (coupes-circuit) vérifient les valeurs d'AvgJtr et de MaxJtr. Si, par exemple, la valeur moyenne de jitter est 5 et la valeur maximum de jitter est 3000, il y a une possibilité d'un problème parce que la variance entre les deux valeurs est très élevée. Si ceci se produisait rapide, il ne pourrait pas y avoir eu assez de temps pour que la file d'attente FIFO 79xx's compense. Ce type de comportement peut être trouvé dans les réseaux qui ont des hauts débits périodiques d'activité tels que de grandes mises à jour de table de routage ou traitent en lots des transferts de fichiers. Dans des ces cas les charges de la circulation vont de bas ou de moyen à élevé et d'arrière de nouveau dans très une courte période.

Remarque: Le téléphone IP 79xx de Cisco peut typiquement manipuler jusqu'à 20 pour cent de perte de paquets sans dégradation apparente de qualité.

Retard

Le retard est la durée qu'il prend un paquet vocal (ou le flux voix) pour voyager de la source à la destination. Dans la plupart des cas le retard variera au cours d'un flux voix (conversation). Dans un réseau correctement accordé, le délai maximal entre le moment où un appelant parle et l'appelé entend que ce qui a été dit est inférieur ce que la personne ordinaire peut détecter. En d'autres termes, il n'y a aucun retard perceptible dans la conversation - des mots sont entendus dès qu'ils seront parlés.

Dans certains cas le retard à travers le réseau grimpera jusqu'à un niveau qui est décelable par l'oreille humaine. Dans un scénario de le pire des cas la conversation détériorera au point où chaque personne doit indiquer qu'ils ont arrêté parler de sorte que l'autre personne sache qu'ils peuvent parler sans être interrompue par les paquets vocaux qui n'ont pas été encore reçus. Si vous êtes au courant des Ethernets vous pourriez appeler ce comportement une collision en retard.

Tous les réseaux imposent un certain retard dans la transmission des paquets de la source à la destination. Même un réseau avec un écart inter constant de paquet de < 1ms éprouvera un certain retard dans le temps entre quand un périphérique de source envoie un paquet et le périphérique de destination le reçoit. Les liaisons série à basse vitesse (64K et ci-dessous) créent plus de retard qu'un lien à grande vitesse tel qu'un OC12 en raison du temps où il prend pour sérialiser les bits sur le support de transmission.

Les variations du retard sont provoqué par par les mêmes situations qui mènent à de longues lacunes inter de paquet comme décrit dans la section sur le jitter ci-dessus. Dans le cas du retard, cependant, les causes durent typiquement plus long que quelques paquets vocaux. Au lieu d'entraîner une augmentation de l'écart inter de paquet pour quelques paquets dans une conversation, ces problèmes affectent des conversations entières.

Remarque: Le téléphone IP 79xx de Cisco ne fournit pas un compteur de retard. Le retard peut être mesuré par des analyseurs de réseau et d'autres périphériques de Gestion de réseau.

Les problèmes mineurs de retard n'affectent pas la Qualité vocale aussi mal que le jitter peut. C'est parce que le jitter peut entraîner des ruptures dans le flux voix où des mots parlés entiers peuvent être perdus, tandis qu'avec le retard, tous les mots parlés arriveront par la suite. En d'autres termes le jitter est très semblable à la perte de paquets dans un réseau abonné fini - les paquets plus de circulent les mémoires tampons d'interface et les obtiennent relâché, ainsi il signifie qu'elles n'arrivent jamais à la destination.

Le diagramme ci-dessous affiche l'effet combiné du retard avec le jitter, qui vont de pair. Les paquets sont transmis à un débit constant. Le réseau IP n'expédie pas les paquets en tant que rapidement ou uniformément, qui a eu comme conséquence de plus grandes et diverses lacunes inter de paquet. En outre, le quatrième paquet est toujours quelque part dans le réseau.

telecaster_trouble_6.gif

Le retard cumulatif dans un réseau dépend combien le routeur et commute vos besoins du trafic de traverser entre la source et la destination de n'importe quelle conversation.

Dans un environnement IP, une manière de mesurer le retard serait d'utiliser l'outil de traceroute, mais ceci fonctionnera seulement pour des sauts de routeur. En outre, quelques hôtes qui prennent en charge la traceroute l'exécutent à une priorité très basse CPU, qui aide pendant une attaque du Déni de service (DOS). Ceci signifie qu'il y a un retard imposé de la part de la CPU qui sera ajoutée au temps que les paquets ont pris pour aller d'un saut à l'autre. En d'autres termes - ne placez pas beaucoup de foi dans les nombres signalés par traceroute.

Il y a des outils d'analyse de réseau tiers qui peuvent envoyer des paquets et le retard de mesure vers le bas à la nanoseconde. Ils sont très utiles pour tester des prototypes de conception de réseaux dans des conditions de charge avant de les mettre en application. Il devrait noter cependant qu'un réseau voix robuste, bien conçu et accordé ne devrait pas avoir à problèmes cohérents de retard et instabilité.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 7415