IPCC-Fehlerbehebungsleitfaden

Einführung

Dieses Dokument enthält Informationen zur Fehlerbehebung im Internet Protocol Contact Center (IPCC), das sich auf das Peripheral Gateway (PG) und das Cisco Intelligent Contact Management (ICM) konzentriert. Obwohl dieses Dokument einige Informationen über häufige Probleme mit Cisco CallManager und dem Cisco Global Directory enthält, versucht dieses Dokument nicht, diese Komponenten vollständig zu beschreiben. Vielmehr konzentriert sich dieses Dokument auf Symptome und Methoden, um die Quelle von Problemen zu identifizieren, die der PG sieht.  Die Probleme können sich auf Software oder Konfiguration beziehen.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Problembehebung und Unterstützung für Cisco ICM PG

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Cisco ICM Version 4.6.2

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Symptome und Fehlerbehebungsmaßnahmen

Überprüfen Sie die PG-Protokolle für IPCC. Wenn Sie im Serverprotokoll des Peripheral Interface Manager (PIM), des Open Peripheral Controller (OPC) oder des Computer Telefony Interface (CTI) unspezifische Fehler sehen, rufen Sie das JTapi Gateway (GW)-Protokoll auf, um eine bessere Textbeschreibung des Problems zu erhalten. Die JTAPI-Schnittstelle stellt in der Regel Ausnahmen bereit, wenn bei Drittanbieteranforderungen Fehler auftreten. Diese Ausnahmen stellen nur Zeichenfolgenbeschreibungen ohne Fehlercode bereit. Daher protokolliert der PIM/OPC/CTI-Server viele Fehler als nicht angegebene Fehler.

Cisco IPCC PIM wird nicht aktiv

PIM nicht aktiviert

Überprüfen Sie, ob ein PIM-Protokoll vorhanden ist. Wenn kein PIM-Protokoll vorhanden ist, überprüfen Sie, ob das Peripheriegerät im Cisco ICM-Setup aktiviert ist. Manchmal wird das Peripheriegerät hinzugefügt, aber Sie müssen das Peripheriegerät aktivieren.

Wählen Sie Bearbeiten > Peripheriegerät aus, und aktivieren Sie das Kontrollkästchen Aktiviert.

PIM-Neustarts

Wenn der PIM-Prozess neu startet, zeigen Sie das PIM-Protokoll im Cisco CallManager PG mit dem Dienstprogramm Dumlog an. Wenn die Protokolldatei auf einen Fehler mit dem OPCHeartbeatTimeout hinweist, müssen Sie diese Registrierungseinstellung ändern. Verwenden Sie regedt32, um die Änderung vorzunehmen.

Ändern Sie OPCHeartbeatTimeout in der Registrierung unter eagtpim dynamische Daten auf 10. Hier ist der Pfad:

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

Hinweis: Dieser Schlüssel wird hier aufgrund von Platzbeschränkungen über zwei Zeilen angezeigt.

PIM im Leerzustand im PIM-Protokollfenster

Wenn sich der PIM-Prozess im Leerlauf befindet, führen Sie die folgenden Prüfungen aus:

• Überprüfen Sie das PIM-Protokoll. Sie müssen mindestens einmal pro Minute "Versuchen Sie zu aktivieren" sehen.

• Wenn das PIM nicht aktiv ist, verwenden Sie das Dumlog-Dienstprogramm, um das OPC-Protokoll zu überprüfen. Führen Sie opctest aus, um festzustellen, ob der OPC-Prozess die Konfiguration vom Router empfängt.

• Wenn der OPC-Prozess die Konfiguration nicht vom Router empfängt, verwenden Sie das Dumlog-Dienstprogramm, um das PGAgent-Protokoll anzuzeigen. Der pgagent-Prozess muss über einen aktiven Pfad zum Central Controller verfügen. Wenn der pgagent keinen aktiven Pfad hat, überprüfen Sie die Netzwerkverbindung und die DMP-Konfiguration im PG-Setup. Verwenden Sie auf dem Router das Dumlog-Dienstprogramm, um das ccagent-Protokoll anzuzeigen. Überprüfen Sie, ob das PG-Gerät (DMP-System-ID) als Gerät auf dem Router aktiviert ist.

• Aktivieren Sie den PG in der Router-Konfiguration durch Setup oder in der Registrierung unter der DMP-Registrierung.

• Verwenden Sie in einem Befehlsfenster den Befehl tracert, um die Netzwerkverbindung zwischen dem Router und dem PG zu überprüfen.

  Hinweis: Zwischen DNS und DHCP kann es zu Diskrepanzen kommen.

• Überprüfen Sie, ob sich die IP-Adresse für den Router in der Hostdatei im Verzeichnis c:\winnt\system32\drivers\etc befindet.

• Überprüfen Sie, ob die in PG > Setup konfigurierte ID für die logische Controller mit der ID für den PG Logical Interface Controller unter Configure > ICM übereinstimmt. Stellen Sie sicher, dass die für das Peripheriegerät in PG > Setup konfigurierte Peripheral-ID der ID für das Peripheriegerät unter Konfigurieren > ICM entspricht.

• Ändern Sie die ICM-Konfiguration entsprechend der Konfiguration.

Der JGW-Prozess wird nicht aktiv.

Falsche Version von Microsoft Java Virtual Machine (JVM) ist installiert

• Rufen Sie eine Eingabeaufforderung auf, geben Sie jview ein, und drücken Sie die EINGABETASTE. Informationen zur installierten Java-Version werden angezeigt:

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

• Wenn Sie diese Ausgabe nicht sehen oder die Version älter als 3190 ist, müssen Sie die richtige Version der Microsoft JVM installieren. Führen Sie msjavx86.exe aus. Diese Datei wird während der Einrichtung im Verzeichnis icr\bin installiert.

Java Classpath ist falsch.

• Rufen Sie über die Eingabeaufforderung das Verzeichnis icr\bin auf, geben Sie jtapigw ein, und drücken Sie die EINGABETASTE.  Eine ähnliche Antwort wird angezeigt:

  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)

• Alternativ wird diese Meldung angezeigt:

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

• Wenn Sie beim Ausführen von jtapigw die zweite Meldung sehen, überprüfen Sie Ihren Java-Klassenspath.  Verwenden Sie den Registrierungs-Editor, um den Wert Classpath unter SOFTWARE\Microsoft\Java VM key anzuzeigen.  Legen Sie die folgende Taste fest:

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

Hinweis: Der Laufwerkbuchstabe und das Windows-Systemverzeichnis können sich unterscheiden, und die Zeichen nach Klassen und vor c:\icr.. lauten: Semikolon, Punkt und Semikolon.

Cisco JTAPI-Client nicht auf PG installiert

• Navigieren Sie von der Eingabeaufforderung zum Verzeichnis icr\bin, geben Sie jtapigw ein, und drücken Sie die EINGABETASTE.  Eine ähnliche Antwort wird angezeigt:

  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)

• Anstelle der oben genannten Meldungen sehen Sie die folgende Meldung:

  Java.lang.NoClassDefFoundError

• Wenn Sie beim Ausführen von jtapigw eine ähnliche Meldung sehen, überprüfen Sie, ob der Cisco JTAPI-Client auf dem PG installiert ist. Suchen Sie die Datei CiscoJtapiVersion.class unter c:\winnt\java\lib.

• Wenn diese Datei nicht vorhanden ist, können Sie die Datei auf dem PG über den Cisco CallManager installieren. http://<callmanager name>/main.asp. Sie können die Datei auf der Registerkarte Anwendung finden.

JTAPI GW-Protokoll beschwert sich über inkompatible JTAPI-Version

• Wenn Sie nur JTAPI 4.1 Service Pack (SP) 4 mit einer Hotfix unter 50 auf dem Cisco CallManager PG installiert haben, müssen Sie ein Upgrade durchführen.

• Wenn Sie ICM > Setup ausgeführt haben, um das PG zu aktualisieren, überprüfen Sie, ob das Datum/die Uhrzeit in der Datei \icr\bin\icrjavalib.zip ein aktualisiertes Datum anzeigt. Das Datum muss etwa dem Datum/der Uhrzeit in der Datei bldXXXXX.version entsprechen, und zwar innerhalb eines Tages.

Hinweis: Setup kann diese Datei nicht aktualisieren, wenn die Datei bei der Ausführung von Setup verwendet wird. Diese Situation kann auftreten, wenn Sie einen Internet-Browser geöffnet haben, da der Browser die Zip-Datei als Verzeichnis für den Klassenpfad behandelt, wenn der Browser die Zip-Datei öffnet. Um dieses Problem zu vermeiden, schließen Sie alle Browsersitzungen, bevor Sie Setup ausführen.  Wenn die Datei vom Setup nicht aktualisiert werden kann, wird eine Meldung angezeigt, die Sie anweist, den Computer neu zu starten, um die Dateien zu aktualisieren. Sie müssen neu starten.

JTAPIGW kann keine Verbindung zu Cisco CallManager herstellen

• Das PIM kommuniziert mit dem JTAPI Gateway (JTAPIGW), und das JTAPIGW kommuniziert mit dem Cisco CallManager. Während der PIM versucht, aktiv zu werden, weist das PIM JTAPIGW an, die Kommunikation mit dem Cisco CallManager über JTAPI zu initialisieren.

• Es müssen Meldungen angezeigt werden, die darauf hinweisen, dass der JTAPIGW eine Verbindung vom PIM akzeptiert hat und dass die Kontakte getProvider() vorhanden sind. Beispiel:

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

  Hinweis: Dieses Beispiel wird aufgrund von Platzbeschränkungen über mehrere Posten angezeigt.

Wenn die Ablaufverfolgung nicht erfolgreich zurückgegeben wurde, können Sie nach dem Aufruf von getProvider() weitere Fehler sehen.  Das trace to getProvider() zeigt die Parameter, die zum Initialisieren von JTAPI verwendet werden.  Der erste Parameter ist der Dienstname, d. h. der IP-Hostname oder die IP-Adresse des Cisco CallManager-Systems.  In diesem Beispiel wird die IP-Adresse verwendet.  Wenn ein Name verwendet wird, muss der PG den Namen über eine Hostdatei oder einen DNS auflösen können.  Achten Sie darauf, dass Sie einen Ping an den Namen oder die Adresse senden können.  Wenn Sie den Dienstnamen ändern müssen, führen Sie ICM > Setup erneut aus, und ändern Sie den Namen im Dialogfeld Peripheriegeräte bearbeiten.

