Comprenez l'implémentation de BÊTISES de finesse et dépannez les questions de débranchement de présence d'Agent Desktop de finesse
Contenu
Introduction
Ce document décrit l'architecture derrière les connexions de finesse qui utilisent des Bidirectionnel-flots au-dessus de HTTP synchrone (BÊTISES) et la façon dont des problèmes de connexion de BÊTISES peuvent être diagnostiqués.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Cisco Finesse
- Unified Contact Center Enterprise (UCCE)
- Unified Contact Center Express (UCCX)
- Outils pour développeurs de navigateur Web
- Gestion de Windows et/ou de MAC
Composants utilisés
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)
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Compréhension de l'implémentation de BÊTISES de finesse
Compréhension de XMPP
La Messagerie et la présence extensibles Protocol (XMPP) (également connu sous le nom de Jabber) est un état de protocole dans un client-server model. XMPP tient compte de la livraison rapide de petites parties de données structurées de langage extensible de balisage (XML) d'une entité à l'autre. XMPP/Jabber est intensivement utilisé dans des applications de messagerie instantanée (IM) et de présence.
Toutes les entités XMPP sont identifiées par leur ID de Jabber (JID).
Système d'adressage JID : user@domain /resource
| utilisateur | nom d'utilisateur de client sur le serveur XMPP ou le nom de la salle de conférence |
| domaine | Nom de domaine complet de serveur XMPP (FQDN) |
| ressource | identifiant de l'entité de l'utilisateur/du point final spécifiques (par exemple, ordinateur portable, smartphone, etc.), un identifiant de session, ou nom du noeud de pubsub |
Des messages XMPP s'appellent les strophes. Il y a trois principales strophes dans XMPP :
1. <message> : une direction, un destinataire
2. <presence> : une direction, éditent à beaucoup
3. <iq> : les informations/requête - demande/réponse
Toutes les strophes doivent et des adresses et de la plupart des strophes également avoir le type, l'id, et le xml : langattributes.
| Attribut de strophe | But |
| à | destination JID |
| de | source JID |
| type | but du message |
| id | identifiant unique utilisé pour joindre une demande avec une réponse pour des strophes de <iq> |
| xml : lang | définit la langue par défaut pour n'importe quel XML lisible pour l'homme dans la strophe |
Message de l'exemple 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 la finesse
Si une application Web doit fonctionner avec XMPP, les plusieurs questions surgissent. Les navigateurs ne prennent en charge pas XMPP au-dessus de Protocole TCP (Transmission Control Protocol) à la façon des indigènes, ainsi tout le trafic XMPP doit être traité par un programme qui fonctionne à l'intérieur du navigateur. Les serveurs Web et les navigateurs communiquent par l'intermédiaire des messages de Protocole HTTP (Hypertext Transfer Protocol), ainsi la finesse et d'autres applications Web enveloppent des messages XMPP à l'intérieur de des messages de HTTP.
La première difficulté avec cette approche est que le HTTP est un protocole sans état. Ceci signifie que chaque demande de HTTP n'est liée à aucune autre demande. Cependant, ce problème peut être abordé par applicable signifie--par exemple par l'utilisation des Témoins/des données de courrier.
La deuxième difficulté est le comportement unidirectionnel du HTTP. Seulement le client envoie des demandes, et le serveur peut seulement répondre. L'incapacité du serveur de pousser des données le rend artificiel d'implémenter XMPP au-dessus de HTTP.
Ce problème n'existe pas dans la spécification de noyau de l'original XMPP (RFC 6120), où XMPP est lié au TCP. Cependant, si vous voulez aborder le problème avec XMPP attaché au HTTP, par exemple, parce que le Javascript peut envoyer des demandes de HTTP, il y a deux solutions possibles. Chacun des deux exigent une passerelle entre le HTTP et le XMPP.
Les solutions proposées sont :
1. Vote (protocole existant) : demandes de HTTP répétées demandant de nouvelles données définies dans XEP-0025 : Vote de HTTP de Jabber
2. Le long vote également est connu comme BÊTISES : le protocole de transport qui émule la sémantique d'une connexion TCP longévitale et bidirectionnelle entre deux entités par efficacement utilisant la plusieurs demande/réponse synchrone de HTTP appareille sans exiger l'utilisation de l'interrogation fréquente définie dans XEP-0124 : HTTP liant et étendu par XEP-0206 : XMPP au-dessus des BÊTISES
La finesse implémente des BÊTISES car elle est tout à fait efficace du point de vue de chargement du serveur et en ce qui concerne le trafic. Le but d'utiliser des BÊTISES est de dissimuler le fait que le serveur ne doit pas répondre car bientôt il y a une demande. La réponse est retardée jusqu'à un temps spécifié jusqu'à ce que le serveur ait des données pour le client, et alors elle est envoyée comme réponse. Dès que le client obtiendra la réponse, le client fait une nouvelle demande et ainsi de suite.
Le client de bureau de finesse (application Web) établit une connexion éventée de BÊTISES au-dessus de port TCP 7443 toutes les 30 secondes. Après 30 secondes, s'il n'y a aucune mise à jour du service de notification de finesse, le service de notification envoie une réponse de HTTP avec un corps vide de l'OK 200 et de la réponse a (presque). Si le service de notification a une mise à jour sur la présence d'un agent ou un événement de dialogue (appel), par exemple, les données sont envoyées immédiatement au client web de finesse.
Finesse XMPP Reqeust/réponse d'exemple
Cet exemple affiche la première réponse de demande de message XMPP partagée entre le client de finesse et le serveur de finesse pour installer la connexion de BÊTISES.
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 de finesse a une connexion HTTP éventée (HTTP-grippage) installée au serveur de finesse par l'intermédiaire du port TCP 7443. Ceci est connu comme long balayage de BÊTISES.
- Le service de notification de finesse est un service de présence qui signale 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 demande de HTTP-grippage avec la mise à jour d'état comme message XMPP dans le corps de réponse de HTTP.
- S'il n'y a aucune mise à jour 30 d'état des secondes après réception de la demande de HTTP-grippage, le service de notification ne répond sans aucune mise à jour d'état pour permettre au web client de finesse pour envoyer une autre demande de HTTP-grippage. Ceci sert de manière au service de notification de savoir que le client web de finesse peut encore se connecter au service de notification et que l'agent n'a pas fermé leur navigateur ou a mis leur ordinateur pour dormir, etc.
Compréhension des messages de la finesse XMPP et des Noeuds XMPP
La finesse implémente également la spécification XEP-0060 XMPP : Éditer-abonnez-vous. Le but de cette spécification est de permettre au serveur XMPP (service de notification) pour obtenir les informations éditées aux Noeuds XMPP (thèmes) et puis pour envoyer des événements XMPP aux entités abonnées au noeud. Dans le cas de la finesse, le serveur du couplage de la téléphonie et de l'informatique (CTI) envoie des messages CTI au service Web de finesse pour dire la finesse au sujet des mises à jour de la configuration comme, mais au sujet non limité à, l'agent ou la création ou les informations de la file d'attente du service de contact (CSQ) sur un appel. Ces informations sont alors converties en message XMPP que le service Web de finesse édite au service de notification de finesse. Le service de notification de finesse envoie alors XMPP au-dessus des messages de BÊTISES aux agents qui sont abonnés à certains Noeuds XMPP.
Certains d'objets de la finesse API qui sont définis du guide de développeur de services Web de finesse sont des Noeuds XMPP. Les clients web de finesse d'agent et de superviseur peuvent s'abonner aux mises à jour d'événement pour certains de ces Noeuds XMPP afin d'avoir des informations à jour sur des événements en temps réel (tels que des événements d'appel, des événements d'état, et ainsi de suite). Cette table affiche les Noeuds XMPP qui sont pubsub activé.
| Objet de la finesse API | But | Abonnement |
| <LoginID> de /finesse/api/User/ | Affiche le mappage d'état et d'équipe de l'agent | Agents et superviseurs |
| /finesse/api/User/ <LoginID>/Dialogues |
Affiche les appels manipulé par l'agent | Agents et superviseurs |
| /finesse/api/User/ <LoginID>/ClientLog |
Utilisé pour capturer des logs de client de l'erreur d'envoi signalez le bouton | Agents et superviseurs |
| /finesse/api/User/ <LoginID>/Queue/<queueID> |
Données de statistiques de file d'attente d'expositions (si activé) | Agents et superviseurs |
| /finesse/api/Team/ <TeamID>/Users |
Affiche les agents qui appartiennent à une certaine équipe comprenant les informations d'état | Superviseurs |
| /finesse/api/SystemInfo |
Affiche l'état du serveur de finesse. Utilisé pour déterminer si le Basculement est nécessaire | Agents et superviseurs |
Exemple 1 : Utilisant des pidgin pour visualiser des Noeuds de la finesse XMPP
Étape 1. Téléchargez et installez les pidgin de client XMPP.
Étape 2. Naviguez vers des comptes > modifient > de base et configurent les options de procédure de connexion :
- Protocol : XMPP
- Nom d'utilisateur : LoginID pour tout agent
- Domaine : FQDN de serveur de finesse
- Ressource : Texte d'attente - n'importe quelle valeur peut être utilisée, par exemple, test
- Mot de passe : Mot de passe d'agent
- Vérifiez la case à cocher de mot de passe de souvenir
Étape 3. Naviguez vers des comptes > modifient > ont avancé et configurent :
- Sécurité de connexion : Cryptage d'utilisation si disponible
- Vérifiez le plaintext d'autoriser authentique d'autres flots décryptés
- Port de connexion : 5222. Utilisez le port par défaut 5222. Ce port est exigé pour les clients externes XMPP. Utilisation de bureau 7443 de clients de finesse. N'utilisez pas le port 7443.
- Serveur de connexion : FQDN de serveur de finesse
Étape 4. Naviguez vers des outils > des modules d'extension et activez la console XMPP.
Étape 5. Naviguez vers les outils > la console XMPP > la console XMPP pour ouvrir la console XMPP.
Étape 6. Exécutez ce message de <iq> pour voir tous les Noeuds XMPP qui existent.
<iq type='get' from='<loginID>@<Finesse_FQDN>/test' to='pubsub.<Finesse_FQDN>' id='testId1'
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
Exemple :
<iq type='get' from='47483648@fin1.ucce.local/test' to='pubsub.fin1.ucce.local' id='testId1'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
Dans un environnement de travaux pratiques avec deux agents et deux CSQ configurés, cette sortie est contenue dans la réponse de finesse :
<iq type='result' id='testId1' from='pubsub.fin1.ucce.local' to='47483648@fin1.ucce.local/test'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/Team/5000/Users'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483648/Dialogs'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483651'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483651/ClientLog'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483649/Queues'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/Team/5001/Users'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483650/ClientLog'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/Queue/1'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483648/ClientLog'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483648/Queues'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483650'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483650/Queues'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483651/Dialogs'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483648'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/Team/1/Users'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483649'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483651/Queues'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483649/ClientLog'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/Queue/0'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483649/Dialogs'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/User/47483650/Dialogs'/>
<item jid='pubsub.fin1.ucce.local' name='' node='/finesse/api/SystemInfo'/>
</query>
</iq>
Exemple 2 : Utilisant l'onglet de réseau d'outils pour développeurs de navigateur pour visualiser des messages de HTTP
Chaque navigateur a un ensemble d'outils pour développeurs. L'onglet de réseau des outils pour développeurs affiche les messages de HTTP envoyés et reçus par le client web de finesse (navigateur). Par exemple, cette image affiche comment le client web de finesse envoie une demande de SystemInfo ce qui vérifie l'état de Tomcat de finesse chaque minute comme contrôle de Basculement. Supplémentaire, les messages de HTTP-grippage de la connexion de BÊTISES sont également affichés. Le serveur de finesse renvoie une réponse dans 30 secondes s'il n'y a aucune mise à jour à éditer sur les Noeuds XMPP que le client web est abonné à.
Dépannez : Message d'erreur de débranchement de BÊTISES
Quand un débranchement de BÊTISES se produit, l'erreur « a perdu la connexion à {FQDN de serveur de finesse}. Veuillez attendre un serveur accessible de finesse à trouver… » est affiché dans une bannière rouge en haut de l'appareil de bureau de finesse.
Ce message est affiché parce qu'à ce moment, aucun événement d'abonnement XMPP ne peut être reçu du service de notification de Cisco Finesse. Par conséquent, les informations d'état et des détails d'appel ne peuvent pas être affichés sur l'Agent Desktop.
Pour UCCX, le temporisateur de déconnexion est de 60 secondes après que débranchement de navigateur. L'agent peut être dans l'état prêt ou non prêt pour que la déconnexion se produise.
Pour UCCE, la finesse prend à 120 secondes pour la détecter quand un agent ferme le navigateur ou le navigateur tombe en panne et attente de finesse 60 secondes avant d'envoyer une demande obligatoire de déconnexion au serveur CTI. Dans ces conditions, la finesse peut prendre à 180 secondes pour se déconnecter l'agent.
Pour plus d'informations sur le comportement de bureau de finesse UCCE, référez-vous à la section de bureau de comportement du chapitre de mécanismes de Basculement de Cisco Finesse dans le guide d'administration de Cisco Finesse.
Analyse de log
La finesse et des logs de service de notification UCCX peuvent être collectées par l'intermédiaire de RTMT ou par l'intermédiaire du CLI :
le fichier obtiennent l'activelog /desktop se reproduit compresse
Logs de service de notification de debug
Le service de notification d'enable mettent au point des logs d'Unified Contact Center Express (UCCX), comme affiché :
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.
Le service de notification d'enable mettent au point des logs d'Unified Contact Center Enterprise (UCCE) (finesse autonome), comme affiché :
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 logs sont dans le répertoire de /desktop/logs/openfire et sont nommés debug.log.
Suivant les indications de l'image, le service de notification (Openfire) debug.log affiche le HTTP liant avec l'appareil de bureau avec l'adresse IP et le port du PC d'agent.
Suivant les indications de l'image, le dernier ms de l'active 0 prouve que la session est encore en activité.
Openfire en clôturant la session de veille indique que la déconnexion d'agent déclenchera en 60 secondes où la finesse enverra une déconnexion obligatoire avec code de raison de 255 au serveur CTI. Le comportement réel de l'appareil de bureau dans ces conditions dépend de la configuration pour la déconnexion sur le débranchement d'agent (CHARGEMENT) dans UCCE. Dans UCCX, c'est toujours le comportement.
Si le client de Fineese n'envoie pas des messages de HTTP-grippage au serveur de finesse, les logs afficheront la session vers le haut du temps et afficheront la fin de 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>
Logs de service de notification de l'information
Ces logs sont dans le répertoire de /desktop/logs/openfire et sont nommés info.log. Si le client de Fineese n'envoie pas des messages de HTTP-grippage au serveur de finesse, les logs afficheront que la la session deviennent 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
Logs de Webservices
Ces logs sont dans le répertoire de /desktop/logs/webservices et sont nommés Desktop-webservices.YYYY-MM-DDTHH-MM-SS.sss.log. Si le client de Fineese n'envoie pas des messages de HTTP-grippage au serveur de finesse dans la durée spécifiée, les logs afficheront que la la présence d'agent deviennent indisponible et 60 secondes plus tard, une déconnexion pilotée par présence se produira.
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 communes pour le débranchement de BÊTISES
Des connexions de BÊTISES sont installées par le client web, et le serveur de finesse détermine si la présence d'agent est indisponible. Ces questions sont presque toujours des questions de côté client concernant le navigateur, l'ordinateur d'agent, ou le réseau car la responsabilité de commencer vers le haut de la connexion incombe au client.
Problème : Les agents déconnectent aux heures différentes (la question de côté client)
Actions recommandées
Vérifiez ces questions :
1. Problème de réseau :
- Le Pare-feu d'examen ordonne et se connecte -- Le port TCP 7443 ne doit pas être bloqué ou étranglé
- Employez un renifleur du trafic web de HTTP comme le ® de violoneur ou le ® de Wireshark pour confirmer que le navigateur envoie des demandes de HTTP-grippage au-dessus du port TCP 7443 et reçoit des réponses
- Vérifiez tous les périphériques/interfaces de réseau entre l'ordinateur d'agent et le serveur de finesse pour le retard excessif ou les pertes de paquets
- La traceroute peut être utile pour déterminer le chemin et pour déterminer des retards
- Sur un PC de ® de Windows de ® de Microsoft : tracert {IP de serveur de finesse | FQDN de serveur de finesse}
- Sur un ® de MAC : traceroute {la finesse divisent l'IP | FQDN de serveur de finesse}
- Sur le logiciel de Cisco IOS®, la statistique d'interface peut être vérifiée : show interfaces
- La traceroute peut être utile pour déterminer le chemin et pour déterminer des retards
- Collectez les logs de client de finesse pour un agent de test. Des logs de client peuvent être collectés de trois manières :
- Logs de console Web de navigateur
- Appuyez sur le bouton d'état d'erreur d'envoi à la page de finesse et collectez les journaux du serveur de finesse. Les logs se trouvent dans /desktop/logs/clientlogs.
- Ouvrez une session par l'intermédiaire de https:// <Finesse-FQDN>/desktop/locallog et collectez les logs après que la question se produise.
Chaque minute, le client se connecte au serveur de finesse pour calculer la dérive et la latence de 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 toutes les questions de collecte de log, référez-vous dépannent le problème se connectant persistant de bureau de Cisco Finesse
2. Navigateur et/ou version non vérifiés :
Utilisez le navigateur/version et les configurations pris en charge selon les matrices de compatibilité :
3. Teneur devant coincée par navigateur en condition pour/traitement de l'autres onglet/fenêtre :
Vérifiez le processus d'agent pour voir s'ils :
- Ayez généralement d'autres onglets ou fenêtres qui exécutent constamment d'autres applications en temps réel telles que la musique/flux vidéo, les connexions de WebSocket, les clients web faits sur commande de gestion de la relation client (CRM), etc.
- Ayez un très grand nombre d'onglets ou les fenêtres s'ouvrent
- Ont désactivé la mise en cache de navigateur
- Ont continué leur navigateur s'exécuter pendant longtemps et ne ferment pas le navigateur à la fin du jour ouvrable
4. Ordinateur mis pour dormir :
Vérifiez pour voir si l'agent met leur ordinateur pour dormir avant de se déconnecter de la finesse ou si leur temporisateur de configuration de sommeil d'ordinateur est très bas.
5. Question CPU de haute ou de mémoire élevée sur l'ordinateur client :
- Si le navigateur d'agent s'exécute dans un environnement partagé tel que des services de bureau distant de Microsoft Windows, le ® de XenApp de ® de Citrix, ® de Citrix XenDesktop, déterminent si la représentation de navigateur dépend du nombre d'utilisateurs exécutant le navigateur en même temps
- Assurez-vous que la mémoire appropriée et des ressources CPU est configurée ont basé sur le nombre d'utilisateurs
- Questions d'utilisation de ressource informatique en contrôle :
- Windows :
- Commande d'Obtenir-compteur de Windows PowerShell qui vérifie % de temps- CPU, mégaoctets de mémoire disponibles, et % de mémoire en service toutes les 2 secondes : Obtenir-compteur - « De compteur \ processeur (_Total) \ % de temps processeur », « \ mémoire \ Moctets disponibles », « \ mémoire \ % a commis des octets en service » - SampleInterval 2 - continus
- L'alternative à employer PowerShell pour visualiser les compteurs de la représentation de Windows, moniteur de performances de Windows peut être utilisée
- Le gestionnaire de tâches peut être utilisé pour visualiser des statistiques vivantes de CPU et mémoire globalement et sur une base de processus-par-processus
- MAC :
- Commande supérieure terminale qui vérifie la CPU et mémoire totale vivante : dessus
- Processus et tri de contrôle par l'utilisation du processeur : dessus - CPU o
- Processus et tri de contrôle par l'utilisation de mémoire : dessus - o MEM
- Le moniteur d'activité peut être utilisé pour visualiser des statistiques vivantes de CPU et mémoire globalement et sur une base de processus-par-processus
- Commande supérieure terminale qui vérifie la CPU et mémoire totale vivante : dessus
- Windows :
6. instruments de tiers exécutant l'activité inattendue et problématique à l'arrière-plan :
Testez le comportement de bureau de finesse tous les instruments de tiers étant coupés.
7. Question de NTP sur le serveur ou le client :
- L'état de ntp d'utils de contrôle sur le serveur d'éditeur de finesse pour assurer la strate de serveur de NTP est 4 ou diminue
- Dans les logs de client, la dérive et la latence de réseau de contrôle
Problème : Tout le débranchement d'agents en même temps (question de côté serveur)
Actions recommandées
Vérifiez ces questions :
1. Débranchement de service de Cisco Unified Communications Manager CTIManager. Si tous les fournisseurs de CTIManager pour UCCX sont arrêt ou crash, les agents UCCX voient l'erreur rouge de bannière. Les agents UCCE ne voient pas la bannière rouge si ceci se produit, mais les appels ne conduisent pas propertly aux agents.
- Vérifiez pour voir si le service de Cisco CTIManager est commencé sur les serveurs CUCM utilisés comme fournisseurs CTI
- Vérifiez pour voir si le service de Cisco CTIManager tombait en panne par l'intermédiaire des logins RTMT d'application d'affichage d'événements pour voir si le service de Cisco CTIManager tombait en panne
- Pour collecter les logins RTMT de visualisateur d'événements : Le système > les outils > le central de suivi et de log > collectent des fichiers > des services système/applications > journal de l'observateur d'événements choisis
- Pour collecter les logins CLI d'application d'affichage d'événements : le fichier obtiennent l'activelog /syslog/CiscoSyslog * hh d'abstime : millimètre : Hh MM/DD/YY : millimètre : MM/DD/YY
- Pour visualiser des vidages de mémoire sur le CLI : les utils creusent la liste active
2. Service de notification Finesse/UCCX arrêté ou tombé en panne :
- Vérifiez les journaux de l'observateur d'événements pour des erreurs de service de notification ou pour voir si le service était arrêté
- Vérifiez pour voir si le service de notification est en hausse : liste de service d'utils
- Vérifiez les temps le service de notification arrêté : l'activelog /desktop/logs/openfire « Openfire de recherche de fichier a arrêté »
- Vérifiez les temps le service de notification commencé : activelog /desktop/logs/openfire « service de recherche de fichier de grippage de HTTP commencé »
- Vérifiez les vidages mémoire de mémoire de service de notification qui ont résulté d'un crash : activelog /desktop/logs/openfire/ *.hprof de liste de fichier
- Vérifiez pour voir si le service de notification écoute le trafic sur le port TCP 7443 : affichez le regexp 7443.*LISTEN de ports ouverts
- Vérifiez pour voir si ces défauts s'appliquent (ces défauts entraîneraient la panne de procédure de connexion pour des agents ouvrant une session et pour des agents déjà ouverts une session, ces agents verraient le message rouge de débranchement de finesse de bannière) :
- CSCva72280 - La finesse Tomcat et Openfire crash pour les caractères non valides XML
- CSCva72325 - UCCX : La finesse Tomcat et Openfire crash pour les caractères non valides XML
Redémarrez le Cisco Finesse Tomcat et le service de notification si on suspecte un crash. Ceci est seulement recommandé dans une situation de réseau vers le bas, autrement, ces agents de débranchement de reprises du serveur de finesse.
- Étapes pour UCCE :
- Cisco Finesse Tomcat d'arrêt de service d'utils
- service de notification de Cisco Finesse d'arrêt de service d'utils
- Cisco Finesse Tomcat de début de service d'utils
- service de notification de Cisco Finesse de début de service d'utils
- Étapes pour UCCX :
- Cisco Finesse Tomcat d'arrêt de service d'utils
- service de notification de Cisco Unified CCX d'arrêt de service d'utils
- Cisco Finesse Tomcat de début de service d'utils
- service de notification de Cisco Unified CCX de début de service d'utils
Utilisant le violoneur
Configurer le violoneur peut être une tâche en quelque sorte provocante sans comprendre les étapes requises et comprendre comment des travaux de violoneur. Le violoneur est un proxy homme-dans-le-moyen de Web qui se tient entre le client de finesse (navigateur Web) et le serveur de finesse. En raison des connexions étant sécurisées entre le client de finesse et le serveur de finesse, ceci ajoute une couche de complexité à la configuration de violoneur afin de visualiser les messages sécurisés.
Question commune de violoneur
Puisque le violoneur se tient entre le client de finesse et le serveur de finesse, l'application de violoneur doit créer les Certificats signés pour tous les ports TCP de finesse qui exigent des Certificats :
Certificats de service de Tomcat de Cisco Finesse
- TCP de serveur d'éditeur de finesse 8445 (et/ou 443 pour UCCE)
- TCP de serveur d'abonné de finesse 8445 (et/ou 443 pour UCCE)
Certificats de service de notification de Cisco Finesse (Unified CCX)
- TCP 7443 de serveur d'éditeur de finesse
- TCP 7443 de serveur d'abonné de finesse
Le déchiffrement HTTPS doit être activé pour que le violoneur génère dynamiquement des Certificats au nom du serveur de finesse. Ceci n'est pas activé par défaut.
Si le déchiffrement HTTPS n'est pas configuré, la connexion en tunnel initiale au service de notification est vue, mais le trafic de HTTP-grippage n'est pas. Expositions de violoneur seulement :
Tunnel to <Finesse server FQDN>:7443
Puis, les Certificats de finesse signés par la nécessité de violoneur sont de confiance par le client. Si ces Certificats ne sont pas faits confiance, passé en mouvement l'étape de établissement de connexion cryptée… de la procédure de connexion de finesse n'est pas possible.
Dans certains cas, recevoir les exceptions de certificat à la procédure de connexion ne fonctionne pas, et les Certificats ont besoin sont de confiance par le navigateur manuellement.
Étapes d'exemple de configuration
Étape 1. Violoneur de téléchargement
Étape 2. Déchiffrement de l'enable HTTPS : Outils > options > HTTPS > contrôle la case à cocher du trafic du déchiffrage HTTPS
Étape 3. Une zone de message d'avertissement ouverte pour demander à faire confiance au certificat racine de violoneur. Sélectionnez oui.
Étape 4. Une zone de message d'avertissement s'ouvre avec le message « que vous êtes sur le point pour installer un certificat d'une autorité de certification (CA) prétendant représenter : DO_NOT_TRUST_FiddlerRoot… Vous voulez installer ce certificat ? ». Sélectionnez oui.
Étape 5. Ajoutez manuellement les Certificats d'éditeur et d'abonné de finesse à la mémoire de confiance de certificat d'ordinateur ou de navigateur. Assurez les ports 8445, 7443, et (seulement pour UCCE) 443. Par exemple, sur Firefox, ceci peut être fait simplement sans télécharger des Certificats de la page du système d'exploitation de gestion de finesse :
Les options > la découverte dans les options (recherche) > délivre un certificat > des serveurs > ajoutent l'exception > l'emplacement > écrivent le server> de <Finesse de https:// : mettez en communication pour les ports appropriés pour les deux serveurs de finesse.
Étape 6. Connectez-vous dans la finesse et voyez les messages de HTTP-grippage laisser le client de finesse au serveur de finesse par l'intermédiaire du violoneur.
Dans l'exemple a fourni, les 5 premiers messages de HTTP-grippage d'exposition de messages qui ont été répondus à par le serveur de finesse. Le premier message contient 1571 octets de données retournés au corps du message. Le corps contient une mise à jour XMPP concernant un événement d'agent. Le message final de HTTP-grippage a été envoyé par le client de finesse, mais n'a pas une réponse du serveur de finesse. Ceci peut être déterminé en voyant que le résultat de HTTP est nul (-) et le nombre d'octets dans le corps de réponse est le null (-1).
Une vue plus étroite des données :
Corps de réponse pour le message XMPP :
Utilisant Wireshark
Wireshark est un outil utilisé généralement de reniflement de paquet qui peut être utilisé pour renifler et décoder le trafic HTTPS. Le trafic HTTPS est le trafic http sécurisé au-dessus du Transport Layer Security (TLS). Le TLS fournit l'intégrité, l'authentification et la confidentialité entre aux hôtes. Il est utilisé généralement dans les applications Web, mais il peut être utilisé avec n'importe quel protocole qui utilise le TCP comme protocole de la couche transport. Secure Sockets Layer (SSL) est l'ancienne version du protocole de TLS, qui n'est plus utilisé car il est non sécurisé. Ces noms sont employés souvent l'un pour l'autre, et le filtre de Wireshark utilisé pour le trafic SSL ou de TLS est SSL.
Étape 1. Sur le PC Windows de l'agent naviguez vers le panneau de configuration > le système et la Sécurité > le système > ont avancé des variables environnementales de paramètres système…
Étape 2. Naviguez vers des variables d'utilisateur pour le <username> d'utilisateur > nouveau…
Créez une variable nommée SSLKEYLOGFILE.
Créez un fichier pour enregistrer le secret de pré-maître SSL dans un répertoire privé : SSLKEYLOGFILE =</path/to/private/directory/with/logfile>
Étape 3. Si Firefox ou Chrome sont ouvert, clôturez les applications. Après qu'ils soient rouverts, ils commenceront l'écriture au SSLKEYLOGFILE.
Étape 4. Sur Wireshark, naviguez pour éditer > des préférences…
Naviguez vers les protocoles > le SSL.
Étape 5. Entrez l'emplacement du nom du fichier secret de log de pré-maître configuré dans l'étape 2.
Étape 6. Utilisant le SSL de && du filtre tcp.port==7443 de Wireshark, la transmission sécurisée de HTTP entre le client de finesse et le serveur de finesse (service de notification) est vue a déchiffré.
Défauts associés
- CSCva72280 - La finesse Tomcat et Openfire crash pour les caractères non valides XML
- CSCva72325 - UCCX : La finesse Tomcat et Openfire crash pour les caractères non valides XML
Informations connexes
- Caractéristiques XMPP
- XEP-0124 : BÊTISES
- XEP-0060 : Éditer-abonnez-vous
- Console Web de Firefox
- Console Web d'Internet Explorer
- Console Web de Chrome
- Windows PowerShell
- Moniteur de performances de Windows
- Dépannage des suppressions dans la file d'attente d'entrée et de sortie
- Gestionnaire de tâches de Windows
- Terminal de MAC
- Moniteur d'activité de MAC
- Téléchargement de violoneur
- Configuration de violoneur
- Téléchargement de Wireshark
- Déchiffrement SSL de Wireshark
- Support et documentation techniques - Cisco Systems
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)