IPCC-Leitfaden zur Fehlerbehebung

Einleitung

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

Voraussetzungen

Anforderungen

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

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

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Cisco ICM Version 4.6.2

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Konventionen

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

Symptome und Maßnahmen zur Fehlerbehebung

Sehen Sie sich die PG-Protokolle für IPCC an. Wenn Sie nicht spezifizierte Fehler in den Protokollen des Peripheral Interface Manager (PIM), Open Peripheral Controller (OPC) oder Computer Telefony Interface (CTI) Server sehen, gehen Sie direkt zum JTapi Gateway (GW)-Protokoll, um eine bessere Beschreibung des Problems zu erhalten. Die JTAPI-Schnittstelle stellt in der Regel Ausnahmen bereit, wenn bei Anfragen von Drittanbietern Probleme auftreten. Diese Ausnahmen stellen nur Zeichenfolgenbeschreibungen ohne Fehlercode bereit. Der PIM/OPC/CTI-Server protokolliert daher viele Fehler als nicht spezifizierte Fehler.

Cisco IPCC PIM wird nicht aktiviert

PIM nicht aktiviert

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

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

PIM wird neu gestartet

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

Ändern Sie OPCHeartbeatTimeout in der Registrierung unter eagtpim dynamic data in 10. Dies 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 Inaktivitätsstatus 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 "Versuchen, sich zu aktivieren" mindestens einmal pro Minute sehen.

• Wenn das PIM nicht aktiv ist, überprüfen Sie das OPC-Protokoll mithilfe des Dienstprogramms dumplog. Führen Sie opctest aus, um festzustellen, ob der OPC-Prozess die Konfiguration vom Router erhält.

• Wenn der OPC-Prozess die Konfiguration nicht vom Router erhält, verwenden Sie das Dumplog-Dienstprogramm, um das pgagent-Protokoll anzuzeigen. Der pgagent-Prozess muss über einen aktiven Pfad zum zentralen Controller verfügen. Wenn der pgagent über keinen aktiven Pfad verfügt, überprüfen Sie die Netzwerkverbindung und die DMP-Konfiguration im PG-Setup. Verwenden Sie auf dem Router das Dienstprogramm dumplog, 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 über Setup oder in der Registrierung unter DMP-Registrierung.

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

  Hinweis: Möglicherweise besteht eine Diskrepanz zwischen DNS und DHCP.

• Ü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 unter PG > Setup konfigurierte ID des logischen Controllers mit der ID des logischen PG-Schnittstellencontrollers unter Konfigurieren > ICM übereinstimmt. Stellen Sie sicher, dass die unter PG > Setup für das Peripheriegerät konfigurierte ID mit der ID für das Peripheriegerät unter Konfigurieren > ICM übereinstimmt.

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

JGW-Prozess wird nicht aktiviert

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 diese Ausgabe nicht angezeigt wird oder die Version älter als 3190 ist, müssen Sie die richtige Version von Microsoft JVM installieren. Führen Sie msjavx86.exe aus. Diese Datei wird während des Setups im Verzeichnis icr\bin installiert.

Java-Klassenpfad ist falsch

• Wechseln Sie an der Eingabeaufforderung zum Verzeichnis icr\bin, geben Sie jtapigw ein, und drücken Sie die EINGABETASTE.  Eine ähnliche Reaktion zeigt sich:

  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 folgende Meldung angezeigt:

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

• Wenn die zweite Meldung angezeigt wird, wenn Sie jtapigw ausführen, überprüfen Sie Ihren Java-Klassenpfad.  Verwenden Sie den Registrierungs-Editor, um den Wert Classpath unter dem virtuellen Schlüssel SOFTWARE\Microsoft\Java anzuzeigen.  Stellen Sie den Schlüssel wie folgt ein:

  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.. sind: Semikolon, Punkt und Semikolon.

Cisco JTAPI-Client nicht auf PG installiert

• Wechseln Sie an der Eingabeaufforderung zum Verzeichnis icr\bin, geben Sie jtapigw ein, und drücken Sie die EINGABETASTE.  Eine ähnliche Reaktion zeigt sich:

  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 obigen Informationen wird die folgende Meldung angezeigt:

  Java.lang.NoClassDefFoundError

• Wenn Sie beim Ausführen von jtapigw eine Meldung wie die zweite sehen, stellen Sie sicher, dass 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 sie über den Cisco CallManager auf dem PG installieren. http://<Name des Callmanagers>/main.asp. Sie finden die Datei auf der Registerkarte Anwendung.

JTAPI-GW-Protokollbeschwerden über inkompatible JTAPI-Version

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

• Wenn Sie gerade ICM > Setup ausgeführt haben, um den PG zu aktualisieren, stellen Sie sicher, dass das Datum/die Uhrzeit in der Datei \icr\bin\icrjavalib.zip ein aktualisiertes Datum anzeigt. Das Datum muss ungefähr dem Datum/der Uhrzeit in der Datei bldXXXXX.version entsprechen und innerhalb eines Tages liegen.

Hinweis: Diese Datei kann nicht aktualisiert werden, wenn sie 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 Browser-Sitzungen, bevor Sie Setup ausführen.  Wenn Setup die Datei nicht aktualisieren kann, wird eine Meldung angezeigt, die Sie anweist, den PC neu zu starten, um die Dateien zu aktualisieren. Sie müssen neu starten.

JTAPIGW kann keine Verbindung mit Cisco CallManager herstellen

• Das PIM kommuniziert mit dem JTAPI-Gateway (JTAPIGW) und das JTAPIGW mit dem Cisco CallManager. Wenn das PIM aktiviert wird, weist das PIM JTAPIGW an, über JTAPI die Kommunikation mit dem Cisco CallManager zu initialisieren.

• Es müssen Meldungen angezeigt werden, die angeben, dass das JTAPIGW eine Verbindung vom PIM akzeptiert hat, und mit getProvider() kontaktiert werden. 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 Zeilen angezeigt.

Wenn die Ablaufverfolgung nicht erfolgreich zurückgegeben wird, werden nach dem Aufruf von getProvider() weitere Fehler angezeigt.  Die Ablaufverfolgung zu 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 in der Lage sein, den Namen über eine Hostdatei oder einen DNS aufzulösen.  Stellen Sie sicher, dass Sie den Namen oder die Adresse pingen können.  Wenn Sie den Dienstnamen ändern müssen, führen Sie ICM > Setup erneut aus, und ändern Sie den Namen im Dialogfeld Peripheriegerät bearbeiten.

Die Ablaufverfolgung des Aufrufs von getProvider() zeigt auch den verwendeten Anmeldenamen an. Beachten Sie, dass die Ablaufverfolgung das Kennwort nicht anzeigt. Der Anmeldename und das Kennwort stammen aus den Eingaben des Administrators unter ICM > Setup. Diese müssen mit einem gültigen Benutzer und Kennwort übereinstimmen, die im Verzeichnis konfiguriert und auf der Cisco-Webseite für Benutzereinstellungen verwaltet werden, um die einzelnen Geräte und Weiterleitungspunkte steuern zu können. Überprüfen Sie, Kennwort sind in ICM > Setup korrekt. Konfigurieren Sie den Benutzer im Verzeichnis so, dass er nur gültige Agentengeräte und Routing-Punkte steuern kann.

JGW-Protokoll gibt unbekannten Host an

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

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

Das JTAPI-GW meldet sich mit Benutzername und Kennwort beim globalen Verzeichnis an. Der Benutzername und das Kennwort im PIM-Dialogfeld im Setup müssen mit dem Benutzernamen und dem Kennwort für den Benutzer übereinstimmen, der im globalen Verzeichnis auf der Cisco CallManager-Admin-Webseite unter ccmadmin > User > Global Directory 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.

