Guía de solución de problemas de IPCC

Introducción

Este documento proporciona información para resolver problemas de IPCC (Internet Protocol Contact Center), centrado en Peripheral Gateway (PG) y Cisco Intelligent Contact Management (ICM). Aunque este documento contiene cierta información sobre problemas comunes con Cisco CallManager y Cisco Global Directory, este documento no intenta describir totalmente estos componentes. En su lugar, este documento se centra en los síntomas y los métodos para identificar el origen de los problemas que ve PG.  Los problemas pueden estar relacionados con el software o con la configuración.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cómo resolver problemas y dar soporte a Cisco ICM PG

Componentes Utilizados

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

• ICM versión 4.6.2 de Cisco

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). If your network is live, make sure that you understand the potential impact of any command.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Síntomas y Acciones de Troubleshooting

Observe los registros de PG para IPCC. Cuando vea errores no especificados en los registros de servidor de Peripheral Interface Manager (PIM), Open Peripheral Controller (OPC) o Computer Telephony Interface (CTI), vaya directamente al registro de JTapi Gateway (GW) para obtener una mejor descripción de texto del problema. La interfaz JTAPI proporciona habitualmente excepciones cuando las cosas van mal en las solicitudes de terceros. Estas excepciones proporcionan solamente descripciones de cadena sin el código de error. Como consecuencia, el servidor PIM/OPC/CTI registra muchos errores como errores no especificados.

Cisco IPCC PIM No se Activa

PIM no Habilitado

Verifique la existencia de un registro de PIM. Si no hay registro de PIM, asegúrese de que el periférico esté habilitado en la configuración de Cisco ICM. A veces, el periférico se añade, pero es necesario habilitarlo.

Seleccione Edit > Peripheral y marque la casilla de verificación Enabled.

PIM se Reinicia

Si el proceso PIM se reinicia, vea el registro PIM el Cisco CallManager PG con la utilidad dumplog. Si el archivo del registro indica un error con OPCHeartbeatTimeout, debe modificar esta configuración del registro. Utilice regedt32 para realizar el cambio.

Modifique OPCHeartbeatTimeout en el registro bajo eagtpim dynamic data a 10. Esta es la trayectoria:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
PIMS\<pim_inst>\EAGENTData\Dynamic

Nota: Esta clave aparece aquí en dos líneas debido a limitaciones de espacio.

PIM en Estado Inactivo en la Ventana de Registro de PIM

Si el proceso PIM está en un estado inactivo, ejecute estas verificaciones:

• Verifique el registro de PIM. Debe ver "Attempt to Activate" al menos una vez por minuto.

• Si PIM no está activo, utilice la utilidad dumplog para verificar el registro de OPC. Ejecute opctest para ver si el proceso OPC recibe la configuración del router.

• Si el proceso OPC no recibe la configuración del router, utilice la utilidad dumplog para ver el registro de pgagent. El proceso pgagent debe tener una trayectoria activa al controlador central. Si pgagent no tiene una trayectoria activa, verifique la conectividad de red y la configuración de DMP en la configuración de PG. En el router, utilice la utilidad dumplog para ver el registro de ccagent. Verifique si el dispositivo PG (ID del sistema DMP) está habilitado como dispositivo en el router.

• Habilite PG en la configuración del router mediante la configuración o en el registro bajo el registro de DMP.

• En una ventana de comandos, utilice el comando tracert para verificar la conectividad de red entre el router y PG.

  Nota: Puede haber una discrepancia entre DNS y DHCP.

• Verifique si la dirección IP para el router está en el archivo de hosts del directorio c:\winnt\system32\drivers\etc.

• Verifique si el ID del controlador lógico configurado en PG > Setup coincide con el ID para el controlador de interfaz lógica PG en Configure > ICM. Asegúrese de que el ID de periférico configurado para el periférico en PG > Setup coincida con el ID para el periférico en Configure > ICM.

• Modifique la configuración de ICM para que coincida con la configuración.

El Proceso JGW No se Activa

Está Instalada una Versión Incorrecta de la Máquina Virtual Java (JVM) de Microsoft

• Vaya a un símbolo del sistema, escriba jview y presione ENTRAR. Aparecerá información sobre la versión de Java instalada:

  Microsoft (R) Command-line Loader for Java version 5.00.3190

• Si no ve esta salida, o si la versión es anterior a la 3190, debe instalar la versión correcta de Microsoft JVM. Ejecute msjavx86.exe. Este archivo se instala en el directorio icr\bin durante la instalación.

La Trayectoria de Clase de Java es Incorrecta

• Desde un símbolo de comandos, vaya al directorio icr\bin, escriba jtapigw y presione INTRO.  Aparece una respuesta similar a esta:

  18:43:17 Fail: Node Manager Required Arguments missing.
  18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164)
  18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs
   (NodeManager.java:27)
  18:43:17 Trace: at MainWorkerThread.mainImplementation
   (MainWorkerThread.java:41)
  18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)

• También puede aparecer este mensaje:

  Java.lang.NoClassDefFoundError: com/cisco/icr/GWThreadGroup

• Si ve el segundo mensaje cuando ejecute jtapigw, verifique la trayectoria de clase de Java.  Utilice el editor de registro para ver el valor Classpath bajo la clave SOFTWARE\Microsoft\Java VM.  Establezca la clave así:

  C:\WINNT\java\classes;.;c:\icr\bin\icrjavalib.zip

Nota: La letra de unidad y el directorio del sistema de Windows pueden ser diferentes y los caracteres después de las clases y antes de c:\icr... son: punto y coma, punto, y punto y coma.

Cliente JTAPI de Cisco no instalado en el PG

• Desde un símbolo de comandos, vaya al directorio icr\bin, escriba jtapigw y presione INTRO.  Aparece una respuesta similar a esta:

  18:43:17 Fail: Node Manager Required Arguments missing.
  18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164)
  18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs (NodeManager.java:27)
  18:43:17 Trace: at MainWorkerThread.mainImplementation (MainWorkerThread.java:41)
  18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)

• En lugar de lo anterior, puede ver este mensaje:

  Java.lang.NoClassDefFoundError

• Si ve algo como el segundo mensaje cuando ejecute jtapigw, verifique que el cliente Cisco JTAPI esté instalado en el PG. Verifique el archivo CiscoJtapiVersion.class bajo c:\winnt\java\lib.

• Si no existe este archivo, puede instalar el archivo en el PG desde Cisco CallManager; http://<nombre de callmanager>/main.asp. Puede encontrar el archivo bajo la pestaña de la aplicación.

El Registro de JTAPI GW se Queja por la Versión de JTAPI Incompatible

• Si instaló solamente el Service Pack JTAPI 4.1 (SP) 4 con cualquier hotfix menor de 50 en Cisco CallManager PG, debe hacer un upgrade.

• Si acaba de ejecutar ICM > Setup para hacer un upgrade de PG, asegúrese de que la fecha/hora del archivo \icr\bin\icrjavalib.zip muestre una fecha actualizada. La fecha debe ser aproximadamente igual que la fecha/la hora del archivo bldXXXXX.version, aproximadamente dentro de un día de diferencia.

Nota: El programa de instalación no puede actualizar este archivo si está en uso cuando ejecuta el programa de instalación. Esta situación puede ocurrir si tiene un navegador de Internet abierto porque el navegador trata el archivo zip como directorio para la trayectoria de la clase si el navegador abre el archivo zip. Para evitar este problema, cierre todas las sesiones del navegador antes de ejecutar Setup.  Si Setup no puede actualizar el archivo, aparece un mensaje con instrucciones para reiniciar el equipo y actualizar los archivos. Debe reiniciar.

JTAPIGW no Puede Conectar con Cisco CallManager

• PIM se comunica con JTapi Gateway (JTAPIGW), y JTAPIGW se comunica con Cisco CallManager. Cuando PIM intenta activarse, PIM le dice a JTAPIGW que inicialice las comunicaciones con Cisco CallManager mediante JTAPI.

• Debe ver mensajes que indican que JTAPIGW ha aceptado una conexión de PIM y entra en contacto con getProvider(), por ejemplo:

  13:16:47 pg2A-jgw1 Trace:Calling getProvider () 172.24.79.128; 
    login=PGUser;passwd=<***edited***>
  13:16:52 pg2A-jgw1 Trace: Returned successfully from getProvider()

  Nota: Este ejemplo aparece en varias líneas debido a limitaciones de espacio.

