Guide de dépannage IPCC

Introduction

Ce document fournit des renseignements pour dépanner l’Internet Protocol Contact Center (IPCC), qui se concentre sur la passerelle d’accès aux périphériques (PG) et Cisco Intelligent Contact Management (ICM). Bien que ce document contienne quelques renseignements sur les problèmes courants avec Cisco CallManager et le répertoire global de Cisco, il n’a pas vocation à décrire complètement ces composants. En revanche, ce document se concentre sur les symptômes et les méthodes permettant d’identifier la source des problèmes observés par la passerelle d’accès aux périphériques.  Les problèmes peuvent être liés au logiciel ou à la configuration.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Comment dépanner et prendre en charge la PAGE missile aux performances améliorées de Cisco

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Version 4.6.2 missile aux performances améliorées de Cisco

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Symptômes et actions de dépannage

Regardez les logs de PAGE pour IPCC. Quand vous voyez des erreurs non spécifiées des journaux du serveur dans le gestionnaire d'interface périphérique (PIM), le contrôleur périphérique ouvert (OPC), ou de couplage de la téléphonie et de l'informatique interface (CTI), allez directement au log de la passerelle de JTapi (gw) pour une meilleure description du problème. L'interface JTAPI fournit habituellement des exceptions quand les choses vont mal sur de tiers demandes. Ces exceptions fournissent seulement des descriptions de chaîne sans code d'erreur. En conséquence, les journaux du serveur PIM/OPC/CTI beaucoup d'erreurs en tant qu'erreurs non spécifiées.

Cisco IPCC PIM ne disparaît pas l'Active

PIM non activé

Vérifiez l'existence d'un log PIM. S'il n'y a aucun log PIM, le contrôle pour s'assurer le périphérique est activé dans l'installation missile aux performances améliorées de Cisco. Parfois, le périphérique est ajouté, mais vous devez activer le périphérique.

Choisi éditez > périphérique, et cochez la case activée.

Reprises PIM

Si les process restarts PIM, visualisent le login PIM la PAGE de Cisco CallManager avec Si le fichier journal indique une erreur avec l'OPCHeartbeatTimeout, vous devez modifier ces paramètres de registre. Utilisation regedt32 d'apporter la modification.

Modifiez OPCHeartbeatTimeout dans le registre sous des données dynamiques d'eagtpim à 10. Voici le chemin :

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

Remarque: Cette clé apparaît plus de deux lignes ici dues aux limites de l'espace.

PIM dans l'état inactif dans la fenêtre de log PIM

Si le processus PIM est dans un état inactif, exécutez ces contrôles :

• Vérifiez le log PIM. Vous devez voir, « tenter de lancer », au moins une fois une minute.

• Si le PIM n'est pas en activité, employez l'utilitaire Dumplog pour vérifier le log OPC. Exécutez-vous opctest pour voir si le processus OPC reçoit la configuration du routeur.

• Si le processus OPC ne reçoit pas la configuration du routeur, employez l'utilitaire Dumplog pour visualiser le log pgagent. Le processus pgagent doit avoir un chemin actif à l'unité centrale de traitement. Si pgagent n'a pas un chemin actif, vérifie la connexion réseau et la configuration DMP dans la mise en page. Sur le routeur, employez l'utilitaire Dumplog pour visualiser le log ccagent. Vérifiez si le périphérique de PAGE (ID système DMP) est activé comme périphérique sur le routeur.

• Activez la PAGE en configuration de routeur par l'installation ou dans le registre sous le registre DMP.

• Dans une fenêtre de commandes, utilisez la commande tracert de vérifier la connexion réseau entre le routeur et la PAGE.

  Remarque: Il peut y a une anomalie entre les DN et le DHCP.

• Vérifiez si l'adresse IP pour le routeur est dans le fichier hôte dans le répertoire de c:\winnt\system32\drivers\etc.

• Vérifiez si l'ID logique de contrôleur configuré en PAGE > installé apparie l'ID pour le contrôleur d'interface logique de PAGE configurent dedans > missile aux performances améliorées. Assurez-vous que l'ID périphérique configuré pour le périphérique en PAGE > installé apparie l'ID pour le périphérique configurent dedans > missile aux performances améliorées.

• Modifiez le missile aux performances améliorées installé pour apparier la configuration.

Le processus JGW ne disparaît pas l'Active

La version incorrecte de Java Virtual Machine de Microsoft (JVM) est installée

• Allez à une invite de commande et tapez le jview et l'appuyez sur ENTRENT. Les informations sur la version Java installée apparaissent :

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

• Si vous ne voyez pas cette sortie, ou si la version est plus tôt que 3190, vous devez installer la bonne version de Microsoft JVM. Exécutez msjavx86.exe. Ce fichier est installé dans le répertoire d'icr \ coffre pendant l'installation.

Java Classpath est incorrecte

• D'une invite de commande, allez au répertoire d'icr \ coffre et tapez le jtapigw et l'appuyez sur ENTRENT.  Une réponse semblable à ceci apparaît :

  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)

• Alternativement, ce message apparaît :

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

• Si vous voyez le deuxième message quand vous exécutez le jtapigw, vérifiez votre classpath de Javas.  Employez l'éditeur de registre pour regarder la valeur Classpath sous la clé de LOGICIEL \ VM de Microsoft \ de Javas.  Placez la clé comme ceci :

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

Remarque: L'identificateur de lecteur et le répertoire de système Windows peuvent différer et les caractères après des classes et avant que c:\icr… soient : point-virgule, période, et point-virgule.

Client de Cisco JTAPI non installé à la PAGE

• D'une invite de commande, allez au répertoire d'icr \ coffre, tapez le jtapigw et l'appuyez sur ENTRENT.  Une réponse semblable à ceci apparaît :

  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)

• Au lieu de ce qui précède, vous pouvez voir ce message :

  Java.lang.NoClassDefFoundError

• Si vous voyez quelque chose comme le deuxième message quand vous exécutez le jtapigw, vérifiez le client de Cisco JTAPI est installé à la PAGE. Vérifiez le fichier CiscoJtapiVersion.class sous c:\winnt\java\lib.

• Si ce fichier n'existe pas, vous pouvez installer le fichier à la PAGE du Cisco CallManager ; <callmanager name>/main.asp de http://. Vous pouvez localiser le fichier sous l'onglet d'application.

Le log JTAPI gw se plaint au sujet de la version incompatible JTAPI

• Si vous installiez seulement le pack de services JTAPI 4.1 (fournisseur de services) 4 avec n'importe quel correctif moins de 50 à la PAGE de Cisco CallManager, vous devez améliorer.

• Si vous vous êtes juste exécuté missile aux performances améliorées > installé pour améliorer la PAGE, vérifiez pour s'assurer que le date/heure sur le fichier \ icr \ coffre \ icrjavalib.zip affiche une date mise à jour. La date doit être approximativement identique comme le date/heure sur le fichier, dans environ un jour.

Remarque: L'installation ne peut pas mettre ce dossier à jour si le fichier est en service quand vous exécutez le programme d'installation. Cette situation peut se produire si vous avez un navigateur d'Internet ouvert parce que, le navigateur traite le fichier zip comme répertoire pour le chemin de classe si le navigateur ouvre le zip. Afin d'éviter ce problème, clôturez toutes les sessions du navigateur avant que vous exécutiez le programme d'installation.  Si l'installation ne peut pas mettre le dossier à jour, un message apparaît, et vous instruit redémarrer votre PC afin de mettre les dossiers à jour. Vous devez redémarrer.

JTAPIGW ne peut pas se connecter au Cisco CallManager

• Le PIM communique avec la passerelle JTAPI (JTAPIGW), et le JTAPIGW communique avec le Cisco CallManager. Comme essais PIM pour aller l'active, le PIM indique JTAPIGW initialiser des transmissions avec le Cisco CallManager par JTAPI.

• Vous devez voir les messages qui indiquent que le JTAPIGW a reçu une connexion du PIM et entre en contact avec le getProvider(), par exemple :

  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()

  Remarque: Cet exemple apparaît au-dessus des plusieurs lignes dues aux limites de l'espace.

Si vous ne voyez pas le suivi retourné avec succès, vous pouvez voir d'autres erreurs après l'appel au getProvider().  Le suivi au getProvider() affiche les paramètres utilisés pour initialiser JTAPI.  Le premier paramètre est le nom de service, qui est le nom d'hôte IP ou l'adresse IP de l'ordinateur de Cisco CallManager.  Dans cet exemple, l'adresse IP est utilisée.  Si un nom est utilisé, la PAGE doit pouvoir résoudre le nom par un fichier hôte ou des DN.  Assurez-vous que vous pouvez cingler le nom ou l'adresse.  Si vous devez changer le nom de service, réexécuter le missile aux performances améliorées > a installé et change le nom dans le dialogue de périphérique d'éditer.

