# Genesys Quality Management Suite 8.1.520 : The Architecture of the Recording Solution

Call Recording has a multi-level module architecture that supports scaling for optimizing functionality in any environment.

## Modules within Call Recording

There are three basic layers in Call Recording:

- The capture layer where Call Recording captures the signaling and RTP streams.
- The storage layer where the resultant files are stored.
- The management layer has the user interfaces and the Media Lifecycle Management.

The modules within the layers are:

- RMI / AMQP
- Core
- Protocol Adapters
- Recorder Server
- Active Recorder Server
- Decoder Server
- Database
- Web Application ServerRMI

RMI

The Java Remote Method Invocation (RMI) enables remote communication between programs written in the Java programming language.

## AMQP Messaging

The Advanced Message Queuing Protocol (AMQP) provides a robust and secure message queue protocol. The Decoder Server uses AMQP for decoding jobs and the Recorder Server uses AMQP for recording jobs. Using AMQP messages removes the need for direct connections between the modules, reduces the number of threads used and makes communication more resilient to failure.

## Core

The Core is a finite-state machine that controls the Recording solution. It receives information about signaling from different Protocol Adapters through its Protocol Drivers. It manages Recorder servers and Decoder servers; and communicates with the Database, Temporary and Permanent File Systems. The Core provides powerful APIs for third party applications, Auditing System and SNMP for monitoring. It includes an Auditing System that creates a log of the events that occurred in Call Recording.

The log records:

- The start of Calls.
- The start of Couples.
- The start and end of RTP streams.
- Requests to start and end recording to the Recorder server.
- Requests to the Decoder server for decoding.
- Database insertions.
- User log in, call replay, export, deletion.

The log supports installation debugging as well auditing user interaction with the system.

## Protocol Adapters

Protocol Adapters provide the Core with the necessary signaling to determine the next actions (start recording, stop recording and so on).

Adapters and drivers convert native signaling to unified messages to enable the Core to process message flows independently from the signaling protocols that they originate from.

Using drivers and adapters Call Recording supports the following signaling protocols:

- Genesys Platform SDK TLib
- JTAPI
- SCCP
- Avaya JTAPI and DMCC
- Generic SIP

The role of each Driver or Protocol Adapter is to translate any signaling into standard messages for the Core; informing the Core about Call Establishment, the beginning and ending of RTP Streams, transfers, conferences, on-holds, barge calls and so on.

Unified messages allow, for example, the use of Call Recording to record one group of phones by SIP adapter and a second group of phones by CUCM JTAPI within a single system.

No changes have to be made to the Core to support new protocols, which allows faster development and more stability.

## Passive Recorder Server

The Recorder server is fully controlled by the Core and starts or stops saving packets of particular specification (port, IP address) to temporary storage.

For SPAN based recording, the Recorder server is always bound to a particular interface (similar to eth1 on the Linux system) which is automatically turned to promiscuous mode to receive the RTP streams. The interface has to be connected to a switch with a configured SPAN port.

There can be multiple instances of Recorder servers at an unlimited number of locations to support distributed IP telephony recording.

The Recorder server can also, if requested by the Core, forward streams of RTP to a particular IP address and port that is used in live a monitoring console for real-time listening to calls.

## Active Recorder Server

The Recorder server is fully controlled by the Core and starts and stops saving packets of a particular IP address and port to temporary storage.

The Recorder server is always bound to a particular interface, for example, eth0 on the Linux system.

There can be multiple instances of Recorder server at an unlimited number of locations to support distributed IP telephony recording.

The Recorder server can also, if requested by the Core, forward streams of RTP to a particular IP address and port for a monitoring console for real-time listening to calls.

The telephone platform sends streams to the Recorder via, a built-in bridge in the IP phone, or a conference, depending on the platform.

Single NIC deployment is possible, but a dedicated management interface is recommended.

## Temporary Storage

Unprocessed raw data captured by the Recorder Server from the network is stored in the Temporary File System. For every recorded call the Recorder Server stores two files in .pcap format. PCAP files are processed right after a call ends or are cached for later processing if Pre-recording is enabled.

