Configurer la collecte de débogage pour les passerelles CUBE et TDM

Introduction

Ce document décrit certaines des meilleures pratiques afin de collecter des débogages vocaux dans un routeur vocal Cisco IOS®/IOS XE®.

Conditions préalables

Exigences

• Connaissances de base de Cisco IOS/IOS XE au sein des routeurs à services intégrés (ISR).
• Accès privilégié pour exécuter des commandes dans les routeurs ISR.
• Une expérience préalable des protocoles VoIP (Voice-over-IP) est souhaitée.
• Pour VoIP Trace, Cisco IOS XE 17.4.1 ou 17.3.2 minimum est requis.

Composants utilisés

Aux fins du présent document, les composants utilisés sont les suivants :

• Cisco ISR 3925
• Cisco ISR 4451
• PuTTY

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Le processus de collecte des débogages dans ces plates-formes présente des défis et peut potentiellement affecter les performances du périphérique. Les défis et les risques augmentent lorsque plusieurs appels actifs sont établis dans un routeur vocal. Dans certains scénarios, si les débogages ne sont pas collectés correctement, cela peut conduire à une CPU élevée qui pourrait nuire à la capacité du routeur et même provoquer une panne logicielle. Ce document traite de la différence entre un CUBE (Cisco Unified Border Element) et une passerelle analogique/TDM (Time-Division Multiplexing).

Passerelles vocales TDM et CUBE

Les passerelles vocales TDM sont principalement utilisées pour interconnecter un système téléphonique interne avec un autre autocommutateur privé (PBX) ou le réseau téléphonique public commuté (RTPC). Les types de connexions utilisés dans les passerelles TDM sont les contrôleurs T1/E1 (RNIS ou CAS) et les circuits analogiques tels que les ports FXS et FXO. Un processeur de signal numérique (DSP) convertit l'audio de sa forme brute en paquets RTP. De la même manière, les paquets RTP sont convertis en audio brut après que le DSP a traité les paquets RTP et envoyé l'audio sur le circuit spécifique. Ces passerelles peuvent interagir avec H323, MGCP ou Skinny Call Control Protocol (SCCP) du côté VoIP et du côté TDM avec ses circuits RNIS PRI ou analogiques comme connexions les plus courantes au RTPC ou aux points d'extrémité.

Comme l'illustre l'image, les passerelles TDM fournissent un pont entre votre infrastructure VoIP interne et les fournisseurs de services analogiques ou RNIS :

Avec l'introduction de la VoIP, les clients ont commencé à transformer rapidement leurs systèmes existants en une infrastructure VoIP moderne. La même chose s'est produite du côté des fournisseurs de services, où ils utilisent désormais des connexions pour interconnecter les services de téléphonie sur site avec l'infrastructure VoIP des fournisseurs de services et étendre leurs capacités afin de fournir de meilleurs services. Le protocole VoIP le plus couramment utilisé aujourd'hui est le protocole SIP (Session Initiation Protocol), et est actuellement largement utilisé par les clients et les fournisseurs de services de téléphonie Internet (ITSP) dans le monde entier.

CUBE a été introduit pour fournir un moyen d'interconnecter ces systèmes VoIP internes avec le monde extérieur par le biais des ITSP avec SIP comme protocole VoIP principal. CUBE est simplement une passerelle IP-IP qui n'a plus besoin d'aucun type de connexion TDM, comme les contrôleurs T1/E1 ou les ports analogiques. CUBE fonctionne sur les mêmes plates-formes que les passerelles TDM.

Le protocole VoIP le plus couramment utilisé est le protocole SIP, pour l'établissement et le démontage des appels, et le protocole RTP pour le transport multimédia. Dans CUBE, un DSP n'est pas nécessaire, sauf si un transcodeur est requis. Le trafic RTP circule de bout en bout du fournisseur de services Internet au point d'extrémité, et CUBE agit comme intermédiaire avec une adresse cachée comme l'une des nombreuses fonctionnalités qu'il offre.

