Résolution des erreurs du commutateur logiciel PGW 2200 pour les appels raccrochés MGCP

  

Introduction

Ce document explique les éléments liés aux appels suspendus sur la passerelle pour la solution de commutateur logiciel Cisco PGW 2200 de contrôle d'appel, en combinaison avec un scénario pour vous aider à résoudre les problèmes. Actuellement, la passerelle Cisco IOS® n'a pas la capacité de corréler l'élément de traitement de service (SPE) (expliqué dans le document Présentation des versions SPE NextPort) avec une connexion DS0 (Digital Service zero) et une connexion MGCP (Media Gateway Control Protocol). Sans les débogages Cisco IOS, il n'est pas possible de mapper un DS0 à un processeur de signal numérique (DSP) avec la commande Cisco IOS show tdm mapping pour les types d'appels basés sur MGCP. L'ID de bogue Cisco CSCdz47711 (clients enregistrés uniquement) est présenté pour corriger cette situation pour les passerelles Cisco IOS AS5350, AS5400 et AS5850.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants :

• Documentation du logiciel Cisco Media Gateway Controller version 9

• Notes de version du logiciel Cisco Media Gateway Controller version 9.3(2)

• Notes de version du logiciel Cisco Media Gateway Controller version 9.4(1)

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Logiciel Cisco PGW 2200 versions 9.3(2) et 9.4(1)

• Passerelle Cisco IOS versions 12.3 et 12.3T

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. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Résoudre les erreurs d'appel de blocage MGCP

Si vous rencontrez un scénario d'appel MGCP suspendu, l'utilisation des débogages n'est pas utile. En outre, pour un système actif, il est difficile de corréler l'enveloppe de charge utile synchrone (SPE) avec une connexion DS0 et MGCP. Si vous voulez corréler DS0 et DSP pour un appel actif, ce document fournit une explication.

Avant de commencer, sur le PGW 2200, assurez-vous que le paramètre MgcpBehavior (utilisez MML [Man-Machine Language]) a une valeur égale à 2 pour la passerelle Cisco IOS. Référez-vous au document Paramètres du fichier XECfgParm.dat pour plus d'informations.

PGW 2200 version 9.1(5) :

• Si MgcpBehavior est égal à 1 (passerelles qui ne sont pas basées sur le logiciel Cisco IOS, telles que Cisco Voice Interworking Service Module [VISM] et Cisco MGX) à la réception du code d'erreur 501, le PGW 2200 définit le circuit sur un état pour empêcher toute utilisation ultérieure. Référez-vous au document Composants et propriétés pour plus d'informations.

• Si le MgcpBehavior est égal à 2 (passerelle Cisco IOS), à la réception du code d'erreur 501, le PGW 2200 définit le circuit sur un état pour empêcher toute utilisation ultérieure. Dès réception du code d'erreur 502 en réponse au premier CRCX (Create Connection), le PGW 2200 envoie le message DLCX (MGCP Delete Connection), suivi d'un autre message CRCX MGCP. Si un autre code d'erreur 502 est retourné par la passerelle Cisco IOS, l'appel est libéré. L'hypothèse est que le circuit est de nouveau utilisable. Reportez-vous au document Composants et propriétés pour plus d'informations.

PGW 2200 version 9.2(2) et ultérieure :

• Si le MgcpBehavior est égal à 1 (pour le VISM et le MGX), à la réception du code d'erreur 501, le PGW 2200 définit le circuit à un état pour empêcher toute utilisation ultérieure.

• Si le MgcpBehavior est égal à 2 (passerelle Cisco IOS), à la réception du code d'erreur 501, le PGW 2200 définit le circuit sur un état pour empêcher toute utilisation ultérieure. Dès réception du code d'erreur 502 (pour le premier message CRCX MGCP), le PGW 2200 envoie un message DLCX MGCP suivi d'un autre message CRCX MGCP. Si le PGW 2200 reçoit un autre code d'erreur 502, l'appel est libéré. Le circuit est réglé sur un état pour empêcher toute utilisation ultérieure. En même temps, le circuit est inclus dans une liste de circuits sur lesquels un audit en arrière-plan (mini) est effectué. Cet audit envoie un message DLCX MGCP forcé pour tous les circuits de la mini liste d'audit afin d'essayer d'amener l'état du circuit en synchronisation avec le PGW 2200.

