BRKDEV-1151

© 2006, Cisco Systems, Inc. All rights reserved.Presentation_ID.scr

1

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 1BRKDEV-115114624_05_2008_X1

Cisco Unified CCX CTI Protocol

BRKDEV-1151


Cisco Unified Contact Center Express (CCX) Computer Telephony Integration (CTI) Protocol

BRKDEV-1151


2


Agenda

OverviewCCX ConfigurationMessage FormatMessage Functions

SessionConfigurationAgent StateCall EventCall ControlMiscellaneous Messages

Sample Call FlowsQ & A


Overview


3


Overview

CCX is a full-featured, integrated, easy-to-use, easy-to-deploy and highly-available customer interaction management for up to 300 agents

CCX offers a rich set of features: skills-based routing, CTI integration, database integration, outbound, email, web chat, WFO

CCX CTI protocol is used between clients such as CAD and the CCX server

CCX CTI protocol has been used since CCX 3.x but is made available with CCX 4.1, CCX 5.0, 6.0 and later releases

Same protocol is used by Cisco Agent Desktop, Cisco Interaction Manager and the CCX Gateway PG

The protocol has a rich set of CTI features including call and agent state notifications, real time statistics, call control, auto-configuration


Overview Diagram

CCX CTI PROTOCOL

Cisco Interaction Manager

CCX Gateway

PG

Cisco Agent Desktop

CCX CTI PROTOCOL

CCX CTI PROTOCOL


4


Overview

Custom Agent DesktopAllows for customized business rules, e.g. automatically make an agent ready if the agent does not have a call and is in Not Ready for a certain duration

Custom Supervisor DesktopAllows supervisors to monitor agents, view real-time data and control agent states. Supports customized business logic such as making all Not Ready agents ready when the calls in queue exceed a certain threshold

Integration with Other ApplicationsAllow agents to interface with only one application by integrating with CRM/ERP applications, e.g. integrate agent state management and call control with backend CRM application to give agents a complete set of functionalities in a single application

The Protocol Can Be Used For


Overview

ReportingSupports customized business logic based on events and notifications, e.g. send out an email when an agent device is down, allow agents to see not only their own agent state and real-time statistics but other agent states as well

Configuration Synchronization and NotificationAllows applications to get configuration data from CCX and be notified of any configuration changes, e.g. Cisco Interaction Manager (CIM) uses CCX CTI protocol to get agent, CSQ and team data

Call DataAllows flexibility in presenting the right call data to agents, e.g. if a call is for Sales, look up sales order in CRM. If a call is for IT support, look up the case in case-tracking tool

The Protocol Can Be Used For


5


CCX CTI Protocol Versions

The table below shows the versions of the CCX CTI protocol supported in various CCX releases

10,11,126.010,11,125.0

104.1CTI VersionCCX Version


Delivery

The delivery of this feature includes a CCX CTI Protocol Developer Guide and sample code

Available to subscribers of the Developer Services program


6


CCX Configuration, Message Format


CCX Configuration for CCX CTI Protocol

CCX CTI client applications use TCP/IP connection on a socket to connect to CCXThe listening port number is specified in AppAdmin system parameters as RmCm TCP Port

Port Used by CCX CTI Clients


7


Fixed Field Data

FieldDataIDSubfield

FieldDataLengthSubfield

DataSubfield

Fixed Fields 1..n Floating Fields 1..n

MessageLength

Message Type Fixed Part Floating Part

Header Body

CCX CTI Protocol Message Format

1 4

32 4 8

6 9

1211107



A CCX CTI message is a byte array of fields containing a message header and a message body

The message header is a required field and contains a 4-byte MessageTypeID field and a 4-byte body length field (excludes the size of the message header)

The MessageTypeID is a numeric ID that identifies the type of the message. For example, OPEN_REQ has a numeric ID of 3, HEARTBEAT_REQ is 5

Header1

MessageLength

MessageType2 3


8


Fixed Part Floating Part5 8


The message body is made up of a fixed and a floating part

The floating part is made up of a field data ID subfield, a field length subfield and data subfield

Body4



The fixed part is made up of fixed fields. Each field has a fixed length and are put together in a fixed order. The type and number of fixed fields depend on the message type. Fixed fields are defined by data types such as CHAR, UCHAR, SHORT, USHORT, INT, UINT, BOOL, TIME

