Interaction Processor Service
- Trip Gilman
This chapter provides a general specification for Interaction Processor type network services. It contains these sections:
Service Overview
An Interaction Processor type service is responsible for managing agent sessions and providing access to its underlying CTI for call control and possibly multimedia functionality. All Interaction Processor services must support each request, response, and event detailed here unless otherwise marked optional. However, they are free to expand on the structures of those messages as well as define new messages.
Service Specific Information
Each registered service has information specific to its service type, vendor, or instance. This information is available through the getServices Core Request or as part of the events produced by the Service Monitor Service.
The "instance-domain" property is used to identify a group of interaction processors running within separate integration platforms that are working together to service the same pool of clients. The set of clients will spread their connections across the platform instances hosting the correct domain. The following information must be provided by all Interaction Processor type services.
{
"vendor", "<vendor-name>",
"version", "<current-version>",
"cti-vendor": "<cti-vendor-name>",
"cti-version": "<cti-version>",
"instance-domain": "<instance-domain>"
}Service Requests and Responses
This section documents the requests that interaction processors must support and the responses that should be returned.
prepareSession
The prepareSession request is used by a client to initialize a new agent session on this interaction processor. The client provides a set of credentials for the agent. After validating the given credentials, the processor creates a new dynamic network resource to represent the agent's session. The resource's unique identifier is included in the response so the client can easily bind to the resource.
The "model" property identifies which call model should be used for the agent session. If this property is missing or blank, the default model will be used. The "override" property determines what will happen if there is already a session underway for the given agent. A value of false will generate a confirmation type response if a session exists. A value of true will forcefully destroy the existing session and create a new one.
It is recommended that clients initially use a value of false for this property and allow the user to decide if they want to destroy the session. If the user requests the session be removed, the client would send a second request with a value of true for the "override" property.
Request
{
"command": "prepareSession",
"data":
{
"model": "<name-of-call-model>",
"override": true | false,
"agent":
{
"id": "<agent-id>",
"password": "<agent-password>"
}
}
}Confirmation Response
{
"command": "prepareSession",
"result": "confirm",
"message": "<confirmation-prompt-text>",
"original":
{
<Contains the original prepareSession request JSON structure>
}
}Success Response
Failure Response
Secondary Events
This request should not generate any secondary service events.
getCapabilities
The getCapabilities request is used by a client to discover the capabilities of this interaction processor.
Request
Success Response
Failure Response
Secondary Events
This request should not generate any secondary service events.
Service Events
The basic interaction processor type service does not generate service events. However, particular implementations may do so.
Â
This document may contain confidential and/or privileged information belonging to OpenMethods. If you are not the intended recipient (or have received this document in error) please notify the sender immediately and destroy this document. Any unauthorized copying, disclosure, or distribution of the material in this document is strictly forbidden.