Voz e comunicações unificadas : Softswitch Cisco PGW 2200

Pesquisar defeitos o mudo chama Cisco PGW2200

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento fornece a informação de Troubleshooting para as chamadas de voz que são abafadas em um sentido no PGW 2200 PSTN Gateway de Cisco (Cisco PGW2200). A informação neste documento aplica-se especificamente à solução de gateway Cisco PSTN usando gateways do Media Gateway Controller (MGC) e do Cisco AS5x00 em combinação com Cisco PGW2200.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware abaixo.

Plataforma Nome da plataforma Versão
Nó PGW2200 Cisco MGC 9.2(2) [da correção de programa S(29)] 9.3(2) [da correção de programa S(7)] 9.4(1)
Gateway PSTN AS5x00 12.2T ou mais altamente

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Fluxos de chamadas

Compreender os ajustes diferentes sobre corte-através através do routing.mml pode ajudá-lo a compreender os fluxos de chamadas diferentes para o conceito de Cisco PGW2200.

Fluxo de chamadas típico com Corte-através no ANM

Um fluxo de chamadas típico com corte-através no ANM (tal como 3) é mostrado abaixo:

Originating TDM Originating Gateway PGW Terminating Gateway            Terminating TDM
                       --------------IAM-------------> 
                                                    <-CRCX-- 
                                                 (M: inactive) 
                                                    --- OK----> 
                                                                                      ---CRCX-> 
                                                                                 (M: sendrecv) 
                                                                                       <--OK----- 
                                                                                      --------------------IAM---------> 
                                                                                       <---------------- ACM----------- 
                       <--------------ACM-------------- 
                                                    <-MDCX-- 
                                                (M: recvonly) 
                                                     --OK------> 
                                                                                       <-----------------ANM----------- 
                       <--------------ANM-------------- 
                                                      <--MDCX--- 
                                                (M: sendrecv) 
                                                     ----OK----> 
                                                                                         ----MDCX--> 
                                                                                  (M: sendrecv) [See note below] 
                                                                                         <---OK--[See note below]

Nota: O MDCX opcional é enviado ao gateway de terminação para girar sobre o cancelamento de eco somente se:

  • a propriedade “EchoCanRequired” do grupo de troncos é ajustada, e

  • o interruptor do termo TDM não forneceu o cancelamento de eco (por exemplo, o parâmetro de Echo_control_device_indicator no mensagem de ACM do termo TDM foi ajustado a zero).

Fluxo de chamadas típico com Corte-através no ACM

Um fluxo de chamadas típico com corte-através no ACM (como corte-através dos iguais 2) é mostrado abaixo:

Originating TDM Originating Gateway             PGW           Terminating Gateway            Terminating TDM 
                           --------------IAM-------------> 
                                                        <--CRCX--- 
                                                           (M: inactive) 
                                                        --- OK-----> 
                                                                                          ---CRCX---> 
                                                                                      (M: sendrecv) 
                                                                                           <--OK---- 
                                                                                           --------------------IAM---------> 
                                                                                            <---------------- ACM----------- 
                          <-------------ACM----------------- 
                                                          <---MDCX---- 
                                                           (M: sendrecv) 
                                                           ----OK----> 
                                                                                             ----MDCX--> 
                                                                                            (M: sendrecv) [OPTIONAL, see note 1] 
                                                                                             <---OK---[OPTIONAL, see note 1] 
                                                                                              <------------------ANM------------ 
                          <-------------ANM------------------ 

Nota: Quando o atendimento é ocupado ou há algum meio anúncio a jogar ao chamador, não há nenhuma razão abrir o trajeto da voz nos ambos sentidos. Se você pensa você tem um atendimento mudo relatado, emite um comando debug mgcp packet no gateway de origem e finalização em combinação com um comando show call history voice ligado às mensagens com um zero enviado contagem de pacote de informação, um comando show call history voice brief, e um traço do Idioma de Definição da Mensagem de Cisco (MDL) no PGW2200 compreender o problema. Um traço de Snooper igualmente ajudá-lo-á a compreender o problema. O traço MDL fornece um fluxo de chamadas completo SS7 e de Media Gateway Control Protocol (MGCP).

Os clientes relatam atendimentos silenciado