Example: OPEN_REQ

4UINTReserved4UINTReserved4UINTReserved4UINTConfigMsgMask4UINTAgentStateMask4UINTCallMsgMask4UINTServicesRequested4UINTReserved4UINTIdleTimeout4UINTVersion Number4UINTInvokeIDByte SizeData TypeFixed Field Name


9



The message floating part follows the fixed part. It is variable in length and sometimes optional (depending on the message type)

The floating part is made up of floating fields, each with a field data ID subfield, a field data length subfield and data subfield

The field data ID subfield is a one-byte field identifying the field type. Examples: 4 is agent extension, 8 is ANI

Floating Fields 1..n

FieldDataIDSubfield


DataSubfield

9

11 1210



Following the field data ID subfield is a one-byte FieldDataLength subfield which indicates the number of bytes of data in the data subfield

The data subfield immediately follows the FieldDataLength subfield

Floating data types include CHAR, UCHAR, SHORT, USHORT, INT, UINT, BOOL, TIME, STRING, UNSPEC

Floating Fields 1..n

FieldDataIDSubfield


DataSubfield

9

11 1210


10



The maximum data size listed in each message definition for each floating field is the maximum number of data bytes allowed

Floating fields may appear in any order in the floating part of the message

Example: OPEN_REQ

Required for agent modeRequired for agent modeRequired for agent modeOptionalRequiredRequiredRequired/Optional

32StringAgentID64StringAgentInstrument16StringAgentExtension64StringClientSignature64UnspecClientPassword64StringClientIDMax SizeData TypeFloating Field Name


Protocol Features


11


Message Types

CCX CTI Messages

Session Management

Agent State Management

Statistics Messages

ConfigurationUpdates

Call Monitor/Control


CCX CTI Protocol Features

CCX CTI protocol provides support for session management, agent state management, configuration updates, call monitoring and control and statistics

CCX CTI clients can receive both solicited and unsolicited messages

Every request message from a client will generate a response message from Unified CCX Server (Solicited messages)

The CCX server can also send some messages like failure notifications to client, without the client requesting for them (Unsolicited messages)


12


Session Messages


Session Messages

A client initiates a session by trying to connect to the CCX server using the TCP port number configuredOnce a connection is established, the client tries to create a session by sending an OPEN_REQIf successful, the CCX server sends an OPEN_CONF response. If unsuccessful, the status code in FAILURE_CONF message indicates failure reason. Examples: E_CTI_SERVER_NOT_MASTER, E_CTI_REQUIRED_DATA_MISSINGIn the OPEN_REQ, the client specifies the version number, the idle timeout, the services requested mask, call message mask, agent state mask, configuration message maskMasks are used to avoid wasting network bandwidth by suppressing unnecessary messages


13


Session Messages

The services requested mask specifies which CTI services the client can request (agent state and call control, call data update, configuration, or all)

The services requested mask also indicates if the connection is in agent or bridge mode

Bridge mode (all-events mode) A bridge mode client receive all agent state and call events for all logged in agents. It also receives confirmation for requests it makes, but not that of other clients

Agent mode (client mode) An agent mode client only receives messages related to that agent

Once a session is established, you cannot change the connection mode of the session


Session Messages

0x00000080Client can perform supervisory functions

CTI_SERVICE_SUPERVISOR

0x00040000Client receives configuration eventsCTI_SERVICE_CONFIG_EVENTS

0x00000010Client receives all call and agent state changes for any phone. Indicates client is in Bridge mode

CTI_SERVICE_ALL_EVENTS

0x00000004Client can control calls and agent states for a specific phone

CTI_SERVICE_CLIENT_CONTROL

0x00000002Client can modify call context data

CTI_SERVICE_CALL_DATA_UPDATE

0x00000001Client receives call and agent state events for a specific phone. Indicates client is in Agent mode

CTI_SERVICE_CLIENT_EVENTS

BytesDescriptionMask Name (for Service Mask)

Examples of Service Mask


14


Session Messages

CallMsgMask is a bitwise combination of unsolicited call event masks that the client wants to receive. If the client wants CALL_DELIVERED_EVENT (0x1) and CALL_ESTABLISHED_EVENT (0x4), the callMsgMask should be 0x5

AgentStateMask is a bitwise combination of unsolicited agent state masks that the client wants to receive

