cisco finesse что это

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Базовый курс по Asterisk

Мы собрали концентрат всех must have знаний в одном месте, которые позволят тебе сделать шаг вперед на пути к экспертному владению Asterisk

Подключаемся к Extension Mobility

Чтобы подключиться к Extension Mobility, с телефонного аппарата:

После этого, телефон перезагрузится и будет с новым профилем и номером. Разлогиниться можно в аналогичной последовательности.

Запуск агентского приложения Finesse

Готово. Если вам нужно выйти из приложения, то под залогиненным пользователем нужно изменить статус работы на «Не готов«, «Конец смены» или аналогичный статус у вас, который обозначает окончание работы. Затем, нажмите в правом верхнем углу кнопку Sign Out.

Как выглядит интерфейс менеджера в Finesse?

Как выглядит интерфейс агента/оператора в Finesse?

Статистика по очереди показывает агенту количество звонящих в КЦ людей, ожидающих ответа в очереди. Так же сегмент покажет самое длинное время ожидания ответа в очереди.

В зоне «Отчет по команде«, агент может видеть своих коллег, их статусы готовности, а также причину неготовности в виде числового кода.

Состояния агентов

Тут все достаточно просто. Если агент не готов, то его статус выглядит вот так (красный индикатор):

Меняем статус агента

Ответить на звонок

Обработка звонка в Finesse

Во время разговора с клиентом агент видит:

Трансфер звонка

Чтобы выполнить трансфер звонка:

Конференция

Чтобы собрать конференцию звонка:

Выполнить исходящий вызов

Чтобы выполнить исходящий звонок из Cisco Finesse:

Продвинутый курс по Asterisk

Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.

Источник

Understand Finesse BOSH Implementation and Troubleshoot Finesse Agent Desktop Presence Disconnect Issues

Available Languages

Download Options

Contents

Introduction

This document describes the architecture behind Finesse connections that use Bidirectional-streams Over Synchronous HTTP (BOSH) and how BOSH connection problems can be diagnosed.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

Components Used

The information in this document is based on these software and hardware versions:

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. If your network is live, ensure that you understand the potential impact of any command.

Understanding Finesse BOSH Implementation

Understanding XMPP

Extensible Messaging and Presence Protocol (XMPP) (also known as Jabber) is a stateful protocol in a client-server model. XMPP allows for fast delivery of small pieces of structured eXtensible Markup Language (XML) data from one entity to another. XMPP/Jabber is extensively used in instant messaging (IM) and presence applications.

All XMPP entities are identified by their Jabber ID (JID).

JID Addressing Scheme: user@domain/resource

Note: All three JID components are not used in all cases. A server would typically just be defined by the domain, a conference room defined by user@domain, and a client by user@domain/resource.

XMPP messages are called stanzas. There are three core stanzas in XMPP:

1. : one direction, one recipient

XMPP Implementation with Finesse

If a web application needs to work with XMPP, multiple issues arise. Browsers don’t support XMPP over Transmission Control Protocol (TCP) natively, so all XMPP traffic must be handled by a program which runs inside the browser. Web servers and browsers communicate via HyperText Transfer Protocol (HTTP) messages, so Finesse and other web applications wrap XMPP messages inside of HTTP messages.

The first difficulty with this approach is that HTTP is a stateless protocol. This means that each HTTP request is not related to any other request. However, this problem can be addressed by applicative means—for example through the use of cookies/post data.

The second difficulty is the unidirectional behavior of HTTP. Only the client sends requests, and the server can only respond. The server’s inability to push data makes it unnatural to implement XMPP over HTTP.

This problem does not exist in the original XMPP Core specification (RFC 6120), where XMPP is bound to TCP. However, if you want to address the problem with XMPP bound to HTTP, for example, because Javascript can send HTTP requests, there are two possible solutions. Both require a bridge between HTTP and XMPP.

The proposed solutions are:

1. Polling (legacy protocol): repeated HTTP requests asking for new data defined in XEP-0025: Jabber HTTP Polling

