EX Engage Connector Recording Provider (EXRP)

EX Engage Connector (EXEC) enables Genesys Cloud (GC) recording management, Quality Monitoring (QM) services, and Speech and Text Analytics (STA) functionality for interactions happening in the Engage Contact Centers. Recording injection and STA-enablement in EXEC is implemented by two components:

1. The EX Conversation Provider (EXCP) component gathers the recording and STA metadata for passing it to the EX Recording Provider (EXRP) when a voice interaction ends.
2. The EX Recording Provider (EXRP) component is responsible for the injection of recorded voice calls along with its metadata (from the Engage contact center into the GC EX Organization) using the public EX API as outlined in EX Recording Injection. The EXRP supports an N+1 redundancy model for enhanced reliability.

Important

All GC services relying on the injected voice recordings to work such as QM and STA should be properly configured in the GC EX Org. Please refer the GC documentation for details.

Recording Injection Use Cases for the Engage Contact Centers

Customers with an existing recording solution

EXEC recording injection can be activated in the Engage Contact centers where active recording is used. An active recording solution includes the following components:

• Recording management: Engage GIR solution or a third-party recorder
• Speech Analytics: Engage Genesys Interaction Analytics (GIA)
• Media management: Media Control Platform (MCP)
  • If GIR is used, MCP records voice conversation and passes it to GIR for storing and processing.
  • When used with a third-party recorder, MCP forks the voice stream to the third-party recorder.
• Call recording control: SIP Server controls recording through start/stop/pause/resume commands to the MCP.

Customers without a recording solution

For customers without a recording solution, EXEC can enable GC recording management, QM, and STA services if your Engage Contact Center uses SIP Server and GVP (Genesys Voice Platform).

• To inject recordings into GC using EXEC, you will need to:
  • Expand your MCP farm with additional recording MCPs.
  • Configure SIP Server-based active recording for your agents.

Important

Recording injection should also be configured and enabled to use STA functionality.

GIA Replacement

GC provides state-of-the-art AI-based STA services which delivers capabilities better than GIA. Customers can continue using GIR for compliance recording and replace their existing GIA-based analytics solution with GC STA.

Recording Transcription for the Engage Contact Centers

EXEC deployed in the recording injection mode can request the injected recordings to be processed by the GC STA (Speech and Text Analytics) services. As a result, injected recordings marked to be processed by the GC STA are transcribed, their transcripts are analyzed for the presence of certain topics, emotion trends are identified, and other STA services may also be applied. EXEC inserts the STA Program ID and the recording language into the injected recording metadata to trigger the STA processing on the GC side.

Customers may want to maintain distinct STA programs for different LOBs. Tech Support conversations should be analyzed using one set of topics, while the conversations of the Wealth Advisors may require a completely different set. Also, each LOB can have queues to serve calls in different languages.

EXEC is designed to identify a queue used to deliver a call to an agent (Origination Queue) and add a program ID and a language associated with this queue as metadata properties of a recording injected to GC. If one call is handled by agents from different LOBs who received this call from their corresponding queues, then recording segments produced for those agents will have Program ID and Language properties collected from the corresponding queues, which may not be the same. If a call is delivered to an agent directly without using a queue, then default org program ID and language are used.

Transcription

EXEC reads the following GC configuration to identify the general settings of transcription for GC Organization and its’ queues:

1. Transcription enabled for GC Org - See the Enable voice transcription section in Speech and text analytics.
   • EXEC requests STA for this injected recording only if transcription is enabled in the EX org. If transcription for the org is disabled, STA is not requested for any of the injected recordings.
2. Transcription enabled on Queue - See Configure voice channels subsection under the Set behavior and thresholds for all interaction types in Create and configure queues
   • EXEC requests STA for the injected recording only if transcription is enabled on a queue.

Transcription configuration is pulled from GC by EXEC every 15 minutes.

Program ID

EXEC reads the following GC configuration to identify the program ID associated with the origination queue:

1. Program assigned to Queue - See the Edit a program section in Work with a program.
   • EXEC checks if any program is assigned to a queue. Only one program can be assigned to one queue.