Comme l'illustre l'image, CUBE permet de distinguer votre infrastructure VoIP interne de l'ITSP SIP :

Collection de débogages vocaux Cisco IOS/IOS XE

Les fonctions vocales sont exécutées sur une liste différente de plates-formes, telles que ISR, ASR, CAT8K, entre autres ; cependant, ils utilisent un logiciel commun qui est soit Cisco IOS ou Cisco IOS XE (les différences entre Cisco IOS et Cisco IOS XE ne sont pas couvertes dans cet article). Voici les bases de l’accès au routeur Cisco IOS.

Comment accéder à un routeur Cisco IOS/IOS XE via l'interface de ligne de commande (CLI)

Les routeurs, comme tous les autres périphériques basés sur l’interface de ligne de commande, nécessitent un moniteur de terminal pour accéder à l’exécution des commandes via Secure Shell (SSH) ou Telnet. SSH est le protocole le plus couramment utilisé de nos jours pour accéder aux périphériques donnés. Il fournit une connexion sécurisée et chiffrée au périphérique. Voici quelques-uns des moniteurs de terminal couramment utilisés pour accéder à l’interface de ligne de commande des routeurs :

Comment configurer le moniteur de terminal pour collecter des commandes show ou des débogages

Il existe différentes manières de collecter les résultats de l'interface de ligne de commande. Il est recommandé d'exporter les informations de l'interface de ligne de commande du routeur vers un fichier distinct. Cela facilite le partage de l'information avec des parties externes.

Voici quelques façons de collecter les sorties du périphérique :

• Videz tous les résultats dans le terminal. Vous devez vous assurer qu'il y a suffisamment de lignes de défilement, sinon, le défilement manque les premières sections de la sortie et les données peuvent être incomplètes. Afin d'augmenter les lignes de défilement dans Putty, naviguez à Putty Configuration > Window > Lines of Scrollback. Normalement, cette valeur est très élevée afin d'avoir assez de résultats de défilement :

Vous pouvez ensuite collecter les informations du moniteur de terminal à l'aide de l'option Copier tout dans le Presse-papiers et coller le résultat dans un fichier texte :

• Une autre option consiste à consigner la sortie de session entière dans un fichier .txt. Avec cette option, toutes les commandes entrées et toutes les sorties collectées sont immédiatement consignées dans le fichier texte. Il s'agit d'une pratique courante afin de consigner tous les résultats dans une session. Afin de consigner toutes les sorties de session dans un fichier dans Putty, naviguez à Putty Configuration > Session > Logging puis sélectionnez All Session Output comme suit :

Remarque : Le nom de fichier journal par défaut est utilisé si aucun autre nom n'est spécifié. Cliquez sur le bouton Parcourir afin de savoir exactement où le fichier est enregistré afin de le retrouver plus tard. Assurez-vous également de ne pas écraser un autre fichier putty.log dans le même chemin d'accès.

Collecter les résultats de la commande show de base à partir de la CLI

Les commandes show sont nécessaires pour collecter des informations de base à partir du routeur avant toute collecte de débogage. Les commandes show sont rapides à collecter et, pour la plupart, n'ont aucun impact sur les performances du routeur. L'isolation du problème peut commencer immédiatement avec une simple sortie de commande show.

Une fois connecté au routeur, la longueur du terminal peut être définie sur 0. Cela peut accélérer la collecte afin d'afficher toutes les sorties à la fois et d'éviter l'utilisation de la barre d'espace. La seule commande qui collecte des informations détaillées sur le routeur est show tech. Vous pouvez également collecter la commande show tech voice qui affiche des données plus spécifiques aux fonctionnalités vocales activées sur le routeur :

Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default

Collecter les résultats du débogage à partir de la CLI

La collecte des résultats de débogage dans Cisco IOS/IOS XE peut parfois être un défi, car il y a un risque de panne du routeur. Certaines des meilleures pratiques sont expliquées dans les sections suivantes pour éviter tout problème.

