PGW 2200 Softswitch PRI-Backhaul-Auflösung

Einführung

Dieses Dokument unterstützt Sie bei der Fehlerbehebung für das PRI-Backhaul auf dem Cisco PGW 2200 im Anrufsteuerungsmodus. Aufgrund der Unterschiede zwischen den Protokollfamilien ist Backhauling in mehrere Kategorien unterteilt. Beispielsweise ISDN für Q Signaling (QSIG) und Digital Private Network Signaling System (DPNSS).

Dieses Dokument behandelt nur das PRI-Backhaul mit dem Cisco PGW 2200.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

• Cisco Media Gateway Controller Software, Version 9

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den Cisco PGW 2200 Software-Versionen 9.3(2) und höher.

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 unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Beschreibung der PRI-Backhaul-Auflösung

PRI/Q.931-Signalisierungs-Backhaul ist die Fähigkeit, die Signalisierung (Ebene Q.931 und höher) zuverlässig von einer PRI-Hauptleitung zu transportieren (siehe Abbildung 1). Dieser PRI-Trunk ist physisch mit einem Media Gateway verbunden, das zur Verarbeitung mit einem Media Gateway Controller (MGC - Cisco PGW 2200) verbunden ist. Das Signalisierungs-Backhaul für ISDN PRI erfolgt an der Layer-2- (Q.921) und Layer-3-Grenze (Q.931). Die unteren Protokollschichten werden auf dem Media Gateway (AS5xx0) terminiert und verarbeitet, während die oberen Schichten per Backhauling zum Cisco PGW 2200 transportiert werden.

Die oberen Protokollschichten werden mithilfe von Reliable User Datagram Protocol (RUDP) over IP per Backhauling oder mithilfe von RUDP an den Cisco PGW 2200 übertragen. RUDP ermöglicht die eigenständige Benachrichtigung über angeschlossene und fehlgeschlagene Sitzungen sowie die sequenzielle Bereitstellung von Signalisierungsprotokollen in einem IP-Netzwerk. Backhaul Session Manager ist eine Softwarefunktion auf dem Cisco PGW 2200 und Media Gateway, die RUDP-Sitzungen verwaltet. Signalisierungs-Backhaul bietet den zusätzlichen Vorteil der Verarbeitung verteilter Protokolle. Dies ermöglicht eine höhere Erweiterbarkeit und Skalierbarkeit. Außerdem wird die Protokollverarbeitung auf niedrigerem Layer vom Cisco PGW 2200 entlastet. Vom Layer-Modell wird das PRI-Backhaul in IP/UDP/RUDP/Backhaul-Session-Manager/PRI ISDN Layer 3 integriert.

Fehlerbehebung

Führen Sie diese Schritte aus, um eine Fehlerbehebung für PRI-Backhaul durchzuführen.

• Schritt 1: Überprüfen Sie die Konfiguration des Cisco Gateways AS5xx0.

• Schritt 2: Überprüfen Sie die Konfiguration des Cisco PGW 2200.

• Schritt 3: Überprüfen Sie den Link Session Manager zwischen dem Cisco AS5xx0 und dem Cisco PGW 2200.

• Schritt 4: Überprüfen Sie den Q.921-Status zwischen dem AS5400 und dem PABX.

Schritt 1: Überprüfen Sie die Konfiguration des Cisco Gateways AS5xx0.

Führen Sie diese Schritte aus, um die Gateway-Konfiguration zu überprüfen.

1. Führen Sie diese Befehle im globalen Konfigurationsmodus aus, um den Backhauling Session Manager so einzurichten, dass er mit dem Cisco PGW 2200 spricht, wenn Sie die IOS®-Fehlermeldung % BSM erhalten: Die Sitzung wird nicht erstellt, die maximale Grenze wird überschritten. Sie können maximal 16 Sitzungen im IOS-Gateway 5xx0 unterstützen.

   backhaul-session-manager
   set set1
   group group1 set set1
   session group group1 x.x.x.x x.x.x.x port priority

   Diese Befehlsausgabe zeigt ein Beispiel:

   backhaul-session-manager
     set pgw-cag client nft
     group pgw-cag set pgw-cag
     session group pgw-cag 213.254.253.140 6000 213.254.252.5 6000 1
     session group pgw-cag 213.254.253.141 6000 213.254.252.5 6000 2
     session group pgw-cag 213.254.253.156 6000 213.254.252.21 6000 3
     session group pgw-cag 213.254.253.157 6000 213.254.252.21 6000 4

   Hinweis: Die Cisco IOS-Konfiguration wird nicht unterstützt, wenn Sie die Backhaul Session Manager-Konfiguration verwenden, um Sitzungen abzuhalten, die auf einen anderen physischen PGW 2200 unter derselben Gruppe verweisen. Sie müssen die beiden PGWs der Serie 2200 in zwei Gruppen unterteilen. Weitere Informationen finden Sie unter Cisco Bug ID CSCec24132 .

