Redundancy options

Owned by Verba Support
Aug 08, 2013
2 min read

Overview

There are two fundamental functions in the recording system that might need redundancy:

  • Media Repository (MR) redundancy - this can be achieved by deploying two Media Repositories in the solution
  • Recording Server (RS) redundancy - this can be achieved by deploying more than one Recording Servers in the solution

It is important to decide an ambition level for redundancy your organization. For some organizations recording is mission critical, but downtime is acceptable on the media repository.

Redundant deployment topologies

Multiple Media Repositories and the Recording Servers can be connected to each other in the following ways:

  • Recording Servers feeding different Media Repositories
    • this provides both MR redundancy and RS redundancy
    • you essentially deploy two standalone recording systems running in parallel
    • the drawback: configuration, user and extension management must be done separately through the two MRs
  • Recording Servers feeding the same Media Repository
    • this provides RS redundancy
    • this solution is managed as one system centrally from the MR servers
You need to calculate with the fact that different recording technologies provide different redundancy possibilities:
  • passive recording
    • provides a redundancy where all recording servers that get the same traffic all can record it at the same time
    • if one of them fails the others will still have the complete call
  • central / RTP-forking based
    • these solutions (e.g. Cisco, Avaya, IP Trade) can send only to one recorder at a time
    • they offer failover between recorders on a per call basis
    • if one fails during a call, the last part of the call will be lost, but the next call will be recorded by another server

 

Redundant topology example

Let's look at the following example requirements and design a redundant solution based on these:

  • call recording is critical for the organisation, which works in finance sector
  • calls must be stored for 7 years, calls might be provided to regulators within 5 workdays
  • Cisco UCM 8.5 is deployed the customer
  • 200 Cisco desktop phones users and 25 IP Trade turrets are used by the customer

Based on these requirements we make the following assumptions:

  • all phones support the Cisco built-in bridge functionality (should be verified with the customer)
  • multiple recording servers will be needed
  • one media repository server might be enough, but long term storage is important

In this case, the following are recommended:

  • use 1 Verba Media Repository server
    • virtualize the server with VMware, so it can be easily moved to other hardware when it fails (boot image might be in SAN to facilitate this)
    • mount redundant SAN volumes to the virtual server
  • deploy 2 Verba Recording Servers
    • both servers can run both the Cisco and IP Trade central recording engines
    • the Cisco and IP Trade solution shall be configured with both recorders in their recording server list
    • both servers will upload to the Verba Media Repository Server (will buffer locally if the MR is not available)