2. Long polling also is known as BOSH: transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling defined in XEP-0124: HTTP Binding and extended by XEP-0206: XMPP Over BOSH

Finesse implements BOSH as it is quite efficient from the server load point of view and traffic-wise. The purpose of using BOSH is to cover up the fact that the server does not have to respond as soon there is a request. The response is delayed up to a specified time until the server has data for the client, and then it is sent as a response. As soon as the client gets the response, the client makes a new request and so forth.

The Finesse desktop client (web application) establishes a stale BOSH connection over TCP port 7443 every 30 seconds. After 30 seconds, if there are no updates from the Finesse Notification Service, the Notification service sends an HTTP reply with a 200 OK and a (nearly) empty response body. If the Notification Service has an update on the presence of an agent or a dialog (call) event, for example, the data is sent immediately to the Finesse web client.

Example Finesse XMPP Reqeust/Response

This example shows the first XMPP message request response shared between the Finesse client and Finesse server to set up the BOSH connection.

Understanding Finesse XMPP Messages and XMPP Nodes

Finesse also implements XMPP specification XEP-0060: Publish-Subscribe. The purpose of this specification is to allow the XMPP server (Notification service) to get information published to XMPP nodes (topics) and then to send XMPP events to entities subscribed to the node. In the case of Finesse, the Computer Telephony Integration (CTI) server sends CTI messages to the Finesse web service to tell Finesse about configuration updates such as, but not limited to, agent or Contact Service Queue (CSQ) creation or information about a call. This information is then converted into an XMPP message that the Finesse web service publishes to the Finesse Notification service. The Finesse Notification service then sends XMPP over BOSH messages to agents that are subscribed to certain XMPP nodes.

Some of Finesse API objects that are defined in the Finesse Web Services Developer Guide are XMPP nodes. Agent and supervisor Finesse web clients may subscribe to event updates for some of these XMPP Nodes in order to have up-to-date information about r eal-time events (such as call events, state events, and so on). This table shows the XMPP nodes that are pubsub enabled.

Example 1: Using Pidgin to View Finesse XMPP Nodes

Step 1. Download and install the XMPP client Pidgin.

Step 2. Navigate to Accounts > Modify > Basic and configure the Login Options:

Step 3. Navigate to Accounts > Modify > Advanced and configure:

Note: Port 5222 is used because only Finesse web clients can use port 7443 to connect to the Notification Service.

Step 4. Navigate to Tools > Plugins and enable the XMPP Console.

Step 5. Navigate to Tools > XMPP Console > XMPP Console to open the XMPP Console.

Step 6. Execute this message to see all of the XMPP nodes that exist.

In a lab environment with two agents and two CSQs configured, this output is contained in the Finesse response:

Example 2: Using Browser Developer Tools Network Tab to View HTTP Messages

Each browser has a set of developer tools. The Network tab of the developer tools shows the HTTP messages sent and received by the Finesse web client (browser). For example, this image shows how the Finesse web client sends a SystemInfo request which checks Finesse Tomcat status every minute as a failover check. Additionally, the http-bind messages from the BOSH connection are also displayed. The Finesse server sends back a response within 30 seconds if there are no updates to publish on the XMPP nodes the web client is subscribed to.

Troubleshoot: BOSH Disconnect Error Message

When a BOSH disconnect occurs, the error «Lost connection to . Please wait for a reachable Finesse Server to be found. » is displayed in a red banner at the top of the Finesse desktop.

This message is displayed because at this time, no XMPP subscription events can be received from the Cisco Finesse Notification Service. Hence, state information and call details cannot be displayed on the agent desktop.

For UCCX, 60 seconds after the browser disconnects, the agent is put into a Logout state. The agent can be in the Ready or Not Ready state for the logout to happen.

For UCCE, Finesse takes up to 120 seconds to detect when an agent closes the browser or the browser crashes and Finesse waits 60 seconds before sending a forced logout request to the CTI server which causes the CTI server to put the agent in a Not Ready state. Under these conditions, Finesse can take up to 180 seconds to sign out the agent. Unlike in UCCX, the agent moves into a Not Ready state instead of the Logout state.

