Voix : H.323

Dépannage et débogage des appels VoIP – Notions élémentaires

19 octobre 2014 - Traduction automatique
Autres versions: PDFpdf | Anglais (19 septembre 2014) | Commentaires


Contenu


Introduction

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 chaque facette de l'architecture de Cisco IOS® utilisée dans des passerelles VoIP et des contrôleurs d'accès de routage 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 Attention : Déboguer le Cisco IOS peut être processeur intensif. 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 les tampons horaires en ajoutant les commandes : service timestamps debug datetime msec , service timestamps log datetime msec en mode enable. L'horodatage aide à déterminer l'intervalle du temps entre les changements d'état.

Conditions préalables

Conditions requises

Ce document est destiné au personnel de réseau impliqué dans la conception et le déploiement des réseaux VoIP. Les lecteurs de ce document doivent prendre connaissance des rubriques suivantes :

  • Configuration VoIP

  • QoS voix 

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®.

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

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

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.

/image/gif/paws/14081/call-legs.gif

Flux d'appels du routeur

/image/gif/paws/14081/call-flow.gif

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 fonctions principales de l'API de contrôle d'appel (également mentionné sous le nom de CCAPI) sont :

  • Identifier les segments d'appel (par exemple, qui est le partenaire de numérotation ? d'où vient-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.

L'interface de fournisseur de téléphonie et de service VoIP (SPI) - le SPI de téléphonie communique avec les POTS (analogue : fxs, fxo, e&m Digital : isdn, qsig, e&m, etc.) homologues de numérotation. 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.

telephony-int.gif

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.

  • Fournisseur de service de téléphonie vocale (VTSP) - Un processus IOS qui entretient des requêtes à partir de l'API de contrôle d'appel et formule les requêtes appropriées au processeur de signaux numériques (protocole de système d'annuaire) 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)

Les objectifs pour vérifier la signalisation numérique et analogique sont :

  • 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

Avec E1, utilisez la commande montrer contrôleurs e1. Pour plus d'informations à ce sujet, consultez :

montrer port voix

show voice port slot-number/port - Utilisez cette commande pour afficher l'état du port et les paramètres configurés sur le port voix des cartes d'interface voix Cisco (VIC). Comme toutes les commandes IOS, les valeurs par défaut ne s'affichent pas dans show running-config, mais ils 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 signaler des événements et peut être utile en résolvant des problèmes avec la 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 de vpm de débogage : 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, ce résultat montre des messages de debug vpm dsp seulement pour le port 1/0/0 :

    debug vpm dsp 
    
    debug vpm port 1/0/0 

    Pour plus d'informations, consultez les commandes de débogage VoIP.

Exemple de sortie pour la commande de debug vpm signal

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 si les deux extrémités de la connexion correspondent aux configurations de la signalisation. 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 sortie pour la commande de debug vpm spi

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 and debug hpi notification peut être utilisée pour voir les chiffres entrants.

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

Pour plus d'informations, consultez les commandes de débogage VoIP.

montrer numéro de plan de numérotation

show dialplan number <digit_string> - Cette commande affiche l'homologue de numérotation qui est mis en correspondance moyennant 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 # connexion à la fin des numéros de téléphone pour les homologues de numérotation avec une longueur variable afin de les faire correspondre sur les chablons de destination qui finissent avec le 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

Si on le détermine que les chiffres ne sont pas envoyés ou reçus correctement, il pourrait être nécessaire d'utiliser ou un grippeur de chiffres (outil de test) ou le testeur de t1 pour vérifier si les chiffres sont envoyés à l'intervalle correct de fréquence et de temporisation. S'ils sont envoyés « inexactement » pour le commutateur (Co ou PBX), quelques valeurs sur le routeur ou le commutateur (Co ou PBX) doivent probablement être réglés de sorte qu'ils soient assortis et puissent fonctionner. 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 :

  • Cisco VoIP gateways fait appel à la signalisation H.323 pour accomplir les appels. H.323 se compose de trois niveaux de négociation d'appel 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 de bout en bout VoIP montre un certain nombre de machines - états 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 la cause semble se situer dans la partie VoIP de l'établissement, vous pourrez probablement regarder la partie du TCP H.225 ou H.245 de l'appel, par opposition à la partie d'UDP de la configuration de 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. Référez-vous à Voix sur IP (VoIP) - Consommation de bande passante par appel pour plus d'informations.

  • 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 retard à sens unique de transmission ne devrait pas dépasser 150 ms (par recommandation G.114).

  • Utilisez une technique de mise en file d'attente qui permet d'identifier le trafic VoIP et à établir des priorités.

  • Quand vous transmettez le VoIP sur des liaisons à faible vitesse, considérez utiliser des techniques de fragmentation de paquets de niveau 2, telles que MLPPP avec le Link Fragmentation and Interleaving (LFI) sur les liaisons point par point, ou le 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 d'aller-retour ne devrait pas dépasser 300 ms autant que 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.

La vérification devrait également être faite 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 à la vérification de la queue.

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)