Le suivi de l'appel au getProvider() affiche également le nom d'ouverture de connexion utilisé. Notez que le suivi n'affiche pas le mot de passe. Le nom d'ouverture de connexion et le mot de passe sont pris sous de ce que l'administrateur entre missile aux performances améliorées > installé. Ceux-ci doivent apparier un utilisateur valide et un mot de passe configuré dans le répertoire et gérés dans la page Web de préférences d'utilisateur Cisco pour avoir la capacité de contrôler chacun des périphériques et des points d'acheminement d'agent. Vérifiez pour s'assurer que le nom et le mot de passe sont corrects dans missile aux performances améliorées > installé. Configurez l'utilisateur dans le répertoire pour avoir l'autorisation de contrôler seulement les périphériques valides et les points d'acheminement d'agent.

Le log JGW indique l'hôte inconnu

Le processus JTAPI gw ne peut pas résoudre l'adresse du Cisco CallManager. Configurez le paramètre de service dans la boîte de dialogue PIM dans l'installation avec le nom d'hôte ou l'adresse IP de Cisco CallManager. Si la configuration de nom d'hôte pour le Cisco CallManager est correcte, assurez-vous que vous pouvez cingler le Cisco CallManager. Sinon, utilisez l'adresse IP du Cisco CallManager, au lieu du nom d'hôte.

Le log JGW indique le mot de passe incorrect ou l'utilisateur

Le JTAPI gw se connecte dans le répertoire global avec un nom d'utilisateur et mot de passe. Le nom d'utilisateur et mot de passe dans la boîte de dialogue PIM dans l'installation doit apparier le nom d'utilisateur et mot de passe pour l'utilisateur configuré dans le répertoire global en page Web d'admin de Cisco CallManager sous le ccmadmin > l'User > Global Directory.

Si l'utilisateur n'existe pas, ajoutez un nouvel utilisateur. Veillez à cocher la case activée par CTI au bas de page.

Case CTI non activée sur la page utilisateur globale de répertoire

Une case sur la page utilisateur globale de répertoire de Cisco CallManager peut activer ou désactiver les privilèges CTI pour un utilisateur PIM ou IP RVI. Vous devez cocher et mettre à jour cette case afin du PIM/JTAPI gw pour aller l'active. Cette case s'assure que deux périphériques CTI ne peuvent pas se connecter au Cisco CallManager, qui peut poser des problèmes (la limite par défaut est 400).

Le service de Cisco CallManager ne fonctionne pas

• Sur la version 3 de Cisco CallManager, ce service affiche dans le contrôle des services en tant que « Cisco CallManager ». Commencez le service.

• Le service de Cisco CallManager est normalement placé pour redémarrer s'il quitte anormalement, mais vous pouvez configurer ceci à "OFF" pour les questions possibles avec le transfert des périphériques sur des scénarios de Basculement.

• Vérifiez le journal d'événements pour voir si les reprises de service de Cisco CallManager. De système les reprises parfois si le système identifie un problème avec l'utilisation adéquate CPU. Les erreurs ou les avertissements d'états de système se connectent en cas qui indiquent « un thread lent de temporisateur SDL ». Avec ce type d'erreur, reprises de Cisco CallManager. Cette version de Cisco CallManager exécute à la priorité normale de tellement autres applications qu'exécuté sur le système peut gêner le signal d'appel.

• Quand la mémoire physique est moins ou le système rencontre d'autres questions de synchronisation, le Cisco CallManager peut proposer une erreur qui indique qu'elle ne pourrait pas initialiser après une minuterie 10 et une reprise minute. Il y a un service composant DCOM pour la couche de base de données Cisco CallManager (DBL) qui a initialiser de problème. Cessez et commencez ce service du DBL DCOM par des services composants – des composants DCOM pour résoudre ce problème.

  Remarque: Ce n'est pas identique qu'un service système comme le Cisco CallManager.

  Ouvrez une valise avec le centre d'assistance technique Cisco (TAC). Ceci peut être probablement un problème la prochaine fois que vous redémarrez le système, à moins que vous résolviez le problème sous-jacent de synchronisation.

