Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

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

Troubleshoot

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

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

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

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

Informações Relacionadas

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.

Figura 1: Backhaul PRI

Figura 2: Backhaul PRI - Sequência de configuração da chamada

Figura 3: Backhaul PRI - Sequência de configuração da chamada

Figura 4: Backhaul PRI - Limpar chamada

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