Die Nachverfolgung des Aufrufs zu getProvider() zeigt auch den verwendeten Anmeldenamen an. Beachten Sie, dass die Ablaufverfolgung das Kennwort nicht anzeigt. Der Anmeldename und das Kennwort stammen von dem, was der Administrator unter ICM > Setup eingibt. Diese müssen mit einem gültigen Benutzer und Kennwort übereinstimmen, der im Verzeichnis konfiguriert und auf der Webseite "Cisco User Preferences" (Cisco Benutzereinstellungen) verwaltet wurde, damit alle Agentengeräte und Routing-Punkte gesteuert werden können. Überprüfen Sie, ob der Name und das Kennwort in ICM > Setup korrekt sind. Konfigurieren Sie den Benutzer im Verzeichnis so, dass er über die Berechtigung verfügt, nur gültige Agentengeräte und Routing-Punkte zu steuern.

JGW-Protokoll zeigt unbekannten Host an

Der JTAPI GW-Prozess kann die Adresse des Cisco CallManager nicht auflösen. Konfigurieren Sie den Service-Parameter im PIM-Dialogfeld im Setup mithilfe des Cisco CallManager-Hostnamens oder der IP-Adresse. Wenn die Hostnamenkonfiguration für Cisco CallManager korrekt ist, stellen Sie sicher, dass Sie einen Ping an den Cisco CallManager senden können. Wenn nicht, verwenden Sie die IP-Adresse des Cisco CallManager anstelle des Hostnamens.

JGW-Protokoll gibt ein ungültiges Kennwort oder einen ungültigen Benutzer an

Die JTAPI GW meldet sich mit einem Benutzernamen und Kennwort beim globalen Verzeichnis an. Der Benutzername und das Kennwort im PIM-Dialogfeld im Setup müssen mit dem Benutzernamen und dem Kennwort des Benutzers übereinstimmen, der im globalen Verzeichnis auf der Cisco CallManager-Admin-Webseite unter ccmadmin > Benutzer > Globales Verzeichnis konfiguriert wurde.

Wenn der Benutzer nicht vorhanden ist, fügen Sie einen neuen Benutzer hinzu. Aktivieren Sie das Kontrollkästchen CTI Enabled (CTI aktiviert) unten auf der Seite.

Das CTI-Kontrollkästchen auf der Seite für globale Verzeichnisbenutzer nicht aktiviert

Ein Kontrollkästchen auf der Seite für die globalen Verzeichnisse von Cisco CallManager kann die CTI-Berechtigungen für einen PIM- oder IP IVR-Benutzer aktivieren oder deaktivieren. Sie müssen dieses Kontrollkästchen aktivieren und aktualisieren, damit PIM/JTAPI GW aktiviert wird. Durch dieses Kontrollkästchen wird sichergestellt, dass zwei CTI-Geräte keine Verbindung zum Cisco CallManager herstellen können. Dies kann zu Problemen führen (die Standardgrenze ist 400).

Der Cisco CallManager-Dienst wird nicht ausgeführt.

• In Cisco CallManager Version 3 wird dieser Dienst in der Dienststeuerung als "Cisco CallManager" angezeigt. Starten Sie den Dienst.

• Der Cisco CallManager-Service wird normalerweise so eingestellt, dass er neu gestartet wird, wenn er ungewöhnlich beendet wird. Sie können ihn jedoch für mögliche Probleme bei der Migration von Geräten in Failover-Szenarien auf "Aus" konfigurieren.

• Überprüfen Sie im Ereignisprotokoll, ob der Cisco CallManager-Dienst neu gestartet wird. Das System wird manchmal neu gestartet, wenn das System ein Problem mit angemessener CPU-Auslastung feststellt. Das System meldet Fehler oder Warnungen im Ereignisprotokoll, die auf einen "langsamen SDL Timer-Thread" hinweisen. Bei diesem Fehlertyp wird der Cisco CallManager neu gestartet. Diese Version von Cisco CallManager wird mit normaler Priorität ausgeführt, sodass andere auf dem System ausgeführte Anwendungen das Anrufsignal stören können.

• Wenn der physische Speicher kleiner ist oder das System auf andere Zeitprobleme stößt, wird dem Cisco CallManager ein Fehler angezeigt, der anzeigt, dass er nach einem Timeout von 10 Minuten und einem Neustart nicht initialisiert werden konnte. Es gibt einen DCOM-Komponentendienst für die Cisco CallManager-Datenbankebene (DBL), bei dem ein Problem bei der Initialisierung vorliegt. Beenden und starten Sie diesen DBL DCOM-Dienst über Komponentendienste - DCOM-Komponenten, um dieses Problem zu beheben.

  Hinweis: Dies ist nicht dasselbe wie ein Systemdienst wie Cisco CallManager.

  Erstellen Sie ein Ticket beim Cisco Technical Assistance Center (TAC). Dies kann beim nächsten Neustart des Systems wahrscheinlich ein Problem darstellen, es sei denn, Sie lösen das zugrunde liegende Zeitproblem.

Verzeichnisprobleme (Konfiguration, nicht ausgeführt, Verzeichniskennwort)

Verzeichnisdienst wird nicht ausgeführt

• Bestätigen Sie, dass der Verzeichnisdienst ordnungsgemäß ausgeführt wird.  Standardmäßig ist dies der DC Directory Server in der Dienststeuerung auf dem Cisco CallManager-System. Versuchen Sie, den Computer zu starten. Es können Fehler auftreten.

• Der Verzeichnisdienst kann in den Zustand "angehalten" wechseln, wenn dem System der Arbeitsspeicher oder der Speicherplatz ausgeht. Fehler werden im Microsoft Windows 2000-Ereignisprotokoll angezeigt. Beheben Sie Ressourcenprobleme und starten Sie ggf. den Verzeichnisdienst neu.

Die Cisco CallManager-Webseite für Benutzer funktioniert nicht.

Überprüfen Sie, ob die Cisco Global Directory-Benutzerwebseite Benutzer anzeigen und konfigurieren und Steuergeräten Berechtigungen zuweisen kann. Sowohl JTAPIGW als auch die Webseite verwenden den Cisco CallManager, um auf den Verzeichnisserver zuzugreifen und auf Benutzer und Berechtigungen zuzugreifen. Wenn das Problem mit JTAPIGW auf ein Problem mit dem Verzeichnisserver zurückzuführen ist, kann auch die Benutzerwebseite Probleme haben. Mögliche Gründe sind, dass der Verzeichnisserver nicht ausgeführt wird oder das Verzeichnis nicht korrekt konfiguriert ist, wenn überhaupt.

Verzeichnisserver nicht installiert

Um Cisco CallManager 3.0.5 und höher verwenden zu können, müssen Sie einen Verzeichnisserver installieren. Das AVVID DC Directory ist die Standardeinstellung, die auf den Spirian Installations-CDs verfügbar ist. Nach der Installation des Verzeichnisservers konfiguriert die Installation des Cisco CallManager das Verzeichnis.

Sie müssen diese Installation ordnungsgemäß durchführen, und der Verzeichnisserver muss ordnungsgemäß ausgeführt werden, damit sich JTAPIGW beim Cisco CallManager anmelden und JTAPI verwenden kann.

Stellen Sie sicher, dass der DC Directory Service und Cisco CallManager beide ordnungsgemäß ausgeführt werden.

Wenn Sie Cisco CallManager installieren, müssen Sie "ciscocisco" eingeben, wenn Sie die Kennworteingabeaufforderung für den Verzeichnismanager sehen. Wenn Sie noch weitere Informationen eingeben, müssen Sie möglicherweise die DC-Verzeichnissoftware (Hinzufügen/Entfernen) entfernen und neu installieren. Wenn Ihnen der Entfernungsprozess mitteilt, dass einige Dateien nicht entfernt werden können, müssen Sie das aktuelle Verzeichnis c:\dcdsrvr manuell entfernen oder umbenennen.

Verzeichnisserver installiert, wird aber nicht ausgeführt

Überprüfen Sie das Bedienfeld, um zu bestätigen, dass der Dienst nicht starten kann. Überprüfen Sie anschließend, ob der Administrator konfiguriert ist und die Anmeldung und das Kennwort für den Dienst im Feld Eigenschaften korrekt sind.

Verzeichnisserver installiert und ausgeführt, kann sich aber nicht mit dem DCD-Admin-Tool anmelden.

Starten Sie DC Directory Admin über das Startmenü Ihres Systems. Melden Sie sich mit dem Kennwort "ciscocisco" (Standard) oder mit dem vom Administrator konfigurierten Kennwort bei Ihrem Benutzer Directory Manager an. Wenn Sie einen Fehler erhalten, der anzeigt, dass der Benutzer nicht konfiguriert ist, führen Sie eine der Cisco AVVID-Konfigurationsdateien im Verzeichnis DCDSrvr\bin aus. Wenn es sich um den primären Cisco CallManager Publisher handelt, führen Sie avvid_cfg.cmd über die DOS-Eingabeaufforderung aus. Wenn es sich um einen sekundären Cisco CallManager handelt, führen Sie avvid_scfg.cmd über die Eingabeaufforderung aus.

Wenn Sie Fehlermeldungen sehen, die darauf hinweisen, dass dies bereits konfiguriert ist, existiert der Benutzer. Wenn es keine Fehler gibt, müssen die Dinge jetzt richtig funktionieren. Wechseln Sie zurück, und überprüfen Sie den Zugriff von den Seiten für globale Verzeichnisbenutzer auf ccmadmin.

Hinweis: Das DC-Verzeichnis wechselt in den Pausenmodus, wenn das Verzeichnis nicht über genügend Systemressourcen verfügt.

Agent kann sich nicht anmelden

In diesem Beispiel wird eine ICM-Beispielkonfiguration für ein Geräteziel verwendet:

Beispiel für Zielgeräte
Unternehmensname	Agent9782755100
Globale Adresse	Agent9782755100
Konfig.Parm	/devtype CiscoPhone /dn 9782755100

Im folgenden Beispiel wird eine ICM-Beispielkonfiguration für einen Agenten verwendet:

Agent-Beispiel
Peripheriegeräte	CCMPG_PIM1
Peripherienummer	1234
Kennwort	XXX

Wenn Sie ICM > Setup für den PG ausführen, geben Sie die Durchwahllänge des Agenten auf "4" an. In der Beispielkonfiguration ist die Erweiterung für das Beispielgerät also die letzten 4 Ziffern des Parameters /dn (z. B. "5100").