Problèmes de répertoire (configuration, ne pas s'exécuter, mot de passe du répertoire)

Le service d'annuaire ne s'exécute pas

• Confirmez que le service d'annuaire est en hausse et s'exécute correctement.  Par défaut, c'est le serveur de DC Directory dans le contrôle des services sur l'ordinateur de Cisco CallManager. Essayez de mettre en marche l'ordinateur. Vous pouvez rencontrer des erreurs.

• Le service d'annuaire peut entrer dans un état fait une pause si le système manque de mémoire ou d'espace disque. Les erreurs apparaissent dans le journal d'événements de Microsoft Windows 2000. Résolvez les problèmes de ressource et redémarrez le service d'annuaire, s'il y a lieu.

La page d'utilisateur web de Cisco CallManager ne fonctionne pas

Vérifiez si la page Web globale d'utilisateur de répertoire de Cisco peut réellement visualiser et configurer des utilisateurs et assigner des autorisations aux périphériques de contrôle. Les JTAPIGW et la page Web emploient le Cisco CallManager pour accéder au serveur de répertoire pour accéder à des utilisateurs et des autorisations. Si le problème avec JTAPIGW est dû à un problème de serveur de répertoire, la page Web d'utilisateur peut également avoir des problèmes. Les possibles raison sont que le serveur de répertoire ne fonctionne pas ou le répertoire n'est pas configuré correctement, le cas échéant.

Serveur de répertoire non installé

Afin d'utiliser le Cisco CallManager 3.0.5 et plus tard, vous devez installer un serveur de répertoire. Le DC Directory AVVID est le par défaut qui est disponible sur les cdroms d'installation de Spirian. Après que vous installiez le serveur de répertoire, l'installation du Cisco CallManager configure le répertoire.

Vous devez exécuter cette installation correctement, et le serveur de répertoire doit être haut et doit s'exécuter correctement pour que le JTAPIGW se connecte dans le Cisco CallManager et pour utilise JTAPI.

Assurez-vous que le service et le Cisco CallManager de DC Directory les deux passage correctement.

Quand vous installez le Cisco CallManager, vous devez écrire le « ciscocisco » quand vous voyez l'invite du mot de passe de gestionnaire de répertoire. Si vous entrez dans toute autre chose, vous pouvez devoir enlever le logiciel de DC Directory (ajout/suppression) et le réinstaller. Si le procédé de suppression t'indique que quelques fichiers ne peuvent pas être retirés, vous devez manuellement enlever ou renommer le répertoire en cours de c:\dcdsrvr.

Le serveur de répertoire a installé mais ne fonctionne pas

Vérifiez le panneau de configuration pour confirmer que le service ne peut pas commencer. Ensuite, vérifiez si l'administrateur est configuré et la procédure de connexion et le mot de passe sont corrects pour le service dans le domaine de Properties.

Le serveur de répertoire a installé et des passages mais ne peut pas ouvrir une session avec l'outil administrateur DCD

Admin de DC Directory de début de votre menu de démarrage de système. Procédure de connexion avec votre gestionnaire de répertoire d'utilisateur avec le mot de passe « ciscocisco » (par défaut) ou Qu'est ce que mot de passe l'admin a configuré. Si vous recevez une erreur qui indique que l'utilisateur n'est pas configuré, exécutez un des fichiers de configuration de Cisco AVVID dans le répertoire de DCDSrvr \ coffre. Si c'est le Cisco CallManager primaire, Publisher, exécutent avvid_cfg.cmd de l'invite DOS. Si c'est un Cisco CallManager secondaire, exécutez avvid_scfg.cmd de l'invite de commande.

Si vous voyez que des erreurs qui indiquent ceci est déjà configurées, l'utilisateur existe. S'il n'y a aucune erreur, les choses doivent commencer à fonctionner correctement maintenant. Retournez et vérifiez l'accès des pages utilisateur globales de répertoire sur le ccmadmin.

Remarque: Le DC Directory entre dans le mode de pause si le répertoire est bas sur des ressources système.

L'agent ne peut pas ouvrir une session

Cet exemple utilise une configuration missile aux performances améliorées témoin pour une cible de périphérique :

Échantillon de cible de périphérique
Nom d'entreprise	Agent9782755100
Adresse globale	Agent9782755100
ConfigParm	/devtype CiscoPhone /dn 9782755100

L'exemple suivant utilise une configuration missile aux performances améliorées témoin pour un agent :

Échantillon d'agent
Périphérique	CCMPG_PIM1
Nombre périphérique	1234
Mot de passe	XXX

Quand vous vous exécutez missile aux performances améliorées > installé pour la PAGE, vous spécifiez une longueur de poste de l'agent de "4". Ainsi, dans la configuration d'échantillon, l'extension pour le périphérique témoin est les 4 derniers chiffres du paramètre de /dn (par exemple, "5100").

Essayez d'ouvrir une session avec CTITest.

Si vous ne pouvez pas se connecter un agent dedans avec le téléphone logiciel, essayez la même exécution par ctitest. Voici une liste témoin des commandes ctitest que vous pouvez employer pour ouvrir une session l'agent témoin à la cible de périphérique témoin. Cette liste des commandes suppose que le serveur CTI écoute sur le port 42027 sur l'ordinateur CTIServerA. Cette liste suppose également que le périphérique est une extension pour le périphérique représenté comme périphérique 5000 missile aux performances améliorées.

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

PIM et serveur CTI ne sont pas en activité dans l'OPC

Utilisez la commande de « état opctest » et confirmez l'IPCC PIM et l'exposition de serveur CTI dans des états PIM_ACTIVE et CTI_ACTIVE. Les barres de titre des fenêtres de log PIM et de serveur CTI indique également l'état de processus.

Le client CTI ne peut pas se connecter

Vérifiez les configurations pour se connecter au serveur CTI. Pour le téléphone logiciel de bureau, les configurations sont dans le fichier .ini (habituellement appareil de bureau de c:\program files\geotel\cti \ cticonfig.ini). Les configurations à vérifier incluent :

• PeripheralID — Cette valeur doit apparier l'ID périphérique pour le périphérique IPCC configurent dedans > missile aux performances améliorées.

• SideAHost — Cette valeur doit être le nom d'hôte IP ou l'adresse du côté R. de serveur CTI

• SideBHost — Cette valeur doit être nom d'hôte IP ou adresse du côté B. de serveur CTI.  Si le serveur CTI simplexed, vous pouvez laisser ce champ vide.

• SideAPort — Cette valeur doit apparier le port que le serveur CTI du côté A écoute des connexions. Cette valeur est spécifiée dans le missile aux performances améliorées installé pour le serveur CTI. Le serveur CTI affiche ce port dans la barre de titre et se connecte cette valeur quand des débuts de serveur CTI. Vérifiez si le client peut cingler le serveur CTI.

Le client CTI obtient l'erreur indique que l'agent a besoin sont enregistré dans l'ACD

Exécutez le setup.exe qui réside dans \ répertoire d'icr \ coffre sur le serveur PG/CTI. Sélectionnez le composant de passerelle CTI. Vérifiez si l'AgentLogin a exigé la case est décoché. Cette sélection de case s'applique pas applicable pour IPCC ou toutes les tiers applications de contrôle. Le but de cette case est de surveiller des applications d'autres agents ACD.

Le log PIM affiche une des ces erreurs de procédure de connexion

Procmon d'utilisation tp* de pim et au « de suivi » pour activer le tiers suivi (distinguant majuscules et minuscules). Ceci doit afficher la demande de procédure de connexion. Vérifiez si les paramètres sont corrects. L'instrument est tracé en tant que « Device= ». Cette valeur doit apparier la chaîne de /dn dans le configparam de cible de périphérique. L'ID d'agent est tracé en tant que « AgentID= ». Cette valeur doit apparier le nombre de périphérique d'agent dans Configure/ICM.

• INVALID_PASSWORD

  Assurez-vous que le mot de passe est correct (le mot de passe ne peut être tracé en tant que texte clair). Si le mot de passe est incorrect le log doit afficher une erreur INVALID_PASSWORD_SPECIFIED.

• INVALID_OBJECT

  Indique que les paramètres de configuration dans la cible de périphérique contiennent un type de périphérique non valide. Cette erreur apparaît comme ceci avec les espaces entre les mots clé :

  /devtype CiscoPhone /dn 9782755100

• INVALID_DEVICE_TARGET

  Indique que quelque chose dans la cible de périphérique est non valide, très probablement quelque chose dans les paramètres de configuration mettent en place. Avec l'utilitaire Dumplog, visualisez le log PIM pour la dernière fois que le PIM a redémarrée. Le log valide les cibles de périphérique et les erreurs de log quand les chaînes de configuration cible de périphérique sont non valides.

Le log JGW affiche des erreurs de procédure de connexion

Vérifiez le log de jgw pour toutes les erreurs qui se produisent sur des tentatives de procédure de connexion. Procmon d'utilisation au PIM et au « suivi *TP* » pour activer le tiers suivi (distinguant majuscules et minuscules). Recherchez la ligne, « MsgAddCallObserver : Adr :  » où est l'extension dans laquelle vous essayez d'ouvrir une session. Cette extension doit être une extension valide de Cisco CallManager sur un périphérique que l'utilisateur de PAGE a l'autorisation de contrôler. L'extension doit être le nombre correct de chiffres pour le téléphone pendant que le Cisco CallManager sait. En d'autres termes, l'extension doit être le nombre que vous composez d'un autre téléphone sur le même Cisco CallManager pour atteindre le téléphone en question.

Périphérique pas dans le domaine de fournisseur

Si le log de jgw affiche une exception, qui indique que le périphérique n'est pas dans le domaine de fournisseur, le téléphone n'est pas associé avec l'utilisateur avec lequel JTAPI gw ouvre une session. Assurez-vous que l'extension sur le côté lointain de la liste globale d'association de périphérique d'utilisateur de répertoire est correcte. Assurez-vous également que le numéro de ligne de périphérique n'est pas enregistré deux fois. La représentation des lignes partagées est une caractéristique de Cisco CallManager qu'IPCC ne prend en charge pas. Vous pouvez par distraction essayer d'installer une représentation des lignes partagées avec deux téléphones qui ont la même ligne. Si vous changez un numéro de ligne, l'autre change, et la PAGE ne peut pas se connecter dans le périphérique correct. Afin de résoudre ce problème, supprimez les deux lignes et ajoutez-les au Cisco CallManager.

INVALID_SKILL_GROUP_SPECIFIED

Afin d'ouvrir une session, un agent doit être configuré dans Configure/ICM en tant que membre au moins d'un groupe de compétences (membre de groupe de compétences).

Agent déjà ouvert une session à un autre téléphone

Assurez-vous que l'agent (comme nombre de périphérique d'agent représente) n'est pas déjà connecté dans une autre cible de périphérique. Une manière de vérifier ceci est d'exécuter le moniteur ICR et d'exécuter la libération de l'état d'agent pour l'agent en question. Si l'agent est ouvert une session, ceci t'affiche l'ID cible de réseau de la cible de périphérique dans laquelle l'agent est ouvert une session. Les données d'agent apparaissent dans l'awdb seulement si vous avez configuré le missile aux performances améliorées pour envoyer des données d'agent pour le périphérique à cet aw.

• Vous pourriez également questionner pour ceci dans l'isqlw contre la table d'Agent_Real_Time dans l'awdb. D'abord, trouvez la cible de compétences pour l'agent (par exemple, choisi * de l'agent où PeripheralID = XXX et PeripheralNumber = YYY). Puis, contrôle si l'agent est ouvert une session (par exemple, sélectionnez * d'Agent_Real_Time où SkillTargetID = XXX).

• Vous pouvez également vérifier ceci quand vous vous connectez au procmon à PIM et à number> périphérique <agent dagent de passage.

Cible de périphérique déjà ouverte une session