Le délai d'expiration de la réponse MGCP est traité comme une condition GW_HELD de défaillance temporaire et le message MGCP DLCX recommence chaque minute. Seule la réception du message RSIP (Restart in Progress) (gracieux/forcé), du code d'erreur MGCP 500 ou de l'un des codes d'erreur 501/502 spéciaux provoque une défaillance permanente si la propriété MgcpBehavior est définie de manière appropriée. N'oubliez pas que le code d'erreur 500 provoque toujours une défaillance, indépendamment de MgcpBehavior, parce qu'il équivaut à « point de terminaison inconnu ».

Remarque : avec PGW 2200 version 9.5(2) et ultérieure, le PGW 2200 a mis en oeuvre MGCP 1.0. Cela fournit une plus grande robustesse et de meilleures procédures de gestion des erreurs.

Message	Logiciel Cisco IOS (5xxx)
CRCX	502
Modifier la connexion (MDCX)	515
DLCX	250
Demande de notification (RQNT)	400
Point de terminaison d'audit (AUEP)	500

La raison en est que le PGW 2200 dispose d'un mécanisme d'audit pour synchroniser les états de canal avec l'élément réseau, tel qu'une passerelle Cisco IOS, avec laquelle il communique. Le programme de vérification du PGW 2200 fonctionne à 4 h 00. (0400) chaque matin et effectue ces actions selon différents scénarios :

• Scénario 1 : Lorsque l'état du canal est OCCUPÉ sur le PGW 2200 ainsi que sur la passerelle Cisco IOS, il n'y a aucune action.

• Scénario 2 : Lorsque l'état du canal est IDLE sur le PGW 2200 ainsi que sur la passerelle Cisco IOS, un DLCX MGCP est envoyé à la passerelle Cisco IOS pour ce point de terminaison. Cela efface toute connexion interrompue, si elle existe.

• Scénario 3 : Lorsque l'état du canal est BUSY sur le PGW 2200 et IDLE sur la passerelle Cisco IOS, le PGW 2200 relâche l'appel et envoie un DLCX à la passerelle Cisco IOS pour le point de terminaison correspondant afin de synchroniser la passerelle Cisco IOS.

• Scénario 4 : Lorsque le canal est IDLE sur le PGW 2200 et OCCUPÉ sur la passerelle Cisco IOS, le PGW 2200 envoie un DLCX MGCP à la passerelle Cisco IOS pour que le point de terminaison correspondant synchronise la passerelle Cisco IOS. La procédure d'audit de passerelle PGW 2200 et Cisco IOS efface le canal sur la passerelle Cisco IOS.

  Si la procédure initiale que le langage de définition de message (MDL) appelle ne parvient pas à mettre le circuit en état d'inactivité, elle appelle une interface du moteur pour marquer le point de terminaison comme désactivé et crée une entrée pour le mécanisme spécial d'audit des points de terminaison bloqués/bloqués du moteur.

  Pour modifier la valeur MgcpBehavior de la passerelle Cisco IOS, définissez la propriété MgcpBehavior sur 2 sur les MGCPPATH.

  mml> prov-sta::srcver="active",dstver="cisco1" 
  mml> prov-ed:sigsvcprop:name="sigmgcpto5xxx",MgcpBehavior="2" 
  mml> prov-cpy

  Remarque : Dans certains cas, un rechargement de la passerelle Cisco IOS est demandé pour redémarrer à partir d'une situation propre. Avant cela, une journalisation détaillée de la passerelle Cisco IOS peut aider à résoudre le problème.

Commandes show

Les commandes show présentées ici peuvent vous aider à vérifier et dépanner un appel suspendu.

Certaines commandes show sont prises en charge par l'Output Interpreter Tool (clients enregistrés uniquement), qui vous permet de voir une analyse de la sortie de la commande show.

La commande show call active voice compact durée more ? peut aider à trouver des appels de longue durée sur la passerelle Cisco IOS :

V5xxx-3# show call active voice compact duration more ? 
  <1-2147483647>  time in seconds 
V5xxx-3# 

La synthèse vocale show call active | include term 4d peut également fournir des instructions :

V5xxx-3# show call active voice brief | include duration 4d 
V5xxx-3# show call active voice brief | include duration ? 
LINE    <cr> 

V5xxx-3#

Ces commandes show peuvent aider à déterminer l'appel suspendu :

• show mgcp statistics - Affiche les statistiques MGCP sur les messages réseau reçus et transmis.