Versuchen Sie, sich bei CTITest anzumelden.

Wenn Sie einen Agenten nicht mit dem Softphone anmelden können, führen Sie den gleichen Vorgang über ctitest aus. Im Folgenden finden Sie eine Beispielliste von Testbefehlen, mit denen Sie sich beim Beispielagenten beim Ziel des Beispielgeräts anmelden können. Diese Befehlsliste setzt voraus, dass der CTI-Server Port 42027 auf dem CTIServerA des Computers abhört. Diese Liste setzt auch voraus, dass das Gerät eine Erweiterung für das Peripheriegerät ist, das als ICM-Peripheriegerät 5000 dargestellt wird.

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

PIM und CTI-Server sind in OPC nicht aktiv.

Verwenden Sie den Befehl opctest "status", und bestätigen Sie die Anzeige von IPCC PIM und CTI-Server in den Zuständen PIM_ACTIVE und CTI_ACTIVE. Die Titelleiste der Protokollfenster des PIM- und CTI-Servers gibt auch den Prozessstatus an.

CTI-Client kann keine Verbindung herstellen

Überprüfen Sie die Einstellungen für die Verbindung mit dem CTI-Server. Die Einstellungen für das Desktop-Softphone befinden sich in der Datei .ini (normalerweise c:\program files\geotel\cti desktop\cticonfig.ini). Zu überprüfende Einstellungen gehören:

• PeripheralID (PeripheralID): Dieser Wert muss mit der Peripheriegerät-ID für das IPCC-Peripheriegerät in Konfigurieren > ICM übereinstimmen.

• SideAHost: Dieser Wert muss der IP-Hostname oder die IP-Adresse von CTI-Server Seite A sein.

• SideBHost: Dieser Wert muss der IP-Hostname oder die Adresse des CTI-Servers auf Seite B sein.  Wenn der CTI-Server einfach ist, können Sie dieses Feld leer lassen.

• SideAPort: Dieser Wert muss mit dem Port übereinstimmen, den der CTI-Server auf Seite A für Verbindungen überwacht. Dieser Wert wird im ICM-Setup für den CTI-Server angegeben. Der CTI-Server zeigt diesen Port in der Titelleiste an und protokolliert diesen Wert beim Start des CTI-Servers. Überprüfen Sie, ob der Client den CTI-Server pingen kann.

Der CTI-Client erhält Fehler. Dieser weist darauf hin, dass der Agent in ACD angemeldet werden muss.

Führen Sie die Datei setup.exe aus, die sich im Verzeichnis \icr\bin auf dem PG/CTI-Server befindet. Wählen Sie die CTI Gateway-Komponente aus. Überprüfen Sie, ob das Kontrollkästchen Agent Login Required deaktiviert ist. Diese Kontrollkästchen sind nicht für IPCC- oder Drittanbieter-Kontrollanwendungen geeignet. Dieses Kontrollkästchen dient zur Überwachung von Anwendungen und anderen ACD-Agenten.

Das PIM-Protokoll zeigt einen dieser Login-Fehler an.

Verwenden Sie procmon für den PIM und "trace tp*", um die Ablaufverfolgung von Drittanbietern zu aktivieren (Groß- und Kleinschreibung beachten). Diese muss die Anmeldeanforderung anzeigen. Überprüfen Sie, ob die Parameter korrekt sind. Das Gerät wird als "Device=" (Gerät) bezeichnet. Dieser Wert muss mit der /dn-Zeichenfolge in der Gerätezielkonfiguration übereinstimmen. Die Agenten-ID lautet "AgentID=". Dieser Wert muss mit der Nummer des Agenten-Peripheriegeräts in Configure/ICM übereinstimmen.

• UNGÜLTIGES_KENNWORT

  Vergewissern Sie sich, dass das Kennwort korrekt ist (das Kennwort kann nicht als Klartext zurückverfolgt werden). Wenn das Kennwort falsch ist, muss das Protokoll den Fehler INVALID_PASSWORD_SPECIFIED aufweisen.

• INVALID_OBJECT

  Gibt an, dass die Konfigurationsparameter im Geräte-Ziel einen ungültigen Gerätetyp enthalten. Dieser Fehler wird mit Leerzeichen zwischen Schlüsselwörtern angezeigt:

  /devtype CiscoPhone /dn 9782755100

• UNGÜLTIG_GERÄT_ZIEL

  Weist darauf hin, dass etwas im Device Target (Zielgerät für Geräte) ungültig ist, höchstwahrscheinlich etwas im Konfigurationsparameter-Feld. Mit dem Dumlog-Dienstprogramm können Sie das PIM-Protokoll zum letzten Mal anzeigen, wenn das PIM neu gestartet wurde. Das Protokoll validiert die Geräteziele und protokolliert Fehler, wenn die Zielkonfigurationszeichenfolgen des Geräts ungültig sind.

Im JGW-Protokoll werden Anmeldefehler angezeigt.

Überprüfen Sie das jgw-Protokoll auf Fehler, die bei Anmeldeversuchen auftreten. Verwenden Sie procmon zum PIM und "trace *TP*", um die Ablaufverfolgung von Drittanbietern zu aktivieren (Groß- und Kleinschreibung beachten). Suchen Sie die Zeile "MsgAddCallObserver: Adresse: XXXX", wobei XXXX die Durchwahl ist, bei der Sie sich anmelden möchten. Bei dieser Durchwahl muss es sich um eine gültige Cisco CallManager-Durchwahl auf einem Gerät handeln, das vom PG-Benutzer gesteuert werden kann. Die Durchwahl muss die richtige Anzahl von Ziffern für das Telefon sein, wie der Cisco CallManager weiß. Das heißt, die Durchwahl muss die Nummer sein, die Sie von einem anderen Telefon im gleichen Cisco CallManager wählen, um das betreffende Telefon zu erreichen.

Gerät nicht in Provider-Domäne

Wenn das jgw-Protokoll eine Ausnahme anzeigt, die anzeigt, dass sich das Gerät nicht in der Provider-Domäne befindet, ist das Telefon nicht dem Benutzer zugeordnet, mit dem sich JTAPI GW anmeldet. Vergewissern Sie sich, dass die Durchwahl am anderen Ende der Liste für die Zuordnung des globalen Verzeichnisses der Benutzergeräte korrekt ist. Stellen Sie außerdem sicher, dass die Gerätenummer nicht zweimal registriert wird. Die gemeinsame Leitungsbelegung ist eine Cisco CallManager-Funktion, die von IPCC nicht unterstützt wird. Sie können versehentlich versuchen, eine gemeinsame Leitungsbelegung mit zwei Telefonen einzurichten, die dieselbe Leitung haben. Wenn Sie eine Zeilennummer ändern, ändern sich die anderen, und PG kann sich nicht beim richtigen Gerät anmelden. Um dieses Problem zu beheben, löschen Sie beide Zeilen, und fügen Sie sie zum Cisco CallManager hinzu.

UNGÜLTIG_SKILL_GROUP_SPEZIFIZIERT

Um sich anzumelden, muss ein Agent in Configure/ICM als Mitglied mindestens einer Kompetenzgruppe (Skill Group Member) konfiguriert werden.

Agent ist bereits an einem anderen Telefon angemeldet

Stellen Sie sicher, dass der Agent (wie die Agentenperipherie-Nummer repräsentiert) nicht bereits bei einem anderen Geräteziel angemeldet ist. Eine Möglichkeit, dies zu überprüfen, besteht darin, Monitor ICR auszuführen und den Bericht Free from Agent für den betreffenden Agenten auszuführen. Wenn der Agent angemeldet ist, wird Ihnen die Ziel-ID des Netzwerks angezeigt, in dem der Agent angemeldet ist. Die Agentendaten werden nur dann im ADB angezeigt, wenn Sie ICM so konfiguriert haben, dass Agentendaten für das Peripheriegerät an dieses AW gesendet werden.

• Sie können dies auch in isqlw gegen die Agent_Real_Time-Tabelle im awdb abfragen. Suchen Sie zunächst das Kompetenzziel für den Agenten (wählen Sie z. B. * aus Agent aus, wobei PeripheralID = XXX und PeripheralNumber = YYY). Überprüfen Sie dann, ob der Agent angemeldet ist (wählen Sie beispielsweise * aus Agent_Real_Time, wobei SkillTargetID = XXX).

• Sie können dies auch überprüfen, wenn Sie eine Verbindung zu procmon mit PIM herstellen und dagent <Agent-Peripherienummer> ausführen.

Geräteziel bereits angemeldet

Stellen Sie sicher, dass das Geräteziel (wie vom Gerät angegeben) nicht bereits über einen anderen Agenten angemeldet ist.

• Eine Möglichkeit, dies zu überprüfen, besteht darin, isqlw mit der Tabelle Agent_Real_Time im WDB auszuführen. Suchen Sie zunächst die Ziel-ID des Netzwerks für das betreffende Geräteziel. Wählen Sie beispielsweise "*" aus Device_Target, wobei ConfigParam "%1003%" entspricht. Überprüfen Sie jetzt, ob das Geräteziel angemeldet ist. Wählen Sie beispielsweise * aus Agent_Real_Time, wobei NetworkTargetID = XXX.

• Sie können dies auch überprüfen, wenn Sie eine Verbindung mit procmon zum PIM herstellen und das Ziel des Geräts auslesen. Es gibt zwei Möglichkeiten, das Geräteziel zu löschen. Der Befehl ddt verwendet eine Netzwerkziel-ID als Eingabe und gibt das Geräteziel aus. Der Befehl adt nimmt die /dn-Zeichenfolge aus der Zielkonfiguration des Geräts als Eingabe und gibt das Geräteziel aus. Wenn z. B. das Geräteziel /dn string /dn 9782755100 ist, wird das Geräteziel als tödlicher 9782755100 ausgewiesen.

Gerät ist nicht mit PG-Benutzer verknüpft

Rufen Sie die Cisco CallManager-Webseite auf, wählen Sie Benutzer/Globales Verzeichnis aus, und suchen Sie die Benutzer-ID, die das PG verwendet. Aktivieren Sie "Associated Devices" (Zugehörige Geräte), und stellen Sie sicher, dass der Benutzer über die Berechtigung zur Steuerung des Geräts verfügt.