Vérification de la mémoire

Avant d'activer des débogages, vous devez vous assurer qu'il y a suffisamment de mémoire pour stocker la sortie dans la mémoire tampon.

Exécutez la commande show process memory pour savoir combien de mémoire vous pouvez allouer afin de consigner toutes les sorties dans la mémoire tampon :

Conseil : Utilisez la commande terminal length default ou terminal length <num_lines> pour revenir à un nombre limité de lignes affichées dans le terminal.

Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832

Dans l'exemple, 7666268552 octets (7,6 Go) peuvent être utilisés par le routeur. Cette mémoire est partagée par le routeur entre tous les processus système. Cela signifie que vous ne pouvez pas utiliser toute la mémoire libre pour enregistrer les résultats dans la mémoire tampon, mais vous pouvez utiliser une bonne quantité de mémoire système si nécessaire.

La plupart des scénarios nécessitent au moins 10 Mo pour collecter suffisamment de sortie de débogage avant que la sortie ne soit perdue ou écrasée. Dans de rares cas, une plus grande quantité de données doit être collectée. Dans ces scénarios spécifiques, vous pouvez obtenir de 50 Mo à 100 Mo de sortie dans la mémoire tampon, ou vous pouvez aller plus haut tant qu'il y a de la mémoire disponible.

Si la mémoire disponible est insuffisante, il existe un problème potentiel de fuite de mémoire. Si tel est le cas, demandez à l'équipe du centre d'assistance technique d'architecture de réviser la cause de cette mémoire insuffisante.

Vérification de l'unité centrale (UC)

Le processeur est affecté par le nombre de processus, de fonctionnalités et d'appels actifs dans le système. Plus le nombre de fonctions ou d'appels actifs dans le système est élevé, plus le processeur est occupé.

Un bon test consiste à s'assurer que le routeur dispose d'un processeur à 30 % ou moins, ce qui signifie que vous pouvez activer en toute sécurité les débogages de basique à avancé (gardez toujours un oeil sur le processeur lorsque des débogages avancés sont utilisés). Si le processeur du routeur est à environ 50 %, les débogages de base peuvent être exécutés et surveiller attentivement le processeur. Si le processeur atteint plus de 80 %, arrêtez immédiatement les débogages (voir plus loin dans cet article) et demandez de l'aide au TAC.

Utilisez la commande show process cpu sorted | exclude 0.00 pour vérifier les 5 dernières valeurs CPU, 60 dernières et 5 minutes ainsi que les processus supérieurs.

Router# show processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
211 4852758 228862580 21 0.15% 0.06% 0.07% 0 IPAM Manager
84 3410372 32046994 106 0.07% 0.04% 0.05% 0 IOSD ipc task
202 3856334 114790390 33 0.07% 0.05% 0.05% 0 VRRS Main thread

Dans le résultat, le routeur n'a pas beaucoup d'activité, le processeur est faible et les débogages peuvent être activés en toute sécurité.

Mise en garde : Portez une attention particulière aux principaux processus CPU actifs. Si le processeur est à 50 % ou plus et que le processus supérieur est un processus vocal uniquement, les débogages de base peuvent être activés. Surveillez en permanence le processeur à l'aide de la commande pour vous assurer que les performances globales du routeur ne sont pas affectées.

Vérification des appels actifs actuels

Chaque routeur a des seuils de capacité différents. Il est important de vérifier combien d'appels sont actifs dans le routeur pour s'assurer qu'il n'est pas proche de la capacité maximale. La fiche technique Cisco Unified Border Element Version 12 fournit des informations de référence sur la capacité de chaque plate-forme.

Utilisez la commande show call active total-calls pour avoir une idée du nombre d'appels actifs dans le système :

Router# show call active total-calls
Total Number of Active Calls : 0

Utilisez la commande show call active voice summary pour obtenir des informations plus détaillées sur les types d'appels spécifiques qui sont actifs :

