Voz y Comunicaciones unificadas : Cisco PGW 2200 Softswitch

Resolver problemas las llamadas del mudo en Cisco PGW2200

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento proporciona la información de Troubleshooting para las llamadas de voz que se silencian en una dirección en el PGW 2200 PSTN Gateway de Cisco (Cisco PGW2200). La información en este documento se aplica específicamente a la solución de gateway PSTN de Cisco usando los gatewayes del Media Gateway Controller (MGC) y del Cisco AS5x00 conjuntamente con Cisco PGW2200.

Antes de comenzar

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

prerrequisitos

No hay requisitos previos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las versiones de software y hardware indicadas a continuación.

Plataforma Nombre de la plataforma Versión
Nodo PGW2200 Cisco MGC 9.2(2) [de la corrección S(29)] 9.3(2) [de la corrección S(7)] 9.4(1)
Gateway PSTN AS5x00 12.2T o más arriba

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Flujos de Llamada

La comprensión de las diversas configuraciones encendido corte-por vía el routing.mml puede ayudarle a entender los diversos flujos de llamada para el concepto de Cisco PGW2200.

Flujo de llamada típico con Corte-por en el ANM

Un flujo de llamada típico con corte-por en el ANM (tal como 3) se muestra abajo:

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: El MDCX opcional se envía al gateway de terminación para girar la cancelación de eco solamente si:

  • se fija la propiedad “EchoCanRequired” del grupo troncal, y

  • el Switch del término TDM no proporcionó la cancelación de eco (por ejemplo, el parámetro de Echo_control_device_indicator en el mensaje ACM del término TDM fue fijado a cero).

Flujo de llamada típico con Corte-por en el ACM

Un flujo de llamada típico con corte-por en el ACM (por ejemplo corte-por los iguales 2) se muestra abajo:

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: Cuando la llamada está ocupada o hay una cierta clase de aviso a jugar al llamador, no hay razón para abrir el trayecto de la voz en las ambas direcciones. Si usted piensa usted tiene una llamada muda señalada, publica un comando debug mgcp packet en el gateway de origen y destino conjuntamente con un comando show call history voice conectado a los mensajes a un cero enviado cuenta de paquetes, un comando show call history voice brief, y una traza del Idioma para la definición de mensaje de Cisco (MDL) en el PGW2200 de entender el problema. Una traza del snooper también le ayudará a entender el problema. La traza MDL proporciona un flujo de llamada completo SS7 y del Media Gateway Control Protocol (MGCP).

Llamadas silenciadas informe de los clientes

Las condiciones siguientes hacen el PGW2200 señalar las llamadas mudas (durante el [DLCX] de la conexión de la cancelación) y la detección por medio de una bandera en platform.log. Estos registros contienen un ID de llamada que tenga la información del gateway y la información de CIC.

  1. El PGW2200 se configura en el modo tolerante del incidente.

  2. La llamada fue contestada (la llamada estaba con éxito corte-por.).

  3. El mensaje de 250 AUTORIZACIONES fue recibido con (P:) en respuesta al DLCX.

  4. Paquete los iguales enviados paquete (PS) 0 o recibido (las RRPP) igualan 0 adentro (P:).

  5. La Duración de la llamada era más de 1 segundo.

Recogida de la información de la llamada adicional

Para recoger la información de la llamada adicional, utilice los pasos siguientes:

  1. Haga una conexión Telnet al gateway as5xxx-1.

  2. Publique el siguiente comando de encontrar el ID de llamada detrás otra vez que se conecta al punto final y al mensaje mudo de la llamada de platform.log:

    as5xxx-1 > show mgcp connection
    

    Lo que sigue es salida de muestra del comando show mgcp connection para las conexiones de la voz sobre 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