• Wenn Sie das Gerät nicht auf der Benutzerseite finden (aktiviert oder deaktiviert), kann es zu Problemen bei der Synchronisierung zwischen der Datenbank (in der der Cisco CallManager die Geräte speichert) und dem Verzeichnisserver (in dem die Geräte gespeichert und Benutzerprofile gespeichert werden) kommen. Überprüfen Sie, ob der Verzeichnisserver (DC Directory Server) ausgeführt wird.

• Überprüfen Sie das Anwendungsprotokoll Windows NT Event Viewer, und suchen Sie im Verzeichnis für Rechenzentren oder Metalink nach Fehlern. Wenn Importfehler auftreten, führen Sie avvid_recfg von c:\dcdsrvr\bin aus.

• Stellen Sie sicher, dass Microsoft Java Virtual Machine (JVM) auf dem Cisco CallManager-System installiert ist. Um dies zu testen, geben Sie jview über eine Eingabeaufforderung ein. Für Cisco CallManager 2.4 müssen Sie JVM manuell installieren. Für Cisco CallManager 3 ist die Plattform Windows 2000 und die JVM-Installation automatisch.

Telefon-Gerät nicht aktiv

Prüfen Sie, ob das Telefon eingeschaltet ist, bei Cisco CallManager registriert ist und Anrufe ohne die Kontrolle durch den Mitarbeiter tätigen und empfangen kann.

Agent kann nicht anrufen

Agent im Status "Not Ready"

Stellen Sie sicher, dass der Agent angemeldet ist und sich nicht im Status "Verfügbar" befindet.  Wenn der Agent nicht verfügbar ist, kann der Mitarbeiter keinen Anruf tätigen. Um einen Anruf zu tätigen, klicken Sie zuerst auf Not Ready (Nicht bereit).

Einstellungen des Agenten-Desks falsch

Wenn nur beim Wählen bestimmter Nummern ein Fehler auftritt, überprüfen Sie diese Nummern von einem physischen Telefon aus, um sicherzustellen, dass Sie sich erfolgreich einwählen können. Wenn Sie einen Nummernplan für das ICM konfiguriert haben, überprüfen Sie, ob die gewählte Nummer mit einer der Platzhalter im Nummernplan übereinstimmt. Überprüfen Sie anschließend, ob der Agent mit den Tischeinstellungen des Agenten den Typ der Nummer wählen kann, die der Nummernplan-Eintrag identifiziert (z. B. International).

Nummernplan für gewählte Nummer im PIM blockiert Zugriff

Der für jedes PIM konfigurierte Nummernplan kann falsch konfiguriert oder korrekt konfiguriert werden, um zu verhindern, dass ein Agent eine bestimmte Nummer anruft. Der Fehler im PIM-Protokoll muss einen Berechtigungsfehler anzeigen. Die Nummern für Agenten und Geräte können sich nicht überschneiden, wenn der gewählte Nummernplan verwendet wird, um Agent-zu-Agent-Anrufe zu tätigen.

Agent führt einen kurzen Anruf durch, muss warten, um einen neuen Anruf zu tätigen

Der Router macht den Agenten nicht verfügbar, wenn der Agent einen Anruf tätigt oder ein Anruf an den Agenten weitergeleitet wird. Dieser Mechanismus ermöglicht dem Router, einen weiteren Anruf an den Agenten weiterzuleiten, bevor der PIM meldet, dass der Anruf eingegangen ist. Einige Netzwerke benötigen mehrere Sekunden, um den Anruf tatsächlich weiterzuleiten. Der Router bricht den Timer nicht basierend auf dem Agentenstatus ab.

Wenn die Zeit, die tatsächlich für die Weiterleitung von Anrufen vom Routing-Client an das PIM benötigt wird, relativ kurz ist, können Sie die konfigurierbare Zeit im Router ändern. Verwenden Sie auf einem der Router in einem DOS-Befehlsfenster rtsetting.exe. Suchen Sie unter Extrapolation > Agent. Die Standardeinstellung ist 10 Sekunden. Wenn der Wert zu kurz ist, leitet der Router Anrufe an Agenten weiter, die gerade einen Anruf erhalten. Dies führt dazu, dass der PIM Anrufe verwirft.

Das Standard-Timeout für PIM beträgt 7 Sekunden. Sie können diesen Wert mit dem Befehl regedt32 ändern. Fügen Sie in diesem Pfad den Schlüssel "AgentReserveTimout" hinzu:

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

Hinweis: Dieser Schlüssel wird dem Setup der Version 4.1.5 hinzugefügt.

Hinweis: Dieser Schlüssel wird hier aufgrund von Platzbeschränkungen über zwei Zeilen angezeigt.

Die PIM-Nummer muss immer ein paar Sekunden niedriger sein als der Router-Extrapolations-Timer, um zu verhindern, dass der Router vor der Verarbeitung des ursprünglichen Ereignisses neue Ereignisse vor dem Anruf an das PIM sendet. Dies verursacht Probleme im PIM.

Wenn der Anruf nach der PIM-Zeitüberschreitung eingeht, wird der Anruf als nicht ACD-basierter Anruf angesehen, und dem Anruf werden keine der Kontextvariablen, Service- oder Kompetenzgruppeninformationen zugewiesen.

Agent kann nicht gehen - nicht bereit, besetzt oder andere

Agent im Status "Aktiv"

Wenn der Agent gerade telefoniert und auf Not Ready (Nicht bereit), Busy (Besetzt) oder Other (Andere) klickt, ändert sich der Agentenstatus nicht sofort. Das ist absichtlich. Der Agent bleibt bis zum Abschluss des Anrufs im Status "Gespräch" oder "Gelöscht". Der Agent wechselt zu Not Ready (Nicht bereit), Work Ready (Arbeitsbereit) oder Work Not Ready (Nicht bereit), je nachdem, welche Taste gedrückt wird. Wenn der Mitarbeiter nach Beendigung des Anrufs sofort zu "Verfügbar" wechselt, müssen Sie die Mitarbeiter-Tischeinstellungen für den Agenten überprüfen und prüfen, ob "Verfügbar nach Eingehend" oder "Verfügbar nach Ausgehend" eingestellt sind. Diese Einstellungen überschreiben die Aufgaben, die der Agent während eines Anrufs mit den Tasten ausführt.

Agenten-Desk-Einstellungen verhindern Umstellungen

Überprüfen Sie die Agententelefoneinstellungen für den Agenten in "Configure ICM" (ICM konfigurieren), und prüfen Sie, ob die Option "Inaktivitätsgrund erforderlich" aktiviert ist. Wenn das Kontrollkästchen aktiviert ist, kann der Support-Mitarbeiter nicht ohne Grund in den Status Not Ready (Nicht bereit) wechseln. Ändern Sie entweder Desktop_Settings.cfg, um die Einstellung für den Agententelefon unter Konfigurieren von ICM zu ändern, oder ändern Sie die Einstellung für den Agentenschreibtisch unter Konfigurieren von ICM.

Wenn dem Agenten keine Agentenschreibeinstellungen zugewiesen sind, kann sich der Agent anmelden und bereit gehen, aber der Agent kann sich nicht abmelden oder abmelden. Die Lösung besteht darin, die Agent-Anwendung zu schließen, eine Agententelefoneinstellung zuzuweisen und sich erneut anzumelden.

Agent muss warten, um nicht bereit zu gehen

Der Router macht den Agenten nicht verfügbar, wenn der Agent einen Anruf tätigt oder ein Anruf an den Agenten weitergeleitet wird. Dieser Mechanismus ermöglicht dem Router, einen weiteren Anruf an den Agenten weiterzuleiten, bevor der PIM den Anruf als empfangen meldet. Einige Netzwerke benötigen mehrere Sekunden, um den Anruf tatsächlich weiterzuleiten. Der Router bricht den Timer nicht basierend auf dem Agentenstatus ab.

Wenn die Zeit, die tatsächlich für die Weiterleitung von Anrufen vom Routing-Client an das PIM benötigt wird, relativ kurz ist, können Sie die konfigurierbare Zeit im Router ändern. Verwenden Sie auf einem der Router in einem DOS-Befehlsfenster rtsetting.exe. Suchen Sie unter Extrapolation > Agent. Der Standardwert ist 10 Sekunden. Wenn der Wert zu kurz ist, leitet der Router Anrufe an Agenten weiter, die gerade einen Anruf erhalten. Dies führt dazu, dass der PIM Anrufe verwirft.

Agent kann nicht gestartet werden

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

Die Daten für die Anmeldeanfrage und die vorbereitete Anfrage sind inkonsistent. Möglicherweise stimmen das Gerät, die Agenten-ID oder die peripheren Nummern nicht überein. Aktivieren Sie die CTI-Serververfolgung mit procmon, und legen Sie die Traces auf 0xf8 fest, um die entsprechenden Traces anzuzeigen. Sie können dies auch in den OPC- oder PIM-Protokollen anzeigen, wenn die Ablaufverfolgung durch einen Drittanbieter (TP) aktiviert ist.

Agent kann sich nicht abmelden

Aktueller Agentenstatus verhindert Anruf

Wenn sich der Mitarbeiter im Status "Work Ready" (Arbeitsbereitschaft), "Work Not Ready" (Arbeitsunfähigkeit) oder "Available" (Verfügbar) befindet, muss der Mitarbeiter zuerst "Not Ready" (Nicht bereit) aufrufen, bevor sich der Mitarbeiter abmeldet. Ändern Sie entweder Desktop_Settings.cfg, um die Einstellungen für den Agentenschreibtisch unter Konfigurieren von ICM zu übernehmen, oder ändern Sie die Einstellung für den Agentenschreibtisch in Konfigurieren von ICM.

Agenten-Desk-Einstellungen verhindern Statusänderungen

Wenn sich der Agent im Status Not Ready (Nicht bereit) befindet und sich immer noch nicht abmelden kann, überprüfen Sie die Agententelefoneinstellungen für den Agenten in Configure ICM (ICM konfigurieren), und prüfen Sie, ob der Abmeldegrund aktiviert ist.

Agent zeigt aktiven Anruf oder Agenten Talking, aber kein Anruf am Telefon

Abmelden Agent Aus und Zurück Ein

