Cisco Unified Contact Center Express CTI Protocol Developer Guide Release 11.0(1)
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- November 23, 2017
Chapter: All Message Types Organized by Class and Type
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
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.
|
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. |
|||
|
|
|||
|
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.
|
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.
|
A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message. |
HEARTBEAT_CONF
On receipt of a HEARTBEAT_REQ message, Unified CCX immediately responds with a HEARTBEAT_CONF message, defined in the following table.
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).
|
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.
|
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. |
CLOSE_CONF
Unified CCX confirms the termination of the communication session with the CLOSE_CONF message, defined in the following table.
|
Set to the same value as the InvokeID from the corresponding CLOSE_REQ message. |
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. |
|
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. |
|
A text description of the reason for the failure reason, if one is known. |
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.
|
A status code indicating the cause of the failure. The possible status codes are defined in Table 1. |
|
Text field indication a text description of the failure reason (if any). |
Configuration Messages
This section includes the following configuration message definitions:
- 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
The CONFIG_REQUEST_KEY_EVENT can be sent by the client to request the current configuration keys for different types of data.
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.
|
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.
|
2: Update |
|||
|
Bit Mask indicating the type of information included: 2: CSQ Information 4: Agent Information 8: Device Information |
|
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.
|
Indicates the status of the configuration block. See Table 3 for status values and descriptions. |
|
No data was sent because the configuration service is not requested in the service request of the OPEN_REQ message. |
||
|
An invalid reserved[131] field is in the CONFIG_REQUEST_EVENT message. |
||
|
An error occurred and an invalid or partial configuration was sent. |
||
CONFIG_CSQ_EVENT
The CONFIG_CSQ_EVENT message is sent to indicate a CSQ configuration update.
|
The number of records included in the floating part of this message. |
|
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). |
||
Table Notes
CONFIG_APPLICATION_EVENT
The CONFIG_APPLICATION_EVENT message is sent by Unified CCX to provide information about an Application.
|
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. |
|
1: Change 2: Delete |
|||
|
The maximum number of sessions associated with this application. |
|||
|
If the application ID is changed, this value stores the previous application ID. |
|||
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. |
|
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. |
|
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.
|
The Number of records included in the floating part of this message. |
|
SeeTable 3. |
|||
|
See Table 3 . |
|||
Table 3 specifies the floating data fields in the CONFIG_DEVICE_EVENT message according to the device type. For example:
|
AgentRecordID (Unified CCX internal ID for this agent record.) |
||||
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.
|
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) |
|||
|
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.
|
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.
|
The same value as the InvokeID from the corresponding request message. |
|||
|
The response to the TEAM_CONFIG_REQ. message. The values are: 1: Unified CCX Internal Error |
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.
|
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. |
|
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.
|
A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message. |
|||
|
The agent’s IP phone number. At least one of AgentExtension, AgentID, or AgentInstrument must be provided. |
|||
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.
|
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. |
|||
|
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. |
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.
|
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 |
|
The password that allows an agent to log into a CSQ. This field is required when AgentState is AGENT_STATE_LOGIN. |
|||
|
The agent’s Unified CCX login ID. This field is required when the AgentState is AGENT_STATE_LOGIN or AGENT_STATE_LOGOFF. |
SET_AGENT_STATE_CONF
The SET_AGENT_STATE_CONF message, defined in the following table, confirms the successful completion of a request for setting the agent state.
|
Set to the same value as the InvokeID from the corresponding request message. |
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.
- 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.
|
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. |
|
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.
|
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType Values. |
|||
|
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.
|
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. |
|||
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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. |
|
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.
|
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.
|
The audio codec type. See Audio Codec Type Values. |
|||
|
The type of device ID supplied in the ConnectionDeviceID floating field. See ConnectionDeviceType Values. |
|||
|
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.
|
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. |
|||
|
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.
- 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.
|
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). |
|
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
The ALTERNATE_CALL_CONF message, defined in the following table, confirms the processing completion of the Alternate Call request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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). |
|
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. |
|
The ID of the connection between the call and the device. Either ConnectionDeviceID or AgentInstrument must be specified. |
|||
|
The IP phone number that answers the call. Either ConnectionDeviceID or AgentInstrument must be specified. |
ANSWER_CALL_CONF
The ANSWER_CALL_CONF message, defined in the following table, confirms successful completion of the Answer Call request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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. |
|
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
The CLEAR_CALL_CONF message, defined in the following table, confirms the processing completion of the Clear Call request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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.
|
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. |
|
The phone number of the agent’s IP phone whose connection is to be released. |
CLEAR_CONNECTION_CONF
The CLEAR_CONNECTION_CONF message, defined in the following table, confirms the processing completion of the Clear Connection request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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.
|
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. |
|
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.
|
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. |
|||
|
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.
|
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. |
|
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:
|
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. |
|||
|
The ID of the device connection associated with the new call. |
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.
|
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
The HOLD_CALL_CONF message, defined in the following table, confirms successful completion of the Hold Call request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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).
|
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. |
|||
|
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.
|
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. |
|||
|
The device ID of the connection between the call and the device. |
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.
|
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. |
|
The device identifier of the currently active call connection. |
|||
RECONNECT_CALL_CONF
The RECONNECT_CALL_CONF message, defined in the following table, confirms the processing completion of the Reconnect Call message request.
|
Set to the same value as the InvokeID from the corresponding request message. |
RETRIEVE_CALL_REQ
The RETRIEVE_CALL_REQ message, defined in the following tables, allows a client to retrieve an existing held connection.
|
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
The RETRIEVE_CALL_CONF message, defined in the following table, confirms the processing completion of the Retrieve Call request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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.
|
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. |
|
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.
|
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. |
|||
|
The device ID of the connection between the call and the device. |
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.
|
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
The SEND_DTMF_SIGNAL_CONF message, defined in the following table, confirms the processing completion of the send DTMF signal request.
|
Set to the same value as the InvokeID from the corresponding request message. |
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.
|
A unique ID generated by the CTI client for each request message. This ID is returned in the corresponding confirmation message. |
|||