- Failover and Load Balancing
- Load Balancing
- If a Recorder Fails
- Scalability
- Scalability of the Recording Solution
- High Availability
- The Failover for Two or More Cores
- GVP Configuration steps
- Genesys Active Recording High Availability with Duplication of Recording
- GVP Configuration steps
- Upon failover
This chapter discusses the options/possibilities for failover and high availability for the call recording solution. The scalability of the solution in simple (nonredundant) mode and in High Availability mode is also discussed.
Failover and Load Balancing
This section describes failover and load balancing methods and their implementation.
The RTPs are distributed to one recorder at a time, between recorders in a resource group, using one of the following methods:
- Round Robin
- Least used
In both cases there is only one recorder recording the current session.

In the diagram the dotted lines indicate interconnections. The solid arrows show a particular call being recorded.
Load Balancing
The Resource Manager detects all active recorders in the Logical Resource Group. The Media Server replicates a call's RTPs to an active recorder. The recorder receives the RTPs, records them, and provides the media + meta data to Call Recording Core. The RTPs for the next call will go to another active recorder in the LRG using load balancing.
Call Recording Core consolidates all data relating to each call.
If a Recorder Fails
1. The failed recorder stops responding to pings from Call Recording Core.
2. Call Recording Core detects the failure and requests the SIP to restart the recording.
3. The SIP Server restarts the recording via the Media Server, and the Resource Manager will find an active recorder from an LRG and forward the Media Server request to this recorder.
Call Recording Core consolidates all data relating to the call.
Scalability
This chapter discuss the possibilities to scale the recording solution by adding multiple recording resources in order to provide recording for a large number of simultaneous calls.

In the diagram, the dotted lines indicate interconnections. The solid arrows show a call being recorded.
The Resource Manager detects all active recorders in the Logical Resource Group. The Media Server replicates a call's RTPs to an active recorder. The recorder receives the RTPs, records them and provides the media and meta data to Call Recording Core. The RTPs for the next call will go to another active recorder in the LRG using load balancing.
Each core is only responsible for a range of DNs.
- The core also gets associated metadata (through T-Lib).
- The replay server requests all recordings and metadata and consolidates (assembles and removes duplicates) all data relating to each call.
Scalability of the Recording Solution
For a large deployment, where multiple SIP Servers are configured, each Call Recording Core instance will monitor a separate SIP server instance. Each Call Recording Core will monitor the range of DNs configured by each SIP server.
However, the REC instances are not specifically tied to any range of DNs or SIP servers. All REC instances can accept a recording session from any GVP media server. GVP Resource Manager will treat all of the RECs in an LRG as a single pool of recording servers. Since Resource Manager can place a limit on the number of concurrent recording sessions on each REC instance, Resource Manager can ensure that the RECs are not overloaded.
Whenever an REC receives a recording session, the REC generates pseudo recording events to a Call Recording Core. In this case, REC sends the pseudo recording events to all Call Recording Core instances. When Call Recording Core instance receives such an event for a DN that it is not responsible for, that instance may ignore the event.
High Availability
There are two possible methods of High Availability. The First method leverages the Load Balancing/Failover principle of the Recorder while adding the redundancy of an additional recording Core.

