Genesys Quality Management Suite 8.1.520 : Genesys Call Recording Architecture

The Active Recording Ecosystem uses Media Stream Replication (MSR) for a fully Active recording solution with Dual Channel Recording (see the Genesys document Call Recording Solution SIP Server  for more information). SIP sessions to the recorder provide basic call info and voice (RTP) data. MSR is where the Media Server replicates the RTPs and makes them available to the recording server. Additional events and information are provided by the T-Server part of the SIP Server.

Genesys Active Recording Architecture

There are four scenarios that will start call recording. Once the call recording has been initiated, the recording process is the same in all four cases:

  •  The SIP Server initiates call recording (for example, a DN is configured to record all calls).
  •  The Call Recording server requests recording by sending a T-lib request TRequestPrivateService to the SIP Server. The recording server can also use run-time controls for pause, resume, and update.
  • A third party, for example an agent desktop, can request call recording by sending a T-lib request TRequestPrivateService to the SIP Server. The third party can also use run-time controls for pause, resume, and update.
  • A recording can be initiated by a Routing Strategy (extension record=source in TRouteCall).

Supported Versions of the Genesys CIM Platform

Genesys Quality Management Suite provides the following support for Genesys CIM.

Full Support: 7.6, 8.0, 8.1

Limited Support: 7.5

Not Supported: Below 7.5

Definitions for the Types of Support Offered

The Genesys Quality Management Suite technology support level for platforms is defined as follows:

  • Full Support – includes bug fixes, critical enhancement back ports from newer versions. Note:  New features are never back ported.
  • Limited Support – includes critical and blocker fixes only, migration from latest release to the latest version.
  • Not Supported  – no bug fixes, paid upgrade to latest version first.

Genesys Active Recording methods

Full-time recording

Records every call for a specific Directory Number (DN). Setting the option record=true in the DN object instructs the SIP Server to enable full-time recording for this DN. Also Routing Strategy is able to make the decision to record the call. This will record the whole conversation regardless of transfers and conferences.

Selective recording

The decision to record a call is made based on recording rules per conversation. Recording rules may be based on any call related meta data such as:

  • Extension number
  • Agent identification
  • User attached data

Dynamic recording

Recording sessions are established on an as-needed basis after the communication session is established. T-lib recording functions are provided to allow third parties such, as agent desktops, to record on demand.

Supported DN monitoring

From version 8.1.520 and on, the following DN types are supported:

  • Extension
  • ACD Position
  • Voice Treatment Port
  • Trunk Group

Types of T-Server Supported

There are several types of T-Server available, but Call Recording only supports SIP T-Servers.

Active Recording Process

The Call Recording server monitors certain Directory Numbers (DNs) by subscribing to them at the SIP Server. When there is a new call involving a monitored DN, the SIP server informs the Call Recording server about the call using T-Lib.

One of four things can occur to start call recording. No matter what device begins the process, the process is the same.

One of the following initiates recording:

1. The SIP Server initiates recording itself, for example, because a DN is configured in Configuration Manager to always be recorded.

2. The SIP Server informs Call Recording of a call with a DN that Call Recording monitors. Call Recording has a recording rule for the DN. Call Recording evaluates the rule, determines that the DN must be recorded and requests recording by sending a T-lib request TRequestPrivateService to the SIP Server.

3. A third party, for example an agent desktop, requests call recording by sending a T-lib request TRequestPrivateService to the SIP server.

4. A recording can be initiated by a Routing Strategy (extension record=source in TRouteCall).

5. Using media control, the SIP Server invites the Media Server to replicate the RTPs (2 invites one per RTP Stream).
 

The Media Server replicates the RTP streams and:

1. Sends the SIP invite messages to the Call Recording server (2 invite messages, one each per RTP Stream).

2. Sends the RTPs to the Call Recording Server.

3. Recording begins.

4. The Call Recording server requests additional information such as user attached data via T-Lib.
 

5. At any time the Call Recording Server or a third party for example the agent desktop can use a TRequestPrivateService message for pause, resume and stop.
 

6. SIP messages from each stream indicate that the call has ended. The Call Recording Server stops recording.

Multi-tenant Environment Support

There are two different Environments in Configuration Manager

  • The Enterprise Environment  is for companies (also referred to as single-tenants) that own their telephone equipment and use it for their own needs.
  • The Hierarchical Multi-tenant Environment  is for companies (such as service providers) that make their telephone equipment available to other companies.

Enterprise Environment

Call Recording caches information about the DNs, agents, and SIP T-Servers.

Hierarchical Multi-tenant Environment

Multi-tenancy is fully supported on the recording level for calls and screen capture.

In a multi tenancy environment, each tenant has its own T-Servers, DNs, and agents connected to a Configuration Manager. In this structure, all are contained in the Configuration Environment.

In the Hierarchical Multi-tenant Environment, in addition to caching information about the DNs, agents, and SIP T-Servers, Call Recording caches information about the structure that represents the multi tenancy environment from the Configuration Manager and uses meta data to distinguish between the tenants.