• show mgcp connection : affiche les informations des connexions actives contrôlées par le MGCP.

• show rtpspi statistics - Affiche les statistiques SPI (Real-Time Transport Protocol).

• show ip socket : affiche les informations de socket IP.

• show voice call summary : affiche un résumé de tous les ports vocaux.

• show voice port summary : affiche des informations de configuration récapitulative sur un port voix spécifique.

• show vtsp call fsm : affiche l'historique complet de toutes les transitions FSM (Finite State Machine) du fournisseur de téléphonie vocale (VTSP).

• show csm voice : affiche les informations relatives au module de commutation d'appels (CSM). Les informations sont l'état CSM dans lequel se trouve la machine pour l'appel associé à ce canal DSP, l'heure de début de l'appel, l'heure de fin de l'appel et le canal sur le contrôleur utilisé par l'appel.

  Remarque : S'il s'agit d'un système de signalisation MGCP 7 (SS7), cette commande n'est pas très utile.

• show spe : affiche l'état SPE.

• show spe voice summary : affiche l'état de la voix SPE.

• show port Operational-status slot/port (pour le DSP suspecté) : affiche des informations sur tous les ports du logement spécifié et du SPE.

• show port voice log verso slot/port (pour le DSP suspecté) : affiche des informations pour tous les ports du logement spécifié et du SPE.

Les informations de la série de commandes show qui suit font référence aux appels MGCP via les passerelles AS5xxx, qui incluent les informations Call_ID© (en gras) pour cet appel. C'est également important lorsque vous voulez dépanner. Le point de terminaison MGCP se trouve à l'aide de la commande debug mgcp packet du logiciel Cisco IOS ou de l'application Cisco Snooper.

V5xxx-3# show mgcp connection 
Endpoint  Call_ID©) Conn_ID(I) (P)ort (M)ode (S)tate (CO)dec (E)vent[SIFL] 
(R)esult[EA] 
1. S3/DS1-0/1   C=2F,1,2     I=0x2  P=16628,17204  M=3  S=4,4  
CO=2  E=0,0,0,0  R=0,0 

Remarque : vérifiez l'état M, qui est lié au mode MGCP sur Dépannage des appels en sourdine sur le Cisco PGW 2200.

La commande show call active voice brief fournit des informations sur les paquets de transmission (Tx)/réception (Rx).

V5xxx-3# show call active voice brief 

Telephony call-legs: 1 
SIP call-legs: 0 
H323 call-legs: 0 
MGCP call-legs: 1 
Multicast call-legs: 0 
Total call-legs: 2 
11DA : 37079hs.1 +-1 pid:0 Originate  connecting 
 dur 00:00:00 tx:1198/189454 rx:113437/18149920 
 IP 10.48.84.217:17204 rtt:0ms pl:16000/1290ms lost:29/34/29 delay:30/25/110ms 
 g711alaw 
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a 
11DA : 37079hs.2 +0 pid:52 Originate  active 
 dur 00:37:50 tx:113437/18149920 rx:1198/189454 
 Tele 3/0:0 (1) [3/0.1] tx:2270655/3000/0ms g711alaw noise:-65 
 acom:90  I/0:-51/-45 dBm 

Telephony call-legs: 1 
SIP call-legs: 0 
H323 call-legs: 0 
MGCP call-legs: 1 
Multicast call-legs: 0 
Total call-legs: 2 

v5xxx-3# 

Exécutez la commande show voip rtp connections pour connaître les détails de la passerelle distante. Ces informations incluent les informations CallId pour cet appel. (Dans ce cas, CallId est 1.)

v5xxx-3# show voip rtp connections 
VoIP RTP active connections : 
No. CallId  dstCallId  LocalRTP RmtRTP LocalIP    RemoteIP 
1         2     1          16628     17204    10.48.84.26  10.48.84.217 
Found 1 active RTP connections 

v5xxx-3# 

La commande show vtsp call fsm est une commande cachée du logiciel Cisco IOS et n'est utilisée que pour l'assistance technique Cisco et l'équipe de développement Cisco. Avec cette commande, vous pouvez rechercher les boîtiers avec l'expression « FSM non valide ». La commande show vtsp call fsm affiche l'historique complet de toutes les transitions FSM VTSP. Il est déclenché automatiquement chaque fois qu'un problème DSP se produit pendant que l'interface de ligne de commande (CLI) debug vtsp error est activée.