Pour plus d'informations sur codes de motif Q.931 et des valeurs, consultez les types de commutateur RNIS, les codes et les valeurs

Valeur de la cause de déconnexion d'appel (dans l'hexa) Signification et numéro (dans la décimale)
CC_CAUSE_UANUM = 0x1 numéro non affecté. (1)
CC_CAUSE_NO_ROUTE = 0x3 aucune route à la destination. (3)
CC_CAUSE_NORM = 0x10 effacement d'appel normal. (16)
CC_CAUSE_BUSY = 0x11 utilisateur occupé (17)
CC_CAUSE_NORS = 0x12 aucune réponse de l'utilisateur. (18)
CC_CAUSE_NOAN = 0x13 aucune réponse d'utilisateur. (19)
CC_CAUSE_REJECT = 0x15 appel rejeté. (21)
CC_CAUSE_INVALID_NUMBER = 0x1C nombre incorrect. (28)
CC_CAUSE_UNSP = 0x1F normal, non spécifié. (31)
CC_CAUSE_NO_CIRCUIT = 0x22 aucun circuit. (34)
CC_CAUSE_NO_REQ_CIRCUIT = 0x2C aucun circuit demandé. (44)
CC_CAUSE_NO_RESOURCE = 0x2F aucune ressource. (47) 1
CC_CAUSE_NOSV = 0x3F service ou option non disponible, ou non spécifiée. (63)

La question de 1Cette peut se produire en raison d'une non-concordance de codecs dans l'installation de h323, ainsi la première étape de dépannage est de coder en dur les homologues de numérotation VoIP pour utiliser les codecs corrects.

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

Pour plus d'informations sur des codecs, se rapportent au VoIP - Compréhension des codecs : Complexité, support, MOS et négociation

Valeur de négociation Signification
codec=0x00000001 G711 ULAW 64K PCM
codec=0x00000002 G711 ALAW 64K PCM
codec=0x00000004 G729
codec=0x00000004 G729IETF
codec=0x00000008 G729a
codec=0x00000010 G726r16
codec=0x00000020 G726r24
codec=0x00000040 G726r32
codec=0x00000080 G728
codec=0x00000100 G723r63
codec=0x00000200 G723r53
codec=0x00000400 GSMFR
codec=0x00000800 G729b
codec=0x00001000 G729ab
codec=0x00002000 G723ar63
codec=0x00004000 G723ar53
codec=0x00008000 CLEAR_CHANNEL

Types de tonalité

Types de tonalité Signification
CC_TONE_RINGBACK 0x1 Tonalité de sonnerie
CC_TONE_FAX 0x2 Tonalité de télécopie
CC_TONE_BUSY 0x4 Signal d'occupation
CC_TONE_DIALTONE 0x8 Tonalité
CC_TONE_OOS 0x10 Tonalité hors service
CC_TONE_ADDR_ACK 0x20 Tonalité d'accusé de réception d'adresse
CC_TONE_DISCONNECT 0x40 Tonalité de déconnexion
CC_TONE_OFF_HOOK_NOTICE 0x80 La tonalité indiquant le téléphone a été laissé décroché
CC_TONE_OFF_HOOK_ALERT 0x100 Une version plus récente de CC_TONE_OFF_HOOK_NOTICE
CC_TONE_CUSTOM 0x200 Tonalité personnalisée - utilisée en spécifiant une tonalité personnalisée
CC_TONE_NULL 0x0 Tonalité nulle

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

Valeurs Signification
CC_CAP_FAX_NONE 0x1 Débranchement de télécopie ou non disponible
CC_CAP_FAX_VOICE 0x2 Appel vocal
CC_CAP_FAX_144 0x4 14,400 bauds
CC_CAP_FAX_96 0x8 9600 bauds
CC_CAP_FAX_72 0x10 7,200 bauds
CC_CAP_FAX_48 0x20 4,800 bauds
CC_CAP_FAX_24 0x40 2,400 bauds
CC_CAP_VAD_OFF 0x1 VAD désactivé
CC_CAP_VAD_ON 0x2 VAD ACTIVÉ

Conversations connexes de la communauté de soutien de Cisco

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


Informations connexes


Document ID: 14081