2. Geben Sie den Befehl pri-group timeslots 1-31 service mgcp ein, um den Controller für das PRI-Backhauling unter der Controller-Konfiguration einzurichten.

   Beispiel:

   controller E1 7/5
    pri-group timeslots 1-31 service mgcp

   Hinweis: In diesem Konfigurationsbeispiel wird der Controller E1 7/5 verwendet, der zu einem späteren Zeitpunkt die Konfiguration des Cisco PGW 2200 wiedergibt.

3. Fügen Sie den Befehl isdn bind-l3 backhaul xxxx unter der ISDN D-Channel-Konfiguration ein, um eine Verbindung zur ISDN-Layer-2-Schnittstelle mit dem Backhauling-Sitzungsverwalter herzustellen.

   Beispiel:

   !
   interface Serial7/5:15
    no ip address
    isdn switch-type primary-net5
    isdn protocol-emulate network
    isdn incoming-voice modem
    isdn bind-l3 backhaul pgw-cag
    isdn PROGRESS-instead-of-ALERTING
    no isdn outgoing display-ie
    isdn outgoing ie redirecting-number
    isdn incoming alerting add-PI
    no cdp enable

   Hinweis: Wenn Sie den Ursachencode 41 "isdn negotiation-bchan resend-setup" hinzufügen, gilt dieser nur für ausgehende Anrufe und nicht für Anrufe, die vom Router empfangen werden. Diese CLI sendet die Konfiguration ohne die EXCLUSIVE-Anzeige und ermöglicht dem Switch, einen anderen B-Kanal auszuwählen, falls dieser verfügbar ist. Andernfalls wählt der Router, wenn der Switch mit Ursachencode 41 antwortet, einen anderen B-Kanal aus und sendet das Setup erneut.

   Hinweis: Möglicherweise verfügt der Switch nicht über einen B-Kanal, der den Merkmalen in der Setup-Meldung entspricht. In diesem Fall kann der Switch keinen weiteren B-Kanal zuweisen, und auch eine Konfiguration mit einem anderen bevorzugten B-Kanal schlägt fehl.

   Hinweis: Sie können MGCP-NAS und PRI-Backhaul auf dem Controller immer noch nicht gleichzeitig verwenden. Der Befehl extsig mgcp auf dem E1-Controller (erforderlich für MGCP-NAS) verhindert die Konfiguration der PRI-Gruppe auf dem Controller:

   as5400(config)#contro e1 7/0
      as5400(config-controller)#extsig mgcp
      as5400(config-controller)#pri-group service mgcp
      %Default time-slot= 16 in use

4. Führen Sie den Befehl debug backhaul-session-manager aus, um den Backhauling Session Manager zu debuggen.

Schritt 2: Überprüfen der PGW 2200-Konfiguration

Führen Sie diese Schritte aus, um die PGW 2200-Konfiguration zu überprüfen.

1. Fügen Sie IPFASPATH zur Cisco PGW 2200-Konfiguration hinzu.

   prov-add:IPFASPATH:NAME="pri2-sig",DESC="Signalling PRI2 
   withCommunicationNAS02",EXTNODE="NAS02",MDO="ETS_300_102",
   CUSTGRPID="Cisco1",SIDE="network",ABFLAG="n",CRLEN=2

   Dadurch wird sichergestellt, dass die MDO-Variante der IOS-Gateway-Variante entspricht.

   Hinweis: Überprüfen Sie die in dieser Tabelle enthaltene ISDN-Variante.

