PGW 2200 Softswitch PRI Backhaul Risoluzione

Introduzione

Questo documento aiuta a risolvere i problemi relativi alle informazioni per il backhaul PRI su Cisco PGW 2200 in modalità Call Control. A causa delle differenze tra le famiglie di protocolli, il backhauling è diviso in diverse categorie. Ad esempio, ISDN per QSIG (Q Signaling) e DPNSS (Digital Private Network Signaling System).

Questo documento copre solo il backhaul PRI con Cisco PGW 2200.

Prerequisiti

Requisiti

Questo documento è utile per conoscere i seguenti argomenti:

• Software Cisco Media Gateway Controller release 9

Componenti usati

Il riferimento delle informazioni contenute in questo documento è il software Cisco PGW 2200 versione 9.3(2) e successive.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Descrizione risoluzione backhaul PRI

PRI/Q.931 signaling backhaul è la capacità di trasportare in modo affidabile il segnale (livelli Q.931 e superiori) da un trunk PRI (vedere la Figura 1). Questo trunk PRI è fisicamente connesso a un media gateway che si connette a un controller media gateway (MGC - Cisco PGW 2200) per l'elaborazione. Il backhaul di segnalazione per PRI ISDN si verifica al limite di layer 2 (Q.921) e layer 3 (Q.931). I livelli inferiori del protocollo vengono terminati ed elaborati sul media gateway (AS5xx0), mentre i livelli superiori vengono instradati al Cisco PGW 2200.

Gli strati superiori del protocollo vengono ritorti o trasportati sul Cisco PGW 2200 utilizzando il protocollo RUDP (Reliable User Datagram Protocol) su IP. RUDP fornisce la notifica autonoma delle sessioni connesse e non riuscite e il recapito garantito in sequenza dei protocolli di segnalazione su una rete IP. Backhaul Session Manager è una funzione software di Cisco PGW 2200 e media gateway che gestisce le sessioni RUDP. Il backhaul di segnalazione offre l'ulteriore vantaggio dell'elaborazione di protocolli distribuiti. Ciò consente una maggiore espandibilità e scalabilità. Inoltre, scarica l'elaborazione del protocollo del livello inferiore da Cisco PGW 2200. Dal modello a livelli, il backhaul PRI è integrato in IP/UDP/RUDP/Backhaul-Session-Manager/PRI ISDN Layer 3.

Risoluzione dei problemi

Completare questa procedura per risolvere i problemi di PRI Backhaul.

• Passaggio 1: Controllare la configurazione di Cisco Gateway AS5xx0.

• Passaggio 2: Controllare la configurazione di Cisco PGW 2200.

• Passaggio 3: Controllare il collegamento al Session Manager tra Cisco AS5xx0 e Cisco PGW 2200.

• Passaggio 4: Controllare lo stato di Q.921 tra AS5400 e PABX.

Passaggio 1: Controllare la configurazione di Cisco Gateway AS5xx0

Completare questa procedura per controllare la configurazione del gateway.

1. In modalità di configurazione globale, eseguire questi comandi per configurare il gestore delle sessioni di backhaul in modo che comunichi a Cisco PGW 2200 se viene visualizzato il messaggio di errore IOS® % BSM: Sessione non creata. Limite massimo superato È possibile supportare un massimo di 16 sessioni nel gateway IOS 5xx0.

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

   L'output di questo comando mostra un esempio:

   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

   Nota: la configurazione Cisco IOS non supporta quando si utilizza la configurazione Backhaul Session Manager per posizionare le sessioni che puntano a diversi PGW 2200 fisici sotto lo stesso gruppo. È necessario separare i due PGW 2200 in due gruppi. Per ulteriori informazioni, fare riferimento all'ID bug Cisco CSCec24132 .

2. Immettere il comando pri-group timeslot 1-31 service mgcp per configurare il controller per il backhaul PRI nella configurazione del controller.

   Ad esempio:

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

   Nota: in questo esempio di configurazione viene usato il controller E1 7/5 che in un secondo momento riflette la configurazione di Cisco PGW 2200.

3. Inserire il comando isdn bind-l3 backhaul xxxx nella configurazione del canale D ISDN per collegarsi all'interfaccia ISDN Layer 2 al backhaul session manager.

   Ad esempio:

   !
   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

   Nota: se si aggiunge il codice causa 41 isdn negotiation-bchan resend-setup, questo si applica solo alle chiamate in uscita e non a quelle ricevute dal router. Questa CLI invia la configurazione senza l'indicatore EXCLUSIVE e consente allo switch di selezionare un altro canale B, se disponibile. In caso contrario, quando lo switch risponde con il codice causa 41, il router seleziona un altro canale B e invia nuovamente la configurazione.

   Nota: è possibile che lo switch non abbia un canale B che corrisponda alle caratteristiche nel messaggio di impostazione. In questo caso, lo switch non è in grado di assegnare un altro canale B e anche una configurazione con un altro canale B PREFERITO non riesce.

   Nota: non è possibile utilizzare contemporaneamente il backhaul MGCP NAS e PRI sul controller. Il comando extsig mgcp sul controller E1 (richiesto per MGCP NAS) impedisce la configurazione del pri-group sul 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. Usare il comando debug backhaul-session-manager per eseguire il debug di Gestione sessioni di backhaul.