Si no ve que se devuelva correctamente el seguimiento, puede ver otros errores después de la llamada a getProvider().  El seguimiento a getProvider() muestra los parámetros utilizados para inicializar JTAPI.  El primer parámetro es el nombre del servicio, que es el nombre del host IP o la dirección IP de la máquina de Cisco CallManager.  En este ejemplo, se utiliza la dirección IP.  Si se utiliza un nombre, el PG debe poder resolver el nombre con un archivo de host o DNS.  Asegúrese de que puede hacer ping al nombre o a la dirección.  Si necesita cambiar el nombre del servicio, ejecute de nuevo ICM > Setup y cambie el nombre en el diálogo Edit Peripheral.

El seguimiento de la llamada a getProvider() también muestra el nombre de inicio de sesión utilizado. Observe que el seguimiento no muestra la contraseña. El nombre de inicio de sesión y la contraseña se toman de lo que el administrador ingresa en ICM > Setup. Estos deben coincidir con un usuario y una contraseña válidos configurados en el directorio y administrados en la página Web Preferencias de usuario de Cisco para tener la capacidad de controlar cada uno de los dispositivos del agente y los puntos de ruta. Asegúrese de que el nombre y la contraseña son correctos en ICM > Setup. Configure el usuario en el directorio para tener permiso de controlar solamente los dispositivos del agente y los puntos de ruta válidos.

El Registro de JGW Indica Host Desconocido

El proceso JTAPI GW no puede resolver la dirección de Cisco CallManager. Configure el parámetro de servicio del cuadro de diálogo de PIM en Setup con el nombre de host o la dirección IP de Cisco CallManager. Si la configuración del nombre del host para Cisco CallManager es correcta, asegúrese de que puede hacer ping a Cisco CallManager. Si no, utilice la dirección IP de Cisco CallManager, en vez del nombre de host.

El Registro JGW Indica Contraseña o Usuario No Válidos

JTAPI GW inicia sesión en Global Directory con un nombre de usuario y una contraseña. El nombre de usuario y la contraseña del cuadro de diálogo PIM en Setup deben corresponder con el nombre de usuario y la contraseña configurados en el directorio global en la página Web de administración de Cisco CallManager bajo ccmadmin > User > Global Directory.

Si no existe el usuario, añada un usuario nuevo. Asegúrese de activar la casilla de verificación CTI Enabled en la parte inferior de la página.

Casilla de Verificación CTI No Habilitada en la Página Global Directory User

Una casilla de verificación de la página del usuario del directorio global de Cisco CallManager puede habilitar o inhabilitar los privilegios CTI para un usuario de PIM o IP IVR. Debe activar y actualizar esta casilla de verificación para que PIM/JTAPI GW se active. Esta casilla de verificación garantiza que no puedan conectarse dos dispositivos CTI a Cisco CallManager, lo que puede provocar problemas (el límite predeterminado es 400).

El Servicio Cisco CallManager No Funciona

• En Cisco CallManager versión 3, este servicio se muestra en el control de servicios como "Cisco CallManager". Inicie el servicio.

• El servicio Cisco CallManager está configurado normalmente para reiniciarse si sale anormalmente, pero puede configurar esto en "off" para evitar posibles problemas con la migración de dispositivos en escenarios de failover.

• Verifique el registro de eventos para ver si el servicio Cisco CallManager se reinicia. El sistema se reinicia a veces si el sistema identifica un problema con el uso adecuado de la CPU. El sistema informa de errores o advertencias en el registro de eventos que indican "subproceso de temporizados SDL lento". Con este tipo de error, Cisco CallManager se reinicia. Esta versión de Cisco CallManager se ejecuta con una prioridad normal, de modo que otras aplicaciones que se ejecuten en el sistema pueden interferir con la señal de llamada.

• Cuando la memoria física es menos o el sistema encuentra otros problemas de sincronización, Cisco CallManager puede mostrar un error que indica que no se pudo inicializar después de un tiempo de espera de 10 minutos, y restablecerse. Hay un servicio del componente DCOM para la capa base de datos (DBL) de Cisco CallManager que tiene un problema de inicialización. Detenga e inicie este servicio DBL DCOM mediante servicios de componente - componentes DCOM para solucionar este problema.

  Nota: No es lo mismo que un servicio del sistema como Cisco CallManager.

  Abra un caso en el Centro de Asistencia Técnica de Cisco (TAC). Es probable que esto sea un problema la próxima vez que reinicie el sistema, a menos que resuelva el problema de sincronización subyacente.

Problemas de Directorio (Configuración, No se Ejecuta, Contraseña del Directorio)

El Servicio de Directorio no se Ejecuta

• Confirme que el servicio de directorio está activo y que se ejecuta correctamente.  De forma predeterminada, éste es el Servidor de Directorio DC en el control de servicios de la máquina de Cisco CallManager. Intente iniciar la máquina. Puede que encuentre errores.

• El servicio de directorio puede entrar en un estado de pausa si el sistema se queda sin memoria o espacio en disco. Aparecen errores en el registro de eventos de Microsoft Windows 2000. Resuelva los problemas de recursos y reinicie el servicio de directorio, en caso necesario.

La Página Web de Usuario de Cisco CallManager No Funciona

Verifique si la página Web de usuario de Cisco Global Directory puede ver y configurar realmente los usuarios y asignar permisos a dispositivos de control. Tanto JTAPIGW como la página Web utilizan Cisco CallManager para acceder al servidor de directorio para acceder a usuarios y permisos. Si el problema con JTAPIGW es debido a un problema del servidor de directorio, la página Web de usuario también puede tener problemas. Las razones posibles son que el servidor de directorio no se ejecute o que el directorio no esté configurado correctamente, si es que está configurado.

Servidor de Directorio no Instalado

Para utilizar Cisco CallManager 3.0.5 y posteriores, debe instalar un servidor de directorio. AVVID DC Directory es el predeterminado, disponible en los CDs de instalación de Spirian. Después de instalar el servidor de directorio, la instalación de Cisco CallManager configura el directorio.

Debe realizar esta instalación correctamente, y el servidor de directorio debe estar activo y ejecutarse correctamente para que JTAPIGW inicie sesión en Cisco CallManager y utilice JTAPI.

Asegúrese de que tanto DC Directory Service como Cisco CallManager se ejecuten correctamente.

Cuando instale Cisco CallManager, debe ingresar "ciscocisco" cuando vea la petición de contraseña del administrador del directorio. Si ingresas otra cosa, es posible que tenga que quitar el software DC Directory (añadir/quitar) y reinstalarlo. Si el proceso de eliminación indica que algunos archivos no se pueden quitar, debe quitar o cambiar de nombre manualmente el directorio actual de c:\dcdsrvr.

El Servidor de Directorio está Instalado pero No Funciona

Verifique el panel de control para confirmar que el servicio no puede iniciarse. Después, verifique si el administrador está configurado y si el nombre y la contraseña de inicio de sesión son correctos para el servicio en el campo Propiedades.

El Servidor del Directorio Está Instalado y Funciona, pero No Puede Iniciar Sesión con la Herramienta de Administración DCD

Inicie DC Directory Admin desde el menú Inicio del sistema. Inicie sesión con el administrador de directorio de usuario con la contraseña “ciscocisco” (predeterminada) o con la contraseña que haya configurado el administrador. Si recibe un error que indica que el usuario no está configurado, ejecute uno de los archivos de configuración de Cisco AVVID en el directorio DCDSrvr\bin. Si éste es el CallManager primario de Cisco, Publisher, ejecute avvid_cfg.cmd desde el símbolo del sistema de DOS. Si es un Cisco CallManager secundario, ejecute avvid_scfg.cmd desde el símbolo del sistema de DOS.

Si ve errores que indiquen que esto está ya configurado, el usuario existe. Si no hay errores, las cosas deben comenzar ahora a funcionar correctamente. Vuelva y verifique el acceso desde las páginas Global Directory User en ccmadmin.

Nota: DC Directory entra en el modo de pausa si el directorio tiene pocos recursos del sistema.

El Agente No Puede Iniciar Sesión

Este ejemplo utiliza una configuración ICM de ejemplo para un dispositivo de destino:

Ejemplo de Dispositivo de Destino
Enterprise Name	Agente9782755100
Global Address	Agente9782755100
ConfigParm	/devtype CiscoPhone /dn 9782755100

El siguiente ejemplo utiliza un ejemplo de configuración de ICM para un agente:

Agent Sample
Periférico	CCMPG_PIM1
Peripheral Number	1234
Contraseña	XXX

Cuando ejecute ICM > Setup para el PG, especifique una longitud de extensión del agente de "4". Así pues, en el ejemplo de configuración, la extensión para el dispositivo de ejemplo son los 4 últimos dígitos del parámetro /dn (por ejemplo, "5100").

Intente iniciar sesión con CTITest.

Si no puede abrir una sesión para un agente con el teléfono de software, intente la misma operación con ctitest. Ésta es una lista de ejemplo de comandos de ctitest que puede utilizar para iniciar una sesión para el agente de ejemplo en el dispositivo de destino de ejemplo. Esta lista de comandos asume que el servidor CTI escucha en el puerto 42027 de la máquina CTIServerA. Esta lista también asume que el dispositivo es una extensión para el periférico representado como periférico ICM 5000.

config /hostA CTIServerA
config /portA 42067
config /service CLIENT_EVENTS+CLIENT_CONTROL
agent /periph 5001 /inst 9782755100
open
login 1234 XXX /inst 9782755100

El PIM y el Servidor CTI no Están Activos en OPC

Utilice el comando "status" de opctest y confirme que el PIM IPCC y el servidor CTI se muestran en los estados PIM_ACTIVE y CTI_ACTIVE. Las barras de título de las ventanas de registro del servidor CTI y de PIM también indican el estado del proceso.

El Cliente CTI no Puede Conectar

Verifique las configuraciones para conectar con el servidor CTI. Para el teléfono de software de escritorio, las configuraciones están en el archivo .ini (habitualmente c:\archivos de programa\geotel\cti desktop\cticonfig.ini). Las configuraciones a verificar incluyen:

• PeripheralID : este valor debe corresponder con el ID de periférico para el periférico IPCC en Configure > ICM.

• SideAHost : este valor debe ser el nombre del host IP o la dirección del lado A del servidor CTI.

• SideBHost : este valor debe ser el nombre del host IP o la dirección del lado B del servidor CTI.  Si el servidor CTI es simplexed, puede dejar este campo en blanco.

• SideAPort : este valor debe corresponder al puerto con que el servidor CTI del lado A escucha las conexiones. Este valor se especifica en el configuración de ICM para el servidor CTI. El servidor CTI muestra este puerto en la barra de título y registra este valor cuando se inicia el servidor CTI. Verifique si el cliente puede hacer ping al servidor CTI.

El Cliente CTI Obtiene un Error que Indica que el Agente Necesita Haber Iniciado Sesión en ACD

Ejecute el setup.exe que reside en el directorio \icr\bin del servidor PG/CTI. Seleccione el componente de CTI Gateway. Verifique si la casilla de verificación Agent Login Requiredestá desmarcada. Esta selección de la casilla de verificación no es aplicable a IPCC ni a ninguna aplicación de control de terceros. El propósito de esta casilla de verificación es monitorear las aplicaciones de otros agentes ACD.

El Registro de PIM Muestra Uno de Estos Errores de Login

Utilice procmon para pim y "trace tp*" para activar el seguimiento de terceros (diferencia entre mayúsculas y minúsculas). Esto debe mostrar la solicitud de login. Verifique si los parámetros son correctos. El instrumento se sigue como "Device=". Este valor debe corresponder con la cadena /dn en el configparam del dispositivo de destino. La identificación del agente se sigue como "AgentID=". Este valor debe corresponder con el número de periférico del agente en Configure/ICM.

• INVALID_PASSWORD

  Asegúrese de que la contraseña sea correcta (la contraseña no se puede seguir como texto sencillo). Si la contraseña es incorrecta, el registro debe mostrar un error INVALID_PASSWORD_SPECIFIED.

• INVALID_OBJECT

  Indica que los parámetros de configuración del dispositivo de destino contienen un tipo de dispositivo no válido. Este error aparece así, con espacios entre las palabras clave:

  /devtype CiscoPhone /dn 9782755100

• INVALID_DEVICE_TARGET

  Indica que algo en el dispositivo de destino no es válido, muy probablemente algo en el campo de los parámetros de la configuración. Con la utilidad dumplog, vea en el registro de PIM cuándo fue la última vez que se reinició el PIM. El registro valida los dispositivos de destino y los errores del registro cuando las cadenas de configuración del dispositivo de destino no son válidas.

El Registro de JGW Muestra Errores de Login

Verifique el registro de jgw para ver los errores que ocurran al intentar iniciar sesión. Utilice procmon para PIM y "trace *TP*" para activar el seguimiento de terceros (diferencia entre mayúsculas y minúsculas). Busque la línea, “MsgAddCallObserver: Addr: XXXX" donde XXXX es la extensión donde intenta iniciar sesión. Esta extensión debe ser una extensión válida de Cisco CallManager en un dispositivo que el usuario de PG tenga permiso para controlar. La extensión debe ser el número correcto de dígitos para el teléfono tal como lo conoce Cisco CallManager. Es decir, la extensión debe ser el número que se marca desde otro teléfono del mismo Cisco CallManager para comunicar con el teléfono en cuestión.

El Dispositivo no Está en el Dominio del Proveedor

Si el registro de jgw muestra una excepción, los que indica que el dispositivo no está en el dominio del proveedor, el teléfono no está asociado con el usuario con el que JTAPI GW inicia sesión. Asegúrese de que la extensión en el extremo lejano de la lista de asociación de dispositivos de usuario de Global Directory es correcta. Asegúrese también de que el número de línea del dispositivo no esté registrado dos veces. La aparición de línea compartida es una función de Cisco CallManager que IPCC no soporta. Puede intentar configurar inadvertidamente una apariencia de línea compartida con dos teléfonos que tengan la misma línea. Si cambia un número de línea, el otro cambia y el PG no puede iniciar sesión en el dispositivo correcto. Para resolver este problema, elimine ambas líneas y añádalas a Cisco CallManager.

INVALID_SKILL_GROUP_SPECIFIED

Para iniciar sesión, se debe configurar un agente en Configure/ICM como miembro de al menos un grupo de capacidades (miembro del grupo de capacidades).

El Agente ya Inició Sesión en Otro Teléfono

Asegúrese de que el agente (como lo representa el Número de agente periférico) no está registrado ya en otro dispositivo de destino. Una manera de verificar esto es ejecutar Monitor ICR y ejecutar el informe Free from Agent para el agente en cuestión. Si el agente inició una sesión, esto muestra el identificador de destino de red del dispositivo de destino en el que el agente inició sesión. Los datos del agente aparecen solamente en awdb si se ha configurado ICM para enviar datos de agente para el periférico a este AW.

• También podría consultar esto en isqlw contra la tabla Agent_Real_Time de awdb. Primero, busque la capacidad de destino para el agente (por ejemplo, select * from Agent where PeripheralID = XXX and PeripheralNumber = YYY). Entonces, verifique si el agente inició sesión (por ejemplo, select * from Agent_Real_Time where SkillTargetID = XXX).

• También puede verificar esto cuando conecte a procmon con PIM y ejecute dagent <número de agente periférico>.

El Dispositivo de Destino ya Inició Sesión

Asegúrese de que el dispositivo de destino (como lo especifica el instrumento) no tenga ya otro agente autentificado.

• Una manera de verificar esto es ejecutar isqlw contra la tabla Agent_Real_Time de awdb. Primero, busque el ID de destino de red para el dispositivo de destino en cuestión. Por ejemplo, select * from Device_Target where ConfigParam like ‘%1003%’. Ahora, vea si el dispositivo de destino está autentificado. Por ejemplo, select * from Agent_Real_Time where NetworkTargetID = XXX.

• También puede verificar esto cuando conecte a procmon para PIM y vuelque el dispositivo de destino. Hay dos maneras de volcar el dispositivo de destino. El comando ddt toma un ID de destino de red como entrada y vuelca el dispositivo de destino. El comando deadt toma la cadena /dn de la configuración de destino del dispositivo como entrada y vuelca el dispositivo de destino. Por ejemplo, si la cadena /dn del dispositivo de destino es /dn 9782755100, volcará el dispositivo de destino como deadt 9782755100.