Assurez-vous que la cible de périphérique (comme l'instrument spécifie) n'a pas déjà un autre agent ouvert une session.

• Une manière de vérifier ceci est d'exécuter l'isqlw contre la table d'Agent_Real_Time dans l'awdb. D'abord, trouvez l'ID cible de réseau pour la cible de périphérique en question. Par exemple, sélectionnez * de Device_Target où ConfigParam aiment « %1003% ». Maintenant, voyez si la cible de périphérique est ouverte une session. Par exemple, sélectionnez * d'Agent_Real_Time où NetworkTargetID = XXX.

• Vous pouvez également vérifier ceci quand vous vous connectez au procmon au PIM et videz la cible de périphérique. Il y a deux manières de vider la cible de périphérique. La commande de DDT prend un ID cible de réseau comme entrée et vide la cible de périphérique. La commande de deadt prend la chaîne de /dn de la configuration cible de périphérique comme entrée et vide la cible de périphérique. Par exemple, si la chaîne de /dn de cible de périphérique est /dn 9782755100, vous videz la cible de périphérique comme deadt 9782755100.

Périphérique non associé avec l'utilisateur de PAGE

Allez à la page Web de Cisco CallManager, à l'utilisateur choisi/au répertoire global et trouvez l'ID utilisateur que la PAGE utilise. Vérifiez les « périphériques associés » et assurez-vous que l'utilisateur a l'autorisation de contrôler le périphérique.

• Si vous ne pouvez pas trouver le périphérique sur la page utilisateur (vérifiée ou décoché), il peut y a un problème avec la synchronisation entre la base de données (où le Cisco CallManager enregistre les périphériques) et le serveur de répertoire (qui enregistre les périphériques et enregistre des profils utilisateurs). Vérifiez pour voir si le serveur de répertoire (serveur de DC Directory) fonctionne.

• Vérifiez le journal de l'observateur d'événements de Windows NT et recherchez les erreurs du répertoire ou du metalink C.C. Si les erreurs d'importation se produisent, exécutez l'avvid_recfg de c:\dcdsrvr\bin.

• Assurez-vous que Java Virtual Machine de Microsoft (JVM) est installé sur l'ordinateur de Cisco CallManager. Afin de tester ceci, jview de type d'une invite de commande. Pour le Cisco CallManager 2.4, vous devez installer JVM manuellement. Pour le Cisco CallManager 3, la plate-forme est Windows 2000 et l'installation JVM est automatique.

Appareil téléphonique non actif

Vérifiez si le téléphone est mis sous tension, inscrit au Cisco CallManager, et capable faire et recevoir des appels du téléphone sans contrôle d'agent.

L'agent ne peut pas faire l'appel

Agent dans l'état non prêt

Assurez-vous que l'agent est ouvert une session et pas dans l'état disponible.  Si l'agent n'est pas disponible, l'agent ne peut pas faire un appel. Afin de faire un appel, premier clic non prêt.

Configurations incorrectes de bureau d'agent

S'il y a une erreur seulement quand vous composez certains numéros, vérifiez ces nombres d'un téléphone physique pour s'assurer que vous pouvez se connecter avec succès. Si vous avez configuré un plan de nombre composé par missile aux performances améliorées, vérifiez pour voir si le nombre vous composent les correspondances une des masques dans votre plan composé de nombre. Vérifiez alors pour voir si les configurations de bureau d'agent pour l'agent permettent à l'agent pour composer le type de nombre que l'entrée composée de plan de nombre identifie (par exemple, international).

Plan composé de nombre dans des blocs Access PIM

Le plan composé de nombre configuré pour chaque PIM peut être inexactement configuré ou correctement configuré pour empêcher un agent d'exiger à un certain nombre. L'erreur dans le log PIM doit indiquer une erreur d'autorisation. Les nombres pour des agents et des périphériques ne peuvent pas superposer quand le plan composé de nombre est utilisé pour faire l'agent aux appels de l'agent.

L'agent fait sous peu l'appel, doit attendre de faire le nouvel appel

Le routeur rend l'agent indisponible quand l'agent fait un appel ou quand un appel est conduit à l'agent. Ce mécanisme permet au routeur pour conduire un autre appel à l'agent avant que le PIM signale l'appel soit arrivé. Quelques réseaux prennent plusieurs secondes pour conduire réellement l'appel. Le routeur n'annule pas le temporisateur basé sur l'état de l'agent.

Si le temps réel pris pour conduire des appels au PIM du client de routage est relativement court, vous pouvez changer le temps configurable dans le routeur. Sur un des Routeurs dans une fenêtre de commande DOS, utilisation rtsetting.exe. Regardez sous l'extrapolation > l'agent. La valeur par défaut est de 10 secondes. Si la valeur est trop courte, le routeur conduit des appels aux agents qui sont sur le point de recevoir un appel. Ceci fait relâcher le PIM des appels.

La minuterie par défaut sur le PIM est de 7 secondes. Vous pouvez modifier cette valeur avec la commande regedt32. Ajoutez la clé de « AgentReserveTimout » dans ce chemin :

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

Remarque: Cette clé sera ajoutée dans l'installation de version 4.1.5.

Remarque: Cette clé apparaît plus de deux lignes ici dues aux limites de l'espace.

Le nombre PIM doit toujours être quelques secondes moins que le temporisateur d'extrapolation de routeur pour empêcher le routeur d'envoyer de nouveaux événements de pré-appel au PIM avant que l'événement d'origine soit traité. Ceci pose des problèmes dans le PIM.

Si l'appel arrive après le temps PIM, l'appel est considéré un appel de non-ACD, et rien les variables de contexte, le service, ou les informations de groupe de compétences est assignée à l'appel.

L'agent ne peut pas aller -- Non prêt, occupé, ou autre

Agent dans l'état « actif »

Si l'agent est à un appel et clique sur non prêt, occupé, ou autre, l'état de l'agent ne change pas immédiatement. Ceci est intentionnel. L'agent reste dans l'entretien ou l'état HOLD jusqu'à la fin de l'appel. Les transitions d'agent à ne pas préparer, pour fonctionner prêt, ou pour fonctionner non prêt, selon lequel le bouton est appuyé sur. Si, après que l'appel finisse, les transitions d'agent immédiatement à disponible, vous doivent vérifier les configurations de bureau d'agent pour l'agent et voir si disponible après entrant ou disponible après sortant sont placés. Ces configurations ignorent les tâches que l'agent effectue avec les boutons pendant un appel.

Les configurations de bureau d'agent empêchent la transition

Vérifiez l'agent que les configurations de bureau pour l'agent configurent dedans le missile aux performances améliorées et voyez si la raison de veille exigée est vérifiée. Si la case est cochée, l'agent ne peut pas entrer dans l'état non prêt sans code de raison. Modifiez le Desktop_Settings.cfg pour apparier l'agent que la configuration de bureau configurent dedans le missile aux performances améliorées, ou changez l'agent la configuration de bureau configurent dedans le missile aux performances améliorées.

S'il n'y a aucune configuration de bureau d'agent assignée à l'agent, l'agent peut ouvrir une session et aller prêt, mais l'agent ne peut pas aller not_ready ou déconnexion. La résolution est de clôturer l'application d'agent, d'assigner une configuration de bureau d'agent, et ouvrir une session de nouveau.

L'agent doit attendre d'aller non prêt

Le routeur rend l'agent indisponible quand l'agent fait un appel ou quand un appel est conduit à l'agent. Ce mécanisme permet au routeur pour conduire un autre appel à l'agent avant que le PIM signale l'appel comme reçu. Quelques réseaux prennent plusieurs secondes pour conduire réellement l'appel. Le routeur n'annule pas le temporisateur basé sur l'état de l'agent.

Si le temps réel pris pour conduire des appels au PIM du client d'artère est relativement court, vous pouvez changer le temps configurable dans le routeur. Sur un des Routeurs dans une fenêtre de commande DOS, utilisation rtsetting.exe. Regardez sous l'extrapolation > l'agent. Le par défaut est de 10 secondes. Si la valeur est trop courte, le routeur conduit des appels aux agents qui sont sur le point de recevoir un appel. Ceci fait relâcher le PIM des appels.

L'agent ne peut pas aller prêt

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

Il y a une incohérence dans les données pour la demande de procédure de connexion et la demande prête. Probablement, l'instrument, l'ID d'agent, ou les nombres périphériques ne s'assortissent pas. Activez le suivi de serveur CTI avec le procmon et placez le regset à 0xf8 pour voir les suivis appropriés. Vous pouvez également visualiser ceci dans l'OPC ou le PIM se connecte, si le tiers suivi (TP) est allumé.

L'agent ne peut pas se déconnecter

L'état actuel d'agent empêche faire l'appel

Si l'agent est dans un travail prêt, le travail non prêt, ou l'état disponible, l'agent doit d'abord aller à non prêt avant que l'agent se déconnecte. Modifiez Desktop_Settings.cfg pour apparier l'agent que la configuration de bureau configurent dedans le missile aux performances améliorées, ou changez l'agent la configuration de bureau configurent dedans le missile aux performances améliorées.

Les configurations de bureau d'agent empêche la modification d'état

Si l'agent est dans l'état non prêt et ne peut pas se déconnecter toujours, vérifiez l'agent que les configurations de bureau pour l'agent configurent dedans le missile aux performances améliorées et voyez si la raison de déconnexion exigée est vérifiée.

L'agent n'affiche l'appel actif ou l'agent parlant, mais aucun appel au téléphone

Agent de log et de retour dedans

Si le téléphone logiciel affiche un appel qui n'est plus physiquement présent, l'état de l'agent peut être coincé en parlant ou l'attente et l'agent n'est pas de pouvoir se déconnecter. Ceci peut être dû à une erreur de programmation dans JTAPI ou le PIM. Afin d'effacer la condition, premier essai d'effacer l'appel du téléphone logiciel si la plaquette de déverrouillage est activée. Si ceci ne fonctionne pas, tenter de se déconnecter l'agent. Si le bouton de déconnexion ne fonctionne pas, quitter, et redémarrer le téléphone logiciel. Si la condition persiste, quittez le téléphone logiciel, exécutez le gestionnaire de tâches, exécutez la mise à mort geodcs.exe et common~1.exe, et redémarrez le téléphone logiciel. Ces processus peuvent continuer à exécuter et se souvenir l'état de l'agent non valide.

Agent dans l'état incorrect au PIM

Dans le procmon, vérifiez l'état de l'agent au PIM. Si vous redémarrez l'Agent Desktop et la condition fait pas clair, il y a plus de mesures que vous pouvez prendre. Le serveur CTI et l'OPC fournissent des mécanismes pour effacer des appels avec le debug interface du procmon ou opctest. C'est une option légèrement préférée à l'autre option qui est de faire un cycle le service de PAGE ou au moins la fin la fenêtre PIM.

Les appels effacent peu après alerte ou ont établi

Paramètres de registre incorrects

Avec regedt32, vérifiez ces paramètres de registre :

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

et

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

Remarque: Ces clés de registre apparaissent plus de deux lignes ici dues aux limites de l'espace.

Placez ces valeurs à 300 et à 28800 respectivement.

Le routage de courrier ne fonctionne pas

Vérifiez l'artère et le script d'artère

Utilisez l'outil de Call Tracer aw pour vérifier si l'appel obtient au script et le script fonctionne correctement. Exécutez le Script Editor et surveillez le script. Regardez les logs de routeur, OPC, et PIM pour des problèmes. La plupart des erreurs d'artère sont retrouvées sans réserve.

Client du routage du périphérique vérifié « de carte d'étiquette de DN d'utilisation »

Il y a une configuration pour chaque client de routage configurent dedans le missile aux performances améliorées étiqueté, « carte de l'utilisation DN/Label. » Si cette configuration est placée « oui » vous au besoin de configurer une entrée « d'étiquette composée de nombre » pour chaque combinaison de numéro composé et d'étiquette possible de cible. Cette configuration n'est pas utile sur des clients de routage de PAGE et doit être placée à « non ».

Aucune étiquette configurée pour la cible conduite de périphérique

Vérifiez l'étiquette configurée sur le client de routage. Vous devez configurer l'étiquette sur chaque client même si l'étiquette est identique sur chaque client.

Le point de routage CTI n'est pas configuré sur le Cisco CallManager

Afin d'utiliser le courrier vous conduisant doit configurer un « point de routage CTI » sur le Cisco CallManager et assigner une ligne au point d'acheminement avec le nombre de répertoire désiré (par exemple, "5000"). Pour que les appels de l'agent signalent le routage, utilisez le plan composé de nombre. Un agent composant au point de routage CTI de Cisco CallManager confond le téléphone logiciel IPCC dans la version 4.1.9 d'appareil de bureau CTI.

Le périphérique pour le point de routage CTI n'est pas allumé liste de périphériques contrôlés par l'utilisateur de PAGE

Vous devez ajouter le périphérique de point de routage CTI à la liste de « périphériques associés » pour l'utilisateur de PAGE sur la page Web d'utilisateur de Cisco CallManager sous le répertoire global. Si vous créez un nouveau périphérique, ajoutez les lignes d'abord, et ajoutez ensuite le périphérique à la liste de « périphériques associés » d'utilisateur. Si vous ajoutez plus de lignes à un périphérique qui existe déjà dans la liste de périphériques d'utilisateur, vous devez redémarrer le JGW pour que le JGW identifie les nouvelles lignes. Cependant, si vous ajoutez un nouveau périphérique, ajoutez une ligne au périphérique, et ajoutez alors le périphérique à la liste de périphériques d'utilisateur, le JGW doit pouvoir identifier le nouveau périphérique (dans environ 30 secondes).

Aucun numéro composé configuré sur le missile aux performances améliorées de Cisco

Vérifiez le numéro composé pour s'assurer que le nombre est configuré pour le client périphérique de routage. Exécutez le procmon à JGW et activez le suivi en tant que « suivi *ROUTE* » (distinguant majuscules et minuscules). Log du contrôle JGW pour les erreurs qui concernent le numéro composé. Sur le startup, tentatives JGW de s'inscrire un appel d'artère de retour au numéro composé. Quand un appel est fait au numéro composé, la passerelle reçoit un « RouteEvent ».

Avec le numéro composé, vérifiez si le type d'appel est créé et tracé correctement au script.

Vérifiez cette reprise de JGW n'est pas exigé

Si vous avez configuré un numéro composé par missile aux performances améliorées, ont installé le point de routage CTI, et l'ont ajouté à la liste de périphériques d'utilisateur mais vous ne recevez toujours pas des demandes de route quand le numéro est composé, vous pouvez devoir redémarrer le JGW (ou faire un cycle la PAGE). Vous devez seulement redémarrer si vous avez activé le suivi dans JGW (le suivi *ROUTE*) et vous voyez que les erreurs qui affichent l'adresse n'est pas dans le fournisseur. Généralement, le JGW doit pouvoir identifier les nouveaux points de routage CTI qui sont ajoutés à la liste de périphériques d'utilisateur sans nécessité de redémarrer. En outre, si des lignes sont ajoutées à un point de routage CTI qui existe déjà, le JGW ne les identifie pas sans nécessité de redémarrer. Vous devez pouvoir éviter une reprise si vous ajoutez un nouveau point de routage CTI pour chaque numéro composé au lieu des nouvelles lignes aux périphériques qui existent déjà.

Remarque: Ceci suppose que DeviceListPolling est activé dans le fichier JTAPI.ini dans le répertoire de winnt \ de Javas \ bibliothèque dans le PIM. Si DeviceListPolling est arrêté, vous devez allumer DeviceListPolling. Si DeviceListPolling est arrêté, et vous ajoutez n'importe quel périphérique à la liste des utilisateurs, vous devez faire un cycle la PAGE ou au moins le JTAPI gw pour que la PAGE voie le nouveau périphérique.

Logs OPC de contrôle pour des dialogues d'artère

L'utilisez opctest pour activer le suivi d'artère « mettent au point /routing » et l'OPC de contrôle se connecte pour des erreurs quand des appels sont faits au point d'acheminement. Vérifiez pour voir que des demandes de route sont reçues et des étiquettes sont retournées. Les demandes de route apparaissent en tant que messages « CSTA_ROUTE_REQUEST » et « ICR_NEW_CALL_REQ ». Les étiquettes retournées apparaissent en tant que messages « ICR_CONNECT ». Si les erreurs se produisent, vous pouvez voir des messages « ICR_DIALOGUE_FAIL » au lieu des messages « ICR_CONNECT ». Dans ce cas, vérifiez le journal du routeur pour des erreurs.

Journaux du routeur de contrôle pour des dialogues d'artère

Utilisation rtsetting.exe d'activer le suivi d'artère et de vérifier des journaux du routeur pour des erreurs quand des appels sont faits au point d'acheminement.

Assurez-vous que toutes les étiquettes exigées sont configurées. Si votre script d'artère vise des agents IPCC/EA, vous devez avoir des étiquettes configurées pour le client de routage de courrier pour chaque cible visée de périphérique.

Conduisant le script ne retire pas l'appel de la file d'attente quand l'agent devient disponible

Vérifiez le journal du routeur pour des erreurs. S'il n'y en a aucun :

Aucune erreur dans le journal du routeur -- Le noeud de file d'attente est aligné à la priorité de base de groupe de compétences

Si le noeud de file d'attente s'aligne à la priorité de base, rien ne se produit quand l'agent devient disponible. Il y a l'option deux de réparer cette question :

• Il y a des paramètres de registre de routeur appelés AutoLoginBase (utilisation rtsetting.exe). Changez cette configuration pour permettre l'appel à aligner au groupe de compétences de base pour fonctionner plus ou moins comme prévus. Il n'y a aucune préférence à primaire au-dessus des qualifications secondaires quand ce type de Mise en file d'attente a lieu.

• Alignez ou aux ensembles de compétences primaires et/ou secondaires dans le noeud de file d'attente explicitement.

Le journal du routeur indique l'étiquette non configurée pour la cible

Configurez l'étiquette pour la cible de périphérique en question et toutes autres cibles auxquels ce client de routage peut conduire. Utilisez l'outil de configuration en vrac aw pour que plus de façon efficace fasse ceci plus de configurent ICR.

Pas de réponse de sonnerie entendu quand tous les agents et ports de file d'attente sont occupés

Journaux du routeur de contrôle

• Des erreurs d'artère doivent être retrouvées sans réserve.

• Vous pouvez utiliser l'outil de traceur d'appel pour tester le chemin d'artère.

• Rtrtrace d'utilisation pour activer le suivi de demande de route et pour vérifier des journaux du routeur pour des erreurs quand des appels sont faits au point d'acheminement.

• Assurez-vous que toutes les étiquettes exigées sont configurées. Si le script d'artère vise des agents IPCC/EA, vous devez avoir des étiquettes configurées pour chaque cible visée de périphérique. Chaque cible de périphérique doit avoir des étiquettes configurées pour chaque client d'artère qui essaye d'envoyer des appels. Ainsi, si un appel pré-est conduit du réseau directement à un agent disponible, le client de routage réseau doit avoir une étiquette pour la cible de périphérique associé. Si l'appel est d'abord aligné à un VRU et ensuite fourni à l'agent, le client de routage VRU doit avoir une étiquette pour la cible de périphérique associé.

Assurez-vous que mappage d'étiquette de DN est arrêté dans le client de routage configurent dedans le missile aux performances améliorées

Assurez-vous que la carte de l'utilisation DN/Label n'est pas signée l'onglet de client de routage chez l'explorateur de la configuration Manager/PG.

Logs du contrôle PIM

• Employez le procmon pour activer le suivi dans le PIM (precall de suivi, tracer le *call_event*) et pour vérifier des logs. Le message de pré-appel apparaît du routeur. Vous voyez également que « DeliveredEvent » avec « DevTgDevStr » a placé au poste de l'agent. Si l'appel n'apparaît pas, assurez-vous que l'étiquette est correcte pour le client d'artère.

Les transferts arbitraires obtiennent des résultats contradictoires

IPCC ne prend en charge pas l'option de placer un appel sur l'attente et de faire un nouvel appel parce que le Cisco CallManager fournit des résultats contradictoires. Ceci est considéré une amélioration de produits et peut être considéré pour une version future.

Le remplaçant ne fonctionne pas

Quand un appel de consultation est commuté/alterné/tenu/récupéré, le Cisco CallManager casse l'association de consultation. Ceci a comme conséquence un scénario arbitraire de transfert qui n'est pas pris en charge. Les agents peuvent rebrancher au client et commencer un nouveau pour consulter. Le téléphone logiciel IPCC désactive le bouton alternatif jusqu'à ce qu'il soit résolu, mais les fournisseurs tiers peuvent se plaindre.

L'interlocuteur de Conferenced ne peut pas conférence à un autre interlocuteur

Le Cisco CallManager a une limite que seulement le demandeur de conférence peut ajouter plus d'interlocuteurs à la conférence. D'autres interlocuteurs ne peuvent pas ajouter plus d'interlocuteurs dans le Cisco CallManager.

Station d'agent déconnectée inopinément

Temporisateur d'inactivité de configurations de bureau d'agent

Dans les configurations de bureau d'agent, il y a un paramètre horaire pour se déconnecter des agents dans l'état non prêt. Le temps maximum d'inactivité est de 2 heures mais vous pouvez configurer l'heure d'être moins. Les agents dans l'état disponible ne sont pas sont enregistré alors que dans l'état d'inactivité. Les transitions d'agent de prêt à ne pas préparer si le temporisateur de pas de réponse de sonnerie expire (aussi une configuration configurable de bureau d'agent).

