Introduction

Ce document présente des techniques de base et des commandes pour dépanner et déboguer les réseaux VoIP. Un aperçu du flux d’appels vocaux et de l’architecture de téléphonie dans un routeur Cisco est présenté, suivi d’une approche de dépannage VoIP étape par étape présentée dans ces étapes:

1. Vérifiez la signalisation numérique et analogique .

2. Vérifiez les chiffres reçus et envoyés depuis les ports vocaux analogiques et numériques.

3. Vérifiez la signalisation VoIP de bout en bout.

4. Comprendre les problèmes de qualité de service (QoS) VoIP.

5. Comprendre les détails des codes de cause et des valeurs de débogage pour VoIP.

Remarque:  Ce document n’explique pas chaque facette de l’architecture Cisco IOS® utilisée dans les passerelles et les contrôleurs d’accès VoIP Cisco. Au lieu de cela, il est destiné à montrer quelles commandes peuvent être utilisées et quels champs des sorties de commande peuvent être les plus précieux.

 Attention: le  débogage de Cisco IOS peut être gourmand en ressources processeur. Soyez prudent lorsque vous utilisez les débogages répertoriés dans ce document. Pour plus d’informations, reportez-vous à Informations importantes sur les commandes de débogage .

Les débogages doivent être exécutés avec les horodatages activés dans le journal. Activez l’horodatage en ajoutant les commandes suivantes: les horodatages de service déboguent la msec datetime , les horodatages du service enregistrent la msec datetime en mode d’activation. Les horodatages aident à déterminer l’intervalle de temps entre les changements d’état.

Conditions préalables

Exigences

Ce document est destiné au personnel des réseaux impliqués dans la conception et le déploiement des réseaux VoIP. Les lecteurs de ce document doivent connaître ces sujets:

• Configuration VoIP

• Voix QoS

Composants utilisés

Ce document n’est pas limité à des versions de logiciel et de matériel spécifiques. Cependant, les sorties montrées sont basées sur la version de logiciel 12.3 (8) de Cisco IOS®.

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 en direct, assurez-vous de comprendre l’impact potentiel de toute commande avant de l’utiliser.

Conventions

Pour plus d’informations sur les conventions des documents, reportez-vous aux Conventions des conseils techniques Cisco .

Flux d’appels dans le réseau

Un facteur important à prendre en compte avant de commencer tout dépannage ou débogage VoIP est que les appels VoIP sont constitués de trois segments d’appel. Ces tronçons d’appel sont la source Plain Old Telephone Systems (POTS), VoIP et POTS de destination. Ceci est illustré dans ce diagramme. Le dépannage et le débogage doivent d’abord se concentrer sur chaque tronçon indépendamment, puis sur l’appel VoIP dans son ensemble.

Flux d’appels du routeur

Ces définitions expliquent la fonction des principaux composants affichés dans le diagramme de flux d’appels du routeur:

API de contrôle des appels (Application Programming Interface) – Trois clients utilisent l’API de contrôle des appels. Les trois clients sont la CLI, l’agent SNMP (Simple Network Management Protocol) et l’application de session. Les principales fonctions de l’API de contrôle des appels (également appelées CCAPI) sont les suivantes:

• Identifiez les segments d’appel (par exemple, de quel pair de numérotation s’agit-il? D’où vient-il?).

• Décidez quelle application de session prend l’appel (par exemple, qui le gère?).

• Appelez le gestionnaire de paquets.

• Mettez en conférence les segments d’appel ensemble.

• Commencez à enregistrer les statistiques d’appels.

Application de session et mappeur de plan de numérotation : l’application de session utilise le mappeur de plan de numérotation pour mapper un numéro à un homologue de numérotation (POTS local ou VoIP distant). Le mappeur de plan de numérotation utilise la table des homologues de numérotation pour rechercher les homologues de numérotation actifs.

Interface de fournisseur de services de téléphonie et de VoIP (SPI) —Le SPI de téléphonie communique avec les homologues de numérotation POTS (analogiques: fxs, fxo, e & m Digital: isdn, qsig, e & m, etc.). Le VoIP SPI est l’interface spécifique aux pairs VoIP. Les pilotes de téléphonie / DSP fournissent des services au SPI de téléphonie tandis que le SPI VoIP repose sur des protocoles de session.

Architecture d’interface de téléphonie

Ce diagramme montre l’architecture des blocs de construction de téléphonie de routeur Cisco et comment ils interagissent entre eux.

Cette liste décrit les fonctions et les définitions des principaux composants du diagramme:

• Interface de programmation d’application de contrôle d’appel (CCAPI) – Entité logicielle qui établit, termine et relie les segments d’appel.

• Fournisseur de service de téléphonie vocale (VTSP) – Processus IOS qui traite les demandes de l’API de contrôle d’appel et formule les demandes appropriées au processeur de signal numérique (DSP) ou au VPM.