Kontrollkästchen "CTI" auf der Seite "Global Directory User" nicht aktiviert

Über ein Kontrollkästchen auf der Seite für globale Verzeichnisbenutzer von Cisco CallManager können die CTI-Berechtigungen für PIM- oder IP IVR-Benutzer aktiviert oder deaktiviert werden. Sie müssen dieses Kontrollkästchen aktivieren und aktualisieren, damit das PIM/JTAPI-GW aktiviert wird. Mit diesem Kontrollkästchen wird sichergestellt, dass zwei CTI-Geräte keine Verbindung zum Cisco CallManager herstellen können, was zu Problemen führen kann (der Standardwert ist 400).

Cisco CallManager-Dienst wird nicht ausgeführt

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

• Der Cisco CallManager-Dienst wird normalerweise neu gestartet, wenn er ungewöhnlich beendet wird. Sie können ihn jedoch so konfigurieren, dass er bei möglichen Problemen mit der Migration von Geräten in Failover-Szenarien ausgeschaltet wird.

• Überprüfen Sie das Ereignisprotokoll, um festzustellen, ob der Cisco CallManager-Dienst neu startet. Das System startet gelegentlich neu, wenn das System ein Problem bei ausreichender CPU-Auslastung erkennt. Das System meldet Fehler oder Warnungen im Ereignisprotokoll, die auf einen "langsamen SDL Timer-Thread" hinweisen. Bei dieser Art von Fehler wird Cisco CallManager neu gestartet. Diese Version von Cisco CallManager wird mit normaler Priorität ausgeführt, sodass andere Anwendungen, die auf dem System ausgeführt werden, das Anrufsignal stören können.

• Wenn der physische Speicher weniger groß ist oder das System auf andere Zeitprobleme stößt, kann der Cisco CallManager nach einer 10-minütigen Zeitüberschreitung und einem Neustart einen Fehler anzeigen, der darauf hinweist, dass die Initialisierung nicht möglich war. Für die Cisco CallManager-Datenbankschicht (DBL) besteht ein DCOM-Komponentendienst, bei dem ein Initialisierungsproblem auftritt. Beenden und starten Sie diesen DBL DCOM-Dienst über Komponentendienste - DCOM-Komponenten, um dieses Problem zu lösen.

  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 beheben das zugrunde liegende Zeitproblem.

Verzeichnisprobleme (Konfiguration, nicht ausgeführt, Verzeichniskennwort)

Verzeichnisdienst wird nicht ausgeführt

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

• Der Verzeichnisdienst kann in einen angehaltenen Zustand wechseln, wenn dem System nicht genügend Arbeitsspeicher oder Festplattenspeicher zur Verfügung steht. Im Microsoft Windows 2000-Ereignisprotokoll werden Fehler angezeigt. Beheben Sie Ressourcenprobleme, und starten Sie ggf. den Verzeichnisdienst neu.

Cisco CallManager-Webseite funktioniert nicht

Überprüfen Sie, ob die Cisco Global Directory-Benutzerwebseite Benutzer anzeigen und konfigurieren kann, und weisen Sie Steuergeräten Berechtigungen zu. Sowohl das 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 einem Verzeichnisserver zurückzuführen ist, kann die Webseite des Benutzers ebenfalls 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 oder höher verwenden zu können, müssen Sie einen Verzeichnisserver installieren. Das AVVID DC-Verzeichnis ist das Standardverzeichnis, das auf den Spirian-Installations-CDs verfügbar ist. Nach der Installation des Verzeichnisservers wird das Verzeichnis durch die Installation des Cisco CallManager konfiguriert.

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

Stellen Sie sicher, dass der Verzeichnisdienst des Rechenzentrums und der Cisco CallManager ordnungsgemäß ausgeführt werden.

Wenn Sie Cisco CallManager installieren, müssen Sie "ciscocisco" eingeben, wenn Sie die Passwortaufforderung des Directory Managers sehen. Wenn Sie etwas Anderes eingeben, müssen Sie möglicherweise die DC Directory-Software entfernen (Hinzufügen/Entfernen) und neu installieren. Wenn der Entfernungsvorgang anzeigt, dass einige Dateien nicht entfernt werden können, müssen Sie das aktuelle Verzeichnis c:\dcdsrvr manuell entfernen oder umbenennen.

Der Verzeichnisserver wurde installiert, wird aber nicht ausgeführt.

Überprüfen Sie die Systemsteuerung, um sicherzustellen, dass der Dienst nicht gestartet werden kann. Überprüfen Sie anschließend im Feld "Properties" (Eigenschaften), ob der Administrator konfiguriert ist und die Anmeldeinformationen und das Kennwort für den Dienst korrekt sind.

Der Verzeichnisserver ist installiert und wird ausgeführt, kann sich aber nicht mit dem DCD-Verwaltungstool 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 Verzeichnis-Manager an. Wenn Sie eine Fehlermeldung erhalten, die besagt, dass der Benutzer nicht konfiguriert ist, führen Sie eine der Cisco AVVID-Konfigurationsdateien im Verzeichnis DCDSrvr\bin aus. Wenn dies der primäre Cisco CallManager, Publisher, ist, 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 Fehler sehen, die darauf hinweisen, dass diese Konfiguration bereits vorgenommen wurde, ist der Benutzer vorhanden. Wenn es keine Fehler gibt, müssen die Dinge jetzt richtig funktionieren. Wechseln Sie zurück, und überprüfen Sie den Zugriff über die Benutzerseiten des globalen Verzeichnisses auf ccmadmin.

Hinweis: Das Verzeichnis des Rechenzentrums wechselt in den Pause-Modus, 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 Geräteziel
Name des Unternehmens	Agent9782755100
Globale Adresse	Agent9782755100
Konfig.-Parameter	/devtype CiscoPhone /dn 9782755100

Im nächsten Beispiel wird eine ICM-Beispielkonfiguration für einen Agenten verwendet:

Agent-Beispiel
Peripheriegerät	CCMPG PIM1
Peripherienummer	1234
Kennwort	XXX

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

Versuchen Sie, sich mit CTITest anzumelden.

Wenn Sie einen Agenten nicht über das Softphone anmelden können, führen Sie den gleichen Vorgang über ctitest aus. Nachfolgend finden Sie eine Beispielliste mit ctitest-Befehlen, mit denen Sie den Beispiel-Agent beim Ziel des Beispielgeräts anmelden können. Diese Befehlsliste setzt voraus, dass der CTI-Server den Port 42027 auf dem Computer CTIServerA abhört. Diese Liste geht auch davon aus, 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, dass der IPCC-PIM und der CTI-Server den Status "PIM_ACTIVE" und "CTI_ACTIVE" aufweisen. Die Titelleisten der Protokollfenster des PIM- und CTI-Servers zeigen ebenfalls den Prozessstatus an.

CTI-Client kann keine Verbindung herstellen

Überprüfen Sie die Einstellungen für die Verbindung zum CTI-Server. Für das Desktop-Softphone befinden sich die Einstellungen in der .ini-Datei (normalerweise c:\program files\geotel\cti desktop\cticonfig.ini). Folgende Einstellungen müssen überprüft werden:

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

• SideAHost (Seiten-Host): Dieser Wert muss der IP-Hostname oder die IP-Adresse von Seite A des CTI-Servers sein.

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

• SideAPort: Dieser Wert muss mit dem Port übereinstimmen, den der CTI-Server auf Seite A auf Verbindungen wartet. 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.

