Errores de la llamada del Troubleshooting en las puntos finales TC registradoas a Cisco CallManager

Introducción

Este documento explica algunos de los problemas comunes del error de la llamada hechos frente con las puntos finales del codificador-decodificador de Tandberg (TC) registradoas a Cisco CallManager y Soluciones sugeridas.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

Cómo capturar los registros de la depuración de H.323

Note: Asegure aseguran la salida de la sesión del host del socket (SSH) se captura.

1. SSH en el codificador-decodificador CLI y ingresan estos comandos:
   • depuración 9 del ctx H.323Packet del registro
   • salida del registro en (esto hace salir todos los registros a la pantalla de la sesión terminal de la sesión de SSH.)
2. Comience una llamada y reconstruya el problema.
3. Ingrese la salida del registro apagado y el ctx H.323Packet del registro pone a punto de los comandos.

Cómo capturar los registros de la depuración del Session Initiation Protocol (SIP)

Note: Asegúrese que salida de la sesión de SSH esté capturado.

1. SSH en el codificador-decodificador CLI y ingresan estos comandos:
   • depuración 9 de SIPPacket del ctx del registro
   • salida del registro en (esto hace salir todos los registros a la pantalla de la sesión terminal de la sesión de SSH.)
2. Comience una llamada y reconstruya el problema.
3. Ingrese la salida del registro apagado y el ctx SIPPacket del registro pone a punto de los comandos.

Cómo recoger los registros de la punto final de la captura del paquete de las puntos finales TC

1. Del GUI de la red elija los diagnósticos > los archivos del registro y active el registro extendido con la captura del paquete completo.
2. Comience una llamada y reconstruya el problema. Observe que la captura de paquetes puede ser activada solamente por 3 minutos.
3. Del GUI de la red elija los diagnósticos > los archivos del registro y descargue el archivo y a la captura de paquetes completos del registro.

La otra información requerida

• Flujo completo de la llamada con todos los dispositivos implicados
• Números de origen y de destino de llamada
• La fecha y hora del problema ocurrió

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en 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 cualquier comando.

Problema: Llame a las fallas debido para llamar el problema del espacio de búsqueda (CSS) /Partition en el CallManager

Las llamadas entre dos puntos finales registradoas al encargado de las Comunicaciones unificadas de Cisco (CUCM) pudieron fallar debido a un problema CSS/Partition en el CUCM.

Capture los registros de llamada del SORBO de la punto final. Este” mensaje no encontrado "404 aparece en los registros del SORBO de la punto final que vienen del CUCM:

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

Solución

Complete estos pasos para controlar el CSS de la punto final de llamada y la división de la punto final llamada. Asegúrese que el CSS de la punto final de llamada tenga la división de la punto final llamada.

Usted puede asignar un CSS en el dispositivo y el nivel de línea en la punto final:

1. Elija el Device (Dispositivo) > Phone (Teléfono), seleccione la punto final y haga clic en la línea, y controle el espacio de búsqueda de llamada (CSS) en el nivel de línea. En este ejemplo, no se configura ningún CSS en el nivel de línea. Sin embargo si hay un CSS en el nivel del número de directorio, cualquiera del CSSs tiene que tener partiton del número al que se llamó:

   

2. Controle el CSS asigned en el nivel del teléfono. Elija el Device (Dispositivo) > Phone (Teléfono) y seleccione la punto final de llamada en la pregunta:

   

3. Controle la división del número al que se llamó. Elija el Device (Dispositivo) > Phone (Teléfono), seleccione el dispositivo llamado, haga clic en la línea, y controle la ruta Partion:

   

4. Después de que usted verifique el Partiton y el CSS en ambas puntos finales, controle si el CSS del dispositivo de llamada tiene la división del dispositivo llamado:

   

   Si no, ésta podía ser la causa del” error no encontrado "404.

Problema: Descenso de la llamada del SORBO después de 15 minutos (o después de cualquier tiempo específico)

Los descensos de la llamada en los intervalos de tiempo específico son causados generalmente por los temporizadores o el tiempo de espera agotado de TCP del SORBO configurados en los Firewall, Routers, y así sucesivamente.

Solución

Cuando las desconexiones de la llamada en exactamente 15 minutos, el problema común considerado son el tiempo de espera agotado de TCP configurado en la red (Firewall, Routers) son menos que la sesión del SORBO expira temporizador. Por abandono en CallManager, la sesión del SORBO expira temporizador se fija a 1800 segundos.

Para verificar esto, elija la administración cm > el sistema > los parámetros de servicio > el servicio unificados Cisco del encargado de llamada de Cisco > buscan - la sesión del SORBO expira temporizador.

