This document describes how Enterprise Chat and Email(ECE) identifies the agent availability status when clients initiate chat sessions.
Cisco recommends that you have knowledge of these topics:
Enterprise Chat and Email
Web browsers Developer Tools
Unified Intelligent Contact Management Enterprise
The information in this document is based on the software version ECE 11.6.
The information in this document were created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration.
In order for Cisco Unified Intelligent Contact Management Enterprise(ICM) to manage the agent activities and properly route tasks, ICM must monitor all the agents that are logged into ICM. The application instances, like ECE, report the agent activities and agent status through the extended ICM CTI/ARM (Agent Report and Management) interface.
The ARM service is built upon the current CTI Server functionality and allows a client application to monitor application agents and task activity. The ARM Interface allows a client application to monitor a specified set of agents (workstation mode) or all agents (bridge mode) associated with an application.
The image shows more details of the ARM interfaces. An application instance uses the ARM interface to manage agents on one or more Agent PGs (log them in and out of media, etc) and to report on their task activity (Start Task, End Task, etc).
Agent Log in Flow
Agent availability is identified from CTI Server side. When an agent logs in to agent console, ECE Listener process sends the request to CTI Server. The request indicates that the agent is logged in and marked himself as available.
These are the indicators which are sent by ECE application to the CTI Server:
Whenever an agent is logged in, a listener sends a MEDIA_LOGIN_REQ. The MEDIA_LOGIN_REQ logs the specified agent into an Media Route Domain(MRD) (logs agent into all skills configured for that MRD and agent). When an agent marks himself as available, the listener does send two more requests that indicate that the agent is ROUTABLE or NOT ROUTABLE and READY or NOT READY, and provides client-defined agent information. The CTI client must have specified the Application Path for the related MRD Peripheral pair in the Open Request message or the log in is rejected. For the log in to succeed, the agent must also be configured to belong to at least one Skill Group(SG) that belongs to the indicated MRD.
The image shows the messages flow diagram for log in request:
Status 0 means No errors were occurred from CTI Server side.
Agent Availability Flow
If the agent is associated to the chat SG, and this SG is associated to the ECE queue in Chat Entry point, when agent marks himself available you do see 2 requests, the MAKE_AGENT_ROUTABLE_IND and MAKE_AGENT_READY_IND.
Make Agent Routable Indication tells to ICM that the specified agent has been set to a ROUTABLE mode for the specified MRD.
Note: The Make Agent Routable Indication message can be sent while it waits for a Make Agent Not Routable Response and cancels the pending Make Agent Not Routable Request.
Once Make Agent Ready Indication request is received by the listener from application server, the listener forwards the request to the CTI Server and at that moment the agent considered as available for ECE. In that case, if chat is initiated at the same time, the system allows to start and creates the chat activity for that chat.
The Listener log shows those requests if the INFO trace is enabled:
At this moment the agent is Routable and Available from the Router perspective. The best way to check this is to use the rttest utility:
rttest: agent_status /agent 6420
### 6520 is ICMAgtID
Agent CUCM.Agent_test (6420, periph# 15003)
domain: Cisco_Voice (1), state = [nr-0:1,R], 411 secs
CL nr TEST_SG (6274, periph# 70520)
L nr CUCM_PIM1.Cisco_Voice.defa.88025 (5000, periph# 31858)
domain: ECE_Chat (5000), state = [na-0:2,RA], 383 secs
CL na TEST_Chat (6928, periph# 70518)
L na CUCM.ECE_Chat.default.11006 (6909, periph# 54839)
na - NotActive
0:2 – AciteTasks:ConcurentTaskLimit
RA - R is routable (if set), A indicated the router considers the agent available for new work in this domain
Caution: In ICM 11.5, 11.6 and 12.0 you can hit the defect CSCvq11852 Chat and emails are not get assigned toagents even they are available. In such scenarios you do see in the rttest output [na-0:2,RD], where D means domain unavailable (as reported by app path).
Beyond that, you can check the agent state from OPCtest and Agent PG procmon utilities.
Where 5000 is Peripheral ID where the agent is created, and 15003 is the agent PeripheralNumber.
Availability Require in Chat Entry Point
In chat initializations, your clients can see the message "Thank you for your inquiry. Our service hours are 9am-5pm PST, Monday-Friday.". Such a message can appear even when there is an agent in Ready state for a chat. To identify the agent availability the system sends the API call when clients run the Entry Point URL. The API request goes through ECE Web server to ECE application server. This availability is determined by the sessions created on the application server.
In ECE 11.6 the Availability Require looks into the MRD availability and if there is any agent available in MRD, then Chat is available. The problem here comes, that if you have 2 SG in CHAT MRD, then if there are an agent available in one of the SG, your MRD becomes active and CHAT is offered. This problem is solved in ECE 12.0 and later versions. The enhancement was done by the use of the SG in the configuration. In that case, the system also counts the Skill Groups for agents who mark themselves available for the specific MRD.
There are two options for how the system defines that the agent is available. Either the agent is available for a chat or there is a Queue Depth which allows to do this. The queue depth configuration allows the number of customers which can be queued when all agents are busy.
In the API response pay attention on checkEligibility: responseType value. It indicates what is an agent availability at that time.
If it comes as 0, it means that there is either the agent is available to take the chat or the queue depth is not reached.
If it is 1, it indicates that there are no agents available.
2 means that the max queue depth has been reached.
Note: There are no options here to see how many agents are available at the specific time.
If an agent is available the other .js files are received by the web browser. As a result, a client does see the initial page with log in name and subject parameters for the Entry Point.
The API responses are available either from the client side (from the web browser Network trace) or from the ECE Application server with debug or trace level which is not recommended to keep for a long time because of the High IO that is consumed.