# 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 Point | Geo-location configured in TRouteCall extension | Geo-location configured in Agent | Recording enabled DN | Recording precedence | Geo-location selected (Precedence)
--- | --- | --- | --- | --- | --- | ---
Location1 |  |  |  | Caller | Caller | Location1
Location1 | Location2 |  |  | Caller | Caller | Location2
Location1 | Location2 | Location3 |  | Caller | Caller | Location3
Location1 | Location2 | Location3 | Location4 | Caller | Caller | Location3
| Location2 | Location3 | Location4 | Caller | Caller | Location3
|  | Location3 | Location4 | Caller | Caller | Location3
|  |  | Location4 | Caller | Caller | None
Location1 |  |  |  | Agent | Agent | Location1
Location1 | Location2 |  |  | Agent | Agent | Location2
Location1 | Location2 | Location3 |  | Agent | Agent | Location3
Location1 | Location2 | Location3 | Location4 | Agent | Agent | Location3
| Location2 | Location3 | Location4 | Agent | Agent | Location3
|  | Location3 | Location4 | Agent | Agent | Location3
|  |  | Location4 | Agent | Agent | Location4
Location1 |  |  |  | Caller and Agent | Agent | Location1
Location1 | Location2 |  |  | Caller and Agent | Agent | Location2
Location1 | Location2 | Location3 |  | Caller and Agent | Agent | Location3
Location1 | Location2 | Location3 | Location4 | Caller and Agent | Agent | Location3
| Location2 | Location3 | Location4 | Caller and Agent | Agent | Location3
|  | Location3 | Location4 | Caller and Agent | Agent | Location3
|  |  | Location4 | Caller and Agent | Agent | Location4

Geo-location Selection for Outbound Calls:

Geo-location configured in Agent | Geo-location configured in Routing Point | Geo-location configured in TRouteCall extension | Geo-location configured in Customer (outbound Trunk DN) | Recording enabled DN | Recording precedence | Geo-location selected (Precedence)
--- | --- | --- | --- | --- | --- | ---
Location1 |  |  |  | Agent | Agent | Location1
Location1 | Location2 |  |  | Agent | Agent | Location2
Location1 | Location2 | Location3 |  | Agent | Agent | Location3
Location1 | Location2 | Location3 | Location4 | Agent | Agent | Location3
| Location2 | Location3 | Location4 | Agent | Agent | Location3
|  | Location3 | Location4 | Agent | Agent | Location3
|  |  | Location4 | Agent | Agent | None
Location1 |  |  |  | Customer | Customer | Location1
Location1 | Location2 |  |  | Customer | Customer | Location2
Location1 | Location2 | Location3 |  | Customer | Customer | Location3
Location1 | Location2 | Location3 | Location4 | Customer | Customer | Location3
| Location2 | Location3 | Location4 | Customer | Customer | Location3
|  | Location3 | Location4 | Customer | Customer | Location3
|  |  | Location4 | Customer | Customer | Location4
Location1 |  |  |  | Customer and Agent | Customer | Location1
Location1 | Location2 |  |  | Customer and Agent | Customer | Location2
Location1 | Location2 | Location3 |  | Customer and Agent | Customer | Location3
Location1 | Location2 | Location3 | Location4 | Customer and Agent | Customer | Location3
| Location2 | Location3 | Location4 | Customer and Agent | Customer | Location3
|  | Location3 | Location4 | Customer and Agent | Customer | Location3
|  |  | Location4 | Customer and Agent | Customer | Location4

## 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 name | Description
  --- | ---
  audiosrc | The 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.
  tonesilenceduration | The 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.