ConfigMsgMask is a bitwise combination of configuration events that the client wants to receive. Configuration events are defined for agents, CSQs, applications and devices


Session Messages

A session is maintained by sending heartbeat messages, which is used to handle and detect transmission and server/client failures

The client sends a heartbeat message at regular intervals called the heartbeat interval. If it does not get confirmation for 3 consecutive heartbeat messages, it should declare a failure and reset the connection

The server will reset the connection if it does not get a heartbeat message within the idle-timeout period, which is specified as a parameter in OPEN_REQ

To close a connection, the client sends a CLOSE_REQ. The server in turn sends a CLOSE_CONF


15


Configuration Messages



CCX CTI clients can acquire configuration data from the CCX server and use configuration messages to synchronize that data between CCX and themselves

This includes an initial bulk upload of configuration data and subsequent dynamic updates whenever there is a configuration change made

CCX configuration messages support data for agents, CSQs, teams, devices (triggers, CTI ports, agent devices, CTI port groups) and applications


16



TEAM_CONFIG_EVENT

TEAM_CONFIG_CONF

TEAM_CONFIG_REQ

CONFIG_BEGIN_EVENT

CONFIG_CSQ_EVENT

CONFIG_APPLICATION_EVENT

CONFIG_AGENT_EVENT

CONFIG_DEVICE_EVENT

CONFIG_END_EVENT

CONFIG_REQUEST_EVENT

CONFIG_KEY_EVENTCONFIG_REQUEST_KEY_EVENT

ResponseRequest

Messages



The client must include the CTI_SERVICE_CONFIG_EVENTS bit in the ServiceRequested field of an OPEN_REQ message if the client wants configuration data. Client sends CONFIG_REQUEST_KEY_EVENT message to request a current set of configuration keysServer responds by sending CONFIG_KEY_EVENT, which contains the CCX configuration keys at the time of the requestIf the client as the same set of keys as the server, it means that the client configuration is in sync with that on the server


17



If the client needs an initial snapshot of the configuration, the client sends CONFIG_REQUEST_EVENT, with the configuration mask set to a value that represents which configuration data is requested

If the initial snapshot of the configuration is requested, the server sends the initial snapshot of the configuration data to the client in a CONFIG_BEGIN_EVENT and CONFIG_END_EVENT block of messages. In between these two messages, the server sends the appropriate message for the type of data requested



Configuration updates performed in the CCX Administration web page are sent to clients in a CONFIG_BEGIN_EVENT and CONFIG_END_EVENT block of messages as well


18



Team Name, Agent ID, Membership TypeCONFIG_TEAM_EVENT

Device Type, extensionCONFIG_DEVICE_EVENT

Login ID, Type, First Name, Last Name, ExtensionCONFIG_AGENT_EVENT

Application ID, Application Name, DescriptionCONFIG_APPLICATION_EVENT

CSQ ID, CSQ Name, Auto-Work SettingCONFIG_CSQ_EVENT

Example Configuration Data in MessageMessage

* All messages above have a record type to indicate if it is an addition, deletion or update

Configuration Data Available in the Configuration Messages



The client must include the CTI_SERVICE_SUPERVISOR bit (0x00000080) in the ServiceRequested field of the OPEN_REQ message if the client wants team configuration dataThe client sends a TEAM_CONFIG_REQ to the CCX serverThe server responds with zero or more TEAM_CONFIG_EVENT messages, followed by a TEAM_CONFIG_CONF messageAfter this request/confirmation exchange, the CCX server sends TEAM_CONFIG_EVENT messages to the client whenever there is a team configuration change

Team Messages


19


Agent State Messages



CCX maintains all agent states and may change an agent state based on various conditions such as an agent hanging up the phone and responding to agent state requests from CAD

CCX CTI clients can monitor or change agent states


20



Agent Clicks Ready on CAD

Agent selected for ACD Call

Agent answers Call

Agent Hangs Up

Work timer Expires or Agent Click Ready

Logoff

CCX

Not Ready

Ready

Reserved

Talking

Work

Ready

SET_AGT_STATE_REQ

SET_AGT_STATE_CONFAGT_STATE_EV

SET_AGT_STATE_REQ

AGT_STATE_EVSET_AGT_STATE_CONF

AGT_STATE_EV

AGT_STATE_EV

AGT_STATE_EV

AGT_STATE_EV

CAD