• Module de processeur vocal (VPM) – Le VPM est chargé de relier et de coordonner les processus de signalisation entre la machine à états de signalisation des ports de téléphonie (SSM), le gestionnaire de ressources DSP et le VTSP.

• Gestionnaire de ressources DSP – Le DSPRM fournit des interfaces par lesquelles le VTSP peut envoyer et recevoir des messages vers et depuis les DSP.

• Packet Handler – Le gestionnaire de paquets transfère les paquets entre les DSP et les segments Peer Call.

• Appeler l’homologue : l’ homologue d’ appel est la branche d’appel opposée. Cela peut être une autre connexion vocale de téléphonie (POTS), VoFR, VoATM ou une connexion VoIP.

Vérifier la signalisation numérique et analogique (POTS Call-Leg)

Les objectifs de la vérification de la signalisation numérique et analogique sont les suivants:

• Vérifiez que la bonne signalisation analogique ou numérique raccroché et décroché est reçue.

• Vérifiez que la signalisation E&M, FXO et FXS appropriée est configurée à la fois sur le routeur et le commutateur (CO ou PBX).

• Vérifiez que les DSP sont en mode de collecte de chiffres.

Les commandes décrites dans ces sections peuvent être utilisées pour vérifier la signalisation.

show controllers T1 / E1 (numérique)

show controllers t1 [slot / port] – Utilisez cette commande en premier. Il montre si la connexion numérique T1 entre le routeur et le commutateur (CO ou PBX) est en haut ou en bas et si elle fonctionne correctement. La sortie de cette commande ressemble à ceci:

router # show controllers T1 1/0 
T1 1/0 est en place. 
Le type d'applique est T1 
canalisé. La longueur de câble est courte. 133 Aucune alarme détectée. 
Le cadrage est ESF, le code de ligne est B8ZS, la source d'horloge est la ligne 
principale. 
Données dans l'intervalle actuel (6 secondes écoulées): 
	0 violations de code de ligne, 0 violations de code de chemin 0 secondes de 
	glissement, 0 secondes de perte de fr 
	, 0 secondes d'erreurs de ligne, 
  0 minutes dégradées 0 secondes d'erreur, 0 secondes d'erreurs en rafale, 0 secondes d'erreurs graves, 
  0 Secs non disponibles

Si vous utilisez E1, utilisez la commande show controllers e1 . Pour plus d’informations, reportez-vous à:

• Dépannage de la couche 1 T1

• Organigramme de dépannage T1

• Dépannage des problèmes de ligne série

afficher le port vocal

show voice port slot-number / port: utilisez cette commande pour afficher l’état du port et les paramètres configurés sur le port vocal des cartes d’interface vocale Cisco (VIC). Comme toutes les commandes IOS, les valeurs par défaut ne s’affichent pas dans show running-config , mais elles s’affichent avec cette commande.

Voici un exemple de sortie pour un port vocal E&M:

router # show voice port 1/0: 1 
RecEive and TransMit Slot est 1, Sub-unit is 0, Port is 1 Type of VoicePort is E&M 
Operation State is DORMANT 
Administrative State is UP 
Aucune interface Down Failure 
Description n'est pas définie 
La régénération du bruit est activé 
Le traitement non linéaire est activé 
Le seuil de mise en attente de la musique 
est réglé sur -38 dBm Le gain d' entrée est réglé sur 0 dB L' 
atténuation de sortie est réglée sur 0 dB L' 
annulation de l'écho est activée La couverture d'annulation de l'écho est réglée sur 16 ms 
Le mode de connexion est normal 
Le numéro de connexion n'est pas set 
Initial Time Out est réglé sur 10 s Interdigit Time Out est réglé sur 10 s 
Call-Disconnect Time Out est réglé sur 60 s



Tone Région est pour US
 
Infos spécifiques de la carte vocale suivante: 
Out Affaiblissement est réglé sur 0 dB 
Annulation d' écho est activée 
Echo Annuler La couverture est fixée à 16 ms en mode de connexion est normal (pourrait être tronc ou APRA) 
Connexion Numéro n'est pas réglé 
initial Time Out est réglé sur 10 s 
Interdigit Time Out est réglé sur 10 s 
Le délai de déconnexion d'appel est réglé sur 60 s La 
tonalité de région est définie pour les 
informations spécifiques à la carte vocale américaine.Les informations suivantes: Le type de signal est clignotement-démarrage 
Le type d'opération est 2 fils Le type 
E&M est 1 Le 
type de numérotation est dtmf 
En saisie La saisie est inactive La 
saisie en sortie est inactive La 
durée du chiffre est réglée sur 100 ms