2. Fügen Sie DCHAN zur Cisco PGW 2200-Konfiguration hinzu.

   prov-add:DCHAN:NAME="pri2-dch1",DESC="Dchannel PRI2 to 
   Project Communication",SVC="pri2-sig",PRI=1,SESSIONSET=
   "mil1-pri2-ses",SIGSLOT=7,SIGPORT=5
   

   Dadurch wird sichergestellt, dass SigSlot/SigPort angegeben werden. Außerdem wird sichergestellt, dass die Cisco Gateway-Ports/-Steckplätze und die Cisco PGW 2200-Ports im DCHAN übereinstimmen.

   Hinweis: Wenn Sie den E1 7/5-Controller auf dem IOS-Gateway verwenden, der den Befehl isdn bind-l3 backhaul IOS enthält, muss SIGSLOT=7,SIGPORT=5 für den MML DCHAN-Befehl dieselben Informationen enthalten.

3. Stellen Sie bei der Bereitstellung der Switch-Trunks sicher, dass Sie den span-Parameter nicht als '0' eingeben. Sie können dies aus dem Inhalt der dritten Spalte in der Datei export_trunk.dat sehen.

   Der span-Wert muss für die Switch-Trunks 'ffff' sein. Geben Sie den Befehl prov-exp:all:dirname="file_name" in der MML-Befehlszeile ein, um das auszuchecken.

   mgcusr@pgw2200-1% mml
   Copyright © 1998-2002, Cisco Systems, Inc.
   Session 1 is in use, using session 2
   pgw2200-1mml> prov-exp:all:dirname="check1"
      MGC-01 - Media Gateway Controller 2005-08-12 17:39:44.209 MEST
      M  RTRV
      "ALL"
      ;
   pgw2200-1 mml> quit

   Öffnen Sie das Verzeichnis /opt/CiscoMGC/etc/cust_specific/check1. Stellen Sie in der Datei export_trunk.dat sicher, dass die dritte Spalte "ffff" anstelle von Nullen (0) enthält. Ist dies nicht der Fall, bearbeiten Sie die Datei und ändern Sie sie.

4. Führen Sie den Befehl prov-add:files:name="BCFile",file="export_trunk.dat",action="Import" aus, um eine MML-Bereitstellungssitzung zu starten, und importieren Sie die Trunks-Datei erneut.

   Die geänderte Datei export_trunk.dat muss sich im Verzeichnis /opt/CiscoMGC/etc/cust_specific/check1 befinden. Denken Sie daran, eine prov-cpy für die neue Konfiguration auszugeben.

5. Geben Sie den MML-Befehl rtrv-alms ein, um die Art des Fehlers zu erklären, der derzeit auftritt.

   rtrv-dest:all 
   
   !--- Shows the MGCP connectivity status of nodes !--- that the PGW 2200 defines.
   
   rtrv-dchan:all
   
   !--- On the active PGW 2200, the status is !--- pri-1:ipfas-1,LID=0:IS. On the standby PGW 2200, !--- the status is pri-1:ipfas-1,LID=0:OOS,STBY.
   
   rtrv-iplnk:all
   
   !--- All of the iplnk are on the standby PGW 2200 in the !--- iplnk-1:OOS,STBY status. They are actually in !--- the OOS state because no message is handled by them. !--- On the active PGW 2200, you see the status as iplnk-1:IS. !--- The other statuses are explained in the !--- MML Command Reference Chapter of the Cisco MGC Software !--- MML Command Reference Guide. 
   
   rtrv-tc:all 
   
   !--- Shows the status of all call channels.
   
   rtrv-alms::cont 
   
   !--- Check the Alarms status on the Cisco PGW 2200.
   
   

   Sie können die Details auch aus /opt/CiscoMGC/var/log für die Datei alm.csv abrufen, indem Sie den Befehl perl - perl -F, -anwe'print unpack("x4 A15", localtime($F[1]))," verwenden.$F[2]: @F[0,3..7]"' < meas.csv.

   Hinweis: Verwenden Sie gmtime anstelle von localtime, wenn Sie in UTC-Zeitstempel konvertieren möchten. Die Ausgabe hat folgendes Format:

   Aug 10 15:58:53.946: 0 0 1 "Fail to communicate with peer module 
   over link B" "ipAddrPeerB" "ProvObjManagement"
   
   Aug 10 21:29:30.934: 0 1 1 "Provisioning: Dynamic Reconfiguration" 
   "POM-01" "ProvObjManagement"
   
   Aug 10 21:29:48.990: 0 1 2 "Signal Channel Failure" "c7iplnk1-ls-stp1" "IosChanMgr"
   Aug 10 21:29:49.620: 0 0 2 "Non-specific Failure" "ls-stp1" "IosChanMgr"
   Aug 10 21:29:49.620: 0 0 2 "Signal Channel Failure" "c7iplnk1-ls-stp1" "IosChanMgr"
   Aug 10 21:29:49.630: 0 0 2 "SS7 Signaling Service Unavailable" "srv-bru8" "IosChanMgr" 

