PGW 2200 Softswitch-Fehlerbehebung für MGCP-Hung-Anrufe

  

Einführung

In diesem Dokument werden die Elemente erläutert, die mit abgebrochenen Anrufen am Gateway für die Cisco PGW 2200 Softswitch-Lösung für die Anrufsteuerung verknüpft sind, in Kombination mit einem Szenario, das Ihnen bei der Fehlerbehebung helfen soll. Derzeit ist das Cisco IOS® Gateway nicht in der Lage, das Service Processing Element (SPE) (das im Dokument Understanding NextPort SPE Versions erläutert wird) mit einer DS0- (Digital Service Zero)- und MGCP-Verbindung (Media Gateway Control Protocol) zu korrelieren. Ohne Cisco IOS-Debugging ist es nicht möglich, einem digitalen Signalprozessor (DSP) eine DS0-Zuordnung mit dem Cisco IOS-Befehl show tdm mapping für MGCP-basierte Anruftypen zuzuordnen. Zur Behebung dieses Problems für die Cisco IOS Gateways AS5350, AS5400 und AS5850 wurde die Cisco Bug-ID CSCdz47711 (nur registrierte Kunden) vorgestellt.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

• Dokumentation für Cisco Media Gateway Controller Software, Version 9

• Versionshinweise für die Cisco Media Gateway Controller Software Version 9.3(2)

• Versionshinweise für die Cisco Media Gateway Controller Software Version 9.4(1)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Cisco PGW 2200 Softwareversionen 9.3(2) und 9.4(1)

• Cisco IOS Gateway Version 12.3 und 12.3T

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Beheben von MGCP-Hung-Anruffehlern

Wenn Sie ein hängendes MGCP-Anrufszenario sehen, ist die Verwendung von Debuggen nicht sinnvoll. Bei einem Live-System ist es zudem schwierig, die synchrone Payload-Umschlageinheit (SPE) mit einer DS0- und MGCP-Verbindung zu korrelieren. Wenn Sie die DS0 und den DSP für einen aktiven Anruf korrelieren möchten, bietet dieses Dokument eine Erläuterung.

Stellen Sie vor dem Start auf dem PGW 2200 sicher, dass die MgcpBehavior-Einstellung (Man-Machine Language [MML] verwenden) einen Wert aufweist, der für das Cisco IOS-Gateway 2 entspricht. Weitere Informationen finden Sie im Dokument Dateiparameter für XECfgParm.dat.

PGW 2200 Version 9.1(5):

• Wenn MgcpBehavior 1 (Gateways, die nicht auf der Cisco IOS Software basieren, z. B. das Cisco Voice Interworking Service Module [VISM] und Cisco MGX) nach Erhalt des Fehlercodes 501, setzt der PGW 2200 die Schaltung auf einen Zustand, um eine weitere Verwendung zu verhindern. Weitere Informationen finden Sie im Dokument Komponenten und Eigenschaften.

• Wenn das MgcpBehavior 2 (Cisco IOS-Gateway) entspricht, setzt der PGW 2200 nach Erhalt des Fehlercodes 501 die Leitung auf einen Zustand, um eine weitere Verwendung zu verhindern. Nach Erhalt des Fehlercodes 502 als Antwort auf die erste Create Connection (CRCX) sendet der PGW 2200 die DLCX-Nachricht (MGCP Delete Connection), gefolgt von einer weiteren MGCP-CRCX-Nachricht. Wenn vom Cisco IOS-Gateway ein weiterer 502-Fehlercode zurückgegeben wird, wird der Anruf beendet. Es wird davon ausgegangen, dass der Stromkreis wieder verwendbar ist. Weitere Informationen finden Sie im Dokument Komponenten und Eigenschaften.

PGW 2200 Version 9.2(2) und höher:

• Wenn MgcpBehavior 1 (für VISM und MGX) entspricht, legt der PGW 2200 nach Erhalt des Fehlercodes 501 den Schaltkreis auf einen Zustand fest, um eine weitere Verwendung zu verhindern.