InterDigit Duration Timing est réglé sur 100 ms 
Pulse Rate Timing est réglé sur 10 impulsions / seconde 
InterDigit Pulse Duration Timing est réglé sur 500 ms 
Clear Wait Duration Timing est réglé sur 400 ms 
Wink Wait Duration Timing est réglé sur 200 ms 
Wink Duration Timing est réglé à 200 ms 
La temporisation de démarrage différé est réglée sur 300 ms 
Durée de retard La temporisation est réglée à 2000 ms 
Cadran Pulse Min. Le délai est réglé sur 140 ms

debug vpm (module de processeur vocal)

Ces commandes sont utilisées pour déboguer l’interface de téléphonie VPM:

• debug vpm signal – Cette commande est utilisée pour collecter des informations de débogage pour les événements de signalisation et peut être utile pour résoudre les problèmes de signalisation vers un PBX.

• debug vpm spi – Cette commande trace la façon dont l’interface du fournisseur de services du module de port vocal (SPI) s’interface avec l’API de contrôle d’appel. Cettecommande de débogage affiche des informations sur la manière dont chaque indication de réseau et chaque demande d’application sont traitées.

• debug vpm dsp – Cette commande affiche les messages du DSP sur le VPM vers le routeur et peut être utile si vous pensez que le VPM n’est pas fonctionnel. Il s’agit d’un moyen simple de vérifier si le VPM répond aux indications de décrochage et d’évaluer la synchronisation des messages de signalisation depuis l’interface.

• debug vpm all – Cette commande EXEC active toutes les commandes de debug vpm : debug vpm spi , debug vpm signal et debug vpm dsp .

• debug vpm port – Utilisez cette commande pour limiter la sortie de débogage à un port particulier. Par exemple, cette sortie affiche lesmessages de débogage vpm dsp uniquement pour le port 1/0/0:

  debug vpm dsp 
  
  debug vpm port 1/0/0

  Pour plus d’informations, reportez-vous aux commandes de débogage VoIP .

Exemple de sortie pour la commande de signal de débogage vpm

maui-voip-austin # debug vpm signal 

! --- Le port FXS 1/0/0 passe de l'état "raccroché" à "décroché"! ---. 
htsp_process_event: [1/0/0, 1.2, 36] fxsls_onhook_offhook htsp_setup_ind 
* 10 mars 16: 08: 55.958: htsp_process_event: 
[1/0/0, 1.3, 8] ! --- Envoie une alerte de sonnerie au téléphone appelé. 
* 10 mars 16: 09: 02.410: htsp_process_event: 
[1/0/0, 1.3, 10] htsp_alert_notify 
* 10 mars 16: 09: 03.378: htsp_process_event: 
[1/0/0, 1.3, 11] ! --- Fin d'appel téléphonique, le port passe "raccroché". 
* 10 mars 16: 09: 11.966: htsp_process_event: 
[1/0/0, 1.3, 6] 
* 10 mars 16: 09: 17.218: htsp_process_event: 
[1/0/0, 1.3, 28] fxsls_offhook_onhook











* 10 mars 16: 09: 17.370: htsp_process_event: 
[1/0/0, 1.3, 41] fxsls_offhook_timer 
* 10 mars 16: 09: 17.382: htsp_process_event: 
[1/0/0, 1.2, 7] fxsls_onhook_release

Si le raccroché et le décroché ne signalent pas correctement, vérifiez les éléments suivants:

• Vérifiez que le câblage est correct.

• Vérifiez que le routeur et le commutateur (CO ou PBX) sont correctement mis à la terre.

• Vérifiez que les deux extrémités de la connexion ont des configurations de signalisation correspondantes. Des configurations non concordantes peuvent entraîner une signalisation incomplète ou unidirectionnelle.

Pour plus d’informations sur le dépannage E&M, reportez-vous à Compréhension et dépannage des types d’interfaces analogiques E&M et des dispositions de câblage.

Exemple de sortie pour le débogage VPM de commande

maui-voip-austin # debug vpm spi    
Le débogage de session du module de port vocal est activé ! --- Le DSP est mis en mode de collecte de chiffres. 
* Mar 10 16: 48: 55.710: dsp_digit_collect_on: 
[1/0/0] packet_len = 20 channel_id = 128 
 packet_id = 35 min_inter_delay = 290 
 max_inter_delay = 3200 mim_make_time = 18 max_make 
_time = 75 min_brake_time = 18 max_brake

Vérifier les chiffres reçus et envoyés (appel POTS)

Une fois que la signalisation raccroché et décroché est vérifiée et fonctionne correctement, vérifiez que les chiffres corrects sont reçus ou envoyés sur le port vocal (numérique ou analogique). Un homologue de numérotation ne correspond pas ou le commutateur (CO ou PBX) ne peut pas faire sonner la bonne station si des chiffres incomplets ou incorrects sont envoyés ou reçus. Certaines commandes qui peuvent être utilisées pour vérifier les chiffres reçus / envoyés sont:

