Colaboración : Cisco Unified Intelligent Contact Management Enterprise

Condición de asincronía en CallRouter ICM/IPCC

15 Abril 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (16 Marzo 2007) | Comentarios

Contenido

Introducción
Requisitos previos
      Requerimientos
      Componentes utilizados
      Convenciones
Descripción
      Registro adicional
      Recopilación de datos
      Solución alternativa
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento señala los pasos recomendados y los niveles de seguimiento necesarios para la resolución de un evento de asincronía en un CallRouter dúplex de administración de contactos inteligentes (ICM) de Cisco Unified Contact Center.

Requisitos previos

Requerimientos

Cisco recomienda poseer ciertos conocimientos acerca de estos temas:

  • ICM de Cisco

  • Alto nivel de conocimiento de la funcionalidad del controlador central de ICM.

  • Regedit

  • Microsoft SQL

Componentes utilizados

La información que contiene este documento se basa en Cisco ICM 5.x y versiones posteriores.

La información que contiene este documento se creó a partir de los dispositivos en un entorno de laboratorio específico. Todos los dispositivos que se utilizan en este documento se iniciaron con una configuración sin definir (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones sobre consejos técnicos de Cisco para obtener más información sobre las convenciones del documento.

Descripción

En raras circunstancias, los CallRouter ICM pueden perder la sincronía con su socio dúplex. El principal disparador de este evento es una suma de comprobación errónea entre el CallRouter y su par. Cuando CallRouter pierde la sincronía se genera un archivo de vaciado de objetos estándar (SOD), es decir, un vaciado de la memoria del router en el momento del fallo.

Un evento de asincronía puede provocar un enrutamiento incorrecto de las llamadas por parte del CallRouter.

Cualquiera de los siguientes métodos se puede emplear para comprobar si existen condiciones de asincronía:

  • Los CallRouter llevan a cabo, cada 15 segundos y de manera automática, una sincronización entre los dos lados. Si se detecta un caso de pérdida de sincronía, CallRouter crea un archivo SOD en el directorio:

    <drive>:\icm\<instance>ra
    and
    <drive>:\icm\<instance>rb
  • Este mensaje se genera en el registro de aplicación dentro del visor de eventos de Windows del CallRouter. Estos son los detalles del mensaje:

    the router has detected that it no longer synchronized with its partner

    También se genera una trampa SNMP.

  • En los registros de CallRouter (rtr) (sólo ejemplos):

    ra-rtr The router has detected that it is no longer synchronized with its partner
    ra-rtr Trace: RunningSyncCheck failure: SideA reported 0A7FDF68, B reported FF1319C5
    ra-rtr Trace: Wrote 719296 records to sync32932.sod, total length = 1871522788 bytes
    ra-rtr Trace: Router dump created in sync32932.sod
    rb-rtr The router has detected that it is no longer synchronized with its partner
    rb-rtr Trace: RunningSyncCheck failure: Side A reported 0A7FDF68, B reported FF1319C5
    rb-rtr Trace: Wrote 719296 records to sync32932.sod, total length = 187152790 bytes
    rb-rtr Trace: Router dump created in sync32932.sod

Registro adicional

Nota: Los archivos SOD estándar que se generan por la pérdida de sincronía de CallRouter presentan limitaciones, por lo que pueden darse casos en los que los ingenieros necesiten un nivel más detallado de depuración para poder aislar mejor el problema. Si ejecuta ICM 5.0 (0) SR8 u otras versiones posteriores, tiene dos claves de registro que se pueden activar para aumentar la depuración de los archivos SOD.

Active estas depuraciones de registro en ambos CallRouter:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\
<cust_instance>\RouterX\Router\CurrentVersion\Debug

Existen dos entradas, MessageTrackingEnabled (Activación del seguimiento de mensajes) y MessageTrackingLimit (Limitación del seguimiento de mensajes).

Establezca los siguientes valores:

  • MessageTrackingEnabled = 1

  • MessageTrackingLimit = 10000 (valor decimal)

Nota: Estos valores son dinámicos y tienen efecto inmediato. Esto no causa ningún comportamiento extraño de ICM. Al establecer estos bits de seguimiento, si se produce otra condición de asincronía se activa una depuración de archivo SOD más detallada. No es necesario desactivar estos dos bits de seguimiento; deben estar activados. Sin embargo, estos bits de seguimiento se restablecen en sus valores predeterminados (esto es, apagados) si la configuración se ejecuta en los CallRouter. Si esto ocurre, se deben volver a activar de forma manual.

Recopilación de datos

Los siguientes datos e información son necesarios si desea solicitar ayuda al Soporte de Cisco para resolver la interrupción:

  1. Anote la hora exacta del fallo.

  2. Recopile los registros del CallRouter desde ambos lados (rtr, mds, nm, ccag) para el tiempo de interrupción.

  3. Recopile los registros del visor de eventos (sistema y aplicación) exportados en formato de texto, haciendo clic con el botón derecho en la carpeta de registro correspondiente y seleccionando Save As (Guardar como). Seleccione Text (Texto) en el menú desplegable Save As Type (Guardar como tipo).

  4. Recopile los archivos SOD de ambos CallRouter.

  5. Recopile los registros CallTypeHalfHour, TCD y RCD que abarcan desde 2,5 horas antes de que los routers perdieran la sincronización hasta 1 hora después de la recuperación.

    Deben estar en formato delimitado por tabulación e incluir el vaciado de ambos lados de los registradores. Estos registros DEBEN provenir de ambos lados de los registradores.

    Éste es un ejemplo de consulta SQL:

    SELECT * FROM Call_Type_Half_Hour
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the
    out of sync error occurred */
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the
    out of sync error occurred or less
    if run within an hour of the problem happening */
    
    SELECT * FROM Termination_Call_Detail
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the
    out of sync error occurred */
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the
    out of sync error occurred or less
    if run within an hour of the problem happening */
    
    SELECT * FROM Route_Call_Detail
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the
    out of sync error occurred */
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the
    out of sync error occurred or less
    if run within an hour of the problem happening*/
  6. Ejecute la utilidad dumpcfg para las bases de datos de ambos registradores desde antes de la pérdida de sincronización hasta después.

    Consulte Uso de la herramienta de administración dumpcfg para seguimiento de los cambios de configuración ICM (en inglés) para obtener más información.

  7. Utilice ICMDBA para exportar la configuración de ambos registradores.

  8. Exporte toda la rama de registro ICM de ambos lados de los CallRouter.

    HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,Inc.

Solución alternativa

Éstas son las dos soluciones alternativas:

  • Apague y vuelva a encender ambos procesos de CallRouter. Ésta es la manera más segura de solucionar este problema.

  • Vuelva a encender un lado de los CallRouter.

Ambas opciones consiguen que los CallRouter se vuelvan a sincronizar y se ejecuten en sincronía. Esto significa que ambos lados de los CallRouter enrutarán de nuevo las llamadas de la misma manera.

La opción 1 es el método más recomendable y ofrece una mayor posibilidad de que ambos CallRouter enruten correctamente todas las llamadas una vez reiniciados. Sin embargo, si no puede permitirse apagar los dos CallRouter al mismo tiempo, puede utilizar la opción 2 en su lugar.

La opción 2 ofrece las mismas posibilidades de éxito que la 1. La opción 2 hace que los CallRouter se vuelvan a sincronizar y que ambos lados enruten las llamadas de igual manera. Sin embargo, si el CallRouter que no se reinició presenta un estado incorrecto después de la resincronización, los estados de los CallRouter en ambos serán incorrectos. Esto puede hacer que ambos CallRouter, a pesar de estar sincronizados, enruten incorrectamente algunas llamadas. Con la opción 2 las posibilidades de que esto ocurra son ligeramente mayores que con la opción 1.

Nota: Cisco recomienda encarecidamente que se planifique una ventana de mantenimiento para llevar a cabo estas acciones de recuperación, a fin de minimizar el impacto sobre el enrutamiento de llamadas de producción.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 81904