Resolução de backhaul PRI de Softswitch PGW 2200

Introduction

Este documento ajuda a solucionar problemas de informações sobre o backhaul PRI no Cisco PGW 2200 no modo de Controle de Chamada. Devido às diferenças entre as famílias de protocolos, o backhaul é dividido em várias categorias. Por exemplo, ISDN para Sinalização Q (QSIG - Q Signaling) e Sistema de Sinalização de Rede Privada Digital (DPNSS - Digital Private Network Signaling System).

Este documento aborda somente o backhaul PRI com o Cisco PGW 2200.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

• Software Cisco Media Gateway Controller versão 9

Componentes Utilizados

As informações neste documento são baseadas no software Cisco PGW 2200 versões 9.3(2) e posteriores.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Descrição da resolução de backhaul PRI

O backhaul de sinalização PRI/Q.931 é a capacidade de transportar de forma confiável a sinalização (camadas Q.931 e superiores) de um tronco PRI (consulte a Figura 1). Esse tronco PRI está fisicamente conectado a um gateway de mídia que se conecta a um controlador de gateway de mídia (MGC - Cisco PGW 2200) para processamento. O backhaul de sinalização para ISDN PRI ocorre no limite de Camada 2 (Q.921) e Camada 3 (Q.931). As camadas inferiores do protocolo são terminadas e processadas no gateway de mídia (AS5xx0), enquanto as camadas superiores são retornadas ao Cisco PGW 2200.

As camadas superiores do protocolo são backhaul ou transportadas para o Cisco PGW 2200 com o uso do Protocolo de Datagrama de Usuário Confiável (RUDP - Reliable User Datagram Protocol) sobre IP. O RUDP fornece notificação autônoma de sessões conectadas e com falha e entrega garantida em sequência de protocolos de sinalização através de uma rede IP. O Backhaul Session Manager é uma função de software no Cisco PGW 2200 e no gateway de mídia que gerencia sessões RUDP. O backhaul de sinalização fornece a vantagem adicional do processamento distribuído de protocolos. Isso permite maior capacidade de expansão e escalabilidade. Ele também descarrega o processamento do protocolo de camada inferior do Cisco PGW 2200. A partir do modelo de camada, o backhaul PRI é integrado na camada 3 de ISDN IP/UDP/RUDP/Backhaul-Session Manager/PRI.

Troubleshoot

Conclua estes passos para solucionar problemas de backhaul PRI.

• Passo 1: Verifique a configuração do Cisco Gateway AS5xx0.

• Passo 2: Verifique a configuração do Cisco PGW 2200.

• Passo 3: Verifique o link do Session Manager entre o Cisco AS5xx0 e o Cisco PGW 2200.

• Passo 4: Verifique o status Q.921 entre o AS5400 e o PABX.

Passo 1: Verifique a configuração do Cisco Gateway AS5xx0

Conclua estes passos para verificar a configuração do gateway.

1. Emita estes comandos no modo de configuração global para configurar o gerenciador de sessão de backhaul para falar com o Cisco PGW 2200 se você receber a mensagem de erro IOS® % BSM: A sessão não foi criada, o limite máximo foi excedido Você pode suportar um máximo de 16 sessões no gateway do IOS 5xx0.

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

   Esta saída de comando mostra um exemplo:

   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

   Observação: a configuração do Cisco IOS não é suportada quando você usa a configuração do Backhaul Session Manager para colocar sessões que apontam para diferentes PGW 2200s físicos no mesmo grupo. Você precisa separar os dois PGW 2200s em dois grupos. Consulte o bug da Cisco ID CSCec24132 para obter informações adicionais.

2. Insira o comando pri-group timeslots 1-31 service mgcp para configurar o controlador para backhaul PRI na configuração do controlador.

   Por exemplo:

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

   Observação: este exemplo de configuração usa a controladora E1 7/5 que reflete posteriormente a configuração do Cisco PGW 2200.

