Dépannage et débogage des appels VoIP

Introduction

Ce document décrit les techniques et les commandes de base pour dépanner et déboguer les réseaux VoIP.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Configuration VoIP

• QoS voix 

• Conception et déploiement de réseaux VoIP

Composants utilisés

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

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.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Ce document explique des techniques et des commandes de base pour dépanner et déboguer des réseaux VoIP. Une vue d'ensemble de l'architecture de flux et de téléphonie d'appel vocal dans un routeur Cisco est présentée, suivie d'une approche de dépannage du pas à pas VoIP présentée dans ces étapes :

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

2. Vérifier les chiffres reçus et envoyés de l'analogue et des ports vocaux numériques.

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

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

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

Remarque : ce document n'explique pas toutes les facettes de l'architecture Cisco IOS utilisée dans les passerelles VoIP et les gardes-barrière Cisco. Au lieu de cela, il montrera quelles commandes peuvent être utilisées et quels champs de résultats peuvent être les plus utiles.

Attention : le débogage de Cisco IOS sollicite énormément le processeur. Exercez la précaution quand vous utilisez les débogages listés dans ce document. Pour plus d'informations, consultez les informations importantes sur des commandes de débogage.

Les débogages doivent être exécutés avec l'horodatage activé dans le journal. Activez l'horodatage avec les commandes : service timestamps debug datetime msec, service timestampslog datetime msec en mode enable. L'horodatage aide à déterminer l'intervalle du temps entre les changements d'état.

Flux d'appel dans le réseau

Un facteur important à considérer avant que vous commenciez un dépannage ou débogage VoIP est que des appels VoIP se composent de trois signaux d'appel. Ces signaux d'appel sont des systèmes téléphoniques commutés traditionnels de source (POTS), VoIP et POTS de destination. Ceci est montré dans le schéma suivant : Le dépannage et le débogage doit se concentrer d'abord indépendamment sur chaque signal d'appel VoIP dans son ensemble.

Flux d'appels du routeur

Ces définitions expliquent la fonction des composants principaux affichés dans l'organigramme de flux d'appels du routeur :

API de contrôle d'appel (interface de programmation d'application) - Trois clients se servent de l'API de contrôle d'appel. Les trois clients sont CLI, agent de Protocole de gestion de réseau simple (SNMP) et l'application de la session. Les principales fonctions de l'API de contrôle des appels (également appelée CCAPI) sont les suivantes :

• Identifiez les segments d'appel (par exemple, quel terminal de numérotation dial-peer est-ce ? d'où provient-il ?).

• Décider quelle application de session prend l'appel (par exemple, qui la prend en charge ?).

• Impliquer le dispositif de traitement de paquets.

• Associer les segments d'appel.

• Débuter d'enregistrer la statistique d'appels.

Application de session et mappeur du plan de numérotation - L'application de session utilise le mappeur du plan de numérotation pour mapper un numéro à un homologue de numérotation (POTS local ou VoIP distant). Le mappeur du plan de numérotation emploie la table des homologues de numérotation pour rechercher l'homologue de numérotation actif.

Telephony and VoIP Service Provider Interface (SPI) : le SPI de téléphonie communique avec les terminaux de numérotation dial-peer POTS (analogiques : fxs, fxo, e&m Digital : isdn, qsig, e&m, etc.). Le VoIP SPI est l'interface spécifique des homologues de numérotation VoIP. Les gestionnaires Telephony/DSP fournissent des services au SPI de téléphonie tandis que le VoIP SPI se fonde sur des protocoles de session.

Architecture d'interface de téléphonie

Ce schéma montre l'architecture des éléments constitutifs de téléphonie de routeur Cisco et comment ils interagissent les uns avec les autres.

Cette liste décrit les fonctions et les définitions des composants principaux de schéma :

• Application programming interface de Contrôle d'appel (CCAPI) - L'entité de logiciel qui établit, termine et ponte des signaux d'appel.