Dispositivo no Asociado con Usuario PG

Vaya a la página Web de Cisco CallManager, seleccione User/Global Directory y busque el userid que utiliza el PG. Verifique el "Associated Devices" y asegúrese de que el usuario tenga permiso para controlar el dispositivo.

• Si no encuentra el dispositivo en la página de usuario (marcado o desmarcado), puede haber un problema con la sincronización entre la base de datos (donde Cisco CallManager guarda los dispositivos) y el servidor de directorio (que guarda los dispositivos y almacena los perfiles de usuario). Verifique si el servidor del directorio (DC Directory Server) se ejecuta.

• Verifique el registro de aplicación del Visor de eventos de Windows NT y busque el directorio DC o el metalink. Si se producen errores de importación, ejecute avvid_recfg desde c:\dcdsrvr\bin.

• Asegúrese de que la Máquina virtual de Java de Microsoft (JVM) esté instalada en la máquina de Cisco CallManager. Para probar esto, escriba jview desde un símbolo de comandos. Para Cisco CallManager 2.4, debe instalar JVM manualmente. Para Cisco CallManager 3, la plataforma es Windows 2000 y la instalación de JVM es automática.

Dispositivo de Teléfono Inactivo

Verifique si el teléfono está prendido, registrado con Cisco CallManager y es capaz de hacer y recibir llamadas del teléfono sin el control del agente.

El agente no puede realizar la llamada

El Agente No Está en Estado Ready

Asegúrese de que el agente esté autentificado y no esté en el estado Available.  Si el agente no está disponible, el agente no puede hacer una llamada. Para hacer una llamada, haga clic primero en Not Ready.

Configuración de Escritorio de Agente Incorrecta

Si hay un error solamente cuando se marcan ciertos números, verifique esos números desde un teléfono físico para asegurarse de que puede marcar correctamente. Si ha configurado un plan de números marcados de ICM, verifique si el número que marca coincide con uno de los comodines del plan de números marcados. A continuación, verifique si la configuración del escritorio del agente permite al agente marcar el tipo de número que la entrada del plan de números marcados identifica (por ejemplo, internacional).

El Plan de Números Marcados de PIM Bloquea el Acceso

El plan de números marcados configurado para cada PIM se puede configurar correcta o incorrectamente para evitar que un agente marque un número determinado. El error en el registro de PIM debe indicar un error de permisos. Los números para los agentes y los dispositivos no se pueden solapar cuando el plan de números marcados se utiliza para hacer llamadas de agente a agente.

El Agente Hace la Llamada Corta, Tiene que Esperar para Hacer una Nueva Llamada

El router hace que el agente no esté disponible cuando el agente hace una llamada o cuando una llamada se rutea al agente. Este mecanismo permite que el router rutee otra llamada al agente antes de que el PIM informe de que ha llegado la llamada. Algunas redes tardan varios segundos en rutear realmente la llamada. El router no cancela el temporizador basándose en el estado del agente.

Si el tiempo real necesario para rutear llamadas al PIM desde el cliente de ruteo es relativamente corto, puede cambiar el tiempo configurable en el router. En uno de los routers de una ventana de comandos de DOS, utilice rtsetting.exe. Busque bajo Extrapolation > Agent. La configuración predeterminada es 10 segundos. Si el valor es demasiado corto, el router rutea las llamadas a los agentes que están a punto de recibir una llamada. Esto hace que el PIM descarte llamadas.

El tiempo de espera predeterminado en el PIM es 7 segundos. Puede modificar este valor con el comando regedt32. Añada la clave "AgentReserveTimout" en esta trayectoria:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\EAGENTData\Dynamic\

Nota: Esta clave se agregará en la configuración de la versión 4.1.5.

Nota: Esta clave aparece aquí en dos líneas debido a limitaciones de espacio.

El número del PIM debe se siempre algunos segundos menos que temporizador de extrapolación del router para evitar que el router envíe los nuevos eventos de prellamada al PIM antes de que se procese el evento original. Esto causa problemas en el PIM.

Si la llamada llega después del tiempo de espera del PIM, la llamada se considera una llamada no ACD, y no se asigna ninguna de las variables de contexto, servicio ni información de grupo de capacidades a la llamada.

El agente no puede ir: no preparado, ocupado u otro

Agente en estado "Activo"

Si el agente está en una llamada y hace clic en Not Ready, Busy u Other, el estado del agente no cambia inmediatamente. Esto es intencionado. El agente permanece en estado Talk o Held hasta que se completa la llamada. El agente pasa a Not Ready, Work Ready o Work Not Ready en función del botón que se presione. Si, una vez que la llamada termina, el agente pasa inmediatamente a Available, debe verificar la configuración de escritorio del agente para ver si se ha establecido Available After Incoming o Available After Outgoing. Estas configuraciones reemplazan las tareas que el agente realiza con los botones durante una llamada.

La Configuración de Escritorio del Agente Impide la Transición

Verifique la configuración de escritorio del agente en Configure ICM y vea si se ha activado Idle Reason Required. Si se marca la casilla de verificación, el agente no puede entrar en el estado Not Ready sin un código de motivo. Modifique Desktop_Settings.cfg para que corresponda con la configuración del escritorio de agente en Configure ICM, o cambie la configuración de escritorio de agente en Configure ICM.

Si no hay configuración de escritorio de agente asignada al agente, el agente puede iniciar sesión y pasar al estado ready, pero no puede pasar a not_ready ni cerrar las sesión. La resolución es cerrar la aplicación agente, asignar una configuración de escritorio de agente e iniciar sesión otra vez.

El Agente Tiene que Esperar para Pasar a Not Ready

El router hace que el agente no esté disponible cuando el agente hace una llamada o cuando una llamada se rutea al agente. Este mecanismo permite que el router rutee otra llamada al agente antes de que el PIM informe de que ha recibido la llamada. Algunas redes tardan varios segundos en rutear realmente la llamada. El router no cancela el temporizador basándose en el estado del agente.

Si el tiempo real necesario para rutear llamadas al PIM desde el cliente de ruteo es relativamente corto, puede cambiar el tiempo configurable en el router. En uno de los routers de una ventana de comandos de DOS, utilice rtsetting.exe. Busque bajo Extrapolation > Agent. El valor predeterminado es 10 segundos. Si el valor es demasiado corto, el router rutea las llamadas a los agentes que están a punto de recibir una llamada. Esto hace que el PIM descarte llamadas.

El agente no puede estar preparado

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

Hay una incoherencia en los datos para la solicitud de login y la solicitud de listo. Posiblemente, el instrumento, la identificación del agente o los números de periférico no coinciden. Active el seguimiento del servidor CTI con procmon y establezca regset en 0xf8 para ver los seguimientos adecuados. También puede ver esto en los registros de OPC o PIM, si está activado el seguimiento de terceros (TP).

El agente no puede cerrar sesión

El Estado Actual del Agente Impide Hacer Llamadas

Si el agente está en estado Work Ready, Work Not Ready o Available, debe pasar primero a Not Ready antes de cerrar la sesión. Modifique Desktop_Settings.cfg para que corresponda con la configuración del escritorio de agente en Configure ICM, o cambie la configuración de escritorio de agente en Configure ICM.

La Configuración de Escritorio de Agente Impide el Cambio de Estado

Si el agente está en estado Not Ready y sigue sin poder cerrar la sesión, verifique la configuración de escritorio de agente en Configure ICM y vea si está activado Logout Reason Required.

El agente muestra una llamada activa o muestra que el agente se encuentra hablando, pero no hay ninguna llamada en el teléfono

Cierre e Inicio de Sesión del Agente

Si el teléfono de software muestra una llamada que ya no está físicamente presente, el estado del agente puede bloquearse en Talking o Hold y el agente no podrá cerrar la sesión. Esto puede ser debido a un bug de software en JTAPI o PIM. Para borrar el estado, intente primero borrar la llamada del teléfono del software si está habilitado el botón de versión. Si esto no funciona, intente cerrar la sesión del agente. Si el botón de cierre de sesión no funciona, salga y reinicie el teléfono de software. Si persiste el estado, salga del teléfono de software, ejecute el Administrador de tareas, termine los procesos geodcs.exe y common~1.exe, y reinicie el teléfono de software. Estos procesos pueden continuar ejecutándose y recordar el estado de agente no válido.