• Wenn das MgcpBehavior 2 (Cisco IOS-Gateway) entspricht, setzt der PGW 2200 nach Erhalt des Fehlercodes 501 die Leitung auf einen Zustand, um eine weitere Verwendung zu verhindern. Nach Erhalt des 502-Fehlercodes (für die erste MGCP CRCX-Nachricht) sendet der PGW 2200 eine MGCP-DLCX-Nachricht, gefolgt von einer weiteren MGCP-CRCX-Nachricht. Wenn der PGW 2200 einen weiteren 502-Fehlercode empfängt, wird der Anruf beendet. Der Schaltkreis ist auf einen Zustand eingestellt, um eine weitere Verwendung zu verhindern. Gleichzeitig ist der Stromkreis in einer Liste von Stromkreisen enthalten, auf denen eine Hintergrundprüfung (Mini) durchgeführt wird. Diese Prüfung sendet eine erzwungene MGCP-DLCX-Nachricht für alle Schaltungen in der Mini-Audit-Liste, um den Schaltungsstatus synchron mit dem PGW 2200 zu bringen.

Die MGCP-Reaktionszeit-Out wird wie eine vorübergehende Fehlerbedingung GW_HELD behandelt, und die MGCP-DLCX-Nachricht wiederholt sich jede Minute. Nur der Empfang der RSIP-Meldung (Restart in Progress) (graceful/ced), des MGCP-Fehlercodes 500 oder eines der speziellen 501/502-Fehlercodes verursacht einen permanenten Ausfall, wenn die MgcpBehavior-Eigenschaft entsprechend festgelegt wird. Beachten Sie, dass Fehlercode 500 unabhängig vom MgcpBehavior immer einen Fehler verursacht, da er "Endpunkt unbekannt" entspricht.

Hinweis: Mit PGW 2200 Version 9.5(2) und höher hat der PGW 2200 MGCP 1.0 implementiert. Dadurch wird die Stabilität erhöht und die Fehlerbearbeitung verbessert.

Meldung	Cisco IOS-Software (5xxx)
CRCX	502
Verbindung ändern (MDCX)	515
DLCX	250
Benachrichtigungsanfrage (RQNT)	400
Audit-Endpunkt (AUEP)	500

Der Grund hierfür ist, dass der PGW 2200 über einen Überwachungsmechanismus verfügt, um die Kanalstatus mit dem Netzwerkelement zu synchronisieren, z. B. mit einem Cisco IOS-Gateway, mit dem er kommuniziert. Das Audit-Programm für den PGW2200 wird um 4:00 Uhr ausgeführt. (0400) jeden Morgen und führt diese Aktionen in verschiedenen Szenarien durch:

• Szenario 1: Wenn der Kanalstatus auf dem PGW 2200 und dem Cisco IOS-Gateway "BUSY" lautet, wird keine Aktion ausgeführt.

• Szenario 2: Wenn der Kanalstatus auf dem PGW 2200 sowie auf dem Cisco IOS-Gateway IDLE ist, wird ein MGCP-DLCX an das Cisco IOS-Gateway für diesen Endpunkt gesendet. Dadurch wird eine aufgehängte Verbindung gelöscht, sofern diese vorhanden ist.

• Szenario 3: Wenn der Kanalstatus auf dem PGW 2200 und IDLE auf dem Cisco IOS-Gateway "BUSY" lautet, gibt der PGW 2200 den Anruf frei und sendet ein DLCX an das Cisco IOS-Gateway, um den entsprechenden Endpunkt zur Synchronisierung des Cisco IOS-Gateways zu veranlassen.