In the diagram the dotted lines indicate interconnections. The solid arrows show a call being recorded.
To provide full redundancy, every DN must be monitored by two different Cores. If there are less than 1200 DNs, then two Cores can monitor all of the DNs. If there are more than 1200 DNs, multiple Cores need to be deployed while monitored ranges must overlap. The DNs monitored by each Call Recording Core must set by configuring the DN activity Detection for each Call Recording Core.
- Each core operates independently, working in active mode.
- There are multiple recorders (two or more) interconnected with every core.
The Resource Manager detects all active recorders in the Logical Resource Group. The Media Server replicates a call's RTPs to an active recorder. The recorder receives the RTPs, records them, and provides the media and meta data to Call Recording Core. The RTPs for the next call will go to another active recorder in the LRG using load balancing. The Replay Server consolidates all data relating to each call.
The Failover for Two or More Cores
1. If one of the Recorders fails, the current recording session is reestablished and sent to the second recorder. Both Cores get the recorded data.
Important: Both cores will attempt to re-establish the recording session since the core detects that the recorder has failed. The end result is that the recording session is re-established, but with the possibility of a duplicate set of intermediate messaging trying to re-establish the recording session.
2. If one of the cores fails, then another core completes the process. Since both recorders provide recordings to all cores it doesn't matter if the first core fails while the first recorder is processing the stream. The stream gets passed to the second core.
3. If there is a failure, some of the recordings may not be available in the first or second database. In some cases, only metadata is available on the first server with no recording, while the complete recording and metadata are available on the second server. In either case all of the recordings get consolidated to the replay server where all of the recordings are available for search and replay.
GVP Configuration steps
1. Make sure that the VP_CallRecordingServer_814 application template is installed.
2. For each Recorder, REC(1) , REC(2)...REC(n), create an application using the application template from above.
3. Create a new Resource Group of recordingserver service type using the Resource Group creation wizard in Genesys Administrator (PROVISIONING >Voice Platform >Resource Groups ).
- Set the load balancing scheme (Round-Robin or Least Used).
- Assign REC(1), REC(2)...REC(n) as the resource access points.
- Set the aor field as the SIP addresses for REC(1), REC(2)...REC(n)
- Remember to set the port-capacity to the number of concurrent calls allowed for REC(1), REC(2)...REC(n).
4. In the default IVR Profile, go to the gvp.service-parameters section in options (create one if it doesn't exist).
Add a parameter
recordingclient.recdest=fixed,sip:rm:port,whererm:portis the address:port of the GVP resource manager.
Important: Note that HA and scalability work independently of each other. You can choose one of the two models mentioned above for handling HA in a large deployment.
Genesys Active Recording High Availability with Duplication of Recording
This HA option provides the best level of redundancy, but requires the most resources, especially on Media Server. This constitutes true redundancy (every conversation is recorded on both call recorders), but is more resource intensive (every recording session creates two pairs of replicated media which increases the load on the Media Server).

In the diagram the dotted lines indicate interconnections. The solid arrows show a call being recorded.
Each Call Recording cluster (Call Recording Core and its associated recorders) is in a different Logical Resource Group (LRG):
The Resource Manager detects all active recorders in each Logical Resource Group. The Media Server replicates a call's RTPs to an active recorder in each LRG. The recorders receive the RTPs, record them, and each provides the media and meta data to its Call Recording Core. The RTPs for the next call will go to another active recorder in each LRG using load balancing.
- There are multiple clusters (two or more) separated as LRG FIRST and LRG SECOND.
- Every core operates independently, working in active mode.
- There are multiple recorders (two or more) interconnected with every core.
- To provide full redundancy, every DN must be monitored by two cores. If there are less than 1200 DNs, then two cores can both monitor all the DNs. If there are more than 1200 DNs, then multiple cores need to be deployed for each monitored range. The DNs monitored by each Call Recording Core must set by configuring the DN activity Detection for each Call Recording Core.
- The GVP media server creates TWO recording sessions (SIP and RTP) for each call being recorded.
- The two recorders (in the diagram LRG FIRST REC (1) and LRG SECOND REC (2)) will receive RTP's simultaneously.
- Since every DN is observed by two different cores, the two Call Recording cores get the available metadata for all of the recorded calls from the SIP Server.
- The replay server requests all recordings and metadata and consolidates (assembles and removes duplicates) from both clusters and all data relating to each call.
GVP Configuration steps
- Make sure the
VP_CallRecordingServer_814application template is installed. - For each Call Recording Core, create an application using the application template from above.
- Create a new Logical Resource Group of the recordingserver service type using the Logical Resource Group creation wizard in Genesys Administrator (PROVISIONING > Voice Platform > Resource Groups). Call this resource group FIRST.
- Set the load balancing scheme (Round-Robin or Least Used).
- Assign LRG FIRST REC(1), REC(2)...REC(n) as the resource access points.
- Set the aor field as the SIP addresses for LRG FIRST REC(1), REC(2)...REC(n).
- Remember to set the port-capacity to the number of concurrent calls allowed for FIRST REC(1), REC(2)...REC(n).
- Create a new Resource Group of the recordingserver service type. Call this resource group SECOND.
- Follow the same steps as above for LRG SECOND.
- In the default IVR Profile, go to the gvp.service-parameters section in options (create one if it doesn't exist).
- Add a parameter
recordingclient.recdest=fixed,sip:rec1:port,whererec1:portis the address:port of REC1 (or one of the addresses of recorders if there are more than one recorders in the FIRST resource group).
Important: Disable Detect recorder Ping in Call Recording Configuration.
Upon failover
1. If one of the recorders fails, the current recording sessions will continue in the other LRG.
2. If one of the cores fails, the other completes the process.
3. If there is a failure, some of the recordings and associated metadata won't be available in the first or second database. All of the recordings get consolidated to the replay server, where all of the recordings are available for search and replay.
Limitation: If there is a failover, there is no guarantee of recording.
Important: Note that HA and scalability work independently of each other. You can choose one of the two models mentioned above for handling HA in a large deployment.