Time Out de pulsation de serveur CTI

Le serveur CTI a un temps configuré de pulsation. Des ordinateurs plus anciens, des serveurs CTI surchargés, ou des réseaux avec des problèmes de bande passante peuvent être la cause principale. Les logs de serveur CTI doivent signaler une erreur dans le log.

L'agent ne se comporte pas comme configuré dans des configurations de bureau d'agent

Les configurations de bureau d'agent configurent dedans ICR (M) et le fichier de configuration chacun des deux d'agent doivent convenir sur la façon dont l'agent est manipulé.

Il y a un temporisateur de travail dans la configuration périphérique sur le missile aux performances améliorées dans les paramètres de configuration. Placez comme de paramètres \ WORKTIMER 30 pour placer un retard 30-second sur automatique-disponible.

Le fichier de configuration de bureau réside dans :

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

Le mode de travail sur entrant doit être placé à requis, à non requis avec des données dans Desk_Settings.cfg et dans le configurer ICR (M) configurations de bureau d'agent. Requis avec des données remplace l'option automatique-disponible.

Consultez l'échouer de transferts

Regardez le log JTAPI gw et voyez s'il y a des erreurs qui indiquent pourquoi le transfert de consultation échoue. Vérifiez si le logiciel agent permet l'attente/la récupère ou les travaux en bascule sur la consultation appellent. Quand l'un ou l'autre d'appel est tenu/récupéré, l'appel n'est plus considéré consultatif, mais un transfert « arbitraire » par le Cisco CallManager. Le Cisco CallManager a des problèmes avec des transferts arbitraires. Limitez l'utilisateur pour rebrancher ou se terminer le transfert quand dans un appel consultatif.

