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

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Dépannage et prise en charge de Cisco ICM PG

Composants utilisés

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

• Cisco ICM version 4.6.2

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

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

Consultez les journaux PG pour IPCC. Lorsque vous voyez des erreurs non spécifiées dans les journaux PIM (Peripheral Interface Manager), OPC (Open Peripheral Controller) ou CTI (Computer Telephony Interface) Server, accédez directement au journal GW (JTapi Gateway) pour obtenir une meilleure description du problème. L'interface JTAPI fournit généralement des exceptions lorsque des problèmes surviennent sur des requêtes tierces. Ces exceptions fournissent uniquement des descriptions de chaîne sans code d'erreur. Par conséquent, le serveur PIM/OPC/CTI consigne de nombreuses erreurs comme des erreurs non spécifiées.

Cisco IPCC PIM ne devient pas actif

PIM non activé

Vérifiez l'existence d'un journal PIM. S'il n'y a pas de journal PIM, vérifiez que le périphérique est activé dans le programme d'installation de Cisco ICM. Parfois, le périphérique est ajouté, mais vous devez l'activer.

Sélectionnez Edit > Peripheral, et cochez la case Enabled.

Redémarrages PIM

Si le processus PIM redémarre, affichez le journal PIM sur Cisco CallManager PG avec l'utilitaire dumplog. Si le fichier journal indique une erreur avec OPCHeartbeatTimeout, vous devez modifier ce paramètre du Registre. Utilisez regedt32 pour effectuer la modification.

Modifiez OPCHeartbeatTimeout dans le Registre sous les données dynamiques eagtpim sur 10. Voici le chemin :

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

Remarque : cette touche apparaît sur deux lignes en raison des limites d'espace.

PIM inactif dans la fenêtre du journal PIM

Si le processus PIM est dans un état inactif, exécutez ces vérifications :

• Vérifiez le journal PIM. Vous devez voir "Tentative d'activation", au moins une fois par minute.

• Si le PIM n'est pas actif, utilisez l'utilitaire dumplog pour vérifier le journal OPC. Exécutez 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, utilisez l'utilitaire dumplog pour afficher le journal pgagent. Le processus pgagent doit avoir un chemin actif vers le contrôleur central. Si pgagent n'a pas de chemin actif, vérifiez la connectivité réseau et la configuration DMP dans la configuration PG. Sur le routeur, utilisez l'utilitaire dumplog pour afficher le journal ccagent. Vérifiez si le périphérique PG (ID système DMP) est activé comme périphérique sur le routeur.

• Activez la PG dans la configuration du routeur via la configuration ou dans le registre sous le registre DMP.

• Dans une fenêtre de commande, utilisez la commande tracert pour vérifier la connectivité réseau entre le routeur et la passerelle.

  Remarque : il peut y avoir une différence entre DNS et DHCP.

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

• Vérifiez si l'ID de contrôleur logique configuré dans PG > Setup correspond à l'ID du contrôleur d'interface logique PG dans Configure > ICM. Assurez-vous que l'ID de périphérique configuré pour le périphérique dans PG > Setup correspond à l'ID du périphérique dans Configure > ICM.

• Modifiez la configuration d'ICM pour la faire correspondre à la configuration.

Le processus JGW ne devient pas actif

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

• Accédez à une invite de commandes et tapez jview et appuyez sur ENTRÉE. Des informations sur la version de 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 antérieure à 3190, vous devez installer la version correcte de Microsoft JVM. Exécutez msjavx86.exe. Ce fichier est installé dans le répertoire icr\bin pendant l'installation.

Le chemin de classe Java est incorrect

• À partir d'une invite de commandes, accédez au répertoire icr\bin et tapez jtapigw et appuyez sur ENTRÉE.  Une réponse similaire à celle-ci 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)

• Le message suivant apparaît également :

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

• Si le deuxième message s'affiche lorsque vous exécutez jtapigw, vérifiez votre chemin d'accès aux classes Java.  Utilisez l'éditeur de registre pour rechercher la valeur Classpath sous la clé de machine virtuelle SOFTWARE\Microsoft\Java.  Définissez la clé comme suit :

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

Remarque : la lettre de lecteur et le répertoire système Windows peuvent être différents et les caractères après les classes et avant c:\icr... sont : point-virgule, point et point-virgule.

Client Cisco JTAPI non installé sur PG

• À partir d'une invite de commandes, accédez au répertoire icr\bin, tapez jtapigw et appuyez sur ENTRÉE.  Une réponse similaire à celle-ci 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 jtapigw, vérifiez que le client Cisco JTAPI est installé sur la PG. Recherchez le fichier CiscoJtapiVersion.class sous c:\winnt\java\lib.

• Si ce fichier n'existe pas, vous pouvez l'installer sur le PG à partir de Cisco CallManager ; http://<nom de callmanager>/main.asp. Vous pouvez localiser le fichier sous l'onglet Application.

JTAPI GW Log se plaint d'une version JTAPI incompatible

• Si vous avez installé uniquement le Service Pack (SP) 4 JTAPI 4.1 avec un correctif inférieur à 50 sur la passerelle Cisco CallManager PG, vous devez effectuer une mise à niveau.

• Si vous venez d'exécuter ICM > Setup pour mettre à niveau la PG, vérifiez que la date/heure du fichier \icr\bin\icrjavalib.zip indique une date de mise à jour. La date doit être à peu près identique à la date/heure du fichier bldXXXXX.version, dans un délai d'une journée environ.

Remarque : le programme d'installation ne peut pas mettre à jour ce fichier s'il est en cours d'utilisation lorsque vous exécutez le programme d'installation. Cette situation peut se produire si vous avez un navigateur Internet ouvert, car, le navigateur traite le fichier zip comme un répertoire pour le chemin de classe si le navigateur ouvre le fichier zip. Pour éviter ce problème, fermez toutes les sessions du navigateur avant d'exécuter le programme d'installation.  Si le programme d'installation ne parvient pas à mettre à jour le fichier, un message s'affiche et vous demande de redémarrer votre ordinateur afin de mettre à jour les fichiers. Vous devez redémarrer.

JTAPIGW ne peut pas se connecter à Cisco CallManager

• Le PIM communique avec la passerelle JTAPI (JTAPIGW) et le JTAPIGW communique avec Cisco CallManager. Lorsque le PIM tente de devenir actif, il demande à JTAPIGW d'initialiser les communications avec Cisco CallManager via JTAPI.

• Vous devez voir des messages qui indiquent que le JTAPIGW a accepté une connexion du PIM et contacte 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 s'affiche sur plusieurs lignes en raison des limites d'espace.

Si vous ne voyez pas que la trace a été retournée avec succès, vous pouvez voir d'autres erreurs après l'appel à getProvider().  La trace de getProvider() affiche les paramètres utilisés pour initialiser JTAPI.  Le premier paramètre est le nom du service, qui est le nom d'hôte IP ou l'adresse IP de la machine Cisco CallManager.  Dans cet exemple, l'adresse IP est utilisée.  Si un nom est utilisé, la PG doit être en mesure de résoudre le nom via un fichier hôte ou DNS.  Assurez-vous que vous pouvez envoyer une requête ping au nom ou à l'adresse.  Si vous devez modifier le nom du service, réexécutez ICM > Setup et modifiez le nom dans la boîte de dialogue Edit Peripheral.

La trace de l'appel à getProvider() indique également le nom de connexion utilisé. Notez que la trace n'indique pas le mot de passe. Le nom de connexion et le mot de passe proviennent de ce que l'administrateur entre sous ICM > Setup. Ils doivent correspondre à un utilisateur et un mot de passe valides configurés dans l'annuaire et administrés dans la page Web Préférences utilisateur Cisco pour pouvoir contrôler chacun des périphériques et points de routage de l'agent. Vérifiez que le nom et le mot de passe sont corrects dans ICM > Setup. Configurez l'utilisateur dans l'annuaire pour qu'il soit autorisé à contrôler uniquement les périphériques et points de routage de l'agent valides.

Le journal JGW indique un hôte inconnu