3. Insira o comando isdn bind-l3 backhaul xxxx na configuração do canal D ISDN para vincular à interface da Camada 2 ISDN ao gerenciador de sessões de backhaul.

   Por exemplo:

   !
   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

   Observação: se você adicionar o código de causa 41 de reenvio da configuração de isdn negotiation-bchan, ele se aplicará somente a chamadas de saída e não a chamadas recebidas pelo roteador. Essa CLI envia a configuração sem o indicador EXCLUSIVO e permite que o switch selecione outro canal B se tiver um disponível. Caso contrário, quando o switch responde com o código de causa 41, o roteador seleciona outro canal B e envia a configuração novamente.

   Observação: é possível que o switch não tenha um canal B que corresponda às características na mensagem de configuração. Nesse caso, o switch não pode atribuir outro canal B, e uma configuração com outro canal B PREFERIDO também falha.

   Observação: você ainda não pode usar o NAS MGCP e o backhaul PRI na controladora ao mesmo tempo. O comando extsig mgcp no controlador E1 (necessário para MGCP NAS) impede a configuração de pri-group no controlador:

   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. Emita o comando debug backhaul-session-manager para depurar o gerenciador de sessão de backhaul.

Passo 2: Verifique a configuração do PGW 2200

Conclua estes passos para verificar a configuração do PGW 2200.

1. Adicione IPFASPATH à configuração do 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

   Isso garante que a variante MDO seja igual à variante de gateway do IOS.

   Observação: verifique a variante ISDN incluída nesta tabela.

2. Adicione DCHAN à configuração do 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
   

   Isso garante que SigSlot/SigPort sejam especificados. Ele também garante que as portas/slot do Cisco Gateway e as portas do Cisco PGW 2200 correspondam no DCHAN.

   Observação: se você usar a controladora E1 7/5 no gateway IOS que inclui o comando IOS isdn bind-l3 backhaul, o SIGSLOT=7,SIGPORT=5 para o comando MML DCHAN precisa ter as mesmas informações.

3. Enquanto provisiona os troncos comutados, certifique-se de que não preencha o parâmetro span como '0'. Você pode ver isso do conteúdo da terceira coluna no arquivo export_trunk.dat.

   O valor span precisa ser 'ffff' nos troncos comutados. Emita o comando prov-exp:all:dirname="file_name" na linha de comando MML para verificar isso.

   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

   Ir para o diretório /opt/CiscoMGC/etc/cust_specific/check1. No arquivo export_trunk.dat, verifique se a terceira coluna contém 'ffff' em vez de zeros (0). Se esse não for o caso, edite o arquivo e altere-o.

4. Emita o comando prov-add:files:name="BCFile",file="export_trunk.dat",action="Import" para iniciar uma sessão de provisionamento de MML e reimportar o arquivo de troncos.

   O arquivo export_trunk.dat modificado deve estar no diretório /opt/CiscoMGC/etc/cust_specific/check1. Lembre-se de emitir um comando prov-cpy para que a nova configuração ocorra.

5. Emita o comando MML rtrv-alms para explicar o tipo de erro que está ocorrendo no momento.

   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.
   
   

   Você também pode recuperar os detalhes de /opt/CiscoMGC/var/log para o arquivo alm.csv com o uso do comando perl -F, -anwe 'print unpack("x4 A15", localtime($F[1])),".$F[2]: @F[0,3.7]"" < meas.csv.

   Nota: Use gmtime em vez de localtime se desejar converter em timestamps UTC. A saída está neste formato:

   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. Emita o comando UNIX tail -f platform.log para verificar platform.log no diretório /opt/CiscoMGC/var/log.

   Consulte Mensagens de Log para obter informações adicionais.

7. Verifique a variante ISDN.

   O comando isdn switch-type primary-net5 é usado no gateway do IOS. No Cisco PGW 2200, ele está vinculado a mdo=ETS_300_102 no IPFASPATH.

   Esta tabela mostra as variantes ISDN suportadas para o Cisco PGW 2200:

   Nome da variante	ISDNPRI	Especificação	Lembretes
   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	ATT ISDN PRI
   ATT_41459_C2	ISDNPRI	(Nortel Meridian)	PRI AT&T da Cisco
   ETS_300_172	ISDNPRI	ETSI 300-172	QSIG ETSI
   Q931_AUSTRÁLIA	ISDNPRI	Q931	PRI Austrália
   Q931	ISDNPRI	Q931	Q931
   Q931_SINGAPORE	ISDNPRI	Q931	PRI de Singapura

   Este exemplo de saída do comando é do gateway do 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)#

Passo 3: Verifique o link RUDPV1 e Session Manager entre o AS5xx0 e o PGW 2200

Conclua estes passos para verificar o link RUDPV1 e Session Manager.