2. Default program - See the Set a default program section in Work with a program.
   • If no program is assigned to a queue, EXEC uses a default org program
3. If no program is identified in any of the previous steps or transcription is disabled for the org or queue, EXEC doesn’t request STA to be performed on the injected recording.

Program configuration is pulled from GC by EXEC every 15 minutes

Language

There are two possible options to configure language, used for transcription:

1. Using Routing Strategies.
2. Setting the default language.

Both options are configured on Engage side by setting corresponding hybrid_integration transaction configuration options.

Routing Strategies

Complex call centers can have multiple departments, using different languages. In order to use specific language for some department, Routing Strategy which is used to route a call to this department, has to be modified. Sending a RequestUpdateUserData should be added to the routing strategy. This request should add a key to call userData to specify the language of the call.

For example:

{"language_code":"de-DE"}

The key, used for language code (“language_code” in the example above), has to be specified as a hybrid_integration transaction parameter sta_userdata_language_key.

Value is a string, containing a language code of the desired language.

A list of supported languages and their codes can be found at Genesys Cloud supported languages under the Native voice transcription section.

Language can be updated several times during the call. There must be only one key specifying the language in the call user data.

Default language

Default language represents the main language, used in the contact center. This language is used if EXEC was not able to get the language configuration from other sources. Default language has to be specified as a hybrid_integration transacton parameter sta_default_language.

EXEC defines language for every recording segment made on behalf of an Agent. The language is defined, when Agent answers the call in the following way:

1. Language is taken from call user data if it’s set from the routing strategy
2. Otherwise, the default language is used from the sta_default_language hybrid_integration parameter.

For recordings made on behalf of a trunk, default language is always used.

Valid language value is a language code of a language, supported by GC. If language value, received from call userData is invalid, default language value is used. If default language value is invalid, STA is not requested for the recording segment.

EXEC Deployment Options for Recording Injection

This section explains how EXEC can be integrated with two different types of the Engage recording solution:

1. Third-party recorder or GIR without GIA
2. GIR with GIA

Those two categories are defined based on the configuration required to integrate the EXEC. In the first case, customers do not use the Engage speech analytics solution. This architecture allows to connect GC STA as a new analytics solution without changing the existing recording processing flow in the contact center. Solutions in the second category use GIA. As a result, GC STA should be brought as a replacement of the existing analytics solution. In most cases, customers can use only one analytics solution at a time (either GIA or GC STA). At the same time, some Engage contact center configurations may allow to use GC STA only for a subset of call recordings when the rest of the calls are still processed in GIA.

Important

Diagrams provided in this section are color-coded: blue indicating a new component or connection and orange for components that require configuration changes. Diagrams show only components that are essential for a particular use case.

Third-party Recorder or GIR without GIA

The following diagram depicts an integration with a third-party recorder. Even though the EXEC integration with the GIR-based solution is slightly different, the required Engage configuration changes are the same in both cases.

In this configuration the existing IVR profile ‘record’ is modified. Based on those changes MCP starts producing recording files in opus format to push those files to EXEC. In case of the third-party recorder, IVR profile is also configured to instruct MCP to push the recording metadata to the EXCP. If GIR-based solution is used, EXCP pulls metadata from the GIR RWS component.

GIR with GIA

If Engage customers use GIA for speech analytics, then GIA should be replaced with the EXEC in the existing IVR Profile 'record' as shown on the diagram below. In this case, MCP stops delivering recordings to the GIA as soon as IVR Profile configuration is changed. Speech analytics can be done only in the GC STA while new configuration is active. Configuration can be rolled back instantly without restart of any components to restore regular GIA-based operations.

Defining Recording Synchronization Scope (Sync-Scope)

Sync-scope refers to a designated portion of your Engage contact center environment configured for injection into the Genesys Cloud EX organization. You define the sync-scope by adding configurations to the Engage CME. If no sync-scope is specified, EXEC syncs your entire Engage environment. Defining a sync-scope is highly recommended, with a smaller scope being ideal for pilot deployments or gradual migrations.