Le processus JTAPI GW ne peut pas résoudre l'adresse de Cisco CallManager. Configurez le paramètre de service dans la boîte de dialogue PIM du programme d'installation avec le nom d'hôte ou l'adresse IP de Cisco CallManager. Si la configuration du nom d'hôte pour Cisco CallManager est correcte, assurez-vous que vous pouvez envoyer une requête ping à Cisco CallManager. Si ce n'est pas le cas, utilisez l'adresse IP de Cisco CallManager au lieu du nom d'hôte.

Le journal JGW indique un mot de passe ou un utilisateur non valide

La passerelle JTAPI se connecte au répertoire global avec un nom d'utilisateur et un mot de passe. Le nom d'utilisateur et le mot de passe dans la boîte de dialogue PIM du programme d'installation doivent correspondre au nom d'utilisateur et au mot de passe de l'utilisateur configuré dans le répertoire global de la page Web d'administration de Cisco CallManager sous ccmadmin > User > Global Directory.

Si l'utilisateur n'existe pas, ajoutez un nouvel utilisateur. Assurez-vous de cocher la case CTI Enabled au bas de la page.

Case à cocher CTI non activée sur la page Utilisateur du répertoire global

Une case à cocher de la page d'utilisateur du répertoire global de Cisco CallManager peut activer ou désactiver les privilèges CTI pour un utilisateur PIM ou IP IVR. Vous devez cocher et mettre à jour cette case pour que la passerelle PIM/JTAPI soit active. Cette case à cocher garantit que deux périphériques CTI ne peuvent pas se connecter à Cisco CallManager, ce qui peut entraîner des problèmes (la limite par défaut est 400).

Le service Cisco CallManager ne fonctionne pas

• Sur Cisco CallManager version 3, ce service s'affiche dans le contrôle de service sous la forme « Cisco CallManager ». Démarrez le service.

• Le service Cisco CallManager est normalement configuré pour redémarrer s'il s'arrête de façon anormale, mais vous pouvez le configurer pour qu'il soit désactivé pour d'éventuels problèmes de migration des périphériques dans des scénarios de basculement.

• Consultez le journal des événements pour voir si le service Cisco CallManager redémarre. Le système redémarre parfois si le système identifie un problème avec une utilisation adéquate du processeur. Le système signale des erreurs ou des avertissements dans le journal des événements qui indiquent un « thread de minuteur SDL lent ». Avec ce type d'erreur, Cisco CallManager redémarre. Cette version de Cisco CallManager s'exécute en priorité normale afin que les autres applications qui s'exécutent sur le système puissent interférer avec le signal d'appel.

• Lorsque la mémoire physique est inférieure ou que le système rencontre d'autres problèmes de synchronisation, Cisco CallManager peut générer une erreur indiquant qu'il n'a pas pu s'initialiser après un délai d'attente de 10 minutes et redémarrer. Un service de composant DCOM pour la couche de base de données (DBL) de Cisco CallManager rencontre un problème d'initialisation. Arrêtez et démarrez ce service DBL DCOM via les composants Services - DCOM pour résoudre ce problème.

  Remarque : il ne s'agit pas d'un service système comme Cisco CallManager.

  Ouvrez un dossier auprès du Centre d'assistance technique de Cisco (TAC). Cela peut probablement être un problème lors du prochain redémarrage du système, à moins que vous ne résolviez le problème de synchronisation sous-jacent.

Problèmes de répertoire (configuration, non en cours, mot de passe de répertoire)

Le service d'annuaire ne fonctionne pas

• Vérifiez que le service d'annuaire est actif et qu'il fonctionne correctement.  Par défaut, il s'agit du serveur d'annuaire DC dans le contrôle de service sur la machine Cisco CallManager. Essayez de démarrer la machine. Vous pouvez rencontrer des erreurs.

• Le service d'annuaire peut passer en état d'interruption si le système manque de mémoire ou d'espace disque. Les erreurs apparaissent dans le journal des événements de Microsoft Windows 2000. Résolvez les problèmes de ressources et redémarrez le service d'annuaire, si nécessaire.

La page utilisateur Web de Cisco CallManager ne fonctionne pas

Vérifiez si la page Web utilisateur de Cisco Global Directory peut réellement afficher et configurer les utilisateurs et attribuer des autorisations pour contrôler les périphériques. JTAPIGW et la page Web utilisent Cisco CallManager pour accéder au serveur d'annuaire afin d'accéder aux utilisateurs et aux autorisations. Si le problème avec JTAPIGW est dû à un problème de serveur d'annuaire, la page Web de l'utilisateur peut également avoir des problèmes. Les raisons possibles sont que le serveur d'annuaire ne s'exécute pas ou que l'annuaire n'est pas configuré correctement, le cas échéant.

Serveur d'annuaire non installé

Pour utiliser Cisco CallManager 3.0.5 et versions ultérieures, vous devez installer un serveur d'annuaire. Le répertoire DC AVVID est le répertoire par défaut disponible sur les CD d'installation Spirian. Après avoir installé le serveur d'annuaire, l'installation de Cisco CallManager configure l'annuaire.

Vous devez effectuer cette installation correctement, et le serveur d'annuaire doit être actif et fonctionner correctement pour que JTAPIGW se connecte à Cisco CallManager et utilise JTAPI.

Assurez-vous que le service d'annuaire DC et Cisco CallManager s'exécutent correctement.

Lorsque vous installez Cisco CallManager, vous devez entrer « ciscocisco » lorsque l'invite du mot de passe du gestionnaire de répertoire s'affiche. Si vous entrez autre chose, vous devrez peut-être supprimer le logiciel de répertoire DC (Ajout/Suppression) et le réinstaller. Si le processus de suppression vous indique que certains fichiers ne peuvent pas être supprimés, vous devez supprimer ou renommer manuellement le répertoire c:\dcdsrvr actuel.

Serveur d'annuaire installé mais ne s'exécute pas

Vérifiez dans le Panneau de configuration que le service ne peut pas démarrer. Vérifiez ensuite si l'administrateur est configuré et si la connexion et le mot de passe sont corrects pour le service dans le champ Propriétés.

Le serveur d'annuaire est installé et fonctionne mais ne peut pas se connecter avec l'outil DCD Admin

Démarrez DC Directory Admin à partir du menu Démarrer de votre système. Connectez-vous avec votre gestionnaire d'annuaire d'utilisateurs avec le mot de passe "ciscocisco" (par défaut) ou tout autre mot de passe que l'administrateur a configuré. Si vous recevez une erreur indiquant que l'utilisateur n'est pas configuré, exécutez l'un des fichiers de configuration Cisco AVVID dans le répertoire DCDSrvr\bin. S'il s'agit du principal Cisco CallManager, Publisher, exécutez avvid_cfg.cmd à partir de l'invite DOS. S'il s'agit d'un Cisco CallManager secondaire, exécutez avvid_scfg.cmd à partir de l'invite de commandes.

Si vous voyez des erreurs indiquant que ce paramètre est déjà configuré, l'utilisateur n'existe pas. S'il n'y a pas d'erreurs, les choses doivent commencer à fonctionner correctement maintenant. Revenez en arrière et vérifiez l'accès à partir des pages Utilisateur du répertoire global sur ccmadmin.

Remarque : le répertoire DC passe en mode pause si les ressources système du répertoire sont insuffisantes.

L'agent ne peut pas se connecter

Cet exemple utilise un exemple de configuration ICM pour une cible de périphérique :

Exemple de cible de périphérique
Nom d'entreprise	Agent9782755100
Adresse globale	Agent9782755100
ConfigParm	/devtype TéléphoneCisco /dn 9782755100

L'exemple suivant utilise un exemple de configuration ICM pour un agent :

Échantillon D'Agent
Périphérique	CCMPG_PIM1
Numéro de périphérique	1234
Mot de passe	XXX

Lorsque vous exécutez ICM > Setup pour la PG, vous spécifiez une longueur de poste d'agent de "4". Ainsi, dans l'exemple de configuration, l'extension du périphérique échantillon correspond aux 4 derniers chiffres du paramètre /dn (par exemple, « 5100 »).

Essayez de vous connecter avec CTITest.