1. Emita estes comandos show e clear:

   • show rudpv1 failure —Mostra as falhas detectadas pelo rudpv1. Por exemplo, você vê SendWindowFullFailures. Isso indica que há congestionamento no envio de segmentos no link IP.

   • show rudpv1 parameters —Mostra os parâmetros de conexão rudpv1 e o estado e os parâmetros de todas as sessões atuais. O tipo de conexão é ATIVE ou PASSIVE. Ativo indica que esse peer era o cliente e iniciou a conexão. Passivo indica que esse peer era o servidor e ouviu a conexão.

   • show rudpv1 statistics —Mostra as estatísticas internas do rudpv1 e as estatísticas de todas as sessões atuais e as estatísticas cumulativas sobre todas as conexões do rudp desde a última vez que a caixa foi reinicializada ou um comando clear statistics foi executado.

   • clear rudpv1 statistics —Limpa todas as estatísticas de rudpv1 que foram coletadas. Execute esse comando sempre que as estatísticas atuais forem necessárias e o IOS Gateway estiver em execução por um longo período.

2. Emita o 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

   Em um sistema ativo, as depurações de desempenho, estado, sinal e transferência são as mais úteis. As depurações para aplicação, retransmissão e temporizador geram muita saída e fazem com que os links falhem ou são úteis apenas para fins de depuração interna.

   Cuidado: essa depuração imprime uma linha para cada segmento enviado ou recebido. Se houver uma quantidade significativa de tráfego em execução, isso causará atrasos de temporização que causam falhas de link.

3. Emita os comandos show backhaul-session-manager e show backhaul set all para ver se o IP pipe que transporta a sinalização está correto.

   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

   Os diferentes status do comando show backhaul set all são:

   • BSM_SET_IDLE

   • BSM_SET_OOS

   • BSM_SET_STDBY_IS

   • BSM_SET_ATIVE_IS

   • BSM_SET_FULL_IS

   • BSM_SET_SWITCH_OVER

   • BSM_SET_UNKNOWN

   Se tudo parecer bem, isso também confirma que o link do conjunto de sessões correspondente no Cisco PGW 2200 tem o status In-Service (comando mml rtrv-iplnk). O pipe entre o Cisco PGW 2200 e o gateway IOS AC5xx0 está agora totalmente operacional. A próxima etapa é verificar o limite entre o gateway do Cisco IOS AS5xx0 e o PABX.

Passo 4: Verifique o status Q.921 entre o AS5xx0 e o PABX

Conclua estes passos para verificar o status Q.921 entre o AS5xx0 e o PABX.

1. Emita os comandos 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 

   Aqui você pode começar a ver o problema de Q.921 não aparecer que corresponde no lado PGW 2200 ao destino e canal D que permanece no estado Fora de serviço. A primeira possibilidade é uma incompatibilidade na configuração do lado da rede Q.921. É simples ver que essa não é a causa do problema porque a remoção da rede isdn protocol-emulate da configuração do AS5400 não resolveu o problema.

2. Veja as depurações Q.921 para ver por que o link Q.921 não é ativado. Esta é a saída de depuração.

   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)

   O AS5400 transmite um SABME Q.921 para inicializar o enlace e recebe um quadro que ele não poderia interpretar (quadro incorreto). As possibilidades são:

   • Problema de hardware no E1 para este AS5400.

   • Loop E1 no lado remoto.

   • Problema de hardware ou configuração no lado remoto.

   Esta primeira possibilidade é excluída movendo a configuração para outro E1 não utilizado no mesmo AS5400. O problema é exatamente o mesmo. O cliente também verifica se não há nenhum loop no E1. Neste ponto, verifique o lado PABX.

3. Emita o comando show controller para verificar possíveis erros da Camada 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 você emite o comando shutdown no controlador, o resultado é esta mensagem de depuração:

   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        

   Emita o comando MML rtrv-alms no 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 você emite o comando no shutdown no controlador, o resultado é esta mensagem de depuração no gateway do 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 

   Consulte Backhaul de Sinalização PRI/Q.931 para Aplicações de Agente de Chamada para comandos debug adicionais do IOS.

Informações Relacionadas

• Notas técnicas do Softswitch Cisco PGW 2200
• Documentação técnica dos Cisco Signaling Controllers
• Suporte à Tecnologia de Voz
• Suporte aos produtos de Voz e Comunicação por IP
• Troubleshooting da Telefonia IP Cisco
• Suporte Técnico e Documentação - Cisco Systems