Router# show call active voice summary
Telephony call-legs: 0
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 0

Voici quelques-unes des valeurs communes :

• Tronçons d'appel de téléphonie : Appels TDM Gateway, y compris les appels analogiques et PRI/RNIS
• Tronçons d'appel SIP : Total des appels SIP. S'il s'agit d'un routeur CUBE, cela indique 2 tronçons d'appel par appel. Divisez le nombre total d'appels affiché ici par 2 pour obtenir un nombre précis
• Tronçons d'appel H323 : Total des appels H323
• Tronçons d'appel SCCP : Ressources multimédia contrôlées par Cisco Unified Communications Manager (CUCM) utilisées dans le routeur, telles que les transcodeurs et les MTP

Paramètres du tampon de journalisation

Pour configurer le routeur de manière à stocker la sortie de débogage dans la mémoire tampon, le mode configure terminal est activé pour modifier manuellement les paramètres de l'interface de ligne de commande. Cette configuration n'a pas d'impact sur le routeur, cependant, comme indiqué dans les sections précédentes, la commande show tech ou show running-config du routeur est nécessaire dans le cas où la configuration doit être restaurée.

Voici un exemple de configuration, qui est une ligne de base commune utilisée par les ingénieurs du centre d'assistance technique. L'exemple alloue une mémoire tampon de 10 Mo, mais elle peut être augmentée si nécessaire : 

# configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog

Ces commandes permettent d'effectuer les tâches suivantes :

• service timestamps debug ou log : Garantit que l'heure du routeur local est écrite sur chaque message enregistré, avec une précision de quelques millisecondes. Cette fonction est utile pour rechercher des appels en fonction de l'heure. Les horodatages en millisecondes vous permettent de regrouper des lignes de débogage en événements logiques connexes lorsque deux lignes se produisent au cours de la même milliseconde.
• numéro d'ordre du service : Écrit le numéro de séquence du débogage dans la ligne. Ceci est utile (essentiellement requis) lorsque les journaux sont transférés à un serveur Syslog. Ceci est très utile afin d'identifier si des messages de débogage au serveur Syslog ont été abandonnés dans le réseau. Le numéro d'ordre est le premier élément du débogage, avant l'horodatage et le message de journal réel. Notez que ceci est différent de l'horodatage/numéro de séquence que les serveurs syslog peuvent écrire localement dans leurs fichiers.
• tampon de journalisation : Indique au routeur d'envoyer des débogages à sa mémoire tampon locale. La taille du tampon est définie en octets. Dans la configuration, la taille de la mémoire tampon a été définie sur 10 Mo.
• pas de console de journalisation et pas de moniteur de journalisation : Aucun message de journal n'est imprimé dans la console ou le moniteur de terminal. Si ces commandes ne sont pas configurées, elles peuvent nuire aux performances du routeur et à la précision des résultats de débogage.
• voice iec syslog : Active les messages de codes d'erreur internes vocaux pour déterminer les raisons de déconnexion.

Configuration des paramètres Syslog

Parfois, les problèmes peuvent être aléatoires et nécessitent un moyen de collecter continuellement des débogages jusqu'à ce que l'événement se produise. Lorsque vous stockez les débogages dans la mémoire tampon, elle les collecte en continu. Notez qu'il est limité à la quantité de mémoire que vous pouvez allouer et une fois qu'il atteint cette quantité de mémoire, la mémoire tampon entoure et abandonne les messages les plus anciens, ce qui conduit à des informations précieuses incomplètes nécessaires pour isoler le problème.

Avec Syslog, le routeur peut envoyer tous les messages de débogage à un serveur externe, où le logiciel Syslog Server les stocke dans des fichiers texte. Bien que ce soit un bon moyen de collecter la sortie de débogage, ce n'est pas la méthode préférée pour la collecte de journaux. Les serveurs Syslog ont tendance à ignorer ou à supprimer des lignes du résultat reçu en raison d'un encombrement du serveur. Comme la sortie de débogage peut submerger le serveur, ou les paquets peuvent être abandonnés en raison des conditions du réseau. Cependant, dans certains scénarios, Syslog est le seul moyen de progresser sur un problème.