Si vous ne pouvez pas connecter un agent avec le téléphone logiciel, essayez la même opération via ctitest . Voici un exemple de commandes ctitest que vous pouvez utiliser pour vous connecter à l'exemple d'agent à la cible du périphérique exemple. Cette liste de commandes suppose que le serveur CTI écoute le port 42027 sur la machine CTIServerA. Cette liste suppose également que le périphérique est un poste pour le périphérique représenté par le périphérique 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

Les serveurs PIM et CTI ne sont pas actifs dans OPC

Utilisez la commande « status » opctest et confirmez que le PIM IPCC et le serveur CTI affichent les états PIM_ACTIVE et CTI_ACTIVE. Les barres de titre des fenêtres de journal du serveur PIM et CTI indiquent également l'état du processus.

Connexion du client CTI impossible

Vérifiez les paramètres de connexion au serveur CTI. Pour le téléphone logiciel de bureau, les paramètres sont dans le fichier .ini (généralement c:\program files\geotel\cti desktop\cticonfig.ini). Les paramètres à vérifier sont les suivants :

• PeripheralID : cette valeur doit correspondre à l'ID de périphérique du périphérique IPCC dans Configurer > ICM.

• SideAHost : cette valeur doit être le nom d'hôte IP ou l'adresse du serveur CTI côté A.

• SideBHost : cette valeur doit être le nom d'hôte IP ou l'adresse du serveur CTI côté B.  Si le serveur CTI est simplifié, vous pouvez laisser ce champ vide.

• SideAPort : cette valeur doit correspondre au port que le serveur CTI du côté A écoute pour les connexions. Cette valeur est spécifiée dans le programme d'installation d'ICM pour le serveur CTI. Le serveur CTI affiche ce port dans la barre de titre et consigne cette valeur au démarrage du serveur CTI. Vérifiez si le client peut envoyer une requête ping au serveur CTI.

Le client CTI obtient une erreur indique que l'agent doit être connecté à ACD

Exécutez le fichier setup.exe qui réside dans le répertoire \icr\bin sur le serveur PG/CTI. Sélectionnez le composant CTI Gateway. Vérifiez si la case Connexion de l'agent requise est décochée. Cette case à cocher n'est pas applicable à IPCC ou à toute application de contrôle tierce. L'objectif de cette case à cocher est de surveiller les applications et autres agents ACD.

Le journal PIM affiche l'une de ces erreurs de connexion

Utilisez procmon sur le pim et « trace tp* » pour activer le suivi tiers (sensible à la casse). La demande de connexion doit s'afficher. Vérifiez si les paramètres sont corrects. L'instrument est tracé comme "Device=". Cette valeur doit correspondre à la chaîne /dn dans le paramètre de configuration cible du périphérique. L'ID de l'agent est suivi comme "AgentID=". Cette valeur doit correspondre au numéro de périphérique de l'agent dans Configurer/ICM.

• MOT_DE_PASSE_INVALIDE

  Assurez-vous que le mot de passe est correct (il est possible que le mot de passe ne soit pas suivi en texte clair). Si le mot de passe est incorrect, le journal doit afficher une erreur INVALID_PASSWORD_SPECIFIED.

• OBJET_NON_VALIDE

  Indique que les paramètres de configuration de la cible de périphérique contiennent un type de périphérique non valide. Cette erreur se présente comme suit avec des espaces entre les mots clés :

  /devtype CiscoPhone /dn 9782755100

• CIBLE_PÉRIPHÉRIQUE_NON VALIDE

  Indique que la cible du périphérique n'est pas valide, probablement dans le champ des paramètres de configuration. Avec l'utilitaire dumplog, affichez le journal PIM pour la dernière fois que le PIM a redémarré. Le journal valide les cibles de périphérique et consigne les erreurs lorsque les chaînes de configuration des cibles de périphérique ne sont pas valides.

Le journal JGW affiche les erreurs de connexion

Recherchez dans le journal jgw les erreurs qui se produisent lors des tentatives de connexion. Utilisez procmon pour le PIM et « trace *TP* » pour activer le suivi tiers (sensible à la casse). Recherchez la ligne « MsgAddCallObserver: Adresse : XXXX" où XXXX est le poste auquel vous essayez de vous connecter. Ce poste doit être un poste Cisco CallManager valide sur un périphérique que l'utilisateur PG est autorisé à contrôler. Le numéro de poste doit correspondre au nombre de chiffres correct du téléphone, comme le sait Cisco CallManager. En d'autres termes, le poste doit être le numéro que vous composez à partir d'un autre téléphone sur le même Cisco CallManager pour joindre le téléphone en question.

Périphérique hors domaine du fournisseur

Si le journal jgw affiche une exception, qui indique que le périphérique n'est pas dans le domaine du fournisseur, le téléphone n'est pas associé à l'utilisateur avec lequel JTAPI GW se connecte. Assurez-vous que l'extension située à l'extrémité de la liste d'association des périphériques des utilisateurs du répertoire global est correcte. Vérifiez également que le numéro de ligne du périphérique n'est pas enregistré deux fois. L'affichage des lignes partagées est une fonctionnalité Cisco CallManager non prise en charge par IPCC. Vous pouvez essayer par inadvertance de configurer une apparence de ligne partagée avec deux téléphones qui ont la même ligne. Si vous changez un numéro de ligne, les autres changements, et PG ne peut pas se connecter au périphérique correct. Afin de résoudre ce problème, supprimez les deux lignes et ajoutez-les à Cisco CallManager.

GROUPE_COMPÉTENCES_NON VALIDE_SPÉCIFIÉ

Pour se connecter, un agent doit être configuré dans Configurer/ICM en tant que membre d'au moins un groupe de compétences (membre du groupe de compétences).

Agent déjà connecté à un autre téléphone

Assurez-vous que l'agent (comme le numéro de périphérique de l'agent le représente) n'est pas déjà connecté à une autre cible de périphérique. Pour ce faire, vous pouvez exécuter Monitor ICR et le rapport Free from Agent pour l'agent en question. Si l'agent est connecté, cela indique l'ID de cible réseau de la cible de périphérique dans laquelle l'agent est connecté. Les données d'agent apparaissent dans la base de données awdb uniquement si vous avez configuré ICM pour envoyer des données d'agent pour le périphérique à cet AW.

• Vous pouvez également effectuer une requête pour ceci dans isqlw par rapport à la table Agent_Temps_Réel dans la base de données awdb. Commencez par rechercher la cible de compétences de l'agent (par exemple, sélectionnez * dans Agent où IDpériphérique = XXX et NuméroPériphérique = AAAA). Vérifiez ensuite si l'agent est connecté (par exemple, sélectionnez * dans Agent_Real_Time où SkillTargetID = XXX).

• Vous pouvez également vérifier cela lorsque vous vous connectez à procmon à PIM et exécutez dagent <numéro de périphérique de l'agent>.

Périphérique cible déjà connecté