Important: If there is no SIP T-Server associated with the switch then Call Recording can't monitor the DNs and therefore no recording can take place.

A single instance of the Call Recording server can handle multiple T-Servers. To identify each tenant separately, Call Recording stores each recorded couple (conversation) with meta data:

  • GEN_CFG_TENANT = X to identify the tenant ID
  • GEN_CFG_SWITCH = Y to identify the switch

Where X is a number that identifies the Tenant and Y is a number that identifies the switch.

Geo-location

Geo-location support provides multi-site deployment with the capability to select specific pools of media servers and recording servers that are located at specific sites. The main motivation for selecting specific media servers is either to minimize WAN traffic or to minimize the latency introduced to a conversation when call recording is enabled.

Geo-location Overview

In a typical scenario, the customer may be calling into a contact center site with a media gateway, and the agent is located in a different site as shown in the diagram.

When both MCP and the recording server are deployed at the data center site, the deployment needs to double the WAN traffic since the media path needs to be bridged through the data center, and this also adds to the latency of the media path by doubling the WAN path.

Minimizing Latency

In order to minimize latency, the geo-location feature is introduced in SIP Server and Resource Manager to allow the MCP to be deployed in a remote site that is close to one party in the call. The diagram shows a deployment that places the MCP in the geo-location=dallas.

Geo-locations for the MCP and Recording Servers are considered separately by the Resource Manager. In the previous diagram, the deployment chooses to not deploy geo-location for the Recording Servers and uses a single pool of Recording Server at the data center. Note that if the deployment chooses to deploy the Recording Servers according to the geo-locations, the same geo-location will be chosen for the same call for both MCP and Recording Server.

Configuration

Configuration of geo-location happens in two places: DN objects in a switch, and Resource Groups for MCP and Recording Servers. Assign a geo-location tag for each DN (of type Trunk DN, Route Point DN, Extension DN, and Trunk Group DN ). The parameter is TServer.geolocation.

To assign a geo-location tag for a Resource Group (for MCP and Recording Server separately), use the Resource Group Wizard and set the geo-location as part of the wizard's process.

Usage

How geo-location is selected for each call depends on the usage model.

SIP Server selects the geo-location with the following order or preference for inbound calls:

1. Geo-location configured in the extensions of RequestRouteCall.

2. Geo-location configured in the Routing Point DN.

3. Geo-location configured in the inbound Trunk DN.

4. Geo-location configured in the DN where the recording is enabled.

For an outbound call, the following order of preference is used:

1. Geo-location configured in the extensions of RequestRouteCall.

2. Geo-location configured in the Routing Point DN.

3. Geo-location configured in the Agent DN.

4. Geo-location configured in the outbound Trunk DN

Full-time Recording

When a DN is configured to be recorded, the geo-location set at the DN is selected. When more than one DN involved in the call has it's geo-location set (in other words, both inbound Trunk DN and the Routing Point DN have geo-location set), then the SIP Server selects the geo-location based on the order of preference listed in the above section.

Selective Recording from a Routing Strategy

If record=source is set in the extension of RequestRoutecall, then the geo-location of the inbound Trunk DN of the call is selected if configured. If record=destination is set in the extension of RequestRouteCall, then the geo-location of the agent (Extension DN) is selected.

Dynamic Recording

When dynamic recording is initiated by the T-lib function RequestPrivateService, either by a 3rd party recording vendor or by Interaction Workspace, the geo-location is selected based on the recorded DN in the call. Specifically:

1. If RequestPrivateService is requested with AttrExtensions as record = source then the geo-location configured for thisDN is selected. If the extension is not defined, record=source is the default value.

2. If RequestPrivateService is requested with AttrExtensions as record = destination then the geo-location configured for otherDN is selected.

Selection Behavior

The following tables illustrate how geo-selection is affected by configuration for inbound and outbound calls.

Geo-location Selection for Inbound Calls:

Geo-location configured in Caller/Customer (Trunk DN)Geo-location configured in Routing PointGeo-location configured in TRouteCall extensionGeo-location configured in AgentRecording enabled DNRecording precedenceGeo-location selected (Precedence)
Location1   CallerCallerLocation1
Location1Location2  CallerCallerLocation2
Location1Location2Location3 CallerCallerLocation3
Location1Location2Location3Location4CallerCallerLocation3
 Location2Location3Location4CallerCallerLocation3
  Location3Location4CallerCallerLocation3
   Location4CallerCallerNone
Location1   AgentAgentLocation1
Location1Location2  AgentAgentLocation2
Location1Location2Location3 AgentAgentLocation3
Location1Location2Location3Location4AgentAgentLocation3
 Location2Location3Location4AgentAgentLocation3
  Location3Location4AgentAgentLocation3
   Location4AgentAgentLocation4
Location1   Caller and AgentAgentLocation1
Location1Location2  Caller and AgentAgentLocation2
Location1Location2Location3 Caller and AgentAgentLocation3
Location1Location2Location3Location4Caller and AgentAgentLocation3
 Location2Location3Location4Caller and AgentAgentLocation3
  Location3Location4Caller and AgentAgentLocation3
   Location4Caller and AgentAgentLocation4