• Voice Telephony Service Provider (VTSP) : processus Cisco IOS qui traite les demandes provenant 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 responsable du pontage et des processus coordonnés de signalisation entre la machine d'état de signalisation de ports de téléphonie (SSM), le manager de ressource DSP et le VTSP.

• Manager de ressource DSP - Le DSPRM fournit les interfaces par lesquelles le VTSP peut envoyer et recevoir des messages à et du DSP.

• Dispositif de traitement de paquets - Le dispositif de traitement de paquets transfère des paquets entre le DSP et les segments d'appel du partenaire.

• Homologue d'appel - L'homologue d'appel est le signal d'appel opposé. Ceci peut être une autre connexion vocale téléphonique (POTS), un VoFR, un VoATM, ou une connexion VoIP.

Vérifier signalisation numérique et analogique (le segment d'appel de POTS)

La vérification de la signalisation numérique et analogique consiste à :

• Déterminer que la signalisation analogique ou numérique appropriée avec combiné raccroché et décroché est reçue.

• Déterminer que la signalisation appropriée E&M, FXO et FXS est configurée sur le routeur et le commutateur (Co ou PBX).

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

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

montrer contrôleurs t1/E1 (numérique)

montrer contrôleurs t1 [emplacement/port] - Utilisez cette commande d'abord. Elle montre si la connexion numérique de t1 entre le routeur et le commutateur (Co ou PBX) est en active ou non et si elle fonctionne correctement. Le résultat de cette commande ressemble à ceci :

router# show controllers T1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is Line
Primary.
Data in current interval (6 seconds elapsed):

	0 Line Code Violations, 0 Path Code Violations
	0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 
  0 Degraded Mins
	0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
  0 Unavail Secs

Si vous utilisez E1, utilisez la commande show controllers e1. Pour plus d'informations à ce sujet, consultez :

• Dépannage de la couche 1 de T1

• Diagramme du dépannage T1

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

montrer port voix

show voice portslot-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 (VIC) Cisco. Comme toutes les commandes Cisco IOS, les valeurs par défaut ne s'affichent pas dans show running-config , mais elles s'affichent avec cette commande.

Ceci est un exemple de sortie pour un port de voix E&M :

router# show voice port 1/0:1
recEive and transMit Slot is 1, Sub-unit is 0, Port is 1
Type of VoicePort is E&M 
Operation State is DORMANT
Administrative State is UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Music On Hold Threshold is Set to -38 dBm
In Gain is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal (could be trunk or plar)
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Signal Type is wink-start
Operation Type is 2-wire
E&M Type is 1
Dial Type is dtmf
In Seizure is inactive
Out Seizure is inactive
Digit Duration Timing is set to 100 ms

InterDigit Duration Timing is set to 100 ms
Pulse Rate Timing is set to 10 pulses/second
InterDigit Pulse Duration Timing is set to 500 ms
Clear Wait Duration Timing is set to 400 ms
Wink Wait Duration Timing is set to 200 ms
Wink Duration Timing is set to 200 ms
Delay Start Timing is set to 300 ms
Delay Duration Timing is set to 2000 ms
Dial Pulse Min. Delay is set to 140 ms

vpm de débogage (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 à un PBX.

• debug vpm spi - Cette commande vérifie comment l'interface du fournisseur de service de module de routage de port vocal (SPI) se connecte par interface à l'API de contrôle d'appel. Cette commande de débogage affiche des informations au sujet de la façon dont chaque indication et requête d'application de réseau est traitée.

• debug vpm dsp - Cette commande affiche des messages du protocole de système d'annuaire sur le VPM au routeur et peut être utile si vous suspectez que le VPM ne soit pas fonctionnel. C'est un moyen simple de vérifier si le VPM réagit aux indications de combiné raccroché et d'évaluer la temporisation pour des messages de signalisation de l'interface.

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

• debug vpm port - Utilisez cette commande pour limiter le résultat du débogage à un port particulier. Par exemple, cette sortie montre debug vpm dspmessages seulement pour le port 1/0/0 :

debug vpm dsp 

debug vpm port 1/0/0 

Exemple de résultat pour debug vpm signalCommand

maui-voip-austin#debug vpm signal


!--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state.

htsp_process_event: [1/0/0, 1.2 , 36] 
fxsls_onhook_offhook htsp_setup_ind
*Mar 10 16:08:55.958: htsp_process_event: 
[1/0/0, 1.3 , 8] 


!--- Sends ringing alert to the called phone.

*Mar 10 16:09:02.410: htsp_process_event: 
[1/0/0, 1.3 , 10] htsp_alert_notify
*Mar 10 16:09:03.378: htsp_process_event: 
[1/0/0, 1.3 , 11] 


!--- End of phone call, port goes "on-hook".

*Mar 10 16:09:11.966: htsp_process_event: 
[1/0/0, 1.3 , 6] 
*Mar 10 16:09:17.218: htsp_process_event: 
[1/0/0, 1.3 , 28] fxsls_offhook_onhook
*Mar 10 16:09:17.370: htsp_process_event: 
[1/0/0, 1.3 , 41] fxsls_offhook_timer
*Mar 10 16:09:17.382: htsp_process_event: 
[1/0/0, 1.2 , 7] fxsls_onhook_release

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

• Vérifiez le câblage est correct.

• Vérifiez si le routeur et le commutateur (Co ou PBX) sont correctement fondus.

• Vérifiez que les deux extrémités de la connexion ont des configurations de signalisation équivalentes. Les configurations mal adaptées peuvent entraîner une signalisation inachevée ou à sens unique.

Pour plus d'informations sur le dépannage E&M, consultez Comprendre et dépanner les types d'interface d'E & M analogique et câbler des configurations.

Exemple de résultat pour debug vpm spiCommand

maui-voip-austin#debug vpm spi   
Voice Port Module Session debugging is enabled


!--- The DSP is put into digit collection mode.

*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_time=75

Vérifier les chiffres reçus et envoyés (le segment d'appel de POTS)

Une fois que la signalisation avec combiné raccroché et combiné décroché est vérifiée et si elle fonctionne correctement, vérifiez si les chiffres corrects sont reçus ou envoyés sur le port voix (numérique ou analogique). Un homologue de numérotation n'est pas mis en correspondance ou le commutateur (Co ou PBX) ne peut pas appeler la station correcte si des chiffres incorrects ou incomplets sont envoyés ou reçus. Certaines commandes peuvent être utilisées pour vérifier les chiffres reçus/envoyés, à savoir :

• show dialplan number - Cette commande est utilisée pour montrer quel partenaire de numérotation est atteint quand un numéro de téléphone particulier est composé.

• debug vtsp session - Cette commande montre les informations sur la façon dont chaque indication et requête d'application de réseau est traitée, signalant des messages d'indications et de contrôle de protocole de système d'annuaire.

• debug vtsp dsp - Dans les versions antérieures à Cisco IOS Version 12.3, cette commande affiche les chiffres pendant qu'ils sont reçus par le port voix. Cependant, dans le logiciel Cisco IOS version 12.3 et versions ultérieures, le résultat de la commande de débogage n'affiche plus les chiffres. La combinaison de debug hpi detail et debug hpinotification peut être utilisée pour voir les chiffres entrants.

• debug vtsp all - Cette commande active les commandes debug voice telephony service provider (VTSP) suivantes : debug vtsp session, debug vtsp error , et debug vtsp dsp.

montrer numéro de plan de numérotation

show dialplan number <digit_string> : cette commande affiche le terminal de numérotation dial-peer correspondant à une chaîne de chiffres. Si plusieurs homologues de numérotation peuvent être mis en correspondance, ils sont tous montrés dans la commande relative à la mise en correspondance.

Remarque : vous devez utiliser le signe # à la fin des numéros de téléphone pour les terminaux de numérotation dial-peer de longueur variable afin de correspondre aux modèles de destination qui se terminent par T.

Le résultat de cette commande ressemble à ceci :

maui-voip-austin#show dialplan number 5000
Dial string terminator: #
Macro Exp.: 5000

VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation
        state is up,
        incoming called-number = `', 
        connections/maximum = 0/unlimited,
        application associated: 
        type = voip, session-target = 
        `ipv4:192.168.10.2',
        technology prefix: 
        ip precedence = 5, UDP checksum = 
        disabled, session-protocol = cisco, 
        req-qos = best-effort, 
        acc-qos = best-effort, 
        dtmf-relay = cisco-rtp, 
        fax-rate = voice,   
        payload size =  20 bytes
        codec = g729r8,   
        payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,
        signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 25630, Charged Units = 0,
        Successful Calls = 25, Failed Calls = 0,
        Accepted Calls = 25, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call 
        clearing.",
        Last Setup Time = 84427934.
        Matched: 5000   Digits: 4
        Target: ipv4:192.168.10.2

débogage de session vtsp

La commande debug vtsp session montre les informations sur la façon dont le routeur interagit avec le protocole de système d'annuaire basé sur les indications de signalisation de la pile de signalisation et des requêtes de routage de l'application. Cette commande de débogage montre les informations au sujet de la façon dont chaque indication et requête d'application de réseau est traitée, signalant des messages d'indications et de contrôle de protocole de système d'annuaire.

maui-voip-austin#debug vtsp session 
Voice telephony call control session debugging is on


!--- Output is suppressed. 
!--- ACTION: Caller picked up handset. 
!--- The DSP is allocated, jitter buffers, VAD 
!--- thresholds, and signal levels are set.


*Mar 10 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
*Mar 10 18:14:22.865: dsp_echo_canceller_control: 
[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66
flags=0x0
*Mar 10 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
*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)] 
packet_len=10 channel_id=1 packet_id=78 
thresh=-38act_setup_ind_ack 
*Mar 10 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_ack(): dsp_dtmf_mod
e()act_setup_ind_ack: passthru_mode = 0, 
no_auto_switchover = 0dsp_dtmf_mode
(VTSP_TONE_DTMF_MODE)


!--- The DSP is put into "voice mode" and dial-tone is 
!--- generated.


*Mar 10 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
_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 ê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 synchronisation corrects. S’ils sont envoyés « incorrectement » pour le commutateur (CO ou PBX), il peut être nécessaire d’ajuster certaines valeurs sur le routeur ou le commutateur (CO ou PBX) afin qu’elles correspondent et interagissent. Ce sont habituellement des valeurs de durée de chiffre et de durée d'inter-chiffre. Un autre élément pour examiner si les chiffres semblent être envoyés correctement sont les tables de traduction de numéros dans le commutateur (Co ou PBX) qui peut ajouter ou supprimer des chiffres.

Vérifier la signalisation de bout en bout VoIP (le segment d'appel de VOIP)

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

• Les passerelles Cisco VoIP utilisent la signalisation H.323 pour effectuer des appels. H.323 est constitué de trois couches de négociation et d'établissement d'appel : H.225, H.245 et H.323. Ces protocoles emploient une combinaison de TCP et UDP pour installer et établir un appel.

• Le débogage VoIP de bout en bout affiche un certain nombre de machines d'état Cisco IOS. Les problèmes de routage avec les machines - états peuvent faire échouer un appel.

• Le débogage de bout en bout VoIP peut être très bavard et créer beaucoup de résultat du débogage.

debug voip ccapi inout

La commande principale de débogage des appels VoIP de bout en bout est debug voip ccapi inout. Le résultat d'un débogage d'appel est montré dans ce résultat.

!--- Action: A VoIP call is originated through the 
!--- Telephony SPI (pots leg) to extension 5000. 
!--- Some output is omitted.


maui-voip-austin#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on


!--- Call leg identification, source peer: Call 
!--- originated from dial-peer 1 pots 
!--- (extension 4000).


*Mar 15 22:07:11.959: cc_api_call_setup_ind 
(vdbPtr=0x81B09EFC, callInfo={called=, 
calling=4000, fdest=0 peer_tag=1}, callID=0x81B628F0)

!--- CCAPI invokes the session application.


*Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"
*Mar 15 22:07:11.963: sess_appl: 
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)


!--- Allocate call leg identifiers "callid = 0x59"


*Mar 15 22:07:11.963: ccCallSetContext 
(callID=0x58, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck 
(callID=0x58)


!--- Instruct VTSP to generate dialtone
. 

*Mar 15 22:07:11.963: ccGenerateTone 
(callID=0x58 tone=8)


!--- VTSP passes digits to CCAPI.


*Mar 15 22:07:20.275:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:20.279: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:20.279: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:20.279: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:20.327: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=5
, duration=100)
*Mar 15 22:07:20.327: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:20.327: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.975:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:21.979: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:21.979: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.979: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:22.075: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:22.079: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:22.079: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.235: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, dgit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:23.239: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:23.239: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.239: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:23.335: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:23.339: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 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, timestamp=0xC2E63BB7, 
expiration=0x0)
*Mar 15 22:07:25.147: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:25.147: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:25.147: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:25.255: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=160)
*Mar 15 22:07:25.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:25.259: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)