Assurez-vous que la cible du périphérique (comme indiqué par l'instrument) n'a pas déjà un autre agent connecté.

• Une façon de vérifier ceci est d'exécuter isqlw avec la table Agent_Temps_Réel dans la base de données awdb. Recherchez d'abord l'ID de cible réseau pour la cible de périphérique en question. Par exemple, sélectionnez * dans Device_Target où ConfigParam comme ‘%1003%’. Maintenant, vérifiez si la cible du périphérique est connectée. Par exemple, sélectionnez * dans Agent_Real_Time où NetworkTargetID = XXX.

• Vous pouvez également vérifier cela lorsque vous vous connectez à procmon au PIM et videz la cible du périphérique. Il existe deux façons de vider la cible du périphérique. La commande ddt prend un ID de cible réseau comme entrée et vide la cible du périphérique. La commande deadt prend la chaîne /dn de la configuration de la cible du périphérique comme entrée et vide la cible du périphérique. Par exemple, si la chaîne /dn cible du périphérique est /dn 978275100, vous videz la cible du périphérique comme deadt 9782755100.

Périphérique non associé à l'utilisateur PG

Accédez à la page Web Cisco CallManager, sélectionnez User/Global Directory et recherchez l'ID utilisateur que la PG utilise. Cochez la case « Associated Devices » et assurez-vous que l'utilisateur a l'autorisation de contrôler le périphérique.

• Si vous ne trouvez pas le périphérique sur la page utilisateur (cochée ou non), il peut y avoir un problème de synchronisation entre la base de données (où Cisco CallManager stocke les périphériques) et le serveur d'annuaire (qui stocke les périphériques et les profils utilisateur). Vérifiez si le serveur d'annuaire (serveur d'annuaire DC) s'exécute.

• Consultez le journal de l'application de l'Observateur d'événements Windows NT et recherchez les erreurs dans le répertoire DC ou dans le métalink. Si des erreurs d'importation se produisent, exécutez avvid_recfg à partir de c:\dcdsrvr\bin.

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

Périphérique téléphonique non actif

Vérifiez si le téléphone est sous tension, s'il est enregistré auprès de Cisco CallManager et s'il peut passer et recevoir des appels depuis le téléphone sans le contrôle de l'agent.

L'agent ne peut pas appeler

Agent à l'état Non prêt

Assurez-vous que l'agent est connecté et qu'il n'est pas à l'état Disponible.  Si l'agent n'est pas disponible, il ne peut pas passer d'appel. Pour passer un appel, cliquez d'abord sur Non prêt.

Paramètres Agent Desk incorrects

Si une erreur se produit uniquement lorsque vous composez certains numéros, vérifiez ces numéros à partir d'un téléphone physique pour vous assurer que vous pouvez composer avec succès. Si vous avez configuré un plan de numérotation ICM, vérifiez si le numéro composé correspond à l'un des caractères génériques de votre plan de numérotation. Vérifiez ensuite si les paramètres du bureau de l'agent permettent à l'agent de composer le type de numéro identifié par l'entrée du plan de numérotation composé (par exemple, International).

Plan de numéro composé dans l'accès aux blocs PIM

Le plan de numérotation configuré pour chaque PIM peut être configuré de manière incorrecte ou correctement pour empêcher un agent d'appeler un certain numéro. L'erreur dans le journal PIM doit indiquer une erreur d'autorisation. Les numéros des agents et des périphériques ne peuvent pas se chevaucher lorsque le plan de numérotation composé est utilisé pour passer des appels agent à agent.

L'Agent Effectue Un Appel Court, Doit Attendre Pour Passer Un Nouvel Appel

Le routeur rend l'agent indisponible lorsque l'agent passe un appel ou lorsqu'un appel est acheminé vers l'agent. Ce mécanisme permet au routeur d'acheminer un autre appel à l'agent avant que le PIM ne signale l'arrivée de l'appel. Certains réseaux mettent plusieurs secondes pour acheminer réellement l'appel. Le routeur n'annule pas le minuteur en fonction de l'état de l'agent.

Si le temps réel nécessaire pour acheminer les appels vers le PIM à partir du client de routage est relativement court, vous pouvez modifier le temps configurable dans le routeur. Sur l'un des routeurs dans une fenêtre de commande DOS, utilisez rtsetting.exe. Cliquez sur Extrapolation > Agent. Le paramètre par défaut est de 10 secondes. Si la valeur est trop courte, le routeur achemine les appels vers les agents sur le point de recevoir un appel. Le PIM abandonne alors les appels.

Le délai d'attente par défaut sur le PIM est de 7 secondes. Vous pouvez modifier cette valeur avec la commande regedt32. Ajoutez la clé « 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 à la configuration de la version 4.1.5.

Remarque : cette touche apparaît sur deux lignes en raison des limites d'espace.

Le numéro PIM doit toujours être inférieur de quelques secondes au minuteur d'extrapolation du routeur pour empêcher le routeur d'envoyer de nouveaux événements de pré-appel au PIM avant que l'événement d'origine ne soit traité. Cela entraîne des problèmes dans le PIM.

Si l'appel arrive après l'expiration du délai PIM, l'appel est considéré comme un appel non-ACD et aucune des variables de contexte, informations de service ou de groupe de compétences n'est attribuée à l'appel.

L'agent ne peut pas y aller : Non prêt, Occupé ou Autre

Agent À L'État « Actif »

Si l'agent est en cours d'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 en conversation ou en attente jusqu'à la fin de l'appel. L'agent passe à Non prêt, Prêt à accepter le travail ou Non prêt à accepter le travail, selon le bouton sur lequel il appuie. Si, après la fin de l'appel, l'agent passe immédiatement à Disponible, vous devez vérifier les paramètres du bureau de l'agent et voir si Disponible après les appels entrants ou Disponible après les appels sortants sont définis. Ces paramètres remplacent les tâches effectuées par l'agent à l'aide des boutons pendant un appel.

Les paramètres du bureau des agents empêchent la transition

Vérifiez les paramètres du bureau de l'agent dans Configurer ICM et voyez si Motif d'inactivité requis est coché. Si la case est cochée, l'agent ne peut pas passer à l'état Non prêt sans code de raison. Modifiez le fichier Desktop_Settings.cfg pour qu'il corresponde au paramètre du bureau de l'agent dans Configurer ICM ou modifiez le paramètre du bureau de l'agent dans Configurer ICM.

Si aucun paramètre de bureau d'agent n'est attribué à l'agent, celui-ci peut se connecter et se déconnecter, mais il ne peut ni se déconnecter ni se déconnecter. La solution consiste à fermer l'application de l'agent, à attribuer un paramètre de bureau de l'agent et à se reconnecter.

L'agent doit attendre pour ne pas être prêt

Le routeur rend l'agent indisponible lorsque l'agent passe un appel ou lorsqu'un appel est acheminé vers l'agent. Ce mécanisme permet au routeur d'acheminer un autre appel vers l'agent avant que le PIM ne signale l'appel comme reçu. Certains réseaux mettent plusieurs secondes pour acheminer réellement l'appel. Le routeur n'annule pas le minuteur en fonction de l'état de l'agent.

Si le temps réel de routage des appels vers le PIM à partir du client de routage est relativement court, vous pouvez modifier le temps configurable dans le routeur. Sur l'un des routeurs dans une fenêtre de commande DOS, utilisez rtsetting.exe. Cliquez sur Extrapolation > Agent. 10 secondes sont établies par défaut. Si la valeur est trop courte, le routeur achemine les appels vers les agents sur le point de recevoir un appel. Le PIM abandonne alors les appels.

L'agent ne peut pas être prêt

VIOLATION_PRIVILÈGE_SUR_PÉRIPHÉRIQUE_SPÉCIFIÉ

Il existe une incohérence dans les données de la demande de connexion et de la demande prête. Il est possible que les numéros d'instrument, d'ID d'agent ou de périphérique ne correspondent pas. Activez le suivi du serveur CTI avec procmon et définissez regset sur 0xf8 pour voir les suivis appropriés. Vous pouvez également l'afficher dans les journaux OPC ou PIM, si le suivi de tiers (TP) est activé.

Déconnexion impossible de l'agent

État actuel de l'agent empêche l'appel

Si l'agent est à l'état Travail prêt, Travail non prêt ou Disponible, il doit d'abord passer à l'état Non prêt avant de se déconnecter. Modifiez le fichier Desktop_Settings.cfg pour qu'il corresponde au paramètre du bureau de l'agent dans Configurer ICM ou modifiez le paramètre du bureau de l'agent dans Configurer ICM.

Les paramètres du bureau des agents empêchent le changement d'état

Si l'agent est à l'état Non prêt et ne peut toujours pas se déconnecter, vérifiez les paramètres du bureau de l'agent dans Configurer ICM et voyez si Motif de déconnexion requis est coché.

L'agent affiche un appel actif ou un agent en conversation, mais aucun appel au téléphone

Déconnexion et reconnexion de l'agent

Si le téléphone logiciel affiche un appel qui n'est plus physiquement présent, l'état de l'agent peut être bloqué en conversation ou en attente et l'agent ne peut pas se déconnecter. Cela peut être dû à un bogue logiciel dans JTAPI ou le PIM. Afin de supprimer la condition, essayez d'abord de supprimer l'appel du téléphone logiciel si le bouton de libération est activé. Si cela ne fonctionne pas, essayez de déconnecter l'agent. Si le bouton de déconnexion ne fonctionne pas, quittez et redémarrez le téléphone logiciel. Si la condition persiste, quittez le téléphone logiciel, exécutez le Gestionnaire des tâches, exécutez kill geodcs.exe et common~1.exe, et redémarrez le téléphone logiciel. Ces processus peuvent continuer à s'exécuter et mémoriser l'état non valide de l'agent.

Agent dans un état incorrect au niveau du PIM

Dans procmon, vérifiez l'état de l'agent au niveau du PIM. Si vous redémarrez le bureau de l'agent et que la condition ne s'efface pas, vous pouvez prendre d'autres mesures. Le serveur CTI et OPC fournissent des mécanismes pour effacer les appels avec l'interface de débogage de procmon ou opctest. Il s'agit d'une option légèrement préférée à l'autre option qui est de faire tourner le service PG ou au moins de fermer la fenêtre PIM.

Appels effacés peu après l'alerte ou établis

Paramètres du Registre incorrects

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

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 sur deux lignes en raison des limites d'espace.

Définissez ces valeurs sur 300 et 28800, respectivement.

Le post-routage ne fonctionne pas

Vérification du routage et du script de routage

Utilisez l'outil AW Call Tracer pour vérifier si l'appel parvient au script et si celui-ci s'exécute correctement. Exécutez Script Editor et surveillez le script. Recherchez les problèmes dans les journaux Router, OPC et PIM. La plupart des erreurs de route sont tracées sans condition.

'Use DN Label Map' vérifié pour le client de routage du périphérique

Il existe un paramètre pour chaque client de routage dans Configurer ICM intitulé « Utiliser DN/Label Map ». Si ce paramètre est défini sur "Oui", vous devez configurer une entrée "Étiquette du numéro composé" pour chaque combinaison de numéro composé et d'étiquette cible possible. Ce paramètre n'est pas utile sur les clients de routage PG et doit être défini sur « Non ».

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

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

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

Pour utiliser le post-routage, vous devez configurer un « point de routage CTI » sur Cisco CallManager et affecter une ligne au point de routage avec le numéro de répertoire souhaité (par exemple, « 5000 »). Pour que les appels d'agent soient post-routés, utilisez le plan de numérotation. Un agent qui compose un numéro vers le point de routage CTI de Cisco CallManager confond le téléphone logiciel IPCC dans la version 4.1.9 de CTI Desktop.

Le périphérique pour le point de routage CTI ne figure pas dans la liste des périphériques contrôlés par l'utilisateur PG

Vous devez ajouter le périphérique de point de routage CTI à la liste des « périphériques associés » pour l'utilisateur PG sur la page Web de l'utilisateur Cisco CallManager sous le répertoire global. Si vous créez un nouveau périphérique, ajoutez d'abord la ou les lignes, puis ajoutez le périphérique à la liste des périphériques associés de l'utilisateur. Si vous ajoutez d'autres lignes à un périphérique qui existe déjà dans la liste des périphériques utilisateur, vous devez redémarrer le JGW pour que le JGW reconnaisse les nouvelles lignes. Cependant, si vous ajoutez un nouveau périphérique, ajoutez une ligne au périphérique, puis ajoutez le périphérique à la liste des périphériques utilisateur, le JGW doit être en mesure de reconnaître le nouveau périphérique (dans un délai d'environ 30 secondes).

Aucun numéro composé configuré sur Cisco ICM

Vérifiez le numéro composé pour vous assurer qu'il est configuré pour le client de routage périphérique. Exécutez procmon à JGW et activez la trace comme "trace *ROUTE*" (sensible à la casse). Recherchez les erreurs relatives au numéro composé dans le journal JGW. Au démarrage, JGW tente d'enregistrer un rappel de routage pour le numéro composé. Lorsqu'un appel est effectué vers le numéro composé, la passerelle reçoit un « RouteEvent ».

En plus du numéro composé, vérifiez si le type d'appel est créé et correctement mappé au script.

Vérifiez que le redémarrage de JGW n'est pas requis

Si vous avez configuré un numéro composé par ICM, que vous avez configuré le point de routage CTI et que vous l'avez ajouté à la liste des périphériques utilisateur, mais que vous ne recevez toujours pas de demandes de routage lorsque le numéro est composé, vous devrez peut-être redémarrer le JGW (ou faire tourner la PG). Vous n'avez besoin de redémarrer que si vous avez activé le suivi dans JGW (trace *ROUTE*) et que vous voyez des erreurs qui montrent que l'adresse n'est pas dans le fournisseur. En règle générale, le JGW doit être capable de reconnaître les nouveaux points de routage CTI qui sont ajoutés à la liste des périphériques utilisateur sans avoir à redémarrer. En outre, si des lignes sont ajoutées à un point de routage CTI qui existe déjà, le JGW ne les reconnaît pas sans avoir besoin de redémarrer. Vous devez pouvoir éviter un redémarrage si vous ajoutez un nouveau point de routage CTI pour chaque numéro composé au lieu de 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 winnt\java\lib du PIM. Si DeviceListPolling est désactivé, vous devez activer DeviceListPolling. Si DeviceListPolling est désactivé et que vous ajoutez un périphérique à la liste des utilisateurs, vous devez faire tourner la PG ou au moins la GW JTAPI pour que la PG puisse voir le nouveau périphérique.

Rechercher les boîtes de dialogue de routage dans les journaux OPC

Utilisez opctest pour activer le suivi de route « debug /routing » et rechercher les erreurs dans les journaux OPC lorsque des appels sont passés au point de routage. Vérifiez que les demandes de routage sont reçues et que les étiquettes sont renvoyées. Les demandes de route apparaissent sous la forme de messages « CSTA_ROUTE_REQUEST » et « ICR_NEW_CALL_REQ ». Les étiquettes renvoyées apparaissent sous la forme de messages « ICR_CONNECT ». Si des erreurs se produisent, vous pouvez voir les messages « ICR_DIALOG_FAIL » au lieu des messages « ICR_CONNECT ». Dans ce cas, recherchez les erreurs dans le journal du routeur.

Rechercher les boîtes de dialogue de routage dans les journaux du routeur

Utilisez rtsetting.exe pour activer le suivi de route et vérifier les erreurs dans les journaux du routeur lorsque des appels sont passés au point de routage.

Vérifiez que toutes les étiquettes requises sont configurées. Si votre script de routage cible des agents IPCC/EA, vous devez avoir des étiquettes configurées pour le client Post Routing pour chaque cible de périphérique cible.

Le Script De Routage Ne Déplace Pas La File D'Attente Des Appels Lorsque L'Agent Est Disponible

Recherchez les erreurs dans le journal du routeur. S'il n'y en a pas :

Aucune erreur dans le journal du routeur — Le noeud File d'attente est mis en file d'attente selon la priorité de base du groupe de compétences

Si le noeud de file d'attente se place en file d'attente selon la priorité de base, rien ne se produit lorsque l'agent devient disponible. Il existe deux options pour résoudre ce problème :

• Il existe un paramètre de registre de routeur appelé AutoLoginBase (use rtsetting.exe). Modifiez ce paramètre pour permettre à l'appel d'être mis en file d'attente vers le groupe de compétences de base de fonctionner plus ou moins comme prévu. Lorsque ce type de mise en file d'attente a lieu, il n'y a pas de préférence pour les compétences primaires par rapport aux compétences secondaires.

• Mettre explicitement en file d'attente les compétences principales et/ou secondaires dans le noeud de file d'attente.

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

Configurez l'étiquette pour la cible du périphérique en question et toutes les autres cibles vers lesquelles ce client de routage peut effectuer le routage. Utilisez l'outil de configuration en bloc AW pour effectuer cette opération plus efficacement que la configuration de l'ICR.

Sonnerie Aucune réponse entendue lorsque tous les agents et ports de file d'attente sont occupés

Vérifier les journaux du routeur

• Les erreurs de routage doivent être tracées de manière inconditionnelle.

• Vous pouvez utiliser l'outil Call Tracer pour tester le chemin de routage.

• Utilisez rtrtrace pour activer la trace de la demande de route et vérifier les journaux du routeur pour détecter les erreurs lorsque des appels sont passés au point de route.

• Vérifiez que toutes les étiquettes requises sont configurées. Si le script de route cible les agents IPCC/EA, vous devez avoir des étiquettes configurées pour chaque cible de périphérique cible. Chaque périphérique cible doit avoir des étiquettes configurées pour chaque client de routage qui tente d'envoyer des appels. Par conséquent, si un appel est pré-routé du réseau directement vers un agent disponible, le client de routage réseau doit avoir une étiquette pour la cible de périphérique associée. Si l'appel est d'abord mis en file d'attente au niveau d'un VRU, puis remis à l'agent, le client de routage VRU doit disposer d'une étiquette pour le périphérique cible associé.

Assurez-vous que le mappage d'étiquette DN est désactivé dans le client de routage dans Configurer ICM

Assurez-vous que l'option Utiliser le mappage DN/Étiquette n'est pas cochée dans l'onglet Client de routage de l'Explorateur Configuration Manager/PG.

Vérifier les journaux PIM

• Utilisez procmon pour activer la trace dans le PIM (trace precall, trace *call_event*) et vérifier les journaux. Le message de pré-appel s'affiche à partir du routeur. Vous voyez également « DeliveredEvent » avec « DevTgDevStr » défini sur l'extension de l'agent. Si l'appel n'apparaît pas, assurez-vous que l'étiquette est correcte pour le client de routage.

Les transferts arbitraires obtiennent des résultats incohérents

IPCC ne prend pas en charge l'option de mise en attente d'un appel et d'établissement d'un nouvel appel, car Cisco CallManager fournit des résultats incohérents. Il s'agit d'une amélioration du produit qui peut être envisagée pour une version ultérieure.

L'autre ne fonctionne pas

Lorsqu'un appel de consultation est commuté/alterné/mis en attente/récupéré, Cisco CallManager rompt l'association de consultation. Cela entraîne un scénario de transfert arbitraire qui n'est pas pris en charge. Les agents peuvent se reconnecter au client et lancer une nouvelle consultation. 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.

La personne en conférence ne peut pas téléphoner dans une autre personne

Cisco CallManager a une limitation : seul l'initiateur de la conférence peut ajouter d'autres participants à la conférence. Les autres parties ne peuvent pas ajouter d'autres parties dans Cisco CallManager.

Station d'agent déconnectée de manière inattendue

Paramètres du bureau d'agents Minuteur d'inactivité

Dans les paramètres de bureau d'agent, il existe un paramètre de temps pour déconnecter les agents à l'état Non prêt. La durée maximale d'inactivité est de 2 heures, mais vous pouvez la réduire. Les agents à l'état Disponible ne peuvent pas être déconnectés alors qu'ils sont à l'état inactif. L'agent passe de Prêt à Non prêt si le minuteur de sonnerie sans réponse expire (également un paramètre de bureau d'agent configurable).

