Comprendre la mise en oeuvre de Finesse BOSH et résoudre les problèmes de déconnexion de Finesse Agent Desktop Presence
Contenu
Introduction
Ce document décrit l'architecture derrière les connexions Finesse qui utilisent les flux bidirectionnels via HTTP synchrone (BOSH) et comment diagnostiquer les problèmes de connexion BOSH.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Cisco Finesse
- Unified Contact Center Enterprise (UCCE)
- Unified Contact Center Express (UCCX)
- Outils de développement de navigateur Web
- Administration Windows et/ou Mac
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Cisco Finesse 9.0(1) - 11.6(1)
- UCCX 10.0(1) - 11.6(2)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Présentation de la mise en oeuvre Finesse BOSH
Présentation de XMPP
Le protocole XMPP (Extensible Messaging and Presence Protocol) (également appelé Jabber) est un protocole avec état dans un modèle client-serveur. XMPP permet la livraison rapide de petits morceaux de données XML (eXtensible Markup Language) structurées d'une entité à l'autre. XMPP/Jabber est largement utilisé dans les applications de messagerie instantanée et de présence.
Toutes les entités XMPP sont identifiées par leur ID Jabber (JID).
Schéma d'adressage JID : user@domain/ressource
| utilisateur | nom d'utilisateur du client sur le serveur XMPP ou nom de la salle de conférence |
| domaine | Nom de domaine complet (FQDN) du serveur XMPP |
| ressource | identificateur de l'entité/point de terminaison spécifique de l'utilisateur (par exemple, ordinateur portable, smartphone, etc.), identificateur de session ou nom de noeud pubsub |
Les messages XMPP sont appelés stanzas. Il existe trois normes principales dans XMPP :
1. <message> : une direction, un destinataire
2. <présence> : une direction, publier à plusieurs
3. <iq> : info/query - requête/réponse
Tous les stanzas doivent être des types, id et xml : langattribute et de la plupart des stanzas.
| Attribut Stanza | Objectif |
| par | JID de destination |
| expéditeur | JID source |
| type | objet du message |
| id | identificateur unique utilisé pour lier une demande à une réponse pour <iq> stanzas |
| xml:lang | définit le langage par défaut pour tout XML lisible par l'homme dans la stanza |
Exemple de message XMPP
<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>
Implémentation XMPP avec Finesse
Si une application Web doit fonctionner avec XMPP, plusieurs problèmes se posent. Les navigateurs ne prennent pas en charge XMPP sur TCP (Transmission Control Protocol) en mode natif, de sorte que tout le trafic XMPP doit être géré par un programme qui s'exécute à l'intérieur du navigateur. Les serveurs Web et les navigateurs communiquent via des messages HTTP (HyperText Transfer Protocol). Finesse et d'autres applications Web encapsulent donc les messages XMPP dans des messages HTTP.
La première difficulté de cette approche est que HTTP est un protocole sans état. Cela signifie que chaque requête HTTP n'est liée à aucune autre requête. Cependant, ce problème peut être résolu par des moyens applicatifs, par exemple par l'utilisation de cookies/données de poste.
La deuxième difficulté est le comportement unidirectionnel du protocole HTTP. Seul le client envoie des requêtes et le serveur ne peut répondre que. L'incapacité du serveur à transmettre des données rend l'implémentation de XMPP sur HTTP peu naturelle.
Ce problème n'existe pas dans la spécification XMPP Core d'origine (RFC 6120), où XMPP est lié à TCP. Cependant, si vous voulez résoudre le problème avec XMPP lié à HTTP, par exemple, parce que Javascript peut envoyer des requêtes HTTP, il y a deux solutions possibles. Les deux nécessitent un pont entre HTTP et XMPP.
Les solutions proposées sont les suivantes :
1. Interrogation (protocole hérité) : requêtes HTTP répétées demandant de nouvelles données définies dans XEP-0025 : Sondage HTTP Jabber
2. L'interrogation longue est également appelée BOSH : protocole de transport qui émule la sémantique d'une connexion TCP bidirectionnelle de longue durée entre deux entités en utilisant efficacement plusieurs paires de requêtes/réponses HTTP synchrones sans nécessiter l'utilisation d'interrogation fréquente définie dans XEP-0124 : Liaison HTTP et étendue par XEP-0206 : XMPP sur BOSH
Finesse implémente BOSH car il est assez efficace du point de vue de la charge du serveur et du trafic. L'utilisation du BOSH a pour but de dissimuler le fait que le serveur n'a pas à répondre dès qu'il y a une demande. La réponse est retardée jusqu'à un délai spécifié jusqu'à ce que le serveur ait des données pour le client, puis elle est envoyée en tant que réponse. Dès que le client reçoit la réponse, il fait une nouvelle demande, etc.
Le client de bureau Finesse (application Web) établit une connexion BOSH stable sur le port TCP 7443 toutes les 30 secondes. Après 30 secondes, s'il n'y a pas de mises à jour du service de notification Finesse, le service de notification envoie une réponse HTTP avec 200 OK et un corps de réponse (presque) vide. Si le service de notification dispose d'une mise à jour sur la présence d'un agent ou d'un événement de dialogue (appel), par exemple, les données sont immédiatement envoyées au client Web Finesse.
Exemple de requête/réponse XMPP Finesse
Cet exemple montre la première réponse de requête de message XMPP partagée entre le client Finesse et le serveur Finesse pour configurer la connexion BOSH.
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>
Pour récapituler :
- Le client Web Finesse a une connexion HTTP périmée (http-bind) configurée sur le serveur Finesse via le port TCP 7443. C'est ce qu'on appelle un sondage de longue durée du BOSH.
- Le service de notification Finesse est un service de présence qui publie des mises à jour concernant l'état d'un agent, d'un appel, etc.
- Si le service de notification a une mise à jour, il répond à la requête http-bind avec la mise à jour d'état en tant que message XMPP dans le corps de la réponse HTTP.
- S'il n'y a pas de mises à jour d'état 30 secondes après réception de la demande http-bind, le service de notification répond sans aucune mise à jour d'état pour permettre au client Web Finesse d'envoyer une autre demande http-bind. Cela permet au service de notification de savoir que le client Web Finesse est toujours en mesure de se connecter au service de notification et que l'agent n'a pas fermé son navigateur ni mis son ordinateur en veille, etc.
Présentation des messages XMPP Finesse et des noeuds XMPP
Finesse implémente également la spécification XMPP XEP-0060 : Publier-Abonner. L'objectif de cette spécification est de permettre au serveur XMPP (service de notification) d'obtenir des informations publiées sur les noeuds XMPP (rubriques), puis d'envoyer des événements XMPP aux entités abonnées au noeud. Dans le cas de Finesse, le serveur CTI (Computer Telephony Integration) envoie des messages CTI au service Web Finesse pour informer Finesse des mises à jour de configuration telles que, mais sans s'y limiter, la création d'un agent ou d'une file d'attente de service de contact (CSQ) ou des informations relatives à un appel. Ces informations sont ensuite converties en un message XMPP que le service Web Finesse publie dans le service de notification Finesse. Le service de notification Finesse envoie ensuite des messages XMPP via BOSH aux agents qui sont abonnés à certains noeuds XMPP.
Certains des objets API Finesse définis dans le Guide de développement des services Web Finesse sont des noeuds XMPP. Les clients Web Finesse agent et superviseur peuvent s'abonner aux mises à jour d'événements pour certains de ces noeuds XMPP afin d'avoir des informations à jour sur les événements en temps réel (tels que les événements d'appel, les événements d'état, etc.). Ce tableau indique les noeuds XMPP qui sont activés par pubsub.
| Objet API Finesse | Objectif | Abonnement |
| /finesse/api/User/<ID de connexion> | Affiche le mappage de l'état et de l'équipe de l'agent | Agents et superviseurs |
| /finesse/api/User/<LoginID>/Dialogues |
Affiche les appels traités par l'agent | Agents et superviseurs |
| /finesse/api/User/<LoginID>/ClientLog |
Utilisé pour capturer les journaux du client à partir du bouton Envoyer le rapport d'erreur | Agents et superviseurs |
| /finesse/api/User/<LoginID>/Queue/<queueID> |
Affiche les données des statistiques de file d'attente (si activé) | Agents et superviseurs |
| /finesse/api/Team/<TeamID>/Users |
Affiche les agents qui appartiennent à une certaine équipe, y compris les informations d'état | Superviseurs |
| /finesse/api/SystemInfo |
Affiche l'état du serveur Finesse. Utilisé pour déterminer si le basculement est nécessaire | Agents et superviseurs |
Exemple 1 : Utilisation de Pidgin pour afficher les noeuds Finesse XMPP
Étape 1. Téléchargez et installez le client XMPP Pidgin.
Étape 2. Accédez à Accounts > Modify > Basic et configurez les options de connexion :
- Protocole : XMPP
- username (nom d’utilisateur) : ID de connexion pour tout agent
- Domaine : Nom de domaine complet du serveur Finesse
- Ressource : Espace réservé - toute valeur peut être utilisée, par exemple, test
- Mot de passe : Mot de passe de l'agent
- Cochez la case Mémoriser le mot de passe
Étape 3. Accédez à Comptes > Modifier > Avancé et configurez :
- Sécurité de la connexion : utiliser le chiffrement si disponible
- Cochez la case Autoriser l'authentification en texte clair d'autres flux non chiffrés
- Port de connexion : 5222. Utilisez le port par défaut 5222. Ce port est requis pour les clients XMPP externes. Les clients de bureau Finesse utilisent le 7443. N'utilisez pas le port 7443.
- Serveur de connexion : Nom de domaine complet du serveur Finesse
Étape 4. Accédez à Outils > Plugins et activez la console XMPP.
Étape 5. Accédez à Outils > Console XMPP > Console XMPP pour ouvrir la console XMPP.
Étape 6. Exécutez ce message <iq> pour afficher tous les noeuds XMPP qui existent.
Exemple :
Dans un environnement de travaux pratiques avec deux agents et deux CSQ configurés, ce résultat est contenu dans la réponse Finesse :
Exemple 2 : Utilisation de l'onglet Réseau des outils de développement de navigateur pour afficher les messages HTTP
Chaque navigateur dispose d'un ensemble d'outils de développement. L'onglet Réseau des outils de développement affiche les messages HTTP envoyés et reçus par le client Web Finesse (navigateur). Par exemple, cette image montre comment le client Web Finesse envoie une requête SystemInfo qui vérifie chaque minute l'état de Finesse Tomcat comme contrôle de basculement. En outre, les messages http-bind de la connexion BOSH sont également affichés. Le serveur Finesse renvoie une réponse dans un délai de 30 secondes s'il n'y a aucune mise à jour à publier sur les noeuds XMPP auxquels le client Web est abonné.
Dépannage: Message d'erreur de déconnexion BOSH
Lorsqu'une déconnexion BOSH se produit, l'erreur « Connexion perdue à {Finesse Server FQDN}. Veuillez patienter jusqu'à ce qu'un serveur Finesse soit trouvé... » s'affiche dans une bannière rouge en haut du bureau Finesse.
Ce message s'affiche car, pour le moment, aucun événement d'abonnement XMPP ne peut être reçu du service de notification Cisco Finesse. Par conséquent, les informations d'état et les détails de l'appel ne peuvent pas être affichés sur le bureau de l'agent.
Pour UCCX, 60 secondes après la déconnexion du navigateur, l'agent est mis en état Déconnexion. L'agent peut être à l'état Prêt ou Non prêt pour la déconnexion.
Pour UCCE, Finesse met jusqu'à 120 secondes pour détecter lorsqu'un agent ferme le navigateur ou le navigateur plante et que Finesse attend 60 secondes avant d'envoyer une demande de déconnexion forcée au serveur CTI, ce qui fait que le serveur CTI met l'agent dans un état Non prêt. Dans ces conditions, Finesse peut prendre jusqu'à 180 secondes pour déconnecter l'agent. Contrairement à UCCX, l'agent passe à l'état Non prêt au lieu de l'état Déconnexion.
Pour plus d'informations sur le comportement d'UCCE Finesse Desktop, reportez-vous à la section Comportement du poste de travail du chapitre Mécanismes de basculement Cisco Finesse du Guide d'administration de Cisco Finesse.
Analyse des journaux
Les journaux du service de notification Finesse et UCCX peuvent être collectés via RTMT ou via l'interface de ligne de commande :
fichier get activelog /desktop recress
Journaux du service de notification de débogage
Activez les journaux de débogage du service de notification de Unified Contact Center Express (UCCX), comme indiqué :
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 will be disabled automatically if Cisco Unified CCX Notification Service is restarted.
Activez les journaux de débogage du service de notification de Unified Contact Center Enterprise (UCCE) (Finesse Standalone), comme indiqué :
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 will be disabled automatically if you restart the Cisco Finesse Notification Service
Ces journaux se trouvent dans le dossier /desktop/logs/openfire et sont nommés debug.log.
Comme le montre l'image, le service de notification (Openfire) debug.log affiche la liaison http avec le bureau ainsi que l'adresse IP et le port du PC de l'agent.
Comme l'illustre l'image, la dernière valeur active de 0 ms indique que la session est toujours active.
Openfire fermant la session inactive indique que la déconnexion de l'agent se déclenchera dans 60 secondes où Finesse enverra une déconnexion forcée avec un code de raison de 255 au serveur CTI. Le comportement réel du bureau dans ces conditions dépend du paramètre Déconnexion sur déconnexion de l'agent (LOAD) dans UCCE. Dans UCCX, c'est toujours le comportement.
Si le client finlandais n'envoie pas de messages http-bind au serveur Finesse, les journaux affichent le temps d'ouverture de la session et indiquent la fermeture de la session.
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>
Journaux du service de notification d'informations
Ces journaux se trouvent dans le dossier /desktop/logs/openfire et sont nommés info.log. Si le client Finese n'envoie pas de messages http-bind au serveur Finesse, les journaux indiquent que la session devient inactive.
2017.06.17 00:16:04 Closing idle session (id=f382a015): 1001003@xxxxx.xxxx.xxx. cisco.com/desktop after being inactive for more than threshold value of 60 2017.06.17 00:16:04 A session is being closed for 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
Journaux des services Web
Ces journaux se trouvent dans le dossier /desktop/logs/webservices et sont nommés Desktop-webservices.YYY-MM-DDTHH-MM-SS.sss.log. Si le client finlandais n'envoie pas de messages http-bind au serveur Finesse dans le délai spécifié, les journaux indiquent que la présence de l'agent devient indisponible et 60 secondes plus tard, une déconnexion déclenchée par la présence se produit.
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
Raisons courantes de la déconnexion BOSH
Les connexions BOSH sont configurées par le client Web et le serveur Finesse détermine si la présence de l'agent n'est pas disponible. Ces problèmes sont presque toujours des problèmes côté client liés au navigateur, à l'ordinateur de l'agent ou au réseau, car c'est au client qu'il incombe de démarrer la connexion.
Problème : Les agents se déconnectent à des moments différents (problème côté client)
Actions recommandées
Vérifiez ces problèmes :
1. Problème réseau :
- Vérifier les règles et les journaux du pare-feu : le port TCP 7443 ne doit pas être bloqué ou limité
- Utilisez un analyseur de trafic Web HTTP comme Fiddler® ou Wireshark® pour confirmer que le navigateur envoie des requêtes http-bind sur le port TCP 7443 et reçoit des réponses
- Vérifier tous les périphériques/interfaces réseau entre l'ordinateur de l'agent et le serveur Finesse pour détecter les retards excessifs ou les abandons de paquets
- Traceroute peut être utile pour déterminer le chemin et les délais
- Sur un PC Microsoft® Windows® : tracert {Finesse Server IP | Nom de domaine complet du serveur Finesse}
- Sur un Mac® : traceroute {Finesse Server IP | Nom de domaine complet du serveur Finesse}
- Sur le logiciel Cisco IOS®, les statistiques d'interface peuvent être vérifiées : show interfaces
- Traceroute peut être utile pour déterminer le chemin et les délais
- Collecter les journaux du client Finesse pour un agent de test. Les journaux clients peuvent être collectés de trois manières :
- Journaux de la console Web du navigateur
- Appuyez sur le bouton Envoyer le rapport d'erreurs sur la page Finesse et collectez les journaux du serveur Finesse. Les journaux se trouvent dans /desktop/logs/clientlogs.
- Connectez-vous via https://<Finesse-FQDN>/desktop/locallog et collectez les journaux après le problème.
Chaque minute, le client se connecte au serveur Finesse pour calculer la dérive et la latence du réseau :
<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
-
- En cas de problème de collecte de journaux, référez-vous à Dépannage du problème de journalisation persistante de Cisco Finesse Desktop
2. Navigateur et/ou version non pris en charge :
Utilisez le navigateur/la version et les paramètres pris en charge conformément aux matrices de compatibilité :
3. Condition bloquée par le navigateur en raison du contenu/du traitement d'autres onglets/fenêtres :
Vérifiez le workflow de l'agent pour voir s'il :
- Il existe généralement d'autres onglets ou fenêtres qui exécutent en permanence d'autres applications en temps réel telles que la diffusion de musique/vidéo, les connexions WebSocket, les clients Web CRM (Customer Relationship Management) personnalisés, etc.
- Disposer d'un très grand nombre d'onglets ou de fenêtres ouverts
- Disposer de la mise en cache du navigateur désactivée
- ont gardé leur navigateur actif pendant longtemps et ne le ferment pas à la fin de la journée de travail ;
4. Ordinateur mis en veille :
Vérifiez si l'agent met son ordinateur en veille avant de se déconnecter de Finesse ou si le compteur de mise en veille de son ordinateur est très faible.
5. Problème de CPU élevé ou de mémoire élevée sur l'ordinateur client :
- Si le navigateur de l'agent s'exécute dans un environnement partagé tel que Microsoft Windows Remote Desktop Services, Citrix® XenApp®, Citrix XenDesktop®, déterminez si les performances du navigateur dépendent du nombre d'utilisateurs exécutant le navigateur simultanément.
- Assurez-vous que la mémoire et les ressources du processeur sont configurées en fonction du nombre d'utilisateurs
- Vérifier les problèmes d'utilisation des ressources de l'ordinateur :
- Fenêtres:
- Commande Get-Counter Windows PowerShell qui vérifie % du temps processeur, mégaoctets de mémoire disponibles et % de mémoire utilisée toutes les 2 secondes : Get-Counter -Counter "\Processor(_Total)\% Processor Time », »\Memory\Available MBytes« , »\Memory\% Committed Bytes In Use » -SampleInterval 2 -Continuel
- Alternative à l'utilisation de PowerShell pour afficher les compteurs de performance de Windows, Windows Performance Monitor peut être utilisé
- Le Gestionnaire des tâches peut être utilisé pour afficher les statistiques en temps réel du processeur et de la mémoire dans le monde entier et au fur et à mesure.
- Mac :
- Commande Terminal top qui vérifie le processeur total et la mémoire en direct : haut
- Vérifier les processus et trier par utilisation du processeur : CPU haut de gamme
- Vérifier les processus et trier par utilisation de la mémoire : MEM en haut
- Le Moniteur d'activité peut être utilisé pour afficher les statistiques en temps réel du processeur et de la mémoire à l'échelle mondiale et par processus.
- Commande Terminal top qui vérifie le processeur total et la mémoire en direct : haut
- Fenêtres:
6. Gadgets tiers réalisant une activité inattendue et problématique en arrière-plan :
Testez le comportement du bureau Finesse en supprimant tous les gadgets tiers.
7. Problème NTP sur le serveur ou le client :
- Vérifiez l'état ntp utils sur le serveur d'édition Finesse pour vous assurer que la strate de serveur NTP est égale ou inférieure à 4
- Dans les journaux du client, vérifiez la dérive et la latence du réseau
Problème : Tous les agents se déconnectent en même temps (problème côté serveur)
Actions recommandées
Vérifiez ces problèmes :
1. Déconnexion du service Cisco Unified Communications Manager CTIManager. Si tous les fournisseurs CTIManager pour UCCX sont arrêtés ou interrompus, les agents UCCX voient l'erreur de bannière rouge. Les agents UCCE ne voient pas la bannière rouge si cela se produit, mais les appels ne parviennent pas à se diriger correctement vers les agents.
- Vérifiez si le service Cisco CTIManager est démarré sur les serveurs CUCM utilisés comme fournisseurs CTI.
- Vérifiez si le service Cisco CTIManager s'est arrêté via l'Observateur d'événements - Les applications se connectent sur RTMT pour voir si le service Cisco CTIManager s'est arrêté.
- Pour collecter les journaux de la visionneuse d'événements sur RTMT : System > Tools > Trace and Log Central > Collecte de fichiers > Select System Services/Applications > Event Viewer-Application Log
- Pour collecter les journaux de l'application de l'observateur d'événements sur l'interface de ligne de commande : fichier get activelog /syslog/CiscoSyslog* abstime hh:mm:MM/JJ/AA hh:mm:MM/JJ/AA
- Pour afficher les vidages principaux sur la CLI : liste active principale utils
2. Service de notification Finesse/UCCX arrêté ou bloqué :
- Vérifiez les erreurs du service de notification dans les journaux d'application de l'Observateur d'événements ou pour voir si le service a été arrêté.
- Vérifiez si le service de notification est actif : liste de services utils
- Vérifiez les heures d'arrêt du service de notification : recherche de fichiers activelog /desktop/logs/openfire « Openfire stop »
- Vérifiez les heures de démarrage du service de notification : recherche de fichiers activelog /desktop/logs/openfire « service de liaison HTTP démarré »
- Recherchez les vidages de mémoire du service de notification résultant d'un plantage : liste de fichiers activelog /desktop/logs/openfire/*.hprof
- Vérifiez si le service de notification écoute le trafic sur le port TCP 7443 : show open ports regexp 7443.*LISTEN
- Vérifiez si ces défauts sont applicables (ces défauts provoqueraient un échec de connexion pour les agents qui se connectent et pour les agents déjà connectés, ces agents verraient le message de déconnexion Finesse de la bannière rouge) :
- CSCva72280 - Finesse Tomcat et Openfire Crash pour les caractères XML non valides
- CSCva72325 -UCCX : Finesse Tomcat et Openfire Crash pour les caractères XML non valides
Redémarrez Cisco Finesse Tomcat et le service de notification si un plantage est suspecté. Ceci est recommandé uniquement en cas de panne du réseau, sinon, ces redémarrages déconnectent les agents du serveur Finesse.
- Étapes pour UCCE :
- arrêt de service utils Cisco Finesse Tomcat
- utils service stop Cisco Finesse Notification Service
- utils service start Cisco Finesse Tomcat
- utils service start Cisco Finesse Notification Service
- Étapes pour UCCX :
- arrêt de service utils 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
Utilisation de Fiddler
La configuration de Fiddler peut s’avérer difficile sans comprendre les étapes nécessaires et comprendre le fonctionnement de Fiddler. Fiddler est un proxy web man-in-the-Middle qui se trouve entre le client Finesse (navigateur web) et le serveur Finesse. En raison des connexions sécurisées entre le client Finesse et le serveur Finesse, cela ajoute une couche de complexité à la configuration Fiddler afin d'afficher les messages sécurisés.
Problème de Fiddler commun
Puisque Fiddler se trouve entre le client Finesse et le serveur Finesse, l'application Fiddler doit créer des certificats signés pour tous les ports TCP Finesse nécessitant des certificats :
Certificats de service Cisco Finesse Tomcat
- Serveur d'édition Finesse TCP 8445 (et/ou 443 pour UCCE)
- Serveur d'abonnés Finesse TCP 8445 (et/ou 443 pour UCCE)
Certificats de service de notification Cisco Finesse (Unified CCX)
- Serveur d'édition Finesse TCP 7443
- Serveur d'abonnés Finesse TCP 7443
Le déchiffrement HTTPS doit être activé pour que Fiddler génère dynamiquement des certificats pour le compte du serveur Finesse. Cette option n'est pas activée par défaut.
Si le déchiffrement HTTPS n'est pas configuré, la connexion initiale au tunnel au service de notification est visible, mais le trafic http-bind ne l'est pas. Fiddler affiche uniquement :
Tunnel to <Finesse server FQDN>:7443
Ensuite, les certificats Finesse signés par Fiddler doivent être approuvés par le client. Si ces certificats ne sont pas fiables, passez à l'étape Établissement d'une connexion chiffrée... étape de connexion Finesse n'est pas possible.
Dans certains cas, l'acceptation des exceptions de certificat de la connexion ne fonctionne pas et les certificats doivent être approuvés manuellement par le navigateur.
Exemples d'étapes de configuration
Étape 1. Télécharger Fiddler
Étape 2. Activer le déchiffrement HTTPS : Outils > Options > HTTPS > cochez la case Décrypter le trafic HTTPS
Étape 3. Une boîte de message d'avertissement s'ouvre pour demander à d'approuver le certificat racine Fiddler. Sélectionnez Oui.
Étape 4. Une boîte de message d'avertissement s'ouvre avec le message « Vous êtes sur le point d'installer un certificat d'une autorité de certification (CA) prétendant représenter : DO_NOT_TRUST_FiddlerRoot... Voulez-vous installer ce certificat ? ». Sélectionnez Oui.
Étape 5. Ajoutez manuellement les certificats d'éditeur et d'abonné Finesse au magasin d'approbation des certificats de l'ordinateur ou du navigateur. Vérifiez les ports 8445, 7443 et (uniquement pour UCCE) 443. Par exemple, sur Firefox, cela peut être fait simplement sans télécharger les certificats à partir de la page d'administration du système d'exploitation Finesse :
Options > Find in Options (search) > Certificates > Servers > Add Exception > Location > Enter https://<Finesse server>:port for the appropriés ports for the two Finesse servers.
Étape 6. Connectez-vous à Finesse et consultez les messages http-bind qui laissent le client Finesse au serveur Finesse via Fiddler.
Dans l'exemple fourni, les 5 premiers messages affichent des messages http-bind auxquels le serveur Finesse a répondu. Le premier message contient 1 571 octets de données renvoyés dans le corps du message. Le corps contient une mise à jour XMPP concernant un événement d'agent. Le dernier message http-bind a été envoyé par le client Finesse, mais n'a pas reçu de réponse du serveur Finesse. Cela peut être déterminé en constatant que le résultat HTTP est null (-) et que le nombre d'octets dans le corps de réponse est null (-1).
Vue plus précise des données :
Corps de réponse du message XMPP :
Utilisation de Wireshark
Wireshark est un outil de détection de paquets couramment utilisé qui peut être utilisé pour détecter et décoder le trafic HTTPS. Le trafic HTTPS est le trafic HTTP sécurisé par le biais de la sécurité de la couche de transport (TLS). TLS assure l’intégrité, l’authentification et la confidentialité entre les hôtes. Il est couramment utilisé dans les applications Web, mais il peut être utilisé avec n’importe quel protocole qui utilise TCP comme protocole de couche transport. SSL (Secure Sockets Layer) est l'ancienne version du protocole TLS, qui n'est plus utilisé car il n'est pas sécurisé. Ces noms sont souvent utilisés de manière interchangeable, et le filtre Wireshark utilisé pour le trafic SSL ou TLS est ssl.
Étape 1. Sur le PC Windows de l'agent, accédez à Panneau de configuration > Système et sécurité > Système > Paramètres système avancés Variables environnementales...
Étape 2. Accédez à Variables utilisateur pour l'utilisateur <nom d'utilisateur> > Nouveau...
Créez une variable nommée SSLKEYLOGFILE.
Créez un fichier pour stocker le secret du maître SSL dans un répertoire privé : SSLKEYLOGFILE=</path/to/private/directory/with/logfile>
Étape 3. Si Firefox ou Chrome sont ouverts, fermez les applications. Après leur réouverture, ils commenceront à écrire dans le fichier SSLKEYLOGFILE.
Étape 4. Sur Wireshark, accédez à Edition > Préférences...
Accédez à Protocoles > SSL.
Étape 5. Entrez l'emplacement du nom de fichier journal secret du maître configuré à l'étape 2.
Étape 6. En utilisant le filtre Wireshark tcp.port==7443 && ssl, la communication HTTP sécurisée entre le client Finesse et le serveur Finesse (service de notification) est vue déchiffrée.
Défauts associés
- CSCva72280 - Finesse Tomcat et Openfire Crash pour les caractères XML non valides
- CSCva72325 -UCCX : Finesse Tomcat et Openfire Crash pour les caractères XML non valides
Informations connexes
- Spécifications XMPP
- XEP-0124 : BOSSE
- XEP-0060 : Publier-Abonner
- Console Web Firefox
- console Web Internet Explorer
- Console Web Chrome
- Windows PowerShell
- Moniteur des performances Windows
- Dépannage des suppressions dans la file d'attente d'entrée et de sortie
- Gestionnaire des tâches Windows
- Terminal Mac
- Moniteur d'activité Mac
- Téléchargement Fiddler
- Configuration de Fiddler
- Téléchargement de Wireshark
- Décryptage SSL Wireshark
- Support et documentation techniques - Cisco Systems
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)