Entienda la implementación de la PALABRERÍA de la delicadeza y resuelva problemas los problemas de la desconexión de la presencia del escritorio del agente de la delicadeza
Contenido
Introducción
Este documento describe la arquitectura detrás de las conexiones de la delicadeza que utilizan las Bidireccional-secuencias sobre HTTP síncrono (PALABRERÍA) y de cómo los Problemas de conexión de la PALABRERÍA pueden ser diagnosticados.
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Delicadeza de Cisco
- Empresa unificada del Centro de contacto (UCCE)
- Centro de contacto unificado expreso (UCCX)
- Herramientas del desarrollador del buscador Web
- La administración de Windows y/o del mac
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Delicadeza de Cisco 9.0(1) - 11.6(1)
- UCCX 10.0(1) - 11.6(2)
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Comprensión de la puesta en práctica de la PALABRERÍA de la delicadeza
Comprensión de XMPP
La Mensajería y el protocolo extensibles de la presencia (XMPP) (también conocido como Jabber) es un protocolo con estado en un client-server model. XMPP permite la salida rápida de los pequeños pedazos de datos estructurados del Lenguaje de marcado extensible (XML) a partir de una entidad a otra. XMPP/Jabber se utiliza extensivamente en las aplicaciones de la Mensajería inmediata (IM) y de la presencia.
Todas las entidades XMPP son identificadas por su identificación del Jabber (JID).
Esquema de dirección JID: user@domain /resource
| usuario | nombre de usuario del cliente en el servidor XMPP o el nombre de la sala de conferencia |
| domain | Nombre de dominio completo (FQDN) del servidor XMPP |
| recurso | identificador de la entidad/de la punto final específicas (e.g., computadora portátil, smartphone, etc) del usuario, un identificador de sesión, o Nombre del nodo del pubsub |
Los mensajes XMPP se llaman las estrofas. Hay tres estrofas de la base en XMPP:
1. <message>: una dirección, un beneficiario
2. <presence>: una dirección, publica a muchos
3. <iq>: información/interrogación - petición/respuesta
Todas las estrofas tienen que y de los direccionamientos y de la mayoría de las estrofas también tener el tipo, la identificación, y xml: langattributes.
| Atributo de la estrofa | Propósito |
| a | destino JID |
| de | fuente JID |
| tipo | propósito del mensaje |
| identificación | Identificador único usado para conectar una petición a una respuesta para las estrofas del <iq> |
| xml: lang | define el idioma predeterminado para cualquier XML legible en la estrofa |
Mensaje del ejemplo 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>
Puesta en práctica XMPP con la delicadeza
Si una aplicación de Web necesita trabajar con XMPP, los problemas múltiples se presentan. Los navegadores no utilizan XMPP sobre el Transmission Control Protocol (TCP) nativo, así que todo el tráfico XMPP se debe manejar por un programa que se ejecute dentro del navegador. Los servidores Web y los navegadores comunican vía los mensajes del Hypertext Transfer Protocol (HTTP), así que la delicadeza y otras aplicaciones de Web envuelven los mensajes XMPP dentro de los mensajes HTTP.
La primera dificultad con este acercamiento es que el HTTP es un protocolo apátrida. Esto significa que cada solicitud HTTP no está relacionada con ninguna otra petición. Sin embargo, este problema se puede abordar por aplicable significa--por ejemplo con el uso de los Cookie/de los datos del poste.
La segunda dificultad es el comportamiento unidireccional del HTTP. Solamente el cliente envía las peticiones, y el servidor puede responder solamente. La incapacidad del servidor para empujar los datos hace artificial ejecutar XMPP sobre el HTTP.
Este problema no existe en la especificación original de la base XMPP (RFC 6120), donde XMPP está limitado al TCP. Sin embargo, si usted quiere abordar el problema con XMPP limitado al HTTP, por ejemplo, porque el Javascript puede enviar las solicitudes HTTP, hay dos Soluciones posibles. Ambos requieren un puente entre el HTTP y XMPP.
Las soluciones propuestas son:
1. El sondear (protocolo heredado): solicitudes HTTP relanzadas que piden los nuevos datos definidos en el XEP-0025: Interrogación del Jabber HTTP
2. El sondear largo también se conoce como PALABRERÍA: el Transport Protocol que emula a la semántica de una conexión TCP duradera, bidireccional entre dos entidades por eficientemente usando la solicitud HTTP/la respuesta síncronas múltiples empareja sin requerir el uso de la interrogación frecuente definido en el XEP-0124: Atascamiento HTTP y extendido por el XEP-0206: XMPP sobre la PALABRERÍA
La delicadeza ejecuta la PALABRERÍA pues es muy eficiente desde el punto de vista de la carga del servidor y tráfico-sabio. El propósito de usar la PALABRERÍA es cubrir para arriba el hecho de que el servidor no tiene que responder pues pronto hay una petición. La respuesta se retrasa hasta un tiempo especificado hasta que el servidor tenga datos para el cliente, y entonces se envía como respuesta. Tan pronto como el cliente consiga la respuesta, el cliente hace una nueva petición y así sucesivamente.
El cliente de escritorio de la delicadeza (aplicación de Web) establece una conexión añeja de la PALABRERÍA sobre el puerto TCP 7443 cada 30 segundos. Después de 30 segundos, si no hay actualizaciones del servicio de notificación de la delicadeza, el servicio de notificación envía una contestación HTTP con un cuerpo vacío de la AUTORIZACIÓN 200 y de la respuesta a (casi). Si el servicio de notificación tiene una actualización en la presencia de un agente o un evento del diálogo (llamada), por ejemplo, los datos se envían inmediatamente al cliente de Web de la delicadeza.
Delicadeza XMPP Reqeust/respuesta del ejemplo
Este ejemplo muestra la primera respuesta de la petición del mensaje XMPP compartida entre el cliente de la delicadeza y el servidor de la delicadeza para poner la conexión de la PALABRERÍA.
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>
Para resumir:
- El cliente de Web de la delicadeza tiene una conexión añeja HTTP (HTTP-lazo) puesta al servidor de la delicadeza vía el puerto 7443 TCP. Esto se conoce como encuesta larga de la PALABRERÍA.
- El servicio de notificación de la delicadeza es un servicio de la presencia que fija las actualizaciones con respecto al estado de un agente, de una llamada, de un etc.
- Si el servicio de notificación tiene una actualización, contesta a la petición del HTTP-lazo con la actualización del estado como mensaje XMPP en el cuerpo del HTTP de respuesta.
- Si hay ningún estado pone al día 30 segundos después de recibir la petición del HTTP-lazo, el servicio de notificación contesta sin ningunas actualizaciones del estado para permitir que el cliente de Web de la delicadeza envíe otra petición del HTTP-lazo. Esto sirve como manera para el servicio de notificación de saber que el cliente de Web de la delicadeza puede todavía conectar con el servicio de notificación y que el agente no cerró a su navegador ni puso su ordenador para dormir, el etc.
Comprensión de los mensajes de la delicadeza XMPP y de los Nodos XMPP
La delicadeza también ejecuta el XEP-0060 de la especificación XMPP: Publicar-suscriba. El propósito de esta especificación es permitir que el servidor XMPP (servicio de notificación) consiga la información publicada a los Nodos XMPP (temas) y después envíe los eventos XMPP a las entidades suscritas al nodo. En el caso de la delicadeza, el servidor del Integración de telefonía de computadora (CTI) envía los mensajes CTI al servicio web de la delicadeza para decir la delicadeza sobre creación o información de la cola del servicio de las actualizaciones de la configuración por ejemplo, pero no limitado a, del agente o del contacto (CSQ) sobre una llamada. Esta información entonces se convierte en un mensaje XMPP que el servicio web de la delicadeza publique al servicio de notificación de la delicadeza. El servicio de notificación de la delicadeza entonces envía XMPP sobre los mensajes de la PALABRERÍA a los agentes que se suscriben a ciertos Nodos XMPP.
Algunos de los objetos de la delicadeza API que se definen en la guía del desarrollador de los servicios web de la delicadeza son Nodos XMPP. Los clientes de Web de la delicadeza del agente y del supervisor pueden suscribir a las actualizaciones del evento para algunos de estos Nodos XMPP para tener información actualizada sobre los eventos en tiempo real (tales como eventos de la llamada, eventos del estado, y así sucesivamente). Esta tabla muestra los Nodos XMPP que son pubsub activado.
| Objeto de la delicadeza API | Propósito | Suscripción |
| <LoginID> de /finesse/api/User/ | Muestra la asignación del estado y del equipo del agente | Agentes y supervisores |
| /finesse/api/User/ <LoginID>/Dialogues |
Muestra las llamadas que son dirigidas por el agente | Agentes y supervisores |
| /finesse/api/User/ <LoginID>/ClientLog |
Utilizado para capturar al cliente los registros del informe de error del envío abotonan | Agentes y supervisores |
| /finesse/api/User/ <LoginID>/Queue/<queueID> |
Muestra los datos estadísticos de la cola (si está activado) | Agentes y supervisores |
| /finesse/api/Team/ <TeamID>/Users |
Muestra los agentes que pertenecen a cierto equipo incluyendo la información del estado | Supervisores |
| /finesse/api/SystemInfo |
Muestra el estado del servidor de la delicadeza. Utilizado para determinar si la Conmutación por falla es necesaria | Agentes y supervisores |
Ejemplo 1: Usando el Pidgin para ver los Nodos de la delicadeza XMPP
Paso 1. Descargue y instale el Pidgin del cliente XMPP.
Paso 2. Navegue a las cuentas > se modifican > básico y configuran las opciones de la clave:
- Protocolo: XMPP
- Nombre de usuario: LoginID para cualquier agente
- Dominio: FQDN del servidor de la delicadeza
- Recurso: Placeholder - cualquier valor se puede utilizar, por ejemplo, prueba
- Contraseña: Contraseña del agente
- Controle el checkbox de la contraseña del recordar
Paso 3. Navegue a las cuentas > se modifican > avanzó y configuran:
- Seguridad de la conexión: Utilice el cifrado si está disponible
- Controle el texto simple de la permit auténtico otras secuencias unencrypted
- Puerto de conexión: 5222. Utilice el puerto predeterminado 5222. Este puerto se requiere para los clientes externos XMPP. Uso 7443 de los clientes de escritorio de la delicadeza. No utilice el puerto 7443.
- Servidor de la conexión: Servidor FQDN de la delicadeza
Paso 4. Navegue a las herramientas > a los plug-in y active la consola XMPP.
Paso 5. Navegue a las herramientas > a la consola XMPP > a la consola XMPP para abrir la consola XMPP.
Paso 6. Ejecute este mensaje del <iq> para ver todos los Nodos XMPP que existan.
<iq type='get' from='<loginID>@<Finesse_FQDN>/test' to='pubsub.<Finesse_FQDN>' id='testId1'
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
Por ejemplo:
<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>
En un entorno del laboratorio con dos agentes y dos CSQ configurados, esta salida se contiene en la respuesta de la delicadeza:
<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>
Ejemplo 2: Usando el navegador el desarrollador equipa la tabulación de la red para ver los mensajes HTTP
Cada navegador tiene un conjunto de las herramientas del desarrollador. La tabulación de la red de las herramientas del desarrollador muestra los mensajes HTTP enviados y recibidos por el cliente de Web de la delicadeza (navegador). Por ejemplo, esta imagen muestra cómo el cliente de Web de la delicadeza envía una petición de SystemInfo cuál controla el estatus de Tomcat de la delicadeza cada minuto como control de la Conmutación por falla. Además, los mensajes del HTTP-lazo de la conexión de la PALABRERÍA también se visualizan. El servidor de la delicadeza devuelve una respuesta en el plazo de 30 segundos si no hay actualizaciones a publicar en los Nodos XMPP que suscriben al cliente de Web a.
Troubleshooting: Mensaje de error de la desconexión de la PALABRERÍA
Cuando ocurre una desconexión de la PALABRERÍA, el error “perdió la conexión a {el servidor FQDN de la delicadeza}. Espere por favor un servidor accesible de la delicadeza que se encontrará que…” está visualizado en un banner rojo en la cima del escritorio de la delicadeza.
Se visualiza este mensaje porque en este tiempo, ningunos eventos de la suscripción XMPP se pueden recibir del servicio de notificación de la delicadeza de Cisco. Por lo tanto, la información del estado y los detalles de llamada no se pueden visualizar en el escritorio del agente.
Para UCCX, el temporizador de la fin de comunicación es 60 segundos después de que desconexión del navegador. El agente puede estar en el listo o no el estado Ready (Listo) para que la fin de comunicación suceda.
Para UCCE, la delicadeza toma hasta 120 segundos para detectar cuando un agente cierra al navegador o el navegador causa un crash y la delicadeza espera 60 segundos antes de enviar una petición forzada de la fin de comunicación al servidor CTI. Bajo estas condiciones, la delicadeza puede tomar hasta 180 segundos para firmar hacia fuera el agente.
Para más información sobre el comportamiento de escritorio de la delicadeza UCCE, refiera a la sección de escritorio del comportamiento del capítulo de los mecanismos de la Conmutación por falla de la delicadeza de Cisco en la guía de administración de la delicadeza de Cisco.
Análisis del registro
La delicadeza y los registros del servicio de notificación UCCX se pueden recoger vía RTMT o vía el CLI:
el fichero consigue el activelog /desktop se repite compresa
Registros del servicio de notificación de la depuración
Active los registros de la depuración del servicio de notificación del Centro de contacto unificado expreso (UCCX), como se muestra:
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.
Active los registros de la depuración del servicio de notificación de la empresa unificada del Centro de contacto (UCCE) (delicadeza independiente), como se muestra:
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
Estos registros están en la carpeta de /desktop/logs/openfire y se nombran debug.log.
Tal y como se muestra en de la imagen, el servicio de notificación (Openfire) debug.log muestra el HTTP que ata con el escritorio junto con la dirección IP y el puerto de la PC del agente.
Tal y como se muestra en de la imagen, el active pasado 0 ms muestra que la sesión es todavía activa.
Openfire cerrando a la sesión inactiva indica que la fin de comunicación del agente accionará en 60 segundos donde la delicadeza enviará una fin de comunicación forzada con un código de motivo de 255 al servidor CTI. El comportamiento real del escritorio bajo estas condiciones depende de la configuración para la fin de comunicación en la desconexión del agente (CARGA) en UCCE. En UCCX, éste es siempre el comportamiento.
Si el cliente de Fineese no envía los mensajes del HTTP-lazo al servidor de la delicadeza, los registros mostrarán la sesión encima del tiempo y mostrarán el cierre de la sesión.
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>
Registros de servicio de la notificación de información
Estos registros están en la carpeta de /desktop/logs/openfire y se nombran info.log. Si el cliente de Fineese no envía los mensajes del HTTP-lazo al servidor de la delicadeza, los registros mostrarán que el sesión llega a estar inactiva.
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
Registros de Webservices
Estos registros están en la carpeta de /desktop/logs/webservices y se nombran Desktop-webservices.YYYY-MM-DDTHH-MM-SS.sss.log. Si el cliente de Fineese no envía los mensajes del HTTP-lazo al servidor de la delicadeza dentro de la cantidad de tiempo especificada, los registros mostrarán que el presencia del agente llega a ser inasequible y ocurrirán 60 segundos después, una fin de comunicación conducida presencia.
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
Razones comunes para la desconexión de la PALABRERÍA
Las conexiones de la PALABRERÍA son puestas por el cliente de Web, y el servidor de la delicadeza determina si la presencia del agente es inasequible. Estos problemas son casi siempre problemas laterales del cliente referentes el navegador, la computadora agente, o a la red pues la responsabilidad de comenzar encima de la conexión incumbe al cliente.
Problema: Los agentes desconectan en los momentos diferentes (el problema lateral del cliente)
Acciones recomendadas
Controle para saber si hay estos problemas:
1. Problema de red:
- Reglas de firewall y registros del estudio -- El puerto 7443 TCP no debe ser bloqueado o ser estrangulado
- Utilice un sniffer del tráfico de la Web HTTP como el ® del Fiddler o el ® de Wireshark para confirmar que el navegador envía las peticiones del HTTP-lazo sobre el puerto 7443 TCP y recibe las respuestas
- Controle todos los dispositivos de red/interfaces entre la computadora agente y el servidor de la delicadeza para saber si hay descensos del Retraso excesivo o del paquete
- Traceroute puede ser útil para determinar la trayectoria y para determinar los retrasos
- En una PC del ® de Windows del ® de Microsoft: tracert {delicadeza IP del servidor | Servidor FQDN de la delicadeza}
- En un ® del mac: traceroute {la delicadeza separa el IP | Servidor FQDN de la delicadeza}
- En el software del ® del Cisco IOS, las estadísticas del interfaz pueden ser controladas: show interfaces
- Traceroute puede ser útil para determinar la trayectoria y para determinar los retrasos
- Recoja los registros del cliente de la delicadeza para un agente de prueba. Los registros del cliente se pueden recoger de tres maneras:
- Registros de la consola Web del navegador
- Presione el botón del informe de error del envío en la página de la delicadeza y recoja los registros del servidor de la delicadeza. Los registros están situados en /desktop/logs/clientlogs.
- Ábrase una sesión vía https:// <Finesse-FQDN>/desktop/locallog y recoja los registros después de que ocurra el problema.
Cada minuto, el cliente conecta con el servidor de la delicadeza para calcular la deriva y la latencia de red:
<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 caso de cualquier problema de la colección del registro, refiera el problema persistente de escritorio del registro de la delicadeza de Cisco del Troubleshooting
2. Navegador y/o versión sin apoyo:
Utilice el buscador admitido/la versión y las configuraciones según las matrices de compatibilidad:
3. Contentar debido/proceso de la condición de atascamiento del navegador de la otra tabulación/ventana:
Controle el flujo de trabajo del agente para ver si ellas:
- Tenga comúnmente otras tabulaciones o ventanas para arriba que estén ejecutando constantemente otras aplicaciones en tiempo real tales como música/flujo de datos de video, conexiones de WebSocket, clientes de Web de encargo de la Administración de la relación del cliente (CRM), etc
- Tenga un gran número de tabulaciones o las ventanas se abren
- Han inhabilitado el almacenamiento en memoria inmediata del navegador
- Han guardado a su navegador el ejecutarse durante mucho tiempo y no cierran al navegador en el final del día laborable
4. Ordenador puesto para dormir:
Controle para ver si el agente pone su ordenador para dormir antes de registrar fuera de la delicadeza o si su temporizador de la configuración del sueño del ordenador es muy bajo.
5. CPU elevada o problema de memoria alta en la computadora cliente:
- Si el navegador del agente se ejecuta en un entorno compartido tal como servicios del Escritorio Remoto de Microsoft Windows, el ® de XenApp del ® de Citrix, ® de Citrix XenDesktop, determina si el funcionamiento del buscador depende del número de usuarios que funcionan con al navegador al mismo tiempo
- Asegúrese de que memoria apropiada y los recursos CPU esté configurada sobre la base del número de usuarios
- Controle los problemas de utilización de recursos del ordenador:
- Windows:
- Comando del Conseguir-contador de Windows PowerShell que controla % de hora de la CPU, megabytes de memoria disponibles, y % de la memoria funcionando cada 2 segundos: Conseguir-contador - “\ Procesador (_Total) \ % del contador del tiempo del procesador”, “\ memoria \ MBYTEs disponibles”, “\ memoria \ % continuo funcionando confiada de los bytes” - SampleInterval 2 -
- La alternativa a usar PowerShell para ver los contadores de rendimiento de Windows, monitor de rendimiento de Windows puede ser utilizada
- El administrador de tareas puede ser utilizado para ver las estadísticas vivas CPU y de la memoria global y en una base del proceso-por-proceso
- Mac:
- Comando top terminal que viven los controles CPU total y memoria: top
- Controle los procesos y clasifiqúelos por la utilización CPU: top - CPU o
- Controle los procesos y clasifiqúelos por la utilización de la memoria: top - o MEM
- El monitor de actividad se puede utilizar para ver las estadísticas vivas CPU y de la memoria global y en una base del proceso-por-proceso
- Comando top terminal que viven los controles CPU total y memoria: top
- Windows:
6. gadgets de las de otras compañías que realizan la actividad inesperada, problemática en el fondo:
Pruebe el comportamiento de escritorio de la delicadeza con todos los gadgets de las de otras compañías quitados.
7. Problema NTP en el servidor o el cliente:
- El estatus NTP de los utils del control en el servidor editor de la delicadeza para asegurar el estrato del servidor NTP es 4 o más bajo
- En los registros del cliente, controle la deriva y la latencia de red
Problema: Toda la desconexión de los agentes al mismo tiempo (Problemas en el lado del servidor)
Acciones recomendadas
Controle para saber si hay estos problemas:
1. Desconexión del servicio de CTIManager del encargado de las Comunicaciones unificadas de Cisco. Si todos los proveedores de CTIManager para UCCX son parada normal o caída, los agentes UCCX ven el error rojo del banner. Los agentes UCCE no ven el banner rojo si sucede éste, pero las llamadas no pueden encaminar propertly a los agentes.
- Controle para ver si el servicio de Cisco CTIManager se comienza en los servidores CUCM usados como proveedores de CTI
- Controle para ver si el servicio de Cisco CTIManager causado un crash vía el espectador del evento - la aplicación abre una sesión RTMT para considerar si el servicio de Cisco CTIManager causó un crash
- Para recoger el espectador del evento abre una sesión RTMT: El sistema > las herramientas > la central del rastro y del registro > recogen los ficheros > los servicios del sistema/las aplicaciones > registro selectos de la Espectador-aplicación del evento
- Para recoger la Espectador-aplicación del evento abre una sesión el CLI: el fichero consigue el activelog /syslog/CiscoSyslog * hh del abstime: milímetro: Hh MM/DD/YY: milímetro: MM/DD/YY
- Para ver los vaciados de memoria en el CLI: los utils quitan el corazón a la lista activa
2. Servicio de notificación Finesse/UCCX parado o causado un crash:
- Controle los registros de la Espectador-aplicación del evento para saber si hay errores del servicio de notificación o ver si el servicio fue parado
- Controle para ver si el servicio de notificación está para arriba: lista del servicio de los utils
- Controle los tiempos el servicio de notificación cerrado: clasifíe el activelog /desktop/logs/openfire “Openfire de la búsqueda paró”
- Controle los tiempos el servicio de notificación comenzado: clasifíe el activelog /desktop/logs/openfire “servicio de la búsqueda del lazo HTTP comenzado”
- Controle para saber si hay vaciados de memoria del servicio de notificación que resultaron de una caída: activelog /desktop/logs/openfire/ *.hprof de la lista de archivos
- Controle para ver si el servicio de notificación está estando atento el tráfico en el puerto 7443 TCP: muestre el regexp 7443.*LISTEN de los puertos abiertos
- Controle para ver si estos defectos son aplicables (estos defectos causarían la falla de registro para los agentes que abren una sesión y para los agentes abiertos una sesión ya, esos agentes verían el mensaje rojo de la desconexión de la delicadeza del banner):
- CSCva72280 - La delicadeza Tomcat y Openfire caída para los caracteres inválidos XML
- CSCva72325 - UCCX: La delicadeza Tomcat y Openfire caída para los caracteres inválidos XML
Recomience la delicadeza Tomcat de Cisco y el servicio de notificación si se sospecha una caída. Esto se recomienda solamente en una situación de la red abajo, si no, estos agentes de la desconexión de los reinicios del servidor de la delicadeza.
- Pasos para UCCE:
- delicadeza Tomcat de Cisco de la parada del servicio de los utils
- servicio de notificación de la delicadeza de Cisco de la parada del servicio de los utils
- delicadeza Tomcat de Cisco del comienzo del servicio de los utils
- servicio de notificación de la delicadeza de Cisco del comienzo del servicio de los utils
- Pasos para UCCX:
- delicadeza Tomcat de Cisco de la parada del servicio de los utils
- la parada Cisco del servicio de los utils unificó el servicio de notificación CCX
- delicadeza Tomcat de Cisco del comienzo del servicio de los utils
- el comienzo Cisco del servicio de los utils unificó el servicio de notificación CCX
Usando el Fiddler
Configurar al Fiddler puede ser algo una tarea difícil sin la comprensión de los pasos necesarios y la comprensión de cómo el Fiddler trabaja. El Fiddler es un hombre-en--medio Web Proxy (Proxy Web) que se coloca entre el cliente de la delicadeza (buscador Web) y el servidor de la delicadeza. Debido a las conexiones que son aseguradas entre el cliente de la delicadeza y el servidor de la delicadeza, esto agrega una capa de complejidad a la configuración del Fiddler para ver los mensajes asegurados.
Problema común del Fiddler
Puesto que el Fiddler se coloca entre el cliente de la delicadeza y el servidor de la delicadeza, la aplicación del Fiddler necesita crear los certificados firmados para todos los puertos de la delicadeza TCP que requieran los Certificados:
Certificados del servicio de Tomcat de la delicadeza de Cisco
- Servidor editor TCP 8445 (y/o 443 de la delicadeza para UCCE)
- Servidor del suscriptor TCP 8445 (y/o 443 de la delicadeza para UCCE)
Certificados del servicio de notificación de la delicadeza de Cisco (unificada CCX)
- Servidor editor TCP 7443 de la delicadeza
- Servidor del suscriptor TCP 7443 de la delicadeza
El desciframiento HTTPS se debe activar para que el Fiddler genere dinámicamente los Certificados en nombre del servidor de la delicadeza. Esto no se activa por abandono.
Si el desciframiento HTTPS no se configura, la conexión del túnel inicial al servicio de notificación se considera, pero el tráfico del HTTP-lazo no es. Demostraciones del Fiddler solamente:
Tunnel to <Finesse server FQDN>:7443
Entonces, los Certificados de la delicadeza firmados por el Fiddler se deben confiar en por el cliente. Si estos Certificados no se confían en, pasado de mudanza la etapa de establecimiento de la conexión encriptada… de la clave de la delicadeza no es posible.
En algunos casos, validar las excepciones del certificado de la clave no trabaja, y los Certificados necesitan ser confiados en por el navegador manualmente.
Pasos del ejemplo de configuración
Paso 1. Fiddler de la transferencia directa
Paso 2. Desciframiento del permiso HTTPS: Herramientas > opciones > HTTPS > control el checkbox del tráfico del Decrypt HTTPS
Paso 3. Un cuadro de mensaje de advertencia abierto pedir confiar en el certificado raíz del Fiddler. Seleccione sí.
Paso 4. Un cuadro de mensaje de advertencia se abre con el mensaje “que usted está a punto de instalar un certificado de las autoridades de certificación (CA) que demandan representar: DO_NOT_TRUST_FiddlerRoot… Usted quiere instalar este certificado?”. Seleccione sí.
Paso 5. Agregue manualmente los Certificados del editor y suscriptor de la delicadeza al almacén de la confianza del certificado del ordenador o del navegador. Asegure los puertos 8445, 7443, y (solamente para UCCE) 443. Por ejemplo, en Firefox, esto puede ser hecha simplemente sin descargar los Certificados de la página de administración del sistema operativo de la delicadeza:
Las opciones > el hallazgo en las opciones (búsqueda) > certifica > los servidores > agregan la excepción > la ubicación > ingresan el server> del <Finesse de https://: vire hacia el lado de babor para los puertos relevantes para ambos servidores de la delicadeza.
Paso 6. El registro en la delicadeza y ve los mensajes del HTTP-lazo dejar al cliente de la delicadeza al servidor de la delicadeza vía el Fiddler.
En el ejemplo proporcionó, los primeros 5 mensajes del HTTP-lazo de la demostración de los mensajes que fueron respondidos por al servidor de la delicadeza. El primer mensaje contiene 1571 bytes de dato vueltos en el cuerpo del mensaje. El cuerpo contiene una actualización XMPP con respecto a un evento del agente. El mensaje final del HTTP-lazo ha sido enviado por el cliente de la delicadeza, pero no ha conseguido una respuesta del servidor de la delicadeza. Esto se puede determinar viendo que el resultado HTTP es nulo (-) y la cantidad de bytes en el cuerpo de la respuesta es la falta de información (-1).
Una vista más cercana de los datos:
Cuerpo de la respuesta para el mensaje XMPP:
Usando Wireshark
Wireshark es una herramienta de uso general del rastreo de paquetes que se puede utilizar para oler y para decodificar el tráfico HTTPS. El tráfico HTTPS es tráfico HTTP asegurado sobre Transport Layer Security (TLS). TLS proporciona a la integridad, a la autenticación y a la confidencialidad en medio a los host. Se utiliza comúnmente en las aplicaciones de Web, pero puede ser utilizado con cualquier protocolo que utilice el TCP como el protocolo de capa de transporte. Secure Sockets Layer (SSL) es la versión anterior del protocolo de TLS, que se utiliza no más pues es inseguro. Estos nombres son de uso frecuente alternativamente, y el filtro de Wireshark usado para el tráfico SSL o de TLS es SSL.
Paso 1. En el PC de Windows del agente navegue al panel de control > al sistema y la Seguridad > el sistema > avanzaron las variables de entorno de los ajustes de sistema…
Paso 2. Navegue a las Variables variables de usuario para el <username> del usuario > nuevo…
Cree una variable nombrada SSLKEYLOGFILE.
Cree un fichero para salvar el secreto del pre-master SSL en un directorio privado: SSLKEYLOGFILE =</path/to/private/directory/with/logfile>
Paso 3. Si Firefox o Chrome está abierto, cierre las aplicaciones. Después de que se abran de nuevo, comenzarán a escribir al SSLKEYLOGFILE.
Paso 4. En Wireshark, navegue para corregir > las preferencias…
Navegue a los protocolos > al SSL.
Paso 5. Ingrese la ubicación del nombre de fichero secreto del registro del pre-master configurado en el paso 2.
Paso 6. Usando el SSL del && del filtro tcp.port==7443 de Wireshark, la comunicación asegurada HTTP entre el cliente y el servidor de la delicadeza (servicio de notificación) de la delicadeza se considera desencriptó.
Defectos relacionados
- CSCva72280 - La delicadeza Tomcat y Openfire caída para los caracteres inválidos XML
- CSCva72325 - UCCX: La delicadeza Tomcat y Openfire caída para los caracteres inválidos XML
Información Relacionada
- Especificaciones XMPP
- XEP-0124: PALABRERÍA
- XEP-0060: Publicar-suscriba
- Consola Web de Firefox
- Consola Web del Internet Explorer
- Consola Web de Chrome
- Windows PowerShell
- Monitor de rendimiento de Windows
- Resolución de problemas en los paquetes descartados en las colas de entrada y salida
- Administrador de tareas de Windows
- Terminal del mac
- Monitor de actividad del mac
- Transferencia directa del Fiddler
- Configuración del Fiddler
- Transferencia directa de Wireshark
- Descifrado SSL de Wireshark
- Soporte Técnico y Documentación - Cisco Systems
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)