Délai de pulsation du serveur CTI dépassé

Le serveur CTI a un délai d'expiration de pulsation configuré. Les ordinateurs plus anciens, les serveurs CTI surchargés ou les réseaux présentant des problèmes de bande passante peuvent en être la cause principale. Les journaux du serveur CTI doivent signaler une erreur dans le journal.

L'agent ne se comporte pas comme configuré dans les paramètres de bureau de l'agent

Les paramètres du bureau de l'agent dans Configurer ICR(M) et le fichier de configuration de l'agent doivent tous deux convenir de la façon dont l'agent est traité.

La configuration des périphériques d'ICM comporte un minuteur de travail dans Paramètres de configuration. Définissez les paramètres comme \WORKTIMER 30 pour définir un délai de 30 secondes sur auto-available.

Le fichier de configuration du bureau se trouve dans :

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

Le mode de travail sur Entrant doit être défini sur Requis, non Requis avec les données dans Desk_Settings.cfg et dans les paramètres de bureau de l'agent ICR(M). Requis avec données remplace l'option de disponibilité automatique.

Échec des transferts de consultation

Examinez le journal de la passerelle JTAPI et voyez s'il y a des erreurs qui indiquent pourquoi le transfert de consultation échoue. Vérifiez si le logiciel de l'agent autorise les opérations de mise en attente/récupération ou d'autres opérations sur l'appel de consultation. Lorsqu'un appel est mis en attente/récupéré, il n'est plus considéré comme consultatif, mais comme un transfert « arbitraire » par Cisco CallManager. Cisco CallManager rencontre des problèmes de transferts arbitraires. Limiter la reconnexion ou le transfert de l'utilisateur lors d'un appel consultatif.

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