Agente en Estado Incorrecto en PIM

En procmon, marca el estado del agente en el PIM. Si reinicia el escritorio de agente y el estado no se despeja, hay más medidas que puede tomar. El servidor CTI y OPC proporcionan mecanismos para despejar llamadas con la interfaz de debug de procmon u opctest. Esta es una opción levemente preferida a la otra opción, que es terminar e iniciar el servicio PG o al menos cerrar la ventana PIM.

Las Llamadas se Borran Pronto Después de la Alerta o de Establecerse

Configuraciones de Registro Incorrectas

Con regedt32, verifique estas configuraciones del registro:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\
  CurrentVersion\<pim_inst>\CallControl\MaxAlertingTimeAllowedForCall

y

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\
  CurrentVersion\<pim_inst>\CallControl\MaxConnectedTimeAllowedForCall

Nota: Estas claves del Registro aparecen aquí en dos líneas debido a limitaciones de espacio.

Establezca estos valores en 300 y 28800, respectivamente.

El Ruteo de Puesto no Funciona

Verifique la Ruta y el Script de Ruta

Utilice la herramienta AW Call Tracer para verificar si la llamada llega al script y si el script se ejecuta correctamente. Ejecute Script Editor y monitoree el script. Mire los registros del router, de OPC y de PIM para ver si hay problemas. La mayoría de los errores de ruta se siguen incondicionalmente.

"Use DN Label Map" Activado para el Cliente de Ruteo del Periférico

Hay una configuración para cada cliente de ruteo de Configure ICM etiquetado "Use DN/Label Map". Si esta configuración se establece en "Yes", debe configurar una entrada "Dialed Number Label" para cada combinación de número marcado y etiqueta de destino posible. Esta configuración no es útil en clientes de ruteo de PG y se debe establecer en "No".

Ninguna Etiqueta Configurada para el Dispositivo de Destino Ruteado

Verifique la etiqueta configurada en el cliente de ruteo. Debe configurar la etiqueta en cada cliente aunque la etiqueta sea idéntica en cada cliente.

El Punto de Ruta CTI no Está Configurado en Cisco CallManager

Para utilizar el ruteo de puesto debe configurar un "punto de ruta CTI" en Cisco CallManager y asignar una línea al punto de ruta con el número de directorio deseado (por ejemplo, "5000"). Para las llamadas de agente al ruteo de puesto, utilice el plan de números marcados. Un agente que marca al punto de ruta de Cisco CallManager CTI confunde el teléfono de software IPCC en la versión 4.1.9 de CTI Desktop.

El Dispositivo para Puntos de Ruta CTI no Está en la Lista de Dispositivos Controlados por el Usuario PG

Debe añadir el dispositivo de punto de ruta CTI a la lista de "Dispositivos asociados" para el usuario de PG en el la página Web del usuario de Cisco CallManager bajo el directorio global. Si crea un nuevo dispositivo, agregue primero las líneas y, a continuación, agregue el dispositivo a la lista "Dispositivos asociados" del usuario. Si añade más líneas a un dispositivo que ya exista en la lista de dispositivos del usuario, deberá reiniciar JGW para que JGW reconozca las líneas nuevas. Sin embargo, si añade un nuevo dispositivo, añade una línea al dispositivo y, a continuación, añade el dispositivo a la lista de dispositivos del usuario, JGW debe poder reconocer el nuevo dispositivo (en unos 30 segundos).

No Hay Ningún Número Marcado Configurado en Cisco ICM

Verifique el número marcado para asegurarse de que el número esté configurado para el cliente de ruteo periférico. Ejecute procmon para JGW y active el seguimiento como "trace "*ROUTE*" (distingue entre mayúsculas y minúsculas). Verifique el registro JGW para ver si hay errores relativos al número marcado. Al iniciarse, JGW intenta registrar una devolución de llamada de ruta para el número marcado. Cuando se hace una llamada al número marcado, el gateway recibe un "RouteEvent".

Junto con el número marcado, verifique si el tipo de llamada se crea y se asigna correctamente al script.

Verificar que No se Necesita el Reinicio de JGW

Si ha configurado un número marcado ICM, ha configurado el punto de ruta CTI, y lo ha añadido a la lista de dispositivos del usuario pero sigue sin recibir solicitudes de ruta cuando se marca el número, puede que necesitar reiniciar JGW (o apagar y prender el PG). Solamente deberá reiniciar si ha activado el seguimiento en JGW (trace "*ROUTE*") y ve errores que muestran que la dirección no está en el proveedor. Generalmente, JGW debe poder reconocer los nuevos puntos de ruta CTI que se añaden a la lista de dispositivos del usuario sin la necesidad de reiniciar. Además, si se añaden líneas a un punto de ruta CTI que ya exista, el JGW no los reconocerá sin necesidad de reiniciar. Debe poder evitar un reinicio si añade un nuevo punto de ruta cti nuevo para cada número marcado en vez de líneas nuevas a dispositivos que ya existen.

Nota: Se supone que DeviceListPolling está activado en el archivo JTAPI.ini en el directorio winnt\java\lib del PIM. Si DeviceListPolling está desactivado, debe activar DeviceListPolling. Si DeviceListPolling está desactivado y añade cualquier dispositivo a la lista de usuarios, debe apagar y prender el PG o al mejor JTAPI GW para que el PG vea el nuevo dispositivo.

Revisar los Registros de OPC para los Diálogos de Ruta

Utilice opctest para activar el seguimiento de rutas "debug /routing" y verifique los registros de OPC para ver si hay errores cuando se realizan llamadas al punto de ruta. Verifique si se están recibiendo solicitudes de ruta y si se devuelven etiquetas. Las solicitudes de ruta aparecen como mensajes “CSTA_ROUTE_REQUEST” y “ICR_NEW_CALL_REQ”. Las etiquetas devueltas aparecen como mensajes "ICR_CONNECT". Si se producen errores, puede ver mensajes "ICR_DIALOG_FAIL" en vez de mensajes "ICR_CONNECT". En este caso, verifique el registro del router para ver si hay errores.

Verificar los Registros del Router para Ver Diálogos de Ruta

Utilice rtsetting.exe para activar el seguimiento de rutas y verifique los registros del router para ver si hay errores cuando se hacen llamadas al punto de ruta.

Asegúrese de que todas las etiquetas requeridas estén configuradas. Si su script de ruta apunta a agentes IPCC/EA, debe tener etiquetas configuradas para el cliente de ruteo de puestos para cada dispositivo de destino deseado.

La secuencia de comandos de ruteo no saca la llamada de la cola cuando el agente se vuelve disponible

Verifique el registro del router para ver si hay errores. Si no hay ninguno:

No hay ningún error en el registro del router: el nodo de cola está en cola para la prioridad base del grupo de habilidades

Si el nodo de cola está en cola para la prioridad de base, nada sucede cuando el agente queda disponible. Hay dos opciones para solucionar este problema:

• Hay una configuración del registro del router llamada AutoLoginBase (utilice rtsetting.exe). Cambie esta configuración para permitir que la llamada se ponga en cola para el grupo de capacidades de base para funcionar más o menos según lo esperado. No hay preferencia para las capacidades primarias sobre las secundarias cuando se utiliza este tipo de colas.

• La cola a los conjuntos de capacidades primarias y/o secundarias establece explícitamente el nodo de cola.

El Registro del Router Indica que la Etiqueta No Está Configurada para el Destino

Configure la etiqueta para el dispositivo de destino en cuestión y todos los demás destinos a los que pueda rutear este cliente de ruteo. Utilice la herramienta de configuración por lotes AW para hacer esto de manera más eficiente que con Configure ICR.

Se Oye la Llamada sin Respuesta cuando Todos los Agentes y Puertos de la Cola Están Ocupados

Verifique los Registros del Router

• Los errores de ruta se deben seguir incondicionalmente.

• Puede utilizar la herramienta de seguimiento de llamadas para probar la trayectoria de la ruta.

• Utilice rtrtrace para activar el seguimiento de solicitudes de ruta y verificar los registros del router cuando se hagan llamadas al punto de ruta.