Consultez l'interlocuteur raccroche mais l'affichage des appels ne disparaît pas

Le Cisco CallManager a actuellement des problèmes avec un événement de débranchement pour une conférence initiée pour consulter quand la conférence n'est pas terminée. Déconnectez l'appel une deuxième fois d'effacer l'affichage des appels au téléphone d'agent.

Le routage de traduction à VRU ne fonctionne pas

D'abord, surveillez le script actif. Vérifiez alors les logs de routeur, OPC, et PIM du client de routage et du VRU. La plupart des erreurs sont retrouvées sans réserve, mais vous pouvez tourner le suivi obtenez jusqu'à une meilleure image de ce qui se produit.

Voici l'ordre de routage de traduction :

• Le client de routage fait une nouvelle demande d'appel au routeur.

• Le routeur renvoie un connecter au client de routage à une étiquette qui doit fournir l'appel au RVI.

• Le RVI doit alors envoyer vers le haut d'un RequestInstruction que la PAGE VRU utilise à la consultation la cible périphérique.

• Le routeur apparie les cibles périphériques de l'instruction de demande avec les routages de traduction périphériques la vise attend en fonction.

• Le script de routage continue des Noeuds de script ou de file d'attente de passage comme conçu par le client.

Surveillez le script actif pour trouver le chemin de panne. Regardez le suivi de routeur pour des erreurs. Vérifiez pour voir si le client d'artère reçoit les étiquettes initiales. Vérifiez si le VRU reçoit l'appel. Vérifiez si le VRU envoie vers le haut d'une instruction de demande au niveau VRU PIM ou OPC.

La demande de route n'obtient pas au « routage de traduction au noeud VRU » dans le script d'artère

Surveillez le script et le vérifiez si la demande obtient au routage de traduction au noeud VRU.

D'abord, dans le script d'artère, un noeud choisi choisi ou d'artère avec un routage de traduction sélectionné n'est pas assez pour traduire l'artère au service VRU commandé. Un routage de traduction au noeud VRU est exigé.

En second lieu, le moniteur doit prouver que l'appel obtient au noeud de routage de traduction. Une panne ici signifie qu'un routage de traduction ne peut pas être déterminé ou le message de demande de route de RequestInstruction n'a pas été reçu du RVI.

Sorties de temps de routage de traduction dans le journal du routeur

L'erreur de minuterie de routage de traduction indique que le routeur ne reçoit pas l'instruction de demande. Vérifiez l'OPC et le VRU PIM pour des erreurs et pour voir si le RequestInstruction arrive.

Indiquez le « routage de traduction » et le « suivi de VRU réseau » avec l'outil de rtrtrace sur le routeur pour une meilleure indication de ce qui se produit dans le routeur. Dans l'OPC de PAGE VRU, indiquez l'enregistrement de contrôle des services avec opctest.

Le log VRU PIM indique DNIS non trouvé sur le groupe de joncteur réseau X

L'instruction de demande doit indiquer un groupe de joncteur réseau valide que les cartes à un nombre périphérique de groupe de joncteur réseau dans un des groupes de joncteur réseau ont configuré pour la PAGE VRU. Faites un cycle la PAGE VRU pour recevoir la mise à jour du nombre périphérique de groupe de joncteur réseau, si modifié.

Configuration missile aux performances améliorées de contrôle

Assurez-vous que le mappage d'étiquette de DN est arrêté dans le client de routage de PAGE RVI. La PAGE RVI a besoin d'une affectation de VRU réseau. Le VRU réseau doit être type-2. La PAGE RVI doit avoir un groupe de jonctions réseau et un groupe de joncteur réseau assignés. Mettez en référence le groupe de jonctions réseau dans le groupe de joncteur réseau.

La PAGE DE CHOIX NIC/post doit avoir une étiquette pour chacun du DNIS dans les cibles périphériques. (Faites aux étiquettes les mêmes que le DNIS pour la demande du client de routage dans l'assistant de routage de traduction. Vous pouvez placer ceci dans le préfixe, sélectionnez le préfixe = l'option DNIS.)

Le client de routage VRU a besoin d'une étiquette configurée pour la cible de périphérique à laquelle elle conduit quand un agent devient disponible.

Dépannez l'IP RVI de Cisco - Interface missile aux performances améliorées

Les couvertures de cette de Cisco section IP RVI comment dépanner des erreurs de configuration entre l'IP RVI et missile aux performances améliorées et inclut des problèmes courants avec l'installation pour le routage de courrier de PAGE RVI et le routage de traduction. Référez-vous au guide de dépannage IP RVI de Cisco pour plus d'informations sur des erreurs générales RVI.