Si possible, utilisez une méthode de transport fiable telle que TCP pour éviter toute perte d'informations et, comme suggestion, connectez le serveur Syslog au même commutateur où le routeur est connecté, ou aussi près que possible du routeur. Il ne garantit toujours pas que toutes les données sont stockées dans les fichiers, mais réduit les risques de perte de données.

Par défaut, les serveurs syslog utilisent le protocole UDP comme protocole de transport sur le port 514.

#configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers

!Optional in case you still want to store debug output in the buffer.
logging buffered 10000000

no logging console
no logging monitor

logging trap debugging

!Replace the 192.168.1.2 with the actual Syslog Server IP Address
logging host 192.168.1.2 transport [tcp|udp] port 

Dès que les commandes sont configurées, le routeur transfère immédiatement les messages à l'adresse IP du serveur Syslog.

Debug Collection

Une fois les débogages activés, la mémoire tampon doit être effacée avant que le problème ne soit reproduit. Cela permet de s'assurer que le résultat est aussi propre que possible et d'éviter toute donnée supplémentaire qui n'est pas nécessaire pour l'analyse. Exécutez la commande clear log. Cela garantit que la mémoire tampon est effacée. Si d'autres appels sont actifs dans le routeur et que les débogages sont activés, le résultat s'imprime immédiatement dans la mémoire tampon.

Router# clear log
Clear logging buffer [confirm]
Router#

Une fois le problème reproduit, désactivez les débogages immédiatement pour arrêter d'autres sorties dans la mémoire tampon. Ensuite, collectez les journaux. Vous pouvez vider tous les résultats du terminal avec les commandes suivantes :

Router# undebug all
Router# terminal length 0
Router# show log

Parfois, PuTTY se ferme car il ne peut pas gérer toutes les sorties en même temps. C'est normal et cela ne signifie pas qu'un échec est survenu. Dans ce cas, rouvrez la session et continuez normalement. Dans les scénarios où la mémoire tampon de journalisation est trop grande ou le moniteur de terminal tombe en panne en raison de la quantité de données qui doivent être imprimées, copiez la sortie de la mémoire tampon sur un périphérique externe directement avec show log | commande redirect :

Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt

La commande copie l'intégralité de la sortie de la mémoire tampon dans un FTP avec l'adresse IP 192.168.1.2 et le nom de fichier debug.txt. Le nom de fichier doit toujours être spécifié. Les autres destinations disponibles pour exporter ces données sont les suivantes :

Router# sh log | redirect ?
bootflash: Uniform Resource Locator
flash: Uniform Resource Locator
ftp: Uniform Resource Locator
harddisk: Uniform Resource Locator
http: Uniform Resource Locator
https: Uniform Resource Locator
nvram: Uniform Resource Locator
tftp: Uniform Resource Locator

Quels débogages peuvent être activés dans les routeurs vocaux

Chaque flux d'appels et type de fonctionnalités (TDM, CUBE ou ressources multimédias SCCP) est différent et vous pouvez activer des débogages spécifiques. Tous les débogages requis doivent être activés en même temps. Lorsqu'un seul débogage est capturé à la fois, il est inefficace et accroît la confusion lors de l'analyse des données.

Les débogages sont activés au niveau de l'invite d'exécution CLI Router#, ce qui nécessite que vous disposiez d'autorisations en mode d'exécution privilégié.

Il existe des débogages de base et avancés. Les débogages de base sont utilisés pour collecter des informations de signalisation dans SIP, H323 ou MGCP, qui montre les conversations du routeur avec ses périphériques homologues.

Les débogages avancés sont très détaillés et sont généralement utilisés pour collecter davantage d'informations en cas d'erreurs internes de pile que les débogages de base ne peuvent pas afficher. Ces débogages sollicitent généralement beaucoup le processeur.