• Asegúrese de que todas las etiquetas requeridas estén configuradas. Si el script de ruta apunta a agentes IPCC/EA, debe tener etiquetas configuradas para cada dispositivo de destino deseado. Cada dispositivo de destino debe tener etiquetas configuradas para cada cliente de ruta que intente enviar llamadas. Así pues, si una llamada es prerruteada desde la red directamente a un agente disponible, el cliente de ruteo debe tener una etiqueta para el dispositivo de destino asociado. Si la llamada primero se pone en cola en un VRU y, a continuación, se entrega al agente, el cliente de ruteo VRU debe tener una etiqueta para el dispositivo de destino asociado.

Asegúrese de que el Mapping de Etiqueta DN Esté Desactivado en el Cliente de Ruteo en Configure ICM

Asegúrese de que Use DN/Label no esté activada en la pestaña Routing Client dentro de Configuration Manager/PG Explorer.

Verificar los Registros de PIM

• Utilice procmon para activar el seguimiento en PIM (trace precall, trace *call_event*) y verifique los registros. El mensaje previo a la llamada aparece desde el router. También verá "DeliveredEvent" con "DevTgDevStr" establecida en la extensión del agente. Si la llamada no aparece, asegúrese de que la etiqueta sea correcta para el cliente de ruta.

Las transferencias arbitrarias producen resultados inconsistentes

IPCC no soporta la opción para poner una llamada en espera y hacer una nueva llamada porque Cisco CallManager proporciona resultados incoherentes. Esto se considera una mejora del producto y se puede considerar para una versión futura.

La alternación no funciona

Cuando se conmuta, se alterna, se retiene o se recupera una llamada de consulta, Cisco CallManager rompe la asociación de consulta. Esto da lugar a un escenario de transferencia arbitraria que no se soporta. Los agentes pueden volver a conectar con el cliente e iniciar una nueva consulta. El teléfono de software IPCC inhabilita el botón alterno hasta que se resuelve, pero los proveedores externos pueden quejarse.

La parte que recibe invitación a una conferencia no puede invitar a otra parte a esa misma conferencia

Cisco CallManager tiene como limitación que solamente el iniciador de la conferencia puede añadir más partes a la conferencia. Otras partes no pueden añadir más partes a Cisco CallManager.

La estación agente se desconectó inesperadamente

Temporizador de Inactividad de Configuración de Agent Desk

En las configuraciones del escritorio de agente, hay una configuración de tiempo para el cierre de sesión de los agentes con estado Not Ready. El tiempo máximo de inactividad es 2 horas, pero puede configurar el tiempo para que sea inferior. Los agentes en estado Available no deben cerrar la sesión mientras estén en estado de inactividad. El agente pasa de Ready a Not Ready si caduca el temporizador de llamada sin respuesta (también una configuración de escritorio de agente configurable).

Tiempo de Espera de Latido del Servidor CTI

El servidor CTI tiene un tiempo de espera de latido configurado. Los equipos más antiguos, los servidores CTI con exceso de trabajo o las redes con problemas de ancho de banda pueden ser la raíz del problema. Los registros del servidor CTI deben indicar un error en el registro.

El Agente no se Comporta como está Configurado en la Configuración de Escritorio de Agente

Las configuraciones de escritorio de agente en Configure ICR(M) y el archivo de configuración del agente tienen que acordar cómo se gestiona el agente.

Hay un temporizador de trabajo en la configuración de periféricos en los parámetros de configuración de ICM. Establezca los parámetros como \WORKTIMER 30 para establecer un retardo de 30 segundos en auto-available.

El archivo de configuración del escritorio reside en:

\program files\geotel\cti desktop\Desk_Settings.cfg

El modo de trabajo en Incoming se debe establecer en Required, no en Required with Data en Desk_Settings.cfg y en la configuración de escritorio de agente en Configure ICR(M). Required with Data tiene precedencia sobre la opción auto-available.

Fallo de las Transferencias de Consultas

Observe el registro de JTAPI GW y vea si hay errores que indiquen por qué falla la transferencia de consultas. Verifique si el software agente permite operaciones de retener/recuperar o alternar en la llamada de consulta. Cuando alguna llamada de retiene/recupera, deja de ser considerada una llamada de consulta, sino una transferencia "arbitraria" por Cisco CallManager. Cisco CallManager tiene problemas con las transferencias arbitrarias. Limite al usuario a reconectar o completar la transferencia cuando se encuentre en una llamada de consulta.

La Parte que Consulta Cuelga, pero la Aparición de la Llamada no Desaparece

Cisco CallManager tiene problemas actualmente con un evento de desconexión para una consulta iniciada por conferencia cuando no se completa la transferencia. Desconecte la llamada una segunda vez para borrar la aparición de la llamada en el teléfono del agente.

La ruta de traducción a VRU no funciona

Primero, monitoree el script activo. A continuación, verifique los registros de router, OPC y PIM del cliente de ruteo y VRU. La mayoría de los errores se siguen incondicionalmente, pero puede activar el seguimiento para obtener una mejor imagen de qué sucede.

Ésta es la secuencia de ruta de traducción:

• El cliente de ruteo hace una nueva solicitud de llamada al router.

• El router devuelve una conexión al cliente de ruteo con una etiqueta que debe entregar la llamada al IVR.

• El IVR debe entonces enviar una RequestInstruction que el VRU PG utiliza para buscar el periférico de destino.

• El router empareja los periféricos de destino de la instrucción de solicitud con los periféricos de destino de las rutas de traducción en las que espera.

• El script de ruteo continúa con el script de ejecución o los nodos de cola según lo designado por el cliente.

Monitoree el script activo para buscar la trayectoria de falla. Busque errores en el seguimiento del router. Verifique si el cliente de ruta recibe las etiquetas iniciales. Verifique si el VRU recibe la llamada. Verifique si el VRU envía una instrucción de solicitud en el nivel de PIM VRO u OPC.

La Solicitud de Ruta no Llega a "Translation Route to VRU Node" en el script de ruta

Monitoree el script y verifique si la solicitud llega a la ruta de traducción al nodo VRU.

Primero, en el script de la ruta, un nodo de selección o de selección de ruta con una ruta de traducción seleccionada no es bastante para traducir la ruta al servicio VRU controlado. Se requiere una ruta de traducción al nodo VRU.

En segundo lugar, el monitor debe mostrar que la llamada llega al nodo de la ruta de traducción. Una falla aquí significa que una ruta de traducción no puede ser determinada o que el mensaje de la solicitud de ruta RequestInstruction no fue recibido del IVR.

Tiempos de espera de ruta de traducción en el registro del router

El error de tiempo de espera de la ruta de traducción indica que el router no recibe la instrucción de solicitud. Verifique el OPC y el PIM VRU para ver si hay errores y ver si llega la RequestInstruction.

Active el "ruteo de traducción" y el "seguimiento VRU de red" con la herramienta rtrtrace en el router para obtener una indicación mejor de lo que ocurre en el router. En el OPC del VRU PG, active los informes de control de servicio con opctest.

El registro del PIM VRU indica que no se encontró el DNIS en el grupo troncal X

La instrucción de solicitud debe indicar un grupo de trunk válido que se asigne a un número de periférico de grupo de trunk en uno de los grupos de trunk configurados para el PG VRU. Apague y prenda el PG VRU para recibir la actualización del número del periférico del grupo de trunk tronco, si se modificó.

Verifique la configuración de ICM

Asegúrese de que el mapping de etiqueta DN esté apagado en el cliente de ruteo del PG IVR. El PG IVR PG necesita una asignación de VRU de red. La VRU de red debe ser de tipo 2. El PG IVR debe tener un grupo de enlaces de red y un grupo de enlaces asignados. Haga referencia al grupo de trunk de red en el grupo de trunk.

El PG de ruteo de NIC/postpuesto debe tener una etiqueta para cada uno de los DNIS en los periféricos de destino. (Haga las etiquetas iguales que los DNIS para la solicitud para el cliente de ruteo en el asistente de ruta de traducción. Puede configurar esto en el prefijo, seleccione la opción prefix = DNIS.)

El cliente de ruteo VRU necesita una etiqueta configurada para el dispositivo de destino al cual rutea cuando un agente está disponible.

Resolver problemas de Cisco IP IVR: Interfaz ICM

La sección Cisco IP IVR trata cómo resolver errores de configuración entre IP IVR e ICM, e incluye problemas comunes con la configuración para el ruteo de puesto de IVR PG y el ruteo de traducción. Refiérase a la Guía de Troubleshooting de Cisco IP IVR para obtener más información sobre los errores de IVR en general.