Cisco CallManager rencontre actuellement des problèmes avec un événement de déconnexion pour une consultation initiée par une conférence lorsque la conférence n'est pas terminée. Déconnectez l'appel une deuxième fois pour effacer l'affichage de l'appel sur le téléphone de l'agent.

Le routage de traduction vers VRU ne fonctionne pas

Commencez par surveiller le script actif. Vérifiez ensuite les journaux Router, OPC et PIM du client de routage et du VRU. La plupart des erreurs sont tracées de manière inconditionnelle, mais vous pouvez activer le suivi pour obtenir une meilleure image de ce qui se passe.

Voici la séquence de routage de traduction :

• Le client de routage envoie une nouvelle demande d’appel au routeur.

• Le routeur renvoie une connexion au client de routage avec une étiquette qui doit remettre l'appel à l'IVR.

• L'IVR doit ensuite envoyer une instruction RequestInstruction que la PG VRU utilise pour rechercher la cible périphérique.

• Le routeur fait correspondre les cibles périphériques de l'instruction de requête avec les cibles périphériques de routage de traduction qu'il attend.

• Le script de routage se poursuit avec un script d'exécution ou des noeuds de file d'attente conçus par le client.

Surveillez le script actif pour trouver le chemin d'échec. Recherchez les erreurs dans le suivi du routeur. Vérifiez si le client de routage reçoit les étiquettes initiales. Vérifiez si le VRU reçoit l'appel. Vérifiez si le VRU envoie une instruction de requête au niveau PIM ou OPC du VRU.

La demande de routage n'atteint pas le noeud « Routage de traduction vers VRU » dans le script de routage

Surveillez le script et vérifiez si la requête parvient au noeud de routage de traduction vers le VRU.

Premièrement, dans le script de routage, un noeud de sélection ou de sélection de routage avec un routage de traduction sélectionné n'est pas suffisant pour traduire le routage vers le VRU contrôlé par le service. Un noeud Routage de traduction vers VRU est requis.

Deuxièmement, le moniteur doit montrer que l'appel atteint le noeud de routage de traduction. Un échec signifie ici qu'un routage de traduction ne peut pas être déterminé ou que le message de demande de routage RequestInstruction n'a pas été reçu de l'IVR.

Délais de routage de traduction dans le journal du routeur

L'erreur Translation route time out indique que le routeur ne reçoit pas l'instruction de requête. Vérifiez si le PIM OPC et le VRU comportent des erreurs et si RequestInstruction arrive.

Activez les options « translation routing » et « network VRU tracing » à l'aide de l'outil rtrtrace sur le routeur pour une meilleure indication de ce qui se passe sur le routeur. Dans le VRU PG OPC, activez le rapport de contrôle de service avec opctest .

Le journal PIM VRU indique que DNIS est introuvable sur le groupe de faisceaux X

L'instruction de requête doit indiquer un groupe de faisceaux valide qui correspond à un numéro de périphérique de groupe de faisceaux dans l'un des groupes de faisceaux configurés pour la passerelle VRU. Redémarrez la VRU PG pour recevoir la mise à jour du numéro de périphérique du groupe de faisceaux, le cas échéant.

Vérifier la configuration ICM

Assurez-vous que le mappage d'étiquette DN est désactivé dans le client de routage IVR PG. La passerelle IVR PG doit être affectée à un VRU de réseau. Le VRU de réseau doit être de type 2. Un groupe de faisceaux réseau et un groupe de faisceaux doivent être affectés à la passerelle IVR. Faites référence au groupe de faisceaux réseau dans le groupe de faisceaux.