Conseil : Une fois les débogages activés, n'oubliez pas d'exécuter la commande clear logging. Cette commande garantit que la mémoire tampon est effacée pour une capture plus nette des débogages.

Débogage de l'API de contrôle d'appel interne (CCAPI)

À l'intérieur de chaque routeur Cisco IOS/IOS XE, il y a une API de contrôle d'appel qui est responsable de la communication entre différentes applications ou protocoles VoIP et les composants du plan de données, tels que RTP, DSP, cartes vocales, entre autres. Afin de capturer les données de cette couche, il y a un débogage spécifique qui peut être utilisé :

debug voip ccapi inout

Il y a d'autres options pour ce débogage ; cependant, debug voip ccapi inout couvre toutes les informations de base sur le plan de numérotation et l'établissement d'appel qui sont normalement plus que suffisantes pour comprendre quels sont les états de cette couche.

Conseil : debug voip ccapi inout a généralement un impact minimal sur le CPU du routeur et il est recommandé d'activer avec tout débogage de signalisation afin de fournir un ensemble complet de journaux avec des informations sur le ou les appels et ses différents états.

Flux d'appels SIP

Ces débogages sont les plus couramment utilisés pour les flux d'appels SIP. Ils peuvent être activés à l'intérieur des passerelles CUBE et TDM avec un segment SIP entre le routeur et CUCM ou tout autre serveur ou proxy SIP.

Débogages SIP de base

debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.

Débogages SIP avancés

debug ccsip all
debug ccsip verbose
debug voice ccapi inout

Flux d'appels numériques (PRI, BRI)

Ces débogages s'appliquent aux interfaces PRI T1/E1 ou BRI (Basic Rate Interfaces) :

Débogage numérique de base

debug isdn q931

Débogage numérique avancé

debug isdn q921

Flux d'appels analogiques

Ces débogages sont utilisés lorsqu'il y a des circuits analogiques impliqués comme des ports Foreign eXchange Subscriber (FXS) ou Foreign eXchange Office (FXO) :

debug vpm signal
debug voip vtsp all

Flux d'appels MGCP

Ces débogages sont utilisés lorsque MGCP est utilisé comme protocole vocal entre une passerelle vocale et CUCM.

Débogages de base

debug mgcp packets
debug mgcp errors

Débogages de CCM-Manager

Les débogages ccm-manager sont utilisés pour suivre le téléchargement de la configuration, et les messages de liaison MoH et PRI/BRI entre CUCM et la passerelle vocale. Ces débogages sont utilisés en fonction des besoins et dépendent du scénario de défaillance.

debug ccm-manager backhaul !For PRI and BRI Deployments
debug ccm-manager errors
debug ccm-manager events
debug ccm-manager config-download !Troubleshoot Configuration download issues from CUCM TFTP
debug ccm-mananger music-on-hold !Troubleshoot internal MoH Process

Débogages MGCP avancés

debug mgcp all

Flux d'appels H323

Bien que H323 ne soit pas très répandu, il existe encore des déploiements avec H323 configuré :

Débogages H323 de base

debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events

Débogages H323 avancés

debug cch323 h225
debug cch323 h245
debug cch323 all

Ressources multimédias SCCP

Ces débogages sont utilisés pour dépanner les problèmes de ressources multimédias SCCP qui impliquent un point de terminaison multimédias (MTP) ou des transcodeurs enregistrés sur un serveur CUCM :

Débogages SCCP de base

debug sccp messages
debug sccp events
debug sccp errors

Débogage SCCP avancé

debug sccp all

Suivi VoIP

Avec l'introduction de Cisco IOS XE 17.4.1 et 17.3.2, il existe une nouvelle option pour capturer les journaux vocaux à l'intérieur de Cisco Unified Border Element (CUBE). Cette nouvelle fonctionnalité est appelée VoIP Trace. Il s'agit d'un nouveau cadre de facilité de maintenance créé pour consigner la signalisation et les événements SIP sans avoir à activer de débogages. 