After the recorded call is processed, the temporary data is no longer needed so it is deleted.

If the decoder fails, the temporary data can be processed by the repair utility.

## Decoder Server

The decoder server is used to:

- Sort the saved RTP packets.
- Decode the RTP Packets from G.711 / G.722 / G.729.
- Transcode the streams to uncompressed PCM.
- Create stereo out of two independent channels, calling and called party.
- Encode the audio into WAV or MP3 format of a selected quality.
- Optionally encrypt the recorded files, MP3 only, as WAV encryption is not supported.

## Database

By default Call Recording uses a standard SQL database (PostgreSQL) to which it connects by JDBC driver. The recordings database stores users, groups, recording rules and information about recorded calls. The actual media files themselves are stored in the File Storage system.

The type of database chosen depends on how large the recording needs are and how much evaluation and retrieval of media is needed. For small to medium recording solutions the default PostgreSQL database is perfectly adequate and is the most cost effective way of storing calls screen captures and related data. For larger solutions, with over 50 million call records, Quality Manager and many IOPS (Input/output Operations Per Second) an Oracle database should be considered. The PostgreSQL database is limited to around 200 million call records, above this limit queries are not returned within acceptable limits.

## Web Application Server

Call Recording has a web-based GUI that is used to:

- Configure the system including Media Lifecycle Management
- Manage users and groups.
- Set recording rules.
- Search and replay calls.

The Web GUI runs on an Apache Tomcat Java based application server.

The Web GUI communicates with the Core and with the Database and the Permanent File System.

## Application Communicator

The Application Communicator is the main source of runtime information for the whole recording system.

Monitoring tools such as SNMP communicate with the Application Communicator and periodically or upon request show the status of all components attached.

If any component fails or reports warnings or problems the system can report this via SNMP for further action.

## API

There are Call Recording APIs to:

- Connect custom applications to the call recording software.
- Monitor events and system core objects.
- Reconfigure settings.
- Add custom information to calls.
- Pause and resume both call and screen recording.
- Integrate with third party Java applications.

Core operations are monitored by connecting observers to specific parts of the Call Recording API that subsequently reports core changes.

## Media Lifecycle Management Tools

Regulations mandate the recording of calls in many industries. In some industries these recordings must be retained for many years, resulting in a large amount of data being accumulated. Contact centers record thousands of calls a day. To avoid running out of disk space on the Recording server the data must be managed by archiving, deleting or relocating it.

Calls can be automatically archived and relocated to permanent storage.

These archives can be restored. If a user requests a call that is no longer available on the direct access storage device, the system administrator is instructed to insert the appropriate storage medium. When the call is retrieved and restored, the user is informed by email.

Regular backups of system configuration and settings can be scheduled according to the customer’s backup policy.

The diagram above shows the different Media lifecycles. The difference between Archive and Backup is that Archive marks the file as having been archived and will therefore only archive it once whereas Backup backs everything up even if it has been archived or previously backed up.

Synchro

Calls from multiple locations can be synchronized online to a central replay server for central access and archiving.

The Replay server consolidates recorded calls and user access. The replay server can also provide a centralized Live Monitor application

Call replication to the Replay Server can be scheduled at selected times – during off-peak hours for example.

Users can check the synchronization between the system core server and replay servers using Web Reports

Disk Space Monitor

The disk space monitor displays the current capacity and sends alerts when partitions reach configured capacities.

Users can configure the disk space monitor so that it sends an alert as soon as there is only one month of recording space left in a partition.

## Network and Operational Structure Infrastructure

The network infrastructure includes:

- The type of IP PBX
- The signaling protocols available.
- The type of Gateways that are available.
- The type of Firewalls that are present if any. For example, SBC or SAN.
- Whether the contact center is present.

The Operational Structure includes:

- The number of Geographical Sites to be recorded.
- The Connectivity and Bandwidth between locations.
- How the Teams or Campaigns and Functional Groups to be recorded are organized.