As seguintes circunstâncias fazem com que o PGW2200 embandeire atendimentos mudos (durante o [DLCX] da conexão da supressão) e detecção em platform.log. Estes logs contêm uma identidade da chamada que tenha a informação de gateway e a informação de CIC.

  1. O PGW2200 é configurado no modo tolerante da falha.

  2. O atendimento foi respondido (o atendimento estava com sucesso corte-através de.).

  3. A mensagem de 250 APROVAÇÕES foi recebida com (P:) em resposta ao DLCX.

  4. Pacote os iguais (PS) enviados pacote 0 ou recebido (PR) igualam 0 dentro (P:).

  5. A duração da chamada era mais de 1 segundo.

Recolhendo a informação de chamada adicional

Para recolher a informação de chamada adicional, use as seguintes etapas:

  1. Faça uma conexão Telnet ao gateway as5xxx-1.

  2. Emita o comando seguinte encontrar para trás a identidade da chamada outra vez que é ligada com o valor-limite e a mensagem muda do atendimento de platform.log:

    as5xxx-1 > show mgcp connection
    

    O seguinte é exemplo de saída do comando show mgcp connection para a Voz sobre conexões IP (VoIP):

    Endpoint Call_ID(C) Conn_ID(I) (P)ort (M)ode (S)tate (C)odec (E)vent[SIFL] (R)esult[EA] 
    1. S0/DS1-0/1 C=103,23,24 I=0x8 P=16586,16634 M=3 S=4,4 C=5 E=2,0,0,2 R=0,0