Wenn das Softphone einen Anruf anzeigt, der nicht mehr physisch vorhanden ist, kann der Agentenstatus im Gespräch oder Halten festgehalten werden, und der Mitarbeiter kann sich nicht abmelden. Dies kann auf einen Softwarefehler in JTAPI oder dem PIM zurückzuführen sein. Um die Bedingung zu löschen, versuchen Sie zuerst, den Anruf vom Softphone zu löschen, wenn die Entriegelungstaste aktiviert ist. Wenn dies nicht funktioniert, versuchen Sie, den Agenten abzumelden. Wenn die Abmeldetaste nicht funktioniert, beenden Sie das Softphone, und starten Sie es neu. Wenn die Bedingung weiterhin besteht, beenden Sie das Softphone, führen Sie den Task-Manager aus, führen Sie kill geodcs.exe und common~1.exe aus, und starten Sie das Softphone neu. Diese Prozesse können weiterhin ausgeführt werden und sich den ungültigen Agentzustand merken.

Agent im falschen Zustand an PIM

Bei procmon den Status des Agenten am PIM überprüfen. Wenn Sie den Agent-Desktop neu starten und der Zustand nicht klar ist, können Sie weitere Maßnahmen ergreifen. CTI-Server und OPC bieten Mechanismen zum Löschen von Anrufen über die Debugschnittstelle von procmon oder opctest. Dies ist eine leicht bevorzugte Option gegenüber der anderen Option, bei der der PG-Dienst neu gestartet oder zumindest das PIM-Fenster geschlossen werden soll.

Ruft bald nach der Benachrichtigung auf oder wurde festgestellt

Registrierungseinstellungen sind falsch

Bei regedt32 überprüfen Sie die folgenden Registrierungseinstellungen:

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

und

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

Hinweis: Diese Registrierungsschlüssel werden hier aufgrund von Platzbeschränkungen über zwei Zeilen angezeigt.

Legen Sie diese Werte auf 300 bzw. 28800 fest.

Post-Routing funktioniert nicht

Überprüfen Sie das Routen- und Routenskript.

Verwenden Sie das AW Call Tracer-Tool, um zu überprüfen, ob der Anruf beim Skript eingeht und das Skript ordnungsgemäß ausgeführt wird. Führen Sie den Skripteditor aus, und überwachen Sie das Skript. Prüfen Sie die Router-, OPC- und PIM-Protokolle auf Probleme. Die meisten Routenfehler werden bedingungslos zurückverfolgt.

'Benutzen Sie die DN-Label-Karte', die auf den Routing-Client des Peripheriegeräts geprüft wurde.

Für jeden Routing-Client gibt es eine Einstellung in Konfigurieren ICM mit der Bezeichnung "Use DN/Label Map" (DN/Label-Zuordnung verwenden). Wenn diese Einstellung auf "Yes" (Ja) gesetzt ist, müssen Sie für jede Kombination aus gewählter Nummer und möglichem Ziellabel einen Eintrag für die "Dialed Number Label" (Label für gewählte Nummer) konfigurieren. Diese Einstellung ist für PG-Routing-Clients nicht sinnvoll und muss auf "Nein" eingestellt werden.

Für geroutetes Geräteziel ist kein Label konfiguriert

Überprüfen Sie das Label, das auf dem Routing-Client konfiguriert wurde. Sie müssen Label auf jedem Client konfigurieren, auch wenn das Label auf jedem Client identisch ist.

Der CTI-Routenpunkt ist für Cisco CallManager nicht konfiguriert.

Um Post Routing verwenden zu können, müssen Sie im Cisco CallManager einen "CTI-Routenpunkt" konfigurieren und dem Routing-Punkt eine Leitung mit der gewünschten Verzeichnisnummer zuweisen (z. B. "5000"). Verwenden Sie für Agentenanrufe zur Post-Routing-Weiterleitung den Nummernplan. Ein Agent, der an den CTI-Weiterleitungspunkt von Cisco CallManager wählt, verwechselt das IPCC-Softphone in CTI Desktop Version 4.1.9.

Gerät für CTI-Routing-Point steht nicht auf der Liste der Geräte, die vom PG-Benutzer gesteuert werden

Sie müssen das CTI-Routenpunkt-Gerät der Liste der "Associated Devices" (Zugehörige Geräte) für den PG-Benutzer auf der Cisco CallManager-Benutzerwebseite im globalen Verzeichnis hinzufügen. Wenn Sie ein neues Gerät erstellen, fügen Sie zunächst die Zeile(n) hinzu, und fügen Sie das Gerät dann der Benutzerliste "Associated Devices" (Zugeordnete Geräte) hinzu. Wenn Sie einem Gerät, das bereits in der Liste der Benutzergeräte enthalten ist, weitere Zeilen hinzufügen, müssen Sie den JGW neu starten, damit der JGW die neuen Zeilen erkennt. Wenn Sie jedoch ein neues Gerät hinzufügen, dem Gerät eine Leitung hinzufügen und das Gerät der Liste der Benutzergeräte hinzufügen, muss das JGW das neue Gerät erkennen können (innerhalb von etwa 30 Sekunden).

Für Cisco ICM ist keine gewählte Nummer konfiguriert.

Überprüfen Sie die gewählte Nummer, um sicherzustellen, dass die Nummer für den Peripherieleitungs-Client konfiguriert ist. Führen Sie procmon zu JGW aus, und aktivieren Sie die Ablaufverfolgung als "trace *ROUTE*" (Groß- und Kleinschreibung beachten). Überprüfen Sie das JGW-Protokoll auf Fehler, die sich auf die gewählte Nummer beziehen. Beim Start versucht JGW, einen Rückruf für die gewählte Nummer für die Route zu registrieren. Wenn die gewählte Nummer angerufen wird, erhält das Gateway ein "RouteEvent".

Überprüfen Sie zusammen mit der gewählten Nummer, ob der Anruftyp erstellt und dem Skript richtig zugeordnet wurde.

Überprüfen Sie, ob der Neustart von JGW nicht erforderlich ist.

Wenn Sie eine gewählte ICM-Nummer konfiguriert haben, den CTI-Routenpunkt eingerichtet haben und diese zur Liste der Benutzergeräte hinzugefügt haben, Sie jedoch immer noch keine Routenanfragen erhalten, wenn die Nummer gewählt wird, müssen Sie möglicherweise den JGW neu starten (oder den PG neu starten). Sie müssen nur neu starten, wenn Sie die Ablaufverfolgung in JGW aktiviert haben (verfolgen Sie *ROUTE*) und Sie Fehler sehen, die zeigen, dass die Adresse nicht im Anbieter ist. Im Allgemeinen muss das JGW neue CTI-Routenpunkte erkennen können, die der Liste der Benutzergeräte hinzugefügt werden, ohne dass ein Neustart erforderlich ist. Wenn einem bereits vorhandenen CTI-Routenpunkt Posten hinzugefügt werden, erkennt der JGW diese auch ohne Neustarten nicht. Sie müssen einen Neustart vermeiden können, wenn Sie einen neuen CTI-Routenpunkt für jede gewählte Nummer anstelle neuer Leitungen zu bereits vorhandenen Geräten hinzufügen.

Hinweis: Dabei wird davon ausgegangen, dass DeviceListPolling in der JTAPI.ini-Datei im Verzeichnis winnt\java\lib im PIM aktiviert ist. Wenn DeviceListPolling deaktiviert ist, müssen Sie DeviceListPolling aktivieren. Wenn DeviceListPolling deaktiviert ist und Sie ein Gerät zur Benutzerliste hinzufügen, müssen Sie den PG oder mindestens JTAPI GW aus- und wieder aktivieren, damit das neue Gerät angezeigt wird.

OPC-Protokolle für Weiterleitungsdialogfelder überprüfen

Verwenden Sie opctest, um die Routenverfolgung "debug /routing" zu aktivieren und die OPC-Protokolle auf Fehler zu überprüfen, wenn Anrufe an den Routenpunkt getätigt werden. Überprüfen Sie, ob Routenanfragen empfangen und Labels zurückgegeben werden. Die Routenanforderungen werden als "CSTA_ROUTE_REQUEST"- und "ICR_NEW_CALL_REQ"-Meldungen angezeigt. Die zurückgegebenen Labels werden als "ICR_CONNECT"-Meldungen angezeigt. Wenn Fehler auftreten, werden statt ICR_CONNECT-Meldungen "ICR_DIALOG_FAIL" angezeigt. Überprüfen Sie in diesem Fall das Router-Protokoll auf Fehler.

Routerprotokolle nach Routendialogen überprüfen

Verwenden Sie rtsetting.exe, um die Routenverfolgung zu aktivieren und Routerprotokolle auf Fehler zu überprüfen, wenn Anrufe an den Routenpunkt getätigt werden.

Stellen Sie sicher, dass alle erforderlichen Labels konfiguriert sind. Wenn Ihr Routing-Skript auf IPCC/EA-Agenten abzielt, müssen für den Post Routing-Client für jedes Zielgeräteziel Labels konfiguriert sein.

Routing-Skript löscht Anrufe nicht, wenn der Agent verfügbar wird

Überprüfen Sie das Router-Protokoll auf Fehler. Wenn keine vorhanden ist:

Kein Fehler im Routerprotokoll - Warteschlangenknoten wird zur Qualifikationsgruppen-Basispriorität in Warteschlange gestellt

Wenn der Warteschlangenknoten der Basispriorität in die Warteschlange gestellt wird, passiert nichts, wenn der Agent verfügbar wird. Es gibt zwei Möglichkeiten, dieses Problem zu beheben:

• Es gibt eine Router-Registrierungseinstellung namens AutoLoginBase (verwenden Sie rtsetting.exe). Ändern Sie diese Einstellung, damit der Anruf in die Warteschlange der Basiskill-Gruppe gestellt wird, um mehr oder weniger wie erwartet zu funktionieren. Bei dieser Art von Warteschlange ist Primär- und Sekundäreinrichtungen nicht vorzuziehen.

• Legen Sie die Warteschlange explizit für die primären und/oder sekundären Skill-Sets im Warteschlangenknoten fest.

Router-Protokoll zeigt an, dass Label nicht für Ziel konfiguriert ist

Konfigurieren Sie das Label für das betreffende Geräteziel und alle anderen Ziele, an die dieser Routing-Client weiterleiten kann. Verwenden Sie das AW-Bulk-Konfigurationstool, um dies über die ICR-Konfiguration effizienter zu machen.

Rufen Sie keine Antwort ab, wenn alle Agenten und Warteschlangen-Ports besetzt sind.

Router-Protokolle überprüfen

• Routenfehler müssen bedingungslos zurückverfolgt werden.

• Sie können das Call Tracker-Tool verwenden, um den Routenpfad zu testen.

