TCP is used as the foundation for communication between the Processor Bridge and its clients. At its most basic, the Bridge Protocol is simply a specification and framework built to provide asynchronous delivery of messages between a server and a client. The Processor Bridge Protocol defines a set of message formats and guidelines for message delivery and timing.

Message Framing

All messages exchanged between the Processor Bridge server and client are framed to identify the start and end of the message contents. The frame header is a simple 4 byte unsigned integer field that defines the length in bytes of the message contents using UTF-8 encoding.

Protocol Messages

There are four types of messages used in the Processor Bridge Protocol: Requests, Queries, Responses, and Events. The first two are produced by the Processor Bridge and delivered to the client. Requests are used to initiate action on a CTI resource while query message retrieve specific information about a CTI resource. On the client side, responses are generated for each request or query received. The format of the response depends on the original message. The client generates event messages to notify the processor bridge of changes to the underlying CTI state.

All protocol messages share a common format and standard header properties:

{
  "header":
  {
    "type": "cti.query" | "cti.request" | "cti.response" | "cti.event",
    "name": <name of the message>,
    "target": <the CTI resource destination of this message>
  },
  "body":
  {
    <the body of the message is specific to the message type and message name>
  }
}

Two headers are used to indicate the type of message and provide a name for the message.

type	String	cti.query \| cti.request \| cti.response \| cti.event
name	String	Message name can be any string

The "type" header will contain one of the four message type strings shown above. The message name header value can be any string but should be readable and kept short if possible. In the case of response messages, the value of the name header should be the message name from the original query or request message. A third standard message header is used to identify the object the message is targeted towards.

target

String

Dot formatted ID chain of target

The " target" header value contains the dot formatted ID chain of the target object. The ID of each object in the target's hierarchy is appended together, starting with the root session object. A '.' is used as the delimiter between each ID section. This header can be used to quickly and uniquely identify the message target. Request and Query messages include a fourth header that uniquely identifies the Request/Query message.

requestId

String

GUID identifying the Request or Query

Response messages include the "requestId" header from the Request or Query the response is related to. Response messages also contain headers meant to denote the relative success or failure of the originating query or request. If a failure does occur during a query or request, error information is provided in the errorMessage header.

result	String	SUCCESS \| FAILURE
errorMessage	String	Readable message that may be displayed to the agent

For Query responses, the "result" header should have a value of SUCCESS if the information was retrieved, FAILURE otherwise. Since a request simply initiates an action within the CTI but does not wait for it to complete, the "result" header has a slightly different meaning than for query responses. If the request cannot be completed, a FAILURE result is returned. However, if the request can be processed (not necessarily successfully) then a SUCCESS result should be returned immediately.

Event messages don't contain additional headers outside the standard "type", "name", and "target" headers.