Todas las puntos finales registradoas a CUCM utilizan este temporizador. Cuando la punto final está en la llamada con otro punto final remoto, uno de los partidos tiene que restaurar la sesión y envía una re-INVITACIÓN o una ACTUALIZACIÓN. Esto restaura tiene que ser enviada antes de que expire la mitad de la sesión 15minutes del temporizador (1800/2 = 900 segundos =). Si no hay mensaje de actualización recibido, la llamada es disconnected.

La comprobación para el temporizador de sesión en la inicial INVITA. Una restauración (INVITE/ACTUALIZACIÓN) debe ser recibida antes de que expire este vez:

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

De acuerdo con la negociación inicial del servidor del agente de /User del cliente del agente de usuario (UAC/UAS), una de las puntos finales restaura la sesión cuando envía una Re-INVITACIÓN. Si el refresco es UAC, el iniciador de la llamada tiene la responsabilidad de restaurar la sesión. Si el refresco es UAS, el servidor tiene que restaurar la sesión. Recoja los registros de la depuración del SORBO de ambas puntos finales y controle estos items:

Ejemplo: Llamada hecha del partido A a CUCM para ir de fiesta el B. Si es el refresco UAC encendido van de fiesta A y UAS en el partido B:

1. Vaya de fiesta A tiene que enviar la re-INVITACIÓN/la ACTUALIZACIÓN al CUCM.
2. CUCM tiene que enviar una re-INVITACIÓN/una ACTUALIZACIÓN para ir de fiesta el B.
3. El partido B recibe la re-INVITACIÓN y responde a ese mensaje con una AUTORIZACIÓN 200.
4. CUCM tiene que enviar la AUTORIZACIÓN 200 para ir de fiesta el A.

Si una punto final envía el mensaje de la re-INVITACIÓN al CUCM, CUCM envía una re-INVITACIÓN al otro partido. Sin embargo, si esto no es recibida por el lado remoto entonces esto podría estar debido a algunos dispositivos de red mientras tanto. Es altamente posible que la re-INVITACIÓN/la respuesta no consigue a uno de los lados debidos SORBER el examen o las configuraciones de red.

Si las puntos finales no inician la re-INVITACIÓN, podría ser un problema con la punto final. Implique el centro de la asistencia técnica de Cisco (TAC) para investigar más lejos.

Problema: Descensos de la llamada de H.323 después de cualquier tiempo específico

Como con el SORBO, en los descensos de la llamada de las llamadas de H.323 en un intervalo de tiempo específico ocurra generalmente debido a la configuración del descanso de la red o del Firewall.

Solución

En las llamadas de H.323, un mensaje de la petición del retardo de ida y vuelta (RTDR) se envía cada 30 segundos entre las puntos finales junto con los números de serie. Para cada petición, se espera una respuesta.

La punto final de Cisco utiliza el mensaje de respuesta del retraso de latencia RTDR/Round, que es una parte del sistema multimedios H.245 de mensaje de control. Este keps la sesión TCP H.245 viva durante la llamada que se utiliza para la administración de llamadas activa. Si la punto final recibe una respuesta para RTDR inicialmente y no se recibe ninguna respuesta durante la llamada, la punto final termina la llamada.

En este decorado, recoja los registros de la depuración de H.323 y la punto final abre una sesión la orden para aislar el problema. De los registros de la depuración de H.323, controle para saber si hay la petición y mensajes de respuesta RTDR y descubra si cae.

En esta salida de ejemplo, la punto final envía una petición RTDR al punto final remoto y no recibe una respuesta del extremo remoto. Por lo tanto desconecta la llamada:

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

Las peticiones y las respuestas se pueden seguir con los sequenceNumbers.

Este ejemplo de los registros de la punto final muestra la causa para la desconexión:

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

Problema: Falla debido de la llamada a la falla de asignación de los recursos del medio

En el caso de las llamadas video, se consideran las llamadas que fallan debido a un error del alocation de los recursos del medio. Por ejemplo, si la llamada y la punto final llamada no utilizan un códec común entonces se requiere un transcodificador, porque una discordancía multi de la frecuencia del tono dual (DTMF) a la punta de terminación de medios (MTP) se requiere en el encargado de llamada.

Solución

Para la transcodificación video, se requiere un transcodificador del procesador de señal de Digitaces del módulo de Digitaces de los paquetes de voz (PVDM3) (DSP) pues los transcodificadores en el PVDM2 no utilizan el vídeo. Si un transcoder/MTP no está disponible, un mensaje inasequible de 503 servicios sería enviado a la punto final:

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

