Verständnis und Fehlerbehebung bei Finesse BOSH-Implementierungen
Inhalt
Einleitung
In diesem Dokument wird die Architektur von Finesse-Verbindungen beschrieben, die BOSH verwenden, und es wird beschrieben, wie BOSH-Verbindungsprobleme diagnostiziert werden können.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Cisco Finesse
- Unified Contact Center Enterprise (UCCE)
- Unified Contact Center Express (UCCX)
- Webbrowser-Entwicklungstools
- Windows- und/oder Mac-Administration
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Cisco Finesse 9.0(1) - 11.6(1)
- UCCX 10.0(1) - 11.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 Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Verbindungen, die bidirektionale Streams über synchrones HTTP verwenden, werden als BOSH bezeichnet.
Verständnis der Finesse BOSH-Implementierung
XMPP verstehen
Extensible Messaging and Presence Protocol (XMPP) (auch als Jabber bekannt) ist ein Stateful-Protokoll in einem Client-Server-Modell. XMPP ermöglicht die schnelle Bereitstellung kleiner strukturierter XML-Daten (eXtensible Markup Language) von einer Einheit an eine andere. XMPP/Jabber wird in großem Umfang in Instant Messaging- (IM) und Presence-Anwendungen eingesetzt.
Alle XMPP-Einheiten werden durch ihre Jabber-ID (JID) identifiziert.
JID-Adressierungsschema: user@domain/resource
| Benutzer |
Client-Benutzername auf dem XMPP-Server oder Name des Konferenzraums |
| Domäne |
Vollqualifizierter Domänenname (FQDN) des XMPP-Servers |
| Ressource |
Kennung der spezifischen Einheit/des Endpunkts des Benutzers (z. B. Laptop, Smartphone usw.), Sitzungskennung oder Name des öffentlichen Unterknotens |
XMPP-Nachrichten werden als Strophen bezeichnet. In XMPP gibt es drei Kernstrophen:
1. <Nachricht>: eine Richtung, ein Empfänger
2. <Präsenz>: eine Richtung, zu vielen veröffentlichen
3. <iq>: Info/Abfrage - Anfrage/Antwort
Alle Strophen haben zu und von Adressen und die meisten Strophen haben auch type, id und xml:langattribute.
| Stanza-Attribut |
Zweck |
| zu |
Ziel-JID |
| von |
Quell-JID |
| typ |
Zweck der Nachricht |
| ID |
eindeutige Kennung zur Verknüpfung einer Anforderung mit einer Antwort für <iq> Strophen |
| xml:lang |
definiert die Standardsprache für jede für Menschen lesbare XML-Datei in der Strophe |
Beispiel-XMPP-Nachricht
<message to='person1@example' from='person2@example' type='chat'>
<subject> Team meeting </subject>
<body>Hey, when is our meeting today? </body>
<thread>A4567423</thread>
</message>
XMPP-Implementierung mit Finesse
Wenn eine Webanwendung mit XMPP arbeiten muss, treten mehrere Probleme auf. Browser unterstützen XMPP über Transmission Control Protocol (TCP) nicht nativ, sodass der gesamte XMPP-Datenverkehr von einem Programm verarbeitet werden muss, das im Browser ausgeführt wird. Webserver und Browser kommunizieren über HTTP-Nachrichten (HyperText Transfer Protocol), sodass Finesse und andere Webanwendungen XMPP-Nachrichten in HTTP-Nachrichten einbinden.
Die erste Schwierigkeit bei diesem Ansatz besteht darin, dass HTTP ein Stateless-Protokoll ist. Das bedeutet, dass jede HTTP-Anfrage nicht mit einer anderen Anfrage in Zusammenhang steht. Dieses Problem kann jedoch mit anwendbaren Mitteln gelöst werden - beispielsweise durch den Einsatz von Cookies/Postdaten.
Die zweite Schwierigkeit ist das unidirektionale Verhalten von HTTP. Nur der Client sendet Anfragen, und der Server kann nur antworten. Da der Server keine Daten per Push bereitstellen kann, ist die Implementierung von XMPP über HTTP unnatürlich.
Dieses Problem tritt in der ursprünglichen XMPP-Core-Spezifikation (RFC 6120), in der XMPP an TCP gebunden ist, nicht auf. Wenn Sie jedoch das Problem mit XMPP angehen möchten, das beispielsweise an HTTP gebunden ist, da Javascript HTTP-Anfragen senden kann, gibt es zwei mögliche Lösungen. Für beide wird eine Brücke zwischen HTTP und XMPP benötigt.
Die vorgeschlagenen Lösungen sind:
1. Polling (Legacy-Protokoll): wiederholte HTTP-Anfragen, die nach neuen, in XEP-0025 definierten Daten fragen: Jabber HTTP Polling
2. Langes Polling wird auch als BOSH bezeichnet: Transportprotokoll, das die Semantik einer langlebigen, bidirektionalen TCP-Verbindung zwischen zwei Einheiten emuliert, indem mehrere synchrone HTTP-Anfrage/Antwort-Paare effizient verwendet werden, ohne dass häufiges Polling gemäß XEP-0124: HTTP Binding und erweitert durch XEP-0206: XMPP Over BOSH erforderlich ist.
Finesse implementiert BOSH, da es in Bezug auf die Serverauslastung und den Datenverkehr sehr effizient ist. Der Grund für die Verwendung von BOSH besteht darin, die Tatsache zu vertuschen, dass der Server nicht sofort antworten muss, wenn eine Anfrage eingeht. Die Antwort wird bis zu einem bestimmten Zeitpunkt verzögert, bis der Server über Daten für den Client verfügt. Anschließend wird sie als Antwort gesendet. Sobald der Client die Antwort erhält, stellt er eine neue Anforderung usw.
Der Finesse Desktop-Client (Web-Anwendung) stellt alle 30 Sekunden eine veraltete BOSH-Verbindung über den TCP-Port 7443 her. Wenn nach 30 Sekunden keine Updates vom Finesse-Benachrichtigungsdienst vorliegen, sendet der Benachrichtigungsdienst eine HTTP-Antwort mit 200 OK und einem (fast) leeren Antworttext. Wenn der Notification Service z.B. über ein Update bei Vorliegen eines Agenten oder eines Dialogereignisses (Call) verfügt, werden die Daten sofort an den Finesse Web Client gesendet.
Finesse XMPP-Anfrage/-Antwort (Beispiel)
Dieses Beispiel zeigt die erste XMPP-Nachrichtenanforderungsantwort, die vom Finesse-Client und dem Finesse-Server gemeinsam verwendet wird, um die BOSH-Verbindung einzurichten.
Finesse client request:
<body xmlns="http://jabber.org/protocol/httpbind" xml:lang="en-US" xmlns:xmpp="urn:xmpp:xbosh" hold="1" ver="1.9" to="fin1.ucce.local" wait="30" xmpp:version="1.0" from="47483648@fin1.ucce.local" rid="704654808"/>
Finesse server response:
<body xmlns="http://jabber.org/protocol/httpbind" xmlns:stream="http://etherx.jabber.org/streams" authid="26779701" sid="26779701" secure="true" requests="4" inactivity="60" polling="5" wait="30" hold="1" ack="704654808" maxpause="300" ver="1.6"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features></body>
Zusammenfassung:
- Der Finesse-Web-Client hat eine veraltete HTTP-Verbindung (http-bind) zum Finesse-Server über den TCP-Port 7443 eingerichtet. Dies wird als lange BOSH-Umfrage bezeichnet.
- Der Finesse Notification Service ist ein Presence-Service, der Updates zum Status eines Agenten, einen Anruf usw. bereitstellt.
- Wenn der Benachrichtigungsdienst über eine Aktualisierung verfügt, antwortet er auf die HTTP-Bind-Anforderung mit der Statusaktualisierung als XMPP-Nachricht im HTTP-Antworttext.
- Wenn 30 Sekunden nach Empfang der HTTP-Bind-Anforderung keine Statusaktualisierungen vorliegen, antwortet der Benachrichtigungsdienst ohne Statusaktualisierungen, damit der Finesse-Webclient eine weitere HTTP-Bind-Anforderung senden kann. Auf diese Weise kann der Benachrichtigungsdienst feststellen, dass der Finesse-Web-Client immer noch eine Verbindung zum Benachrichtigungsdienst herstellen kann und dass der Agent den Browser nicht geschlossen oder den Computer nicht in den Ruhezustand versetzt hat usw.
Finesse XMPP-Nachrichten und XMPP-Knoten verstehen
Finesse implementiert auch die XMPP-Spezifikation XEP-0060: Publish-Subscribe. Der Zweck dieser Spezifikation ist es, dem XMPP-Server (Benachrichtigungsdienst) zu ermöglichen, Informationen abzurufen, die an XMPP-Knoten (Themen) veröffentlicht werden, und dann XMPP-Ereignisse an Entitäten zu senden, die für den Knoten abonniert sind. Im Fall von Finesse sendet der CTI-Server (Computer Telefony Integration) CTI-Nachrichten an den Finesse-Webservice, um Finesse über Konfigurationsaktualisierungen zu informieren, wie z. B. die Erstellung eines Agenten oder einer CSQ (Contact Service Queue) oder Informationen zu einem Anruf. Diese Informationen werden dann in eine XMPP-Nachricht umgewandelt, die der Finesse-Webdienst an den Finesse Notification-Dienst übermittelt. Der Finesse Notification Service sendet XMPP über BOSH-Nachrichten an Agenten, die für bestimmte XMPP-Knoten registriert sind.
Einige der im Finesse Web Services Developer Guide definierten Finesse API-Objekte sind XMPP-Knoten. Agenten- und Supervisor-Webclients von Finesse können Ereignisaktualisierungen für einige dieser XMPP-Knoten abonnieren, um aktuelle Informationen über Echtzeitereignisse (z. B. Anrufereignisse, Zustandsereignisse usw.) zu erhalten. Diese Tabelle zeigt die XMPP-Knoten, die pubsub aktiviert sind.
| Finesse API-Objekt |
Zweck |
Abonnement |
| /finesse/api/User/<LoginID> |
Zeigt den Status und die Teamzuordnung des Agenten an. |
Agenten und Supervisoren |
| /finesse/api/User/<LoginID>/Dialogs |
Zeigt die Anrufe an, die vom Mitarbeiter bearbeitet wurden. |
Agenten und Supervisoren |
| /finesse/api/User/<LoginID>/ClientLog |
Wird zum Erfassen von Client-Protokollen über die Schaltfläche Send Error Report (Fehlerbericht senden) verwendet. |
Agenten und Supervisoren |
| /finesse/api/User/<LoginID>/Queue/<queueID> |
Zeigt Warteschlangenstatistikdaten an (falls aktiviert) |
Agenten und Supervisoren |
| /finesse/api/Team/<TeamID>/Benutzer |
Zeigt die Agenten an, die zu einem bestimmten Team gehören, einschließlich Statusinformationen |
Supervisoren |
| /finesse/api/SystemInfo |
Zeigt den Status des Finesse-Servers an. Ermittelt, ob ein Failover erforderlich ist |
Agenten und Supervisoren |
Beispiel 1: Verwenden von Pidgin zum Anzeigen von Finesse XMPP-Knoten
Schritt 1: Laden Sie den XMPP-Client Pidgin herunter, und installieren Sie ihn.
Schritt 2: Navigieren Sie zu Konten > Ändern > Grundlegend, und konfigurieren Sie die Anmeldeoptionen:
- Protokoll: XMPP
- Benutzername: Anmelde-ID für einen beliebigen Agenten
- Domäne: FQDN des Finesse-Servers
- Ressource: Platzhalter - jeder Wert kann verwendet werden, z. B. test
- Kennwort: Agent-Kennwort
- Aktivieren Sie das Kontrollkästchen Kennwort speichern.
Schritt 3: Navigieren Sie zu Konten > Ändern > Erweitert, und konfigurieren Sie:
- Verbindungssicherheit: Falls verfügbar, Verschlüsselung verwenden
- Aktivieren Sie das Kontrollkästchen Klartext zulassen, um andere unverschlüsselte Streams zu erstellen.
- Verbindungsport: 5222. Verwenden Sie den Standardport 5222. Dieser Port ist für externe XMPP-Clients erforderlich. Finesse Desktop-Clients verwenden 7443. Verwenden Sie nicht den Port 7443.
- Verbindungsserver: Finesse-Server FQDN
Schritt 4: Navigieren Sie zu Tools > Plugins, und aktivieren Sie die XMPP-Konsole.
Schritt 5: Navigieren Sie zu Extras > XMPP-Konsole > XMPP-Konsole, um die XMPP-Konsole zu öffnen.
Schritt 6: Führen Sie diese <iq>-Meldung aus, um alle vorhandenen XMPP-Knoten anzuzeigen.
Beispiele:
In einer Laborumgebung mit zwei konfigurierten Agenten und zwei CSQs ist diese Ausgabe in der Finesse-Antwort enthalten:
Beispiel 2: Verwenden der Registerkarte Netzwerk der Browser-Entwicklertools zum Anzeigen von HTTP-Nachrichten
Jeder Browser verfügt über eine Reihe von Entwicklungstools. Auf der Registerkarte "Netzwerk" der Entwicklungstools werden die vom Finesse-Webclient (Browser) gesendeten und empfangenen HTTP-Nachrichten angezeigt. Dieses Bild zeigt beispielsweise, wie der Finesse-Webclient eine SystemInfo-Anfrage sendet, die den Finesse-Tomcat-Status jede Minute als Failover-Prüfung überprüft. Zusätzlich werden auch die HTTP-Bind-Meldungen der BOSH-Verbindung angezeigt. Der Finesse-Server sendet innerhalb von 30 Sekunden eine Antwort zurück, wenn auf den XMPP-Knoten, für die der Web-Client abonniert ist, keine Updates zur Veröffentlichung vorhanden sind.
Fehlerbehebung: Fehlermeldung bei BOSH-Verbindungstrennung
Wenn eine BOSH-Verbindung getrennt wird, wird der Fehler Verbindung mit {Finesse Server FQDN} verloren. Bitte warten Sie, bis ein erreichbarer Finesse-Server gefunden wurde... wird in einem roten Banner oben auf dem Finesse-Desktop angezeigt.
Diese Meldung wird angezeigt, da derzeit keine XMPP-Abonnementereignisse vom Cisco Finesse Notification Service empfangen werden können. Daher können Statusinformationen und Anrufdetails nicht auf dem Mitarbeiter-Desktop angezeigt werden.
Bei UCCX wird der Agent 60 Sekunden nach dem Trennen der Browserverbindung in den Abmeldestatus versetzt. Der Agent kann sich im Status Ready (Bereit) oder Not Ready (Nicht Bereit) befinden, damit die Abmeldung erfolgt.
Für UCCE benötigt Finesse bis zu 120 Sekunden, um zu erkennen, wann ein Agent den Browser schließt oder der Browser abstürzt, und Finesse wartet 60 Sekunden, bevor eine erzwungene Abmeldeanforderung an den CTI-Server gesendet wird, die den CTI-Server veranlasst, den Agenten in den Zustand "Nicht bereit" zu versetzen. Unter diesen Bedingungen kann es bis zu 180 Sekunden dauern, bis Finesse den Agenten abmeldet. Im Gegensatz zu UCCX wechselt der Agent in den Status "Not Ready" (Nicht bereit) und nicht in den Status "Logout" (Abmelden).
Weitere Informationen zum Verhalten von UCCE Finesse Desktop finden Sie im Abschnitt "Desktop Behavior" des Kapitels "Cisco Finesse Failover Mechanism" im Cisco Finesse Administration Guide.
Protokollanalyse
Die Finesse- und UCCX-Benachrichtigungsdienstprotokolle können über RTMT oder die CLI erfasst werden:
file get activelog /desktop recurs compress
Debug Notification Service-Protokolle
Aktivieren Sie die Benachrichtigungs-Service-Debug-Protokolle von Unified Contact Center Express (UCCX) wie folgt:
admin:utils uccx notification-service log enable
WARNING! Enabling Cisco Unified CCX Notification Service logging can affect system performance
and should be disabled when logging is not required.
Do you want to proceed (yes/no)? yes
Cisco Unified CCX Notification Service logging enabled successfully.
NOTE: Logging can be disabled automatically if Cisco Unified CCX Notification Service is restarted.
Aktivieren Sie die Benachrichtigungs-Service-Debug-Protokolle von Unified Contact Center Enterprise (UCCE) (Finesse Standalone) wie folgt:
admin:utils finesse notification logging enable
Checking that the Cisco Finesse Notification Service is started...
The Cisco Finesse Notification Service is started.
Cisco Finesse Notification Service logging is now enabled.
WARNING! Cisco Finesse Notification Service logging can affect system performance
and should be disabled when logging is not required.
Note: Logging can be disabled automatically if you restart the Cisco Finesse Notification Service
Diese Protokolle befinden sich im Ordner /desktop/logs/openfire und haben den Namen debug.log.
Wie im Bild gezeigt, zeigt der Benachrichtigungsdienst (Openfire) debug.log die HTTP-Bindung mit Desktop sowie die IP-Adresse und den Port des Agent-PCs.
Wie im Bild gezeigt, zeigt die letzte aktive 0 ms, dass die Sitzung noch aktiv ist.
Das Schließen der inaktiven Sitzung durch OpenFire zeigt an, dass die Agenten-Abmeldung innerhalb von 60 Sekunden ausgelöst werden kann, wobei Finesse eine erzwungene Abmeldung mit dem Ursachencode 255 an den CTI-Server senden kann. Das tatsächliche Verhalten des Desktops unter diesen Bedingungen hängt von der Einstellung für "Logout on Agent Disconnect (LOAD)" in UCCE ab. In UCCX ist dies immer das Verhalten.
Wenn der Finesse-Client keine HTTP-Bind-Meldungen an den Finesse-Server sendet, können die Protokolle die Sitzungslaufzeit und das Schließen der Sitzung anzeigen.
2017.06.17 00:14:34 Session (id=f382a015) was last active 0 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:15:04 Session (id=f382a015) was last active 13230 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:15:34 Session (id=f382a015) was last active 43230 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:16:04 Session (id=f382a015) was last active 63231 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:17:04 Unable to route packet. No session is available so store offline. <message from="pubsub. xxxxx.xxxx.xxx.cisco. com" to="1001003@xxxxx.xxxx.xxx.cisco.com.cisco.com" id="/finesse/api/User/1001003__1001003@xxxxx.xxxx.xxx.cisco.com__o5Aqb"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="/finesse/api/User/1001003"><item id="0d78a283-466d-4477-a07e-6e33a856fce388"><notification xmlns="http://jabber.org/protocol/pubsub"><Update>
Info Notification Service-Protokolle
Diese Protokolle befinden sich im Ordner /desktop/logs/openfire und haben den Namen info.log. Wenn der Finesse-Client keine HTTP-Bind-Meldungen an den Finesse-Server sendet, können die Protokolle anzeigen, dass die Sitzung inaktiv wird.
2017.06.17 00:16:04 Closing idle session (id=f382a015): 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
after inactivity for more than threshold value of 60 2017.06.17 00:16:04 A session is closed for 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
Webservices-Protokolle
Diese Protokolle befinden sich im Ordner /desktop/logs/webservices und haben den Namen Desktop-webservices.YYYY-MM-DDTHH-MM-SS.sss.log. Wenn der Finesse-Client innerhalb der festgelegten Zeit keine HTTP-Bind-Meldungen an den Finesse-Server sendet, kann aus den Protokollen hervorgehen, dass der Agent nicht mehr verfügbar ist, und 60 Sekunden später kann es zu einem präsenzgesteuerten Logout kommen.
0000001043: XX.XX.XX.XXX: Jun 17 2017 00:16:04.630 +0530: %CCBU_Smack Listener Processor (1)-6-PRESENCE_NOTIFICATION_RECIEVED: %[FROM JID=1001003@xxxxx.xxxx.xxx.cisco.com/desktop][PRESENCE_TYPE=unavailable]:Finesse received a presence notifcation 0000000417: XX.XX.XX.XXX: Jun 17 2017 00:16:04.631 +0530: %CCBU_Smack Listener Processor (1)-6-UNSUBSCRIBE_REQUEST_SUCCESS: %[NodeId=/finesse/api/User/1001003/ClientLog][user_id=1001003@xxxxx.xxxx.xxx.cisco.com]: Sucessfully unsubscribed from a node on the XMPP server 0000001044: XX.XX.XX.XXX: Jun 17 2017 00:16:04.631 +0530: %CCBU_Smack Listener Processor (1)-6-AGENT_PRESENCE_MONITOR: %[message_string=Adding agent 1001003 into the expiry hash.]: 0000001051: XX.XX.XX.XXX: Jun 17 2017 00:16:35.384 +0530: %CCBU_pool-8-thread-1-6-AGENT_PRESENCE_MONITOR: %[message_string=[Expired] Removed agent from cache 1001003]: 0000001060: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.632 +0530: %CCBU_CoreImpl-worker12-6-PRESENCE DRIVEN LOGOUT: %[agent_id=1001003]: Performing CTI Logout on basis of the agents unavailable presence 0000001061: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.633 +0530: %CCBU_CoreImpl-worker12-6-MESSAGE_TO_CTI_SERVER: %[cti_message=Invoke id :39 , agentstate :
1, workmode : 0, reason code: 255, forceflag :1, agentcapacity: 1, agentext: 1001003, agentid: 1001003, supervisorid: null, ssoFlag=false][cti_message_name=SetAgentStateReq]: Message going to the backend cti server 0000001066: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.643 +0530: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=1 (LOGOUT), stateDuration=0,
skillGroupNumber=-1, skillGroupPriority=0, agentState=1 (LOGOUT), eventReasonCode=255, numFltSkillGroups=0, CTIClientSignature=null, agentID=1001003, agentExtension=1001003, agentInstrument=null, agentID_Long=1001003,
duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[], MRDId=1, agentMode=0]CTIMessageBean [invokeID=null, cti_sequence_id=105,
msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1497638824642,"CTI_MSG_DISPATCH":1497638824643}, msgName=AgentStateEvent, deploymentType=CCX]][cti_response_time=1][dispatch_phase=DnD-CHECKPOINT-3B]:
Decoded Message to Finesse from backend cti server
Allgemeine Gründe für BOSH-Trennung
BOSH-Verbindungen werden vom Web-Client eingerichtet, und der Finesse-Server bestimmt, ob der Agent-Presence-Status nicht verfügbar ist. Bei diesen Problemen handelt es sich fast immer um clientseitige Probleme in Bezug auf den Browser, den Agentencomputer oder das Netzwerk, da der Verbindungsstart vom Client abhängt.
Problem - Verbindung der Agenten zu verschiedenen Zeiten getrennt (Client-seitiges Problem)
Empfohlene Maßnahmen
Überprüfen Sie, ob folgende Probleme vorliegen:
1. Netzwerkproblem:
- Firewall-Regeln und -Protokolle überprüfen - TCP-Port 7443 darf nicht blockiert oder gedrosselt werden
- Verwenden Sie einen HTTP-Web-Traffic-Sniffer wie Fiddler® oder Wireshark®, um zu bestätigen, dass der Browser HTTP-Bind-Anfragen über den TCP-Port 7443 sendet und Antworten empfängt.
- Überprüfen Sie alle Netzwerkgeräte/Schnittstellen zwischen dem Agent-Computer und dem Finesse-Server auf übermäßige Verzögerungen oder Paketverluste.
- Traceroute kann zur Ermittlung des Pfads und von Verzögerungen nützlich sein.
- Auf einem Microsoft® Windows® PC: tracert {Finesse Server IP | Finesse-Server - FQDN}
- Auf einem Mac®: Traceroute {Finesse Server IP | Finesse-Server - FQDN}
- In der Cisco IOS® Software können die Schnittstellenstatistiken überprüft werden: Schnittstellen anzeigen
- Weitere Informationen finden Sie unter Fehlerbehebung bei Einbrüchen von Eingabewarteschlangen und Einbrüchen von Ausgabewarteschlangen
- Traceroute kann zur Ermittlung des Pfads und von Verzögerungen nützlich sein.
- Sammeln von Finesse-Client-Protokollen für einen Test-Agenten Client-Protokolle können auf drei Arten erfasst werden:
- Webkonsolen-Protokolle für Browser
- Drücken Sie auf der Seite Finesse die Schaltfläche Send Error Report (Fehlerbericht senden), und sammeln Sie die Finesse-Serverprotokolle. Die Protokolle befinden sich unter /desktop/logs/clientlogs.
- Melden Sie sich über https://<Finesse-FQDN>/desktop/localLog an, und erfassen Sie die Protokolle, nachdem das Problem aufgetreten ist.
Der Client stellt jede Minute eine Verbindung zum Finesse-Server her, um die Drift und die Netzwerklatenz zu berechnen:
<PC date-time with GMT offset>: : <Finesse FQDN>: <Finesse server date-time with offset>:
Header : Client: <date-time>, Server: <date-time>, Drift: <drift> ms, Network Latency (round trip): <RTT> ms
2019-01-11T12:24:14.586 -05:00: : fin1.ucce.local: Jan 11 2019 11:24:14.577 -0600: Header : Client: 2019-01-1
Bei Protokollsammlungsproblemen finden Sie weitere Informationen unter Problembehandlung bei Cisco Finesse Desktop Persistent Logging Problem
2. Nicht unterstützter Browser und/oder Version:
Verwenden Sie die unterstützten Browser/Versionen und Einstellungen gemäß den Kompatibilitätsmatrizen:
3. Browserzustand aufgrund des Inhalts/der Verarbeitung anderer Unterfenster/Fenster:
Überprüfen Sie den Agenten-Workflow, um festzustellen, ob sie:
- In der Regel gibt es Registerkarten oder Fenster, auf denen ständig andere Echtzeitanwendungen ausgeführt werden, z. B. Musik-/Video-Streaming, WebSocket-Verbindungen, benutzerdefinierte CRM-Webclients usw.
- Sehr viele Registerkarten oder Fenster geöffnet haben
- Browser-Caching deaktiviert haben
- Ihren Browser über einen langen Zeitraum laufen lassen und den Browser nicht am Ende des Arbeitstages schließen
4. Computer in den Schlaf versetzt:
Überprüfen Sie, ob der Agent den Computer in den Energiesparmodus versetzt, bevor Sie sich von Finesse abmelden, oder ob der Zeitgeber für die Einstellung des Energiesparmodus sehr niedrig ist.
5. Hoher CPU- oder hoher Speicherbedarf auf dem Client-Computer:
- Wenn der Agent-Browser in einer freigegebenen Umgebung wie Microsoft Windows Remote Desktop Services, Citrix® XenApp® oder Citrix XenDesktop® ausgeführt wird, stellen Sie fest, ob die Leistung des Browsers von der Anzahl der Benutzer abhängt, die den Browser gleichzeitig ausführen.
- Stellen Sie sicher, dass der richtige Arbeitsspeicher und die richtigen CPU-Ressourcen auf Basis der Anzahl der Benutzer konfiguriert werden.
- Probleme bei der Nutzung der Computerressourcen überprüfen:
- Windows:
- Windows PowerShell Get-Counter-Befehl, der % der CPU-Zeit, MB verfügbaren Arbeitsspeichers und % des verwendeten Arbeitsspeichers alle 2 Sekunden überprüft: Get-Counter -Counter "\Processor(_Total)\% Processor Time","\Memory\Available MBytes","\Memory\% Committed Bytes In Use" -SampleInterval 2 -Continuous
- Als Alternative zur Verwendung von PowerShell zum Anzeigen der Windows-Leistungsindikatoren kann Windows Performance Monitor verwendet werden.
- Der Task-Manager kann verwendet werden, um Live-CPU- und Speicherstatistiken global und auf Prozessbasis anzuzeigen.
- Mac:
- Terminal Top-Befehl, der die Live-Gesamt-CPU und den Arbeitsspeicher überprüft: top
- Prozesse überprüfen und nach CPU-Auslastung sortieren: top -o CPU
- Prozesse überprüfen und nach Speichernutzung sortieren: top -o MEM
- Activity Monitor kann verwendet werden, um Live-CPU- und Arbeitsspeicherstatistiken global und auf Prozessbasis anzuzeigen
- Terminal Top-Befehl, der die Live-Gesamt-CPU und den Arbeitsspeicher überprüft: top
- Windows:
6. Gadgets von Drittanbietern, die unerwartete, problematische Aktivitäten im Hintergrund ausführen:
Testen Sie das Verhalten des Finesse-Desktops, wenn alle Gadgets von Drittanbietern entfernt wurden.
7. NTP-Problem auf Server oder Client:
- Überprüfen Sie utils ntp status auf dem Finesse Publisher-Server, um sicherzustellen, dass die NTP-Serverschicht 4 oder niedriger ist.
- Überprüfung der Drift und Netzwerklatenz in den Client-Protokollen
Problem - Alle Agenten trennen gleichzeitig die Verbindung (serverseitiges Problem)
Empfohlene Maßnahmen
Überprüfen Sie, ob folgende Probleme vorliegen:
1. Cisco Unified Communications Manager CTIManager-Dienst wird getrennt. Wenn alle CTIManager-Anbieter für UCCX heruntergefahren sind oder abstürzen, wird den UCCX-Agenten der rote Bannerfehler angezeigt. In diesem Fall wird den UCCE-Agenten das rote Banner nicht angezeigt, aber Anrufe werden nicht richtig an die Agenten weitergeleitet.
- Überprüfen Sie, ob der Cisco CTIManager-Dienst auf den CUCM-Servern gestartet wird, die als CTI-Anbieter verwendet werden.
- Überprüfen Sie, ob der Cisco CTIManager-Dienst über die Ereignisanzeige abgestürzt ist. Die Anwendung meldet sich bei RTMT an, um zu sehen, ob der Cisco CTIManager-Dienst abgestürzt ist.
- Um Ereignisanzeige-Protokolle auf RTMT zu sammeln, navigieren Sie zu System > Tools > Trace and Log Central > Collect Files > Select System Services/Applications > Event Viewer-Application Log.
- Um die Ereignisanzeige-Anwendungsprotokolle in CLI zu sammeln, rufen Sie die Datei activelog /syslog/CiscoSyslog* abstime hh:mm:MM/TT/JJ hh:mm:MM/TT/JJ auf.
- So zeigen Sie Core Dumps in der CLI an: utils core active list
2. Der Finesse/UCCX-Benachrichtigungsdienst wurde beendet oder ist abgestürzt:
- Überprüfen Sie die Ereignisanzeige-Anwendungsprotokolle auf Fehler des Benachrichtigungsdiensts, oder stellen Sie fest, ob der Dienst beendet wurde.
- Überprüfen Sie, ob der Benachrichtigungsdienst aktiv ist: Dienstliste "utils"
- Überprüfen Sie, wann der Benachrichtigungsdienst heruntergefahren wurde: file search active log /desktop/logs/openfire "Openfire stop"
- Überprüfen Sie die Startzeiten des Benachrichtigungsdiensts: file search active log /desktop/logs/openfire "HTTP bind service started" (HTTP-Bindungsdienst gestartet).
- Suchen Sie nach Speicherabbildern des Benachrichtigungsdiensts, die nach einem Absturz entstanden sind: Dateiliste activelog /desktop/logs/openfire/*.hprof
- Überprüfen Sie, ob der Benachrichtigungsdienst auf Datenverkehr auf dem TCP-Port 7443 wartet: show open ports regexp 7443.*LISTEN
- Prüfen Sie, ob diese Fehler zutreffen (diese Fehler würden bei angemeldeten Agenten zu einem Anmeldefehler führen und bei bereits angemeldeten Agenten würde für diese Agenten die rote Bannernachricht Finesse disconnect angezeigt):
Starten Sie Cisco Finesse Tomcat und Notification Service neu, wenn ein Absturz vermutet wird. Dies wird nur bei einem Netzwerkausfall empfohlen. Andernfalls werden die Agenten bei einem Neustart vom Finesse-Server getrennt.
Schritte für UCCE:
- utils service stop Cisco Finesse Tomcat
- utils service stop Cisco Finesse Notification Service
- utils service start Cisco Finesse Tomcat
- utils service start Cisco Finesse Notification Service
Schritte für UCCX:
- utils service stop Cisco Finesse Tomcat
- utils service stop Cisco Unified CCX Notification Service
- utils service start Cisco Finesse Tomcat
- utils service start Cisco Unified CCX Notification Service
Fiddler verwenden
Die Konfiguration von Fiddler kann eine ziemlich schwierige Aufgabe sein, ohne die erforderlichen Schritte zu verstehen und zu verstehen, wie Fiddler funktioniert. Fiddler ist ein Man-in-the-Middle-Webproxy, der zwischen dem Finesse-Client (Webbrowser) und dem Finesse-Server steht. Aufgrund der gesicherten Verbindungen zwischen dem Finesse-Client und dem Finesse-Server erhöht sich die Komplexität der Fiddler-Konfiguration, um gesicherte Nachrichten anzuzeigen.
Häufiges Fiddler-Problem
Da Fiddler zwischen dem Finesse-Client und dem Finesse-Server steht, muss die Fiddler-Anwendung signierte Zertifikate für alle Finesse TCP-Ports erstellen, die Zertifikate erfordern:
Cisco Finesse Tomcat Service-Zertifikate
- Finesse Publisher-Server TCP 8445 (und/oder 443 für UCCE)
- Finesse Subscriber-Server TCP 8445 (und/oder 443 für UCCE)
Cisco Finesse (Unified CCX) Notification Service-Zertifikate
- Finesse Publisher-Server TCP 7443
- Finesse Subscriber-Server TCP 7443
Die HTTPS-Entschlüsselung muss aktiviert sein, damit Fiddler dynamisch Zertifikate für den Finesse-Server generieren kann. Diese Funktion ist nicht standardmäßig aktiviert.
Wenn die HTTPS-Entschlüsselung nicht konfiguriert ist, wird die ursprüngliche Tunnelverbindung zum Benachrichtigungsdienst angezeigt, der HTTP-Bind-Datenverkehr jedoch nicht. Fiddler zeigt nur:
Tunnel to <Finesse server FQDN>:7443
Anschließend müssen die von Fiddler signierten Finesse-Zertifikate vom Client als vertrauenswürdig eingestuft werden. Wenn diese Zertifikate nicht vertrauenswürdig sind, ist ein Übergang über die Phase der Herstellung der verschlüsselten Verbindung... der Finesse-Anmeldung nicht möglich.
In einigen Fällen funktioniert das Akzeptieren der Zertifikatausnahmen von der Anmeldung nicht, und die Zertifikate müssen vom Browser manuell als vertrauenswürdig eingestuft werden.
Beispiel für Konfigurationsschritte
Schritt 1: Fiddler herunterladen
Schritt 2: HTTPS-Entschlüsselung aktivieren. Navigieren Sie zu Extras > Optionen > HTTPS, und aktivieren Sie das Kontrollkästchen HTTPS-Datenverkehr entschlüsseln.
Schritt 3: Ein Warnmeldungsfeld wird geöffnet, in dem Sie gefragt werden, ob Sie dem Fiddler-Stammzertifikat vertrauen. Wählen Sie Ja aus.
Schritt 4: Ein Warnmeldungsfeld mit der Meldung "Sie sind im Begriff, ein Zertifikat von einer Zertifizierungsstelle (CA) zu installieren, die behauptet, Folgendes darzustellen: DO_NOT_TRUST_FiddlerRoot... Möchten Sie dieses Zertifikat installieren?" Wählen Sie Ja aus.
Schritt 5: Fügen Sie die Finesse Publisher- und Subscriber-Zertifikate manuell zum Zertifikatvertrauensspeicher des Computers oder Browsers hinzu. Stellen Sie die Ports 8445, 7443 und (nur für UCCE) 443 sicher. Auf Firefox kann dies beispielsweise einfach durchgeführt werden, ohne Zertifikate von der Seite "Finesse Operating System Administration" herunterzuladen:
Optionen > Suchen unter Optionen (Suche) > Zertifikate > Server > Ausnahme hinzufügen > Standort > Geben Sie https://<Finesse-Server>:Port für die entsprechenden Ports für beide Finesse-Server ein.
Schritt 6: Melden Sie sich bei Finesse an, und sehen Sie sich die http-bind-Meldungen an, die den Finesse-Client über Fiddler dem Finesse-Server überlassen.
Im angegebenen Beispiel zeigen die ersten 5 Nachrichten HTTP-Bind-Nachrichten, die vom Finesse-Server beantwortet wurden. Die erste Nachricht enthält 1571 Byte Daten, die im Nachrichtentext zurückgegeben werden. Der Text enthält ein XMPP-Update für ein Agent-Ereignis. Die letzte HTTP-Bind-Nachricht wurde vom Finesse-Client gesendet, hat jedoch keine Antwort vom Finesse-Server erhalten. Dies kann bestimmt werden, wenn das HTTP-Ergebnis NULL (-) und die Anzahl der Bytes im Antworttext NULL (-1) ist.
Detailliertere Ansicht der Daten:
Antworttext für XMPP-Nachricht:
Wireshark verwenden
Wireshark ist ein häufig verwendetes Paket-Sniffing-Tool, mit dem HTTPS-Datenverkehr gesniffen und decodiert werden kann. HTTPS-Datenverkehr ist HTTP-Datenverkehr, der über TLS (Transport Layer Security) gesichert wird. TLS gewährleistet Integrität, Authentifizierung und Vertraulichkeit zwischen zwei Hosts. Es wird häufig in Webanwendungen verwendet, kann jedoch mit jedem Protokoll verwendet werden, das TCP als Transportschichtprotokoll verwendet. Secure Sockets Layer (SSL) ist die frühere Version des TLS-Protokolls, das nicht mehr verwendet wird, da es unsicher ist. Diese Namen werden häufig synonym verwendet, und der Wireshark-Filter, der für SSL- oder TLS-Datenverkehr verwendet wird, ist ssl.
Schritt 1: Navigieren Sie auf dem Windows-PC des Agenten zu Systemsteuerung > System und Sicherheit > System > Erweiterte Systemeinstellungen Umgebungsvariablen...
Schritt 2: Navigieren Sie zu Benutzervariablen für Benutzer <Benutzername> > Neu...
Erstellen Sie eine Variable mit dem Namen SSLKEYLOGFILE.
Erstellen Sie eine Datei, um den SSL-Premaster-Schlüssel in einem privaten Verzeichnis zu speichern: SSLKEYLOGFILE=</path/to/private/directory/with/logfile>
Schritt 3: Wenn Firefox oder Chrome geöffnet sind, schließen Sie die Anwendungen. Nach dem erneuten Öffnen können sie mit dem Schreiben in die SSLKEYLOGFILE beginnen.
Schritt 4: Navigieren Sie in Wireshark zu Bearbeiten > Voreinstellungen...
Navigieren Sie zu Protokolle > SSL.
Schritt 5: Geben Sie den in Schritt 2 konfigurierten Speicherort der Datei für das geheime Protokoll des Vormasters ein.
Schritt 6: Verwenden Sie Wireshark filter tcp.port==7443 && ssl, die sichere HTTP-Kommunikation zwischen dem Finesse-Client und Finesse-Server (Notification Service) wird entschlüsselt gesehen.
Verwandte Fehler
- Cisco Bug-ID CSCva7280 - Finesse Tomcat und Openfire Crash für ungültige XML-Zeichen
- Cisco Bug-ID CSCva7235 - UCCX: Finesse Tomcat und Openfire-Absturz wegen ungültiger XML-Zeichen
Zugehörige Informationen
- XMPP-Spezifikationen
- XEP-0124: BOSH
- XEP-0060: Veröffentlichen-Abonnieren
- Firefox-Webkonsole
- Microsoft Edge-Webkonsole
- Chrome-Webkonsole
- Windows PowerShell
- Windows-Leistungsüberwachung
- Fehlerbehebung bei Unterbrechungen von Eingabe- und Ausgabewarteschlangen
- Windows Task-Manager
- Mac-Terminal
- MAC-Aktivitätsüberwachung
- Fiddler-Download
- Fiddler-Konfiguration
- Wireshark-Download
- Wireshark SSL-Verschlüsselung
- Technischer Support und Dokumentation für Cisco Systeme
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
31-May-2023 |
Aktualisierter Titel, Einführung, PII, voreingenommene Sprache, SEO, Alternativer Text, Branding-Anforderungen, Stilanforderungen, maschinelle Übersetzung, Gerunds, Formatierung. |
1.0 |
23-Jun-2017 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)