VoIP Trace est activé par défaut et peut être désactivé à tout moment si nécessaire. VoIP Trace capture des informations spécifiques pour les appels SIP uniquement :

• Messages SIP pour les appels de liaison SIP à liaison
• Événements et appels API de la couche SIP vers d'autres couches dans CUBE
• Erreurs SIP
• Contrôle d'appel (flux d'appels de communications unifiées traités par CUBE)
• États et événements FSM (Finite State Machines)
• Homologue de numérotation correspondant
• Ports RTP alloués
• Corrélation des erreurs IEC avec la signalisation SIP

Restrictions

VoIP Trace n'enregistre pas les informations relatives aux messages SIP hors dialogue :

• ENREGISTRER
• OPTIONS
• ABONNEMENT/NOTIFICATION
• INFOS

VoIP Trace in HA est pris en charge, mais les mises en garde suivantes s'appliquent :

• Par défaut, VoIP Trace est activé sur le routeur de secours. Seules les traces applicables au processus de veille sont présentées jusqu'à ce qu'il devienne actif.
• Une fois la veille active, elle ne contient PAS les traces complètes des appels avec points de contrôle, mais uniquement les nouveaux appels.
• show voip trace <key> fonctionne toujours sur le routeur de secours et affiche les données du tampon de couverture et du flux multimédia pour les appels.

Activation de la trace VoIP

Comme indiqué, cette fonctionnalité est activée par défaut. La commande permettant d'activer cette fonctionnalité est la suivante :

Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#

Désactivation de la trace VoIP

Pour désactiver cette fonctionnalité, les commandes sont les suivantes :

Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown

Mise en garde : Une fois la fonction VoIP Trace désactivée, toute la mémoire est effacée et les informations perdues.

Les commandes disponibles dans le mode de configuration trace sont les suivantes :

Router(conf-serv-trace)# ?
default       Set a command to its defaults
  exit          Exit from voice service voip trace mode
  memory-limit  Set limit based on memory used
  no            Negate a command or set its defaults
  shutdown      Shut Voip Trace debugging

Configurer la limite de mémoire

La limite de mémoire détermine la quantité de mémoire utilisée par VoIP Trace pour stocker les données. Par défaut, elle représente 10 % de la mémoire disponible sur la plate-forme, mais elle peut être modifiée pour atteindre un maximum de 1 Go et un minimum de 10 Mo. La mémoire est allouée de manière dynamique, ce qui signifie que la fonctionnalité utilise uniquement la mémoire nécessaire et dépend du volume d'appels. Une fois qu'il a atteint la mémoire maximale disponible, il tourne autour et supprime les entrées plus anciennes.

Lorsque la limite de mémoire est modifiée pour être supérieure à la mémoire disponible de 10 %, un message s'affiche dans l'interface de ligne de commande :

Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.

Pour définir la valeur par défaut à 10% d'utilisation de la mémoire, la commande memory-limit platform peut être utilisée :

Router(conf-serv-trace)# memory-limit platform
 Reducing the memory-limit clears all VoIP Trace statistics and data.
 If you wish to copy this data first, enter 'no' to cancel,
 otherwise enter 'yes' to proceed. Continue? [no]: 

Mise en garde : Lorsque la limite de mémoire est réduite, toutes les données VoIP Trace sont perdues. Une sauvegarde des données doit être collectée avant que la mémoire ne soit réduite.

Affichage des données de suivi VoIP

Pour afficher les données de VoIP Trace, vous devez utiliser des commandes show spécifiques. Les données peuvent être affichées dans la même session de terminal ou peuvent également être envoyées via syslog à un serveur syslog hors-box.

Remarque : Les traces sont vidées 32 secondes après la réception d'un BYE pour un appel.