As descrições de campo do comando show mgcp connection para VoIP são mostradas abaixo.

  • Valor-limite — O valor-limite para cada atendimento, mostrado na convenção de nomeação do ponto final de digital do número de slot (S0) e da linha digital (DS1-0) número (1).

  • Call_ID (C) — A identidade da chamada MGCP enviada pelo agente do atendimento, a identidade da chamada da interface de programação do aplicativo de controle da chamada interna (CCAPI) para este valor-limite, e a identidade da chamada CCAPI para os trechos de chamada de peer. O CCAPI é um API que forneça facilidades de Controle de chamadas aos aplicativos.

  • Conn_ID (I) — O identificador de conexão gerado pelo gateway e enviado no mensagem de reconhecimento.

  • Ort (P) — as portas usadas para esta conexão. A primeira porta é a porta local do User Datagram Protocol (UDP). A segunda porta é a porta remota UDP.

  • Ode (M) — o modo de chamada, onde:

    • 0 — Indica um valor inválido de modo.

    • 1 — Indica que o gateway deve somente enviar pacotes.

    • 2 — Indica que o gateway deve somente receber pacotes.

    • 3 — Indica que o gateway pode enviar e receber pacotes.

    • 4 — Indica que o gateway deve nem enviar nem receber pacotes. [Inative]

    • 5 — Indica que o gateway deve colocar o circuito no modo loopback.

    • 6 — Indica que o gateway deve colocar o circuito no modo de teste.

    • 7 — Indica que o gateway deve usar o circuito para o acesso de rede para dados.

    • 8 — Indica que o gateway deve colocar a conexão no modo do loopback de rede.

    • 9 — Indica que o gateway deve colocar a conexão no modo de teste de continuidade da rede.

    • 10 — Indica que o gateway deve colocar a conexão no modo de conferência.

  • INFORMAÇÃO do tate (S) — exemplo: S=4,4 que o inteiro do punho mostra que o estado da chamada local MGCP e o segundo inteiro mostram o estado da chamada remoto MGCP.

    MGCP_CALL_IDLE = 0, quietude
    MGCP_CALL_SETTING = 1, chamada recebida do PSTN
    MGCP_CALL_CONNECTING = 2, MGCP CRCX recebido
    MGCP_CALL_CONFERENCING = 3, atendimento conectado, esperam o conf
    MGCP_CALL_ACTIVE = 4, conferência criada
    MGCP_CALL_CONF_DESTROYING = 5, conferência de destruição
    MGCP_CALL_DISCONNECTING = 6, Conf destruiu, atendimento da disconexão
    MGCP_CALL_INACTIVE = 7, atendimento no modo inativo
    MGCP_CALL_VOICE_CONNECTING = 8, criando o trecho da chamada telefônica somente
    MGCP_CALL_VOICE_ACTIVE = 9, trecho da chamada telefônica criado
    MGCP_CALL_CONF_DISSOCIATING = 10, conf de destruição
    MGCP_CALL_CALLLEGS_DISSOCIATED =11, Conf destruiu, nenhum discon do atendimento
    MGCP_CALL_HP_CONNECTING = 12, conectando o trecho de chamada do gancho de cabelo TDM
    MGCP_CALL_HP_CONNECTED = 13, um trecho de chamada HP conectado
    MGCP_CALL_HP_CONFERENCING = 14, trecho de chamada do Grampeamento de TDM de Conferência
    MGCP_CALL_HP_ACTIVE = 15, estado ativo do grampeamento de TDM
    MGCP_CALL_VOIP_CONF_DESTROY = 16, Conf destruíram, fazem o atendimento HP
    MGCP_CALL_ERROR_STATE = 17, atendimento no estado de erro
    MGCP_CALL_CONNECTING_INACTIVE = 18, criando a conexão inativa
    MGCP_CALL_CONF_DESTROYING_INACTIVE = 19, Conf destroem a conexão inativa
    MGCP_CALL_CONT_TEST = 20, teste de continuidade AAL2/IP (xrbk)
    MGCP_CALL_SETUP_WAIT = 21, informação do instalação de espera
    MGCP_CALL_WAIT_NSE_SENT = 22, espera para que o evento NSE seja enviado
    MGCP_CALL_TWC_ACTIVE = 23, active do atendimento TWC
    MGCP_CALL_WAIT_STATE = 24, App estão esperando o Controle de chamadas
    MGCP_CALL_HANDOVER = 25, App estão agarrando suportam o controle
    MGCP_CALL_EM_DISCONNECTING = 26, atendimento da disconexão, valores-limite do E&M
    MGCP_CALL_MAX_STATE = 27

  • informação (C)odec — Exemplo: C=1

    MGCP_CODEC_UNDEFINED 0
    MGCP_G711_U, 1 = Mu-law de G.711
    MGCP_G711_A, 2 = G.711a-law
    MGCP_G726_32K, 3 = G.726 32K
    MGCP_G726_24K, 4 = G.726 24K
    MGCP_G726_16K, 5 = G.726 16K
    MGCP_G729, 6 = G.729
    MGCP_G729_A, 7 = G.729-A
    MGCP_G729_B, 8 = G.729-B
    MGCP_G729_B_LOW_COMPLEXITY, 9 = G.729-B
    MGCP_G728, 10 = G.728
    MGCP_G7231_HIGH_RATE, 11 = taxa alta G.723.1
    MGCP_G7231_A_HIGH_RATE, 12 = taxa alta do anexo A G.723.1
    MGCP_G7231_LOW_RATE, 13 = G.723.1 desprezado
    MGCP_G7231_A_LOW_RATE, 14 = anexo A G.723.1 desprezado
    MGCP_GSM_FULL_RATE, 15 = GS de varredura completa
    MGCP_GSM_HALF_RATE, 16 = GS de meia varredura
    MGCP_GSM_ENHANCED_FULL_RATE, 17 = Enhanced Full Rate GS
    MGCP_GSM_ENHANCED_HALF_RATE, 18 = GS aumentaram de meia varredura
    MGCP_CLEAR_CHANNEL = 128, 128 = canaleta desobstruída de Nx64
    MGCP_NSE = 129 Para o NSE

  • Respiradouro (E) — exemplo: E=3,0,2,3 o campo do evento é lido como: E=last_successful_mgcp_event, last_successful_internal_event, last_failed_app_event, last_requested_app_event

    MGCP_APP_EV_ACK = -1, MGCP ACK
    MGCP_APP_EV_CREATE_CONN = 0, O MGCP cria msg da conexão
    MGCP_APP_EV_DELETE_CONN, =1 Msg da conexão de exclusão de MGCP
    MGCP_APP_EV_MODIFY_CONN, =2 O MGCP altera msg da conexão
    MGCP_APP_EV_NOTIFY_REQ, =3 O MGCP notifica msg do pedido
    MGCP_APP_EV_ALERT, =4 Evento alerta CCAPI
    MGCP_APP_EV_CALL_CONNECT,=5 O atendimento CCAPI conecta o evento
    MGCP_APP_EV_CONF_RDY,=6 Conferência de CCAPI pronta
    MGCP_APP_EV_CONF_DESTROY,=7 Conferência de CCAPI destruída
    MGCP_APP_EV_CALL_DISCONNECT,=8 Disconexão do atendimento CCAPI
    MGCP_APP_EV_CALL_PROCEED, =9 Continuação do atendimento CCAPI
    MGCP_APP_EV_OFF_HOOK,=10 Fora-gancho CCAPI/configuração de chamada ind
    MGCP_APP_EV_ON_HOOK, =11 Em-gancho/atendimento CCAPI desligado
    MGCP_APP_EV_MEDIA_EVT,=12 Eventos de media MGCP
    MGCP_APP_EV_INT_EVT,=13 Eventos internos MGCP
    MGCP_APP_EV_DISSOC_CONF,=14  
    MGCP_APP_EV_ASSOC_CONF,=15  
    MGCP_APP_EV_MODIFY_DONE,=16 O atendimento CCAPI altera o ev feito
    MGCP_APP_EV_VOICE_MODE_DONE,=17 A Voz Corte-através de aconteceu
    MGCP_APP_EV_NSE,=18 Eventos CCAPI NSE
    MGCP_APP_EV_CALL_HANDOFF,=19 Atendimento da entrega a algum outro app
    MGCP_APP_EV_MAX_EVENT  

  • Esult (R) — exemplo: R=0,0 o campo de resultado é interpretado como: R=Event_result, (booleano) faz nós precisa de enviar o ACK?

    MGCP_APP_EVR_NORMAL_OK = 0, Evento normal MGCP processado ESTÁ BEM
    MGCP_APP_EVR_INVALID_OK, Evento inválido MGCP processado ESTÁ BEM
    MGCP_APP_EVR_CALLP_REL, o registro de chamada é liberado
    Erros do protocolo de MGCP/* *
    MGCP_APP_EVR_INVALID_CALL_ID = 10, O TGW encontra a identidade da chamada inválida
    MGCP_APP_EVR_INVALID_CONNECTION_ID, O TGW encontra o identificador de conexão inválido
    MGCP_APP_EVR_DUPLICATED_MESSAGE, O achado TGW duplicou msg do sgcp
    MGCP_APP_EVR_MGCP_ACK_FAILURE, O TGW não pode enviar msg ack do sgcp
    MGCP_APP_EVR_MGCP_DELETE_FAILURE, O TGW não pode enviar msg da supressão do sgcp
    MGCP_APP_EVR_MGCP_CREATE_ACK_FAILURE, O TGW não pode enviar cria msg ack
    MGCP_APP_EVR_MGCP_CREATE_ACK_MISSING, O TGW não enviou msg ack do sgcp
    MGCP_APP_EVR_MGCP_DELETE_ACK_FAILURE, O TGW não pode enviar msg ack da supressão
    MGCP_APP_EVR_MGCP_NOTIFY_FAILURE, O TGW não pode enviar o sgcp notifica msg
    MGCP_APP_EVR_INVALID_STATE, Evento do achado TGW no estado errado
    Problema de recurso/* *
    MGCP_APP_EVR_TGW_DOWN = 30, TGW no modo da parada oportuna
    MGCP_APP_EVR_TGW_NOT_READY, TGW não pronto para o evento
    MGCP_APP_EVR_CALL_VDB_FAILURE, O TGW não pode obter o vdbptr
    MGCP_APP_EVR_PREV_RTP_PORT_LOCKED, O TGW encontra a porta precedente do rtp travada
    MGCP_APP_EVT_CONN_RECORD_MISSING, O TGW não pode encontrar o registro conexão
    MGCP_APP_EVR_ENDP_NOT_READY, TGW não pronto para o evento
    MGCP_APP_EVR_MEM_RSRC_ERROR, O TGW manda o alloc transiente do mem errar
    MGCP_APP_EVR_CALL_CAC_FAILURE, O GW não tem a largura de banda
    MGCP_APP_EVR_CONF_RSRC_ERROR, O GW não pode obter o recurso do conf
    Falha do evento/* *
    MGCP_APP_EVR_REQ_EVENT_FAILURE = 40, O TGW não pode segurar o evento pedido
    MGCP_APP_EVR_INVALID_CCAPI_EVENT, O TGW não pode segurar o evento do ccapi
    MGCP_APP_EVR_IGNORE_CCAPI_EVENT, O TGW ignorará o evento do ccapi
    Falha de sinal/* *  
    MGCP_APP_EVR_SIGNAL_FAILURE = 50 pés, O TGW não pode segurar o sinal
    MGCP_APP_EVR_ABNORMAL_ONHOOK, O TGW encontra o onhook anormal
    MGCP_APP_EVR_INVALID_OFFHOOK, Offhook inválido do achado TGW
    MGCP_APP_EVR_INVALID_COT, O TGW encontra o berço inválido
    MGCP_APP_EVR_COT_FAILURE, O TGW não fez o COT
    MGCP_APP_EVR_COT_DISABLE_FAILURE, O TGW não desabilitou o COT
    Falha na configuração de chamada/* *
    MGCP_APP_EVR_CALL_SETUP_REQ_FAILURE = 60, O TGW não pode setup o pedido de chamada
    MGCP_APP_EVR_CALL_SETUP_IND_FAILURE, O TGW não pode segurar a indicação do atendimento
    MGCP_APP_EVR_CALL_CONTEXT_FAILURE, O TGW não pode setup o contexto
    MGCP_APP_EVR_CALL_PEER_FAILURE, O TGW não pode setup o par
    MGCP_APP_EVR_CALL_VOX_CALL_FAILURE, O TGW não pode setup o atendimento voip/voaal2
    MGCP_APP_EVR_CALL_VOIP_CALL_FAILURE, O TGW não pode setup o atendimento do voip
    MGCP_APP_EVR_CALL_DISCONNECT_FAILURE, O TGW não pode desligar o atendimento
    MGCP_APP_EVR_CALL_MODIFY_FAILURE, O TGW não pode alterar o parm do atendimento
    MGCP_APP_EVR_CALL_ALERT_FAILURE, O TGW não pode alertar o atendimento
    MGCP_APP_EVR_CALL_DELETE_FAILURE, O TGW não pode suprimir do atendimento
    MGCP_APP_EVR_CALL_UNKNOWN_FEATURE, O TGW não pode segurar a característica do unknow
    MGCP_APP_EVR_UNSUPPORTED_CODEC, O TGW encontra codec unsupported
    MGCP_APP_EVR_NO_DIGIT_MAP, O TGW não pode encontrar o mapa de dígito
    MGCP_APP_EVR_IGNORE_DIGIT, O TGW não pode processar os dígitos
    MGCP_APP_EVR_DIGITS_OVERFLOW, O TGW não pode segurar dígitos demais
    MGCP_APP_EVR_DIGITS_NOTIFY_FAILURE, O TGW não pode enviar os dígitos para fora
    MGCP_APP_EVR_CODEC_NOT_MATCHED, O codec TGW não combina o Rmt TGW
    MGCP_APP_EVR_INVALID_CONN_MODE, O TGW não pode compreender o modo do engodo
    Falha do par/* *
    MGCP_APP_EVR_PEER_MISSING = 90, Achado TGW para não encontrar o par
    MGCP_APP_EVR_PEER_NOT_READY, Par do achado TGW não pronto
    MGCP_APP_EVR_PEER_IN_WRONG_STATE, O TGW encontra o par no estado errado
    MGCP_APP_EVR_PEER_DISCONNECT_FAILURE, O TGW não pode desligar o par
    MGCP_APP_EVR_NO_CONFERENCE_ID, O TGW não pode encontrar o ID de conferência
    MGCP_APP_EVR_CONF_CREATE_FAILURE, O TGW não pode criar a conferência
    MGCP_APP_EVR_CONF_DESTROY_FAILURE, O TGW não pode destruir a conferência
    MGCP_APP_EVR_UNKNOWN_CONN_TYPE, O TGW não pode segurar o tipo do engodo
    MGCP_APP_EVR_INVALID_ENDPOINT, O TGW não pode conectar ao valor-limite
    MGCP_APP_EVR_INVALID_NSE_EVENT = 100, Evento inválido NSE
    MGCP_APP_EVR_NSE_RCVD_ON_WRONG_LEG, Os eventos NSE vêm a um pé errado
    MGCP_APP_EVR_SEND_NSE_FAILURE, Não pode enviar um evento NSE
    MGCP_APP_EVR_PLAY_TONE_FAILURE, Não pode jogar o tom NSE-pedido
    Erro transitório/* *
    MGCP_APP_EVR_TRANS_ERROR = 110, Ponto final de TGW no estado de transição
    MGCP_APP_EVR_MAX_RESULT  

Causas possíveis e ações recomendadas

Compreendendo e definindo seu problema

Os atendimentos do mudo podem ser ligados aos problemas de software ou às outras edições. Use as seguintes etapas para começar a pesquisar defeitos o mudo chama Cisco PGW2200.

  1. Compreenda a descrição do problema do cliente. Os atendimentos do mudo podem ser relacionados a outros artigos que não são ligados aos erros de software tais como problemas de Roteamento IP e do Layer 1. A solução de cada causa de raiz expõe frequentemente os problemas adicionais do baixo-nível que precisam de ser fixados primeiramente.

  2. Calcule a relação das chamadas falha para abafar atendimentos no local do cliente pela monitoração de 24 horas.

  3. Avoid que define exatamente que porcentagem dos atendimentos é alarming.

  4. Tente reproduzir esta situação para compreender a causa real do problema.

Verificando a carga de CPU no PGW2200

Para verificar a carga de CPU no PGW2200, emita o comando seguinte:

mml> rtrv-ne-health

Este comando indica o seguinte tipo de informação:

MGC-01 - Media Gateway Controller 2003-02-14 15:36:50.788 GMT 
M RTRV 
"Platform State:ACTIVE" 
"Machine Congestion Level = MCL 0 (No Congestion)" 
"Current in progress calls = 83, call attempts = 2 cps" 
"CPU 0 Utilization = 1 % CPU 1 Utilization = 0 %" 
"CPU 2 Utilization = 2 % CPU 3 Utilization = 0 %" 
"Memory (KB):3715344 Free virtual, 8390328 Total virtual, 4194304 
Total rea" 
"Filesystem kbytes used avail capacity Mounted on" 
"/dev/dsk/c0t0d0s0 494235 47099 397713 11% /" 
"/dev/dsk/c0t0d0s4 10678328 5494165 5077380 52% /opt" 
;

Verifique a informação dos atendimentos por segundo (CP) e tente-a calcular isto em combinação com os gateways que você se está usando. Talvez alguns gateways têm uma carga da alta utilização da CPU devido à quantidade de atendimentos que entram. O seguinte indicador do resultado em platform.log igualmente pode explicar o estado do sistema.

Fri Nov 13 10:18:28:119 2002 CET | engine (PID 14488) <Error>engMclMgrImpl::updateSystemMcl:
 System Mcl = 1, MclName = cpu, Load = 84 AvgLoad = 68

Nota: Neste exemplo, havia uma condição de sobrecarga de CPU devido ao tráfego elevado que diminuiu em poucos minutos. Isto realiza-se em consequência do período das horas de pico. Nesse ponto, tente ligar esta informação com os atendimentos mudos.

Verificando a carga de CPU nos gateways

Para obter um estado sobre uma certa quantidade de tempo, emita o comando seguinte:

as5xxx-1> show proc cpu history

Uma carga da alta utilização da CPU pode ser causada por um dos artigos que estão sendo ligados para processar o interruptor. Para verificar isto, emita a executar-configuração da mostra | comando route do incl.

as5xxx-1> show running-config | incl route 

Para evitar uma carga da alta utilização da CPU no gateway, não tenha os comandos seguintes em suas configurações:

no ip route-cache
no ip route-cache cef 

Nota: O comando ip route-cache ou ip route-cache cef deve ser configurado nos gateways.

Se você vê alguma do acima, você é processo mais provável que comuta em vez do interruptor rápido e a carga de sistema será extremamente alta, os atendimentos podem ser perdidos, e a Qualidade de voz será deficiente. Adicionalmente, o mensagem de MGCP não pode ser reconhecido (ACK) ou ser gerado.

Mensagens de RSIP não enviados em Ethernet secundária

Segundo a maneira que o comando ip host é configurado nos gateways, ele não enviará mensagens de RSIP em Ethernet secundária. A razão que o gateway está tentando enviar ao primeiro endereço IP de Um ou Mais Servidores Cisco ICM NT para um segundo círculo das tentativas antes de falhar sobre ao segundo endereço IP de Um ou Mais Servidores Cisco ICM NT é ligada à configuração de software do ½ do ¿  de Cisco IOSïÂ. Isto força uma pesquisa de DNS (que olha um comando ip host quando o comando no ip domain-lookup é configurado). Quando isto acontece, o primeiro endereço IP de Um ou Mais Servidores Cisco ICM NT está retornado e usado outra vez. Para evitar este comportamento, use o comando seguinte no perfil MGCP:

as5xxx-1> mgcp profile 
as5xxx-1> no max1 lookup 

Nota: Você precisa de recarregar o roteador para que a configuração do comando no max1 lookup tome o efeito.

Sugestões de Troubleshooting mudas do atendimento

Execute as seguintes etapas para determinar se há umas edições adicionais em sua rede.

  1. Determine se a duração da chamada é menos do que os segundos 10.

  2. Determine se os pacotes transmitir (Tx) ou receba os pacotes (RX) são zero.

    as5xxx-1> show mgcp connection 

    E verificação no Call_ID, que é 3334373 para este exemplo.

    Endpoint            Call_ID(C)   Conn_ID(I)                                 (P)ort                 (M)ode (S)tate (CO)dec (E)vent[SIFL] (R)esult[EA] 
                1. S6/DS1-1/31 C=345F3D,3334373,3334374  I=0x197074  P=19544,18424  M=3  S=4,4 CO=6 E=2,0,0,2  R=0,0
  3. Tente ligar o Call_ID usando o seguinte:

    as5xxx-1 > show call active voice brief | incl Call_ID
     
    Tele 0/0:0 (call_id): tx:0/0/0ms None noise:0 acom:0  i/0:0/0 dBm 
    
  4. Neste momento, você pode encontrar a informação do comando show call ative voice, ligado em Conn_ID para encontrar pacotes de Tx, bytes de Tx, pacotes RX, e informação de bytes RX. Esta informação pode dizer-lhe os números de pacotes que estão sendo enviados e recebidos.

    Telephony call-legs: 1 
    SIP call-legs: 0 
    H323 call-legs: 0 
    Total call-legs: 2 
    0    : 482619719hs.1 +0 pid:0 Originate  active 
     dur 00:12:35 tx:42517/711257 rx:24197/661142 
     Tele 6/1:0 (3334373): tx:755060/278000/0ms g729r8 noise:-120 acom:90  i/0:-51/-12 dBm 
    0    : 482619719hs.2 +-1 pid:0 Originate  connecting 
     dur 00:00:00 tx:24192/660942 rx:42517/711257 
     IP 0.0.0.0:18424 rtt:1ms pl:280000/37390ms lost:347/1/0 delay:40/30/120ms g729r8 

    Neste caso, você pode encontrar os detalhes do Local e do gateway remoto.

    as5xxx-1 > show voip rtp connections 
    VoIP RTP active connections : 
    No. CallId  dstCallId  LocalRTP RmtRTP LocalIP         RemoteIP 
    1   3334374 3334373    19544    18424  193.41.31.2     193.41.24.5
  5. Determine se uma porcentagem maior dos atendimentos mudos ocorre durante períodos ocupados.

Nas situações raras, os pacotes enviados pelo Cisco AS5400 não podem ser recebidos pela relação do Cisco AS5300 TDM. Se isto ocorre, o Cisco AS5400 DLCX ACK mostra pacotes de Tx, mas o Cisco AS5300 não mostra nenhuns pacotes RX. A interface de loopback é importante para a conexão MGCP em combinação com o comando mgcp bind.

Nota: A implementação de MGCP usa o melhor endereço IP de Um ou Mais Servidores Cisco ICM NT disponível no MGC como um endereço de origem para comunicar-se com o agente do atendimento. O fluxo de mídia usa o endereço de loopback se configurado, se não o melhor endereço IP de Um ou Mais Servidores Cisco ICM NT disponível como seu endereço de origem. Não há nenhuma maneira definida de mudar este comportamento. O comando bind reserva mais flexibilidade para escolher o endereço de origem para o controle e os pacotes de mídias.

São alistadas abaixo algumas situações que explicam o comportamento do comando. Para todos estes casos, o mensagem de advertência apropriado será indicado segundo a situação.

  • Quando há ativo o MGCP chama o gateway, o comando bind será rejeitado para o controle e os media.

  • Se a relação do ligamento não está acima, a seguir o comando está aceitado, mas não toma a influência até que a relação venha acima.

  • Se o endereço IP de Um ou Mais Servidores Cisco ICM NT não é atribuído na relação do ligamento, o comando bind está aceitado mas toma o efeito somente depois que o endereço IP válido é atribuído, durante este tempo se os atendimentos MGCP estão acima, o comando bind é removida.

  • Quando a relação encadernada vai para baixo, ou devido a um manual feche na relação ou devido a uma falha operacional, a atividade do ligamento é desabilitada nessa relação.

  • Quando o ligamento não é configurado no MGC, o endereço IP de Um ou Mais Servidores Cisco ICM NT usou-se para o controle da fonte MGCP e o media é melhor endereço IP de Um ou Mais Servidores Cisco ICM NT disponível.

Tarefas adicionais relativas para abafar atendimentos

Um dos critérios que o PGW2200 se usa para embandeirar um atendimento mudo é que o atendimento deve estar no estado da resposta, assim que ele significa que o mensagem ANM deve ter sido enviado pelo PGW2200 ao interruptor SS7 de origem. Antes de enviar o mensagem ANM ao interruptor SS7 de origem, o PGW2200 transmite o MDCX ao GW para ajustar o modo ao Enviar-RECV. Se o MDCX não é reconhecido pelo GW devido à Conectividade ou às outras edições, o atendimento não alcança o estado da resposta, daqui não é seguido porque um atendimento mudo. Nesse ponto, um log de erros será enviado ao arquivo de platform.log em opta/CiscoMGC/var/log.

Comando mgcp enviado novamente

Se o mensagem de comando MGCP (CRCX, DLCX, MDCX) é enviado novamente devido a um intervalo (por exemplo [sendrecv] enviado PGW2200 MDCX quatro vezes), mas o gateway não fez ACK ele, o atendimento falha e não é considerado um atendimento mudo pelo PGW2200. O PGW2200 embandeira um atendimento mudo (mudo-mensagem em platform.log) durante o DLCX se:

  1. O atendimento foi respondido, e

  2. uma mensagem de 250 APROVAÇÕES teve o parâmetro de conexão (P:), e

  3. O PS ou o PR eram 0 em (P:)

Nota: Isto pode ser ligado a outros artigos não ligados como um atendimento mudo real. Por exemplo, se a chamada originada pendura acima quando as respostas do número chamado, você consideram esta mensagem e está correto. Mas este não é um atendimento mudo. Para atendimentos do gancho de cabelo (o hairpinning é o nome dado aos atendimentos que originam e terminam no mesmo roteador ou no gateway), a mensagem de 250 APROVAÇÕES em resposta ao DLCX não tem o parâmetro de conexão (P:). Estes atendimentos são não são embandeirados como o mudo.

Compreendendo o log de erros

Um erro é escrito no seguinte formato enviando novamente a informação:

mgcp_link_comp_id ioCcMgcpConnMgr: mgcpCmdRequestTimeout: Successfully resent txn:transaction_id msg:
 message cnt:no_of_retry remaning

Exemplo:

Tue Jul 16 11:05:46:219 2002 EST | mgcp-1 (PID 20828) <Error> 
00100001 ioCcMgcpConnMgr: mgcpCmdRequestTimeout: Successfully resent txn:1718 msg:DLCX 1718 s13/ds1-20/28@tasty-7 MGCP 0.1 
C: 72 
I: 16 
R: 
S: 
X: 6B5 
 cnt:1.

Transação suprimida

Se uma transação é suprimida após novas tentativas máxima, um erro está escrito no seguinte formato:

MGCP Link Comp Id ioCcMgcpConnMgr: mgcpCmdRequestTimeout: type message type, cnt: <-1>,
 txn:transaction_id, connMsgPtr pointer to message

Exemplo:

Tue Jul 16 11:05:50:218 2002 EST | mgcp-1 (PID 20828) <Error> 
00100001 ioCcMgcpConnMgr: mgcpCmdRequestTimeout: type 5, cnt:-1, txn: 1718, connMsgPtr 0027b718

Emita o comando show mgcp stat verificar em artigos falhados e tentar compreender porque uma transação foi suprimida.

Recolhendo um traço MDL no PGW2200

Se todos os artigos estão corretos, execute um traço MDL e recolha todos os detalhes do comando show log no GW. As seguintes etapas mostram como recolher o traço MDL:

  1. Identifique o número de origem do SigPath SS7 ou a origem do número do TrunkGroup em que os atendimentos são colocados.

  2. Comece o traço MDL emitindo o comando seguinte:

    mml> sta-sc-trc:ss7sigPath name | orig
    		  trunkgroup number
    
    
  3. Execute um teste.

  4. Pare o traço MDL emitindo o comando seguinte:

    mml> stp-sc-trc:all
    
  5. Identifique a identidade da chamada (C:) do atendimento ruim do MGCP debugam no gateway.

  6. Converta o traço MDL em um formato legível:

    mml> get_trc.sh trace file name
    
    
  7. Datilografe a identidade da chamada na alerta para saltar ao traço MDL do atendimento ruim.

  8. Escolha o C da opção converter o arquivo de rastreamento.

  9. O arquivo de rastreamento está em /opt/CiscoMGC/var/trace.


Informações Relacionadas


Document ID: 44183