CTI-Client erhält Fehler zeigt Agent muss bei ACD angemeldet werden

Führen Sie setup.exe aus, das sich im Verzeichnis \icr\bin auf dem PG/CTI-Server befindet. Wählen Sie die Komponente CTI Gateway aus. Überprüfen Sie, ob das Kontrollkästchen Agent-Anmeldung erforderlich deaktiviert ist. Dieses Kontrollkästchen gilt nicht für IPCC oder Steuerungsanwendungen von Drittanbietern. Mit diesem Kontrollkästchen können Sie Anwendungen und andere ACD-Agenten überwachen.

Im PIM-Protokoll wird einer dieser Anmeldefehler angezeigt.

Verwenden Sie procmon zum pim und "trace tp*", um die Nachverfolgung durch Drittanbieter zu aktivieren (Groß-/Kleinschreibung beachten). Hier muss die Anmeldeanforderung angezeigt werden. Überprüfen Sie, ob die Parameter korrekt sind. Das Instrument wird als "Gerät=" zurückverfolgt. Dieser Wert muss mit der /dn-Zeichenfolge im configparam des Geräteziels übereinstimmen. Die Agenten-ID wird als "AgentID=" zurückverfolgt. Dieser Wert muss mit der Nummer des Agent-Peripheriegeräts in Configure/ICM übereinstimmen.

• UNGÜLTIGES_KENNWORT

  Vergewissern Sie sich, dass das Kennwort richtig ist (möglicherweise wird es nicht als Klartext zurückverfolgt). Wenn das Kennwort falsch ist, muss im Protokoll ein INVALID_PASSWORD_SPECIFIED-Fehler angezeigt werden.

• UNGÜLTIGES_OBJEKT

  Gibt an, dass die Konfigurationsparameter im Geräteziel einen ungültigen Gerätetyp enthalten. Dieser Fehler wird folgendermaßen angezeigt: Leerzeichen zwischen den Schlüsselwörtern:

  /devtype CiscoPhone /dn 9782755100

• UNGÜLTIGES_GERÄT_ZIEL

  Gibt an, dass ein Element im Geräteziel ungültig ist, höchstwahrscheinlich ein Element im Feld für die Konfigurationsparameter. Zeigen Sie mit dem Dienstprogramm dumplog das PIM-Protokoll an, wenn das PIM das letzte Mal neu gestartet wurde. Das Protokoll validiert die Geräteziele und Protokollfehler, wenn die Konfigurationszeichenfolgen für das Geräteziel ungültig sind.

Fehler beim Einloggen im JGW-Protokoll

Überprüfen Sie das JGW-Protokoll auf Fehler, die bei Anmeldeversuchen auftreten. Verwenden Sie procmon zum PIM und "trace *TP*", um die Nachverfolgung durch Drittanbieter zu aktivieren (Groß-/Kleinschreibung beachten). Suchen Sie nach der 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, für das der PG-Benutzer die Berechtigung hat, sie zu steuern. Die Durchwahl muss die richtige Ziffernanzahl für das Telefon sein, wie der Cisco CallManager weiß. Mit anderen Worten: Die Durchwahl muss die Nummer sein, die Sie von einem anderen Telefon im selben Cisco CallManager wählen, um das betreffende Telefon zu erreichen.

Gerät nicht in Anbieterdomäne

Wenn im JGW-Protokoll eine Ausnahme angezeigt wird, die anzeigt, dass sich das Gerät nicht in der Anbieterdomäne befindet, ist das Telefon nicht dem Benutzer zugeordnet, bei dem sich JTAPI GW anmeldet. Vergewissern Sie sich, dass die Durchwahl am anderen Ende der Liste der Benutzergerätezuordnungen für das globale Verzeichnis korrekt ist. Stellen Sie außerdem sicher, dass die Geräteleitungsnummer nicht zweimal registriert wird. Die gemeinsame Leitungsbelegung ist eine Funktion von Cisco CallManager, die von IPCC nicht unterstützt wird. Sie können versehentlich versuchen, eine gemeinsame Leitungsbelegung mit zwei Telefonen mit derselben Leitung einzurichten. Wenn Sie eine Leitungsnummer ändern, ändert sich die andere, und der PG kann sich nicht beim richtigen Gerät anmelden. Um dieses Problem zu beheben, löschen Sie beide Leitungen, und fügen Sie sie dem Cisco CallManager hinzu.

UNGÜLTIG_SKILL_GROUP_SPECIFIED

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 Agenten-Peripherienummer darstellt) 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 Netzwerkziel-ID des Geräteziels angezeigt, an dem der Agent angemeldet ist. Die Agentendaten werden in der awdb nur angezeigt, wenn Sie ICM so konfiguriert haben, dass Agentendaten für das Peripheriegerät an diese AW gesendet werden.

• Sie können dies auch in isqlw mit der Tabelle Agent_Real_Time in der awdb abfragen. Suchen Sie zunächst das Kompetenzziel für den Agenten (wählen Sie beispielsweise * aus Agent mit 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 ist).

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

Geräteziel bereits angemeldet

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

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

• Sie können dies auch überprüfen, wenn Sie eine Verbindung mit procmon zum PIM herstellen und das Geräteziel auslesen. Es gibt zwei Möglichkeiten, das Geräteziel auszulagern. Der Befehl ddt nimmt eine Netzwerkziel-ID als Eingabe und gibt das Geräteziel aus. Der Befehl datet übernimmt die /dn-Zeichenfolge aus der Gerätezielkonfiguration als Eingabe und gibt das Geräteziel aus. Wenn die Geräteziel-/dn-Zeichenfolge z. B. /dn 9782755100 ist, geben Sie das Geräteziel als Dead 9782755100 aus.

Gerät nicht mit PG-Benutzer verknüpft

Rufen Sie die Cisco CallManager-Webseite auf, wählen Sie Benutzer/Globales Verzeichnis aus, und suchen Sie nach der Benutzer-ID, die vom PG verwendet wird. Überprüfen Sie "Zugeordnete 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 die Geräte vom Cisco CallManager gespeichert werden) und dem Verzeichnisserver (in dem die Geräte und Benutzerprofile gespeichert werden) kommen. Überprüfen Sie, ob der Verzeichnisserver (DC Directory Server) ausgeführt wird.

• Überprüfen Sie das Anwendungsprotokoll der Windows NT-Ereignisanzeige, und suchen Sie nach Fehlern im Verzeichnis oder Metalink des Rechenzentrums. Wenn Importfehler auftreten, führen Sie avvid_recfg aus 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 an einer 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 erfolgt automatisch.

Telefongerät nicht aktiv

Überprüfen Sie, ob das Telefon eingeschaltet und beim Cisco CallManager registriert ist. Außerdem können Sie Anrufe vom Telefon ohne Mitarbeiterkontrolle tätigen und entgegennehmen.

Agent kann keinen Anruf tätigen

Agent im Status "Nicht bereit"

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

Falsche Agentendesk-Einstellungen

Wenn nur beim Wählen bestimmter Nummern ein Fehler auftritt, überprüfen Sie diese Nummern von einem physischen Telefon, um sicherzustellen, dass Sie sich erfolgreich einwählen können. Wenn Sie einen Wählnummernplan für ICM konfiguriert haben, überprüfen Sie, ob die gewählte Nummer mit einem der Platzhalter im gewählten Nummernplan übereinstimmt. Überprüfen Sie anschließend, ob der Agent über die Agententischeinstellungen die Art der Nummer wählen kann, die der gewählte Nummernplaneintrag identifiziert (z. B. International).

