Revision as of 03:55, April 18, 2017 by Sschlich (talk | contribs) (3rd Party Desktop support)
Jump to: navigation, search

Deploying a Remote Agent deployment - GIR Interoperability

Overview

This document outlines the GIR interoperability requirements for supporting SIP Server Remote Agents for specific switches.

In order for GIR to provide product support for the SIP Server Remote Agent Deployments for specific switches, there are a few design guidelines that the deployment must adhere to as outlined in the following sections. Solution team that validates the SIP Server Remote Agent Deployment must also produce a Test Report for GIR interoperability to ensure that the solution will be compatible with GIR.

Quality Management and Interaction Analytics interoperability is TBD.

Scope

The scope of this document applies to deployments that contains only SIP Server and no T-Server. Deployments with T-Server are not included in the scope of this document and is consider not supported by this document.

Deployment Model

In a Remote Agent deployment, agent devices will be managed through a 3rd party switch. SIP Server is responsible for managing the agent login and route calls to agents to the extension DN. The extension DN in this type of model is not going to be the SIP device directly, but rather it is managed by a 3rd party switch. From SIP Server perspective, the 3rd party switch acts just like the device itself, which allows SIP Server to bridge the call through MCP to perform active recording.

In this deployment model, all TEvent generated by SIP Server should work just like a regular SIP Server. As GIR is dependent on ICON DB for collecting party events and attached data, having the full set of TEvents will allow GIR to be compatible with remote agent deployment.

Inbound calls

Inbound calls to SIP Server first arrives on a Trunk DN. The call can be directed to a routing point DN for routing to an agent via the extension DN. To simplify configuration of the contact for extension DN, a softswitch DN can be defined so that all extension DN can share the same configured contact information.

Outbound calls

Outbound contact solution that uses TMakePredictive call against SIP Server will allow SIP Server to record outbound campaigns with agents For manual outbound calls, agents must be using 3rd party call control through WDE/WWE to place outbound calls. Please see Solution Limitation for details.

Recording controls

WDE and WWE have native support for displaying recording indication plus recording controls for dynamic recording.

IVR Recording

IVR Recording is supported in this deployment with Trunk Group DN as IVR (using agent recording method) or with PlayApplication treatments (with VoiceXML recording control).

Screen Recording

Screen recording is compatible for voice calls that are recorded on SIP Server. GIR monitors for any calls that are recorded by SIP Server and can trigger screen recording based on internal rules.

Hot seating support

Hot seating is supported for remote agent deployment for WDE and WWE.

3rd Party Desktop support

While this document focuses on support for WDE and WWE, some customers may want to write custom desktop applications. In order for custom desktop applications to interoperate with GIR screen recording, the desktop must integrate with Screen Recording Service API as outlined in Genesys Interaction Recording API Reference

The following pages in the API documentation are relevant for SRS integration: Client login: https://docs.genesys.com/Documentation/CR/latest/API/Login Client polling: https://docs.genesys.com/Documentation/CR/latest/API/Polling It is important to highlight that custom desktop must handle the following features of SRS:

Function area Feature Description
Login Hot seating Whenever the agent changes place (either during login or after login), the customer desktop must report the DN, Place, Switch to SRS
Login basic authentication Pass user/password during login to SRS
Cross origin resource sharing For web-based desktop
Security CSRF For web-based desktop
Security TLS Custom desktop must support TLS if SRS is configured to use TLS.
Failover site failover Custom desktop must report to SRS when voice is switched over from one data center to another. A site failover usually includes a change of DN/Place/Switch and the address of RWS, and the custom desktop must report the changes to SRS.

Solution Limitation

In an SIP Server Remote Agent deployment, agents have the ability to place calls using 3rd party call control through WDE/WWE, or use the device directly to place calls (1st party call control) Calls that are placed through WDE/WWE with 3rd party call control will be recorded by SIP Server and be accessible by GIR.

Comments or questions about this documentation? Contact us for support!