!--- Matched dial-peer 2 voip. Destination number !--- 5000


*Mar 15 22:07:25.259: ssaSetupPeer cid(88) 
peer list:tag(2) called number(5000) 
*Mar 15 22:07:25.259: ssaSetupPeer cid(88), 
destPat(5000), matched(4), prefix(),
peer(81C04A10)


!--- Continue to call an interface and start the !--- next call leg.


*Mar 15 22:07:25.259: ccCallProceeding 
(callID=0x58, prog_ind=0x0)
*Mar 15 22:07:25.259: ccCallSetupRequest 
(Inbound call = 0x58, outbound peer =2,
dest=, params=0x81BAF168 mode=0, 
*callID=0x81B6DE58)
*Mar 15 22:07:25.259: callingNumber=4000, 
calledNumber=5000, redirectNumber=


!--- VoIP call setup.


*Mar 15 22:07:25.263: ccIFCallSetupRequest:
(vdbPtr=0x81A75558, dest=, 
callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}, mode=0x0)
*Mar 15 22:07:25.263: ccCallSetContext 
(callID=0x59, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert 
(callID=0x58, prog_ind=0x8, sig_ind=0x1)


!--- POTS and VoIP call legs are tied together.


*Mar 15 22:07:25.375: ccConferenceCreate 
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)
*Mar 15 22:07:25.375: cc_api_bridge_done 
(confID=0x1E, srcIF=0x81B09EFC, srcCall
ID=0x58, dstCallID=0x59, disposition=0, 
tag=0x0)