Clients use the SET_AGENT_STATE_REQ to request a state change

The SET_AGENT_STATE_REQ also contains a field for a reason code

If the request is successful, the server send a SET_AGENT_STATE_CONF response. If not, a FAILURE_CONF is sent


21



Agent Clicks Ready on CAD

Agent Selected for ACD Call

Agent Answers Call

Agent Hangs Up

Work Timer Expires or Agent Click Ready

Logoff

CCX CAD

Not Ready

Ready

Reserved

Talking

Work

Ready

SET_AGT_STATE_REQ

SET_AGT_STATE_CONFAGT_STATE_EV

SET_AGT_STATE_REQ

AGT_STATE_EVSET_AGT_STATE_CONF

AGT_STATE_EV

AGT_STATE_EV

AGT_STATE_EV

AGT_STATE_EV



AGENT_STATE_EVENT is sent whenever an agent changes state

The agent state is reflected by the last AGENT_STATE_EVENT received.

AGENT_STATE_EVENT also contains a reason code field

Reason codes can be system generated or custom. Examples of system-generated reason codes: RNA (32763), Phone_Down (32759)


22


Call Event Messages


Call Events

CCX generates call events related to calls on monitored lines which include triggers (route points), CTI ports and agent ACD lines

These call events are unsolicited messages, which are sent to CCX CTI clients

A client can be notified of a call with a BEGIN_CALL_EVENT as soon as the client is associated with the new call

Additional events are sent to the client as the call is handled,depending on the treatment the call receives

When the association ends, the client receives a CALL_END_EVENT


23


Call Events

Examples of call events:CALL_DELIVERED – indicates the call is ringingCALL_ESTABLISHED – indicates that the call is answeredCALL_HELD_EVENT – indicates that the call is put on holdCALL_RETRIEVED_EVENT – indicates that the held call is resumedCALL_CLEARED_EVENT – indicates that the call has terminated, usually when the last device disconnects from the callCALL_CONNECTION_CLEARED_EVENT – indicates that a party has dropped from a call


Call Events

CALL_TRANSFERRED_EVENT – indicates that a call has been transferred to another destinationCALL_CONFERENCED_EVENT – indicates that multiple calls have been joined into a conference callCALL_QUEUED_EVENT – indicates that a call is placed in queueRTP_STARTED_EVENT – indicates that RTP media stream has startedRTP_STOPPED_EVENT – indicates that RTP media stream has stoppedCALL_DATA_UPDATE_EVENT – indicates that the call context data has changedSET_CALL_DATA_REQUEST – used to set call context data


24


Call Events

Most of the events will have a callID field to identify the call

The CALL_TRANSFERRED and CALL_CONFERENCED events have a primaryCallID and a secondaryCallID. This is because transfer and conference involve 2 calls, a primary and a secondary call. After the transfer and conference completion, the primary call survives and the secondary call drops


Call Control Messages


25



A CCX CTI client can send messages to request CCX to perform call control on behalf of a specified agent phone number. These are solicited messages, and the outcome of the request is indicated in response message

If a call control request is unsuccessful, a CONTROL_FAILURE_CONF response is sent



HOLD_CALL_CONFHOLD_CALL_REQHold

CONSULT_CALL_CONF

TRANSFER_CALL_CONF

CONSULT_CALL_REQ

TRANSFER_CALL_REQ

Transfer

RETRIEVE_CALL_CONFRETRIEVE_CALL_REQUnhold

CONSULT_CALL_CONF

CONFERENCE_CALL_CONF

CONSULT_CALL_REQ

CONFERENCE_CALL_REQ

Conference

CLEAR_CALL_CONNECTION_CONF

CLEAR_CALL_CONF

CLEAR_CALL_CONNECTION_REQ

CLEAR_CALL_REQ

Drop

SEND_DTMF_SIGNAL_REQ

MAKE_CALL_REQ

ANSWER_CALL_REQ

Request

SEND_DTMF_SIGNAL_CONFSend DTMF

MAKE_CALL_CONFMake Call

ANSWER_CALL_CONFAnswerResponseAction

* Most Requests Will Contain a CallID used to Identify the Call. The Transfer and Conference Request Contains 2 callIDs. The MakeCall Request Will Return a callD in the MakeCallConf.


26


Miscellaneous Messages



A CCX CTI client can obtain real-time information related to CSQs and agents. These messages are solicited messages where the CTI client requests the desired information and the CCX server sends the required information as the response