Remarque : Vous pouvez également convertir CallId = 1 en hexadécimal, ce qui vous donne id = 0x1.

V5xxx-3# show vtsp call fsm 

0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
id=0x1 state=S_CONNECT chan_id=3/0:0 (1) DSM state=S_DSM_BRIDGED 
Stack 0: 
State Transitions: timestamp (state, event) -> (state, event) ... 
370.796 (S_SETUP_REQUEST, E_TSP_PROCEEDING) -> 
370.796 (S_SETUP_REQ_PROC, E_TSP_CONNECT) -> 
Event Counts (zeros not shown): (event, count) 
(E_TSP_PROCEEDING, 2) :(E_TSP_CONNECT, 2) : 
State Counts (zeros not shown): (state, count) 
(S_SETUP_REQ_PROC, 2) :(S_SETUP_REQUEST, 2) : 
  

--------------------- DSM basic call state information --------------------- 
id=0x1 state=S_DSM_BRIDGED chan_id=0 
Stack 0: 
State Transitions: timestamp (state, event) -> (state, event) ... 
370.796 (S_DSM_INIT, E_DSM_CC_GEN_TONE) -> 
370.796 (S_DSM_INIT, E_DSM_CC_CALL_MODIFY) -> 
370.796 (S_DSM_INIT, E_DSM_CC_BRIDGE) -> 
370.800 (S_DSM_BRIDGING, E_DSM_CC_CAPS_IND) -> 
370.800 (S_DSM_BRIDGING, E_DSM_CC_CAPS_ACK) -> 
475.764 (S_DSM_BRIDGED, E_DSM_CC_GET_LEVELS) -> 
2641.564 (S_DSM_BRIDGED, E_DSM_CC_GET_LEVELS) -> 
Event Counts (zeros not shown): (event, count) 
(E_DSM_DSP_GET_VP_DELAY, 496) :(E_DSM_DSP_GET_VP_ERROR, 496) :(E_DSM_DSP_GET_TX, 
 496) :(E_DSM_DSP_GET_RX, 496) 
(E_DSM_DSP_GET_LEVELS, 2) :(E_DSM_CC_BRIDGE, 1) :(E_DSM_CC_GEN_TONE, 1) :
 (E_DSM_CC_REQ_PACK_STAT, 496) 
(E_DSM_CC_CAPS_IND, 1) :(E_DSM_CC_CAPS_ACK, 1) :(E_DSM_CC_CALL_MODIFY, 1) :
 (E_DSM_CC_GET_LEVELS, 2) 

State Counts (zeros not shown): (state, count) 
(S_DSM_INIT, 3) :(S_DSM_BRIDGING, 2) :(S_DSM_BRIDGED, 2484) : 

v5xxx-3# 

Pour savoir sur quel DSP l'appel est connecté, exécutez la commande show tdm mapping et liez les détails au point de terminaison pour lequel vous effectuez le suivi. Dans ce cas, il s'agit de S3/DS1-0/1 :

v5xxx-3# show tdm mapping 

E1 3/0 is up: 
Loopback: NONE 
DS0      Resource    Call Type 
----------------------------------- 

1          1/0         VOICE 

E1 3/1 is up: 
Loopback: NONE 
DS0      Resource    Call Type 
----------------------------------- 

v5xxx-3# 

Il est connecté au port 1 de SPE 1. Exécutez la commande show spe pour connaître les états Port et Call.

v5xxx-3# show spe 
Settings  : 
========== 
Country code config : default T1 (u Law) 
Country code setting: e1-default 
History log events  : 50(per port) 
Legend    : 
========== 
Port state: (s)shutdown   (r)recovery  (t)test  (a)active call 
            (b)busiedout  (d)download  (B)bad   (p)busyout pending 
Call type : (m)modem      (d)digital   (v)voice (f)fax-relay       (_)not in use 

Summary   : 
========== 
Ports     : Total   60  In-use     1  Free    59  Disabled     0 
Calls     : Modem    0  Digital    0  Voice    1  Fax-relay    0 

                     SPE          SPE     SPE  SPE   Port         Call 