Remarque : La signalisation SIP est affichée par segment et n'est pas combinée comme des débogages standard. Les débogages réguliers, tels que les messages de débogage CCSIP, affichent la signalisation SIP d'un appel dans l'ordre exact des événements. Dans VoIP Trace, chaque branche est distincte. Pour déterminer le bon ordre, les horodatages sont utilisés.

Les commandes disponibles pour afficher les données sont les suivantes :

Router# show voip trace ?
  all            Display all VoIP Traces
  call-id        Filter traces based on Internal Call Id
  correlator     Filter traces based on FPI Correlator
  cover-buffers  Display the summary of all cover buffers
  session-id     Filter traces based on SIP Session ID
  sip-call-id    Filter traces based on SIP Call Id
  statistics     Display statistics for VoIP Trace

Show VoIP Trace All

Cette commande affiche toutes les données de trace VoIP disponibles dans la mémoire tampon. L’utilisation de cette commande a un impact sur les performances du routeur. Une fois la commande entrée, un message d'avertissement s'affiche pour alerter sur le risque et confirmer la poursuite :

Router# show voip trace all
 Displaying 11858 cover buffers
 This may severely impact system performance.
 Continue? [yes/no] no 

Show VoIP Trace Cover-Buffers

Cette commande affiche une vue d'ensemble des détails de tous les appels signalés sous VoIP Trace. Chaque tronçon d'appel est doté d'une mémoire tampon de couverture qui contient un résumé de l'appel consigné.

Router# show voip trace cover-buffers
------------------ Cover Buffer ---------------
Search-key = 8845:3002:659
Timestamp = *Sep 30 01:17:33.615
Buffer-Id = 1
CallID = 659
Peer-CallID = 661
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 20857880-1ec12085-13b930-411b300a@10.48.27.65
SIP Session ID = 2b1289c400105000a0002c3ecf872659
GUID = 208578800000
-----------------------------------------------

------------------ Cover Buffer ---------------
Search-key = 8845:3002:661
Timestamp = *Sep 30 01:17:33.634
Buffer-Id = 2
CallID = 661
Peer-CallID = 659
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 8D6DEC28-1F111EB-829FD797-1B22F6DB@10.48.55.11
SIP Session ID = 0927767800105000a0005006ab805584
GUID = 208578800000
-----------------------------------------------

Pour plus d'informations sur chaque champ, reportez-vous au tableau suivant :

Afin de filtrer les tampons de couverture, vous pouvez utiliser les commandes include et section :

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
!or
Router# show voip trace cover-buffers | section Search-key | 8845 | 3002
Search-key = 8845:3002:661

Show VoIP Trace Call-Id

En combinaison avec la commande précédente, show voip trace call-id peut être utilisé pour trouver les appels. Une fois que l'ID d'appel a été identifié, cette commande peut être utilisée pour afficher toutes les informations relatives à la branche d'appel spécifique :

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661

Afficher les statistiques de suivi VoIP

Cette commande show affiche des informations détaillées sur l'état, la consommation de mémoire, les appels en erreur ou en panne, les appels réussis, les horodatages des entrées les plus récentes et les plus anciennes, etc.

Router# show voip trace statistics
VoIP Trace Statistics
Tracing status             : ENABLED at *Sep 12 06:44:02.349
Memory limit configured    : 803209216 bytes
Memory consumed            : 254550928 bytes (31%)
Total call legs dumped     : 2
Oldest trace dumped        : *Sep 12 07:29:21.077 Search-key: 9898:30000:64
Latest trace dumped        : *Sep 12 07:29:21.010 Search-key: 9898:30000:63
Total call legs captured   : 11858
Total call legs available  : 11858
Oldest trace available     : *Sep 12 06:57:23.923, Search-key: 5250001:4720001:11
Latest trace available     : *Sep 13 05:08:25.353, Search-key: 19074502232:30000:13177
Total traces missed        : 0

Pour plus d'informations sur chaque champ, reportez-vous au tableau suivant :

Commandes show supplémentaires