Passaggio 2: Controllare la configurazione di PGW 2200

Completare questi passaggi per controllare la configurazione di PGW 2200.

1. Aggiungere IPFASPATH alla configurazione di Cisco PGW 2200.

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

   Ciò assicura che la variante MDO sia uguale alla variante gateway IOS.

   Nota: controllare la variante ISDN inclusa in questa tabella.

2. Aggiungere DCHAN alla configurazione di Cisco PGW 2200.

   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
   

   Ciò assicura che SignatureSlot/SigPort siano specificati. Assicura inoltre che le porte/gli slot del gateway Cisco e le porte Cisco PGW 2200 corrispondano sul DCHAN.

   Nota: se si usa il controller E1 7/5 sul gateway IOS che include il comando isdn bind-l3 backhaul IOS, il SIGSLOT=7,SIGPORT=5 per il comando MML DCHAN deve avere le stesse informazioni.

3. Durante il provisioning dei trunk commutati, accertarsi di non riempire il parametro span come '0'. Ciò è possibile dal contenuto della terza colonna nel file export_trunk.dat.

   Il valore di span deve essere 'ffff' sui trunk commutati. Per estrarre il file, usare il comando prov-exp:all:dirname="nome_file" dalla riga di comando MML.

   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

   Andare alla directory /opt/CiscoMGC/etc/cust_specific/check1. Nel file export_trunk.dat, assicurarsi che la terza colonna contenga 'ffff' anziché zeri (0). In caso contrario, modificare il file.

4. Usare il comando prov-add:files:name="BCFile",file="export_trunk.dat",action="Import" per avviare una sessione di provisioning MML e reimportare il file dei trunk.

   Il file export_trunk.dat modificato deve trovarsi nella directory /opt/CiscoMGC/etc/cust_specific/check1. Ricordarsi di emettere un prov-copy affinché la nuova configurazione abbia luogo.

5. Usare il comando MML rtrv-alms per spiegare il tipo di errore che si sta verificando.

   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.
   
   

   È inoltre possibile recuperare i dettagli da /opt/CiscoMGC/var/log per il file alm.csv utilizzando il comando perl perl -F, -anwe 'print unpack("x4 A15", localtime($F[1])),".$F[2]: @F[0,3.7]"' < meas.csv.

   Nota: utilizzare gmtime anziché localtime se si desidera eseguire la conversione in timestamp UTC. L'output è nel formato seguente:

   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. Utilizzare il comando UNIX tail -f platform.log per controllare platform.log nella directory /opt/CiscoMGC/var/log.

   Per ulteriori informazioni, fare riferimento a Messaggi di registro.

7. Controllare la variante ISDN.

   Il comando isdn switch-type primary-net5 viene usato sul gateway IOS. In Cisco PGW 2200, è collegato a mdo=ETS_300_102 in IPFASPATH.

   Nella tabella seguente vengono mostrate le varianti ISDN supportate per Cisco PGW 2200:

   Nome variante	ISDNPRI	Specifiche	Note
   ETS_300_102	ISDNPRI	ETSI 300_102	PRI ETSI
   ETS_300_102_C2	ISDNPRI	ETSI 300_102	PRI ETSI
   ATT_41459	ISDNPRI	AT&T 41459	PRI ISDN ATT
   ATT_41459_C2	ISDNPRI	(Meridiano Nortel)	Cisco AT&T PRI
   ETS_300_172	ISDNPRI	ETSI 300-172	QSIG ETSI
   Q931_AUSTRALIA	ISDNPRI	D931	PRI Australia
   D931	ISDNPRI	D931	D931
   Q931_SINGAPORE	ISDNPRI	D931	PRI Singapore

   Questo output di comando di esempio viene restituito dal gateway IOS.

   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)#

Passaggio 3: Controllare il collegamento tra RUDPV1 e Session Manager tra AS5xx0 e PGW 2200

Completare questi passaggi per controllare il collegamento RUDPV1 e Session Manager.