• Szenario 4: Wenn der Kanal IDLE auf dem PGW 2200 und BUSY auf dem Cisco IOS-Gateway ist, sendet der PGW 2200 einen MGCP-DLCX an das Cisco IOS-Gateway, damit der entsprechende Endpunkt das Cisco IOS-Gateway synchronisiert. Das PGW 2200- und Cisco IOS-Gateway-Audit löscht den Kanal auf dem Cisco IOS-Gateway.

  Wenn die ursprüngliche Prozedur, die von der Message Definition Language (MDL) aufgerufen wird, den Schaltkreis nicht in den Leerlaufzustand bringt, wird eine Engine-Schnittstelle aufgerufen, um den Endpunkt als deaktiviert zu markieren und einen Eintrag für den speziellen Prüfmechanismus für hängende/stranded Endpunkte des Motors zu erstellen.

  Um den MgcpBehavior-Wert für das Cisco IOS-Gateway zu ändern, ändern Sie die MgcpBehavior-Eigenschaft für die MGCPPATHs in 2.

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

  Hinweis: In einigen Fällen wird ein erneutes Laden des Cisco IOS-Gateways angefordert, um von einer reinen Situation zu starten. Bevor Sie dies tun, kann eine detaillierte Protokollierung des Cisco IOS-Gateways zur Lösung des Problems beitragen.

Befehle anzeigen

Die hier beschriebenen Befehle show können Ihnen bei der Überprüfung und Fehlerbehebung bei einem abgebrochenen Anruf helfen.

Bestimmte show-Befehle werden vom Output Interpreter Tool unterstützt (nur registrierte Kunden), mit dem Sie eine Analyse der show-Befehlsausgabe anzeigen können.

Die Aktiv-Sprachübertragung anzeigen Kompakt-Dauer mehr ? kann beim Auffinden von Anrufen mit langer Laufzeit auf dem Cisco IOS-Gateway helfen:

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

Die Anzeige der aktiven Sprachübertragung Außerdem können Richtlinien bereitgestellt werden, wenn der Befehl "| Duration 4d" einschließen soll:

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

V5xxx-3#

Mithilfe dieser show-Befehle kann der aufgehängte Anruf ermittelt werden:

• show mgcp statistics: Zeigt MGCP-Statistiken über empfangene und übertragene Netzwerknachrichten an.

• show mgcp connection: Zeigt Informationen für aktive Verbindungen an, die vom MGCP gesteuert werden.

• show rtpspi statistics (rtpspi statistics): Zeigt die Statistiken der Service Provider Interface (SPI) für das Real-Time Transport Protocol (RTP) an.

• show ip socket: Zeigt Informationen zum IP-Socket an.

• show voice call summary: Zeigt eine Zusammenfassung aller Sprach-Ports an.

• show voice port summary: Zeigt zusammengefasste Konfigurationsinformationen zu einem bestimmten Sprach-Port an.

• show vtsp call fsm: Zeigt den vollständigen Verlauf aller Übergänge des Finite State Machine (FSM) des Sprachtelefonie-Service-Providers (VTSP) an.

• show csm voice: Zeigt die Informationen zum Call Switching Module (CSM) an. Die Informationen sind der CSM-Zustand, in dem sich der Computer für den mit diesem DSP-Kanal verknüpften Anruf befindet, die Startzeit des Anrufs, die Endzeit des Anrufs und der Kanal auf dem Controller, der vom Anruf verwendet wird.

  Hinweis: Wenn es sich um ein MGCP-Signalisierungssystem 7 (SS7) handelt, wird dieser Befehl nicht häufig verwendet.

• show spe: Zeigt den SPE-Status an.

• show spe voice summary: Zeigt den SPE-Sprachstatus an.

• show port operations-status slot/port (für den vermuteten DSP) - Zeigt Informationen für alle Ports im angegebenen Steckplatz und in der angegebenen SPE an.

• show port voice log Reverse Slot/Port (für den vermuteten DSP) - Zeigt Informationen für alle Ports im angegebenen Slot und in der SPE an.

Die Informationen in der Reihe von show-Befehlen, die auf MGCP-Anrufe über AS5xxx-Gateways folgt, einschließlich Call_ID©) Informationen (in Fettschrift hervorgehoben) für diesen Anruf. Dies ist auch wichtig, wenn Sie eine Fehlerbehebung durchführen möchten. Der MGCP-Endpunkt befindet sich mit dem Befehl debug mgcp packet der Cisco IOS-Software oder mit der Cisco Snooper-Anwendung.

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 