• Verwenden Sie trtratrace, um die Routenanforderungs-Nachverfolgung zu aktivieren und Router-Protokolle auf Fehler zu überprüfen, wenn Anrufe an den Routing-Punkt getätigt werden.

• Stellen Sie sicher, dass alle erforderlichen Labels konfiguriert sind. Wenn das Routing-Skript auf IPCC/EA-Agenten abzielt, müssen für jedes Zielgeräteziel Labels konfiguriert sein. Für jedes Geräteziel müssen Labels für jeden Route-Client konfiguriert sein, der versucht, Anrufe zu senden. Wenn also ein Anruf direkt vom Netzwerk an einen verfügbaren Agenten weitergeleitet wird, muss der Netzwerk-Routing-Client über ein Label für das zugehörige Geräteziel verfügen. Wenn der Anruf zuerst an einer VRU in die Warteschlange gestellt und dann an den Agenten weitergeleitet wird, muss der VRU-Routing-Client über ein Label für das zugehörige Geräteziel verfügen.

Vergewissern Sie sich, dass die DN-Labelzuordnung im Routing-Client unter Konfigurieren von ICM deaktiviert ist.

Vergewissern Sie sich, dass im Konfigurations-Manager/PG-Explorer auf der Registerkarte Routing-Client die Option DN/Label-Zuordnung verwenden nicht aktiviert ist.

PIM-Protokolle überprüfen

• Verwenden Sie procmon, um die Ablaufverfolgung im PIM (Ablaufverfolgungsprotokoll, Nachverfolgung *call_event*) zu aktivieren und Protokolle zu überprüfen. Die Anrufnachricht wird vom Router aus angezeigt. Es wird auch "DeliveredEvent" angezeigt, bei dem "DevTgDevStr" auf die Agentenerweiterung festgelegt ist. Wenn der Anruf nicht angezeigt wird, stellen Sie sicher, dass das Label für den Routing-Client korrekt ist.

Uneinheitliche Ergebnisse bei willkürlichen Übertragungen

IPCC bietet keine Unterstützung für die Option, einen Anruf zu halten und einen neuen Anruf zu tätigen, da der Cisco CallManager inkonsistente Ergebnisse liefert. Dies gilt als Produkterweiterung und kann für eine zukünftige Version in Betracht gezogen werden.

Alternative funktioniert nicht

Wenn ein Beratungsgespräch geschaltet/gewechselt/gehalten/abgerufen wird, unterbricht Cisco CallManager die konsultierende Zuordnung. Dies führt zu einem willkürlichen Transferszenario, das nicht unterstützt wird. Support-Mitarbeiter können erneut eine Verbindung zum Kunden herstellen und einen neuen Kundenberater starten. Das IPCC-Softphone deaktiviert die alternative Taste, bis sie gelöst ist. Drittanbieter können sich jedoch beschweren.

Konferenzteilnehmer kann keine Konferenz mit einer anderen Partei abhalten

Cisco CallManager hat eine Einschränkung, dass nur der Initiator der Konferenz weitere Teilnehmer zur Konferenz hinzufügen kann. Andere Parteien können dem Cisco CallManager keine weiteren Teilnehmer hinzufügen.

Unerwartete Abmeldung der Agenten-Station

Agent Desk-Einstellungen Inaktivitäts-Timer

In den Einstellungen für den Agenten-Desk gibt es eine Zeiteinstellung, um Agenten im Status Not Ready (Nicht bereit) abzumelden. Die maximale Inaktivitätszeit beträgt 2 Stunden, Sie können jedoch festlegen, dass die Zeit geringer ist. Agenten im Status "Verfügbar" werden nicht abgemeldet, wenn sie sich im Inaktivitätszustand befinden. Der Agent wechselt von "Ready" zu "Not Ready", wenn der Timer für "Ring no Answer" abläuft (ebenfalls eine konfigurierbare Agent-Schreibtischeinstellung).

Taktzeit des CTI-Servers

Der CTI-Server verfügt über eine konfigurierte Taktzeit. Ältere Computer, überarbeitete CTI-Server oder Netzwerke mit Bandbreitenproblemen können die Ursache sein. CTI-Serverprotokolle müssen einen Fehler im Protokoll melden.

Der Agent verhält sich nicht wie in den Agent Desk-Einstellungen konfiguriert.

Die Agententelefoneinstellungen in Configure ICR(M) und die Agentenkonfigurationsdatei müssen beide vereinbaren, wie der Agent behandelt wird.

In der Peripheriekonfiguration auf ICM in Konfigurationsparametern befindet sich ein Arbeitszeitgeber. Legen Sie die Parameter als \WORKTIMER 30 fest, um eine Verzögerung von 30 Sekunden für die automatische Verfügbarkeit festzulegen.

Die Desktop-Konfigurationsdatei befindet sich in:

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

Der Arbeitsmodus für "Eingehend" muss auf "Erforderlich" gesetzt sein, nicht auf "Erforderlich" mit "Daten" in Desk_Settings.cfg und in den Einstellungen für den Agenten "ICR(M) konfigurieren". Erforderlich mit Daten ersetzt die automatisch verfügbare Option.

Übermittlung von Beratungsgesprächen fehlgeschlagen

Überprüfen Sie im JTAPI GW-Protokoll, ob Fehler vorliegen, die den Grund für den Fehler bei der Weitergabe angeben. Prüfen Sie, ob die Agent-Software den Halten/Abrufen oder alternativen Betrieb des Beratungsanrufs zulässt. Wenn ein Anruf gehalten/abgerufen wird, wird der Anruf nicht mehr als beratend, sondern als "willkürliche" Weiterleitung durch den Cisco CallManager angesehen. Der Cisco CallManager hat Probleme mit willkürlichen Übertragungen. Beschränken Sie den Benutzer, bei einem Beratungsgespräch erneut eine Verbindung herzustellen oder die Weiterleitung abzuschließen.

Berater reagiert nicht mehr, aber die Anrufanzeige verschwindet nicht

Der Cisco CallManager hat derzeit Probleme mit einer Disconnect-Veranstaltung für eine durch eine Konferenz initiierte Beratung, wenn die Konferenz nicht abgeschlossen ist. Trennen Sie das Gespräch ein zweites Mal, um die Anruffunktion am Agententelefon zu löschen.

Die Übersetzungsroute zur VRU funktioniert nicht.

Überwachen Sie zuerst das aktive Skript. Überprüfen Sie dann die Router-, OPC- und PIM-Protokolle des Routing-Clients und der VRU. Die meisten Fehler werden bedingungslos zurückverfolgt, aber Sie können die Nachverfolgung aufschalten, um ein besseres Bild von dem zu bekommen, was passiert.

Die Übersetzungsreihenfolge sieht folgendermaßen aus:

• Der Routing-Client stellt eine neue Anrufanfrage an den Router.

• Der Router gibt eine Verbindung zum Routing-Client mit einem Label zurück, das den Anruf an die IVR weiterleiten muss.

• Der IVR muss dann eine RequestInstruction senden, die der VRU PG zum Nachschlagen des peripheren Ziels verwendet.

• Der Router stimmt die Peripheriegeräte der Anforderungsanweisung mit den Zielvorgaben für das Peripheriegerät überein, auf die er wartet.

• Das Routing-Skript wird mit vom Kunden entworfenen Skript- oder Warteschlangenknoten fortgesetzt.

Überwachen Sie das aktive Skript, um den Fehlerpfad zu finden. Suchen Sie in der Router-Ablaufverfolgung nach Fehlern. Überprüfen Sie, ob der Routen-Client anfängliche Labels empfängt. Überprüfen Sie, ob die VRU den Anruf empfängt. Überprüfen Sie, ob die VRU eine Anforderungsanweisung auf VRU PIM- oder OPC-Ebene sendet.

Die Routenanforderung führt im Routenskript nicht zum Knoten "Übersetzungsroute zur VRU".

Überwachen Sie das Skript, und überprüfen Sie, ob die Anforderung zur Übersetzungsroute zum VRU-Knoten gelangt.

Zunächst reicht im Routing-Skript ein ausgewählter oder route select-Knoten mit einer ausgewählten Übersetzungsroute nicht aus, um die Route zum servicesteuerung VRU zu übersetzen. Es ist eine Übersetzungsroute zum VRU-Knoten erforderlich.

Zweitens muss der Monitor zeigen, dass der Anruf zum Übersetzungsrouten-Knoten gelangt. Ein Fehler bedeutet, dass eine Übersetzungsroute nicht bestimmt werden kann oder die Anforderungsnachricht für die RequestInstruction-Route nicht vom IVR empfangen wurde.

Timeout für Übersetzungsrouten im Routerprotokoll

Der Timeout-Fehler bei der Übersetzungsroute weist darauf hin, dass der Router die Anforderungsanweisung nicht erhält. Überprüfen Sie den OPC und den VRU-PIM auf Fehler, und überprüfen Sie, ob die RequestInstruction-Methode eintrifft.

Schalten Sie "Translation Routing" und "Netzwerk-VRU-Ablaufverfolgung" mit dem Trace-Tool auf dem Router ein, um besser zu erkennen, was im Router auftritt. Aktivieren Sie im VRU PG OPC die Dienststeuerungs-Reporting-Funktion mit opctest.

VRU-PIM-Protokoll zeigt an, dass DNIS nicht auf Trunk-Gruppe X gefunden wurde

Die Anforderungsanweisung muss eine gültige Trunk-Gruppe angeben, die einer Trunk-Gruppe-Peripheriegerätnummer in einer der für den VRU PG konfigurierten Trunk-Gruppen zugeordnet ist. Den VRU PG aus- und wieder einschalten, um die Aktualisierung der Peripheriegeräte der Trunk-Gruppe zu erhalten, falls diese geändert wurden.

ICM-Konfiguration überprüfen

Stellen Sie sicher, dass die DN-Labelzuordnung im IVR PG-Routing-Client deaktiviert ist. Der IVR PG benötigt eine Netzwerk-VRU-Zuweisung. Das Netzwerk-VRU muss Typ 2 sein. Dem IVR PG muss eine Netzwerk-Trunk-Gruppe und eine Trunk-Gruppe zugewiesen sein. Verweisen Sie auf die Netzwerk-Trunk-Gruppe in der Trunk-Gruppe.

Der NIC/Post-Routing-PG muss über ein Label für jeden DNIS in den peripheren Zielen verfügen. (Weisen Sie im Übersetzungs-Routing-Assistenten für die Anforderung des Routing-Clients die gleichen Etiketten wie der DNIS an. Sie können dies im Präfix einrichten und die Option prefix = DNIS auswählen.)