Vérifiez généralement les logs MIVR sous la page Web d'appadmin > de fichiers de suivi d'engine >.

• Ports CTI et points de routage CTI RVI configurés dans le Cisco CallManager, le RVI, et le missile aux performances améliorées.

• Des ports CTI et les points de routage CTI RVI sont associés avec l'utilisateur RVI dans le répertoire global de Cisco CallManager.

• La case de contrôle des services est signée configuration missile aux performances améliorées RVI.

• Noms de script dans des noms de script de VRU réseau de correspondance de définitions de script IVR dans le missile aux performances améliorées.

• Le nombre de groupe de joncteur réseau en PAGE VRU apparie le nombre de groupe de port CTI dans IP RVI.

Le routage de traduction échoue

Avec toutes les autres actions que vous utilisez pour dépanner, vous peut également essayer ces choses pour aider à dépanner l'IP RVI.

• Vérifiez le log MIVR. Ce log peut généralement indiquer des zones problématiques.

• L'utilisation mettent au point des configurations pour tourner sur IP RVI de Cisco sont SS_TEL et LIB_ICM.

• Activez le log de Cisco Jtapi pour IP RVI avec des jtprefs sur l'IP RVI. Voir les outils de debug. Engine IP RVI d'arrêt et de début après que vous activiez le suivi.

• Vérifiez si le nombre de groupe de port CTI sur le groupe de port de routage de traduction IP RVI JTAPI apparie le nombre périphérique dans la configuration de groupe de joncteur réseau dans le missile aux performances améliorées.

Le script ne joue pas ou joue le message d'erreur

Vérifiez les logs IP RVI sous des fichiers d'engine-suivi pour vérifier si :

• Exécutez le script est reçu.

• IP RVI peut trouver le script. Scripts de téléchargement avec l'outil administrateur de référentiel.

• IP RVI peut trouver la demande. Les demandes définies par l'utilisateur résident dans \ wfavvid \ demandes \ utilisateur \ en_us \ sur l'IP RVI.

L'état JTAPI affiche le service partiel

Ceci signifie généralement que certains des ports CTI ou des points de routage CTI configurés dans l'IP RVI n'ont pas été configurés et/ou ont été associés avec l'utilisateur IP RVI sur le Cisco CallManager.

Ceci peut également signifier que les scripts ne sont pas nommés correctement ou avoir été téléchargé au gestionnaire de référentiel.

L'état missile aux performances améliorées sur IP RVI affiche l'état partiel

Généralement, cette condition indique une configuration partielle ou la configuration mal adaptée sur un côté ou l'autre.

Bégayez la demande entendue quand un appel est retiré de la file d'attente du routeur

C'est un script de acheminement misconfigured qui permet trop peu de délai d'attente dans la configuration de script de VRU réseau configurent dedans ICR.

Certains des scripts qui sont disponibles avec l'IP RVI pour l'interface missile aux performances améliorées exécutent très un longtemps, mais le délai par défaut sur la configuration de script de réseau missile aux performances améliorées sont de trois minutes. Si les temps de script et le chemin de panne de script de passage lit un autre script de passage, ces scripts de passage obtiennent fondamentalement en attente au RVI. Quand les scripts sont retirés de la file d'attente, vous entendez beaucoup de scripts jouer au-dessus de l'un l'autre.

Dépannez les statistiques de service IVR

Les statistiques RVI sont importantes pour des états de niveau de service IPCC. Par conséquent, quelques informations sur la façon dont dépanner sont incluses ici. Comme aperçu, les changements du routeur et de la PAGE VRU où des appels mis en application dans le VRU sont comptés comme alignés, au lieu de connecté. Quand les appels obtiennent conduit, ils sont signalés comme répondu. Quand le client dans la file d'attente déconnecte des appels, ils sont signalés comme abandonnés. Référez-vous à readme.txt des correctifs 53 et 54 pour des détails supplémentaires. Le routeur envoie en bas des événements de file d'attente spéciale qui indiquent quel état l'appel est dedans au routeur.

Il y a une installation spéciale de registre dans le VRU PIM ainsi vous devez volontairement allumer cette caractéristique afin d'assurer l'interruption minimale.

L'état en temps réel 10 de service d'entreprise fait l'utilisation spéciale de ces données quand vous ajoutez les services VRU et des services de PAGE de Cisco CallManager à l'un ou plusieurs périphérique d'entreprise signale. L'état en temps réel de service d'entreprise exige que la PAGE VRU et des services de la PAGE de Cisco CallManager soient groupées dans un service d'entreprise pour signaler des buts.

D'autres états utiles de file d'attente sont les nouveaux rapports de type d'appel pour les enregistrements en temps réel et historiques, et la grille en temps réel de groupe de compétences affiche maintenant des appels alignés contre le groupe de compétences.

Aucun article mouvement d'appel de statistiques ou d'arrêt de service n'est généré

VRU PIM ne génère pas des événements CSTA. Activez l'enregistrement de contrôle des services dans la mise en page VRU. C'est dans la clé de registre dans ServiceControlQueueReporting dessous :

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

Remarque: Cette clé de registre apparaît plus de deux lignes ici dues aux limites de l'espace.

VRU signale tous les appels comme connecté, non aligné au besoin

Clé de registre de ServiceControlQueueReporting pas dans le pas ou non réglée à 1

Le journal de démarrage pour VRU PIM doit se plaindre s'il n'existe pas.

Ajoutez la clé de ServiceControlQueueReporting et placez la valeur à 1 dans :

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

Remarque: Cette clé apparaît plus de deux lignes ici dues aux limites de l'espace.

Des appels sont comptés contre le service faux ou n'apparaissent pas dans des états de service

Le log OPC indique le service traçant non trouvé

Le log OPC indique que le mappage de service n'est pas trouvé quand des appels sont comptés contre le service faux ou n'apparaissent pas dans des états de service.

Questions d'enregistrement missile aux performances améliorées de Cisco

Le missile aux performances améliorées de Cisco n'est pas conçu pour la corrélation facile des tables de type d'appel de données, de service, et de groupe de compétences. Les nombres ont généralement des significations légèrement différentes dans chaque groupe. Il y a seulement un service pour un appel, mais il peut y avoir deux groupes de compétences si plus d'un agent est impliqué. La réorientation sur la caractéristique du pas de réponse (RONA) génère vraisemblablement une autre artère de courrier sans génération d'un autre enregistrement d'arrêt.

Le groupe de compétence d'un agent, groupe de compétences, service, des nombres de type d'appel n'équilibrent pas

• Symptôme : Les appels traités ou d'autres champs de statistique ne s'assortissent pas entre le service, le type d'appel, et/ou les rapports de groupe de compétences.

• Condition : Le type d'appel, le service, et les groupes de compétences sont installés avec une carte logique entre eux, mais les états toujours ne s'assortissent pas exactement.

• Dépannez : Si le volume d'appels est moins que le 1appel par seconde, activez les configurations de suivi dans l'OPC, le PIM, et le JTAPI gw, comme approprié à CSTA, à PIM, à AGENT, et à tiers événements. Référez-vous à la section d'outils de ce document pour des instructions.

• Documentez l'écoulement d'appel :

  • L'artère initiale de courrier est-elle à la PAGE de Cisco CallManager ou à la PAGE VRU ?

  • En avant sur le pas de réponse (FONA) est configuré et à quoi FONA est-il configuré pour réorienter ?

  • Est-ce qu'groupe de compétences par défaut configuré avec le nombre périphérique 0 pour séparer des appels conduits de non-est conduit et des appels sortants ?

Saisissez les données historiques des ces tables pendant un jour avec « sélectionnent * » des déclarations :

• Peripheral_Half_Hour

• Call_Type_Half_Hour

• Service_Half_Hour

• Skill_Group_Half_Hour

• Termination_Call_Detail

• Route_Call_Detail

Dépannez le Cisco CallManager

Quand vous collectez les suivis dans le Cisco CallManager, vous pouvez tourner les indicateurs de la page d'admin de Cisco CallManager sous des services > des drapeaux de suivi. 0xCB05 est un bon drapeau de suivi installé pour le suivi SDL des erreurs CTI. Placez 0xCB05 sous des paramètres de service pour mettent au point des buts. Référez-vous aux cas AVVID TAC : Collecter le pour en savoir plus de l'information de dépannage. Référez-vous à la documentation en ligne de Cisco CallManager, y compris des guides de dépannage.

Activez le suivi pour le Cisco CallManager

Référez-vous aux suivis de Cisco CallManager d'installation pour le support technique de Cisco pour les informations sur la façon dont activer le suivi pour le Cisco CallManager.

Adresses IP de Cisco CallManager de modification