Nummernplan in PIM blockiert den Zugriff

Der für jeden PIM konfigurierte Nummernplan kann falsch konfiguriert oder richtig konfiguriert sein, um zu verhindern, dass ein Agent eine bestimmte Nummer anruft. Der Fehler im PIM-Protokoll muss auf einen Berechtigungsfehler hinweisen. Die Nummern für Agenten und Geräte dürfen sich nicht überschneiden, wenn der gewählte Nummernplan für Anrufe zwischen Agenten verwendet wird.

Agent tätigt kurzen Anruf, muss auf neuen Anruf warten

Der Agent wird vom Router deaktiviert, wenn der Agent einen Anruf tätigt oder ein Anruf an den Agenten weitergeleitet wird. Auf diese Weise kann der Router einen weiteren Anruf an den Agenten weiterleiten, bevor der PIM den Anruf als eingetroffen meldet. In einigen Netzwerken dauert es mehrere Sekunden, den Anruf weiterzuleiten. Der Router bricht den Timer nicht aufgrund des Agentenstatus ab.

Wenn die Zeit, die tatsächlich benötigt wird, um Anrufe vom Routing-Client zum PIM weiterzuleiten, relativ kurz ist, können Sie die konfigurierbare Zeit im Router ändern. Verwenden Sie auf einem der Router in einem DOS-Befehlsfenster die Datei rtsetting.exe. Suchen Sie unter Extrapolation > Agent. Die Standardeinstellung ist 10 Sekunden. Wenn der Wert zu niedrig ist, leitet der Router Anrufe an Agenten weiter, die einen Anruf erhalten. Dadurch verwirft das PIM Anrufe.

Das Standard-Timeout für PIM beträgt 7 Sekunden. Sie können diesen Wert mit dem Befehl regedt32 ändern. Fügen Sie den Schlüssel "AgentReserveTimout" in diesem Pfad 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 von 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 einige Sekunden kürzer sein als der Router-Extrapolations-Timer, damit der Router keine neuen Pre-Call-Ereignisse an den PIM senden kann, bevor das ursprüngliche Ereignis verarbeitet wird. Dies führt zu Problemen mit dem PIM.

Wenn der Anruf nach der PIM-Zeitüberschreitung eingeht, gilt der Anruf als Nicht-ACD-Anruf, und dem Anruf werden keine der Kontextvariablen, Dienst- oder Kompetenzgruppeninformationen zugewiesen.

Agent kann nicht gehen - nicht bereit, besetzt oder andere

Agent im Status "Aktiv"

Wenn sich der Agent in einem Gespräch befindet und auf Not Ready (Nicht bereit), Busy (Besetzt) oder Other (Andere) klickt, ändert sich der Agentenstatus nicht sofort. Das ist Absicht. Der Mitarbeiter bleibt bis zum Abschluss des Anrufs im Gesprächs- oder gehaltenen Zustand. Der Agent wechselt je nach gedrückter Taste zu "Not Ready", "Work Ready" oder "Work Not Ready". Wenn der Agent nach Beendigung des Anrufs sofort auf "Verfügbar" wechselt, müssen Sie die Agententischeinstellungen überprüfen und feststellen, ob "Verfügbar nach Eingang" oder "Verfügbar nach Ausgang" eingestellt ist. Diese Einstellungen überschreiben die Aufgaben, die der Agent mit den Schaltflächen während eines Anrufs ausführt.

Einstellungen für den Agentenarbeitsplatz verhindern den Umstieg

Überprüfen Sie die Agententischeinstellungen für den Agenten in ICM konfigurieren, und ob die Ursache für einen Leerlauf aktiviert ist. Wenn das Kontrollkästchen aktiviert ist, kann der Agent nicht ohne Ursachencode in den Status "Not Ready" wechseln. Ändern Sie entweder die Datei Desktop_Settings.cfg so, dass sie mit der Agentendesk-Einstellung in ICM konfigurieren übereinstimmt, oder ändern Sie die Agentendesk-Einstellung in ICM konfigurieren.

Wenn dem Agenten keine Agenten-Desk-Einstellung zugewiesen ist, kann sich der Agent anmelden und bereit machen, aber der Agent kann nicht go_ready oder abmelden. Die Lösung besteht darin, die Agentenanwendung zu schließen, einen Agententisch zuzuweisen und sich erneut anzumelden.

Agent muss warten, um nicht bereit zu sein

Der Agent wird vom Router deaktiviert, wenn der Agent einen Anruf tätigt oder ein Anruf an den Agenten weitergeleitet wird. Auf diese Weise kann der Router einen weiteren Anruf an den Agenten weiterleiten, bevor der PIM den Anruf als empfangen meldet. In einigen Netzwerken dauert es mehrere Sekunden, den Anruf weiterzuleiten. Der Router bricht den Timer nicht aufgrund des Agentenstatus ab.

Wenn die Zeit, die tatsächlich benötigt wird, um Anrufe vom Routing-Client an das PIM weiterzuleiten, relativ kurz ist, können Sie die konfigurierbare Zeit im Router ändern. Verwenden Sie auf einem der Router in einem DOS-Befehlsfenster die Datei rtsetting.exe. Suchen Sie unter Extrapolation > Agent. Der Standardwert ist 10 Sekunden. Wenn der Wert zu niedrig ist, leitet der Router Anrufe an Agenten weiter, die einen Anruf erhalten. Dadurch verwirft das PIM Anrufe.

Agent kann nicht einsatzbereit sein

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

Die Daten für die Anmeldeanforderung und die Bereitschaftsanforderung sind inkonsistent. Möglicherweise stimmen Instrument, Agenten-ID oder Peripherienummern nicht überein. Aktivieren Sie die CTI Server-Ablaufverfolgung mit procmon, und setzen Sie regset auf 0xf8, um die entsprechenden Ablaufverfolgungen anzuzeigen. Sie können dies auch in den OPC- oder PIM-Protokollen anzeigen, wenn die TP-Ablaufverfolgung (Tracing über Drittanbieter) aktiviert ist.

Agent kann sich nicht abmelden

Aktueller Agentenstatus verhindert Anruf

Wenn sich der Agent im Status "Work Ready", "Work Not Ready" oder "Available" befindet, muss er zunächst "Not Ready" auswählen, bevor sich der Agent abmeldet. Ändern Sie entweder Desktop_Settings.cfg so, dass die Einstellung für den Agenten-Desk in "ICM konfigurieren" übereinstimmt, oder ändern Sie die Einstellung für den Agenten-Desk in "ICM konfigurieren".

Agentendesktopeinstellungen 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 Agententischeinstellungen in Configure ICM (ICM konfigurieren), und überprüfen Sie, ob Abmeldungsgrund erforderlich aktiviert ist.

Agent zeigt aktiven Anruf oder Agentengespräch an, aber kein Anruf am Telefon

Agent abmelden und wieder einloggen

Wenn das Softphone einen Anruf anzeigt, der physisch nicht mehr vorhanden ist, kann der Status des Agenten in Gespräch oder Halten festgehalten werden, und der Agent kann sich nicht abmelden. Dies kann auf einen Softwarefehler in JTAPI oder PIM zurückzuführen sein. Um die Bedingung zu beheben, versuchen Sie zunächst, den Anruf vom Softphone zu löschen, wenn die Lösetaste 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 weiter ausgeführt werden und sich den Status des ungültigen Agenten merken.

Agent mit falschem Status beim PIM