• show dialplan number – Cette commande est utilisée pour montrer quel homologue de numérotation est atteint lorsqu’un numéro de téléphone particulier est composé.

• debug vtsp session – Cette commande affiche des informations sur le traitement de chaque indication de réseau et demande d’application, les indications de signalisation et les messages de contrôle DSP.

• debug vtsp dsp – Plus tôt que la version 12.3 du logiciel Cisco IOS, cette commande affiche les chiffres au fur et à mesure qu’ils sont reçus par le port vocal. Cependant, dans le logiciel Cisco IOS version 12.3 et ultérieure, la sortie de lacommande de débogage n’affiche plus les chiffres. La combinaison des détails de débogage hpi et de la notification de débogage hpi peut être utilisée pour voir les chiffres entrants.

• debug vtsp all – Cette commande active ces commandes de débogage du fournisseur de services de téléphonie vocale (VTSP): debug vtsp session , debug vtsp error et debug vtsp dsp .

Pour plus d’informations, reportez-vous aux commandes de débogage VoIP .

afficher le numéro du plan de numérotation

show dialplan number < digit_string > – Cette commande affiche l’homologue de numérotation qui correspond à une chaîne de chiffres. Si plusieurs homologues de numérotation peuvent être mis en correspondance, ils sont tous affichés dans l’ordre dans lequel ils sont mis en correspondance.

Remarque:  Vous devez utiliser le signe # à la fin des numéros de téléphone pour les pairs de numérotation de longueur variable afin de faire correspondre les modèles de destination qui se terminent par T.

La sortie de cette commande ressemble à ceci:

maui-voip-austin # show dialplan number 5000 
Terminaison de la chaîne de numérotation: # 
Macro Exp .: 5000 