La PG de carte réseau/post-routage doit avoir une étiquette pour chaque DNIS dans les cibles périphériques. (Dans l’assistant de routage de traduction, définissez les étiquettes sur le même nom que le DNIS pour la demande du client de routage. Vous pouvez le configurer dans le préfixe, sélectionnez l'option prefix = DNIS.)

Le client de routage VRU a besoin d'une étiquette configurée pour le périphérique cible vers lequel il effectue le routage lorsqu'un agent devient disponible.

Dépannage de l'interface Cisco IP IVR - ICM

Cette section de Cisco IP IVR explique comment résoudre les erreurs de configuration entre IP IVR et ICM et inclut les problèmes courants liés à la configuration du routage de post-routage et de traduction de la passerelle IVR PG. Référez-vous au Guide de dépannage de Cisco IP IVR pour plus d'informations sur les erreurs générales IVR.

En général, vérifiez les journaux MIVR sous la page web appadmin > Engine > Trace files.

• Ports et points de routage CTI IVR configurés dans Cisco CallManager, IVR et ICM.

• Les ports et les points de routage CTI IVR sont associés à l'utilisateur IVR dans le répertoire global de Cisco CallManager.

• La case Contrôle de service est cochée dans la configuration IVR ICM.

• Les noms de script dans les définitions de script IVR correspondent aux noms de script VRU réseau dans ICM.

• Le numéro de groupe de faisceaux dans VRU PG correspond au numéro de groupe de ports CTI dans IP IVR.

Échec du routage de traduction

En plus de toutes les autres actions que vous utilisez pour le dépannage, vous pouvez également essayer ces choses pour aider à dépanner l'IVR IP.

• Vérifiez le journal MIVR. Ce journal peut généralement pointer vers des zones problématiques.

• Utilisez les paramètres de débogage SS_TEL et LIB_ICM pour activer Cisco IP IVR.

• Activez le journal Cisco Jtapi pour IP IVR avec jtprefs sur IP IVR. Voir Outils de débogage. Arrêtez et démarrez le moteur IP IVR après avoir activé le suivi.

• Vérifiez si le numéro de groupe de ports CTI sur le groupe de ports de routage de traduction JTAPI IP IVR correspond au numéro de périphérique dans la configuration du groupe de faisceaux dans ICM.

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

Vérifiez les journaux IP IVR sous les fichiers de suivi du moteur pour vérifier si :

• Le script d'exécution est reçu.

• IP IVR peut trouver le script. Téléchargez des scripts avec l'outil d'administration du référentiel.

• IP IVR peut trouver l'invite. Les invites définies par l'utilisateur résident dans \wfavvid\prompts\ user\en_us\ sur l'IVR IP.

L'état JTAPI indique un service partiel

Cela signifie généralement que certains ports CTI ou points de routage CTI configurés dans l'IVR IP n'ont pas été configurés et/ou associés à l'utilisateur de l'IVR IP sur Cisco CallManager.

Cela peut également signifier que les scripts ne sont pas nommés correctement ou qu'ils n'ont pas été téléchargés dans le Gestionnaire de référentiel.

L'état ICM sur IP IVR indique un état partiel

Généralement, cette condition indique une configuration partielle ou une configuration incorrecte d'un côté ou de l'autre.

Invite de démarrage entendue lorsqu'un appel est retiré de la file d'attente du routeur

Il s'agit d'un script de routage mal configuré qui autorise un délai d'attente trop faible dans la configuration du script VRU réseau dans Configurer ICR.

Certains des scripts disponibles avec l'interface IP IVR pour ICM s'exécutent très longtemps, mais le délai d'attente par défaut sur la configuration du script réseau ICM est de trois minutes. Si le script expire et que le chemin d'échec du script d'exécution exécute un autre script d'exécution, ces scripts d'exécution sont mis en file d'attente au IVR. Lorsque les scripts sont retirés de la file d'attente, vous entendez de nombreux scripts se chevaucher.

Dépannage des statistiques de service IVR

Les statistiques IVR sont importantes pour les rapports de niveau de service IPCC. Par conséquent, certaines informations sur la façon de dépanner sont incluses ici. En guise de vue d'ensemble, les modifications apportées à la passerelle de routage et de VRU où les appels implémentés dans le VRU sont comptabilisés comme des appels en file d'attente, au lieu d'être connectés. Lorsque des appels sont routés, ils sont signalés comme ayant obtenu une réponse. Lorsque le client en file d'attente déconnecte des appels, ils sont signalés comme abandonnés. Consultez le fichier readme.txt des correctifs 53 et 54 pour plus de détails. Le routeur envoie des événements de file d'attente spéciaux qui indiquent l'état de l'appel au niveau du routeur.

Un registre spécial est configuré dans le VRU PIM. Vous devez donc activer volontairement cette fonctionnalité afin d'assurer une interruption minimale.

Le Rapport en temps réel sur les services d'entreprise 10 utilise ces données de manière spéciale lorsque vous ajoutez le ou les services VRU et le ou les services PG Cisco CallManager à un ou plusieurs rapports de périphériques d'entreprise. Le rapport en temps réel sur les services d'entreprise nécessite que les services VRU PG et Cisco CallManager PG soient regroupés dans un service d'entreprise à des fins de création de rapports.

Les nouveaux rapports de type d'appel pour les enregistrements historiques et en temps réel sont également utiles. La grille en temps réel du groupe de compétences affiche désormais les appels mis en file d'attente pour le groupe de compétences.

Aucune statistique de service ou enregistrement détaillé des appels de terminaison n'est généré

VRU PIM ne génère pas d'événements CSTA. Activez la fonction Service Control Reporting dans la configuration VRU PG. Il s'agit de la clé de Registre dans ServiceControlQueueReporting sous :

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

Remarque : cette clé de registre apparaît sur deux lignes en raison des limites d'espace.

Le VRU signale tous les appels comme connectés, non mis en file d'attente comme requis

Clé de registre ServiceControlQueueReporting non conforme ou non définie sur 1

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

Ajoutez la clé ServiceControlQueueReporting et définissez la valeur sur 1 dans :

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

Remarque : cette touche apparaît sur deux lignes en raison des limites d'espace.

Les appels sont comptabilisés dans un service incorrect ou n'apparaissent pas dans les rapports de service

Le journal OPC indique que le mappage de service est introuvable

Le journal OPC indique que le mappage de service est introuvable lorsque les appels sont comptés par rapport au mauvais service ou n'apparaissent pas dans les rapports de service.

Problèmes de rapport Cisco ICM

Cisco ICM n'est pas conçu pour faciliter la corrélation des données des tables Type d'appel, Service et Groupe de compétences. Les nombres ont généralement des significations légèrement différentes dans chaque groupe. Il n'y a qu'un seul service pour un appel, mais il peut y avoir deux groupes de compétences si plusieurs agents sont impliqués. La fonctionnalité de redirection en l'absence de réponse (RONA) génère probablement une autre route post-appel sans la génération d'un autre enregistrement de fin.

Les numéros de groupe de compétences d'agent, de groupe de compétences, de service et de type d'appel ne sont pas équilibrés

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

• Condition : Le type d'appel, le service et les groupes de compétences sont configurés avec un mappage logique les uns aux autres, mais les rapports ne correspondent toujours pas exactement.

• Dépannage: Si le volume d'appels est inférieur à 1 appel par seconde, activez les paramètres de suivi dans OPC, PIM et JTAPI GW, en fonction des événements CSTA, PIM, AGENT et tiers. Reportez-vous à la section outils de ce document pour obtenir des instructions.

• Documentez le flux d'appels :

  • Le post-routage initial est-il sur Cisco CallManager PG ou VRU PG ?

  • La fonction FONA (Forward on No Answer) est-elle configurée et à quoi la fonction FONA est-elle configurée pour la redirection ?

  • Un groupe de compétences par défaut est-il configuré avec le périphérique numéro 0 pour séparer les appels routés des appels sortants et non routés ?

Récupérez les données historiques de ces tableaux pendant une journée avec les instructions « select * » :

• Périphérique_Demi_Heure

• Type_Appel_Demi_Heure

• Service_Demi_Heure

• Groupe_Compétences_Demi_Heure

• Détail_Appel_Fin

• Détail_Appel_Routage

Dépannage de Cisco CallManager

Lorsque vous collectez les traces dans Cisco CallManager, vous pouvez activer les indicateurs de la page d'administration de Cisco CallManager sous Services > Trace Flags. 0xCB05 est un bon indicateur de suivi configuré pour le suivi SDL des erreurs CTI. Définissez 0xCB05 sous les paramètres de service à des fins de débogage. Reportez-vous aux cas du TAC AVVID : Collecte des informations de dépannage pour plus d'informations. Reportez-vous à la documentation en ligne de Cisco CallManager, y compris les guides de dépannage.

Activer le suivi pour Cisco CallManager

Référez-vous à Configurer les suivis Cisco CallManager pour l'assistance technique de Cisco pour des informations sur la façon d'activer le suivi pour Cisco CallManager.

Modifier les adresses IP de Cisco CallManager

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

1. Exécutez le programme d'installation sur Cisco CallManager PG et modifiez les services JTAPI pour Cisco CallManager PIM. Si vous disposez d'une mobilité de poste et/ou de services téléphoniques.

2. Arrêtez le moteur CRA.

3. Dans CRA - Modifiez l'adresse IP sous Configuration du moteur.

4. Modifiez IP sous JTAPI.

5. Arrêtez le service d'annuaire DC sur le serveur.

6. Modifier l'adresse IP dans la configuration du répertoire.

7. Dans Cisco CallManager - changez l'adresse IP sous System > Server.

8. Modifiez l'adresse IP dans les URL sous System > Enterprise Parameters.

9. Modifiez l'adresse IP dans toutes les URL sous Features > Phone Services.

10. Modifier l'adresse IP du serveur - Propriétés réseau.

11. Remplacez DHCP Option 150 par la nouvelle adresse IP.

12. Changez IP dans le profil d'hôtel dans le répertoire DC, Cisco CallManager > System Profile > Hoteling.

13. Ouvrez SQL Enterprise Manager.

14. Modifier les adresses IP dans les URL de la table Plug-In.

Afin de sauvegarder vos modifications de configuration :

1. Ouvrez la configuration stiBackup.

2. Modifiez les adresses IP du serveur sous tous les onglets appropriés.

Outils de débogage

Procmon

Procmon est un outil de ligne de commande que vous pouvez utiliser pour déboguer les processus GW PIM et JTAPI.

• Utilisation : processus procmon <nom du client> <noeud>.

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcc cg1a ctisvr

Voici quelques paramètres de suivi utiles pour chacun des processus :

• JTAPI GW (utiliser procmon)

  • trace JT_TPREQUESTS (active les suivis de demandes tierces)

  • trace JT_JTAPI_EVENT_USED (active les traces pour les événements JTAPI utilisés par la PG)

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

  • trace JT_ROUTE_MESSAGE (active les traces du client de routage)

  • trace JT_LOW* (traces basées sur les couches JTAPI et CTI sous-jacentes)

• PIM (utiliser procmon)

  • trace tp* (active les suivis de demandes tierces)

  • trace precall (active les traces d'événements de trace)

  • trace *event (active les suivis d'événements d'agent et d'appel)

  • trace csta* (active les suivis d'événements d'appel CSTA)

• SERVEUR CTI (utilisez procmon)

  • regset EMSTraceMask 0xf8 (active les traces utiles du serveur CTI, susceptibles d'être renvoyées)

OPCtest

Opctest est un outil en ligne de commande pour déboguer le processus OPC sur la PG.

• Utilisation : opctest /cust <nom du client> /node <noeud>

  • opctest /cust ipcc /node pg1a

• Paramètres utiles

  • debug /agent (active les traces d'événements d'agent)

  • debug /routing (active les suivis d'événements de routage)

  • debug /cstacer (active les traces d'événements csta)

  • debug /tpmsg (active les traces de demandes d'appel tierces)

contre-essai

Rttest est un outil d'interface de ligne de commande permettant de déboguer le processus du routeur sur le logiciel ICM. Voir trtrace pour la version GUI.

• Utilisation : rttest /cust ipcc

rtsetting.exe

Outil GUI permettant de modifier les paramètres du registre du routeur.

• Il existe une option permettant de rétablir les paramètres par défaut.

rtrtrace.exe

Outil GUI permettant d'activer diverses traces de routeur sur l'ICM.

• Les paramètres particulièrement utiles pour IPCC sont les suivants :

  • Mise en file d'attente : pour les problèmes de retrait.

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

  • Routage de traduction - pour les problèmes de routage de traduction.

vidage mémoire

Exporte les fichiers binaires Cisco ICM dans des fichiers texte. Remplacez les répertoires par le répertoire des fichiers journaux des processus.

• Les fichiers journaux des processus OPC, PIM et JtapiGW résident dans icr\<nom_client>\<noeud>\logfiles\.

• Sur la PG, il y a un fichier batch appelé cdlog où vous tapez >cdlog <cust> <node>.

• Utilisation : dumplog nom du processus

  • Dumplog /" (pour obtenir de l'aide sur les différentes options de dumplog)

  • Dumplog jgw1

  • Dumplog pim1

  • Opc Dumplog

vrutrace

Outil permettant d'afficher le fichier de capture VRU PG. Fonctionne comme dumplog.

Call Tracer

Outil Cisco ICM que vous pouvez utiliser pour déboguer des scripts de routage.  Vous pouvez trouver cet outil dans l'élément de menu AW sur l'AW.

jtprefs

Il s'agit d'un outil permettant d'activer les suivis JTAPI pour le client JTAPI sur l'IVR IP. Les traces JTAPI sur la PG IPCC sont contrôlées avec l'interface procmon. Cet outil réside dans les fichiers programme\CiscoJtapiTools\.

Analyseur de performances

Outil d'administration de Microsoft Windows 2000 qui affiche des données en temps réel pour Cisco CallManager, Cisco IP IVR et ICM. Vous pouvez voir les appels en cours, les périphériques enregistrés et l'utilisation du processeur. Vous pouvez trouver cet outil sous Démarrer > Programmes > Outils d'administration.

Fichiers journaux

Fichiers journaux Cisco ICM

Les fichiers journaux Cisco ICM résident dans \icr\<cust>\<node>\logfiles. Ici, le client référence le nom de l'instance du client et le noeud référence pg1a, ra pour le routeur, cg1a, etc. Utilisez dumplog pour afficher les fichiers journaux.

Remarque : vous pouvez afficher les fichiers de capture d'événements avec des outils de suivi tels que vrutrace. Ces fichiers se trouvent dans un répertoire différent.

Fichiers journaux Cisco CallManager

Les fichiers journaux de Cisco CallManager se trouvent normalement dans \program files\cisco\ccm\trace avec les répertoires de suivi de :

• Ccm - Journaux SDI CallManager.

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

• Sdl - Journaux de signalisation d'appel.

• Tftp - Journaux pour le serveur tftp.

Vous pouvez modifier les paramètres de suivi de ces fichiers à partir de la page d'administration de Cisco CallManager sous Paramètres de suivi. Vous pouvez modifier les paramètres de suivi SDL sous les paramètres de service dans Cisco CallManager.

Fichiers journaux IP IVR

Les fichiers journaux IP IVR résident dans \program files\wfavvid. Vous pouvez également afficher les fichiers journaux IPIVR à partir de la page appadmin sous engine-trace files.

Vous pouvez afficher les journaux du client Cisco JTAPI lorsque vous activez les événements JTAPI avec jtprefs.exe et redémarrez le moteur IP IVR.

Données de profil utiles

Lorsque vous collectez des données pour ouvrir des dossiers, collectez les données répertoriées dans cette section, en plus des fichiers journaux.

Nombre d'agents

Quel est le nombre d'agents configurés ?

Passerelles utilisées

Combien de passerelles sont configurées ?

Versions logicielles des composants

Cisco CallManager, JTAPI Client, ICM, Gateway IOS version et IP IVR.

• Vous pouvez trouver la version de Cisco CallManager sur la page Web d'administration de Cisco CallManager sous Aide > À propos de > Détails.

• Afin de trouver la version du client JTAPI, tapez simplement jview CiscoJtapiVersion dans une invite de commande dans le répertoire \winnt\java\lib sur la passerelle Cisco CallManager PG.

• Vous pouvez également trouver la version IP IVR.

Type IVR

Quel type de système de réponse vocale interactif est utilisé ?

Plates-formes

Quels types de plates-formes sont en cours d'utilisation / 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
• Activation du suivi
• Lecture d'un fichier journal Drwtsn32
• Cas du TAC AVVID : Collecte des informations de dépannage
• Modification des adresses IP de Cisco CallManager
• Assistance et documentation techniques - Cisco Systems