Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
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)
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.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
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.
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#
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é :
Le support n'est pas configuré.
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.)
Le porteur est occupé (condition d'éblouissement).
Effectuez les étapes suivantes :
Notez que le PGW 2200 signale des erreurs pour chaque appel.
Si vous constatez des erreurs au moins trois à cinq fois en un seul jour sur le même CIC (porteur), il est suspect.
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.
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.
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.
É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.
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>
Créez une demande de service auprès de l'assistance technique Cisco et envoyez le résultat de l'appel pour analyse.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
02-Feb-2006 |
Première publication |