!--- Exchange capability bitmasks with remote 
!--- the VoIP gateway 
!--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth).


*Mar 15 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})


!--- Both gateways agree on capabilities.

*Mar 15 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})
*Mar 15 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})
*Mar 15 22:07:35.259: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=T
, duration=0)
*Mar 15 22:07:35.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:35.259: ssaTraceSct: 
cid(88)st(4)oldst(3)cfid(30)csize(0)in(1)
fDest(0)-cid2(89)st2(4)oldst2(1)
*Mar 15 22:07:35.399: cc_api_call_connected
(vdbPtr=0x81A75558, callID=0x59)
*Mar 15 22:07:35.399: sess_appl: 
ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0)
*Mar 15 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)


!--- VoIP call is connected.


*Mar 15 22:07:35.399: ccCallConnect 
(callID=0x58)


!--- VoIP call is disconnected. Cause = 0x10
 

*Mar 15 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 d'appel, vous pouvez éventuellement avoir besoin d'examiner la partie H.225 ou H.245 TCP de l'établissement d'appel, par opposition à la partie UDP de l'établissement H.323. Les commandes qui peuvent être utilisées pour déboguer l'établissement H.225 ou H.245 sont :

• transactions de débogage ip tcp and paquet de débogage ip tcp — Ces commandes examinent la portion TCP de la négociation H.225 et H.245. Elles retournent 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 H.225 basée sur l'événement traité. Pensez à ceci comme le niveau 1 de l'établissement de H.323 en trois parties.