A CTI client can send a QUERY_QUEUE_STATISTICS_REQ to obtain real-time info of a CSQ. The QUERY_QUEUE_STATISTICS_CONF includes number of logged in, in-session, available, unavailable, work, reserved agents, and number of calls in queue for each priority of the CSQ, total calls, number of handled, abandoned, dequeued calls, oldest call in queue, average talk and wait durations, longest talk and wait durations of the CSQ


27



A CTI client can send a QUERY_AGENT_QUEUE_STATISTICS_REQ to get queue-related real-time info of an agent. The QUERY_AGENT_QUEUE_STATISTICS_CONF includes the number of calls in queue and oldest call in queue for the agent,aggregated across all the CSQs the agent belongs to

A CCX CTI client can get snapshot of a call or a device.

The SNAPSHOT_CALL_REQ message can be used to request info about a call. The SNAPSHOT_CALL_CONF contains info such as call variables, number of active devices associated withthe call, ANI, DNIS etc.

The SNAPSHOT_DEVICE_REQ message can be used to request info about a device. The SNAPSHOT_DEVICE_CONF contains info such as the current calls on the device and the state of each call


Call Scenarios


28


Sample Call Flow

Cisco Agent Desktop

4. Call Is Presented to the Agent

5. Agent Answers

Call

6. Call Established

8. Agent Selects Wrap-up

Code

7. Call Drops

1. Caller Makes

Call

CCX CTI Protocol

Agent

CCX

2. Call Presented to and Answered at CTI Port

3. Call Queues on a CSQ

9. Agent Goes Ready


CTI Messages in Call Scenarios

Scenario A: A call is routed to an agent who answers the call. Agent has extension 1007. Caller has extension 1054. CTI Port DN is 3550. Route Point is 5000

Bridge-mode clients

answeringDeviceID:3550

answeringDeviceType:73

CALL_ESTABLISHED_EV

Bridge-mode clients

alertingDeviceID:3550

alertingDeviceType:73

CALL_DELIVERED_EV

Bridge-mode clients

ConnectionCallID: 18748370

connDeviceID: 3550

Ani: 1054

Dnis: 5000

BEGIN_CALL_EVCall arrives at application, and is answered at CTI Port

Sent ToParametersCTI MessageAction


29



Bridge-mode clients

Agent-mode 1007

State: Reserved

agentID: jdoe

agentExtn: 1007

AGENT_STATE_EVAgent is available

Bridge-mode clients

CSQID: 4CALL_QUEUED_EVRequest for agent

Bridge-mode clients

CallVar1: 95008CALL_DATA_UPDATE_EVScript sets an enterprise data

Sent toParametersCTI MessageAction



Bridge-mode clients

Agent-mode 1007

answeringDeviceID:1007

answeringDeviceType:76 (agent device)

CALL_ESTABLISHED_EV

Bridge-mode clients

Agent-mode 1007

State: In-SessionAGENT_STATE_EVAgent answers

Bridge-mode clients

Agent-mode 1007

alertingDeviceID:1007

alertingDeviceType:76 (Agent Device)

CSQID: 4

CALL_DELIVERED_EVAgent phone rings



30



Bridge-mode clients

Agent-mode 1007

releasingDeviceID: 3550

connectionCallID: 1874370

CALL_CONNECTION_CLEARED_EV

Bridge-mode clients

Agent-mode 1007

Direction:0RTP_STARTED_EV

Bridge-mode clients


CALL_DEQUEUEDAgent answersSent toParametersCTI MessageAction



Bridge-mode clients

Agent-mode 1007

releasingDeviceID: 1007CALL_CONNECTION_CLEARED_EV

Bridge-mode clients

Agent-mode 1007

State:WorkAGENT_STATE_EVAgent hangs up

Bridge-mode clients

Agent-mode 1007

Direction:1RTP_STARTED_EVSent toParametersCTI MessageAction


31



Bridge-mode clients

Agent-mode 1007

connectionCallID: 1874370CALL_CLEARED_EVAgent hangs up

Bridge-mode clients

Agent-mode 1007

Direction:1RTP_STOPPED_EV

Bridge-mode clients

Agent-mode 1007

Direction:0RTP_STOPPED_EV




Bridge-mode clients

Agent-mode 1007