Überprüfen Sie in procmon den Status des Agenten am PIM. Wenn Sie den Agenten-Desktop neu starten und sich die Bedingung nicht löscht, können Sie weitere Maßnahmen ergreifen. CTI-Server und OPC bieten Mechanismen zum Löschen von Anrufen über die Debug-Schnittstelle von procmon oder opctest. Dies ist eine etwas bevorzugte Option gegenüber der anderen Option, bei der der PG-Dienst aus- oder wieder eingeschaltet oder das PIM-Fenster zumindest geschlossen wird.

Anrufe werden kurz nach Benachrichtigung gelöscht oder sind eingerichtet

Registrierungseinstellungen falsch

Mit 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

Route- und Routenskript prüfen

Mit dem AW Call Tracer-Tool können Sie überprüfen, ob der Anruf beim Skript ankommt und das Skript ordnungsgemäß ausgeführt wird. Skripteditor ausführen und Skript überwachen. Prüfen Sie die Protokolle für Router, OPC und PIM auf Probleme. Die meisten Routenfehler werden bedingungslos zurückverfolgt.

'DN-Labelzuordnung verwenden' für Routing-Client des Peripheriegeräts aktiviert

In der ICM-Konfiguration gibt es eine Einstellung für jeden Routing-Client 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 Ziel-Label einen Eintrag für die Bezeichnung "Dialed Number Label" (Gewählte Nummer) konfigurieren. Diese Einstellung ist für PG-Routing-Clients nicht hilfreich und muss auf "Nein" gesetzt werden.

Kein Label für geroutetes Geräteziel konfiguriert

Überprüfen Sie das auf dem Routing-Client konfigurierte Label. Label muss auf jedem Client konfiguriert werden, auch wenn das Label auf jedem Client identisch ist.

CTI-Weiterleitungspunkt ist auf Cisco CallManager nicht konfiguriert

Zur Verwendung von Post Routing müssen Sie im Cisco CallManager einen "CTI Route Point" konfigurieren und dem Routing Point eine Leitung mit der gewünschten Verzeichnisnummer (z. B. "5000") zuweisen. Verwenden Sie für Agentenanrufe zur Weiterleitung den gewählten Nummernplan. Ein Agent, der sich an den Cisco CallManager CTI Route Point wählt, verwechselt das IPCC-Softphone in CTI Desktop Version 4.1.9.

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

Sie müssen das CTI Route Point-Gerät der Liste "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 Liste "Zugeordnete Geräte" des Benutzers hinzu. Wenn Sie einem Gerät, das bereits in der Liste der Benutzergeräte vorhanden ist, weitere Zeilen hinzufügen, müssen Sie das JGW neu starten, damit das 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 dann der Liste der Benutzergeräte hinzufügen, muss das JGW in der Lage sein, das neue Gerät zu erkennen (innerhalb von ca. 30 Sekunden).

Keine gewählte Nummer in Cisco ICM konfiguriert

Überprüfen Sie die gewählte Nummer, um sicherzustellen, dass sie für den Routing-Client des Peripheriegeräts konfiguriert ist. Führen Sie procmon zum 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 das JGW, einen Routen-Rückruf für die gewählte Nummer 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, ob ein Neustart von JGW erforderlich ist

Wenn Sie eine gewählte ICM-Nummer konfiguriert, den CTI-Weiterleitungspunkt eingerichtet und der Liste der Benutzergeräte hinzugefügt haben, aber beim Wählen der Nummer immer noch keine Weiterleitungsanforderungen erhalten, müssen Sie den JGW möglicherweise neu starten (oder den PG neu starten). Sie müssen nur neu starten, wenn Sie die Trace im JGW aktiviert haben (trace *ROUTE*) und Sie Fehler sehen, die zeigen, dass die Adresse nicht im Provider ist. Im Allgemeinen muss das JGW in der Lage sein, neue CTI-Routenpunkte zu erkennen, die der Liste der Benutzergeräte hinzugefügt werden, ohne dass ein Neustart erforderlich ist. Wenn einem bereits vorhandenen CTI-Routenpunkt Leitungen hinzugefügt werden, erkennt das JGW diese nicht, ohne dass ein Neustart erforderlich ist. Sie müssen in der Lage sein, einen Neustart zu vermeiden, wenn Sie für jede gewählte Nummer einen neuen CTI-Routenpunkt anstelle neuer Leitungen zu bereits vorhandenen Geräten hinzufügen.

Hinweis: Dies setzt voraus, dass DeviceListPolling in der Datei JTAPI.ini 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 einschalten, damit der PG das neue Gerät sehen kann.

OPC-Protokolle für Routendialoge überprüfen

Verwenden Sie opctest, um die Routenverfolgung "debug /routing" zu aktivieren und OPC-Protokolle auf Fehler zu überprüfen, wenn Aufrufe an den Routing-Punkt erfolgen. Überprüfen Sie, ob Routing-Anforderungen empfangen und Labels zurückgegeben werden. Die Routenanforderungen werden als "CSTA_ROUTE_REQUEST"- und "ICR_NEW_CALL_REQ"-Nachrichten angezeigt. Die zurückgegebenen Labels werden als "ICR_CONNECT"-Nachrichten angezeigt. Wenn Fehler auftreten, können Sie "ICR_DIALOG_FAIL" Meldungen anstelle von "ICR_CONNECT" Meldungen sehen. Überprüfen Sie in diesem Fall das Router-Protokoll auf Fehler.

Routerprotokolle auf Routendialoge überprüfen

Verwenden Sie rtsetting.exe, um die Routenverfolgung zu aktivieren und Router-Protokolle auf Fehler zu überprüfen, wenn Anrufe am Routing-Punkt erfolgen.

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

Das Routingskript entfernt die Warteschlange für einen Anruf nicht, wenn der Agent verfügbar wird.

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

Kein Fehler im Routerprotokoll - Warteschlangenknoten wird in Warteschlange mit der Basispriorität der Kompetenzgruppe gestellt

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

• Es gibt eine Routerregistrierungseinstellung namens AutoLoginBase (verwenden Sie rtsetting.exe). Ändern Sie diese Einstellung, damit der Anruf in die Warteschlange der Gruppe mit den grundlegenden Fähigkeiten gestellt werden kann und mehr oder weniger wie erwartet funktioniert. Bei dieser Art der Warteschlangenzuweisung wird keine primäre gegenüber sekundären Fertigkeiten bevorzugt.

• Führen Sie eine Warteschlange entweder mit den primären und/oder sekundären Fähigkeiten im Warteschlangenknoten explizit aus.

Router-Protokoll weist auf Label hin, das nicht für das Ziel konfiguriert wurde

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 Configuration Tool, um dies über die ICR-Konfiguration effizienter zu machen.

"Ring No Answer Heard" (Keine Antwort), wenn alle Agenten und Warteschlangen-Ports belegt sind

Router-Protokolle überprüfen

• Routenfehler müssen vorbehaltlos zurückverfolgt werden.

• Sie können den Routenpfad mit dem Tool zur Anrufverfolgung testen.

• Verwenden Sie rtrtrace, um die Route Request Trace zu aktivieren und Router-Protokolle auf Fehler zu überprüfen, wenn Anrufe am Routing-Punkt erfolgen.

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

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

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

PIM-Protokolle überprüfen

• Verwenden Sie procmon, um die Ablaufverfolgung im PIM (Ablaufverfolgungsprotokoll, Ablaufverfolgung *call_event*) zu aktivieren und Protokolle zu überprüfen. Die Meldung vor dem Anruf wird auf dem Router angezeigt. Außerdem wird "DeliveredEvent" angezeigt, wobei "DevTgDevStr" auf die Agentenerweiterung festgelegt ist. Wenn der Anruf nicht erscheint, stellen Sie sicher, dass die Bezeichnung für den Route Client richtig ist.