VoiceOverIpPeer2 
        information type = voice,         tag = 2, destination-pattern = `5000 ', 
        answer-address =`', preference = 0, 
        group = 2, l' état de l'administrateur est activé, l' 
        état de fonctionnement est activé, 
        numéro appelé entrant = `` ', 
        connexions / maximum = 0 / illimité, 
        application associée: type = voip, session-target = 
        `ipv4: 192.168.10.2' , 
        préfixe technologique : ip precedence = 5 , somme de contrôle UDP = 
        désactivé, session-protocol = cisco,

        
        
        req-qos = best-effort, 
        acc-qos = best-effort, 
        dtmf-relay = cisco-rtp, fax-rate = voix,    
        taille de la charge utile = 20 octets 
        codec = g729r8, 
        taille de la charge utile = 20 octets , 
        facteur d' attente    = 10, Icpif = 30, 
        type de signalisation = cas, VAD = activé , piège QOV médiocre = désactivé, 
        temps de connexion = 25630, unités chargées = 0, 
        appels réussis = 25, appels échoués = 0, 
        appels acceptés = 25, appels refusés = 0, 
        La cause de la dernière déconnexion est "10", le 
        dernier texte de déconnexion correspond à la " 
        suppression d' appel normale ". 
        Heure de la dernière configuration = 84427934.
        
        
        Correspondance: 5000 chiffres: 4 
        Cible: ipv4: 192.168.10.2

debug vtsp session

La commande debug vtsp session affiche des informations sur la manière dont le routeur interagit avec le DSP en fonction des indications de signalisation de la pile de signalisation et des demandes de l’application. Cette commande de débogage affiche des informations sur la manière dont chaque indication de réseau et demande d’application est traitée, les indications de signalisation et les messages de contrôle DSP.

maui-voip-austin # debug vtsp  
session Le débogage de session de contrôle d'appel de téléphonie vocale est activé ! --- La sortie est supprimée. ! --- ACTION: l'appelant a décroché le combiné. ! --- Le DSP est alloué, les tampons de gigue, les seuils VAD! --- et les niveaux de signal sont définis. 
* 10 mars 18: 14: 22.865: dsp_set_playout : [1/0/0 (69)] 
packet_len = 18 channel_id = 1 packet_id = 76 mode = 1 initial = 60 min = 4 max = 200 fax_nom = 300 
* 10 mars 18: 14: 22.865: dsp_echo_canceller_control : 
[1/0/0 (69)] packet_len = 10 channel_id = 1 packet_id = 66 
flags = 0x0 
* 10 mars 18: 14: 22.865: dsp_set_gains : [1/0/0 (69)] 
packet_len = 12 channel_id = 1 packet_id = 91 in_gain = 0 out_gain = 65506







* 10 mars 18: 14: 22.865: dsp_vad_enable : [1/0/0 (69)] 
packet_len = 10 channel_id = 1 packet_id = 78 thresh = -38 act_setup_ind_ack 
* 10 mars 18: 14: 22.869: dsp_voice_mode : [1/0 / 0 (69)] 
packet_len = 24 channel_id = 1 packet_id = 73 coding_type = 1 
 voice_field_size = 80 VAD_flag = 0 echo_length = 64 comfort_noise = 1  
inband_detect = 1 digit_relay = 2 
AGC_flag = 0act_setup_ind_ode_ack (): dsp_dup_setru_m_sport (): dsp_dup_setru_def 
() 0, 
no_auto_switchover = 0dsp_dtmf_mode 
(VTSP_TONE_DTMF_MODE) ! --- Le DSP est mis en "mode vocal" et la tonalité est! --- générée. 
* 10 mars 18: 14: 22.873: dsp_cp_tone_on

 




: [1/0/0 (69)] 
packet_len = 30 channel_id = 1 packet_id = 72 tone_id = 4 
n_ freq = 2 freq_of_first = 350 freq_of_second = 440 amp_of_first = 
4000 amp_of_second = 4000 direction = 1 on_time_first = 65535 
off_time_first = 0 on_time_first = 65535 off_time_first = 0 on_time 
_second = 65535 off_time_second = 0

S’il est déterminé que les chiffres ne sont pas envoyés ou reçus correctement, il peut alors être nécessaire d’utiliser un capteur de chiffres (outil de test) ou un testeur T1 pour vérifier que les chiffres sont envoyés à la fréquence et à l’intervalle de temps corrects. S’ils sont envoyés « incorrectement » pour le commutateur (CO ou PBX), certaines valeurs sur le routeur ou le commutateur (CO ou PBX) peuvent éventuellement devoir être ajustées afin qu’elles correspondent et puissent interagir. Il s’agit généralement de valeurs de durée numérique et de durée inter-chiffres. Un autre élément à examiner si les chiffres semblent être envoyés correctement sont les tables de traduction de nombres dans le commutateur (CO ou PBX) qui peuvent ajouter ou supprimer des chiffres.

Vérifier la signalisation VoIP de bout en bout (VOIP Call-Leg)

Après avoir vérifié que la signalisation du port vocal fonctionne correctement et que les chiffres corrects sont reçus, passez au dépannage et au débogage du contrôle d’appel VoIP. Ces facteurs expliquent pourquoi le débogage du contrôle des appels peut devenir un travail complexe:

• Les passerelles VoIP Cisco utilisent la signalisation H.323 pour terminer les appels. H.323 est composé de trois couches de négociation d’appel et d’établissement d’appel: H.225, H.245 et H.323. Ces protocoles utilisent une combinaison de TCP et UDP pour configurer et établir un appel.

• Le débogage VoIP de bout en bout montre un certain nombre de machines d’état IOS. Les problèmes avec n’importe quelle machine d’état peuvent provoquer l’échec d’un appel.

• Le débogage VoIP de bout en bout peut être très détaillé et créer beaucoup de sortie de débogage.

debug voip ccapi inout

La commande principale pour déboguer les appels VoIP de bout en bout est debug voip ccapi inout . La sortie d’un débogage d’appel est affichée dans cette sortie.

! --- Action: Un appel VoIP est émis via le! --- Telephony SPI (potars leg) vers l'extension 5000.! --- Certaines sorties sont omises. 


maui-voip-austin # debug voip ccapi inout 
voip fonction ccAPI entrée / sortie le débogage est activé ! --- Identification de la jambe d'appel, pair source: Appel! --- provient des pots du cadran-pair 1! --- (extension 4000) . 
* 15 mars 22: 07: 11.959: cc_api_call_setup_ind
(vdbPtr = 0x81B09EFC, callInfo = {appelé =, 
appelant = 4000, fdest = 0 peer_tag = 1 }, callID = 0x81B628F0)
 ! --- CCAPI appelle l'application de session. * 15 mars 22: 07: 11.963: cc_process_call_setup_ind 
(event = 0x81B67E44) a transmis un appel à l'application "SESSION" 
* 15 mars 22: 07: 11.963: sess_appl:









ev (23 = CC_EV_CALL_SETUP_IND), cid (88), disp (0) ! --- Allouer les identificateurs de jambe d'appel "callid = 0x59" 
* 15 mars 22: 07: 11.963: ccCallSetContext 
( callID = 0x58 , context = 0x81BAF154) 
* Mar 15 22: 07: 11.963: ccCallSetupAck 
( callID = 0x58 ) ! --- Demandez à VTSP de générer une tonalité . * 15 mars 22: 07: 11.963: ccGenerateTone 
(callID = 0x58 tone = 8) ! --- VTSP transmet les chiffres à CCAPI. 
* 15 mars 22: 07: 20.275: cc_api_call_digit_begin 
(vdbPtr = 0x81B09EFC, callID = 0x58, digit = 5, flags = 0x1, horodatage = 0xC2E63BB7, expiration = 0x0) 
* 15 mars 22: 07: 20.279: sess_appl: 
ev (10 = CC_EV_CALL_DIGIT_BEGIN), cid (88), disp (0)
















* 15 mars 22: 07: 20.279: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1) csize (0) in (1) fDest (0) 
* 15 mars 22: 07: 20.279: ssaIgnore cid (88), 
st (0), oldst (0), ev (10) * 15 mars 22: 07: 20.327: cc_api_call_digit 
(vdbPtr = 0x81B09EFC, callID = 0x58, chiffre = 5 
, durée = 100) 
* 15 mars 22 : 07: 20.327: sess_appl: 
ev (9 = CC_EV_CALL_DIGIT), cid (88), disp (0) 
* 15 mars 22: 07: 20.327: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1 ) csize (0) in (1) fDes 
t (0) 
* 15 mars 22: 07: 21.975: cc_api_call_digit_begin 
(vdbPtr = 0x81B09EFC, callID = 0x58, digit = 0, 
flags = 0x1, timestamp = 0xC2E63BB7, expiration = 0x0) 
* 15 mars 22: 07: 21.979: sess_appl: 
ev (10 = CC_EV_CALL_DIGIT_BEGIN), cid (88), disp (0)

* 15 mars 22: 07: 21.979: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1) csize (0) in (1) fDes 
t (0) 
* 15 mars 22: 07: 21.979: ssaIgnore cid (88), 
st (0), oldst (0), ev (10) * 15 mars 22: 07: 22.075: cc_api_call_digit 
(vdbPtr = 0x81B09EFC, callID = 0x58, chiffre = 0 
, durée = 150) 
* 15 mars 22: 07: 22.079: sess_appl: 
ev (9 = CC_EV_CALL_DIGIT), cid (88), disp (0) 
* 15 mars 22: 07: 22.079: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (- 1) csize (0) in (1) fDest (0) 
* 15 mars 22: 07: 23.235: cc_api_call_digit_begin 
(vdbPtr = 0x81B09EFC, callID = 0x58, dgit = 0, 
flags = 0x1, horodatage = 0xC2E63BB7, expiration = 0x0) 
* 15 mars 22: 07: 23.239: sess_appl: 
ev (10 = CC_EV_CALL_DIGIT_BEGIN), cid (88), disp (0)

* 15 mars 22: 07: 23.239: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1) csize (0) in (1) fDest (0) 
* 15 mars 22: 07: 23.239: ssaIgnore cid (88), 
st (0), oldst (0), ev (10) * 15 mars 22: 07: 23.335: cc_api_call_digit 
(vdbPtr = 0x81B09EFC, callID = 0x58, chiffre = 0 
, durée = 150) 
* 15 mars 22 : 07: 23.339: sess_appl: 
ev (9 = CC_EV_CALL_DIGIT), cid (88), disp (0) 
* 15 mars 22: 07: 23.339: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1 ) csize (0) in (1) fDes 
t (0) 
* Mar 15 22: 07: 25.147: cc_api_call_digit_begin 
(vdbPtr = 0x81B09EFC, callID = 0x58, d 
igit = 0, flags = 0x1, horodatage = 0xC2E63BB7, 
expiration = 0x0) 
* 15 mars 22: 07: 25.147: sess_appl:

ev (10 = CC_EV_CALL_DIGIT_BEGIN), cid (88), disp (0) 
* 15 mars 22: 07: 25.147: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1) csize (0) dans ( 1) fDest (0) 
* 15 mars 22: 07: 25.147: ssaIgnore cid (88), 
st (0), oldst (0), ev (10) * 15 mars 22: 07: 25.255: cc_api_call_digit 
(vdbPtr = 0x81B09EFC, callID = 0x58, digit = 0 
, duration = 160) 
* 15 mars 22: 07: 25.259: sess_appl: 
ev (9 = CC_EV_CALL_DIGIT), cid (88), disp (0) 
* 15 mars 22: 07: 25.259: ssaTraceSct: 
cid (88) st (0) oldst (0) cfid (-1) csize (0) in (1) fDest (0) ! --- Voip de cadran-pair 2 apparié. Numéro de destination! --- 5000 * 15 mars 22: 07: 25.259: ssaSetupPeer cid (88) 
peer list: tag (2) numéro appelé (5000) 
* 15 mars 22: 07: 25.259: ssaSetupPeer cid (88),






 
destPat (5000) , matched (4), prefix (), 
peer (81C04A10) ! --- Continuez à appeler une interface et démarrez le! --- prochain appel. * 15 mars 22: 07: 25.259: ccCallProceeding 
(callID = 0x58 , prog_ind = 0x0)
 * 15 mars 22: 07: 25.259: ccCallSetupRequest 
(appel entrant = 0x58, pair sortant = 2, 
dest =, params = 0x81BAF168 mode = 0, 
* callID = 0x81B6DE58) 
* 15 mars 22: 07: 25.259: callNumber = 4000, 
calledNumber = 5000 , redirectNumber = ! --- Configuration d'appel VoIP. * 15 mars 22: 07: 25.263: ccIFCallSetupRequest: 
(vdbPtr = 0x81A75558, dest =, callParams = {appelé = 5000, appelant = 4000, 
fdest = 0, voice_peer_tag = 2} , mode = 0x0)













* 15 mars 22: 07: 25.263: ccCallSetContext 
(callID = 0x59 , context = 0x81BAF3E4) 
* 15 mars 22: 07: 25.375: ccCallAlert 
(callID = 0x58, prog_ind = 0x8, sig_ind = 0x1) ! --- POTS et appel VoIP les jambes sont liées ensemble. * 15 mars 22: 07: 25.375: ccConferenceCreate 
(confID = 0x81B6DEA0, callID1 = 0x58, callI 
D2 = 0x59, tag = 0x0) * 15 mars 22: 07: 25.375: cc_api_bridge_done  
(confID = 0x1E, srcIF = 0x81B09EFC, srcCall ID = 0x81B09EFC, srcCall ID 0x58, dstCallID = 0x59 , disposition = 0, 
tag = 0x0) ! --- Capacité d'échange de masques de bits avec la télécommande! --- la passerelle VoIP! --- (Codec, VAD, VoIP ou FAX, taux de FAX, etc. ). * 15 mars 22: 07: 26.127: cc_api_caps_ind 
(dstVdbPtr = 0x81B09EFC,













dstCallId = 0x58, src 
CallId = 0x59, caps = {codec = 0x4, fax_rate = 0x2, 
vad = 0x2, modem = 0x1 codec_bytes = 20, 
signal_type = 0}) 

! --- Les deux passerelles s'accordent sur les capacités. * 15 mars 22: 07: 26.127: cc_api_caps_ack 
(dstVdbPtr = 0x81B09EFC, dstCallId = 0x58, src CallId = 0x59, caps = {codec = 0x4, fax_rate = 0x2, 
vad = 0x2, modem = 0x1 codec_bytes = 20, 
signal_type = 0} ) * 15 mars 22: 07: 26.139: cc_api_caps_ack  
(dstVdbPtr = 0x81A75558, dstCallId = 0x59 , src
 CallId = 0x58, caps = {codec = 0x4, fax_rate = 0x2, 
vad = 0x2, modem = 0x1 codec_bytes = 20, 
signal_type = 0 }) 
* 15 mars 22: 07: 35.259: cc_api_call_digit 
(vdbPtr = 0x81B09EFC, callID = 0x58, digit = T





, durée = 0) 
* 15 mars 22: 07: 35.259: sess_appl: 
ev (9 = CC_EV_CALL_DIGIT), cid (88), disp (0) 
* 15 mars 22: 07: 35.259: ssaTraceSct: 
cid (88) st (4 ) oldst (3) cfid (30) csize (0) dans (1) 
fDest (0) -cid2 (89) st2 (4) oldst2 (1) * 15 mars 22: 07: 35.399: cc_api_call_connected 
(vdbPtr = 0x81A75558, callID = 0x59) 
* 15 mars 22: 07: 35.399: sess_appl: 
ev (8 = CC_EV_CALL_CONNECTED), cid (89), disp (0) 
* 15 mars 22: 07: 35.399: ssaTraceSct: 
cid (89) st (4) oldst (1) cfid (30) csize (0) in (0) 
fDest (0) -cid2 (88) st2 (4) oldst2 (4) ! --- L'appel VoIP est connecté. * 15 mars 22: 07: 35.399: ccCallConnect 
(callID = 0x58) ! --- L'appel VoIP est déconnecté. Cause = 0x10 * 15 mars 23: 29: 39.530: ccCallDisconnect






 



 


(callID = 0x5B, cause = 0x10 tag = 0x0)

Si l’appel échoue et que la cause semble être dans la partie VoIP de l’établissement de l’appel, vous devrez peut-être examiner la partie TCP H.225 ou H.245 de l’établissement de l’appel, par opposition à la seule partie UDP du Configuration H.323. Les commandes qui peuvent être utilisées pour déboguer la configuration d’appel H.225 ou H.245 sont:

• debug ip tcp transactions et debug ip tcp packet – Ces commandes examinent la partie TCP de la négociation H.225 et H.245. Ils renvoient les adresses IP, les ports TCP et les états des connexions TCP.

• debug cch323 h225 – Cette commande examine la partie H.225 de la négociation d’appel et trace la transition d’état de la machine à états H.225 en fonction de l’événement traité. Considérez cela comme la partie de couche 1 de l’établissement d’appel H.323 en trois parties.

• debug cch323 h245 – Cette commande examine la partie H.245 de la négociation d’appel et trace la transition d’état de la machine à états H.245 en fonction des événements traités. Considérez cela comme la partie de la couche 2 de l’établissement d’appel H.323 en trois parties.

Comprendre les problèmes de qualité de service (QoS) VoIP

Lorsque les appels VoIP sont correctement établis, l’étape suivante consiste à vérifier que la qualité vocale est bonne. Bien que le dépannage de la qualité de service ne soit pas couvert dans ce document, ces directives doivent être prises en compte pour obtenir une bonne qualité vocale:

• Comprenez combien de bande passante un appel VoIP consomme avec chaque codec. Cela inclut les en-têtes de couche 2 et IP / UDP / RTP. Pour plus d’informations, reportez-vous à Voix sur IP – Consommation de bande passante par appel .

• Comprenez les caractéristiques du réseau IP sur lequel les appels transitent. Par exemple, la bande passante d’un réseau à relais de trames au CIR est très différente de celle ci-dessus-CIR (ou rafale), où les paquets peuvent être abandonnés ou mis en file d’attente dans le cloud Frame-Relay. Assurez-vous que le retard et la gigue sont contrôlés et éliminés autant que possible. Le temps de transmission unidirectionnel ne doit pas dépasser 150 ms (conformément à la recommandation G.114).

• Utilisez une technique de mise en file d’attente qui permet d’identifier et de hiérarchiser le trafic VoIP.

• Lorsque vous transmettez la VoIP sur des liaisons à faible débit, envisagez d’utiliser des techniques de fragmentation de paquets de couche 2, telles que MLPPP avec fragmentation et entrelacement de liens (LFI) sur des liaisons point à point, ou FRF.12 sur des liaisons trame-relais. La fragmentation de paquets de données plus volumineux permet moins de gigue et de retard dans la transmission du trafic VoIP car les paquets VoIP peuvent être entrelacés sur la liaison.

• Essayez d’utiliser un codec différent et essayez l’appel avec VAD activé et désactivé pour éventuellement réduire le problème au DSP, par opposition au réseau IP.

Avec la VoIP, les principaux éléments à rechercher lors du dépannage des problèmes de QoS sont les paquets perdus et les goulots d’étranglement du réseau qui peuvent provoquer des retards et de la gigue.

Chercher:

• interface gouttes

• gouttes de tampon

• congestion de l’interface

• encombrement des liaisons

Chaque interface dans le chemin de l’appel VoIP doit être examinée. Éliminez également les chutes et la congestion. En outre, le retard aller-retour doit être réduit autant que possible. Les pings entre les points d’extrémité VoIP donnent une indication du délai aller-retour d’une liaison. Le délai aller-retour ne doit pas dépasser 300 ms dans la mesure du possible. Si le retard doit dépasser cette valeur, des efforts doivent être faits pour s’assurer que ce retard est constant, afin de ne pas introduire de gigue ou de retard variable.

Une vérification doit également être effectuée pour s’assurer que le mécanisme de mise en file d’attente IOS place les paquets VoIP dans les files d’attente appropriées. Les commandes IOS, telles que show queue interface ou show priority, peuvent aider à vérifier la mise en file d’attente.

Détails des codes de cause et des valeurs de débogage pour VoIP

Utilisez ces tables lorsque vous lisez les débogages et les valeurs associées dans les débogages.

Q.931 Causes de déconnexion d’appel (cause_codes de debug voip ccapi inout)

Pour plus d’informations sur les codes de cause et les valeurs Q.931, reportez-vous à Types, codes et valeurs de commutateur RNIS

¹ Ce problème peut se produire en raison d’une incompatibilité de codec dans la configuration du H323. La première étape de dépannage consiste donc à coder en dur les homologues de numérotation VoIP pour utiliser le codec correct.

Valeurs de négociation de codec (à partir du débogage voip ccapi inout)

Pour plus d’informations sur les CODEC, reportez-vous à VoIP – Comprendre les codecs: complexité, prise en charge, MOS et négociation.

Types de sons

Valeurs des capacités de FAX-Rate et VAD

Information connexe

• Configuration des plans de numérotation, des homologues de numérotation et de la manipulation des chiffres
• Commandes de débogage VoIP
• Dépannage de la couche 1 T1
• Organigramme de dépannage T1
• Dépannage des problèmes de ligne série
• Prise en charge de la technologie vocale
• Assistance produit pour la voix et les communications unifiées
• Dépannage de la téléphonie IP Cisco 
• Assistance technique – Cisco Systems