Las Descripciones del campo del comando show mgcp connection para el VoIP se muestran abajo.

  • Punto final — El punto final para cada llamada, mostrado en la convención para nombres del punto final digital del número de slot (s0) y de la Línea digital (DS1-0) número (1).

  • Call_ID (C) — El ID de llamada MGCP enviado por el agente de la llamada, el ID de llamada de la interfaz de programación de la aplicación de control de la llamada interna (CCAPI) para este punto final, y el ID de llamada del CCAPI para los tramos de llamada de peer. El CCAPI es un API que proporciona los recursos de Control de llamadas a las aplicaciones.

  • Conn_ID(I) — El ID de conexión generado por el gateway y enviado en el mensaje ACK.

  • Ort (P) — los puertos usados para esta conexión. El primer puerto es el puerto local del User Datagram Protocol (UDP). El segundo puerto es el puerto del telecontrol UDP.

  • Oda (M) — el modo de llamada, donde:

    • 0 — Indica un valor inválido para el modo.

    • 1 — Indica que el gateway debe enviar solamente los paquetes.

    • 2 — Indica que el gateway debe recibir solamente los paquetes.

    • 3 — Indica que el gateway puede enviar y recibir los paquetes.

    • 4 — Indica que el gateway debe ni enviar ni recibir los paquetes. [Inactive]

    • 5 — Indica que el gateway debe poner el circuito en el Loopback Mode.

    • 6 — Indica que el gateway debe poner el circuito en el modo de prueba.

    • 7 — Indica que el gateway debe utilizar el circuito para el acceso a la red para los datos.

    • 8 — Indica que el gateway debe poner la conexión en el modo del Network Loopback.

    • 9 — Indica que el gateway debe poner la conexión en el modo de prueba de continuidad de la red.

    • 10 — Indica que el gateway debe poner la conexión en el modo de conferencia.

  • INFORMACIÓN del tate (S) — ejemplo: S=4,4 que el número entero del puño muestra que el estado de la llamada local MGCP y el segundo número entero muestra al estado de la llamada del telecontrol MGCP.

    MGCP_CALL_IDLE = 0, ocioso
    MGCP_CALL_SETTING = 1, llamada entrante del PSTN
    MGCP_CALL_CONNECTING = 2, MGCP CRCX recibido
    MGCP_CALL_CONFERENCING = 3, llamada conectada, aguardan el conf
    MGCP_CALL_ACTIVE = 4, conferencia creada
    MGCP_CALL_CONF_DESTROYING = 5, conferencia de destrucción
    MGCP_CALL_DISCONNECTING = 6, conf destruido, llamada de la desconexión
    MGCP_CALL_INACTIVE = 7, llamada en el modo inactivo
    MGCP_CALL_VOICE_CONNECTING = 8, creando el tramo de llamada de telefonía solamente
    MGCP_CALL_VOICE_ACTIVE = 9, tramo de llamada de telefonía creado
    MGCP_CALL_CONF_DISSOCIATING = 10, conf de destrucción
    MGCP_CALL_CALLLEGS_DISSOCIATED =11, conf destruido, ningún discon de la llamada
    MGCP_CALL_HP_CONNECTING = 12, conexión del tramo de llamada de la horquilla TDM
    MGCP_CALL_HP_CONNECTED = 13, un tramo de llamada de HP conectado
    MGCP_CALL_HP_CONFERENCING = 14, tramo de llamada del retorno de llamada TDM de conferencia
    MGCP_CALL_HP_ACTIVE = 15, estado activo del Retorno de llamada de TDM
    MGCP_CALL_VOIP_CONF_DESTROY = 16, conf destruido, hacen la llamada de HP
    MGCP_CALL_ERROR_STATE = 17, llamada en el estado de error
    MGCP_CALL_CONNECTING_INACTIVE = 18, creando la conexión inactiva
    MGCP_CALL_CONF_DESTROYING_INACTIVE = 19, conf destruyen la conexión inactiva
    MGCP_CALL_CONT_TEST = 20, prueba de continuidad AAL2/IP (xrbk)
    MGCP_CALL_SETUP_WAIT = 21, para información de configuración que espera
    MGCP_CALL_WAIT_NSE_SENT = 22, espera para que evento NSE sea enviado
    MGCP_CALL_TWC_ACTIVE = 23, active de la llamada TWC
    MGCP_CALL_WAIT_STATE = 24, App está esperando el Control de llamadas
    MGCP_CALL_HANDOVER = 25, App está asiendo apoyan el control
    MGCP_CALL_EM_DISCONNECTING = 26, llamada de la desconexión, puntos finales E&M
    MGCP_CALL_MAX_STATE = 27

  • Odec info (del C) — ejemplo: C=1

    MGCP_CODEC_UNDEFINED 0
    MGCP_G711_U, 1 = Mu-law de G.711
    MGCP_G711_A, 2 = Ley a de G.711
    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 = alta velocidad G.723.1
    MGCP_G7231_A_HIGH_RATE, 12 = anexo G.723.1 a la alta velocidad
    MGCP_G7231_LOW_RATE, 13 = G.723.1 de tarifa reducida
    MGCP_G7231_A_LOW_RATE, 14 = anexo G.723.1 un de tarifa reducida
    MGCP_GSM_FULL_RATE, 15 = GS de exploración completa
    MGCP_GSM_HALF_RATE, 16 = GS de media exploración
    MGCP_GSM_ENHANCED_FULL_RATE, 17 = Enhanced Full Rate GS
    MGCP_GSM_ENHANCED_HALF_RATE, 18 = GS aumentaron de media exploración
    MGCP_CLEAR_CHANNEL = 128, 128 = canal despejado del Nx64
    MGCP_NSE = 129 Para el NSE

  • Respiradero (E) — ejemplo: El E=3,0,2,3 el campo del evento se lee 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, El MGCP crea los msg de la conexión
    MGCP_APP_EV_DELETE_CONN, =1 Msg de la conexión de eliminación de MGCP
    MGCP_APP_EV_MODIFY_CONN, =2 El MGCP modifica los msg de la conexión
    MGCP_APP_EV_NOTIFY_REQ, =3 El MGCP notifica los msg de la petición
    MGCP_APP_EV_ALERT, =4 Evento de alerta CCAPI
    MGCP_APP_EV_CALL_CONNECT,=5 La llamada del CCAPI conecta el evento
    MGCP_APP_EV_CONF_RDY,=6 Conferencia CCAPI lista
    MGCP_APP_EV_CONF_DESTROY,=7 Conferencia CCAPI destruida
    MGCP_APP_EV_CALL_DISCONNECT,=8 Desconexión de la llamada del CCAPI
    MGCP_APP_EV_CALL_PROCEED, =9 Procedimiento de la llamada del CCAPI
    MGCP_APP_EV_OFF_HOOK,=10 Descolgado/configuración de la llamada ind del CCAPI
    MGCP_APP_EV_ON_HOOK, =11 En-gancho/llamada del CCAPI desconectada
    MGCP_APP_EV_MEDIA_EVT,=12 Eventos de medios MGCP
    MGCP_APP_EV_INT_EVT,=13 Eventos internos de MGCP
    MGCP_APP_EV_DISSOC_CONF,=14  
    MGCP_APP_EV_ASSOC_CONF,=15  
    MGCP_APP_EV_MODIFY_DONE,=16 La llamada del CCAPI modifica el ev hecho
    MGCP_APP_EV_VOICE_MODE_DONE,=17 La Voz Corte-por ha sucedido
    MGCP_APP_EV_NSE,=18 Eventos CCAPI NSE
    MGCP_APP_EV_CALL_HANDOFF,=19 Llamada de las manos a un poco de otro app
    MGCP_APP_EV_MAX_EVENT  

  • Esult (R) — ejemplo: El R=0,0 el campo de resultado se interpreta como: ¿R=Event_result, (boleano) hace nosotros necesita enviar el ACK?

    MGCP_APP_EVR_NORMAL_OK = 0, Evento normal de MGCP procesado OK
    MGCP_APP_EVR_INVALID_OK, Evento MGCP inválido procesado OK
    MGCP_APP_EVR_CALLP_REL, se libera el registro de llamada
    Errores del protocolo MGCP/* *
    MGCP_APP_EVR_INVALID_CALL_ID = 10, El TGW encuentra el ID de llamada inválido
    MGCP_APP_EVR_INVALID_CONNECTION_ID, El TGW encuentra el ID de conexión inválido
    MGCP_APP_EVR_DUPLICATED_MESSAGE, Msg duplicados hallazgo del sgcp TGW
    MGCP_APP_EVR_MGCP_ACK_FAILURE, El TGW no puede enviar los msg ack del sgcp
    MGCP_APP_EVR_MGCP_DELETE_FAILURE, El TGW no puede enviar los msg de la cancelación del sgcp
    MGCP_APP_EVR_MGCP_CREATE_ACK_FAILURE, El TGW no puede enviar crea los msg ack
    MGCP_APP_EVR_MGCP_CREATE_ACK_MISSING, El TGW no envió los msg ack del sgcp
    MGCP_APP_EVR_MGCP_DELETE_ACK_FAILURE, El TGW no puede enviar los msg ack de la cancelación
    MGCP_APP_EVR_MGCP_NOTIFY_FAILURE, El TGW no puede enviar el sgcp notifica los msg
    MGCP_APP_EVR_INVALID_STATE, Evento del hallazgo TGW en el estado incorrecto
    Problema de recurso/* *
    MGCP_APP_EVR_TGW_DOWN = 30, TGW en el modo del Cierre elegante
    MGCP_APP_EVR_TGW_NOT_READY, TGW no listo para el evento
    MGCP_APP_EVR_CALL_VDB_FAILURE, El TGW no puede obtener el vdbptr
    MGCP_APP_EVR_PREV_RTP_PORT_LOCKED, El TGW encuentra el puerto anterior del rtp bloqueado
    MGCP_APP_EVT_CONN_RECORD_MISSING, El TGW no puede encontrar el expediente conec
    MGCP_APP_EVR_ENDP_NOT_READY, TGW no listo para el evento
    MGCP_APP_EVR_MEM_RSRC_ERROR, El TGW hace que el alloc de memoria transitoria yerre
    MGCP_APP_EVR_CALL_CAC_FAILURE, El GW no tiene el ancho de banda
    MGCP_APP_EVR_CONF_RSRC_ERROR, El GW no puede conseguir el recurso del conf
    Falla del evento/* *
    MGCP_APP_EVR_REQ_EVENT_FAILURE = 40, El TGW no puede manejar el evento pedido
    MGCP_APP_EVR_INVALID_CCAPI_EVENT, El TGW no puede manejar el evento ccapi
    MGCP_APP_EVR_IGNORE_CCAPI_EVENT, El TGW ignorará el evento ccapi
    Falla de señal/* *  
    MGCP_APP_EVR_SIGNAL_FAILURE = 50, El TGW no puede manejar la señal
    MGCP_APP_EVR_ABNORMAL_ONHOOK, Colgado anormal del hallazgo TGW
    MGCP_APP_EVR_INVALID_OFFHOOK, Offhook inválido del hallazgo TGW
    MGCP_APP_EVR_INVALID_COT, Hallazgo TGW cot inválido
    MGCP_APP_EVR_COT_FAILURE, El TGW no pudo hacer el COT
    MGCP_APP_EVR_COT_DISABLE_FAILURE, El TGW no pudo inhabilitar el COT
    Falla de configuración de la llamada/* *
    MGCP_APP_EVR_CALL_SETUP_REQ_FAILURE = 60, El TGW no puede poner el pedido de llamada
    MGCP_APP_EVR_CALL_SETUP_IND_FAILURE, El TGW no puede manejar la indicación de la llamada
    MGCP_APP_EVR_CALL_CONTEXT_FAILURE, El TGW no puede poner el contexto
    MGCP_APP_EVR_CALL_PEER_FAILURE, El TGW no puede poner al par
    MGCP_APP_EVR_CALL_VOX_CALL_FAILURE, El TGW no puede poner la llamada voip/voaal2
    MGCP_APP_EVR_CALL_VOIP_CALL_FAILURE, El TGW no puede poner la llamada del voip
    MGCP_APP_EVR_CALL_DISCONNECT_FAILURE, El TGW no puede desconectar la llamada
    MGCP_APP_EVR_CALL_MODIFY_FAILURE, El TGW no puede modificar el parm de la llamada
    MGCP_APP_EVR_CALL_ALERT_FAILURE, El TGW no puede alertar la llamada
    MGCP_APP_EVR_CALL_DELETE_FAILURE, El TGW no puede borrar la llamada
    MGCP_APP_EVR_CALL_UNKNOWN_FEATURE, El TGW no puede manejar la característica del unknow
    MGCP_APP_EVR_UNSUPPORTED_CODEC, Códecs no admitidos del hallazgo TGW
    MGCP_APP_EVR_NO_DIGIT_MAP, El TGW no puede encontrar el mapa de dígito
    MGCP_APP_EVR_IGNORE_DIGIT, El TGW no puede procesar los dígitos
    MGCP_APP_EVR_DIGITS_OVERFLOW, El TGW no puede manejar demasiados dígitos
    MGCP_APP_EVR_DIGITS_NOTIFY_FAILURE, El TGW no puede mandar los dígitos
    MGCP_APP_EVR_CODEC_NOT_MATCHED, El códec TGW no hace juego el rmt TGW
    MGCP_APP_EVR_INVALID_CONN_MODE, El TGW no puede entender el modo de la estafa
    Error del par/* *
    MGCP_APP_EVR_PEER_MISSING = 90, Hallazgo TGW no encontrar al par
    MGCP_APP_EVR_PEER_NOT_READY, Par del hallazgo TGW no listo
    MGCP_APP_EVR_PEER_IN_WRONG_STATE, El TGW encuentra al par en el estado incorrecto
    MGCP_APP_EVR_PEER_DISCONNECT_FAILURE, El TGW no puede desconectar al par
    MGCP_APP_EVR_NO_CONFERENCE_ID, El TGW no puede encontrar el ID de conferencia
    MGCP_APP_EVR_CONF_CREATE_FAILURE, El TGW no puede crear la conferencia
    MGCP_APP_EVR_CONF_DESTROY_FAILURE, El TGW no puede destruir la conferencia
    MGCP_APP_EVR_UNKNOWN_CONN_TYPE, El TGW no puede manejar el tipo de la estafa
    MGCP_APP_EVR_INVALID_ENDPOINT, El TGW no puede conectar con el punto final
    MGCP_APP_EVR_INVALID_NSE_EVENT = 100, Evento NSE inválido
    MGCP_APP_EVR_NSE_RCVD_ON_WRONG_LEG, Los eventos NSE vienen a una pierna incorrecta
    MGCP_APP_EVR_SEND_NSE_FAILURE, No puede enviar un evento NSE
    MGCP_APP_EVR_PLAY_TONE_FAILURE, No sabe jugar el tono NSE-pedido
    Error transitorio/* *
    MGCP_APP_EVR_TRANS_ERROR = 110, Punto final TGW en el estado de transición
    MGCP_APP_EVR_MAX_RESULT  

Posibles causas y acciones recomendadas

Entendiendo y definiendo su problema

Las llamadas del mudo se pueden conectar a los problemas del software o a otras cuestiones. Utilice los pasos siguientes para comenzar a resolver problemas las llamadas mudas en Cisco PGW2200.

  1. Entienda la descripción de problemas del cliente. Las llamadas del mudo se pueden relacionar con otros elementos que no se enlacen a los errores del software tales como problemas del Routing IP y del Layer 1. La solución de cada causa raíz expone a menudo los problemas de nivel inferior adicionales que necesitan ser reparados primero.

  2. Calcule la relación de transformación de las llamadas fallidas para silenciar las llamadas en la ubicación del cliente por la supervisión de 24 horas.

  3. Avoid que define exactamente qué porcentaje de las llamadas es alarmante.

  4. Intente reproducir esta situación para entender la causa real del problema.

El marcar carga de la CPU en el PGW2200

Para comprobar carga de la CPU el PGW2200, publique el siguiente comando:

mml> rtrv-ne-health

Este comando visualiza el siguiente tipo de información:

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" 
;

Marque la información de las llamadas por segundo (los CP) e intente calcular esto conjuntamente con los gatewayes que usted está utilizando. Algunos gatewayes tienen quizá CPU elevada una carga debido a la cantidad de llamadas que vienen adentro. La visualización siguiente del resultado en platform.log también puede explicar el estatus del 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: En este ejemplo, había sobrecarga de la CPU una condición debido al mucho tráfico que redujo en unos minutos. Esto es como resultado de período de la hora pico. En ese momento, intente enlazar esta información a las llamadas mudas.

El marcar carga de la CPU en los gatewayes

Para obtener un estatus durante una determinada cantidad de hora, publique el siguiente comando:

as5xxx-1> show proc cpu history

CPU elevada una carga se puede causar por uno de los elementos que son conectados al process switching. Para marcar esto, publique los ejecutar-config de la demostración | comando route del incl.

as5xxx-1> show running-config | incl route 

Para evitar CPU elevada una carga en el gateway, no tenga los siguientes comandos en sus configuraciones:

no ip route-cache
no ip route-cache cef 

Nota: El comando ip route-cache o ip route-cache cef debe ser configurado en los gatewayes.

Si usted ve antedicho un de los, usted es process switching más probable en vez de la transferencia rápida y la carga del sistema será extremadamente alta, las llamadas pueden ser perdidas, y la Calidad de voz será pobre. Además, el mensaje MGCP no puede ser reconocido (ACK) o ser generado.

Mensajes RSIP no enviados en Ethernet secundaria

Dependiendo de la manera que configuran al comando ip host en los gatewayes, él no enviará los mensajes RSIP en Ethernet secundaria. La razón que el gateway está intentando enviar a la primera dirección IP para una segunda ronda de los intentos antes de fallar encima a la segunda dirección IP se conecta a la configuración del software del ½ del ¿Â de Cisco IOSïÂ. Esto fuerza una búsqueda de DNS (que mire un comando ip host cuando configuran al comando no ip domain-lookup). Cuando sucede esto, la primera dirección IP se vuelve y se utiliza otra vez. Para evitar este comportamiento, utilice el siguiente comando en el perfil MGCP:

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

Nota: Usted necesita recargar al router para que la configuración del comando no max1 lookup tome el efecto.

Sugerencias para Troubleshooting mudas de la llamada

Realice los pasos siguientes para determinar si hay problemas adicionales en su red.

  1. Determine si la Duración de la llamada es menos de 10 segundos.

  2. Determine si los paquetes del transmitir (tx) o reciba los paquetes (del rx) son cero.

    as5xxx-1> show mgcp connection 

    Y control en el Call_ID, que es 3334373 por este ejemplo.

    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. Intente conectar el Call_ID usando el siguiente:

    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. En este momento, usted puede encontrar la información del comando show call active voice, conectado en Conn_ID para encontrar los paquetes del tx, los bytes del tx, los paquetes del rx, y la información de bytes del rx. Esta información puede decirle los números de paquetes que son enviados y recibidos.

    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 

    En este caso, usted puede encontrar los detalles del Local y del 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 si un porcentaje más grande de las llamadas mudas ocurre durante los períodos ocupados.

En las situaciones poco comunes, los paquetes enviados por el Cisco AS5400 no se pueden recibir por la interfaz del Cisco AS5300 TDM. Si ocurre esto, el Cisco AS5400 DLCX ACK muestra los paquetes del tx, pero el Cisco AS5300 no muestra ninguna paquetes del rx. El Loopback Interface es importante para la conexión de MGCP conjuntamente con el comando mgcp bind.

Nota: La implementación de MGCP utiliza la mejor dirección IP disponible en el MGC como dirección de origen para comunicar con el agente de la llamada. La secuencia de medios utiliza el Loopback Address si está configurada, si no la mejor dirección IP disponible como su dirección de origen. No hay manera definida de cambiar este comportamiento. El comando bind permite más flexibilidad para elegir a la dirección de origen para el control y los paquetes de medios.

Se enumeran abajo algunas situaciones que explican el comportamiento del comando. Para todos estos casos, el mensaje de advertencia apropiado será visualizado dependiendo de la situación.

  • Cuando hay activo el MGCP llama en el gateway, rechazarán al comando bind para el control y los media.

  • Si la interfaz del lazo no está para arriba, después se valida el comando, pero no toma la influencia hasta que suba la interfaz.

  • Si la dirección IP no se asigna en la interfaz del lazo, validan al comando bind pero toma el efecto solamente después que se asigna el IP Address válido, durante este tiempo si las llamadas MGCP están para arriba, el comando bind se quita.

  • Cuando la interfaz encuadernada va abajo, o debido a un manual cierre en la interfaz o debido a una falla de funcionamiento, la actividad del lazo se inhabilita en esa interfaz.

  • Cuando el lazo no se configura en el MGC, la dirección IP utilizó para el control de la compra de componentes MGCP y el media es mejor dirección IP disponible.

Tareas adicionales relacionadas para silenciar las llamadas

Uno de los criterios que el PGW2200 utiliza para señalar una llamada por medio de una bandera muda es que la llamada debe estar en el estado de la respuesta, así que él significa que el mensaje ANM se debe haber enviado por el PGW2200 al Switch que origina SS7. Antes de enviar el mensaje ANM al Switch que origina SS7, el PGW2200 transmite el MDCX al GW para fijar el modo al Enviar-recv. Si el MDCX no es reconocido por el GW debido a la Conectividad o a otros problemas, la llamada no alcanza el estado de la respuesta, por lo tanto no se sigue pues una llamada muda. En ese momento, un registro de error será enviado al archivo de platform.log en opta/CiscoMGC/var/registro.

Comando mgcp vuelto a enviar

Si no lo hizo el mensaje del comando MGCP (CRCX, DLCX, MDCX) es vuelto a enviar debido a un time-out (por ejemplo [sendrecv] enviado PGW2200 MDCX cuatro veces), solamente el gateway ACK él, la llamada falla y no es considerada una llamada muda por el PGW2200. El PGW2200 señala una llamada por medio de una bandera muda (mudo-mensaje en platform.log) durante el DLCX si:

  1. La llamada fue contestada, y

  2. un mensaje de 250 AUTORIZACIONES tenía parámetro de la conexión (P:), y

  3. El PS o las RRPP era 0 en (P:)

Nota: Esto se puede conectar a otros elementos no enlazados como una llamada muda real. Por ejemplo, si la parte llamadora cuelga para arriba cuando las respuestas de la Parte llamada, usted consideran este mensaje y está correcto. Pero esto no es una llamada muda. Para las llamadas de la horquilla (el hairpinning es el nombre dado a las llamadas que originan y terminan en el mismo router o el gateway), el mensaje de 250 AUTORIZACIONES en respuesta al DLCX no tiene parámetro de la conexión (P:). Estas llamadas son no se señalan por medio de una bandera como mudo.

Comprensión del registro de error

Un error se escribe en el formato siguiente para volver a enviar la información:

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

Ejemplo:

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.

Transacción borrada

Si una transacción se borra después de las cantidades de intentos máximas, un error se escribe en el formato siguiente:

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

Ejemplo:

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

Publique el comando show mgcp stat de comprobar los elementos fallados y de intentar entender porqué una transacción fue borrada.

Recogida de una traza MDL en el PGW2200

Si todos los elementos están correctos, ejecute una traza MDL y recoja todos los detalles del comando show log en el GW. Los pasos siguientes muestran cómo recoger la traza MDL:

  1. Identifique el número del SigPath que origina SS7 u originar el número del TrunkGroup en el cual se ponen las llamadas.

  2. Comience la traza MDL publicando el siguiente comando:

    mml> sta-sc-trc:ss7sigPath name | orig
    		  trunkgroup number
    
    
  3. Realice una prueba.

  4. Pare la traza MDL publicando el siguiente comando:

    mml> stp-sc-trc:all
    
  5. Identifique el ID de llamada (C:) de la mala llamada del debug MGCP en el gateway.

  6. Convierta la traza MDL en un formato legible:

    mml> get_trc.sh trace file name
    
    
  7. Teclee el ID de llamada en el prompt para saltar a la traza MDL de la mala llamada.

  8. Elija el C de la opción para convertir el archivo de traza.

  9. El archivo de traza está en /opt/CiscoMGC/var/trace.


Información Relacionada


Document ID: 44183