En general, verifique los registros de MIVR bajo la página web appadmin > Engine > Trace files.

• Puertos IVR CTI y puntos de ruta CTI configurados en Cisco CallManager, IVR e ICM.

• Los puertos IVR CTI y los puntos de ruta CTI se asocian al usuario IVR en el directorio global de Cisco CallManager.

• La casilla de verificación Service Control está marcada en la configuración de IVR ICM.

• Los nombres de script en las definiciones de script IVR coinciden con los nombres de script VRU de ICM.

• El número de grupo de trunk en VRU PG coincide con el número de grupo de puertos CTI en IP IVR.

Falla la traducción de ruta

Junto con todas las demás acciones que utilice para resolver problemas, puede probar también estas cosas para ayudar a resolver problemas de IP IVR.

• Verifique el registro de MIVR. Este registro puede apuntar generalmente a áreas problemáticas.

• Las configuraciones del debug para activar en Cisco IP IVR son SS_TEL y LIB_ICM.

• Active el registro del Cisco Jtapi para IP IVR con jtprefs en IP IVR. Vea Herramientas de Debug. Detenga e inicie el motor de IP IVR después de activar el seguimiento.

• Verifique si el número del grupo de puertos CTI en el grupo de puertos de ruta de traducción IP IVR JTAPI coincide con el número de periférico en la configuración del grupo de trunk en ICM.

La secuencia de comandos no reproduce o reproduce mensaje de error

Verifique los registros de IP IVR bajo los archivos de seguimiento de motor para verificar si:

• Se recibe el script de ejecución.

• IP IVR encuentra el script. Cargue scripts con la herramienta de administración del depósito.

• IP IVR encuentra la indicación. Las indicaciones definidas por el usuario residen en \wfavvid\prompts\ user\en_us\ en IP IVR.

El estado de JTAPI indica servicio parcial

Esto significa generalmente que algunos de los puertos CTI o de los puntos de ruta CTI configurados en IP IVR no se han configurado o asociado con el usuario de IP IVR en Cisco CallManager.

Esto puede también significar que los scripts no se han nombrado correctamente o no se han cargado en Repository Manager.

El estado de ICM en IP IVR muestra el estado parcial

Generalmente, este estado indica una configuración parcial o una configuración no coincidente en un lado u otro.

Se Oye un Mensaje Entrecortado cuando se Quita una Llamada de la Cola del Router

Esto es un script de ruteo mal configurado que deja un tiempo de espera demasiado corto en la configuración de script VRU en Configure ICR.

Algunos de los scripts disponibles con IP IVR para la interfaz ICM funcionan durante mucho tiempo, pero el tiempo de espera predeterminado en la configuración de script de red de ICM es de tres minutos. Si el script agota el tiempo de espera y la trayectoria de la falla del script de ejecución reproduce otro script de ejecución, estos scripts de ejecución se ponen básicamente en cola en el IVR. Cuando los scripts salgan de la cola, oirá muchos scripts reproduciéndose unos sobre otros.

Resolver Problemas de Estadísticas del Servicio IVR

Las estadísticas IVR son importantes para los informes del nivel de servicio IPCC. Por lo tanto, aquí se incluye alguna información sobre cómo resolver problemas. En general, los cambios en el router y en el PG VRU donde las llamadas implementadas en el VRU se cuentan como en cola, en vez de conectadas. Cuando las llamadas se rutean, se indican como respondidas. Cuando el cliente en cola desconecta las llamadas, se indican como abandonadas. refiérase al readme.txt de los hot fixes 53 y 54 para ver detalles adicionales. El router envía eventos de cola especiales que indican en qué estado está la llamada en el router.

Hay un registro especial configurado en el PIM VRU, así que debe activar voluntariamente esta función para asegurar que las interrupciones sean mínimas.

Enterprise Service Real Time Report 10 hace un uso especial de estos datos cuando agrega los servicios VRU y los servicios Cisco CallManager PG a uno o más informes de periféricos empresariales. Enterprise Service Real Time Report requiere que los servicios VRU PG y Cisco CallManager PG estén agrupados en un servicio de empresa para propósitos de informe.

Otros informes útiles de la cola son los nuevos informes de tipo de llamada para registros históricos y en tiempo real, y la cuadrícula en tiempo real de grupos de capacidades muestra ahora las llamadas en cola frente al grupo de capacidades.

No se Generan Estadísticas de Servicio ni Registros de Detalle de Llamadas de Terminación

El PIM VRU no genera eventos CSTA. Active Service Control Reporting en la configuración de VRU PG. Esto está en la clave de registro de ServiceControlQueueReporting bajo:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\VRUData\Config

Nota: Esta clave del Registro aparece aquí en dos líneas debido a limitaciones de espacio.

VRU Indica Todas las Llamadas como Conectadas, No en Cola como se Requiere

La Clave de Registro ServiceControlQueueReporting no Existe o No Está Establecida en 1

El registro de inicio para PIM VRU debe quejarse si no existe.

Añada la clave ServiceControlQueueReporting y establezca el valor en 1 en:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\VRUData\Config

Nota: Esta clave aparece aquí en dos líneas debido a limitaciones de espacio.

Las Llamadas se Cuentan como Servicio Incorrecto o No Aparecen en los Informes de Servicio

El Registro de OPC Indica que No se Encontró el Mapping de Servicio

El registro de OPC indica que el mapping de servicio no se encuentra cuando se cuentan las llamadas para un servicio incorrecto o no aparecen en los informes del servicio.

Problemas de Informe de Cisco ICM

Cisco ICM no se diseñó para una correlación fácil de las tablas de datos de tipo de llamada, servicio y grupo de capacidades. Los números tienen generalmente significados ligeramente diferentes en cada grupo. Hay solamente un servicio para una llamada, pero puede haber dos grupos de capacidades si hay más de un agente implicado. La función de redirección si no hay respuesta (RONA) genera probablemente otra ruta de puesto sin la generación de otro registro de terminación.

Los Números de Grupo de Capacidades de Agente, Grupo de Capacidades y Tipo de Llamada no se Equilibran

• Síntoma: Las llamadas gestionadas u otros campos de la estadística no coinciden entre los informes de servicio, tipo de llamada y/o grupo de capacidades.

• Condición: El tipo de llamada, el servicio y los grupos de capacidades se configuran con mapa lógico entre sí, pero los informes continúan sin coincidir exactamente.

• Troubleshoot: si el volumen de llamadas es menor de 1 llamada por segundo, active la configuración de seguimiento en OPC, PIM y JTAPI GW, según lo adecuado para CSTA, PIM AGENT y los eventos de terceros. Refiérase a la sección herramientas de este documento para ver instrucciones.

• Documente el flujo de llamadas:

  • ¿Está la ruta de puesto inicial en el Cisco CallManager PG o el VRU PG?

  • ¿Está configurado el reenvío si no ha respuesta (FONA) y dónde está configurada la redirección de FONA?

  • ¿Hay un grupo de capacidades predeterminado configurado con el número de periférico 0 para separar las llamadas ruteadas hacia fuera de las no ruteadas y las entrantes?

Tome los datos históricos de los estas tablas para un día con las instrucciones "select *":

• Peripheral_Half_Hour

• Call_Type_Half_Hour

• Service_Half_Hour

• Skill_Group_Half_Hour

• Termination_Call_Detail

• Route_Call_Detail

Resolver Problemas de Cisco CallManager

Cuando recopile los seguimientos en Cisco CallManager, puede activar los indicadores desde la página de administración de Cisco CallManager bajo Services > Trace Flags. 0xCB05 es un buen indicador de seguimiento configurado para el seguimiento de SDL de los errores de CTI. Establezca 0xCB05 bajo parámetros de servicio para propósitos de debug. Refiérase a Casos TAC AVVID: Recopilación de Información de Troubleshooting para obtener más información. Refiérase a la documentación en línea de Cisco CallManager, incluyendo las guías de troubleshooting.

Activar el Seguimiento para Cisco CallManager

Refiérase a Configuración de Seguimientos de Cisco CallManager para el Soporte Técnico de Cisco para obtener información sobre cómo activar el seguimiento para Cisco CallManager.