Référez-vous à changer les adresses IP de Cisco CallManager et changez le nom du serveur.

1. Exécutez le programme d'installation à la PAGE de Cisco CallManager et changez les services JTAPI pour le Cisco CallManager PIM. Si vous avez la mobilité d'extension, et/ou les services de téléphonie.

2. Engine de CRA d'arrêt.

3. Dans CRA - Adresse IP de modification sous la configuration d'engine.

4. IP de modification sous JTAPI.

5. Service de DC Directory d'arrêt sur le serveur.

6. Adresse IP de modification dans la configuration de répertoire.

7. Dans le Cisco CallManager - adresse IP de modification sous le System > Server.

8. Adresse IP de modification dans l'URLs sous le System > Enterprise Parameters.

9. Changez l'adresse IP dans tout l'URLs sous des caractéristiques > des services de téléphonie.

10. Adresse IP du serveur de modification - Propriétés du réseau.

11. Option 150 DHCP de modification à la nouvelle adresse IP.

12. Changez l'IP dans le profil d'hôtel dans le DC Directory, profil de Cisco CallManager > de système > Hoteling.

13. Ouvrez le gestionnaire d'entreprise SQL.

14. Adresses IP de modification dans l'URLs dans la table embrochable.

Afin de sauvegarder vos modifications de configuration :

1. Ouvrez la configuration de stiBackup.

2. Adresses IP de serveur de modification sous tous les onglets appropriés.

Outils de debug

Procmon

Procmon est un outil ligne de commande que vous pouvez utiliser pour mettre au point des processus PIM et JTAPI gw.

• Utilisation : processus de <node> de name> de <customer de procmon.

  • Ipcc pg1a pim1 de Procmon

  • Ipcc pg1a jgw1 de Procmon

  • Ctisvr de l'ipcc cg1a de Procmon

Voici quelques configurations utiles de suivi pour chacun des processus :

• JTAPI gw (procmon d'utilisation)

  • suivi JT_TPREQUESTS (active de tiers suivis de demande)

  • suivi JT_JTAPI_EVENT_USED (active des suivis pour les événements JTAPI les utilisations de PAGE)

  • suivi JT_PIM_EVENT (active des suivis pour des messages d'événement envoyés au PIM)

  • suivi JT_ROUTE_MESSAGE (active des suivis de client de routage)

  • suivi JT_LOW* (suivis basés sur les couches sous-jacentes JTAPI et CTI)

• PIM (procmon d'utilisation)

  • tp* de suivi (active de tiers suivis de demande)

  • precall de suivi (active des suivis d'événement de precall)

  • suivi *event (active des suivis d'événement d'agent et d'appel)

  • csta* de suivi (active des suivis d'événement d'appel CSTA)

• SERVEUR CTI (procmon d'utilisation)

  • regset EMSTraceMask 0xf8 (active les suivis utiles de serveur CTI, probables pour s'envelopper autour)

OPCtest

Opctest est un outil ligne de commande pour mettre au point le processus OPC à la PAGE.

• Utilisation : le <node> de /node de name> de <customer de /cust opctest

  • l'ipcc /node pg1a de /cust opctest

• Configurations utiles

  • mettez au point /agent (active des suivis d'événement d'agent)

  • mettez au point /routing (active des suivis d'événement de routage)

  • mettez au point /cstacer (active des suivis d'événement de csta)

  • mettez au point /tpmsg (active de tiers suivis de demande d'appel)

rttest

Rttest est un outil d'interface de ligne de commande pour mettre au point le processus de routeur sur le missile aux performances améliorées. Voir le rtrtrace pour la version GUI.

• Utilisation : l'ipcc de /cust rttest

rtsetting.exe

Outil GUI pour changer des paramètres de registre de routeur.

• Il y a une option de placer des configurations de nouveau au par défaut.

rtrtrace.exe

L'outil GUI pour activer le divers routeur trace sur le missile aux performances améliorées.

• Les configurations particulièrement utiles pour IPCC sont :

  • Queue – pour des problèmes retirant de la file d'attente.

  • Contrôle des services – pour des problèmes avec l'interface VRU.

  • Routage de traduction – pour des problèmes avec des routages de traduction.

dumplog

Fichiers binaires missile aux performances améliorées de Cisco de vidages mémoire aux fichiers texte. Répertoires de modification au répertoire de processus de fichiers journal.

• L'OPC, les PIM, et les fichiers journal de processus de JtapiGW résident dans l'icr \ <customer_name> \ <node> \ fichiers journal \.

• À la PAGE, il y a un fichier batch appelé le cdlog où vous tapez le <node> de <cust> de >cdlog.

• Utilisation : nom du processus de dumplog

  • Dumplog/ » (pour l'aide en différentes options de dumplog)

  • Dumplog jgw1

  • Dumplog pim1

  • Opc de Dumplog

vrutrace

Un outil pour visualiser le fichier de capture de PAGE VRU. Fonctionne semblable au dumplog.

Call Tracer

Outil missile aux performances améliorées de Cisco que vous pouvez utiliser pour mettre au point des scripts de routage.  Vous pouvez trouver cet outil dans la commande de menu aw sur l'aw.

jtprefs

C'est un outil pour activer des suivis JTAPI pour le client JTAPI sur l'IP RVI. Les suivis JTAPI à la PAGE IPCC sont contrôlés avec l'interface de procmon. Cet outil réside dans des fichiers de programme \ CiscoJtapiTools \.

Moniteur de performances

Un outil d'administration de Microsoft Windows 2000 qui affiche des données en temps réel pour l'IP RVI de Cisco CallManager, de Cisco, et le missile aux performances améliorées. Vous pouvez voir des appels en cours, des périphériques enregistrés, et l'utilisation du processeur de processus. Vous pouvez trouver cet outil sous le Start > Programs > Administrative tools.

Fichiers journal

Fichiers journal missile aux performances améliorées de Cisco

Les fichiers journal missile aux performances améliorées de Cisco résident dans \ icr \ <cust> \ <node> \ fichiers journal. Ici, références client les références pg1a de nom du service du client et de noeud, Ra pour le routeur, cg1a, et plus. Dumplog d'utilisation pour visualiser les fichiers journal.

Remarque: Vous pouvez visualiser des fichiers de capture d'événement avec des outils de suivi tels que le vrutrace. Ces fichiers sont dans un répertoire différent.

Fichiers journal de Cisco CallManager

Les fichiers journal de Cisco CallManager résident normalement dans \ fichiers de programme \ Cisco \ ccm \ suivi avec des répertoires de suivi de :

• Ccm - Logs de SDI de CallManager.

• Dbl - Logs de couche de base de données.

• Sdl - Logs de signalisation d'appel.

• Tftp - Logs pour le serveur de tftp.

Vous pouvez modifier les configurations de suivi pour ces fichiers de la page d'admin de Cisco CallManager sous des configurations de suivi. Vous pouvez modifier des configurations de suivi SDL sous des paramètres de service dans le Cisco CallManager.

Fichiers journal IP RVI

Les fichiers journal IP RVI résident dans \ fichiers de programme \ wfavvid. Vous pouvez également visualiser des fichiers journal IPIVR de la page d'appadmin sous des fichiers d'engine-suivi.

Vous pouvez visualiser des logs de client de Cisco JTAPI quand vous activez des événements JTAPI avec jtprefs.exe et redémarrez l'engine IP RVI.

Données utiles de profil

Quand vous collectez des données pour ouvrir des valises, collectez les données répertoriées dans cette section, en plus des fichiers journal.

Nombre d'agents

Quel est le nombre d'agents configurés ?

Passerelles utilisées

Combien de passerelles sont configurées ?

Versions de logiciel des composants

Cisco CallManager, client JTAPI, missile aux performances améliorées, version IOS de passerelle, et IP RVI.

• Vous pouvez trouver la version de Cisco CallManager sur la page Web d'admin de Cisco CallManager sous l'aide > environ > des détails.

• Afin de trouver la version du client JTAPI, simplement jview CiscoJtapiVersion de type dans une invite de commande le répertoire \ winnt \ à Javas \ bibliothèque à la PAGE de Cisco CallManager.

• Vous pouvez également trouver la version IP RVI.

Type RVI

Quel type de RVI est en service ?

Plateformes

Quels types de Plateformes sont en service/CPU/et quantité de mémoire physique.

Informations connexes

• Utilisation de la console du moniteur de traitement à distance (Procmon)
• Comment utiliser l'outil Dumplog
• Utilisation de l'utilitaire de ligne de commande OPCTest
• L'utilitaire rttest de Cisco ICM
• Indiquer le suivi
• Lecture d'un fichier journal Drwtsn32
• Cas du TAC AVVID : Collecte des informations de dépannage
• Changer les adresses IP de Cisco CallManager
• Support et documentation techniques - Cisco Systems