Der VRU-Routing-Client benötigt ein Label, das für das Geräteziel konfiguriert ist, an das er geleitet wird, sobald ein Agent verfügbar ist.

Fehlerbehebung bei der Cisco IP IVR - ICM-Schnittstelle

Dieser Abschnitt zu Cisco IP IVR behandelt die Fehlerbehebung bei Konfigurationsfehlern zwischen IP IVR und ICM und enthält häufige Probleme bei der Einrichtung von IVR PG-Postrouting und Übersetzungsrouting. Weitere Informationen zu allgemeinen IVR-Fehlern finden Sie im Cisco IP IVR-Fehlerbehebungshandbuch.

Im Allgemeinen überprüfen Sie die MIVR-Protokolle unter der Webseite appadmin > Engine > Trace files.

• In Cisco CallManager, IVR und ICM konfigurierte IVR-CTI-Ports und CTI-Routenpunkte.

• IVR-CTI-Ports und CTI-Weiterleitungspunkte sind IVR-Benutzern im globalen Cisco CallManager-Verzeichnis zugeordnet.

• Das Kontrollkästchen für die Servicesteuerung ist in der IVR ICM-Konfiguration aktiviert.

• Skriptnamen in IVR-Skriptdefinitionen stimmen mit Netzwerk-VRU-Skriptnamen in ICM überein.

• Die Trunk-Gruppennummer im VRU PG stimmt mit der CTI-Port-Gruppennummer in IP IVR überein.

Übersetzungsroute ist fehlerhaft

Zusammen mit allen anderen Maßnahmen, die Sie zur Fehlerbehebung verwenden, können Sie diese Schritte auch zur Fehlerbehebung für IP IVR ausführen.

• Überprüfen Sie das MIVR-Protokoll. Dieses Protokoll kann im Allgemeinen auf Problembereiche verweisen.

• Verwenden Sie Debug-Einstellungen, um Cisco IP IVR zu aktivieren: SS_TEL und LIB_ICM.

• Aktivieren Sie das Cisco Jtapi-Protokoll für IP IVR mit Jtprefs auf der IP IVR. Siehe Debugtools. Beenden und starten Sie die IP IVR-Engine, nachdem Sie die Ablaufverfolgung aktiviert haben.

• Überprüfen Sie, ob die CTI-Port-Gruppennummer in der IP IVR JTAPI-Portgruppe für die Übersetzungsroute mit der Peripherienummer in der Trunk-Gruppenkonfiguration im ICM übereinstimmt.

Skript wird nicht wiedergegeben oder gibt Fehlermeldung aus.

Prüfen Sie die IP-IVR-Protokolle unter Engine-Trace-Dateien, um zu überprüfen, ob:

• Skript ausführen wird empfangen.

• IP IVR kann Skripts finden. Laden Sie Skripts mit dem Repository Admin-Tool hoch.

• IP IVR kann Eingabeaufforderung finden. Benutzerdefinierte Eingabeaufforderungen befinden sich in \wfavvid\prompts\ user\en_us\ der IP-IVR.

JTAPI-Status zeigt Teildienst an

Dies bedeutet in der Regel, dass einige der CTI-Ports oder CTI-Routenpunkte, die in der IP-IVR konfiguriert wurden, nicht konfiguriert wurden und/oder dem IP-IVR-Benutzer im Cisco CallManager zugeordnet sind.

Dies kann auch bedeuten, dass die Skripte nicht korrekt benannt wurden oder nicht in den Repository Manager hochgeladen wurden.

Der ICM-Status auf IP IVR zeigt einen partiellen Status an.

Im Allgemeinen weist diese Bedingung auf eine teilweise Konfiguration oder eine nicht übereinstimmende Konfiguration auf der einen oder anderen Seite hin.

Hinweisen der stotternden Eingabeaufforderung, wenn ein Anruf vom Router aus in die Warteschlange gestellt wird

Dies ist ein falsch konfiguriertes Routing-Skript, das zu wenig Zeitüberschreitung in der Konfiguration des Netzwerk-VRU-Skripts in Konfigurieren ICR ermöglicht.

Einige der Skripts, die mit der IP IVR für die ICM-Schnittstelle verfügbar sind, laufen sehr lange, aber die Standardzeitüberschreitung in der ICM-Netzwerkskriptkonfiguration beträgt drei Minuten. Wenn das Skript das Timeout überschreitet und der Pfad für das Ausführen des Skripts ein anderes Laufskript wiedergibt, werden diese Laufskripts im Prinzip in die Warteschlange des IVR gestellt. Wenn die Skripte in die Warteschlange gestellt werden, hören Sie, wie viele Skripte sich übereinander abspielen.

Fehlerbehebung bei IVR-Servicestatistiken

IVR-Statistiken sind für IPCC-Service-Level-Berichte wichtig. Aus diesem Grund finden Sie hier einige Informationen zur Fehlerbehebung. Als Übersicht werden die Änderungen im Router und im VRU PG, bei dem implementierte Anrufe in der VRU in die Warteschlange gestellt werden, anstatt als verbunden gezählt. Wenn Anrufe weitergeleitet werden, werden sie als beantwortet gemeldet. Wenn der Kunde in der Warteschlange Anrufe beendet, werden diese als abgebrochen gemeldet. Weitere Informationen finden Sie in der Readme.txt-Datei der Hotfixes 53 und 54. Der Router sendet spezielle Warteschlangenereignisse, die angeben, in welchem Zustand sich der Anruf am Router befindet.

Im VRU-PIM ist eine spezielle Registrierung vorhanden. Sie müssen diese Funktion daher freiwillig aktivieren, um eine minimale Unterbrechung sicherzustellen.

Der Enterprise Service Real Time Report 10 nutzt diese Daten besonders, wenn Sie einen oder mehrere Peripheriegeräte mit einem oder mehreren VRU-Service(s) und Cisco CallManager PG-Diensten versehen. Der Enterprise Service Real Time Report erfordert, dass VRU PG- und Cisco CallManager PG-Services zu Berichtszwecken in einem Enterprise-Service gruppiert werden.

Weitere hilfreiche Warteschlangenberichte sind die neuen Anruftypberichte für Echtzeit- und Verlaufsdatensätze, und das Echtzeit-Raster für Kompetenzgruppen zeigt jetzt Anrufe an, die für die Kompetenzgruppe in Warteschlangen gestellt wurden.

Es werden keine Servicestatistiken oder Terminierungsaufzeichnungen für Anrufdetails erstellt.

VRU PIM generiert keine CSTA-Ereignisse. Aktivieren Sie die Dienststeuerungs-Reporting-Funktion in der VRU PG-Einrichtung. Dies befindet sich im Registrierungsschlüssel in ServiceControlQueueReporting unter:

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

Hinweis: Dieser Registrierungsschlüssel wird hier aufgrund von Platzbeschränkungen über zwei Zeilen angezeigt.

Die VRU meldet alle Anrufe als verbunden, nicht als angefordert in Warteschlange gestellt

ServiceControlQueueReporting-Registrierungsschlüssel wurde nicht zugeordnet oder nicht auf 1 festgelegt

Das Systemstartprotokoll für VRU PIM muss sich beschweren, wenn es nicht vorhanden ist.

Fügen Sie den ServiceControlQueueReporting-Schlüssel hinzu, und legen Sie den Wert auf 1 in:

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

Hinweis: Dieser Schlüssel wird hier aufgrund von Platzbeschränkungen über zwei Zeilen angezeigt.

Anrufe werden mit falschem Service gezählt oder werden in Serviceberichten nicht angezeigt.

OPC-Protokoll zeigt an, dass die Servicezuordnung nicht gefunden wurde.

Das OPC-Protokoll weist darauf hin, dass die Servicezuordnung nicht gefunden wird, wenn Anrufe mit dem falschen Service angerechnet werden oder nicht in Serviceberichten angezeigt werden.

Cisco ICM-Reporting-Probleme

Cisco ICM ist nicht für die einfache Korrelation von Daten-Anruftypen, -Services und -Kompetenzgruppen ausgelegt. Die Zahlen haben in der Regel eine leicht unterschiedliche Bedeutung in jeder Gruppe. Es gibt nur einen Service für einen Anruf, aber es können zwei Qualifikationsgruppen vorhanden sein, wenn mehr als ein Mitarbeiter involviert ist. Die Funktion "Redirect on no Answer (RONA)" (Umleitung bei Nichtantwort) generiert ohne die Generierung eines weiteren Terminierungsdatensatzes wahrscheinlich eine weitere Postroute.

Agenten-Kompetenzgruppe, Kompetenzgruppe, Service, Anruftypnummern nicht ausgleichen

• Symptom: Anrufe, die verarbeitet werden, oder andere statistische Felder stimmen nicht mit den Berichten zu Service, Anruftyp und/oder Qualifikationsgruppe überein.

• Bedingung: Anruftyp, Service und Kompetenzgruppen werden mit einer logischen Zuordnung zueinander eingerichtet, Berichte stimmen jedoch immer noch nicht genau überein.

• Fehlerbehebung: Wenn das Anrufvolumen weniger als einen Anruf pro Sekunde beträgt, aktivieren Sie die Ablaufverfolgungseinstellungen in OPC, PIM und JTAPI GW, je nach CSTA-, PIM-, AGENT- und Drittanbieterereignissen. Anweisungen hierzu finden Sie im Abschnitt Tools dieses Dokuments.

• Dokumentieren des Anrufflusses:

  • Ist die erste POST-Route auf dem Cisco CallManager PG oder VRU PG?

  • Ist "Forward on no Answer (FONA)" konfiguriert, und auf was ist FONA für die Umleitung konfiguriert?

  • Ist eine standardmäßige Skill-Gruppe mit der Peripherienummer 0 konfiguriert, um geroutete Anrufe von nicht weitergeleiteten und ausgehenden Anrufen zu trennen?

Ziehen Sie die Verlaufsdaten aus diesen Tabellen für einen Tag mit den Aussagen "Select *" (Auswählen *) in Anspruch:

• Peripherie_Half_Stunde

• Anruftyp_Half_Stunde

• Service_Half_Stunde

• Skill_Group_Half_Stunde

• Terminierung_Anruf_Detail

• Route_Call_Detail

Fehlerbehebung bei Cisco CallManager