SPE#    Port #       State        Busyout Shut Crash State        Type 
1/00    0000-0005    ACTIVE             0    0     0 a_____       v_____ 
1/01    0006-0011    ACTIVE             0    0     0 ______       ______ 
1/02    0012-0017    ACTIVE             0    0     0 ______       ______ 
1/03    0018-0023    ACTIVE             0    0     0 ______       ______ 
1/04    0024-0029    ACTIVE             0    0     0 ______       ______ 
1/05    0030-0035    ACTIVE             0    0     0 ______       ______ 
1/06    0036-0041    ACTIVE             0    0     0 ______       ______ 
1/07    0042-0047    ACTIVE             0    0     0 ______       ______ 
1/08    0048-0053    ACTIVE             0    0     0 ______       ______ 
1/09    0054-0059    ACTIVE             0    0     0 ______       ______ 

v5xxx-3# 

Dans ce cas, vous pouvez savoir si des paquets sont toujours envoyés et envoyés sur ce port SPE si vous émettez la commande show port Operational-status 1/0 (pour le DSP suspecté) :

v5xxx-3# show port operational-status 1/0   
Slot/SPE/Port -- 1/0/0 
Service Type                            : Voice service 
Voice Codec                             : G.711 a-law 
Echo Canceler Length                    : 8 ms 
Echo Cancellation Control               : Echo cancellation       - disabled 
                                          Echo update             - enabled 
                                          Non-linear processor    - enabled 
                                          Echo reset coefficients - disabled 
                                          High pass filter enable - disabled 
Digit detection enable                  : DTMF signaling          - enabled 
Voice activity detection                : Enabled 
Comfort noise generation                : Generate comfort noise 
Digit relay enable                      : OOB Digit relay         - enabled 
                                          IB Digit relay          - enabled 
Information field size                  : 20 ms 
Playout de-jitter mode                  : adaptive 
Encapsulation protocol                  : RTP 
Input Gain                              : 0.0 dB 
Output Gain                             : 0.0 dB 
Tx/Rx SSRC                              : 24/0 
Current playout delay                   : 30 ms 
Min/Max playout delay                   : 25/110 ms 
Clock offset                            : 180505398 ms 
Predictive concealment                  : 0 ms 
Interpolative concealment               : 1105 ms 
Silence concealment                     : 0 ms 
Buffer overflow discards                : 19 
End-point detection errors              : 23 
Tx/Rx Voice packets                     : 944/88273 
Tx/Rx signaling packets                 : 0/0 
Tx/Rx comfort noise packets             : 11/0 
Tx/Rx duration                          : 1767250/1767250 ms 
Tx/Rx voice duration                    : 3000/16000 ms 
Out of sequence packets                 : 0 
Bad protocol headers                    : 0 
Num. of late packets                    : 23 
Num. of early packets                   : 28 
Tx/Rx Power                             : -45.2/-51.2 dBm 
Tx/Rx Mean                              : -44.3/-51.0 dBm 
VAD Background noise level              : -65.8 dBm 
ERL level                               : 27.7 dB 
ACOM level                              : 90.1 dB 
Tx/Rx current activity                  : silence/silence 
Tx/Rx byte count                        : 151051/14123360 
ECAN Background noise level             : 0.0 dBm 
Latest SSRC value                       : 4144068239 
Number of SSRC changes                  : 1 
Number of payload violations            : 0 

v5350-3# 

Émettez cette commande plusieurs fois pour fournir des détails sur le type de connexion qui est combiné avec la passerelle distante. Exécutez cette commande sur la passerelle locale/distante pour connaître l'état.

Si vous avez un appel suspendu, vous pouvez émettre les commandes debug vtsp error et debug mgcp packet endpoint S3/DS1-0/1. Lorsque vous mettez le point de terminaison MGCP hors tension, le résultat est le message de débogage suivant :

Apr  9 12:30:18.602: MGCP Packet received from 10.48.84.25:2427- 
DLCX 617 S3/DS1-0/1@v5300-3.cisco.com MGCP 0.1 
C: 1C 
I: 4D 
R: 
S: 
X: 268 
Apr  9 12:30:18.626: 250 617 OK 
P: PS=128, OS=20241, PR=16615, OR=2658400, PL=4, JI=24, LA=0 

Ces commandes sont également utiles :

v5xxx-3# show voice call summary 
PORT           CODEC    VAD VTSP STATE       VPM STATE 
============== ======== === ==================== 
3/0:0.1            g711alaw  y     S_CONNECT 

v5xxx-3# show voice port summary 
                                     IN       OUT 
PORT      CH   SIG-TYPE   ADMIN OPER STATUS   STATUS   EC 
========= == ============ ===== ==== ======== ======== == 
3/0:0     01    xcc-voice   up   none  none   none     y 