6. Geben Sie den UNIX-Befehl tail -f platform.log ein, um platform.log im Verzeichnis /opt/CiscoMGC/var/log zu überprüfen.

   Weitere Informationen finden Sie unter Protokollmeldungen.

7. Überprüfen Sie die ISDN-Variante.

   Der Befehl isdn-switch-type primary-net5 wird auf dem IOS-Gateway verwendet. Beim Cisco PGW 2200 ist er mit mdo=ETS_300_102 im IPFASPATH verknüpft.

   In dieser Tabelle sind die unterstützten ISDN-Varianten für den Cisco PGW 2200 aufgeführt:

   Variantenname	ISDNPRI	Spezifikation	Anmerkungen
   ETS_300_102	ISDNPRI	ETSI 300_102	ETSI PRI
   ETS_300_102_C2	ISDNPRI	ETSI 300_102	ETSI PRI
   ATT_41459	ISDNPRI	AT&T 41459	ATT ISDN PRI
   ATT_41459_C2	ISDNPRI	(Nortel Meridian)	Cisco AT&T PRI
   ETS_300_172	ISDNPRI	ETSI 300-172	ETSI-QSIG
   Q931_AUSTRALIEN	ISDNPRI	Frage 931	Australien PRI
   Frage 931	ISDNPRI	Frage 931	Frage 931
   Q931_SINGAPUR	ISDNPRI	Frage 931	Singapur PRI

   Diese Beispielbefehlsausgabe stammt vom IOS-Gateway.

   v5350-3(config)#isdn switch-type ?
     primary-4ess    Lucent 4ESS switch type for the U.S.
     primary-5ess    Lucent 5ESS switch type for the U.S.
     primary-dms100  Northern Telecom DMS-100 switch type for U.S.
     primary-net5    NET5 switch type for UK, Europe, Asia , Australia
     primary-ni      National ISDN Switch type for the U.S.
     primary-ntt     NTT switch type for Japan
     primary-qsig    QSIG switch type
     primary-ts014   TS014 switch type for Australia (obsolete)
   v5350-3(config)#

Schritt 3: Überprüfen Sie die Verbindung zwischen RUDPV1 und Session Manager zwischen dem AS5xx0 und dem PGW 2200.

Führen Sie diese Schritte aus, um den Link RUDPV1 und Session Manager zu überprüfen.

1. Geben Sie die folgenden show- und clear-Befehle ein:

   • show rudpv1 failure - Zeigt alle Fehler an, die rudpv1 erkannt hat. Sie sehen z. B. SendWindowFullFailures. Dies weist darauf hin, dass Überlastungen beim Senden von Segmenten an die IP-Verbindung auftreten.

   • show rudpv1 parameters: Zeigt die rudpv1-Verbindungsparameter sowie den Status und die Parameter aller aktuellen Sitzungen an. Der Verbindungstyp ist entweder AKTIV oder PASSIVE. Active gibt an, dass dieser Peer der Client war und die Verbindung initiiert hat. Passive gibt an, dass dieser Peer der Server war und die Verbindung überwacht hat.

   • show rudpv1 statistics - Zeigt interne Statistiken von rudpv1 und Statistiken für alle aktuellen Sitzungen und die kumulierten Statistiken über alle rudp-Verbindungen seit dem letzten Neustart des Felds oder der Ausführung eines klaren Statistikbefehls an.

   • clear rudpv1 statistics: Löscht alle gesammelten rudpv1-Statistiken. Führen Sie diesen Befehl aus, wenn aktuelle Statistiken erforderlich sind und das IOS-Gateway über einen längeren Zeitraum ausgeführt wird.