Beliebige Übertragungen führen zu inkonsistenten Ergebnissen

Der IPCC unterstützt die Option, einen Anruf in die Warteschleife zu setzen und einen neuen Anruf zu tätigen, nicht, da der Cisco CallManager inkonsistente Ergebnisse liefert. Dies gilt als Produktverbesserung und kann für eine zukünftige Version in Betracht gezogen werden.

Alternative funktioniert nicht

Wenn ein Beratungsgespräch vermittelt/alterniert/gehalten/abgerufen wird, unterbricht der Cisco CallManager die Beratungszuordnung. Dies führt zu einem willkürlichen Transferszenario, das nicht unterstützt wird. Support-Mitarbeiter können sich erneut mit dem Kunden in Verbindung setzen und eine neue Beratung starten. Das IPCC-Softphone deaktiviert die alternative Taste, bis der Fehler behoben ist. Drittanbieter können sich jedoch beschweren.

Konferenzteilnehmer kann nicht in einer anderen Partei konferenzen abhalten

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

Agentenstation unerwartet abgemeldet

Inaktivitäts-Timer für Agentendesktopeinstellungen

In den Agentendesk-Einstellungen gibt es eine Zeiteinstellung zum Abmelden von Agenten im Status "Not Ready" (Nicht bereit). Die maximale Inaktivitätsdauer beträgt 2 Stunden, kann jedoch auf einen geringeren Wert eingestellt werden. Agenten im Status "Verfügbar" werden nicht abgemeldet, wenn sie sich im Status "Inaktivität" befinden. Der Agent wechselt von "Ready" (Bereit) zu "Not Ready" (Nicht bereit), wenn der Zeitgeber für das Nichtantworten des Ruftons abläuft (ebenfalls eine konfigurierbare Agentendesktopeinstellung).

CTI-Server-Heartbeat-Zeitüberschreitung

Für den CTI-Server ist ein Timeout für den Heartbeat konfiguriert. Ältere Computer, überarbeitete CTI-Server oder Netzwerke mit Bandbreitenproblemen können die Ursache sein. CTI-Serverprotokolle müssen einen Fehler im Protokoll melden.

Agent verhält sich nicht so, wie in den Agentendesk-Einstellungen konfiguriert

Sowohl die Agent-Desk-Einstellungen in Configure ICR(M) als auch die Agent-Konfigurationsdatei müssen sich darauf einigen, wie der Agent gehandhabt wird.

In den Konfigurationsparametern der ICM-Peripheriekonfiguration ist ein Work Timer vorhanden. Stellen Sie die Parameter auf \WORKTIMER 30 ein, um eine 30-Sekunden-Verzögerung bei der automatischen Verfügbarkeit einzustellen.

Die Desktop-Konfigurationsdatei befindet sich in:

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

Der Arbeitsmodus für eingehende Anrufe muss mit "Daten" in "Desk_Settings.cfg" und in "ICR(M)-Agententischeinstellungen konfigurieren" auf "Erforderlich" und "Nicht erforderlich" gesetzt werden. Erforderlich mit Daten ersetzt die Option für die automatische Verfügbarkeit.

Weiterleitung durch Beratung fehlgeschlagen

Schauen Sie sich das JTAPI GW-Protokoll an und sehen Sie nach, ob Fehler vorliegen, die darauf hinweisen, warum die Weiterleitung mit Rücksprache fehlschlägt. Prüfen Sie, ob die Agenten-Software den Anruf halten/abrufen oder alternative Vorgänge beim Beratungsgespräch erlaubt. Wenn ein Anruf gehalten/abgerufen wird, gilt der Anruf nicht mehr als konsultativer Anruf, sondern als "willkürliche" Weiterleitung durch den Cisco CallManager. Der Cisco CallManager hat Probleme mit willkürlichen Übertragungen. Begrenzen Sie den Benutzer in einem Beratungsgespräch darauf, die Verbindung wiederherzustellen oder die Weiterleitung abzuschließen.

Die Beratergruppe legt auf, aber die Anzeige des Anrufs wird nicht ausgeblendet.

Cisco CallManager hat aktuell Probleme mit einem Verbindungsabbruch für eine Konferenz, die angerufen wird, um Rat zu erhalten, wenn die Konferenz nicht abgeschlossen ist. Trennen Sie den Anruf ein zweites Mal, um die Anzeige des Anrufs auf dem Agententelefon zu deaktivieren.

Übersetzungsroute zu VRU funktioniert nicht

Überwachen Sie zunächst 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 Spur nach oben drehen, um ein besseres Bild davon zu erhalten, was passiert.

Die Reihenfolge der Übersetzungswege ist wie folgt:

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

• Der Router stellt eine Verbindung zum Routing-Client mit einem Label her, das den Anruf an das IVR weiterleiten muss.

• Der IVR muss dann eine RequestInstruction senden, die der VRU PG verwendet, um das periphere Ziel zu suchen.

• Der Router vergleicht periphere Ziele der Anforderungsanweisung mit den peripheren Zielen des Übersetzungsrouten-Programms, auf die er wartet.

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

Überwachen Sie das aktive Skript, um den Fehlerpfad zu finden. Prüfen Sie die Router-Nachverfolgung auf Fehler. Überprüfen Sie, ob der Routingclient anfängliche Labels empfängt. Überprüfen Sie, ob die VRU den Anruf empfängt. Überprüfen Sie, ob das VRU eine Anforderungsanweisung auf VRU-PIM- oder OPC-Ebene sendet.

Route Request wird im Routenskript nicht an "Translation Route to VRU Node" weitergeleitet

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

Zunächst reicht im Routing-Skript ein Select- oder Route-Select-Knoten mit ausgewählter Übersetzungsroute nicht aus, um die Route in die servicegesteuerte VRU zu übersetzen. Eine Übersetzungsroute zum VRU-Knoten ist erforderlich.

Zweitens muss der Monitor anzeigen, dass der Anruf beim Übersetzungsroutenknoten ankommt. Ein Fehler bedeutet, dass keine Übersetzungsroute ermittelt werden kann oder die RequestInstruction-Routenanforderungsnachricht nicht vom IVR empfangen wurde.

Timeout für Übersetzungsroutinen im Router-Protokoll

Ein Timeout-Fehler bei der Übersetzung gibt an, dass der Router die Anforderungsanweisung nicht erhält. Überprüfen Sie den OPC und den VRU PIM auf Fehler, und prüfen Sie, ob die RequestInstruction eintrifft.

Aktivieren Sie "translation routing" und "network VRU tracing" mit dem Tool "rtrtrace" auf dem Router, um besser anzuzeigen, was auf dem Router passiert. Aktivieren Sie im VRU PG OPC die Funktion für die Servicesteuerung und opctest.

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

Im Anforderungsbefehl muss eine gültige Trunk-Gruppe angegeben werden, die einer Trunk-Gruppen-Peripherienummer in einer der für den VRU PG konfigurierten Trunk-Gruppen zugeordnet ist. Schalten Sie den VRU PG aus, um die Aktualisierung der Trunk-Gruppen-Peripherienummer zu erhalten, falls geändert.

ICM-Konfiguration prüfen