v5xxx-3# 

La commande show mgcp statistics fournit également des détails sur la connexion ayant échoué. Essayez de comprendre les informations de champ échouées. L'une des causes de l'échec de la connexion MGCP est le fait que les rapports de point de terminaison sont en mode transitoire et sont temporairement indisponibles lorsque le PGW 2200 envoie un CRCX. Le PGW 2200 sort alors avec une défaillance temporaire en tant que cause et tente à nouveau ce point de terminaison ultérieurement car il n'était qu'en mode transitoire. Ces codes d'identification de circuit SS7 (CIC) n'ont pas de connexion MGCP. La raison de cette situation est que le MGCP sur la passerelle retourne un code d'erreur 400 MGCP (échec temporaire pour les nouveaux messages CRCX envoyés par la passerelle Cisco IOS).

v5xxx-3# show mgcp statistics 
 UDP pkts rx 306, tx 330 
 Unrecognized rx pkts 0, MGCP message parsing errors 0 
 Duplicate MGCP ack tx 0, Invalid versions count 0 
 CreateConn rx 0, successful 0, failed 0 
 DeleteConn rx 0, successful 0, failed 0 
 ModifyConn rx 0, successful 0, failed 0 
 DeleteConn tx 0, successful 0, failed 0 
 NotifyRequest rx 0, successful 0, failed 0 
 AuditConnection rx 0, successful 0, failed 0 
 AuditEndpoint rx 306, successful 305, failed 1 
 RestartInProgress tx 1, successful 1, failed 0 
 Notify tx 0, successful 0, failed 0 
 ACK tx 305, NACK tx 1 
 ACK rx 0, NACK rx 0 

 IP address based Call Agents statistics: 
 IP address 10.48.84.25, Total msg rx 306, 
                  successful 305, failed 1 
 System resource check is DISABLED. No available statistic 

v5xxx-3#

Diagnostiquer les appels suspendus PGW 2200

Cette section décrit les étapes à suivre pour isoler un CIC SS7 suspendu sur le PGW 2200 de la manière dont CIC « x » via la commande MML rtrv-tc : all est bloqué en tant qu'appel OUT sur le PGW 2200. Tout d'abord, émettez la commande prt-call MML sur ce CIC.

Par exemple, sur une connexion de liaison MGCP, si le porteur demandé dans le message SETUP n'est pas disponible pour cet appel, le PGW 2200 génère l'alarme PRI : B-Channel Not Available et signale les erreurs CP_ERR_CHAN_NOT_ACQ dans platform.log. D'autres messages d'erreur peuvent apparaître dans platform.log, selon le type de scénario d'appel que vous exécutez. Pour plus de détails, reportez-vous à la section Diagnostic des appels suspendus du document Dépannage du noeud Cisco MGC pour le PGW 2200.

Il existe trois raisons possibles de la non-disponibilité :

1. Le support n'est pas configuré.

2. Le porteur n'est pas en service. (Par exemple, il est dans un état hors service (OOS), il est dans un état verrouillé/bloqué ou le MGCP a désactivé le point de terminaison.)

