The processor bridge creates an interaction destination when an interaction is added to a channel.  The destination is used to monitor and control the interaction’s CTI state.  The generic interaction destination is a template for all interaction types.  Each interaction type will have additional messages that can be carried by their respective interaction destination types.

·       Accept/Reject interaction

·       Complete interaction

·       Retrieve interaction data

·       Modify interaction data

As with the processor control destination, the interaction destination follows the same lifecycle of setup, initialization, and tear down.  The following figure depicts the initialization phase of an interaction destination:

It is important to note that with all CTI resource related communication destinations, no event messages should be raised prior to receiving and responding to the initialization query message.

Queries & Responses

This section defines the possible query messages the processor bridge may send to the interaction destination and the format of any expected result messages.

interaction.query.init

This query retrieves information about the interaction’s current state within the CTI.  The response to this query carries a JSON payload describing the current state.

Query Headers

Query Properties

Response Headers

Response JSON

Below is an example of the JSON returned in the response message:

{

"interaction-state" : "INTERACTION_STATE",

"interaction-data" :

{

"DATA_KEY" : "DATA_VALUE",

"DATA_KEY" :

{

"DATA_SUB_KEY" : "DATA_VALUE",

…

},

…

},

Interaction specific structures

}

The interaction state must one of the standard states:

·       ALERTING – Inbound interaction is awaiting acceptance (ringing for telephony interactions)

·       DIALING – Outbound telephony interaction is waiting for other party to answer

·       STARTED – The interaction has been accepted, or the other party has answered in the case of an outbound telephony interaction

·       ENDED – The interaction has ended but has not been marked completed.  All call legs have been released for telephony interactions

·       COMPLETED – The interaction has been marked as completed

The interaction-data object must be present even if no interaction data is provided.  The overall structure of the interaction data object is platform specific, although it should generally have key/value pairs or named sets of key/value pairs.

Special Considerations

There may be additional actions taken by the processor bridge depending on the type of interaction being initialized.  Interaction type specific information and actions are defined in their respective document sections.  Any interaction related events sent to the destination remain in queue until these objects are initialized themselves.  Once this is complete, any waiting events are processed in the order they arrived.

Requests

This section defines the possible requests the processor bridge may make to the interaction destination.  The client will always generate a response message as a result of these requests.  Some requests require the client to perform actions in a particular order.  These constraints will be detailed in the description of the request.

interaction.request.accept

Requests the client accept the interaction and assign it to this agent.  The execution of this request will most likely differ depending on the type of interaction being accepted.

Request Headers

Request Properties

Response Headers

interaction.request.reject

Requests the client rejects the interaction and places it into a state as to allow it to be offered to another available agent.

Request Headers

Request Properties

Response Headers

interaction.request.complete

Requests the client mark this interaction as complete.  Completed is the final stage of an interaction prior to being disposed.

Request Headers

Request Properties

Response Headers

interaction.request.getinteractiondata

This request indicates the client should send an event containing the interaction’s current set of interaction data as soon as possible.

Request Headers

Request Properties

Response Headers

interaction.request.changeinteractiondata

Requests the client update the interaction’s data; placing the given value under the provided key.

Request Headers

Request Body JSON

Below is an example of the JSON sent in the request message:

{

      "interactionData" :

      [

            {

"key" : "DATA_KEY",

"value" : "DATA_VALUE"

                  },

…

]

}

For multi-depth structures, the data.key will be '.' delimited starting at the root key name and having the updated key in the final segment.

Response Headers

interaction.request.setdisposition

Requests the client update the interaction’s disposition.

Request Headers

Request Properties

Response Headers

interaction.request.dispose

Notifies the client that the processor bridge is ready to dispose of the interaction and that any underlying CTI resources should be released.  The actual disposal of resources should be performed after a response is returned.

Request Headers

Request Properties

Response Headers

Client Events

This section describes the possible events the client can send the processor bridge to the interaction destination.  In most cases, these events are unsolicited though may be the indirect result of executing a previously received request message.

interaction.started

This event indicates that the interaction has been accepted and assigned to the agent.  In the case of telephony interactions, this event means the agent has answered an inbound call or the called party has answered the outbound call.

Event Headers

Event Properties

interaction.interactiondatachanged

This event indicates that the interaction’s data has changed.  The event message contains the full set of interaction data in JSON.

Event Headers

Event JSON

Below is an example of the JSON contained in the event message:

{

"interaction-data" :

{

"DATA_KEY" : "DATA_VALUE",

"DATA_KEY" :

{

"DATA_SUB_KEY" : "DATA_VALUE",

…

},

…

},

Interaction specific structures

}

The interaction-data object must be present even if no interaction data is provided.  The overall structure of the interaction data object is platform specific, although it should generally have key/value pairs or named sets of key/value pairs.

interaction.ended

This event indicates that the interaction has ended but is not marked complete.  Although this event is defined at the generic interaction level, it usually only pertains to telephony and Unify callback type interactions.  Multimedia interactions can be marked completed directly from the started state.  However, telephony and Unify callback interactions must reach the ended state before they may be marked complete.  The only exception is that an interaction that is rejected will generate this event regardless of interaction type.

Event Headers

Event Properties

interaction.completed

This event indicates that the interaction has been marked completed.

Event Headers

Event Properties