Multiple data center locations

Genesys Interaction Recording (GIR) can be deployed in multiple data center locations.

Before you can deploy GIR in multiple data center locations, you must consider the following:

Recording storage locations

Recording files can be saved in separate storage locations. The location of the recording files is directly related to the location of the agent handling the recording, so that compliance or bandwidth requirements between data centers is met. To enable each data center to record an interaction, each data center must be deployed with its own Media Control Platform (MCP) instance. Consider the following examples:

There are data centers throughout the country where the agents reside, and Genesys server components are located in those data centers. To save network bandwidth between the data centers, all recording files must be stored in the same data center in which the recordings occur. A recording file is only transported to another data center whenever a client requests it for media file playback.
There are data centers in different countries where the agents handle interactions. There are compliance requirements to ensure that interactions arriving in a country are recorded and stored in that country's data center only, and interactions arriving in another country are recorded and stored in that country's data center only. Your deployment model has Interaction Recording Web Services nodes installed in data centers per country.

These examples require that Interaction Recording Web Services nodes be located in each data center with a local storage location. For those locations that do not have local storage configured, a centralized storage location can be used.

In the case of voice recordings, the storage location is determined based on the geo-location set in the SIP Server.

For screen recording, the mapping storage location based on the Interaction Recording Web Services nodes requires no provisioning of the location of the agent, since the connection of the Screen Recording Service to the Interaction Recording Web Services nodes represents the actual location in which the agent resides.

The following diagram is an example of how recording storage can be divided into multiple data centers. When studying this diagram consider the following:

In a system where there is a data center in the same location as the SIP Server and GVP, recording and recording storage are located in the same data center. RWS and the Recording Crypto Server should also be deployed in all of these data centers.
GIR recording can occur in any of these data centers. GIR operates in primary / backup across 2 such data centers. SpeechMiner and GIR components (such as Recording Processor Script and Muxer), are deployed in these data centers.

Configure voice recording storage

To configure the voice recording storage locations, refer to Configuring the Storage Credentials for Interaction Recording Web Services > Enable Storage.

Assign a recording IVR profile

A Recording IVR profile enables you to setup a separate voice recording storage location, per data center location, based on the SIP Server geo-location.
To setup a separate voice recording storage location, perform the steps in the IVR Profile section.

Configure screen recording storage

To configure the screen recording storage locations, refer to Configuration for Screen Recordings > Configuring the Storage Credentials for Interaction Recording Web Services > Step #4 Enable storage for a single or multiple locations.

Recording processing

Each data center where recordings occur must be deployed with at least one Recording Processor Script, to process recordings within the same data center. When the processing is complete, the recording metadata is written to the primary data center for indexing.

The Recording Processor Script is deployed in the primary and backup data centers. SpeechMiner is also deployed in the primary and backup data centers, and these components are active in the primary data center while the backup data center only contains backup instances. Indexing of recording metadata also occurs in the primary data center.

For additional information, see Deploying Recording Processor Script.

The Recording Processor Script should send recording metadata to the SpeechMiner Interaction Receiver in the primary data center according to the IVR Profile configuration above.

Screen Recording processing

The Screen Recording Service (SR Service) is always connected to Interaction Recording Web Services (RWS). This connection occurs from the agent's location to a data center in which the SIP Server and RWS are deployed. This connection manages screen recording and the upload of screen recordings to the recording storage.

The Recording Muxer Script processes screen recordings through the primary data center. Muxer operates in the primary/backup data center and all active instances operate in the primary data center.

If a data center fails and agents need to use the backup data center for continuity of operations, the SR Service must be reconfigured to connect to the Interaction Recording Web Services nodes located in a backup data center. Perform one of the following procedures to reconfigure the SR Service for this purpose. Once the SR Service is configured to connect to that remote data center, the recording files will be transported to the remote data center and saved locally at that data center.

Configure the agent desktop to re-submit the data center server address to the SR Service, specifying the backup data center address.
Update DNS mapping of RWS to specify the backup data center.
Use an HTTP Load Balancer to redirect HTTP requests from the SR Service to the backup data center where RWS is located.

User interface

SpeechMiner works in active/backup mode across data centers.

To enable recordings from multiple data centers to be viewed from a single SpeechMiner user interface, assign a primary data center where SpeechMiner hosts the primary database and index.

Data center index update

Ensure that the indexes are up-to-date in all data centers.

SpeechMiner Index: Configure the Daily Index Backup and write the backup to the backup data center. Whenever the primary data center becomes unavailable, the backup index can be configured to be the primary instance in the backup data center. For additional information, see: SMConfig > Index.

Elasticsearch Index: In the backup data center, write a periodic task (for example, cron job) that will execute the following re-indexing command using HTTP to RWS. It is recommended that you perform this task daily.

POST http://<Interaction Recording Web Services Server>:<Interaction Recording Web Services Port>/api/v2/ops/contact-centers/<contact center ID (in hex format)>/recordings

If you are using screen recording you must also perform a re-indexing command for the screen recording index.

POST http://<Interaction Recording Web Services Server>:<Interaction Recording Web Services Port>/api/v2/ops/contact-centers/<contact center ID (in hex format)>/screen-recordings

For additional information about how to obtain the contact center ID, refer to Configuring Features.

For example:

Using a text editor, create a new file called update_index with the following content:

{
   "operationName":"forceIndex",
   "from":1369272257713,
   "to":1369275857713,
   "purgeOld":false
}

Execute the following command:

{
   curl -u ops:ops -X POST -d @update_index
 http://<Interaction Recording Web Services Server>:<Interaction Recording Web Services Port>/api/v2/ops/contact-centers/<contact center ID (in hex format)>/recordings
 --header "Content-Type: application/json"; echo
}

If you are using screen recordings, you must also execute the following command:

{
   curl -u ops:ops -X POST -d @update_index
 http://<Interaction Recording Web Services Server>:<Interaction Recording Web Services Port>/api/v2/ops/contact-centers/<contact center ID (in hex format)>/screen-recordings
 --header "Content-Type: application/json"; echo
}

Attribute	Type	Mandatory	Description
operationName	String	yes	forceIndex
from	long	yes	Milliseconds since epoch. The starting timestamp from which recordings are indexed and rounded to the nearest hour.
to	long	no	Milliseconds since epoch. The ending timestamp until recordings are indexed and rounded to the nearest hour.
purgeOld	boolean	no	The flag that specifies if the old index should be deleted prior to re-indexing. This is necessary when the updated RWS version needs an index with an updated schema. Default value = false

Due to the rounding of time units in the API, the re-indexing command interval is a minimum of one hour.

Encryption management

When multiple data centers are deployed, you must ensure that the Recording Crypto Server (RCS) keystore file is replicated to all the RCS instances in all the data centers.

To learn how to replicate the RCS keystore file, refer to the Deploying Recording Crypto Server page.

Media lifecycle management

Media Lifecycle Management is location specific and can be configured separately for each data center. Refer to Configuring Media Lifecycle Management to configure multiple regions.

Contents