State:ReadyAGENT_STATE_EVAgent goes Ready

Bridge-mode clients

Agent-mode 1007

wrapupData:SaleCALL_DATA_UPDATE_EVAgent selects wrap-up code

Bridge-mode clients

Agent-mode 1007

connectionCallI: 1874370

END_CALL_EV



32



Scenario B: Based on previous scenario. Instead of dropping the call, the agent transfers the call to extension 1070. Agent has extension 1007. Caller has extension 1054. CTI Port DN is 3550. Route Point is 5000

Bridge-mode clients

Agent Mode 1007

holdingDeviceID:1007


CALL_HELD_EV

Bridge-mode clients

Agent Mode 1007

Direction: 1RTP_STOPPED_EV

Bridge-mode clients

Agent Mode 1007

Direction: 0RTP_STOPPED_EVAgent initiates xfer




Agent dials 1070

Bridge-mode clients

Agent mode 1007


calledDeviceID:1070

CALL_ORIGINATED_EV

Bridge-mode clients

Agent mode 1007


callingDeviceID:1007

CALL_SERVICE_INITIATED_EV

Bridge-mode clients

Agent mode 1007


BEGIN_CALL_EVSent toParametersCTI MessageAction


33



Bridge-mode clients

Agent mode 1007

Direction: 1RTP_STARTED_EV

Bridge-mode clients

Agent mode 1007

Direction:0RTP_STARTED_EV

Bridge-mode clients

Agent mode 1007

answeringDeviceID:Unknown

answeringDeviceType:65535 (none)

CALL_ESTABLISHED_EV1070 answers




Bridge-mode clients

Agent mode 1007

State:WorkAGENT_STATE_EV

Bridge-mode clients

Agent mode 1007

connectionCallID:18748375

RTP_STOPPED_EV(x2)

Bridge-mode clients

Agent mode 1007

xferringDeviceID:1007

xferredDeviceID:Unknown

primaryCallID:

18748373

secondaryCallID: 18748375

CALL_TRANSFERRED_EVAgent completes xfer



34



Bridge-mode clients

Agent mode 1007


CALL_CLEARED_EV

Bridge-mode clients

Agent mode 1007


END_CALL_EV

Bridge-mode clients

Agent mode 1007


releasingDeviceID:1007





Bridge-mode clients

Agent mode 1007


CALL_CLEARED_EV

Bridge-mode clients

Agent mode 1007


END_CALL_EV

Bridge-mode clients

Agent mode 1007


releasingDeviceID:1007




35


Troubleshooting


Troubleshooting

Look at the MIVR logs on the active CCX serverMake sure DEBUG is turned on ICD_CTI trace sub-facilityTo enable more detailed traces, turn on XDEBUG[1-5]SS_RM, SS_CM and SS_RMCM sub-facilities also help with troubleshootingLooks for exceptions in the ICD_CTI tracesTraces show field values. Example

13319: Mar 31 15:18:23.448 GMT-800 %MIVR-ICD_CTI-7-UNK:EventHandler: posting {AGENT_STATE_EVENT: Socket:Socket: null monitoredDeviceDN:1007, agentDN:1007, agentID:cyeo, monitorID = 0, stateDuration = 0, agentstate = IN_SESSION, eventreasoncode = 0, agentID = cyeo, agentExtension = 1007, agentID_Long = cyeo } to outboundQ


36


Troubleshooting

Traces also show the socket the message was sent to

350271: May 07 11:27:16.076 GMT-800 %MIVR-ICD_CTI-7-UNK:OutboundMessageprocessor : Q size after posting msg : { length=-1 type=AGENT_STATE_EVENT, monitorID=0, peripheralID=1, sessionID=0, peripheralType=21, skillGroupState=4, stateDuration=0, skillGroupNumber=-1, skillGroupID=-1, skillGroupPriority=0, agentstate=TALKING, eventReasonCode=0, MRDid=1, numTasks=0, agentMode=0, maxTaskLimit=0, ICMAgentID=0, agentAvailabilityStatus=1, numFltSkillGroups=0, CTIClientSignature=null, agentID=cyeo, agentExtension=1007, agentInstrument=null, agentID_Long=cyeo, duration=-1, nextAgentState=2} to socket: Socket[addr=172.19.136.80,port=1419,localport=42027] is : 1

Example:


Q & A


37


Documents

BRKDEV-1151