Feedback
Contents
- All message types organized by class and type
- All message types organized by ID number
- Session-Management messages
- Session initialization maintenance system event and termination messages
- OPEN_REQ
- OPEN_CONF
- HEARTBEAT_REQ
- HEARTBEAT_CONF
- SYSTEM_EVENT
- CLOSE_REQ
- CLOSE_CONF
- Masks used in the OPEN_REQ message
- CTI service masks
- Unsolicited call-event message masks
- Agent state masks
- Configuration-Information masks
- Failure messages
- FAILURE_CONF
- FAILURE_EVENT
- Configuration messages
- CONFIG_REQUEST_KEY_EVENT
- CONFIG_KEY_EVENT
- CONFIG_REQUEST_EVENT
- CONFIG_BEGIN_EVENT
- CONFIG_END_EVENT
- CONFIG_CSQ_EVENT
- CONFIG_APPLICATION_EVENT
- CONFIG_AGENT_EVENT
- CONFIG_DEVICE_EVENT
- TEAM_CONFIG_EVENT
- TEAM_CONFIG_REQ
- TEAM_CONFIG_CONF
- Agent-State messages
- AGENT_STATE_EVENT
- QUERY_AGENT_STATE_REQ
- QUERY_AGENT_STATE _CONF
- SET_AGENT_STATE_REQ
- SET_AGENT_STATE_CONF
- Call-Event messages
- Primary.Actual Field Format
- General Rules
- BEGIN_CALL_EVENT
- END_CALL_EVENT
- CALL_DATA_UPDATE_EVENT
- CALL_DELIVERED_EVENT
- CALL_ESTABLISHED_EVENT
- CALL_HELD_EVENT
- CALL_RETRIEVED_EVENT
- CALL_CLEARED_EVENT
- CALL_CONNECTION_CLEARED_EVENT
- CALL_ORIGINATED_EVENT
- CALL_FAILED_EVENT
- CALL_CONFERENCED_EVENT
- CALL_TRANSFERRED_EVENT
- CALL_DIVERTED_EVENT
- CALL_SERVICE_INITIATED_EVENT
- CALL_QUEUED_EVENT
- CALL_DEQUEUED_EVENT
- RTP_STARTED_EVENT (OPTIONAL)
- RTP_STOPPED_EVENT (OPTIONAL)
- Call-Control (Client-Control) messages
- CONTROL_FAILURE_CONF
- ALTERNATE_CALL_REQ
- ALTERNATE_CALL_CONF
- ANSWER_CALL_REQ
- ANSWER_CALL_CONF
- CLEAR_CALL_REQ
- CLEAR_CALL_CONF
- CLEAR_CONNECTION_REQ
- CLEAR_CONNECTION_CONF
- CONFERENCE_CALL_REQ
- CONFERENCE_CALL_CONF
- CONSULT_CALL_REQ
- CONSULT_CALL_CONF
- HOLD_CALL_REQ
- HOLD_CALL_CONF
- MAKE_CALL_REQ
- MAKE_CALL_CONF
- RECONNECT_CALL_REQ
- RECONNECT_CALL_CONF
- RETRIEVE_CALL_REQ
- RETRIEVE_CALL_CONF
- TRANSFER_CALL_REQ
- TRANSFER_CALL_CONF
- SEND_DTMF_SIGNAL_REQ
- SEND_DTMF_SIGNAL_CONF
- SET_CALL_DATA_REQ
- SET_CALL_DATA_CONF
- SUPERVISE_CALL_REQ
- SUPERVISE_CALL_CONF
- SUPERVISOR_ASSIST_REQ
- SUPERVISOR_ASSIST_CONF
- SUPERVISOR_ASSIST_EVENT
- BAD_CALL_REQ
- BAD_CALL_CONF
- Miscellaneous messages
- QUERY_QUEUE_STATISTICS_REQ
- QUERY_QUEUE_STATISTICS_CONF
- QUERY_AGENT_QUEUE_STATISTICS_REQ
- QUERY_AGENT_QUEUE_STATISTICS_CONF
- QUERY_DEVICE_INFO_REQ
- QUERY_DEVICE_INFO_CONF
- QUERY_SUMMARY_STATISTICS_REQ
- QUERY_SUMMARY_STATISTICS_CONF
- SNAPSHOT_CALL_REQ
- SNAPSHOT_CALL_CONF
- SNAPSHOT_DEVICE_REQ
- SNAPSHOT_DEVICE_CONF
- START_RECORDING_REQ
- START_RECORDING_CONF
All message types organized by class and type
Table 1 lists the message types by message class and by message type name. See the index for an alphabetical listing.
A "Solicit" message is a client message that makes a request of the server (Unified CCX). A "Solicited" message is a message Unified CCX sends to the client in response to a "solicit" message. For example: an OPEN_REQ and an OPEN_CONF message are a solicit and a solicited message respectively. An "unsolicited" message is one sent to the client that the client did not request; For example a SYSTEM_EVENT message.
- All message types organized by ID number
- Session-Management messages
- Configuration messages
- Agent-State messages
- Call-Event messages
- Call-Control (Client-Control) messages
- Miscellaneous messages
All message types organized by ID number
Table 1 lists the message types by ID number. See the index for an alphabetical listing.
Session-Management messages
- Session initialization maintenance system event and termination messages
- Masks used in the OPEN_REQ message
- Failure messages
Session initialization maintenance system event and termination messages
OPEN_REQ
The OPEN_REQ and the OPEN_CONF messages depict the session initialization message flow. Once a TCP connection has been established, a client attempts to initialize a communications session by sending to Unified CCX an OPEN_REQ message, defined in this section.
Note
The ServiceRequested mask determines if a client is in bridge mode or in agent mode. These two modes are mutually exclusive. Do not set agent-mode fields for a bridge-mode client. See Two client modes for connecting with Unified CCX, for an explanation of agent and bridge modes.
The square bracketed subscript number ending the field names for the data in the floating part of the message descriptions is the FieldDataID for that field. For example AgentID[194] means that 194 is the FieldDataID for the AgentID field.
Table 3 OPEN_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The version number of the interface requested by the client. This defines the version of all messages in the message set.
The session idle timer, expressed in seconds. If the session is idle (no messages received) for this length of time, Unified CCX resets the TCP connection and awaits the establishment of a new session. This value must be at least 2 times the heartbeat interval but less than 120 seconds.
A bitwise combination of the CTI Services listed in Table 1 that the client is to receive.
A bitwise combination of the Unsolicited Call Event Message Masks listed in Table 1 that the client is to receive.
A bitwise combination of Agent State Masks listed in Table 1 that the client is to receive.
A bitwise combination of the Configuration Event masks listed in Table 1 that the client is to receive.
Table 4 OPEN_REQ floating part message body format The password of the user identified by clientID. ClientID and ClientPassword are optionally used to authenticate the client making the session open request. This field must be present even if authentication is not being used (they can be of zero length).
The agent’s ACD IP phone extension. For Agent mode, at least one of AgentExtension, AgentID, or AgentInstrument must be provided by the client.
The agent’s IP phone number. For Agent mode, at least one of AgentExtension, AgentID, or AgentInstrument must be provided by the client.
Note Unified CCX does not use the Client ID and Client Password (they can be of zero length). Even though the fields are required, Unified CCX Computer Telephony Integration ignores them.
OPEN_CONF
The OPEN_CONF message, defined in the following tables, confirms the completion of the processing requested by the OPEN_REQ message.
Table 5 OPEN_CONF fixed part message body format A bitwise combination of the CTI Services listed in CTI service masks that the client has been granted. Services granted can be less than those requested.
The current Unified CCX on-line status when client EVENTS service has been granted.
One of the values from What is an agent state? representing the current state of the associated agent phone.
HEARTBEAT_REQ
The HEARTBEAT_REQ and the HEARTBEAT_CONF messages depict the heartbeat message flow. The following table defines the HEARTBEAT_REQ message.
HEARTBEAT_CONF
SYSTEM_EVENT
When the Unified CCX status or the agent’s device status changes, Unified CCX sends a SYSTEM_EVENT message, defined in the following table, to all clients to indicate that status (for example, on_line or off_line).
Table 9 SYSTEM_EVENT fixed part message body format The current operational status of Unified CCX. Any non-zero value is indicative of a component failure or communication outage that prevents normal CTI operations (see also Unified CCX status values).
A value that enumerates the specific system event that occurred. See SystemEventID values for system event ID values.
An argument value that is specific to the system event being reported.
A second argument value that is specific to the system event being reported.
A third argument value that is specific to the system event being reported.
Indicates the type of the device ID supplied in the EventDeviceID floating field. See DeviceType values for device ID type values. This is set to DEVID_NONE if no floating field is provided.
CLOSE_REQ
The CLOSE_REQ message, defined in the following table, requests from Unified CCX a communication session termination.
The CLOSE_REQ and CLOSE_CONF messages depict the session termination message flow.
Table 11 CLOSE_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
A status code indicating the reason for closing the session. See Table 1.
Masks used in the OPEN_REQ message
Unified CCX can provide much more real-time data than the typical client needs. Apply message masks to suppress (mask) the transmission of unneeded data and thereby avoid wasting network bandwidth.
The network impact of the expected number of simultaneously connected clients must be carefully considered before deploying a client application that unmasks a large number of messages.
Within the OPEN_REQ message, there are four separate mask types for selecting the type of messages wanted and filtering out (masking) unwanted messages:
- CTI service masks
- Unsolicited call-event message masks
- Agent state masks
- Configuration-Information masks
CTI service masks
CTI service masks specify the CTI services that the client requests.
Unsolicited call-event message masks
The Unsolicited Call-Event Message masks specify unsolicited call-event messages that the client requests.
Agent state masks
The Agent state masks specify the agent state messages that the client requests.
Configuration-Information masks
The Configuration-Information masks specify the configuration event messages that the client requests.
Failure messages
Unified CCX can indicate errors to the client using the FAILURE_CONF and FAILURE_EVENT messages.
FAILURE_CONF
Unified CCX may use the FAILURE_CONF message, defined in the following table, in response to any request message from the client. Unified CCX sends the FAILURE_CONF message in place of the positive confirmation message specific to the request.
Note
In a high availability environment, if a connection is made to a standby server, the server can reply with a FAILURE_CONF indicating error E_CTI_SERVER_NOT_MASTER.
Table 17 FAILURE_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
A status code indicating the cause of the failure. The possible status codes are defined in Table 1.
FAILURE_EVENT
Unified CCX may use the FAILURE_EVENT message, defined in the following table, to asynchronously indicate a failure or error condition to the client.
Table 19 FAILURE_EVENT fixed part message body format A status code indicating the cause of the failure. The possible status codes are defined in Table 1.
Configuration messages
- CONFIG_REQUEST_KEY_EVENT
- CONFIG_KEY_EVENT
- CONFIG_REQUEST_EVENT
- CONFIG_BEGIN_EVENT
- CONFIG_END_EVENT
- CONFIG_CSQ_EVENT
- CONFIG_APPLICATION_EVENT
- CONFIG_AGENT_EVENT
- CONFIG_DEVICE_EVENT
- TEAM_CONFIG_EVENT
- TEAM_CONFIG_REQ
- TEAM_CONFIG_CONF
CONFIG_REQUEST_KEY_EVENT
CONFIG_KEY_EVENT
The CONFIG_KEY_EVENT message is sent by Unified CCX in response to CONFIG_REQUEST_KEY_EVENT message. It contains the Unified CCX keys at the time of the request. Although the data type for the keys is UNSPEC, the keys should be interpreted as 8-byte integer.
Returning any key of all binary 0’s tells the client that the specified configuration needs to be uploaded.
Table 23 CONFIG_KEY_EVENT fixed part message body format Status value of operation. See Table 3.
CONFIG_REQUEST_EVENT
The CONFIG_REQUEST_EVENT message may be sent by the client after it receives the CONFIG_KEY_EVENT message.
Unified CCX responds by sending a CONFIG_BEGIN_EVENT, CONFIG_xxx records (where xxx refers to the type of configuration records such as CSQ, Application, Agent, or Device), and then a CONFIG_END block containing all the records for that configuration item. After the client gets this new configuration data, the client should clear the existing configuration and use the new configuration set.
CONFIG_BEGIN_EVENT
The CONFIG_BEGIN_EVENT signifies the beginning of configuration data from Unified CCX.
Table 28 CONFIG_BEGIN_EVENT fixed part message body format 2: Update
Bit Mask indicating the type of information included:
2: CSQ Information
4: Agent Information
8: Device Information
Table 29 CONFIG_BEGIN_EVENT floating part message body format The Unified CCX configuration key of the customer (or all customers) for applications (if any).
The Unified CCX configuration key of the customer (or all customers) for CSQs (if any).
The Unified CCX configuration key of the customer (or all customers) for agents (if any).
The Unified CCX configuration key of the customer (or all customers) for device information (if any).
CONFIG_END_EVENT
The CONFIG_END_EVENT message is sent by Unified CCX to indicate the end of a successful configuration upload or an error condition. It most likely will follow configuration records preceded by a CONFIG_BEGIN_EVENT message or it can be a response to a CONFIG_REQUEST_EVENT message indicating either an error or that there is no configuration for the items requested.
Table 30 CONFIG_END_EVENT fixed part message body format Indicates the status of the configuration block. See Table 3 for status values and descriptions.
CONFIG_CSQ_EVENT
The CONFIG_CSQ_EVENT message is sent to indicate a CSQ configuration update.
Table 33 CONFIG_CSQ_EVENT fixed part message body format The number of records included in the floating part of this message.
Table 34 CONFIG_CSQ_EVENT floating part message body format 1: Change
2: Delete
The Contact Service Queue ID. This ID is used to identify a CSQ internally in Unified CCX.
TRUE if the agent goes into work mode after handling a call from this CSQ. FALSE if not present.
MR Domain ID[216] (Version 11)
(see Table note 1)
1= Email (see Table note 2).
CONFIG_APPLICATION_EVENT
The CONFIG_APPLICATION_EVENT message is sent by Unified CCX to provide information about an Application.
Table 35 CONFIG_APPLICATION_EVENT fixed part message body format The number of records contained in the floating part of this message.
The maximum number of records that can be put in the message is 10.
CONFIG_AGENT_EVENT
The CONFIG_AGENT_EVENT message is sent by Unified CCX to provide information about an agent.
Note
The LoginID field is considered unique for all records. Two records sent with matching LoginID’s are considered to be the same record.
Table 37 CONFIG_AGENT_EVENT fixed part message body format The number of records contained in the floating portion of this message.
The maximum number of records that can be put in the message is 10.
Table 38 CONFIG_AGENT_EVENT floating part message body format 1: Change
2: Delete
2: Supervisor
The Number of the CSQ to which this agent belongs.
A pair consists of the next two fields with a maximum of 30. For example: If the Number of CSQs for the agent is 2, then four fields follow this one (CSQID1 and Reserved and CSQID2 and Reserved).
CONFIG_DEVICE_EVENT
The CONFIG_DEVICE_EVENT message is sent by Unified CCX to provide information about a device’s configuration. Unified CCX sends CONFIG_DEVICE_EVENT messages for all route points, agents, and CTI ports.
Table 39 CONFIG_DEVICE_EVENT fixed part message body format The Number of records included in the floating part of this message.
Table 3 specifies the floating data fields in the CONFIG_DEVICE_EVENT message according to the device type. For example:
TEAM_CONFIG_EVENT
The TEAM_CONFIG_EVENT message informs the clients of Unified CCX that there is a change to the agent team configuration. A team may include agents, one primary supervisor, secondary supervisors, and CSQs.
Table 42 TEAM_CONFIG_EVENT fixed part message body format The number of AgentID, AgentFlag, Recordtype, and MemberType fields present in the floating part of the message, up to a maximum of 64.
The type of agent team configuration change to perform. One of the following values:
2: Remove Team (No optional floating part is present. The client is responsible for removing all team related data for this team).
3: Change Team (includes TeamName change, addition/deletion of team members, addition/deletion of primary supervisors, addition/deletion of secondary supervisors)
Table 43 TEAM_CONFIG_EVENT floating part message body format The assigned team name. This field must be the first floating field.
The AgentID of an agent or supervisor if the MemberType is agent/supervisor member or the CSQID of a member of the team if the MemberType is CSQ member.
A set of flags indicating the attributes of the preceding AgentID. Possible values are:
0x0002: Temporary Agent
0x0004: Supervisor
(0 flag is for regular agent)
The type of agent change. It can have following values:
2: Delete
2: CSQ member
TEAM_CONFIG_REQ
The TEAM_CONFIG_REQ message requests team configuration data from Unified CCX. If initial configuration is requested, the initial configuration is sent followed by the TEAM_CONFIG_CONF message.
Table 44 TEAM_CONFIG_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
This parameter indicates if the client wants initial bulk upload and/or a team configuration update. The values are:
0x1: initial configuration requested.
0x2: updates only.
TEAM_CONFIG_CONF
The TEAM_CONFIG_CONF message is an acknowledgement from Unified CCX to the client that it received the request for team configuration data. This message also indicates to clients that they should expect to receive team configuration updates.
Agent-State messages
- AGENT_STATE_EVENT
- QUERY_AGENT_STATE_REQ
- QUERY_AGENT_STATE _CONF
- SET_AGENT_STATE_REQ
- SET_AGENT_STATE_CONF
AGENT_STATE_EVENT
An agent-state change (such as logging on, becoming available to handle incoming calls, and so on) sends to the client an AGENT_STATE_EVENT message, defined in the following tables.
Table 47 AGENT_STATE_EVENT fixed part message body format One of the values representing the current state of the agent (see Table 1).
If only one event is sent for the agent (Not one for each CSQ to which the agent belongs) this is set to 0.
The number of seconds since the agent entered this state (typically 0).
The Customer Service Queue ID affected by the state change, as known by CCX.
The value representing the current state of the associated agent (see Table 1).
A Unified CCX code indicating the reason for the state change. (see Table 1)
If information for more than one CSQ is passed, this must be non-zero and indicates the number of records (CSQID, and CSQState, Reserved[63], and Reserved[64] fields) present in the floating part of the message.
There can be up to 99 records.
If more than 99 are required, then another AGENT_STATE_EVENT message must be sent.
If there are 0 records in the floating part of the message, then a single record (of CSQID and CSQState) is specified in the fixed part of the message.
Table 48 AGENT_STATE_EVENT floating part message body format The signature of the client that is associated with this agent.
If present specifies in seconds the anticipated time in the state specified. This is useful for work states to estimate the time before going ready or not ready.
The ID of the CSQ affected by the state change. If a particular CSQ is specified, the state in all other CSQs is implicitly made BUSY_OTHER.
One of the values from Table 1 representing the current state of the associated agent with respect to the CSQ. There can be more than one CSQ field in the message (see numCSQs above).
QUERY_AGENT_STATE_REQ
The QUERY_AGENT_STATE_REQ message, defined in the following tables, allows a client to retrieve the current state of an agent at a specified device.
Table 49 QUERY_AGENT_STATE_REQ field name message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
QUERY_AGENT_STATE _CONF
The QUERY_AGENT_STATE _CONF message, defined in the following tables, is confirmation of the receipt of the QUERY_AGENT_STATE_REQ message.
Table 51 QUERY_AGENT_STATE _CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
One of the values from representing the current state of the associated agent (see Table 1).
The count of CSQID, reserved[63], reserved[64], and CSQState as a group in the floating part. The maximum count allowed is 20.
Table 52 QUERY_AGENT_STATE _CONF floatingfield name message body format The agent’s Unified CCX IP phone number, if the agent is logged on.
The ID of the CSQ affected by the state change.
If a particular CSQ is specified, the state in all other CSQs is implicitly made BUSY_OTHER.
One of the values from Table 1 representing the current state of the associated agent with respect to the CSQ identified by CSQID.
InternalAgentState
One of the values from Table 2 representing the agent internal states. All the transitional states the agent goes through are part of agent internal states values.
USHORT
2
SET_AGENT_STATE_REQ
The SET_AGENT_STATE_REQ message, defined in the following tables, allows a client to change an ACD agent’s state.
Table 53 SET_AGENT_STATE_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
One of the values from representing the desired state of the associated agent (see Table 1).
A Unified CCX code indicating the reason for the agent state change (see Table 1).
Unified CCX is requested to force this state change regardless of its validity.
Used only with AGENT_STATE_LOGIN or AGENT_STATE_LOGOFF:
2: Agent authentication only. No agent state change. Use with AGENT_STATE_LOGIN (Version 12)
0x1: Outbound feature enabled
Call-Event messages
Call-Event messages are unsolicited messages sent to clients when Unified CCX reports that a call-event has occurred. There are no request or confirmation messages associated with these unsolicited event messages. Every call can be announced to the client with an unsolicited BEGIN_CALL_EVENT message, informing the client that it has just been associated with a new call and providing the initial call context data.
Additional call events are then sent to the client as the call is handled, depending upon the type of ACD involved and the treatment that the call receives. Finally, an END_CALL_EVENT message is sent to the client when its association with a call is dissolved.
This section includes the following message definitions:
- BEGIN_CALL_EVENT
- END_CALL_EVENT
- CALL_DATA_UPDATE_EVENT
- CALL_DELIVERED_EVENT
- CALL_ESTABLISHED_EVENT
- CALL_HELD_EVENT
- CALL_RETRIEVED_EVENT
- CALL_CLEARED_EVENT
- CALL_CONNECTION_CLEARED_EVENT
- CALL_ORIGINATED_EVENT
- CALL_FAILED_EVENT
- CALL_CONFERENCED_EVENT
- CALL_TRANSFERRED_EVENT
- CALL_DIVERTED_EVENT
- CALL_SERVICE_INITIATED_EVENT
- CALL_QUEUED_EVENT
- CALL_DEQUEUED_EVENT1
- RTP_STARTED_EVENT (OPTIONAL)
- RTP_STOPPED_EVENT (OPTIONAL)
- Primary.Actual Field Format
- BEGIN_CALL_EVENT
- END_CALL_EVENT
- CALL_DATA_UPDATE_EVENT
- CALL_DELIVERED_EVENT
- CALL_ESTABLISHED_EVENT
- CALL_HELD_EVENT
- CALL_RETRIEVED_EVENT
- CALL_CLEARED_EVENT
- CALL_CONNECTION_CLEARED_EVENT
- CALL_ORIGINATED_EVENT
- CALL_FAILED_EVENT
- CALL_CONFERENCED_EVENT
- CALL_TRANSFERRED_EVENT
- CALL_DIVERTED_EVENT
- CALL_SERVICE_INITIATED_EVENT
- CALL_QUEUED_EVENT
- CALL_DEQUEUED_EVENT
- RTP_STARTED_EVENT (OPTIONAL)
- RTP_STOPPED_EVENT (OPTIONAL)
Primary.Actual Field Format
From Cisco Unified CCX 8.0(1) release onwards, Join Across Line (JAL) feature is supported. If an agent uses this feature while handling calls between an IPCC extension and non-ACD extension (non-IPCC extension), and the call on his non-ACD extension survives, then Unified CCX will treat this as a business call, which moved to secondary extension of the agent.
In this scenario, if a CTI client like CAD uses the Unified CCX CTI protocol version 14 for fetching call events, it will receive the call events in the new Primary.Actual field format. In this format, all connection device and subject device id fields in many of the Unified CCX CTI call events sent to the client will be changed to include the primary ICD extension concatenated with a "dot" and the actual extension used (for example, 1000.1001).
General Rules
The general rules for the Primary.Actual field format in the Unified CCX CTI Protocol Version 14 are mentioned below:
- This format applies only to non-ICD secondary lines for logged on agents.
- This format is backward compatible with Unified CCX CTI clients that use versions prior to 14. For backward compatibility, Unified CCX removes the primary ID field and returns only the actual extension ID.
- All instances of ConnectionDeviceID, subject DeviceID, ANI, DNIS, and DialedNumbers fields are affected. These fields exist in many _CONF and _EVENT messages. Clients can also provide the new format to _REQ messages (not required). Unified CCX will ignore the primary part and utilize only the actual extension to be used in the third party call control methods.
- The device type shall also change to reflect the field type. A new field DEVID_NON_ACD_DEVICE is introduced to label "Primary.Actual" fields.
- Since the device ID is able to hold two IDs, the maximum length of the ID is essentially cut in half. With this new format, the maximum length for the device ID fields is cut from 64 bytes to 31 bytes (1 byte for the dot) assuming that both the primary and the actual IDs are of the same length.
BEGIN_CALL_EVENT
The first association between a call and a client (a route point, a CTI port, or an agent phone to which the agent has logged in) generates a BEGIN_CALL_EVENT message to the client, providing the call ID and the initial call context data. This message is optional.
The CallID identifies the call, and the ConnectionDeviceType and ConnectionDeviceID uniquely identify the client’s local call connection, if any, or another valid call connection.
This message always precedes any other event messages for that call. Subsequent changes to the call context data (if any) result in CALL_DATA_UPDATE_EVENT messages containing the changed call data being sent to the client.
Note
There can be multiple calls with the same CallID value.
The following tables define the format of the BEGIN_CALL_EVENT message.
Table 56 BEGIN_CALL_EVENT fixed part message body format The number of clients previously associated with this call. This value also indicates the number of client signatures and timestamps that are present in the floating part of the message.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
The general classification of the call type. See CallType values.
The type of device ID supplied in the ConnectionDeviceID floating field. See Table 1
Indicates the disposition of the called party. See Disposition values.
Table 57 BEGIN_CALL_EVENT floating part message body format The ID of the connection between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
ANI (Automatic Number Identification). The telephone number of the person making the call. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The DNIS (Dialed Number Identification Service) provided with the call; that is, the number associated with a call on a switch. This can be different, though often it is not, from the number the caller dialed. This is different if the call is transferred. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The telephone number dialed. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The digits entered by the caller in response to IVR prompting.
CallVariable2[14]. (optional)throughCallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
END_CALL_EVENT
An END_CALL_EVENT message is generated when the association between a call and the client is dissolved and no further call-event messages for the call are sent to this client. This message does not necessarily indicate that the subject call has been terminated.
The following tables define the format of the END_CALL_EVENT message.
Table 58 END_CALL_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Table 59 END_CALL_EVENT floating part message body format The ID of the connection between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_DATA_UPDATE_EVENT
Changes to the call context data generate a CALL_DATA_UPDATE_EVENT to the client that contains
only the items that have changed. This message is optional. The initial call context is provided in the BEGIN_CALL_EVENT message.
Note
This event MUST be sent if Unified CCX changes the call ID with no other notifying events such as CALL_CONFERENCED_EVENT or CALL_TRANSFERRED_EVENT. One circumstance in Unified CCX where this can happen is when a non-ACD call is transferred through a route point into the ACD system. In the 1-2-1 transfer model, when the call is transferred, call 1 is the resultant call but is unknown to monitoring systems.
The CALL_DATA_UPDATE_EVENT message is defined in the following tables.
Table 60 CALL_DATA_UPDATE_EVENT fixed part message body format The number of clients associated with this call. This value also indicates the number of client signatures and timestamps that are present in the floating part of the message.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
The general classification of the call type. See CallType values.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
The type of device ID supplied in the NewConnectionDeviceID floating field. See ConnectionDeviceType values.
The disposition of the called party. See Disposition values.
Table 61 CALL_DATA_UPDATE_EVENT floating part message body format The previous ID of the call connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The new ID of the call connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
ANI (automatic Number Identification). The telephone number of the person making the call. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The digits entered by the caller in response to the IVR prompting.
CallVariable2[14]. (optional)throughCallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
CALL_DELIVERED_EVENT
The arrival of a call at any device on Unified CCX generates a CALL_DELIVERED_EVENT message to the client. This event generally indicates the called device is ringing. This is defined in the following tables.
The LocalConnectionState field can be used to distinguish between those cases of the call arriving at the switch and those cases of the call arriving at an agent IP phone.
Table 62 CALL_DELIVERED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the device ID type supplied in the AlertingDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CallingDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CalledDeviceID floating field. See DeviceType values.
Indicates the type of the device ID supplied in the LastRedirectDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
Table 63 CALL_DELIVERED_EVENT floating part message body format The ID of the connection between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device that is alerting. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the calling device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the originally called device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the previously alerted device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The ID of the consultation Call that Unified CCX placed from the CTI port to the agent IP phone.
ANI (Automatic Number Identification). The telephone number of the person making the call. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The DNIS (Dialed Number Identification Service) provided with the call; that is, the number associated with a call on a switch. This can be different, though often it is not, from the number the caller dialed. This is different if the call is transferred. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The telephone number dialed. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The digits entered by the caller in response to the IVR prompting.
CallVariable2[14]. (optional) through CallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
CALL_ESTABLISHED_EVENT
The answering of a call on an IP phone on Unified CCX creates a new call connection and generates a CALL_ESTABLISHED_EVENT message to the client. This is defined in the following tables.
The CallID identifies the call, and the ConnectionDeviceType and ConnectionDeviceID uniquely identify the new call connection that was created. When more than one call with the same CallID value exists, the connection being created by this CALL_ESTABLISHED_EVENT shall apply to the call that does not yet have a destination connection established.
Table 64 CALL_ESTABLISHED_EVENT fixedfield name message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the type of the device ID supplied in the AnsweringDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CallingDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CalledDeviceID floating field. See DeviceType values.
Indicates the type of the device ID supplied in the LastRedirectDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 65 CALL_ESTABLISHED_EVENT floating part message body format The ID of the connection between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device that answered the call. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the calling device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the originally called device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the previously alerted device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_HELD_EVENT
Placing a call on hold sends to the client a CALL_HELD_EVENT message, defined in the following tables.
Table 66 CALL_HELD_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the device ID type supplied in the HoldingDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 67 CALL_HELD_EVENT floating part message body format The ID of the connection between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device that activated the hold. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_RETRIEVED_EVENT
Resuming a call previously placed on hold sends to the client a CALL_RETRIEVED_EVENT message, defined in the following tables.
Table 68 CALL_RETRIEVED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the type of the device ID supplied in the RetrievingDeviceID floating field.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 69 CALL_RETRIEVED_EVENT floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device that de-activated hold. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_CLEARED_EVENT
A CALL_CLEARED_EVENT message, defined in the following tables, is sent to the client when a call is terminated, normally when the last device disconnects from a call.
Table 70 CALL_CLEARED_EVENT fixed part message body format The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
CALL_CONNECTION_CLEARED_EVENT
When a party drops from a conference call, a CALL_CONNECTION_CLEARED_EVENT message, defined in the following tables, can be sent to the client.
Table 72 CALL_CONNECTION_CLEARED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the device ID type supplied in the ReleasingDeviceID floating field.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 73 CALL_CONNECTION_CLEARED_EVENT floating part message body format The ID of the cleared connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device that cleared the connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_ORIGINATED_EVENT
The initiation of a call at any monitored device sends to the client a CALL_ORIGINATED_EVENT, defined in the following tables.
Table 74 CALL_ORIGINATED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the device ID type supplied in the CallingDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CalledDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 75 CALL_ORIGINATED_EVENT floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the calling device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the called device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_FAILED_EVENT
A CALL_FAILED_EVENT message, defined in the following tables, can be sent to the client when a call cannot be completed.
Table 76 CALL_FAILED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the type of the device ID supplied in the FailingDeviceID floating field. See DeviceType values.
Indicates the type of the device ID supplied in the CalledDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 77 CALL_FAILED_EVENT floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the failing device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the called device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_CONFERENCED_EVENT
The joining of calls into a conference call causes a CALL_CONFERENCED_EVENT message, defined in the following tables, to be sent to the client. Unified CCX MUST ensure that the CALL_CONFERENCED_EVENT is sent after any DELIVERED events for the secondary call, even in the case of a blind conference call.
Table 78 CALL_CONFERENCED_EVENT fixed part message body format Indicates the connection type supplied in the PrimaryDeviceID floating field.
The Call ID value that Unified CCX assigned to the primary call.
The number of active connections associated with this conference call, up to a maximum of 16. This value also indicates the number of ConnectedPartyCallID, ConnectedPartyDeviceType, and ConnectedPartyDeviceID floating fields present in the floating part of the message.
Indicates the connection type of the ID supplied in the SecondaryDeviceID floating field. See ConnectionDeviceType values.
The Call ID value that Unified CCX assigns to the secondary call.
Indicates the device ID type supplied in the ControllerDeviceID floating field. See DeviceType values.
Indicates device ID type supplied in the AddedPartyDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 79 CALL_CONFERENCED_EVENT floating part message body format The device ID of the primary call connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the secondary call connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the conference controller device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device added to the call. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The Call ID value assigned to one of the conference call parties. There can be more than one ConnectedPartyCallID field in the message (see the preceding TypeParties field description).
The device ID type supplied in the following ConnectedPartyDeviceID floating field. See ConnectionDeviceType values.
There can be more than one ConnectedPartyDeviceType field in the message (see the preceding TypeParties field description). This field always immediately follows the corresponding ConnectedPartyCallID field.
The device ID of one of the conference call parties. See DeviceType values.
There can be more than one ConnectedPartyDeviceID field in the message (see the preceding TypeParties field description). This field always immediately follows the corresponding ConnectedPartyDeviceType field. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_TRANSFERRED_EVENT
The transfer of a call to another destination causes a CALL_TRANSFERRED_EVENT message, defined in the following tables, to be sent to the client.
A CALL_TRANSFERRED_EVENT must always be sent AFTER any corresponding CALL_DELIVERED_EVENT for the secondary call.
Table 80 CALL_TRANSFERRED_EVENT fixed part message body format Indicates the connection type supplied in the PrimaryDeviceID floating field. See ConnectionDeviceType values.
The Call ID value that Unified CCX assigned to the primary call.
The number of active connections associated with this conference call, up to a maximum of 16.
This value also indicates the number of the ConnectedPartyCallID, the ConnectedPartyDeviceType, and the ConnectedPartyDeviceID floating fields present in the floating part of the message.
Indicates the connection type supplied in the SecondaryDeviceID floating field. See ConnectionDeviceType values.
The Call ID value that Unified CCX assigned to the secondary call.
Indicates the device ID type supplied in the TransferringDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the TransferredDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 81 CALL_TRANSFERRED_EVENT floating part message body format The device ID of the primary call connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the secondary call connection. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device that transferred the call. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device to which the call was transferred. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The Call ID value assigned to one of the call parties. There can be more than one ConnectedPartyCallID field in the message (see the preceding NumParties field description).
Indicates the type of the device ID supplied in the following ConnectedPartyDeviceID floating field. There can be more than one ConnectedPartyDeviceType field in the message (see the preceding TypeParties field description). This field always immediately follows the corresponding ConnectedPartyCallID field.
The device ID of one of the call parties. There can be more than one ConnectedPartyDeviceID field in the message (see the preceding NumParties field description). This field always immediately follows the corresponding ConnectedPartyDeviceType field. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_DIVERTED_EVENT
The moving of a call from one device or target to another can cause a CALL_DIVERTED_EVENT message, defined in the following tables, to be sent to the client. Examples of this are a call ringing at one agent and getting diverted to another. Another example is a call getting diverted out of queue to an agent.
Table 82 CALL_DIVERTED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
The type of the device ID supplied in the DivertingDeviceID floating field. See DeviceType values.
The type of the device ID supplied in the CalledDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
A reason or explanation for the occurrence of the event. See Call EventCause (CEC) values.
Table 83 CALL_DIVERTED_EVENT floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device from which the call was diverted. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the device to which the call was diverted. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_SERVICE_INITIATED_EVENT
The initiation of telecommunications service ("dial tone") at a device causes a CALL_SERVICE_INITIATED_EVENT message, defined in the following tables, to be sent to the client.
Table 84 CALL_SERVICE_INITIATED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the device ID type supplied in the CallingDeviceID floating field. See DeviceType values.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 85 CALL_SERVICE_INITIATED_EVENT floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the calling device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_QUEUED_EVENT
The placing of a call in a queue pending the availability of some resource causes a CALL_QUEUED_EVENT message, defined in the following tables, to be sent to the client.
Clients with Client Events Service can receive this message when an outbound call is queued waiting for a resource. Clients with All Events Service can also receive this message when inbound calls are queued.
Table 86 CALL_QUEUED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the device ID type supplied in the Queue DeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CallingDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the CalledDeviceID floating field. See DeviceType values.
Indicates the device ID type supplied in the LastRedirect DeviceID floating field. See DeviceType values.
The number of CSQs to which the call has queued, up to a maximum of 20.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
Table 87 CALL_QUEUED_EVENT floating part message body format The device ID between the call and the device. This is the CTI Port that the call is on. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The ID of the queuing device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The calling line ID (if any). In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The DN of the Route point that was called. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The device ID of the redirecting device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
CALL_DEQUEUED_EVENT
The explicit removal of a call from a queue causes a CALL_DEQUEUED_EVENT message, defined in the following tables, to be sent to the client.
Note that this event is not reported when calls leave a queue "normally" (that is, due to resource availability, call termination, and so on). In those cases, a DIVERTED event is expected. It is not currently anticipated that Unified CCX will need to send this event. One possible exception would be if a call is queued to multiple queues and then a script or some mechanism on Unified CCX dequeues the call from less than all the queues.
Table 88 CALL_DEQUEUED_EVENT fixed part message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Indicates the type of device supplied in the QueueDeviceID floating field.
The number of calls remaining in the queue for this service.
The number of CSQs that the call has been removed from, up to a maximum of 20. A zero value indicates that the call has been implicitly removed from all queues.
The local end state of the connection. For more information, see LocalConnectionState (LCS) values.
Indicates a reason or explanation for the event occurrence. See Call EventCause (CEC) values.
RTP_STARTED_EVENT (OPTIONAL)
The RTP_STARTED_EVENT message indicates that an RTP (Real Time Protocol) media stream has been started. There are two media streams for audio media (one for the caller and one for the receiver). So there are two RTP Started events, one indicating the input has started (that is, the phone is listening) and the other that the output has started (that is, the outgoing media from the agent phone has begun).
The RTP Started event generally comes up at the same time as the established event. It also occurs when a call is retrieved from being on hold, and when the transfer or conference operations are completed.
There is no guarantee of the order of the RTP started events in relationship to the established and retrieved events. The RTP started events can occur before or after the established event.
Tthe following tables define the format of the RTP_STARTED_EVENT message.
Table 90 RTP_STARTED_EVENT (OPTIONAL) fixed part message body format The audio codec type. See Audio Codec Type values.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Table 91 RTP_STARTED_EVENT (OPTIONAL) floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The IP Address to which the client is sending the RTP stream.
The UDP (User Datagram Protocol) port number to which the client is sending the RTP Stream.
RTP_STOPPED_EVENT (OPTIONAL)
The RTP_STOPPED_EVENT message indicates that an RTP media has been stopped. There are two media streams for audio media so there are two RTP Stopped events, one indicating the input has stopped (that is, the phone is not listening) and the other that the output has stopped (that is, the outgoing media from the agent phone has stopped).
The RTP Stopped Event is received when the call is placed on hold and when the call disconnects.
The following tables define the format of the RTP_STOPPED_EVENT message.
Table 92 RTP_STOPPED_EVENT (OPTIONAL) fixed part message body format The TCP/IP port number of the client connection that was closed.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
Table 93 RTP_STOPPED_EVENT (OPTIONAL) floating part message body format The device ID between the call and the device. In CTI Protocol Version 14, the general rules for the Primary.Actual Field Format will apply to this field.
The IP Address to which the client was sending the RTP stream.
The UDP (User Datagram Protocol) port number to which the client was sending the RTP Stream.
Call-Control (Client-Control) messages
The call-control messages are from client applications requesting changes to agent states or establishing, answering, controlling, or terminating calls on behalf of a specified agent phone number, or manipulating the telephone features associated with an agent’s IP phone.
These messages evoke a message response from Unified CCX. Consequently the messages are paired request/response messages. A request message for the desired control action is sent, and the outcome of the request is indicated by the type of response message that is received. Depending on the specifics of the request, as much as 10 or 15 seconds might elapse before the response message is returned. A successfully executed request is indicated by the corresponding control-action confirmation message, while an unsuccessful request is indicated by a CONTROL_FAILURE_CONF message.
This section includes the following message definitions:
- CONTROL_FAILURE_CONF
- ALTERNATE_CALL_REQ
- ALTERNATE_CALL_CONF
- ANSWER_CALL_REQ
- ANSWER_CALL_CONF
- CLEAR_CALL_REQ
- CLEAR_CALL_CONF
- CLEAR_CONNECTION_REQ
- CLEAR_CONNECTION_CONF
- CONFERENCE_CALL_REQ
- CONFERENCE_CALL_CONF
- CONSULT_CALL_REQ
- CONSULT_CALL_CONF
- HOLD_CALL_REQ
- HOLD_CALL_CONF
- MAKE_CALL_REQ
- MAKE_CALL_CONF
- RECONNECT_CALL_REQ
- RECONNECT_CALL_CONF
- RETRIEVE_CALL_REQ
- RETRIEVE_CALL_CONF
- TRANSFER_CALL_REQ
- TRANSFER_CALL_CONF
- SEND_DTMF_SIGNAL_REQ
- SEND_DTMF_SIGNAL_CONF
- SET_CALL_DATA_REQ
- SET_CALL_DATA_CONF
- SUPERVISE_CALL_REQ
- SUPERVISE_CALL_CONF
- SUPERVISOR_ASSIST_REQ
- SUPERVISOR_ASSIST_CONF
- SUPERVISOR_ASSIST_EVENT
- BAD_CALL_REQ
- BAD_CALL_CONF
- CONTROL_FAILURE_CONF
- ALTERNATE_CALL_REQ
- ALTERNATE_CALL_CONF
- ANSWER_CALL_REQ
- ANSWER_CALL_CONF
- CLEAR_CALL_REQ
- CLEAR_CALL_CONF
- CLEAR_CONNECTION_REQ
- CLEAR_CONNECTION_CONF
- CONFERENCE_CALL_REQ
- CONFERENCE_CALL_CONF
- CONSULT_CALL_REQ
- CONSULT_CALL_CONF
- HOLD_CALL_REQ
- HOLD_CALL_CONF
- MAKE_CALL_REQ
- MAKE_CALL_CONF
- RECONNECT_CALL_REQ
- RECONNECT_CALL_CONF
- RETRIEVE_CALL_REQ
- RETRIEVE_CALL_CONF
- TRANSFER_CALL_REQ
- TRANSFER_CALL_CONF
- SEND_DTMF_SIGNAL_REQ
- SEND_DTMF_SIGNAL_CONF
- SET_CALL_DATA_REQ
- SET_CALL_DATA_CONF
- SUPERVISE_CALL_REQ
- SUPERVISE_CALL_CONF
- SUPERVISOR_ASSIST_REQ
- SUPERVISOR_ASSIST_CONF
- SUPERVISOR_ASSIST_EVENT
- BAD_CALL_REQ
- BAD_CALL_CONF
CONTROL_FAILURE_CONF
The CONTROL_FAILURE_CONF message, defined in the following tables, confirms that the previously requested control-service function identified by the given invokeID was unsuccessful. This message is sent in place of the corresponding confirmation message for the requested control-service function.
Table 94 CONTROL_FAILURE_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
One of the values specifying the reason that the request failed. See Control Failure (CF) values.
Unified CCX detailed error data, if available. Otherwise, 0. See Unified CCX ErrorCode values.
ALTERNATE_CALL_REQ
The ALTERNATE_CALL_REQ message, defined in the following tables, requests the double action of placing an active call on hold and then either retrieving a previously held call or answering an alerting call at the same device.
Note
When specifying an alerting call, since there is no formal connection between a call and an alerting device, the ConnectionDeviceID of the calling connection is used here (as given in the CALL_DELIVERED_EVENT message).
Table 96 ALTERNATE_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value assigned to the currently active call by Unified CCX.
The Call ID value assigned to the other call by Unified CCX.
The device ID type supplied in the ActiveConnectionDeviceID floating field. See ConnectionDeviceType values.
The device ID type supplied in the OtherConnectionDeviceID floating field. See ConnectionDeviceType values.
ALTERNATE_CALL_CONF
ANSWER_CALL_REQ
The ANSWER_CALL_REQ message, defined in the following tables, allows a client to connect an alerting call at the device which is alerting.
Note
Since there is no formal connection between a call and an alerting device, the ConnectionDeviceID of the calling connection is used here (as given in the CALL_DELIVERED_EVENT message).
Table 99 ANSWER_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value assigned to the call by Unified CCX. Can contain the special value 0xffffffff when alerting callID is not provided.
The device ID type supplied in the ConnectionDeviceID floating field. Set this field to CONNECTION_ID_NONE when the alerting callID is not provided. See ConnectionDeviceType values.
ANSWER_CALL_CONF
CLEAR_CALL_REQ
The CLEAR_CALL_REQ message, defined in the following tables, allows a client to release all devices from the specified call without regard to the number of other call parties.
Note
Most applications use the CLEAR_CONNECTION_REQ message to avoid inadvertent clearing of all conference parties when dropping from a conference call.
Table 102 CLEAR_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
CLEAR_CALL_CONF
CLEAR_CONNECTION_REQ
The CLEAR_CONNECTION_REQ message, defined in the following tables, allows a client to release a specific device connection from a designated call.
If only one party remains connected to the call following this request, the remaining connection is cleared and the call is terminated.
Table 105 CLEAR_CONNECTION_REQ fixed part message body format An ID for this request message that is returned in the corresponding confirm message.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
CLEAR_CONNECTION_CONF
CONFERENCE_CALL_REQ
The CONFERENCE_CALL_REQ message, defined in the following tables, allows a client to conference an existing held call with another active call.
The two calls are merged and the two connections at the conferencing device are in the connected state.
Table 108 CONFERENCE_CALL_REQ fixed part message body format An ID for this request message that is returned in the corresponding confirm message.
The Call ID value assigned to the active call by Unified CCX.
The type device ID supplied in the HeldConnectionDeviceID floating field. See ConnectionDeviceType values.
The type device ID supplied in the ActiveConnectionDeviceID floating field. See ConnectionDeviceType values.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
Table 109 CONFERENCE_CALL_REQ floating part message body format The ID of the held call connection. Either a HeldConnectionDeviceID or DialedNumber is required.
The number to be dialed. Either a HeldConnectionDeviceID or DialedNumber is required.
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
CONFERENCE_CALL_CONF
The CONFERENCE_CALL_CONF message, defined in the following tables, confirms successful completion of the Conference Call request.
Table 110 CONFERENCE_CALL_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The Call ID value assigned to the resulting conference call by Unified CCX.
The connection type of the device supplied in the NewConnectionDeviceID floating field. See ConnectionDeviceType values.
The number of active connections associated with this conference call, up to a maximum of 16. This value also indicates the number of ConnectedPartyCallID, ConnectedPartyDeviceType and ConnectedPartyDeviceID floating fields present in the floating part of the message.
Table 111 CONFERENCE_CALL_CONF floating part message body format The Call ID value assigned to one of the conference call parties. There can be more than one ConnectedPartyCallID field in the message (see NumParties, above).
The device ID type of the device supplied in the following ConnectedPartyDeviceID floating field. There can be more than one ConnectedPartyDeviceType field in the message (see NumParties, above).
The device ID of one of the conference call parties. There can be more than one ConnectedPartyDeviceID field in the message (see NumParties, above).
CONSULT_CALL_REQ
The CONSULT_CALL_REQ message, defined in the following tables, requests the combined action of placing an active call on hold and then making a new call.
By default, the call context data of the active call is used to initialize the context data of the consultation call. A client can override some or all of this original call context in the consultation call by providing the desired values in this request.
Table 112 CONSULT_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value assigned to the active call by Unified CCX.
The connection type of the device supplied in the ActiveConnectionDeviceID floating field. See ConnectionDeviceType values.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
Table 113 CONSULT_CALL_REQ floating part message body format The phone number of the agent’s IP phone that initiates the new call.
Call-related variable data used in place of the corresponding variable from the active call.
CallVariable2[14].(optional) through CallVariable9[21] (optional)
Call-related variable data that used in place of the corresponding variable from the active call.
Call-related wrapup data used in place of the corresponding data from the active call.
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
CONSULT_CALL_CONF
The CONSULT_CALL_CONF message, defined in the following tables, confirms successful completion of the Consult Call request:
Table 114 CONSULT_CALL_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The Call ID value assigned to the resulting new call by Unified CCX.
The type of device ID supplied in the NewConnectionDeviceID floating field. See ConnectionDeviceType values.
HOLD_CALL_REQ
The HOLD_CALL_REQ message, defined in the following tables, allows a client to place an existing call connection into the held state.
Table 116 HOLD_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The connection type of the device supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
HOLD_CALL_CONF
MAKE_CALL_REQ
The MAKE_CALL_REQ message, defined in the following tables, allows a client to initiate a call between two devices.
This request attempts to create a new call and establish a connection between the calling device (originator) and the called device (destination).
Table 119 MAKE_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
Table 120 MAKE_CALL_REQ floating part message body format CallVariable2[14]. (optional) through CallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
MAKE_CALL_CONF
The MAKE_CALL_CONF message, defined in the following tables, confirms the processing completion of the Make Call request.
Table 121 MAKE_CALL_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The connection type of the device supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
RECONNECT_CALL_REQ
The RECONNECT_CALL_REQ message, defined in the following tables, requests the combined action of clearing an active call and then retrieving an existing held call.
Table 123 RECONNECT_CALL_REQ fixed part field name message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value assigned to the currently active call by Unified CCX.
The type of device ID supplied in the ActiveConnectionDeviceID floating field. See ConnectionDeviceType values.
The type device ID supplied in the HeldConnectionDeviceID floating field. See ConnectionDeviceType values.
RECONNECT_CALL_CONF
RETRIEVE_CALL_REQ
The RETRIEVE_CALL_REQ message, defined in the following tables, allows a client to retrieve an existing held connection.
Table 126 RETRIEVE_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The connection type of the device supplied in the HeldConnectionDeviceID floating field. See ConnectionDeviceType values.
RETRIEVE_CALL_CONF
TRANSFER_CALL_REQ
The TRANSFER_CALL_REQ message, defined in the following tables, allows a client to transfer a held call with an active call at the same device.
This request merges the two calls with connections to a single common device. Both of the connections with the common device become NULL and their device IDs are released.
Table 129 TRANSFER_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value assigned to the currently active call by Unified CCX.
The connection type of the device supplied in the ActiveConnectionDeviceID floating field. See ConnectionDeviceType values.
The connection type of the device supplied in the HeldConnectionDeviceID floating field. See ConnectionDeviceType values.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
Table 130 TRANSFER_CALL_REQ floating part message body format The device ID of the held call connection. Either a HeldConnectionDeviceID or DialedNumber is required.
CallVariable2[14]. (optional) through CallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
TRANSFER_CALL_CONF
The TRANSFER_CALL_CONF message, defined in the following tables, confirms the processing completion of the Transfer Call request.
Table 131 TRANSFER_CALL_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The Call ID value assigned to the resulting transferred call by Unified CCX.
The type of device ID supplied in the NewConnectionDeviceID floating field. See ConnectionDeviceType values.
The number of active connections associated with this conference call, up to a maximum of 16.
SEND_DTMF_SIGNAL_REQ
The SEND_DTMF_SIGNAL_REQ message, defined in the following tables, allows a client to have the ACD transmit a sequence of DTMF tones on behalf of a call party.
Table 133 SEND_DTMF_SIGNAL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The connection type of the device supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
The duration in milliseconds of the DTMF digit tones. A value of 0 can be used to select a default value. Can be ignored if Unified CCX is unable to alter the DTMF tone timing.
Specifies the duration in milliseconds of the DTMF inter-digit spacing. A value of 0 can be used to select a default value. Can be ignored if Unified CCX is unable to alter the DTMF tone timing.
SEND_DTMF_SIGNAL_CONF
SET_CALL_DATA_REQ
This message is sent by a client or Unified CCX to set one or more call variables and/or call wrap-up data. The combination of CallID, ConnectionDeviceType, and ConnectionDeviceID uniquely identify the call to be operated on. Variables not provided in the message are not affected. See also Call context data.
The SET_CALL_DATA_REQ and SET_CALL_DATA_CONF messages are defined in the following table and in SET_CALL_DATA_CONF.
Table 136 SET_CALL_DATA_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
The general classification of the call type. See CallType Values, page 9-13.
Indicates the disposition of the called party. See Disposition Values, page 9-19.
Table 137 SET_CALL_DATA_REQ floating part message body format The digits entered by the caller in response to IVR prompting.
CallVariable2[14]. (optional) through CallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
SET_CALL_DATA_CONF
The SET_CALL_DATA_CONF message confirms the processing completion of the SET_CALL_DATA_REQ message.
When the requested call variables have been updated, and the new values are guaranteed to remain set in the event that the CTI session is abnormally terminated, Unified CCX responds to the client that requested the update with the SET_CALL_DATA_CONF message.
SUPERVISE_CALL_REQ
At any time, for monitoring quality of service, training, and so on, a supervisor client can send a SUPERVISE_CALL_REQ message to Unified CCX to request barge-in or interception of a call. At the end of such call supervision, a supervisor client should send a SUPERVISE_CALL_REQ message with SUPERVISOR_CLEAR as the SupervisorAction value to disconnect the supervisor's device from the call. The SUPERVISE_CALL_REQ message, defined in the following tables, allows a supervisor client to supervise an agent's call, either through barge-in or interception.
Table 139 SUPERVISE_CALL_REQ fixed part field name message body format Field name
A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value assigned to the call by Unified CCX. This Call ID value is normally the Integer CallID on the agent’s device.
The Call ID value of the supervisor. If there is no supervisor call, this field must be set to 0xffffffff.
The type of device ID supplied in the AgentConnectionDeviceID floating field. See ConnectionDeviceType values.
The type of device ID supplied in the SupervisorConnectionDeviceID floating field. See ConnectionDeviceType values.
One of the values from Table 3 specifying the desired call supervision operation.
Table 140 SUPERVISE_CALL_REQ floating part field name message body format Field name
The identifier of the connection of the agent call and the agent's device. Either the CallID and the ConnectionDeviceID, or one of AgentExtension, AgentID, or AgentInstrument must be provided.
The identifier of the connection of the supervisor call and the supervisor's device. Either the CallID and the ConnectionDeviceID, or one of AgentExtension, AgentID, or AgentInstrument must be provided.
The agent's IP phone extension. Either CallID and ConnectionDeviceID, or one of AgentExtension, AgentID, or AgentInstrument must be provided.
Supervisory Action Values
Table 141 Supervisory Action Values SUPERVISOR_MONITOR
The supervisor device is to be connected to the call for silent monitoring. This allows the supervisor to hear all parties participating in the call.
1
The supervisor device is to be connected to the call as an active participant. This allows the supervisor to speak to all parties participating in the call, as in a conference.
The supervisor device is to be connected to the call as an active participant and the agent connection will be dropped.
SUPERVISE_CALL_CONF
The SUPERVISE_CALL_CONF message, defined in the following tables, confirms the processing completion of the SUPERVISE_CALL_REQ message.
Table 142 SUPERVISE_CALL_CONF fixed part field name message body format Set to the same value as the InvokeID from the corresponding request message.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
SUPERVISOR_ASSIST_REQ
When an agent needs supervisor assistance, an agent can send a SUPERVISOR_ASSIST_REQ message to Unified CCX asking for assistance from a team supervisor.
Once an available supervisor is found, a call with calltype SUPERVISOR_ASSIST is initiated and a SUPERVISOR_ASSIST_CONF is sent to the requesting client. If no supervisor can be found a FAILURE_CONF response is returned to the requesting client.
The SUPERVISOR_ASSIST_REQ message, defined in the following tables, allows a client to notify the client agent's supervisor that assistance with the indicated call is required.
Table 144 SUPERVISOR_ASSIST_REQ fixed part field name message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The Call ID value of the call with which the agent needs assistance. Can contain the special value 0xffffffff when there is no related call.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
SUPERVISOR_ASSIST_CONF
The SUPERVISOR_ASSIST_CONF message, defined in the following tables, confirms the processing completion of the SUPERVISOR_ASSIST_REQ message.
Table 146 SUPERVISOR_ASSIST_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The Call ID value assigned to the resulting SupervisorAssist call by Unified CCX.
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
SUPERVISOR_ASSIST_EVENT
The SUPERVISOR_ASSIST_EVENT message, defined in the following tables, indicates that a client requested supervisor assistance.
Table 148 SUPERVISOR_ASSIST_EVENT fixed part field name message body format The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
BAD_CALL_REQ
The BAD_CALL_REQ message, defined in the following tables, allows a CTI client to notify Unified CCX of the bad quality of a call.
Given this information, Unified CCX can log information on the call that can help diagnose the issue.
Table 150 BAD_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The connection type of the device supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
The Call ID value of the call that the agent needs assistance with. Can contain the special value 0xffffffff when there is no related call.
Miscellaneous messages
This section contains the following message definitions:
- QUERY_QUEUE_STATISTICS_REQ
- QUERY_QUEUE_STATISTICS_CONF
- QUERY_AGENT_QUEUE_STATISTICS_REQ
- QUERY_AGENT_QUEUE_STATISTICS_CONF
- QUERY_DEVICE_INFO_REQ
- QUERY_DEVICE_INFO_CONF
- QUERY_SUMMARY_STATISTICS_REQ
- QUERY_SUMMARY_STATISTICS_CONF
- SNAPSHOT_CALL_REQ
- SNAPSHOT_CALL_CONF
- SNAPSHOT_DEVICE_REQ
- SNAPSHOT_DEVICE_CONF
- QUERY_QUEUE_STATISTICS_REQ
- QUERY_QUEUE_STATISTICS_CONF
- QUERY_AGENT_QUEUE_STATISTICS_REQ
- QUERY_AGENT_QUEUE_STATISTICS_CONF
- QUERY_DEVICE_INFO_REQ
- QUERY_DEVICE_INFO_CONF
- QUERY_SUMMARY_STATISTICS_REQ
- QUERY_SUMMARY_STATISTICS_CONF
- SNAPSHOT_CALL_REQ
- SNAPSHOT_CALL_CONF
- SNAPSHOT_DEVICE_REQ
- SNAPSHOT_DEVICE_CONF
- START_RECORDING_REQ
- START_RECORDING_CONF
QUERY_QUEUE_STATISTICS_REQ
The QUERY_AGENT_QUEUE_STATISTICS_REQ message, defined in the following tables, allows a CTI client to obtain the current call handling statistics for one of the client agent’s CSQs. To avoid impacting system performance, clients should not request queue statistics too frequently. Depending on the needs of the client application, updating queue statistics after each call is handled can be appropriate.
QUERY_QUEUE_STATISTICS_CONF
The QUERY_QUEUE_STATISTICS_CONF message, defined in the following tables, confirms the processing completion of the QUERY_AGENT_QUEUE_STATISTICS_REQ message.
Today values represent statistics accumulated since StartTime as indicated in the message. Call counts and times are updated when any after-call work for the call is completed (calls currently in progress are not included in the statistics).
Table 155 QUERY_QUEUE_STATISTICS_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The number of agents currently belonging to the CSQ who are currently logged in.
The number of agents currently belonging to the CSQ who are currently In-Session (talking state).
The number of agents currently belonging to the CSQ who are currently Unavailable (not ready state).
The number of agents currently belonging to the CSQ who are currently in Work state (work not ready state).
The number of agents currently belonging to the CSQ who are currently in Selected state (reserved state).
The total number of calls that are in the priority queue 1 of CSQ.
The total number of calls that are in the priority queue 2 of CSQ.
The total number of calls that are in the priority queue 3 of CSQ.
The total number of calls that are in the priority queue 4 of CSQ.
The total number of calls that are in the priority queue 5 of CSQ.
The total number of calls that are in the priority queue 6 of CSQ.
The total number of calls that are in the priority queue 7 of CSQ.
The total number of calls that are in the priority queue 8 of CSQ.
The total number of calls that are in the priority queue 9 of CSQ.
The total number of calls that are in the priority queue 10 of CSQ.
The Date and Time that the following counters have started accumulating.
The total number of calls that were associated to this CSQ in the current day.
The elapsed wait time for the oldest call currently in queue.
The total number of calls that were handled by agents belonging to the CSQ in the current day.
The total number of calls that were associated with the CSQ and were abandoned by the callers before connecting to an agent.
The total number of calls that were dequeued from the CSQ queue.
The average talk duration for the calls coming in to this CSQ.
The average wait time for a call before it gets connected to an agent.
The longest time that a caller was talking to an agent (for this CSQ).
The longest wait time before a caller got connected to an agent.
QUERY_AGENT_QUEUE_STATISTICS_REQ
The QUERY_AGENT_QUEUE_STATISTICS_REQ message allows a CTI client to obtain the summary queue statistics for an agent for all the CSQs to which the agent belongs. To avoid impacting system performance, clients should not request agent statistics too frequently. Depending on the needs of the client application, updating agent statistics after each call is handled may be appropriate.
QUERY_AGENT_QUEUE_STATISTICS_CONF
The QUERY_AGENT_QUEUE_STATISTICS_CONF message, defined in the following tables, confirms the completion of the QUERY_AGENT_QUEUE_STATISTICS_REQ message.
Table 159 QUERY_AGENT_QUEUE_STATISTICS_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The sum of the total number of calls in queue for all the CSQs that this Agent belongs to.
The elapsed wait time of the oldest call currently in queue for any of the CSQs to which the Agent belongs.
QUERY_DEVICE_INFO_REQ
The QUERY_DEVICE_INFO_REQ message, defined in the following tables, allows a client to retrieve general information about a specified device.
QUERY_DEVICE_INFO_CONF
The QUERY_DEVICE_INFO_CONF message, defined in the following tables, confirms the processing completion of the Query Device Info request.
Table 163 QUERY_DEVICE_INFO_CONF field name message body format Set to the same value as the InvokeID from the corresponding request message.
The maximum number of concurrent calls that can be active at the device.
The maximum number of concurrent calls that can be held at the device. Set to 0xFFFF if unknown or unavailable.
The maximum number of devices that can participate in conference calls at the device. Set to 0xFFFF if unknown or unavailable.
A bitwise combination of Agent State masks in which a MAKE_CALL_REQ message can be initiated.
QUERY_SUMMARY_STATISTICS_REQ
QUERY_SUMMARY_STATISTICS_CONF
The QUERY_SUMMARY_STATISTICS_CONF message, defined in the following table, confirms the processing completion of the QUERY_SUMMARY_STATISTICS_REQ message.
Today values represent statistics accumulated since StartTime as indicated in the message. Call counts and times are updated when any after-call work for the call is completed (calls currently in progress are not included in the statistics).
Table 166 QUERY_SUMMARY_STATISTICS_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The total number of calls that are in priority queue 1 for all CSQs.
The total number of calls that are in priority queue 2 for all CSQs.
The total number of calls that are in priority queue 3 for all CSQs.
The total number of calls that are in priority queue 4 for all CSQs.
The total number of calls that are in priority queue 5 for all CSQs.
The total number of calls that are in priority queue 6 of all CSQs.
The total number of calls that are in priority queue 7 for all CSQs.
The total number of calls that are in priority queue 8 for all CSQs.
The total number of calls that are in priority queue 9 for all CSQs.
The total number of calls that are in priority queue 10 for all CSQs.
The Date and Time that the following counters have started accumulating.
The time that the oldest call currently in queue has been waiting.
The total number of calls that were handled in the current day.
The total number of calls that were abandoned by the callers before connecting to an agent.
The average wait time for a call before it gets connected to an agent
The longest wait time before a caller got connected to an agent.
SNAPSHOT_CALL_REQ
The SNAPSHOT_CALL_REQ message, defined in the following tables, allows a client to retrieve information on a specified call.
The call information provided consists of a list of the associated devices and the connection state for each device.
Table 167 SNAPSHOT_CALL_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
The connection type of the device supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
SNAPSHOT_CALL_CONF
The SNAPSHOT_CALL_CONF message, defined in the following tables, confirms the processing completion of the requested Snapshot Call data.
Table 169 SNAPSHOT_CALL_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
This value is set to 0. For a silent monitoring call, this value is set to 21 (CALLTYPE_SUPERVISOR_ MONITOR).
The number of active devices associated with this call, up to a maximum of 16.
This value also indicates the number of CallCallID, CallConnectionDeviceType, CallConnectionDeviceID, CallDeviceType, CallDeviceID, and CallDeviceConnectionState floating fields present in the floating part of the message.
The number of NamedVariable floating fields present in the floating part of the message.
The number of NamedArray floating fields present in the floating part of the message.
( Only available in CTI Protocol version 11 and later.)
Table 170 SNAPSHOT_CALL_CONF floating part message body format The digits entered by the caller in response to IVR prompting.
CallVariable2[14]. (optional) through CallVariable9[21] (optional)
Call-related variable data that has a variable name defined in the Unified CCX Editor. See NAMEDVARIABLE data format, for the format of this field.
Call-related variable data that has an array variable name defined in the Unified CCX Editor. See NAMEDARRAY data format, for the format of this field.
The Call ID value assigned to one of the call device connections. There can be more than one CallCallID field in the message (see NumCallDevices, above).
The connection type of the device supplied in the following CallConnectionDeviceID floating field. There can be more than one CallConnectionDeviceType fields in the message (see NumCallDevices, above). This field always immediately follows the corresponding CallConnectionCallID field. See ConnectionDeviceType values.
The device ID of one of the call connections. There can be more than one CallConnectionDeviceID field in the message (see NumCallDevices, above). This field always immediately follows the corresponding CallConnectionDeviceType field. See ConnectionDeviceType values.
The device ID type of the device supplied in the following CallDeviceID floating field. See DeviceType values.
There can be more than one CallDeviceType field in the message (see NumCallDevices, above). This field always immediately follows the corresponding CallConnectionDeviceID field.
The device ID of the subject device. There can be more than one CallDeviceID field in the message (see NumCallDevices, above). This field always immediately follows the corresponding CallDeviceType field.
The local connection state of one of the call device connections. There can be more than one CallDeviceConnectionState field in the message (see NumCallDevices, above). This field always immediately follows the corresponding CallDeviceID field.
SNAPSHOT_DEVICE_REQ
The SNAPSHOT_DEVICE_REQ message, defined in the following tables, allows a client to retrieve information on a specified device.
The device information provided consists of a list of the calls associated with the device and the current state of each call.
Table 171 SNAPSHOT_DEVICE_REQ fixed part message body format A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message.
For non-agent devices this indicates the type of the device specified in the following AgentInstrument floating field.
SNAPSHOT_DEVICE_CONF
The SNAPSHOT_DEVICE_CONF message, defined in the following tables, confirms the requested completion of the Snapshot Device data request.
Table 173 SNAPSHOT_DEVICE_CONF fixed part message body format Set to the same value as the InvokeID from the corresponding request message.
The number of active calls associated with this device, up to a maximum of 16.
This value also indicates the number of CallConnectionCallID, CallConnectionDeviceType, CallConnectionDeviceID, and CallState floating fields present in the floating part of the message.
Table 174 SNAPSHOT_DEVICE_CONF floating part message body format The Call ID value assigned to one of the calls. There can be more than one CallConnectionCallID field in the message (see NumCalls, above).
The connection type of the device supplied in the following CallConnectionDeviceID floating field. See ConnectionDeviceType values.
There can be more than one CallConnectionDeviceType field in the message (see NumCalls, above). This field always immediately follows the corresponding CallConnectionCallID field.
Indicates the connection type supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType values.
The active state of the call (LocalConnectionState (LCS) values). There can be more than one CallState field in the message (see NumCalls, above). This field always immediately follows the corresponding CallConnectionDeviceID field.
START_RECORDING_REQ
A CTI client sends a START_RECORDING_REQ message, requesting Unified CCX to start recording a call. Upon receiving the START_RECORDING_REQ, Unified CCX processes the recording request. If the recording is successful, Unified CCX sends back START_RECORDING_CONF to the requesting CTI client. If not, Unified CCX sends back CONTROL_FAILURE_CONF with appropriate error codes indicating the failure cause.
Table 175 START_RECORDING_REQ Message Format An ID for this request message that will be returned in the corresponding confirm message.
reserved
Set the value to 1.
UINT
4
ConnectionCallID
The Call ID value assigned to this call.
UINT
4
reserved
Set the value to 0.
UINT
4
reserved
Set the value to 0.
UINT
4
reserved
Set the value to 0.
UINT
4
ConnectionDeviceIDType
Indicates the type of the connection identifier supplied in the ConnectionDeviceID floating field.
USHORT
2
reserved
Set the value to 0.
USHORT
2
reserved
Set the value to 0.
USHORT
2
reserved
Set the value to 0.
USHORT
2
reserved
Set the value to 0.
USHORT
2
ConnectionDeviceID (required)
The identifier of the connection between the call and the device.
STRING
64
ClientAddress (server only)
The IP address of the CTI client requesting call recording, provided by CTI Server when this message is sent to a server application.
STRING
16
AgentExtension
The agent's ACD teleset extension. For requesting clients with All Events or Peripheral Monitor service, at least one of Agent Extension or Agent Instrument must be provided.
STRING
16
AgentInstrument
The agent's ACD instrument number. For requesting clients with ALL EVENTS or PERIPHERAL MONITOR service, at least one of Agent Extension or Agent Instrument must be provided.
STRING
64
ClientAddressIPV6 (v14+)(not supported by ICM)
The IP address of the CTI client (Where supported, this address can replace ClientAddress. One but not both must be present.).
STRING
16
Maximum message size (including header)
280