1. Utilizzare i seguenti comandi show e clear:

   • show rudpv1 failure: visualizza gli eventuali errori rilevati da rudpv1. Ad esempio, viene visualizzato SendWindowFullFailures. Ciò indica che esiste una congestione nell'invio di segmenti sul collegamento IP.

   • show rudpv1 parameters: visualizza i parametri della connessione rudpv1, nonché lo stato e i parametri di tutte le sessioni correnti. Il tipo di connessione è ATTIVO o PASSIVO. Attivo indica che il peer era il client e ha avviato la connessione. Passive indica che il peer era il server e ha ascoltato la connessione.

   • show rudpv1 statistics: visualizza le statistiche interne rudpv1 e le statistiche per tutte le sessioni correnti e le statistiche cumulative su tutte le connessioni rudp dall'ultimo riavvio della casella o dall'esecuzione di un comando clear statistics.

   • clear rudpv1 statistics: cancella tutte le statistiche rudpv1 raccolte. Eseguire questo comando quando sono necessarie statistiche correnti e il gateway IOS è in esecuzione da un periodo di tempo esteso.

2. Eseguire il comando debug rudpv1.

   #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 un sistema live, i debug relativi a prestazioni, stato, segnale e trasferimento sono i più utili. I debug per l'applicazione, la ritrasmissione e il timer generano troppo output e causano l'errore dei collegamenti oppure sono stati utili solo per il debug interno.

   Attenzione: con questo debug viene stampata una linea per ciascun segmento inviato o ricevuto. In caso di quantità significativa di traffico in esecuzione, si verificheranno ritardi negli intervalli che causeranno errori di collegamento.

3. Eseguire il comando show backhaul-session-manager e show backhaul set all per verificare se la pipe IP che trasporta la segnalazione è corretta.

   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

   Gli stati del comando show backhaul set all sono:

   • BSM_SET_IDLE

   • BSM_SET_OS

   • BSM_SET_STDBY_IS

   • BSM_SET_ACTIVE_IS

   • BSM_SET_FULL_IS

   • BSM_SET_SWITCH_OVER

   • BSM_SET_UNKNOWN

   Se tutto funziona correttamente, questa condizione conferma anche che il collegamento del set di sessioni corrispondente sul Cisco PGW 2200 è in servizio (comando mml rtrv-iplnk). La pipe tra Cisco PGW 2200 e il gateway IOS AC5xx0 è ora completamente operativa. Il passaggio successivo è quello di controllare il limite tra il gateway Cisco IOS AS5xx0 e il PABX.

Passaggio 4: Controllare lo stato di Q.921 tra AS5xx0 e PABX

Completare questi passaggi per controllare lo stato di Q.921 tra AS5xx0 e PABX.

1. Eseguire i comandi show isdn status e show isdn service.

   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 

   In questa schermata è possibile osservare il problema del canale Q.921 che non viene visualizzato, corrispondente sul lato PGW 2200 alla destinazione e al canale D che rimane nello stato Fuori servizio. La prima possibilità è una mancata corrispondenza nella configurazione del lato rete Q.921. È facile capire che questa non è la causa del problema, in quanto la rimozione della rete emulata dal protocollo isdn dalla configurazione di AS5400 non ha risolto il problema.

2. Visualizzare i debug di Q.921 per capire perché il collegamento Q.921 non viene visualizzato. Questo è l'output del comando debug.

   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)

   AS5400 trasmette un modulo Q.921 SABME per inizializzare il collegamento e riceve un frame che non è stato possibile interpretare (frame errato). Le possibilità sono:

   • Problema hardware su E1 per AS5400.

   • E1 sul lato remoto.

   • Problema di configurazione o hardware sul lato remoto.

   Questa prima possibilità viene esclusa spostando la configurazione su un altro E1 inutilizzato sullo stesso AS5400. Il problema appare esattamente lo stesso. Il cliente verifica inoltre che non vi sia alcun loop sull'E1. A questo punto, controllare il lato PABX.

3. Utilizzare il comando show controller per verificare la presenza di possibili errori di layer 1.

   #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. Quando si esegue il comando shutdown nel controller, il risultato è il seguente messaggio di debug:

   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        

   Eseguire il comando MML rtrv-alms su PGW 2200:

   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" 

   Quando si usa il comando no shutdown nel controller, il risultato è questo messaggio di debug sul gateway IOS:

   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 

   Per ulteriori comandi di debug IOS, fare riferimento a PRI/Q.931 Signaling Backhaul per applicazioni Call Agent.

Informazioni correlate

• Cisco PGW 2200 Softswitch - Note tecniche
• Documentazione tecnica sui Cisco Signaling Controller
• Supporto alla tecnologia vocale
• Supporto dei prodotti per le comunicazioni voce e IP
• Risoluzione dei problemi di Cisco IP Telephony
• Documentazione e supporto tecnico – Cisco Systems