A single target destination is always present between the Processor Bridge and its client regardless of the number of active agent sessions or status of the connection to the third-party CTI solution.  The Processor Control destination is used for several key functions:

·       Allows Processor Bridge to convey server status changes, such as server shutdown

·       Allows client to notify Processor Bridge in case of loss of communication with CTI

·       Supports validation of Agent login credentials

·       Retrieval of Agent information

·       Initiation of new Agent Sessions

The control destination for a specific processor bridge instance will always use {Processor_Name}.CONTROL as the target value.  The name of the processor instance is obtained by the processor bridge from the HIS configuration.  The client will need to have its own configuration mechanism to store and retrieve this value.

Control Destination Lifecycle

Unlike the communication targets used to control and monitor CTI resources, the processor control destination set up procedure isn’t strictly defined by the protocol.  The client connects to the server using the configured network interface and port using TLS if enabled.  Initialization is triggered by the client connecting to the server.  The figure below depicts the initialization process:

The bridge begins interacting with the client by sending a request message indicating the client should send out an update on its current status.  The client responds to the request with an acknowledgement and follows it with an event message that contains its current status.

Although this exchange could be handled using a query message with the server status information included in the response, a request is made instead to allow the client to asynchronously deliver its status.  Since the client already sends out changes to its status using the event mechanism, allowing it to leverage the same pattern during initialization reduces the burden on client developers.

A second exchange is made between the bridge and client to finalize setup and initialization.  The bridge sends a query message to the client requesting information about the capabilities of the client’s CTI solution.  The information is returned to the bridge in the query response message.  Once this final exchange is completed, the bridge becomes available and agents can begin to log in.

The connection is gracefully torn down with a request message.  The client must acknowledge the request before disposing of any underlying CTI resources.  One final CTI event is delivered from the client indicating that the processor bridge may terminate communication

Queries & Responses

This section defines the possible query messages the processor bridge may send to the control destination and the format of any expected result messages.  Note that control destination queries and responses contain a "target" header with a value of "{Processor_Name}.CONTROL".

cti.query.capabilities

Retrieves a set of key value pairs that describe the underlying CTI’s capabilities.

Query Headers

Query Body Properties

Response Headers

Response Body Properties

cti.query.agentinfo

Retrieves some basic information about a specific agent.  To ensure security measures can be enforced, the requesting agent’s credentials are provided as part of the query.

Query Headers

Query Body Properties

Response Headers

Response Body Format

{

"switch-agent-id" : "The login id agent uses to authenticate with the switch",

"first-name" : "The agent's first name",

"last-name" : "The agent's last name",

"full-name" : "The agent's full name",

"cti-specific" :

{

Object structure containing any platform specific information about the
agent

}

}

The agent's name can either be provided as a single property "full-name" or divided into two pieces using "first-name" and "last-name" together.  If "full-name" is provided, any values in "first-name" or "last-name" will be ignored.  The contents and format of the cti-specific section is not defined here.  This information will be provided as-is to the client for use in configuration or actionable during screen-pop.

Requests

This section defines the possible requests the processor bridge may make over to the control 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.

cti.request.validateagentcredentials

Confirms the credentials provided for an agent are valid.  Not all CTI platforms support validation of agent credentials without causing side effects such as logging the agent into a station.  If the credentials cannot be validated in a side-effect free manner, a FAILURE should be returned indicating the operation is not supported.

Request Headers

Request Body Properties

Response Headers

Response Properties

cti.request.serverstatus

Requests that the client send its status to the bridge as soon as possible.  This request is part of the control initialization phase.  Although this request can be sent at any time, it will be rarely seen outside the initialization phase, as the client should be sending status updates any time a change occurs.

Request Headers

Request Body Properties

Response Headers

cti.request.createsession

Instructs the client to prepare a new agent session using the destination described in the request message.  The request can occur any time between the initialization and tear down phase of the control destination.

Request Headers

Request Body Properties

Response Headers

cti.request.dispose

Notifies the client that the processor bridge will be ending service 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 Body Properties

Response Headers

Client Events

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

cti.serverstatuschanged

This event is raised any time the client’s ability to service requests has changed or as a result of a server status request message from the processor bridge.  This event may be raised at any point after the initial request during initialization and before the tear down phase.

Event Headers

Event Properties