Stellen Sie sicher, dass die DN-Labelzuordnung im IVR-PG-Routing-Client deaktiviert ist. Der IVR PG benötigt eine Netzwerk-VRU-Zuweisung. Die Netzwerk-VRU muss vom 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 jedes der DNIS in den peripheren Zielen verfügen. (Die Beschriftungen für die Anforderung des Routing-Clients im Übersetzungs-Routen-Assistenten müssen mit den DNIS-Bezeichnungen übereinstimmen. Sie können dies im Präfix einrichten, und die Option prefix = DNIS auswählen.)

Der VRU-Routing-Client benötigt ein für das Geräteziel konfiguriertes Label, an das er weiterleitet, wenn ein Agent verfügbar wird.

Fehlerbehebung bei Cisco IP IVR - ICM-Schnittstelle

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

Überprüfen Sie im Allgemeinen die MIVR-Protokolle auf der Webseite appadmin > Engine > Trace files.

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

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

• Das Kontrollkästchen "Service Control" ist in der IVR ICM-Konfiguration aktiviert.

• Skriptnamen in IVR-Skriptdefinitionen entsprechen Netzwerk-VRU-Skriptnamen in ICM.

• Die Trunk-Gruppennummer in VRU PG entspricht der CTI-Port-Gruppennummer in IP IVR.

Übersetzungsroute schlägt fehl

Zusammen mit allen anderen Aktionen, die Sie zur Fehlerbehebung verwenden, können Sie diese Schritte auch ausprobieren, um bei der Fehlerbehebung für das IP IVR zu helfen.

• Überprüfen Sie das MIVR-Protokoll. Dieses Protokoll kann in der Regel auf Problembereiche verweisen.

• Verwenden Sie die Debug-Einstellungen zum Aktivieren von Cisco IP IVR SS_TEL und LIB_ICM.

• Aktivieren Sie Cisco JTAPI-Protokoll für IP IVR mit jtprefs für IP IVR. Siehe Debugtools. Stoppen 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-Umwandlungsroute-Portgruppe mit der Peripherienummer in der Trunk-Gruppenkonfiguration im ICM übereinstimmt.

Skript wird nicht abgespielt oder spielt Fehlermeldung

Überprüfen Sie die IP-IVR-Protokolle unter den Modul-Trace-Dateien, um sicherzustellen, dass:

• Skript ausführen wird empfangen.

• IP IVR kann Skript finden. Skripte mit dem Repository Admin Tool hochladen.

• IP IVR kann Eingabeaufforderung finden. Benutzerdefinierte Aufforderungen finden Sie unter \wfavvid\prompts\ user\en_us\ der IP-IVR.

JTAPI-Status zeigt partiellen Dienst an

Dies bedeutet im Allgemeinen, dass einige der im IP IVR konfigurierten CTI-Ports oder CTI-Routenpunkte nicht konfiguriert und/oder mit dem IP IVR-Benutzer im Cisco CallManager verknüpft wurden.

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

ICM-Status auf IP IVR zeigt partiellen Status an

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

Stottern-Eingabeaufforderung wird gehört, wenn ein Anruf vom Router in die Warteschlange gestellt wird

Dies ist ein falsch konfiguriertes Routing-Skript, das in der Netzwerk-VRU-Skriptkonfiguration in ICR konfigurieren zu wenig Zeitüberschreitung zulässt.

Einige der Skripte, die mit dem IP IVR für die ICM-Schnittstelle verfügbar sind, werden sehr lange ausgeführt, die Standard-Zeitüberschreitung in der ICM-Netzwerkskriptkonfiguration beträgt jedoch drei Minuten. Wenn das Skript eine Zeitüberschreitung aufweist und der Pfad für den Fehlschlag des Ausführungsskripts ein anderes Ausführungsskript wiedergibt, werden diese Ausführungsskripts im Grunde beim IVR in die Warteschlange gestellt. Wenn die Skripte aus der Warteschlange entfernt werden, hören Sie viele Skripte übereinander spielen.

Fehlerbehebung bei IVR-Servicestatistiken

IVR-Statistiken sind wichtig für IPCC-Service-Level-Berichte. Daher finden Sie hier einige Informationen zur Fehlerbehebung. Als Überblick werden die Änderungen an Router und VRU PG, bei denen Anrufe in der VRU implementiert wurden, nicht als verbunden, sondern als in die Warteschlange eingereiht gezählt. Wenn Anrufe weitergeleitet werden, werden sie als beantwortet gemeldet. Wenn der Kunde in der Warteschlange die Verbindung trennt, werden sie als abgebrochen gemeldet. Weitere Informationen finden Sie in der Readme-Datei der Hotfixes 53 und 54. Der Router versendet spezielle Warteschlangenereignisse, die den Status des Anrufs auf dem Router angeben.

Im VRU PIM ist ein spezielles Register eingerichtet, daher müssen Sie diese Funktion freiwillig aktivieren, um eine minimale Unterbrechung sicherzustellen.

Der Enterprise Service Real Time Report 10 verwendet diese Daten besonders, wenn Sie einem oder mehreren Enterprise-Peripheriegeräteberichten den oder die VRU-Dienst(e) und den/die Cisco CallManager PG-Dienst(e) hinzufügen. Für den Enterprise Service Real Time Report müssen die VRU PG- und Cisco CallManager PG-Services zu Berichtszwecken in einem Enterprise-Service gruppiert werden.

Weitere nützliche Warteschlangenberichte sind die neuen Anruftypberichte für Echtzeit- und Verlaufsdatensätze, und das Echtzeit-Raster für Kompetenzgruppen zeigt nun Anrufe in Warteschlangen für die Kompetenzgruppe an.

Es werden keine Servicestatistiken oder Datensätze mit Details zu Anrufbeendigungen erstellt.

VRU PIM generiert keine CSTA-Ereignisse. Aktivieren Sie das Reporting zur Servicesteuerung in der eingerichteten VRU PG. Dies steht 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.

VRU meldet alle Anrufe als verbunden und nicht wie erforderlich in die Warteschlange gestellt

ServiceControlQueueReporting-Registrierungsschlüssel ist nicht auf Geschwindigkeit festgelegt oder nicht auf 1 festgelegt

Das Startprotokoll 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 in wie folgt auf 1 fest:

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 nicht in Serviceberichten angezeigt

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

Das OPC-Protokoll zeigt an, dass die Dienstzuordnung nicht gefunden wird, wenn Anrufe für den falschen Dienst gezählt werden oder nicht in Dienstberichten angezeigt werden.

Cisco ICM-Berichtsprobleme

Cisco ICM ist nicht für die einfache Korrelation von Daten ausgelegt, die in den Tabellen Anruftyp, Service und Kompetenzgruppe enthalten sind. Die Zahlen haben in der Regel in jeder Gruppe leicht unterschiedliche Bedeutungen. Es gibt nur einen Service für einen Anruf, es können jedoch auch zwei Kompetenzgruppen vorhanden sein, wenn mehr als ein Agent beteiligt ist. Die Funktion "Redirect on no Answer" (RONA) generiert wahrscheinlich eine weitere Postroute, ohne dass ein weiterer Terminierungsdatensatz generiert wird.

Unausgewogenes Verhältnis zwischen Agenten-Kompetenzgruppe, Kompetenzgruppe, Service und Anruftypnummern

• Symptom: Die verarbeiteten Anrufe oder andere Statistikfelder stimmen nicht mit den Berichten zu Services, Anruftypen und/oder Kompetenzgruppen überein.

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

• Fehlerbehebung: Wenn das Anrufvolumen weniger als 1 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:

  • Wird die erste POST-Route auf dem Cisco CallManager PG oder VRU PG durchgeführt?

  • Ist Forward On No Answer (FONA) konfiguriert und an was ist FONA konfiguriert, um eine Umleitung vorzunehmen?

  • Ist eine Standardqualifikationsgruppe mit der Peripherienummer 0 konfiguriert, um ausgehende Anrufe von nicht weitergeleiteten und ausgehenden Anrufen zu trennen?