Cambiar Direcciones IP de Cisco CallManager

Refiérase a Cambio de las Direcciones IP de Cisco CallManager y cambie el nombre del servidor.

1. Ejecute la Configuración en Cisco CallManager PG y cambie los servicios JTAPI para el PIM de Cisco CallManager. Si tiene movilidad de extensión, y/o servicios telefónicos.

2. Detenga el Motor CRA.

3. En CRA: cambie la dirección IP bajo Engine Configuration.

4. Cambie la IP bajo JTAPI.

5. Detenga el servicio DC Directory en el servidor.

6. Cambie la dirección IP en la configuración del directorio.

7. En Cisco CallManager: cambie la dirección IP bajo System > Server.

8. Cambie la dirección IP en las URL bajo System > Enterprise Parameters.

9. Cambie la dirección IP en todas las URL bajo Features > Phone Services.

10. Cambie Server IP Address : propiedades de red.

11. Cambie DHCP Option 150 a una nueva dirección IP.

12. Cambie la IP del perfil del hotel en DC Directory, Cisco CallManager > System Profile > Hoteling.

13. Abrir SQL Enterprise Manager.

14. Cambie las direcciones IP en las URL de la tabla PlugIn.

Para hacer una copia de seguridad de los cambios de configuración:

1. Abra stiBackup configuration.

2. Cambie las direcciones IP bajo todas las pestañas adecuadas.

Herramientas de depuración

Procmon

Procmon es una herramienta de la línea de comando que puede utilizar para hacer el debug de los procesos de PIM y JTAPI GW.

• Uso: Proceso procmon <nombre del cliente> <nodo>.

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcc cg1a ctisvr

Estas son algunas configuraciones útiles de seguimiento para cada uno de los procesos:

• JTAPI GW (utilizar procmon)

  • trace JT_TPREQUESTS (activa los seguimientos de solicitud de terceros)

  • trace JT_JTAPI_EVENT_USED (activa los seguimientos para los eventos JTAPI que utiliza el PG)

  • trace JT_PIM_EVENT (activa los seguimientos para los mensajes de evento enviados al PIM)

  • trace JT_ROUTE_MESSAGE (activa los seguimientos de cliente de ruteo)

  • trace JT_LOW* (seguimientos basados en las capas JTAPI y CTI subyacentes)

• PIM (utilizar procmon)

  • trace tp* (activa los seguimientos de solicitud de terceros)

  • trace precall (activa los seguimientos de eventos de prellamada)

  • trace *event (activa los seguimientos de eventos de agente y llamada)

  • trace csta* (activa los seguimientos de eventos de llamada CSTA)

• CTI SERVER (utilizarprocmon)

  • regset EMSTraceMask 0xf8 (activa seguimientos de servidor CTI útiles, fáciles de envolver)

OPCtest

Opctest es una herramienta de la línea de comandos para depurar el proceso OPC en el PG.

• Uso: opctest /cust <nombre de cliente> /node <nodo>

  • opctest /cust ipcc /node pg1a

• Configuraciones útiles

  • debug /agent (activa los seguimientos de eventos de agente)

  • debug /routing (activa los seguimientos de eventos de ruteo)

  • debug /cstacer (activa los seguimientos de eventos csta)

  • debug /tpmsg (activa los seguimientos de solicitud de llamadas de terceros)

rttest

Rttest es una herramienta de la interfaz de la línea de comandos para hacer el debug del proceso del router en el ICM. Vea rtrtrace para la versión de GUI.

• Uso: rttest /cust ipcc

rtsetting.exe

Herramienta GUI para cambiar la configuración del registro del router.

• Hay una opción para establecer de nuevo las configuraciones predeterminadas.

rtrtrace.exe

Herramienta GUI para activar en varios seguimientos de router en el ICM.

• Configuraciones especialmente útiles para IPCC son:

  • Queuing : para problemas para quitar de la cola.

  • Service Control : para problemas con la interfaz de VRU.

  • Translation Routing : para problemas con rutas de traducción.

dumplog

Vuelca archivos binarios de Cisco ICM en archivos de texto. Cambie los directorios al directorio logfiles del proceso.

• Los archivos de registro de proceso de OPC, PIM y JtapiGW residen en icr\<nombre de cliente>\<nodo>\logfiles\.

• En el PG, hay un archivo por lotes llamado cdlog donde debe escribir >cdlog <cliente> <nodo>.

• Uso: dumplog nombre de proceso

  • Dumplog/” (para obtener ayuda sobre diferentes opciones de dumplog)

  • Dumplog jgw1

  • Dumplog pim1

  • Dumplog opc

vrutrace

Herramienta para ver el archivo de captura de VRU PG. Funciona de manera similar a dumplog.

Rastreador de llamadas

Herramienta de Cisco ICM que puede utilizar para hacer el debug de scripts de ruteo.  Puede encontrar esta herramienta en el elemento de menú AW de AW.

jtprefs

Esta es una herramienta para activar seguimientos JTAPI para el cliente JTAPI en el IP IVR. Los seguimientos de JTAPI en el IPCC PG se controlan con la interfaz procmon. Esta herramienta reside en archivos de programa\CiscoJtapiTools \.

Supervisor de rendimiento

Herramienta administrativa de Microsoft Windows 2000 que muestra datos en tiempo real para Cisco CallManager, Cisco IP IVR e ICM. Puede ver las llamadas en curso, los dispositivos registrados y la utilización de la CPU del proceso. Puede encontrar esta herramienta bajo Inicio > Programas > Herramientas administrativas.

Archivos del registro

Archivos de Registro de Cisco ICM

Los archivos de registro de Cisco ICM residen en \icr\<cliente>\<nodo>\logfiles. Aquí, cliente se refiere al nombre de la instancia del cliente y las referencias de nodo pg1a, ra para el router, cg1a y más. Utilice dumplog para ver los archivos de registro.

Nota: Puede ver los archivos de captura de eventos con herramientas de seguimiento como vrutrace. Estos archivos están en un directorio distinto.

Archivos de Registro de Cisco CallManager

Los archivos de registro de Cisco CallManager residen normalmente en \archivos de programa\cisco\ccm\trace con los directorios de seguimiento en:

• Ccm: registros SDI de CallManager.

• Dbl: registros de la capa de base de datos.

• Sdl: registros de señalización de llamadas.

• Tftp: registros para el servidor tftp.

Puede modificar la configuración de seguimiento para estos archivos desde la página de administración de Cisco CallManager bajo trace settings. Puede modificar la configuración de seguimiento SDL bajo service parameters en Cisco CallManager.

Archivos de Registro de IP IVR

Los archivos de registro de IP IVR residen en \archivos de programa\wfavvid. También puede ver los archivos de registro de IPIVR desde la página appadmin bajo engine-trace files.

Puede ver los registros de Cisco JTAPI Client activando los eventos de JTAPI con jtprefs.exe y reiniciando el motor de IP IVR.

Datos del perfil útiles

Cuando recopile datos para abrir casos, recopile los datos enumerados en esta sección, además de los archivos de registro.

Cantidad de agentes

¿Cuál es el número de agentes configurados?

Puertas de enlace utilizadas

¿Cuántos gateways hay configurados?

Versiones de software de los componentes

Cisco CallManager, JTAPI Client, ICM, versión de Gateway IOS e IP IVR.

• Puede encontrar la versión de Cisco CallManager en la página de administración de Cisco CallManager bajo Help > About > Details.

• Para encontrar la versión de JTAPI Client, escriba simplemente jview CiscoJtapiVersion en un prompt de comando en el directorio \winnt\java\lib en Cisco CallManager PG.

• También puede encontrar la versión de IP IVR.

‘Tipo IVR’

¿Qué tipo de IVR está en uso?

Plataformas

¿Qué tipos de plataformas están en uso/CPU/y cantidad de memoria física.

Información Relacionada

• Uso de consola de monitor de proceso remoto (Procmon)
• Cómo usar la utilidad Dumplog
• Utilización de la Utilidad de la Línea de Comandos OPCTest
• La utilidad rttest ICM de Cisco
• Activar rastreo
• Lectura de un Archivo de Registro de drwtsn32
• Casos TAC AVVID: Recopilación de Información de Troubleshooting
• Cambio de Direcciones IP de Cisco CallManager
• Soporte Técnico y Documentación - Cisco Systems