Note: The CTI disconnect Not Ready vs. Logout state behavior in UCCE is controlled by the PG /LOAD parameter. Per the Release Notes for Unified Contact Center Enterprise & Hosted Release 10.0(1), the /LOAD parameter is deprecated starting in UCCE 10.0.

For more information on UCCE Finesse Desktop behavior, refer to the Desktop Behavior section of the Cisco Finesse Failover Mechanisms chapter in the Cisco Finesse Administration Guide.

Note: Timer values might change in future as per the product requirement.

Log Analysis

The Finesse and UCCX Notification service logs can be collected via RTMT or via the CLI:

file get activelog /desktop recurs compress

Debug Notification Service Logs

Note: Set debug level logs only while reproducing an issue. Turn off the debugs after the issue has been reproduced.

Enable Notification Service debug logs of Unified Contact Center Express (UCCX), as shown:

Enable Notification Service debug logs of Unified Contact Center Enterprise (UCCE) (Finesse Standalone), as shown:

These logs are in the /desktop/logs/openfire folder and are named debug.log.

As shown in the image, the Notification Service (Openfire) debug.log shows the http binding with desktop along with the IP address and port of the agent PC.

As shown in the image, the last active 0 ms shows that session is still active.

Openfire closing the idle session indicates the agent logout will trigger in 60 seconds where Finesse will send a forced logout with a reason code of 255 to the CTI server. The actual behavior of the desktop under these conditions depends on the setting for Logout on Agent Disconnect (LOAD) in UCCE. In UCCX, this is always the behavior.

If the Fineese client does not send http-bind messages to the Finesse server, the logs will show the session up time and show the session close.

Info Notification Service Logs

These logs are in the /desktop/logs/openfire folder and are named info.log. If the Fineese client does not send http-bind messages to the Finesse server, the logs will show the the session become inactive.

Webservices Logs

Common Reasons for BOSH Disconnect

BOSH connections are setup by the web client, and the Finesse server determines if the agent presence is unavailable. These issues are almost always client side issues relating to the browser, agent computer, or network as the onus of starting up the connection is up to the client.

Problem: Agents disconnect at different times (client side issue)

Recommended Actions

Check for these issues:

Every minute, the client connects to the Finesse server to calculate drift and network latency:

2. Unsupported browser and/or version:

Use supported browser/version and settings as per the compatibility matrices:

3. Browser stuck condition due to content/processing of other tab/window:

Check the agent workflow to see if they:

4. Computer put to sleep:

Check to see if the agent puts their computer to sleep before logging out of Finesse or if their computer sleep setting timer is very low.

5. High CPU or high memory issue on client computer:

6. 3rd party gadgets performing unexpected, problematic activity in background:

Test the Finesse desktop behavior with all 3rd party gadgets removed.

7. NTP issue on server or client:

Problem: All agents disconnect at the same time (server side issue)

Recommended Actions

Check for these issues:

1. Cisco Unified Communications Manager CTIManager service disconnect. If all CTIManager providers for UCCX are shutdown or crash, UCCX agents see the red banner error. UCCE agents do not see the red banner if this happens, but calls fail to route propertly to the agents.

Note: Core dumps file names use the format: core.

2. Finesse/UCCX Notification Service stopped or crashed:

Restart Cisco Finesse Tomcat and Notification Service if a crash is suspected. This is only recommended in a network down situation, otherwise, these restarts disconnect agents from the Finesse server.

Using Fiddler

Configuring Fiddler can be a somewhat challenging task without understanding the steps needed and understanding how Fiddler works. Fiddler is a man-in-the-middle web proxy that stands between the Finesse client (web browser) and the Finesse server. Due to the connections being secured between the Finesse client and Finesse server, this adds a layer of complexity to the Fiddler configuration in order to view secured messages.

Common Fiddler Issue