Hinweis: Überprüfen Sie den M-Status, der mit dem MGCP-Modus für die Fehlerbehebung bei Stummschaltung auf dem Cisco PGW 2200 verknüpft ist.

Der Befehl show call active voice brief liefert Informationen über Übertragungs-/Empfangs- (Rx-)Paketinformationen.

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# 

Geben Sie den Befehl show voip rtp connections ein, um Details zum Remote Gateway zu erfahren. Dazu gehören die CallId-Informationen für diesen Anruf. (In diesem Fall ist CallId 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# 

Der Befehl show vtsp call fsm ist ein versteckter Befehl der Cisco IOS Software und wird nur für den technischen Support von Cisco und das Cisco Development Team verwendet. Mit diesem Befehl können Sie nach den Gehäusen mit der Phrase "Invalid FSM" (Ungültiger FSM) suchen. Der Befehl show vtsp call fsm zeigt den vollständigen Verlauf aller VTSP-FSM-Übergänge an. Sie wird automatisch ausgelöst, wenn ein DSP-Problem auftritt, während die Befehlszeilenschnittstelle debug vtsp error (CLI) aktiviert ist.

Hinweis: Sie können auch CallId = 1 in Hex umwandeln, was Ihnen ID = 0x1 gibt.

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# 

Um herauszufinden, mit welchem DSP der Anruf verbunden wird, führen Sie den Befehl show tdm mapping aus, und verknüpfen Sie die Details mit dem Endpunkt, für den Sie die Ablaufverfolgung durchführen. In diesem Fall ist es 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# 

Diese Verbindung ist mit SPE 1, Port 1 verbunden. Geben Sie den Befehl show spe ein, um die Status Port und Call (Anruf) zu ermitteln.

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# 

In diesem Fall können Sie herausfinden, ob Pakete an diesem SPE-Port immer noch ein- und ausgesendet werden, wenn Sie den Befehl show port Operational-status 1/0 (für den vermuteten DSP) ausführen:

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# 

Geben Sie diesen Befehl mehrmals an, um Details über die Art der Verbindung anzugeben, die mit dem Remote Gateway verbunden ist. Geben Sie diesen Befehl auf dem Local/Remote Gateway ein, um den Status zu ermitteln.

Wenn Sie einen aufgehängten Aufruf haben, können Sie die Befehle debug vtsp error und debug mgcp packet endpoint S3/DS1-0/1 ausführen. Wenn Sie den MGCP-Endpunkt herunterfahren, wird folgende Debugmeldung angezeigt:

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 

Diese Befehle sind auch nützlich:

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# 

Der Befehl show mgcp statistics enthält auch Details zur fehlgeschlagenen Verbindung. Versuchen Sie, die fehlerhaften Feldinformationen zu verstehen. Eine der Ursachen für die fehlgeschlagene MGCP-Verbindung ist die Tatsache, dass Endpunktberichte im transienten Modus sind und vorübergehend nicht verfügbar sind, wenn der PGW 2200 ein CRCX sendet. Der PGW 2200 gibt dann einen temporären Ausfall als Ursache frei und versucht diesen Endpunkt zu einem späteren Zeitpunkt erneut, da er sich nur im transienten Modus befand. Diese SS7-Circuit Identification Codes (CICs) verfügen über keine MGCP-Verbindung. Der Grund dafür ist, dass das MGCP auf dem Gateway einen 400-MGCP-Fehlercode zurückgibt (temporärer Fehler bei neuen CRCX-Nachrichten, die vom Cisco IOS-Gateway gesendet werden).

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#

Diagnose von PGW 2200-Hung-Anrufen

In diesem Abschnitt werden Schritte beschrieben, um einen nicht angenommenen SS7-CIC auf dem PGW 2200 in der Art und Weise zu isolieren, wie CIC "x" über den MML-Befehl rtrv-tc:all als Call OUT auf dem PGW 2200 feststeckt. Führen Sie zunächst den Befehl für den MML-Port-Anruf auf diesem CIC aus.

Wenn beispielsweise der in der SETUP-Nachricht angeforderte Träger für einen MGCP-Backhaul-Anruf nicht verfügbar ist, generiert der PGW 2200 den Alarm PRI: B-Channel nicht verfügbar und meldet CP_ERR_CHAN_NOT_ACQ-Fehler in platform.log. Weitere Fehlermeldungen können in platform.log angezeigt werden, je nachdem, welcher Anrufszenario ausgeführt wird. Weitere Informationen finden Sie im Abschnitt Diagnose von Hung-Anrufen im Dokument Problembehandlung beim Cisco MGC-Knoten für den PGW 2200.

Es gibt drei mögliche Gründe für die Nichtverfügbarkeit:

1. Der Träger ist nicht konfiguriert.

2. Der Träger ist nicht in Betrieb. (Beispielsweise befindet es sich im Out-of-Service-Zustand (OOS), befindet sich im gesperrten/blockierten Zustand, oder der MGCP deaktiviert den Endpunkt.)

3. Der Träger ist beschäftigt (Glare Bedingung).

Gehen Sie wie folgt vor:

1. Beachten Sie, dass der PGW 2200 für jeden Anruf Fehler meldet.

2. Wenn an einem einzigen Tag mindestens drei- bis fünfmal an einem CIC (Träger) Fehler auftreten, ist dies vermutet.

3. Überprüfen Sie den Status des CIC/Trägersystems mithilfe des Befehls rtrv-tr:all MML.

   Wenn der CIC nicht aktiv ist, wird er nicht aufgehängt.

4. Wenn der CIC SS7 besetzt ist, geben Sie den Befehl port-call auf diesem CIC aus.

   Weitere Informationen zum MML-Befehl für den Anruf erhalten Sie mit dem Befehl 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>
   

   Eine Anrufdatei für den Druck mit der Erweiterung .prt wird im Verzeichnis /opt/CiscoMGC/var/trace geschrieben.

5. Öffnen Sie die Datei, und suchen Sie nach der Zeichenfolge LcmOrigSmState.

   Wenn Sie OrigSmState und TermSmState als RelIdle sehen, ist der CIC nicht hängen.

   Beispiel:

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

   Wenn entweder OrigSmState oder TermSmState nicht RelIdle ist, besteht ein wahrscheinlicher Verdacht. Im Folgenden sind zwei Beispiele für aufgehängte CIC-Anrufe aufgeführt:

   Beispiel 1:

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

   Beispiel 2:

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

   Wenn Sie den nächsten Schritt erreichen, haben Sie einen ausgefallenen CIC identifiziert.

6. Geben Sie den Befehl stp-call MML ein, um den nicht mehr reagierenden CIC zu löschen.

   Geben Sie den Befehl grep Osm file_name.prt ein. Sie sollten OsmRelIdle erhalten.

   Geben Sie den Befehl grep Tsm file_name.prt ein. Sie sollten TsmRelIdle erhalten.

   Wenn Sie OsmRelIdle und TsmRelIdle nicht sehen und diese Bedingung weiter besteht, nachdem Sie einen anderen Port-Call-Befehl ausgeben (kann Teil eines transienten Befehls sein), wird der CIC wahrscheinlich nicht mehr angezeigt.

7. Wenn das Problem mit dem Befehl stp-call nicht behoben werden kann, führen Sie den MML-Befehl kill-call aus.

   Der Befehl kill-call löscht die Verbindung im MGCP-Gateway nicht. Daher ist eine MGCP-Überwachung erforderlich, wenn Sie den Befehl kill-call ausgeben. Führen Sie das Audit während eines Zeitraums mit geringem Datenverkehr durch. Weitere Einzelheiten zum Befehl kill-call erhalten Sie mit dem Befehl 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. Erstellen Sie eine Serviceanfrage beim technischen Support von Cisco, und reichen Sie die Anrufausgabe zur Analyse ein.

Zugehörige Informationen

• Cisco PGW 2200 Softswitch - Fehlerbehebung in technischen Hinweisen
• Produktsupport für Cisco Signaling Controller
• Unterstützung von Sprachtechnologie
• Produkt-Support für Sprach- und IP-Kommunikation
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support und Dokumentation - Cisco Systems