Geo-location Selection for Outbound Calls:

 

Geo-location configured in AgentGeo-location configured in Routing PointGeo-location configured in TRouteCall extensionGeo-location configured in Customer (outbound Trunk DN)Recording enabled DNRecording precedenceGeo-location selected (Precedence)
Location1   AgentAgentLocation1
Location1Location2  AgentAgentLocation2
Location1Location2Location3 AgentAgentLocation3
Location1Location2Location3Location4AgentAgentLocation3
 Location2Location3Location4AgentAgentLocation3
  Location3Location4AgentAgentLocation3
   Location4AgentAgentNone
Location1   CustomerCustomerLocation1
Location1Location2  CustomerCustomerLocation2
Location1Location2Location3 CustomerCustomerLocation3
Location1Location2Location3Location4CustomerCustomerLocation3
 Location2Location3Location4CustomerCustomerLocation3
  Location3Location4CustomerCustomerLocation3
   Location4CustomerCustomerLocation4
Location1   Customer and AgentCustomerLocation1
Location1Location2  Customer and AgentCustomerLocation2
Location1Location2Location3 Customer and AgentCustomerLocation3
Location1Location2Location3Location4Customer and AgentCustomerLocation3
 Location2Location3Location4Customer and AgentCustomerLocation3
  Location3Location4Customer and AgentCustomerLocation3
   Location4Customer and AgentCustomerLocation4


Applying Audio Tones During the Recording

In order to meet the regulatory requirements, some deployments require the system to periodically generate an audio tone to notify the participants in a call that the call is currently being recorded.

Audio tones can be generated either as all-party consent or one-party consent:

  • All-party consent requires that all parties in the call being recorded hear the audio tone periodically.
  • One-party consent only requires one of the parties in the call to hear the audio tone. The consent is configurable on the media server.

When the recording is paused, no audio tone is generated. When the recording is resumed, the audio tone is applied. The following parameters are configurable in the deployment and they follow the same convention used for other parameters that can be applied

to a call recording. These parameters can be set in the following manner in order of precedence:

  • Extensions in RequestPrivateService.
  • IVR Profile for call recording service as service parameters.

    Parameter nameDescription
    audiosrcThe URI of the audio tone. If the URI is set to empty string, or not defined, or resolves to a bad URI, then no audio tone is applied to the call. No other notifications are generated by media server (ie. MSML events) when no audio tone is being applied.
    tonesilencedurationThe length of time between playing the audio tone in milliseconds. This is mandatory if audiosrc is defined, otherwise no audio tone is applied.

The above parameters can be passed as additional parameters in RequestPrivateService (AttrExtensions). For example:

 AttributeExtensions ... 'record' 'source' 'id' '2134980asdf320990adsflkjag' 'dest' 'sip:10.0.0.101' 'name' 'value' 'audiosrc' 'http://example.com/tone.wav' 'tonesilenceduration' '30000' 

Configuration

Media Server enables the behavior of consent to be configurable:

[conference] record_recorddnhearstone – Specifies whether the RecordDN (Party A) hears the repeating tone.

[conference] record_otherdnhearstone – Specifies whether the OtherDN (Party B) hears the repeating tone.

Media Server controls whether the recording gets the audio tone as well. When the audio tone is injected into the call, Media Server now distinguishes between what the participant hears and what the participant says. The above two configuration parameters affect what the participant hears.

[conference] record_chan1source – Specifies the recorded media that represents the first participant (Record DN) in the recording session.

This can either be recorddnsays or otherdnhears. If the Other DN is configured to receive consent and you want the consent to be recorded, set the value to otherdnhears.

[conference] record_chan2source – Specifies the recorded media that represents the second participant (Other DN) in the recording session.

This can either be otherdnsays or recorddnhears. If the Record DN is configured to receive consent and you want the consent to be recorded, set the value to recorddnhears.

Audio Tones for Recording a Conference

When recording a conference, there are two media servers involved in the call; one for recording the recording DN and the other for mixing media for other parties. The audio tone is generated from the recording media server and is propagated to the conferencing media server. In order to ensure all parties get the consent, set [conference] record_recorddnhearstone and [conference] record_otherdnhearstone to true.

Screen Capture

Screen capture can only take place while there is a conversation involving a monitored DN.

Screen captures can be initiated in one of two ways:

Either:

  • The Call Recording Server initiates screen capture because of a recording rule.

Or

  • The agent desktop (or a third party) requests screen capture by sending a TsendEvent via T-Lib to the SIP server. The SIP server then sends an EventUser event via T-Lib to instruct the Call Recording server to start recording.

In either case the Call Recording server sends a request using a control protocol to the Screen Capture Capture Client to capture screens. The capture client starts uploading the captured media to the Call Recording server using a Screen Capture protocol. The Call Recording server processes and stores the media.

Active Recording Live Monitoring

In Live Monitoring it is only possible to monitor calls that are being recorded. If a call shown in the list doesn't show the recording icon, the RTPs have not been replicated, and there won't be audio.