• 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 H.225 basée sur l'événement traité. Pensez à ceci comme le niveau 2 de l'établissement de H.323 en trois parties.

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

Quand des appels VoIP sont correctement établis, l'étape suivante est de vérifier que la qualité vocale est bonne. Bien que le dépannage de QoS ne soit pas couvert dans ce document, ces directives doivent être considérées pour atteindre la bonne qualité de la voix :

• Vous devez savoir combien de largeur de bande un appel VoIP consomme avec chaque codec. Ceci inclut le niveau 2 et les en-têtes IP/UDP/RTP. Pour plus d'informations, référez-vous à Modifier le calcul de consommation de bande passante pour les appels vocaux.

• Comprendre que les caractéristiques du réseau IP les appels voyage plus de. Par exemple, la largeur de bande d'un réseau à relais de trame au CIR est différente du CIR au-dessus (ou salve), où les paquets peuvent être déposés ou mis en attente dans l'entité en relais de trame. Assurez-vous que le délai et instabilité sont contrôlés et éliminés autant que possible. Le délai 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, utilisez des techniques de fragmentation de paquets de couche 2, telles que MLPPP avec fragmentation et entrelacement de liaison (LFI) sur des liaisons point à point ou FRF.12 sur des liaisons Frame Relay. La fragmentation d'un plus grand paquet de données donne moins de dispersions et de retard à transmettre le trafic VoIP parce que les paquets VoIP peuvent être intercalés sur la liaison.