3. Le porteur est occupé (condition d'éblouissement).

Effectuez les étapes suivantes :

1. Notez que le PGW 2200 signale des erreurs pour chaque appel.

2. Si vous constatez des erreurs au moins trois à cinq fois en un seul jour sur le même CIC (porteur), il est suspect.

3. Vérifiez l'état du CIC/support à l'aide de la commande rtrv-tr:all MML.

   S'il est inactif, le CIC n'est pas suspendu.

4. Si le CIC SS7 est occupé, émettez la commande prt-call sur ce CIC.

   Pour plus de détails sur la commande prt-call MML, lancez la commande help :prt-call.

   mgc-bru-20 mml> help :prt-call
   �� � � � � � � � � �MGC-01 - Media Gateway Controller 2004-11-29 19:32:35.998 GMT
   � � � � � � � � � � �M� RTRV��� 
   ����� 
   ���������������������������� PRT-CALL -- Print Call
   ���������������������������� ----------------------
         
      Purpose:      Prints diagnostic information about hung calls to a log file.  
                    
      Format:       prt-call:<sigpath>:CIC=<n>|span=<n>[bc=<n>|CID=<n>][,LOG=<logn]
                    [,EVT]
      Input
      Description:  Target parameters are as follows:
                    * sigPath -- Corresponding MML name for any of the 
                      following component types:
                      - Signal path of in-band TDM up to MUX and then 
                        time switched to TDM media and sent to Cisco MGC
                      - Signal path of in-band TDM signaling up to CU 
                        and then encapsulated and sent over IP to the Cisco MGC
   
   <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
   

   Un fichier d'appel d'impression avec l'extension .prt est écrit dans le répertoire /opt/CiscoMGC/var/trace.

5. Ouvrez le fichier et recherchez la chaîne LcmOrigSmState.

   Si vous voyez OrigSmState et TermSmState comme RelIdle, vous n'avez pas de CIC suspendu.

   Exemple :

   VAR LcmOrigSmState: STATE 
   �� { 
   �� OsmRelIdle 
   �� } [8]
   VAR LcmTermSmState: STATE 
   �� { 
   �� TsmRelIdle 
   �� }[8]

   Si OrigSmState ou TermSmState n'est pas RelIdle, vous avez un suspect probable. Voici deux exemples d'appels d'impression CIC bloqués :

   Exemple 1 :

   VAR LcmOrigSmState: STATE 
   �� { 
   �� OsmRelTerm3wAwaitConnDelInd 
   �� }[8] 
   VAR LcmTermSmState: STATE 
   �� { 
   �� TsmRelTermInit 
   �� }[8] 

   Exemple 2 :

   VAR LcmOrigSmState: STATE 
   �� { 
   �� OsmRelOrigInit 
   �� }[8] 
   VAR LcmTermSmState: STATE 
   �� { 
   �� TsmRelIdle 
   �� }[8] 

   Si vous atteignez l'étape suivante, vous avez identifié un CIC suspendu.

6. Émettez la commande MML stp-call pour effacer le CIC suspendu.

   Émettez la commande grep Osm file_name.prt. Vous devriez obtenir OsmRelIdle.

   Émettez la commande grep Tsm file_name.prt. Vous devriez avoir TsmRelIdle.

   Si vous ne voyez pas OsmRelIdle et TsmRelIdle, et si cette condition persiste après avoir émis une autre commande prt-call (peut faire partie de transitoire), le CIC est probablement suspendu.

7. Si le problème de la commande stp-call n'est pas résolu, émettez la commande MML kill-call.

   La commande kill-call n'efface pas la connexion dans la passerelle MGCP. Par conséquent, un audit MGCP est requis si vous émettez la commande kill-call. Effectuez l'audit pendant une période de faible trafic. Pour plus de détails sur la commande kill-call, émettez la commande help :kill-call :

   � �PGW2200A mml> help :kill-call
   �� � � � � � � � � � �MGC-01 - Media Gateway Controller 2004-11-29 19:34:52.084 GMT
   � � � � � � � � � � � M� RTRV���� 
   ����� 
   ��������������������� KILL-CALL -- Resolve a Stuck CIC
   ��������������������� --------------------------------
   ����� 
   �� Purpose:����� Resolves a stuck or hung CIC (forcefully releases a bearer channel
   ���������������� associated with a single call instance that cannot be returned to
   ���������������� the idle state with the reset-cic or stp-call command) on the MGC.
   ���������������� Note:� This command only releases bearer channels locally on the
   ���������������� MGC. No SS7 messages are sent to the remote call side (destination
   ���������������� MGW). 
   �� Syntax:������ kill-call:<sigpath_name>|<target>:CID=sip call id,confirm
   ���������������� kill-call:<sigpath_name>|<target>:[span= number,]confirm
   ���������������� kill-call:<sigpath_name>|<target>:[cic=<num>], [RNG=number,]com
   ���������������� kill-call:<dest_mgw>:span=<span>,bc=<bearer channel>,[RNG=numbm
   �� Input�������� * sigpath_name -- MML name of the SS7 or ISDN-PRI signal path
   �� Description:
   
   <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
   

8. Créez une demande de service auprès de l'assistance technique Cisco et envoyez le résultat de l'appel pour analyse.

Informations connexes

• Notes techniques de dépannage du commutateur logiciel Cisco PGW 2200
• Assistance produit pour les contrôleurs de signalisation Cisco
• Assistance technique concernant la technologie vocale
• Support produit pour Voix et Communications IP
• Dépannage des problèmes de téléphonie IP Cisco
• Support et documentation techniques - Cisco Systems