2. Geben Sie den Befehl debug rudpv1 aus.

   #debug rudpv1 ?
     application  Enable application debugging
     client       Create client test process
     performance  Enable performance debugging
     retransmit   Enable retransmit/softreset debugging
     segment      Enable segment debugging
     server       Create server test process
     signal       Show signals sent to applications
     state        Show state transitions
     timer        Enable timer debugging
     transfer     Show transfer state information

   In einem Live-System sind die Debug für Leistung, Zustand, Signal und Übertragung die nützlichsten. Die Debugger für Anwendung, Neuübertragung und Timer generieren entweder zu viel Ausgabe und führen zum Ausfall der Links, oder sie waren nur für interne Debugzwecke nützlich.

   Vorsicht: Bei diesem Debugging wird für jedes gesendete oder empfangene Segment eine Zeile ausgegeben. Wenn ein erheblicher Teil des Datenverkehrs ausgeführt wird, führt dies zu Zeitverzögerungen, die Verbindungsausfälle verursachen.

3. Geben Sie den Befehl show backhaul-session-manager und show backhaul set all befehls ein, um festzustellen, ob die IP-Leitung, die die Signalisierung transportiert, in Ordnung ist.

   NAS02#show backhaul-session-manager group status all
   Session-Group
      Group Name   : pgw-cag
      Set Name     : pgw-cag
      Status       : Group-Inservice
      Status (use) : Group-Active
   
   NAS02#show backhaul  set all
   Session-Set
      Name   : pgw-cag
      State  : BSM_SET_ACTIVE_IS
      Mode   : Non-Fault-Tolerant(NFT)
      Option : Option-Client
      Groups : 1
      statistics 
           Successful switchovers:0 
           Switchover Failures: 0 
           Set Down Count 1 
           Group: pgw-cag

   Die verschiedenen Status für den Show Backhaul-Satz lauten wie folgt:

   • BSM_SET_IDLE

   • BSM_SET_OOS

   • BSM_SET_STDBY_IS

   • BSM_SET_ACTIVE_IS

   • BSM_SET_FULL_IS

   • BSM_SET_SWITCH_OVER

   • BSM_SET_UNKNOWN

   Wenn alles in Ordnung ist, bestätigt dies auch, dass die entsprechende Verbindung für den Sitzungssatz auf dem Cisco PGW 2200 über den In-Service-Status verfügt (MML-Befehl rtrv-iplnk). Die Leitung zwischen dem Cisco PGW 2200 und dem IOS-Gateway AC5xx0 ist nun voll betriebsbereit. Im nächsten Schritt wird die Grenze zwischen dem Cisco IOS-Gateway AS5xx0 und dem PABX überprüft.

Schritt 4: Überprüfen Sie den Q.921-Status zwischen dem AS5xx0 und dem PABX.

Führen Sie diese Schritte aus, um den Q.921-Status zwischen dem AS5xx0 und dem PABX zu überprüfen.

1. Geben Sie den show isdn status und die show isdn service-Befehle ein.

   NAS02#show isdn status 
   Global ISDN Switchtype = primary-net5
   ISDN Serial7/5:15 interface
           ******* Network side configuration ******* 
           dsl 0, interface ISDN Switchtype = primary-net5
           L2 Protocol = Q.921  L3 Protocol(s) = BACKHAUL 
       Layer 1 Status:
           ACTIVE
       Layer 2 Status:
           TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
       Layer 3 Status:
           0 Active Layer 3 Call(s)
       Active dsl 0 CCBs = 0
       The Free Channel Mask:  0xFFFF7FFF
       Number of L2 Discards = 4, L2 Session ID = 25
       Total Allocated ISDN CCBs = 0
   
   
   NAS02#show isdn service
   PRI Channel Statistics:
   ISDN Se7/5:15, Channel [1-31]
     Configured Isdn Interface (dsl) 0
      Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)
       Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
       Service State (0=Inservice 1=Maint 2=Outofservice)
       Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

   Hier sehen Sie das Problem, dass auf der PGW 2200-Seite Q.921 nicht angezeigt wird, das dem Ziel und dem D-Kanal entspricht, der sich im Out-of-Service-Zustand befindet. Die erste Möglichkeit besteht in einer Diskrepanz in der Konfiguration auf Netzwerkseite des Q.921. Es ist einfach zu erkennen, dass dies nicht die Ursache des Problems ist, da das Problem nicht durch das Entfernen des isdn-protokollemulierten Netzwerks aus der AS5400-Konfiguration gelöst wurde.