Greifen Sie die historischen Daten aus diesen Tabellen für einen Tag mit den "select *"-Anweisungen:

• Peripherie_Halbe_Stunde

• Anruftyp halbe Stunde

• Service_Halbe_Stunde

• Skill_Group_Half_Hour

• Terminierung_Anruf_Details

• Route_Call_Detail

Fehlerbehebung bei Cisco CallManager

Wenn Sie die Ablaufverfolgungen im Cisco CallManager sammeln, können Sie die Markierungen auf der Seite Cisco CallManager Admin unter Services > Ablaufverfolgungs-Markierungen aktivieren. 0xCB05 ist ein gutes Trace-Flag, das für die SDL-Nachverfolgung von CTI-Fehlern eingerichtet wurde. Stellen Sie 0xCB05 zu Debugzwecken unter Service-Parameter ein. Siehe AVVID TAC Cases: Sammeln von Problembehebungsinformationen für weitere Informationen Weitere Informationen finden Sie in der Cisco CallManager Online-Dokumentation, einschließlich der Anleitungen zur Fehlerbehebung.

Aktivieren der Ablaufverfolgung für Cisco CallManager

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

Ändern der Cisco CallManager-IP-Adressen

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

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

2. CRA-Modul anhalten.

3. In CRA: Ändern Sie die IP-Adresse unter Modulkonfiguration.

4. Ändern Sie die IP unter JTAPI.

5. DC-Verzeichnisdienst auf dem Server beenden.

6. Ändern der IP-Adresse in der Verzeichniskonfiguration

7. Ändern Sie im 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. Server-IP-Adresse ändern - Netzwerkeigenschaften.

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

12. Ändern Sie die IP-Adresse im Hotelprofil im Verzeichnis des Rechenzentrums, Cisco CallManager > System Profile > Hoteling.

13. Öffnen Sie SQL Enterprise Manager.

14. Ändern von IP-Adressen in URLs in der Plug-In-Tabelle

So sichern Sie Ihre Konfigurationsänderungen:

1. Öffnen Sie stiBackup configuration.

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

Debug-Tools

Procmon

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

• Verwendung: procmon <Kundenname> <Knoten>.

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcc cg1a ctisvr

Nachfolgend finden Sie einige nützliche Ablaufverfolgungseinstellungen für die einzelnen Prozesse:

• JTAPI GW (procmon verwenden)

  • trace JT_TPREQUESTS (aktiviert Drittanbieter-Anforderungsnachverfolgungen)

  • trace JT_JTAPI_EVENT_USED (aktiviert die Ablaufverfolgungen für die JTAPI-Ereignisse, die vom PG verwendet werden)

  • trace JT_PIM_EVENT (aktiviert Ablaufverfolgungen für Ereignisnachrichten, die an das PIM gesendet werden)

  • trace JT_ROUTE_MESSAGE (aktiviert Routing-Client-Traces)

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

• PIM (procmon verwenden)

  • trace tp* (aktiviert Drittanbieter-Anforderungs-Traces)

  • Ablaufverfolgungs-Precall (aktiviert Precall-Ereignisabläufe)

  • trace *event (aktiviert die Nachverfolgung von Agenten- und Anrufereignissen)

  • trace csta* (aktiviert CSTA-Ablaufverfolgungen für Anrufereignisse)

• CTI-SERVER (procmon verwenden)

  • regset EMSTraceMask 0xf8 (aktiviert nützliche CTI-Serverspuren, die wahrscheinlich umbrochen werden)

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 (aktiviert die Ereignisablaufverfolgung des Agenten)

  • debug /routing (aktiviert Routingereignisspuren)

  • debug /cstacer (aktiviert csta-Ereignis-Traces)

  • debug /tpmsg (aktiviert die Ablaufverfolgungen von Anrufanforderungen von Drittanbietern)

reißen

Rtest ist ein Befehlszeilenschnittstellen-Tool zum Debuggen des Router-Prozesses auf dem ICM. Die GUI-Version finden Sie unter rtrtrace.

• Verwendung: rtest /cust ipcc

rtsetting.exe

GUI-Tool zum Ändern der Registrierungseinstellungen des Routers.

• Es gibt eine Option zum Zurücksetzen der Einstellungen auf den Standardwert.

rtrtrace.exe

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

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

  • Warteschlangenverwaltung - für Probleme beim Entfernen aus der Warteschlange.

  • Servicesteuerung - für Probleme mit der VRU-Schnittstelle.

  • Übersetzungsrouting - für Probleme mit Übersetzungsrouten.

Mülleimer

Blendet Cisco ICM-Binärdateien in Textdateien aus. Wechseln Sie in das Verzeichnis der Prozessprotokolldateien.

• OPC-, PIM- und JtapiGW-Prozessprotokolldateien befinden sich in icr\<customer_name>\<node>\logfiles\.

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

• Verwendung: Dumlog-Prozessname

  • Dumplog /" (für Hilfe zu verschiedenen Dumplog-Optionen)

  • Dumplog jgw1

  • Dumplog pim1

  • DumpLog-Opc

vrutrace

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

Call Tracer

Cisco ICM-Tool zum Debuggen von Routing-Skripts.  Dieses Tool finden Sie im AW-Menüpunkt im AW.

Jtprefs

Mit diesem Tool können JTAPI-Traces für den JTAPI-Client auf dem IP-IVR aktiviert werden. Die JTAPI-Traces auf dem IPCC PG werden über die procmon-Schnittstelle gesteuert. Dieses Tool befindet sich in den Programmdateien\CiscoJtapiTools\.

Leistungsüberwachung

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

Protokolldateien

Cisco ICM-Protokolldateien

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

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

Cisco CallManager-Protokolldateien

Cisco CallManager-Protokolldateien befinden sich normalerweise im Verzeichnis \program files\cisco\ccm\trace mit Ablaufverfolgungsverzeichnissen für:

• CCM - CallManager SDI-Protokolle.

• DBL - Datenbankebenenprotokolle.

• 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 den Ablaufverfolgungseinstellungen ändern. Sie können die SDL Trace-Einstellungen unter den Service-Parametern im Cisco CallManager ändern.

IP IVR-Protokolldateien

IP-IVR-Protokolldateien befinden sich unter \program files\wfavvid. Sie können IPIVR-Protokolldateien auch auf der Seite "appadmin" unter "engine-trace files" anzeigen.

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

Nützliche Profildaten

Wenn Sie Daten erfassen, um Tickets zu öffnen, erfassen Sie zusätzlich zu den Protokolldateien die in diesem Abschnitt aufgeführten Daten.

Anzahl der 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

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

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

• Hier finden Sie auch die IP IVR-Version.

IVR-Typ

Welche Art von IVR wird verwendet?

Plattformen

Welche Plattformtypen werden verwendet/CPU/Kapazität des physischen Speichers.

Zugehörige Informationen

• Verwenden der Remote Process Monitor Consle (Procmon)
• Verwenden des Dienstprogramms Dumplog
• Verwenden des Befehlszeilendienstprogramms OPCTest
• Das Testprogramm Cisco ICM
• Tracing aktivieren
• Lesen einer Drwtsn32-Protokolldatei
• VERMEIDEN SIE TAC-FÄLLE: Sammeln von Informationen zur Fehlerbehebung
• Ändern der Cisco CallManager-IP-Adressen
• Technischer Support und Dokumentation für Cisco Systeme