Wenn Sie die Traces in Cisco CallManager erfassen, können Sie die Flags auf der Cisco CallManager-Admin-Seite unter Services > Trace Flags (Services > Trace Flags) umschalten. 0xCB05 ist ein gutes Trace-Flag für die SDL-Nachverfolgung von CTI-Fehlern. Legen Sie 0xCB05 unter Service-Parameter für Debugzwecke fest. Siehe AVVID TAC Cases: Sammeln von Informationen zur Fehlerbehebung für weitere Informationen. Weitere Informationen finden Sie in der Online-Dokumentation zu Cisco CallManager, einschließlich Anleitungen zur Fehlerbehebung.

Aktivieren Sie die Ablaufverfolgung für Cisco CallManager.

Weitere Informationen zum Aktivieren der Ablaufverfolgung für Cisco CallManager finden Sie unter Einrichten von Cisco CallManager Traces für den technischen Support von Cisco.

IP-Adressen von Cisco CallManager ändern

Weitere Informationen finden Sie unter Ändern der Cisco CallManager-IP-Adressen und Ändern des Servernamen.

1. Führen Sie das Setup für Cisco CallManager PG aus, und ändern Sie die JTAPI-Services für den Cisco CallManager PIM. Wenn Sie über Durchwahlmobilität und/oder Telefondienste verfügen.

2. CRA-Engine stoppen.

3. In CRA - Ändern Sie die IP-Adresse unter Engine Configuration.

4. Ändern Sie die IP unter JTAPI.

5. Beenden Sie den DC-Verzeichnisdienst auf dem Server.

6. Ändern der IP-Adresse in der Verzeichniskonfiguration

7. Ändern Sie in Cisco CallManager die IP-Adresse unter System > Server.

8. Ändern Sie die IP-Adresse in URLs unter System > Enterprise Parameters.

9. Ändern Sie die IP-Adresse in allen URLs unter Funktionen > Telefondienste.

10. Ändern der Server-IP-Adresse - Netzwerkeigenschaften.

11. Ändern Sie die DHCP-Option 150 in eine neue IP-Adresse.

12. Ändern Sie die IP im Hotelprofil im Rechenzentrumsverzeichnis, Cisco CallManager > Systemprofil > Hoteling.

13. Öffnen Sie SQL Enterprise Manager.

14. Ändern Sie die IP-Adressen in URLs in der PlugIn-Tabelle.

So sichern Sie Ihre Konfigurationsänderungen:

1. Öffnen Sie die stiBackup-Konfiguration.

2. Ändern Sie die Server-IP-Adressen unter allen entsprechenden Registerkarten.

Debugtools

Procmon

Procmon ist ein Befehlszeilentool, mit dem Sie PIM- und JTAPI GW-Prozesse debuggen können.

• Verwendung: procmon <Kundenname> <Knoten>-Prozess.

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcc cg1a ctisvr

Hier einige nützliche Ablaufverfolgungseinstellungen für die einzelnen Prozesse:

• JTAPI GW (Verwendung von procmon)

  • trace JT_TPREQUESTS (schaltet Drittanbieteranforderungsverfolgungen ein)

  • trace JT_JTAPI_EVENT_USED (schaltet Ablaufverfolgungen für die JTAPI-Ereignisse ein, die das PG verwendet)

  • trace JT_PIM_EVENT (aktiviert Ablaufverfolgungen für an PIM gesendete Ereignismeldungen)

  • trace JT_ROUTE_MESSAGE (schaltet Routing-Client-Traces ein)

  • trace JT_LOW* (Traces basierend auf den zugrunde liegenden JTAPI- und CTI-Layern)

• PIM (Verwendung von procmon)

  • trace tp* (aktiviert Nachverfolgungen von Drittanbieteranfragen)

  • Ablaufverfolgungsprotokoll (Schalten von Vorfeld-Ereignisspuren)

  • trace *event (schaltet Agent- und Anrufereignisspuren ein)

  • trace csta* (aktiviert CSTA-Anrufereignisspuren)

• CTI-SERVER (Verwendung von procmon)

  • regset EMSTraceMask 0xf8 (aktiviert nützliche CTI-Server-Ablaufverfolgungen, die sich wahrscheinlich umwickeln lassen)

OPCtest

Opctest ist ein Befehlszeilentool zum Debuggen des OPC-Prozesses auf dem PG.

• Verwendung: opctest /cust <Kundenname> /node <knoten>

  • opctest/cust ipcc/node pg1a

• Nützliche Einstellungen

  • debug /agent (schaltet Agent-Ereignisverfolgungen ein)

  • debug/routing (schaltet Routing-Ereignisverfolgungen ein)

  • debug /cstacer (schaltet csta event traces ein)

  • debug /tpmsg (aktiviert Anrufanforderungsverfolgungen von Drittanbietern)

Neuheit

RTEST ist ein Befehlszeilenschnittstellen-Tool zum Debuggen des Routerprozesses auf dem ICM. Die GUI-Version finden Sie unter rtrtrace.

• Verwendung: rtest /cust ipcc

rtsetting.exe

GUI-Tool zum Ändern der Router-Registrierungseinstellungen

• Es besteht die Möglichkeit, die Einstellungen wieder auf die Standardeinstellungen zurückzusetzen.

rtrtrace.exe

GUI-Tool zum Aktivieren verschiedener Router-Traces auf dem ICM.

• Einstellungen, die besonders für IPCC nützlich sind, sind:

  • Warteschlangenverwaltung - bei Problemen mit der Warteschlangenverwaltung.

  • Servicesteuerung - bei Problemen mit der VRU-Schnittstelle.

  • Übersetzungsrouting - bei Problemen mit Übersetzungsrouten.

Dumlog

Fügt Binärdateien von Cisco ICM in Textdateien ein. Ändern Sie Verzeichnisse in das Verzeichnis der Prozesslogdateien.

• Protokolldateien für OPC-, PIM- und JtapiGW-Prozesse befinden sich in icr\<customer_name>\<node>\logfiles\.

• Auf dem PG befindet sich eine Batchdatei namens cdlog, in der Sie >cdlog <cust> <node> eingeben.

• Verwendung: Dumlog-Prozessname

  • Dumplog /" (Hilfe zu verschiedenen Dumlog-Optionen)

  • Dumplog jgw1

  • Dumping pi1

  • Dumpinglog-Ops

Vruce

Ein Tool zum Anzeigen der VRU PG-Erfassungsdatei. Funktioniert ähnlich wie Dumlog.

Anrufübernahme

Das Cisco ICM-Tool, mit dem Sie Routing-Skripts debuggen können.  Dieses Tool finden Sie im AW-Menüelement auf dem AW.

JTPRF

Dies ist ein Tool zum Aktivieren von JTAPI-Traces für den JTAPI-Client auf der IP-IVR. Die JTAPI-Traces auf dem IPCC PG werden mit der procmon-Schnittstelle gesteuert. Dieses Tool befindet sich im Programm files\CiscoJtapiTools\.

Leistungsüberwachung

Ein Verwaltungstool von Microsoft Windows 2000, das Echtzeitdaten für den Cisco CallManager, Cisco IP IVR und das ICM anzeigt. Sie können laufende Anrufe sehen, registrierte Geräte anzeigen und die CPU-Auslastung verarbeiten. Sie finden dieses Tool unter Start > Programme > Verwaltung.

Protokolldateien

Cisco ICM-Protokolldateien

Die Cisco ICM-Protokolldateien befinden sich in \icr\<cust>\<node>\logfiles. Hier verweist der Kunde auf den Namen der Kundeninstanz und die Node-Referenzen pg1a, ra für Router, cg1a usw. Verwenden Sie Dumlog, um die Protokolldateien anzuzeigen.

Hinweis: Sie können Ereigniserfassungsdateien mit Ablaufverfolgungstools wie vrutrace anzeigen. Diese Dateien befinden sich in einem anderen Verzeichnis.

Cisco CallManager-Protokolldateien

Cisco CallManager-Protokolldateien befinden sich normalerweise im \Programm files\cisco\ccm\trace mit Ablaufverfolgungsverzeichnissen von:

• Ccm - CallManager SDI-Protokolle

• Dbl - Protokolle auf Datenbankebene.

• SDL - Anrufsignalisierungsprotokolle.

• TFTP - Protokolle für den TFTP-Server.

Sie können die Ablaufverfolgungseinstellungen für diese Dateien auf der Cisco CallManager-Admin-Seite unter Ablaufverfolgungseinstellungen ändern. Sie können die SDL-Ablaufverfolgungseinstellungen in Cisco CallManager unter Dienstparameter ändern.

IP IVR-Protokolldateien

IP IVR-Protokolldateien befinden sich in \Programmdateien\wfavvid. Sie können IPIVR-Protokolldateien auch von der appadmin-Seite unter Engine-Trace-Dateien anzeigen.

Sie können Cisco JTAPI-Client-Protokolle anzeigen, wenn Sie JTAPI-Ereignisse mit jtprefs.exe aktivieren und das IP IVR-Modul neu starten.

Nützliche Profildaten

Wenn Sie Daten zum Öffnen von Tickets sammeln, sammeln Sie zusätzlich zu den Protokolldateien die in diesem Abschnitt aufgeführten Daten.

Anzahl Agenten

Wie viele Agenten sind konfiguriert?

Verwendete Gateways

Wie viele Gateways sind konfiguriert?

Softwareversionen der Komponenten

Cisco CallManager, JTAPI-Client, ICM, Gateway IOS-Version und IP IVR

• Sie finden die Cisco CallManager-Version auf der Cisco CallManager Admin-Webseite unter Hilfe > Info > Details.

• Um die JTAPI Client-Version zu finden, geben Sie einfach jview CiscoJtapiVersion in eine Eingabeaufforderung im Verzeichnis \winnt\java\lib im Cisco CallManager PG ein.

• Sie finden auch die IP IVR-Version.

IVR-Typ

Welche Art von IVR wird verwendet?

Plattformen

Welche Arten von Plattformen werden verwendet/CPU/Menge des physischen Speichers.

Zugehörige Informationen

• Verwenden der Remote Process Monitor-Konsole (Procmon)
• Verwendung des Dumping-Dienstprogramms
• Verwenden des Befehlszeilendienstprogramms OPCTest
• Das Cisco ICM-Testprogramm
• Tracing aktivieren
• Laden einer DRWTSN32-Protokolldatei
• AVVID TAC-Tickets: Sammeln von Informationen zur Fehlerbehebung
• Ändern der Cisco CallManager-IP-Adressen
• Technischer Support und Dokumentation - Cisco Systems