2. Sehen Sie sich die Q.921-Debuggen an, um zu erfahren, warum der Q.921-Link nicht angezeigt wird. Dies ist die Debug-Ausgabe.

   Apr 14 10:57:23.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0
   Apr 14 10:57:24.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0
   Apr 14 10:57:25.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0
   Apr 14 10:57:45.419: ISDN Se7/5:15 Q921: Net RX <- BAD FRAME(0x02017F)
   Apr 14 10:57:46.419: ISDN Se7/5:15 Q921: Net RX <- BAD FRAME(0x02017F)

   Das AS5400 überträgt ein Q.921 SABME, um die Verbindung zu initialisieren, und empfängt einen Frame, den es nicht interpretieren konnte (schlechter Frame). Die Möglichkeiten sind:

   • Hardwareproblem auf dem E1 für diesen AS5400.

   • E1-Schleife auf der Remote-Seite.

   • Hardware- oder Konfigurationsprobleme auf der Remote-Seite.

   Diese erste Möglichkeit wird ausgeschlossen, indem die Konfiguration auf ein anderes nicht verwendetes E1 auf demselben AS5400 verschoben wird. Das Problem sieht genau gleich aus. Der Kunde überprüft auch, ob an der E1-Leitung keine Schleife vorhanden ist. Überprüfen Sie an diesem Punkt die PABX-Seite.

3. Führen Sie den Befehl show controller aus, um mögliche Layer-1-Fehler zu überprüfen.

   #show controllers E1
    Framing is CRC4, Line Code is HDB3, Clock Source is Line.
     Data in current interval (480 seconds elapsed):
        107543277 Line Code Violations, 0 Path Code Violations
        120 Slip Secs, 480 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
        0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 480 Unavail Secs
     Total Data (last 24 hours)
        3630889 Line Code Violations, 4097 Path Code Violations,
        2345 Slip Secs, 86316 Fr Loss Secs, 20980 Line Err Secs, 0 Degraded Mins,
        1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 86317 Unavail Secs

4. Wenn Sie den Befehl shutdown unter dem Controller ausführen, wird folgende Debugmeldung ausgegeben:

   000046: Jun 2 16:19:16.740: %CSM-5-PRI: delete PRI at slot 7, unit 2, channel 0
   000047: Jun  2 16:19:16.744: %CONTROLLER-5-UPDOWN: Controller E1 7/2, changed sn
   000048: Jun  2 16:19:16.744: SESSION: PKT: xmt. (34) bufp: 0x6367F52C, len: 16        

   Geben Sie den MML-Befehl rtrv-alms auf dem PGW 2200 aus:

   mml> rtrv-alms
     MGC-02 - Media Gateway Controller 2005-06-02 18:11:29.285 GMT
       M  RTRV                                                                                                                                                                                                                            "pri-bucegi: 2005-06-02 17:28:15.301 GMT,ALM=\"FAIL\",SEV=MJ" 

   Wenn Sie den Befehl no shutdown unter dem Controller ausführen, wird diese Debug-Meldung im IOS-Gateway angezeigt:

   000138: Jun  2 17:03:25.350: %CONTROLLER-5-UPDOWN: Controller E1 7/2, changed sp
   000139: Jun  2 17:03:25.350: %CSM-5-PRI: add PRI at slot 7, unit 2, channel 15 0 

   Weitere IOS-Debug-Befehle finden Sie unter PRI/Q.931 Signaling Backhaul für Call Agent-Anwendungen.

Zugehörige Informationen

• Cisco PGW 2200 Softswitch - Technische Hinweise
• Technische Dokumentation 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