Verständnis der JTAPI-Architektur und des Anrufflusses in UCCX

Einleitung

In diesem Dokument werden die grundlegende Funktionalität von JTAPI, seine Architektur und der Anrufablauf in Bezug auf UCCX beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt die Kenntnis dieser Tools und Funktionen:

• JTAPI - Java Telefony API
• API - Application Programming Interface
• UCCX - Unified Contact Center Express
• CUCM - Cisco Unified Communications Manager
• CTI = Computer Telefony Integration

Cisco empfiehlt, sich mit folgenden Themen vertraut zu machen:

• Konfiguration von Cisco Unified Communications Manager (CUCM)
• Unified Contact Center Express (UCCX)-Konfiguration

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:

• UCCX Version 12.5.1.11002-481
• CUCM-Version 12.5.1.11900-146

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 Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

In diesem Dokument werden die JTAPI-Architektur, der Anruffluss, das Aktivieren von Debugging und das Erfassen der Protokolle beschrieben.

JTAPI - Überblick

Cisco Unified JTAPI dient als Programmierschnittstellenstandard, der von Sun Microsystems für den Einsatz mit Java-basierten Computertelefonie-Anwendungen entwickelt wurde. Cisco JTAPI implementiert die Sun JTAPI 1.2-Spezifikation mit zusätzlichen Cisco-Erweiterungen. Sie benötigen Cisco JTAPI, um Anwendungen zu entwickeln, die:

• Steuern und beobachten Sie Cisco Unified Communications Manager-Telefone.

• Weiterleitung von Anrufen über CTI-Ports (Computer-Telefony Integration) und Weiterleitungspunkte (virtuelle Geräte)

JTAPI und UCCX

Cisco Unified JTAPI wird in einem Contact Center verwendet, um den Gerätestatus zu überwachen und Routing-Anweisungen auszugeben, damit Anrufe zur richtigen Zeit am richtigen Ort eingehen können. Darüber hinaus wird JTAPI zum Starten und Stoppen der Aufzeichnung von Anweisungen beim Abrufen von Anrufstatistiken für die Analyse sowie zum Einblenden von Aufrufen in CRM-Anwendungen, automatisches Skripting und Remote-Anrufsteuerung verwendet.

JTAPI-Architektur

Cisco Unified JTAPI wird in einer Unternehmensumgebung eingesetzt und kombiniert Benutzerverfügbarkeit, Standort und Präferenzen in einer speziell angepassten Umgebung für präsenzbasiertes Routing.

Hier sind die Anwendungen von JTAPI:

• JTAPI kann zwei oder mehr Kombinationen von Telefonen und Leitungen überwachen oder entsprechende Benachrichtigungen erhalten.
• Contact Center-Anwendungen verwenden vollständiges Anrufmodell für JTAPI.
• JTAPI bietet folgende Funktionen:
  • Anrufsteuerung
  • Medienkontrolle
  • Medienverhandlung

JTAPI-Beobachtermodell

Im folgenden Diagramm wird das Provider-Observer-Modell erläutert, das JTAPI verwendet.

Beobachter

Beobachter-Schnittstellen

JTAPI basiert auf der Idee des Beobachters. Vom Betrachter bezieht es sich auf die Idee des einen, der die Ereignisse beobachtet. Sie können mehrere Beobachter zu verschiedenen Dingen innerhalb des Systems platzieren lassen. JTAPI verwendet Beobachter, um die Zustandsänderungen der Objekte zu erfahren.

So können Sie beispielsweise über Leitungen, Telefone, Terminals, Adressen usw. Beobachter entsenden, die sich über Zustandsänderungen informieren.

JTAPI-Anbietermodell

Im folgenden Diagramm wird das Provider-Modell erläutert, mit dem JTAPI arbeitet:

JTAPI-AnbietermodellAnbietermodell