Para resolver esto, controlar la configuración de la lista del grupo del grupo/recursos del medio de los recursos del medio (MRG/MRGL) y asegurar el vídeo transcoder/MTP está disponible. Un MRGL se puede asignar a un dispositivo en el nivel del teléfono o el nivel de la agrupación de dispositivos:

1. En el CallManger elija el Device (Dispositivo) > Phone (Teléfono) y seleccione el dispositivo que tiene el problema y controle la agrupación de dispositivos y las configuraciones MRGL:

   

2. Si la configuración MRGL en el teléfono no es ninguna, después usted tiene que controlar las configuraciones de la agrupación de dispositivos para asegurarse de que hay un transcodificador.
3. Elija el sistema > a la agrupación de dispositivos y seleccione a la agrupación de dispositivos asignada al dispositivo:

   

4. Elija los recursos del medio > la lista del grupo de los recursos del medio y seleccione el MRGL asignado en el nivel del teléfono/el nivel de la agrupación de dispositivos y controle los MRG:

   

5. Observe los MRG y elija los recursos del medio > al grupo de los recursos del medio y seleccione los MRG conocidos. Asegúrese que usted haga PVDM3 una dotación física transcoder/MTP agregar.

   

Problema: Fallas debido de la llamada al ancho de banda escaso

A menudo hay los decorados adonde una llamada consigue disconnected debido a la configuración de ancho de banda escasa en la región/la ubicación en el dispositivo en CUCM. Cuando la región se fija a un ancho de banda baja que la punto final no pueda utilizar, CallManager envía un media no aceptable "488” con la causa 125 que significa “fuera del ancho de banda” o “del ancho de banda escaso” después de que suceda la negociación de medios del SORBO.

Usted necesita el caputure que el SORBO abre una sesión la punto final según lo descrito y busca este mensaje:

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

Solución

Si sucede este problema, controle la región configurada en ambas las puntos finales y controle la relación de la región entre ellas:

1. Elija el Device (Dispositivo) > Phone (Teléfono) y seleccione ambos dispositivos. Controle a la agrupación de dispositivos asignada a los dispositivos:

   

2. Una vez que usted controla a la agrupación de dispositivos, elija el sistema > a la agrupación de dispositivos en el CUCM y controle la región configurada en ambas agrupaciones de dispositivos:

   

3. Elija el sistema > la información > las regiones de la región y controle la relación de la región. Controle el ancho de banda video audio en la región y asegúrese de que la punto final puede actuar en el ancho de banda audio/video según lo seleccionado:

   

En las capturas de pantalla antedichas se asume que una punto final está en la región “región del tronco” y la otra está en la “región de los puntos finales locales”.

Otra solución alternativa es intentar la llamada video como llamada audio si el ancho de banda para el ancho de banda de llamada video es escaso. Utilice este procedimiento para controlar y configurar:

1. Elija el Device (Dispositivo) > Phone (Teléfono) y seleccione el dispositivo de llamada con el problema. Controle si el parámetro en este tiro de pantalla se controla. Si es desenfrenado, contrólelo de modo que una llamada video recurra al audio en caso de los problemas de ancho de banda:

   

   Este problema podía suceder debido a las configuraciones de ubicación en el CallManager.

   Las ubicaciones se pueden asignar en el nivel del teléfono o en el nivel de la agrupación de dispositivos (el nivel del teléfono toma la prioridad más alta).

2. Para controlar las configuraciones de ubicación llanas del teléfono, elegir los dispositivos > los teléfonos y controlar la ubicación en ambos que llaman y la punto final llamada:

   

   La ubicación puede también ser aplicada en el nivel de la agrupación de dispositivos. Por lo tanto, en primer lugar controle la agrupación de dispositivos de ambas puntos finales:

   

3. Elija el sistema > a la agrupación de dispositivos. En la agrupación de dispositivos, controle la ubicación asignada en ambos la llamada y las puntos finales llamadas. En este ejemplo no se asigna ninguna ubicación en el nivel de la agrupación de dispositivos. Se utiliza la configuración de la ubicación del teléfono:

   

4. Controle si el ancho de banda suficiente se configura entre la llamada y la ubicación llamada de las puntos finales. En esta punto final del Ejemplo 1 se asume para estar en la ubicación de los puntos finales locales y la otra está en la ubicación de Hub_None y el ancho de banda para el audio/las llamadas video e immersive todo se configura como ilimitado:

   

Podía haber otras razones de la desconexión. Véase la página 178 de la guía de la administración de registros del detalle de llamada del encargado de las Comunicaciones unificadas de Cisco, release/versión 10.0(1) para los códigos de la causa de la desconexión.