EXEC components, EXAS and EXCP, inject agent and call-related activity only for those belonging to the sync-scope. EXCP then sends a recording injection request to EXRP for all injected calls. Consequently, EXRP also adheres to the defined sync-scope.

Voice recordings to be injected to GC are collected in the EXEC WebDAV transient storage first. Engage solution can be configured to push either all recordings or only the recordings related to the sync-scope calls into the WebDAV storage. In both cases EXRP injects only the sync-scope recordings into GC. So, those two approaches are identical from the end-user perspective. The difference is in the required size of the WebDAV storage. More details about the pros and cons of those configurations are provided in the following sections.

Storing All Engage Recordings in WebDAV

The following diagram depicts an EXEC integration with the Engage contact center where GIA is used for speech analytics (mentioned earlier). In the example, customers select one of their lines of business LOB1 to be synced to GC. As a result, all EXEC modules only inject the data related to the selected LOB1. GIA stops receiving any recordings. So, call center agent and supervisors should log in to GC to use the STA services there instead.

The main advantage of this approach is a simple configuration, which can be used in any Engage deployment. Customers need to replace GIA in their 'record' IVR Profile configuration with the EXEC to redirect the recording files accordingly.

This approach requires EXRP WebDAV transient recording storage to hold all Engage contact center recordings produced in the last 24 hours. In large contact centers, it may require a significant amount of storage and processing power.

Storing Only Engage Sync-Scope Recordings in WebDAV

In certain Engage configurations, you can create a dedicated processing flow for sync-scope calls at the SIP Server level. This allows GC STA and GIA to be used in parallel, with GC STA working with sync-scope calls while all other calls are processed by GIA. Specific Engage configurations allow creating a dedicated processing flow for sync-scope calls at the SIP Server level. This can be implemented in environments using SIP Server geo-locations with the MSML strict matching policy, or potentially other environments.

This approach allows:

• Process sync-scope calls separately from other types of calls. GC STA can analyze sync-scope calls, while GIA handles all other calls.
• WebDAV storage only needs to accommodate recordings from sync-scope calls.

These advantages stem from SIP Server being configured to identify and report sync-scope calls to the GVP (Genesys Voice Platform), a core component of the Engage recording solution. GVP applies a newly created IVR profile to the sync-scope calls and MCP generates Opus recording files only for the sync-scope calls and pushes them to GC EXEC. Processing of all other recordings remains unchanged.

How recording injection works in EX Engage Connector

This section explains the recording injection processing flow in EXEC. The following diagram depicts EXEC integration with the third-party recorder only. Processing flow is mostly the same for the third-party recorder and GIR/GIA integrations. The difference between the two is how EXCP obtains the recording metadata. In the first case, MCP pushes metadata to the EXCP as soon as the recording segment is complete. In the GIR/GIA integration, EXCP pulls metadata from the GIR RWS component when the interaction ends.

[Insert diagram illustrating the processing flow]

Recordings are processed as follows:

1. MCP records an audio file in the opus format covering one segment of a contact center voice call.
2. MCP stores the recorded file to the EXRP WebDAV Transient Recording Storage using a link configured in the recdest2 configuration option.
3. MCP posts the recording metadata to the EXCP via HTTP Load balancer which injects the interaction events into GC.
4. EXCP stores the received metadata to Redis.
5. EXCP detects the end of an interaction and calls the EXRP REST API via HTTP Load Balancer. This interaction-end API is called once for each recorded call segment providing GC-metadata (recording and STA metadata) and the name of the recorded audio file for this segment.
6. EXRP pulls the audio recording file from the WebDAV storage.
7. EXRP encrypts the recording using GC public key which it pulls periodically using GC EX Public API.
8. EXRP creates a ZIP archive, which contains one encrypted audio file and a JSON file with the corresponding GC-metadata.
9. EXRP obtains an S3-pre-signed URL to upload the created archive by calling GC public API.
10. EXRP uploads the ZIP archive to an S3 bucket using the pre-signed upload URL obtained on the previous step.