Der JTAPI-Provider ist eine Verbindung von der Anwendung zum Call Manager oder CTI Manager. Anbieter werden verwendet, um Beobachter an die Objekte anzubringen. Sie können auch einen Beobachter an einen Anbieter anhängen. Anbieter werden verwendet, um über die an den Objekten durchgeführten Aktionen informiert zu werden. (Sie können auch die Kontrolle über die Geräte übernehmen, an die der Beobachter angeschlossen ist (von dem Anbieter, der diesen Beobachter angeschlossen hat).

JTAPI-Benutzer

Die nächsten Screenshots stammen von CUCM (links) und UCCX (rechts), die den JTAPI-Anwendungsbenutzer erläutern.

• Wenn Sie eine Anwendung starten und eine Verbindung zum CTI-Manager herstellen möchten, öffnen Sie einen Anbieter.
• Der Grund, einen Anbieter zu öffnen, besteht darin, dass Sie die Aktionen überwachen können, die auf den Geräten, Terminals usw. durchgeführt werden.
• Die Implementierung in CUCM erfolgt über einen Anwendungsbenutzer.
• Sie erstellen diesen Benutzer und geben Anmeldeinformationen an, damit er sich zuerst über CTI beim CUCM authentifizieren kann.
• Der im CUCM erstellte JTAPI-Anwendungsbenutzer ist also der Anbieter.
• Abgesehen von der reinen Überwachung müssen Sie sicherstellen, dass diese Geräte unter "Associated Devices" (Zugehörige Geräte) aufgeführt sind, um sicherzustellen, dass Sie die Geräte steuern können.

P1- und P2-Griffe

P1 und P2 sind die Provider Handles. Diese werden wichtig, wenn Sie mehrere Anbieter aus derselben Anwendung öffnen möchten. Von UCCX erstellen Sie zwei Anbieter, von denen der eine die Kontrolle über die CTI-Ports und Routenpunkte hat, der andere die Kontrolle über die Agententelefone namens RM-JTAPI-Anbieter. Als UCCX erstellen Sie den Anbieter, der zuerst die CTI-Ports und Routenpunkte steuert, d. h. den JTAPI P1-Anbieter. Der andere Provider, den Sie nach dem P1 erstellen, ist der P2-Provider oder der RmCm-Provider, der die Agenten-Geräte behandelt.

Wenn ein neues P1-Anrufereignis angezeigt wird, wissen Sie, dass es sich um ein Anrufereignis von einem CTI-Port oder einem CTI-Routing-Punkt handelt. Wenn Sie P2 new call event (P2 neuer Anruf) sehen, wissen Sie, dass es sich um einen Anruf vom Telefon aus handelt. Sie erstellen einen RM-JTAPI-Benutzer und einen JTAPI-Benutzer auf der CCX-Seite, aber auf der CUCM-Seite werden zwei JTAPI-Benutzer erstellt. Dies liegt daran, dass jeder CCX-Knoten seinen eigenen JTAPI-Benutzer erhält, diesen aber gemeinsam nutzt. Wenn Sie einen Trigger auf UCCX erstellen, wird er beiden JTAPI-Benutzern hinzugefügt. Beide Knoten öffnen einen Anbieter separat. Daher werden alle auf dem Routing-Point ergriffenen Maßnahmen auf beiden CCX-Knoten benachrichtigt.

Abgesehen davon befindet sich der sekundäre Knoten einfach nur dort und informiert Sie laufend darüber, dass er immer noch der sekundäre Knoten ist. Jeder Knoten verfügt über eine eigene Gruppe von CTI-Ports. Die CTI-Ports von Knoten 1 werden von jtapi_1 gesteuert. Die CTI-Ports von Knoten 2 werden von jtapi_2 gesteuert.

Wenn der Anruf am CTI-Routenpunkt ankommt, werden beide CCX-Knoten über das neue Anrufereignis informiert, aber der aktive CCX-Knoten antwortet dem Call Manager mit einer Umleitungsanforderung für einen seiner CTI-Ports, den er steuert.

Wenn eine IP mit einem CTI-Routing-Punkt in CUCM verglichen wird, handelt es sich um eine IP des CCX. Dies bedeutet jedoch nicht, dass ein bestimmter Knoten den Anruf weiterleitet.

In der Regel heben Sie die Verknüpfung des Geräts mit dem JTAPI-Benutzer auf und fügen es erneut hinzu. Der Grund dafür ist, dass wenn Sie die Verknüpfung aufheben, der Provider darüber informiert wird und alle Verbindungen entfernt, und dann, wenn er wieder hinzugefügt wird, der Beobachter wieder hinzugefügt wird und der Provider beginnt, es erneut mit offenen Anbieteranfragen zu überwachen. Sie sehen, dass neben dem Gerät, das in der Liste der gesteuerten Geräte hinzugefügt wird, auch das Kontrollkästchen Kontrolle über Gerät von CTI zulassen auf dem einzelnen Gerät vorhanden ist. Dadurch soll eine zusätzliche Präzision erreicht werden. Wenn also der Weiterleitungspunkt in der Liste der kontrollierten Geräte hinzugefügt wurde, das CTI-Kontrollkästchen jedoch nicht aktiviert ist, können Sie trotzdem über die Ereignisse an diesem Weiterleitungspunkt benachrichtigt werden. Es sind jedoch keine Aktionen zur Anrufsteuerung möglich.

Anrufablauf

Im Folgenden sind die Ereignissequenzen aufgeführt, die für den UCCX-Anruffluss relevant sind:

1. Wenn der Anruf am CTI-Routenpunkt ankommt, wird er an einen CTI-Port umgeleitet.
2. Der CTI-Port öffnet den Medienkanal mit dem ipvms-Treiber auf der uccx-Box.
3. Sobald Sie sich entschieden haben, dass der Mitarbeiter den Anruf entgegennehmen muss, wird ein Rücksprache-Transfer vom Port zum Mitarbeiter durchgeführt.
4. Ein neues Anrufereignis wird an den CTI-Routenpunkt gesendet.
5. Umleitungsanforderung wird an CTI-Port gesendet.
6. Der Status der Anruf-ID wird zu "Inaktiv".
7. Dann folgt ein weiteres Anrufereignis für den Anruf am CTI-Port.
8. Wenn die Umleitungsantwort 0 ist, ist sie gut. Wenn sie nicht 0 ist, bedeutet dies, dass sie fehlgeschlagen ist.
9. Dann senden Sie eine Anfrage zur Annahme des Anrufs (diese wird nicht beantwortet, nur am Port akzeptiert).
10. Akzeptieren Sie dann Step-Treffer für das Skript, d. h., wenn die Anfrage zur Anrufbeantwortung in Jtapi eingeht.

11. Dann erhalten Sie eine Antwort vom Port.

12. Anrufstatus ändert sich in Verbunden.

13. Nachdem die Antwort vom Port empfangen wurde, findet eine Medienverhandlung statt.

14. Der Port sendet eine open_logical_channel-Anforderung, in der er seinen Port und seine IP teilt, an die der Remote-Teilnehmer das RTP senden soll.

15. Vor dem Öffnen des logischen Kanals wird eine Verbindung mit dem IPVMS-Treiber in der UCCX-Box hergestellt und ein RTP-Stream geöffnet.

16. Das nächste Ereignis ist das start_receive-Ereignis, das uns die Informationen am anderen Ende mitteilt (d. h. die IP-Adresse und der Port des anrufenden Geräts).

17. Dann erhalten Sie das start_transmission-Ereignis wie jedes andere Mediensignal.

18. Jetzt hören Sie IVR und die Ansagen.

19. Wenn der Anruf nun einen Schritt im Skript erreicht, der die Weiterleitung des Anrufs an einen Agenten ermöglicht, wird eine CallSetupTransferRequest angezeigt.

20. Im Gegensatz zur ersten Nachricht handelt es sich hierbei um eine Weiterleitung mit Rücksprache und nicht um eine Weiterleitung.

21. Der Grund dafür ist die Weiterleitung mit Rücksprache: Wenn ein Mitarbeiter BEREIT ist, aber nicht an seinem Platz sitzt, und wir den Anruf weiterleiten, bleibt er einfach unbeantwortet. Wenn wir jedoch eine Weiterleitung mit Rücksprache durchführen, dann wird der Anruf wieder in die Warteschlange gestellt, wenn der Mitarbeiter nicht anwesend ist.

22. Wie bei jeder anderen Weiterleitung mit Rücksprache, dies ist der CTI-Anschluss, der zum ersten Mal auf dem Telefon auf die Weiterleitungstaste drückt.

23. Bei einem regulären Konsultationstransfer gibt es einen Medienpfad zwischen A und C. In diesem Fall weisen Sie CUCM jedoch an, dies nicht zu tun, da es keinen Sinn macht, Medien zwischen UCCX und dem Agenten einzurichten.

24. Sie machen also eine Weiterleitung mit Rücksprache, ohne ein Medium zwischen dem Agenten und dem CTI-Port zu wechseln.

25. An diesem Punkt hält der CTI-Port den Anrufer, und es wird ein geänderter Anrufstatus angezeigt, event=HOLD.

26. Jetzt sehen Sie ein neues Anrufereignis vom CTI-Port zum Agentengerät.(Verwenden der ursprünglichen Anruf-ID, aber einer Teilmenge davon und eines P2-Ereignisses.)

27. Wenn Sie die Anruf-ID des P2-Ereignisses durchsuchen, wird die nächste Nachricht als Anrufannahmeanfrage angezeigt. Dies bedeutet, dass der Agent den Anruf angenommen hat.

28. Wenn Sie wissen, dass der Agent den Anruf angenommen hat (mit P2) und dass sich der Anruf auch auf der CTI-Portseite im verbundenen Zustand befindet (mit P1), dann sehen Sie einen Routing Point (Weiterleitungspunkt). Dies bedeutet, dass die Weiterleitungstaste zum zweiten Mal gedrückt CallDirectTransferRequestwurde.

29. Nun, da der CTI-Port weiß, dass der Agent den Anruf angenommen hat, gibt es keinen Punkt warten, es sendet sofort eine, CallDirectTransferRequest die der CTI-Port ist, drücken Sie die Transfer-Taste zum zweiten Mal, wie oben erläutert.

30. Nun, der ursprüngliche Anrufabschnitt (derjenige, der auf Halten war) ist derjenige, der überlebt.

31. Die andere Anrufstrecke wird zerstört (zwischen Port und Agent).

32. An diesem Punkt werden CUCM und UCCX aus dem Bild und RTP zwischen dem Anrufer und dem Agenten über Gateway eingerichtet.

Im nächsten Diagramm wird der oben erwähnte Anruffluss kurz erläutert.

JTAPI-Anrufflussübersicht

Fehlerbehebung

Aktivieren und Sammeln von JTAPI-Protokollen

JTAPI-Debugging aktivieren

Überprüfen Sie diese Schritte, um JTAPI-Debugging-Ebenen zu aktivieren.

1. Bei UCCX anmelden
2. Rufen Sie CCX Serviceability auf.
3. Gehe zu Spur.
4. Gehen Sie zu Konfiguration.
5. Wählen Sie im Dropdown-Menü "Service auswählen" die Option Cisco Unified CM Telefony Client aus.
6. Aktivieren Sie das Kontrollkästchen Debuggen.
7. Aktivieren Sie alle Kontrollkästchen mit Ausnahme von MISC_DEBUGGING.

JTAPI-Debugging erfassen

Bitte überprüfen Sie diese Schritte, um JTAPI-Debug-Ebenen von RTMT oder CLI zu aktivieren.

Von RTMT

1. Melden Sie sich beim CCX Real Time Monitoring Tool an.
2. Klicken Sie auf Trace & Log Central.
3. Klicken Sie auf Dateien sammeln.
4. Wählen Sie JTAPI Client für alle Server aus.
5. Klicken Sie auf Next (Weiter).
6. Wählen Sie die Zeitstempel und den Speicherort aus, an dem die Protokolldateien gespeichert werden sollen.

Von CLI

JTAPI-Protokollspeicherort

activelog /uccx/log/JTAPI

Befehl zum Erfassen der JTAPI-Protokolle:

Datei get activelog /uccx/log/JTAPI/* recurs compress

Syntax:

Datei {activelog|inactivelog|install}-Dateispezifikation abrufen [Optionen]

Datei-Spezifikation obligatorische Datei zu übertragen

Optionen Optionale Reltime Monate|Wochen|Tage|Stunden|Minuten Zeitwert

                                 abstim hh:mm:MM/TT/JJ hh:mm:MM/TT/JJ

                                 Matchregex

                                 wiederkehren

                                 verdichten

5 Möglichkeiten zum Herunterladen der Protokolle basierend auf dem Zeitstempel

reltime: Relativer Zeitraum, angegeben als Minuten | Stunden | Tage | Wochen | Monatswert

abstime: Absoluter Zeitraum, angegeben als hh:mm:MM/TT/JJ hh:mm:MM/TT/JJ

match - Übereinstimmung mit einer bestimmten Zeichenfolge im Dateinamen, angegeben als Zeichenfolgenwert

recurs - Alle Dateien abrufen, einschließlich Unterverzeichnisse

komprimieren-Option können Sie die Dateien in einem Zip-Format herunterladen.

Referenzlinks

• JTAPI-Entwicklerhandbuch
• UCCX-Nachverfolgungsebenen