The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Clients can acquire configuration data from the CTI server and use configuration messages to synchronize that data between Unified CCX and themselves. This includes an initial bulk upload of configuration data and subsequent dynamic updates whenever there is a configuration change made through the RMCM subsystem in the Unified CCX Administration software on Unified CCX.
Currently, the Unified CCX CTI protocol supports the CTI client retrieval of only the following configuration data.
A CSQ controls incoming calls by determining where an incoming call is to be placed in the queue and to which agent the call is sent.
Unified CCX applications interact with contacts and perform such functions as prompting callers for information, transferring calls, providing information to callers, and so on.
An agent is the person in the contact center who handles customer calls, e-mail, and other types of correspondence between the customer and the company.
Call connection points in the computer system.
Agent team information. A team may include agents, CSQs, a primary supervisor, and a secondary supervisor.
Table 1 lists the configuration messages and Table 1 describes the messages. The rest of this chapter explains how to use them. See Message Type Definitions for detailed descriptions of the message contents.
Table 1 briefly describes the configuration messages. For complete definitions of these messages, see the referenced definition link for each message.
Configuration initialization messages
Requests configuration data from the server.
The type of update data received depends on the ConfigInfoMask used in this request.
The ConfigInfoMasks used to indicate the type of data requested are:
0 = No initial configuration information upload is wanted, but update configuration data is wanted. This is used when the client does not want the initial update messages but does want, at the time of this message, configuration update messages.
Response to the client CONFIG_REQUEST_KEY_EVENT message.
Contains the requested Unified CCX configuration keys at the time of the CONFIG_REQUEST_KEY_EVENT.
Response to the server CONFIG_KEY_EVENT message.
Tells the server if it wants the requested initial snapshot of the configuration or only updates.
Indicates the beginning of configuration data (all data of the same type of the same key) from the server.
Indicates one of the following:
Configuration team messages
Indicates the end of team configuration data or an error condition.
The following process applies to application, CSQ, agent, and device configuration. For agent team data, see Share Agent Team Configuration Data.
|Step 1||The client must include the CTI_SERVICE_CONFIG_EVENTS bit
(0x00040000) in the ServiceRequested field of an OPEN_REQ message if the client
wants configuration data. The
Unified CCX CTI server
does not provide configuration data to the client unless that bit is set. In
the OPEN_REQ message, the client must also include the configuration message
mask indicating the type of configuration data that it wants.
The client cannot send a configuration request before the server is online. The status of the server is shown in the OPEN_CONF reply to the OPEN_REQ message or in a SYSTEM_EVENT message.
|Step 2||The client sends a CONFIG_REQUEST_KEY_EVENT message to the server to request a set of current configuration keys (see CONFIG_REQUEST_KEY_EVENT).|
|Step 3||In response to the CONFIG_REQUEST_KEY_EVENT message, the server replies with a CONFIG_KEY_EVENT message containing the requested keys (see CONFIG_KEY_EVENT).|
|Step 4||Based on the keys returned in the CONFIG_KEY_EVENT message, the client decides if it needs an initial snapshot of the configuration.|
|Step 5||If the client needs an initial snapshot of the configuration, it sends the CONFIG_REQUEST_EVENT message with the requested configuration mask. Otherwise, the client sends this message with the configuration mask set to zero, indicating that the client configuration is in sync with the server configuration and that it only needs configuration updates.|
|Step 6||If in Step 5, the initial snapshot of the configuration is
requested, the server sends the initial snapshot of the configuration data to
the client in a CONFIG_BEGIN_EVENT and CONFIG_END_EVENT block of messages. In
between these two messages, the server sends the appropriate message for the
type of data requested (see
If all the data does not fit in one message, the server sends multiple messages of the same type. In this case, each data message is called a record. The whole transaction from the begin event to the end event is called a data block.
The server sends configuration data messages in the following order:
However, the order in which the client receives the data is irrelevant. The client may receive the data messages in any order depending on the timing and number of messages sent. What is important is that all the messages between a begin and end message contain consistent data. That is, for example, if a CSQ message is sent with an Agent message in the same data block, the agent referenced belongs to that CSQ.
|Step 7||Configuration updates performed in the Unified CCX Administration web page are sent to clients in a CONFIG_BEGIN_EVENT and CONFIG_END_EVENT block of messages as well.|
Figure 1 illustrates the preceding steps
During an initial configuration upload, if the server needs to break up the configuration into multiple CONFIG_BEGIN_EVENT/CONFIG_END_EVENT messages, a status 5 is listed in the CONFIG_END_EVENT message until all the data is sent. A status of 0 is included in the final CONFIG_END_EVENT message to indicate a successful data upload.
The consistency of configuration data is managed through configuration keys. Unified CCX server always increments configuration keys when a configuration update happens in the Unified CCX Administration. The set of keys are sent to clients in the CONFIG_KEY_EVENT message and the CONFIG_BEGIN_EVENT message. Clients may store these keys.
The keys are 8-byte values and are stored as long data in Unified CCX. Configuration keys apply to the configuration events determined by the mask bit CTI_SERVICE_CONFIG_EVENTS of the ServicesRequested field of the OPEN_REQ message only.
If a client has the same set of keys as the server, it indicates that the client configuration is in sync with the server’s configuration.
Agent Team configuration data is the exception and is not managed by these keys.
|Step 1||The client must include the CTI_SERVICE_SUPERVISOR bit (0x00000080) in the ServiceRequested field of an OPEN_REQ message if the client wants team configuration data. The CCX CTI server does not provide team update configuration data to the client unless that bit is set.|
|Step 2||When a client needs team configuration data, it sends a
TEAM_CONFIG_REQ message to the Unified CCX server.
If the "configparam" field in the TEAM_CONFIG_REQ message is set to 0x1, it takes the initial configuration.
|Step 3||The server responds with zero or more TEAM_CONFIG_EVENT messages,
followed by a TEAM_CONFIG_CONF message.
The TEAM_CONFIG_CONF messages mark the end of the initial configuration upload. After that, the client receives updates only for the message session.
|Step 4||After this request/confirmation exchange, the Unified CCX server sends TEAM_CONFIG_EVENT messages to the client whenever there is a team configuration change in the Unified CCX Administration web page.|
As Unified CCX and clients exchange configuration messages, Unified CCX may encounter errors. These errors are conveyed to clients through configuration messages or a generic FAILURE_CONF message and a FAILURE_EVENT message. For example, the status code in the CONFIG_KEY_EVENT message and the CONFIG_END_EVENT message may indicate an error condition in Unified CCX. Client applications are expected to check these error code and error messages. When a client detects an error condition in Unified CCX, the client needs to start over the configuration data sharing process. It is required that the client waits for at least 10 seconds before starting the process.
Although the configuration data sharing process is designed to maintain configuration consistency using the configuration key, a client developer may want to design a mechanism to overwrite the configuration key mechanism in case of unforeseen conditions in which the Unified CCX configuration and client configuration are out of sync. For example, a client developer may create a button such that whenever that button is clicked, the client starts the configuration data sharing process. In this process, the result of key comparison is ignored and CONFIG_REQUEST_EVENT message is always sent.