Since Fiddler stands in between the Finesse client and Finesse server, the Fiddler application needs to create signed certificates for all Finesse TCP ports that require certificates:

Cisco Finesse Tomcat service certificates

Cisco Finesse (Unified CCX) Notification Service certificates

HTTPS decryption must be enabled for Fiddler to dynamically generate certificates on behalf of the Finesse server. This is not enabled by default.

If HTTPS decryption is not configured, the initial tunnel connection to the Notification service is seen, but the http-bind traffic is not. Fiddler only shows:

Then, the Finesse certificates signed by Fiddler must be trusted by the client. If these certificates are not trusted, moving past the Establishing encrypted connection. stage of Finesse login is not possible.

In some cases, accepting the certificate exceptions from the login does not work, and the certificates need to be trusted by the browser manually.

Example Configuration Steps

Step 1. Download Fiddler

Step 2. Enable HTTPS decryption: Tools > Options > HTTPS > check the Decrypt HTTPS traffic checkbox

Step 3. A warning message box open to ask to trust the Fiddler Root Certificate. Select Yes.

Step 4. A warning message box opens with the message «You are about to install a certificate from a certification authority (CA) claiming to represent: DO_NOT_TRUST_FiddlerRoot. Do you want to install this certificate?». Select Yes.

Step 5. Manually add the Finesse publisher and subscriber certificates to the computer or browser certificate trust store. Ensure ports 8445, 7443, and (only for UCCE) 443. For example, on Firefox, this can be done simply without downloading certificates from the Finesse Operating System Administration page:

Options > Find in Options (search) > Certificates > Servers > Add Exception > Location > Enter https:// :port for the relevant ports for both Finesse servers.

Step 6. Log into Finesse and see the http-bind messages leave the Finesse client to the Finesse Server via Fiddler.

In the example provided, the first 5 messages show http-bind messages that were responded to by the Finesse server. The first message contains 1571 bytes of data returned in the message body. The body contains an XMPP update regarding an agent event. The final http-bind message has been sent by the Finesse client, but has not gotten a response from the Finesse server. This can be determined by seeing that the HTTP result is null (-) and the number of bytes in the response body is null (-1).

Closer view of the data:

Response body for XMPP message:

Using Wireshark

Wireshark is a commonly used packet sniffing tool that can be used to sniff and decode HTTPS traffic. HTTPS traffic is HTTP traffic secured over Transport Layer Security (TLS). TLS provides integrity, authentication and confidentiality between to hosts. It is used commonly in web applications, but it can be used with any protocol that uses TCP as the transport layer protocol. Secure Sockets Layer (SSL) is the former version of the TLS protocol, which is no longer used as it is insecure. These names are often used interchangeably, and the Wireshark filter used for SSL or TLS traffic is ssl.

Caution: The example configuration provided is for Wireshark 2.6.6 (v2.6.6-0-gdf942cd8)and Mozilla Firefox 64.0.2 (32-bit) on Windows7 x64 in a lab environment. These procedures may not generalize to all versions of Fiddler, all browsers, or all computer operating systems. If your network is live, ensure that you understand the potential impact of any configuration. Reference the official Wireshark SSL documentation for more information. Wireshark 1.6 or greater is required.

Note: This method will only work for Firefox and Chrome. This method does not work for Internet Explorer.

Step 1. On the agent’s Windows PC navigate to Control Panel > System and Security > System > Advanced system settings Environmental Variables.

Step 2. Navigate to User variables for user > New.

Create a variable named SSLKEYLOGFILE.

Create a file to store the SSL premaster secret in a private directory: SSLKEYLOGFILE=

Note: Creating a system variable instead of a user variable and/or storing the file in a non-private directory will also work, but then all users on the system can access the premaster secret, which is less secure.

Step 3. If Firefox or Chrome are open, close the applications. After they are reopened, they will start writing to the SSLKEYLOGFILE.

Step 4. On Wireshark, navigate to Edit > Preferences.

Navigate to Protocols > SSL.

Step 5. Enter the location of the premaster secret log filename configured in Step 2.

Источник