• Essayez d'utiliser un codec différent et d'essayer l'appel avec VAD activé et désactivé pour cerner le problème au protocole de système d'annuaire, par opposition au réseau IP.

Avec le VoIP, les principales choses à rechercher en dépannant des problèmes de QoS sont des paquets abandonnés et des goulots d'étranglement du réseau qui peuvent entraîner retards et instabilité.

Cherchez :

• abandons d'interface

• abandons de mémoire tampon

• congestion d'interface

• encombrement de liaison

Chaque interface dans le chemin de l'appel VoIP doit être examinée. En outre, éliminez les abandons et l'encombrement. En outre, le délai d'aller-retour doit être réduit autant que possible. Les pings entre les points d'extrémité VoIP donnent une indication du délai d'aller-retour d'une liaison. Le délai de transmission 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 pris pour s'assurer que ce retard est constant, pour ne pas introduire le dispersement ou le retard variable.

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

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

Utilisez ces tableaux quand vous lisez des débogages et les valeurs associées dans les débogages.

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

¹Ce problème peut se produire en raison d'une non-correspondance de codecs dans la configuration H323. La première étape de dépannage consiste donc à coder en dur les terminaux de numérotation dial-peer VoIP pour utiliser le codec correct.

Valeurs de négociation de codecs (du debug voip ccapi inout)

Pour plus d'informations sur les CODEC, référez-vous à Comprendre les codecs : Complexité, Support matériel, MOS et Négociation.

Types de tonalité

Débit de télécopie et valeurs de fonctionnalités VAD

Informations connexes

• Dépannage de la couche 1 de T1
• Dépannage de T1
• Dépannage des problèmes de ligne série
• Dépannage des problèmes de téléphonie IP Cisco
• Assistance technique de Cisco et téléchargements