Deployment Guide 5 8 1.0 English

ZOOM Quality Management Suite
Deployment Guide
AUTHOR
ZOOM International
VERSION
5.8
DATE
August 2016
ZOOM International s.r.o.

Danube House
Karolinsk 650/1, Karln,
186 00 Praha 8,
Czech Republic
Phone: (+420) 222 554 111
ZOOM International
Copyright 2015 ZOOM International. All rights reserved.
ZOOM International provides interaction recording and quality management for Contact
Center and Unified Communications environments focused on Avaya, Cisco, and Genesys
platforms.
ZOOM Quality Management Suite is a solution for compliance and quality management.
It includes interaction recording, screen capture, agent evaluation, live monitoring, e-learning,
voice of the customer, speech analytics and workforce management integration.
Europe, Czech Republic Americas Russia, CIS
Karolinsk 650/1, 186 00 810 Crescent Centre Drive TN Ulitsa Krzhizhanovskogo,

Praha 8, Czech Republic 37067, USA 14 Moscow, Russia
Phone: +420 222 554 111 Phone: +1 888 939 4291 Phone: +7 495 967 9079
Poland, Baltics Middle East Ukraine
Piotrkowska Str 12, Office 808 Dubai Media City, Building 8/55, Petra Sahaidachnoho St,
25-510, Kielce, Poland Dubai, UAE 25, Kiev, Ukraine
Phone: +48 606 476 287 Phone: +971 (50) 443 4881 Phone: +7 495 967 9079
Africa
Turkey APAC
2nd Floor, West Tower Maude
Street, Nelson Mandela Nida Kule, Degirmen Sok.No: Mae Rim, Chiang Mai,
Square, Sandton 2196, South 18/19, Kozyatagi, Istanbul, Turkey 50180, Thailand
Africa Phone: +90 0216 2506513 Phone: +66 8985 20005
Phone: +27 11 881 5496
Australia
44 Market St, Level 26,

Sydney NSW 2000,
Australia
Phone: +61 2 9091 8030
You can always reach us at: sales@zoomint.com

Deployment Guide
This guide is intended for pre-sales engineers, service professionals and technical staff
who are responsible for the complete delivery of the ZOOM Quality Management
deployment. The guide describes how to plan, prepare the contact center platform, install,
and configure the solution in various manners to fit your requirements.
The entire deployment process consists of three main parts:
Planning
Avaya Call Recording Architecture

Cisco Call Recording Architecture
Genesys Call Recording Architecture
Integration with Contact Centers
Hardware Requirements
Ports usage
Supported Call Scenarios for Recording
The Architecture of the Recording Solution
Deployment types
Installation
Prerequisites: Configuration of platform for recording

Installation of OS and QM Suite
Configuration
Single Server Configuration

Multi Server Configuration
3
Planning
When planning your ZOOM Quality Management solution you may make decisions on how
it is deployed to suit your needs
Choose How You Want to Record Your Calls Select Operating System
Avaya Call Recording Architecture CentOS

Cisco Call Recording Architecture RedHat
Genesys Call Recording Architecture 32bit or 64bit
Select a Deployment Architecture Select Database
Single Server Deployment Postgres

Cluster Deployment Oracle
High Availability Deployment
Integrating with Contact Center platform
Sizing
Cisco UCCE
Inputs to Calculate Expected Load, Cisco UCCX
Disk Space and Licenses Genesys
Hardware Virtualization
Planning Hardware Requirements Support of VMware ESX/ESXi 4.1 and

later
4
5
Avaya Call Recording Architecture
ZOOM Quality Management provides active Supported versions and compatibility
recording of the Avaya platform based on
PBX platform: Avaya Communications
Avaya Aura Communications Manager.
Manager 6.0 and above
Avaya Driver is an active driver module in Integration platform: Avaya AE
Call Recording Core that acts as an Services 6.0 and above
interface to the Avaya platform. Hardware (GW) platform: all Media
Gateways supported by Avaya
Additionally, it can integrate with the
The application has been developed and
Genesys contact center platform on top of
tested on Avaya Aura Communications
the Avaya Aura PBX. As a result it can Manager version 6.1. According to the
provide native call recording on Avaya while Avaya documentation the methods and
attaching various contact related metadata interfaces used are compatible with any CM
from Genesys. version 6.0 and up.
Platforms and features not supported
Overview Any Avaya PBX solution based on a

different switching solution than
Avaya Driver allows calls to be Avaya Aura Communications
obtained and processed from the Ava Manager
ya contact center platform Limited integration with CC Elite.
Supports active recording method by
using the Single Step Conference Supported Scenarios
feature (see Recording Principles)
Requires software licenses and hardw ZOOM Quality Management Avaya Driver
supports the following scenarios:
are resources (see Requirements for
Licenses and Resources) Agent to Agent (basic call with logged
Provides selected external data from agents on both sides)
the Avaya platform Basic call (internal without logged
Sizing implications limit the number of agent)
messages which can be handled by Call Hold
the infrastructure Blind Transfer
Consultative transfer
Ad hoc conference (blind)
Prerequisites Ad hoc conference (consultative)
Preparing Avaya platform for Active
Supported Voice Codecs
Recording
The virtual recording devices support this
Configuration voice codecs:
Configuring Avaya Driver G.711 ulaw
G.711 Alaw
G.729
G.729 Annex A
Codecs are offered for codec handshake
upon registration in this order.
6
While using G.711, there is a
limitation of maximum packet size of
Decoder module is able to process.
Maximum supported packets
aggregation is 4 frames per packet.
7
Avaya Active Recording
This section contains a high level description of how QM Suite Avaya Active Recording works:
Avaya Driver
Recording Principles
Requirements for Licenses and Resources
8
Avaya Driver
Avaya Driver allows users to obtain and process calls from the Avaya contact center platform.
It sits between the Avaya telephone exchange and the Call Recording Core module and
transforms events about calls into Call Recording internal objects. These objects are
processed by various Call Recording modules (the calls are recorded, decoded, encrypted,
and saved to the database).
Avaya Driver communicates with the Avaya platform using: JTAPI to handle signaling events
about calls (to observe terminals and calls) and the AES server (request and response
services) to deal with device media or to get additional call information (DMCC to create
virtual phone and capture voice conversations).
9
Recording Principles
Single Step Conference
Registering a Pool of Recorders
Detecting Terminal Activity
Single Step Conference
Call Recording monitors phone activity. The Avaya Application Enablement Services server
(AES server) informs Call Recording of any calls in progress and requests that the recorder's
virtual device is added to a single step conference allowing the recorder to receive the RTP
stream.
When a call occurs to a monitored extension (terminal). The AES Server notifies the Call
Recording server about the call with a JTAPI Established Call event.
10
The Call Recording server requests that its virtual phone (recorder) is added to the
conversation.
11
The CM server establishes a single step conference including the caller, the called number,
and the virtual phone recorder.
The recording ends when instructed to do so by Call Recording, or ends automatically when
the entire call ends.
Registering a Pool of Recorders
Call Recording uses the Application Enablement Services (AES) and Device Media and Call
Control (DMCC) Services, to register a pool of standalone recording devices (a recorder
group) in Client media mode with the dependency mode Main. The Client media mode
means that Call Recording handles the media streams from the DMCC device. The Main
dependency mode means that the recorder can receive calls and listen.
During registration Call Recording sets the following:
The RTP IP address
The port number
The codec
The encryption settings
These settings are used to send the media stream to the recorder.
Detecting Terminal Activity
Call Recording uses the AES server DMCC service to add a call control listener to monitor the
target extension for Established Call events. Whenever the extension joins a call an
12
Established Call event occurs, which triggers Call Recording to use the Single Step
Conferencing method to add a recorder to the call as a virtual phone. Call Recording receives
the calls aggregated RTP media stream via the Media Gateway and records the call.
13
Requirements for Licenses and Resources
Requirements for Licenses and Resources apply for the deployment of ZOOM Quality
Management and the Avaya platform.
TSAPI and DMCC License Consumption
Avaya provides licenses for TSAPI and DMCC. It is necessary to have licenses in order to
have the ability to record and monitor calls. The ZOOM Quality Management Avaya Driver
consumes the following licenses:
DMC Basic License
One license for every recorded call to create a virtual phone and capture voice
conversations (which is consumed and released on demand in runtime).
TSAPI Basic License
One license for every monitored terminal (which is consumed when the driver starts and
is released on shutdown).
One license for every recorded call (single step conference) (which is consumed and
released on demand in runtime).
For a consultative call an extra DMCC and an extra TSAPI license are required for the
duration of the consultation. If the consultation ends or the consulted party joins the
conference then these extra licenses are released.
TDM Timeslots and MedPro Resources
Calls involving only IP endpoints may also use TDM media, all calls start out in this mode and
are converted to direct IP media when possible. Switching from one media path to another
through the use of IP (or SIP) signaling is often referred to as shuffling, and can be used to
connect IP devices with calls that require TDM media resources, such as managed transfers
to DCP-based extensions.
Each recording device consumes an additional MedPro resource and license.
Example
500 agents to be recorded

Maximum of 200 simultaneous calls to be recorded
The solution is either IP only or it is not necessary to calculate TDM resources
License Type Number of Licenses
TSAPI 700 (500 for Service Observing

+ 200 for Single Step Conference)
DMCC 200 (for Single Step Conference)
MedPro 200 (for Single Step Conference)
DMCC = Device Media Call Control
14
Avaya EPR
This feature is available from QM Suite version 5.6.
This sections describes Avaya Enhanced Passive Recording(EPR) in the QM Suite.

Overview
Supported versions
Next steps
Overview
ZOOM Quality Management provides Enhanced Passive recording via the Avaya platform
based on the Avaya Aura Communication Manager. This method uses the Avaya TASPI
service to retrieve call event messages and connects to the SMS WS to obtain information
about the devices location(IP address). The device information is cached and updated within
a configurable time period. This method of recording doesn't consume licenses on the Avaya
platform during recording in contrast to the Avaya Active Recording method. The RTP stream
is processed by a passive recorder.
Supported versions
PBX platform: Avaya Communications Manager 5.2.1 and above

Integration platform: Avaya AE Services 5.2.1 and above
Hardware (GW) platform: all Media Gateways supported by Avaya
The application has been developed and tested on Avaya Aura Communications Manager
version 6.1. According to the Avaya documentation the methods and interfaces used are
compatible with any CM version from 5.2.1 and above.
15
It is not possible to record analog calls via Avaya EPR.
Next steps
Preparing Avaya for integration

Configure QM Suite
Configuring Avaya Driver for Recording
16
17
External Data from Avaya Platform
ZOOM Quality Management can attach selected metadata that help to identify which agent
handled the call. The meta data depends on which recording method you use:
External data obtained by Avaya Active Recording
External data obtained by Avaya EPR
Avaya Integration with Genesys CIM
External data obtained by Avaya Active Recording
Property Name Description
AVCM_stationName The name administered for this device.
AVCM_callId Holds the call ID (Integer) assigned to the call by the

Communication Manager.
AVCM_universalCallId Holds the Universal Call ID (Long) assigned to the

call by the Communication Manager. The Universal
Call ID is unique on the switch network because it is a
combination of switch network node number, call ID,
and the time stamp for the call. This Universal Call ID
should be used to identify the call on the CMS report.
AVCM_universalCallIdStr Holds the Universal Call ID (String) assigned to the

call by the Communication Manager. The Universal
Call ID is unique on the switch network because it is a
combination of switch network node number, call ID,
and the time stamp for the call. This Universal Call ID
should be used to identify the call on the CMS report.
AVCM_so_active Indicates whether the service which is observing is

active for this device or not.
AVCM_incoming Indicates whether an incoming call is to the requested

device or not.
AVCM_incomingTrunkCall Indicates that an outside call is coming in from a trunk

to the requested device.
AVCM_recordingExtension The extension that has requested the recording.
AVCM_recordingExtensionName The name administered for the station which is

requesting the recording.
AVCM_vdnExtension The extension of the VDN that was used to route the
call here. If the call is not routed through a VDN
extension, then this field is NULL.
AVCM_vdnName the name of the VDN that was used to route the call
here. If the call is not routed through a VDN
extension, then this field is NULL.
18
AVCM_agentLoginId If a call center agent is involved in this call, this field
specifies the login ID of the agent. If there is no agent
involved, then this field is NULL. For recording
scenarios, this agentLoginID is the login ID of the
agent who logged on the recording extension. For
non-recording scenarios, this agentLoginID is the
login ID of the agent who logged on the originating
extension.
AVCM_agentName If a call center agent is involved in a call, this field

specifies the name of the agent. If there is no agent
involved, then this field is NULL. For recording
scenarios, this is the name of the agent who logged
on the recording extension. For non-recording
scenarios, this is the name of the agent who logged
on to the originating extension.
External data obtained by Avaya EPR
Property Name Description
AVCM_tsapiCallID Holds the call ID (Integer) assigned to the call by the

TSAPI.
AVCM_UCID Holds the Universal Call ID (Long) assigned to the call by

TSAPI.
AVCM_conferenceMembers The participants are alphabetically sorted in ascending

order ex: "081654,6011,6012"
Avaya Integration with Genesys CIM
The Genesys Integration Module (GIM) is a basic Genesys CIM integration module that
provides information about agents and other attached data from CIM T-Server to Call
Recording. This attached data can then be used in searches for call recordings.
19
Sizing Implications
ZOOM Quality Management communicates with the Communication Manager by exchanging

messages via the Avaya Application Enablement Service (AES). The number of messages
the infrastructure can handle is limited by several factors:
Number of messages CM can handle
Number of messages AES can handle
Number of CLAN cards installed in the system (= GW limit)
Number of messages single C-LAN card can handle
Connection speed between CM and AES server
Number of communication messages each C-LAN card is able to handle:
On the TN799 DP CLAN Board or when Processor Ethernet is deployed, the Board
Limit is 200 messages per second to the Avaya Communication Manager and 240
messages per second from the Avaya Communication Manager.
In order for an AE Server to support 1000 Messages per Second (mps) it must be
provisioned with at least five CLAN Boards (1000/240=4.2).
In order for an AE Server to support 720 Messages per Second (mps) it must be
provisioned with at least three CLAN Boards (720/240=3).
Number of connections to C-LAN:
C-LAN card is limited to 500 sockets. Different types of communication utilize different
number of sockets.
Avaya best practice states that no more than 250 phones should be connected to it
when another Gateway or adjunct is connected to it.
Another recommendation states not to use more than 600 IP Phones on single system,
using just 3 C-LAN cards.
By doing this you will have spare capacity in case of network failure to a certain C-LAN
or hardware issues, and you may even use C-LAN priorities.
20
Cisco Call Recording Architecture
This section describes the various methods of Cisco recording. List of supported CUCM
versions can be found here - Supported Platforms
Cisco Recording Methods
Passive SPAN Based Recording
Multi-Site Passive Recording
Cisco Enhanced Passive Recording with JTAPI Signaling
Cisco Active Recording with JTAPI
Cisco Selective User Recording
Cisco Active Recording Integrated with UCCE
Active Recording Integrated with UCCX
CUBE Active SIP Recording
Overview
Enabling CUBE Active SIP Recording
Additional topics
Cisco Recording Methods
The oldest method of Cisco recording is Passive SPAN-based Recording. This method is still
an option in the following cases:
Recording during SRST mode (SCCP or SIP sniffer).
Recording on an SIP trunk without active CTI control.
The Passive Recording method relies on the capture of Skinny SCCP signaling. However, it is
incapable of detecting more complicated call scenarios such as conferences.
Passive Recording with JTAPI signaling is an improved version of passive recording. The use
of JTAPI signaling ensures the capture of all the scenarios listed in the Supported Call
Scenarios for recording. It is useful for installations that can't be recorded actively. For
example: installations with phones that don't support silent monitoring. In other words, phones
without built-in bridges.
Active Recording with JTAPI offers the best functionality and reliability on a Cisco platform. It
is recommended whenever possible.
Passive SPAN Based Recording
Passive Recording is an older approach to call recording from an IP PBX. It doesn't require
direct support from the IP PBX and is suitable for situations where another active recording
method cannot be used. This is, for example, the case with Cisco IP phones which do not
support the "Build in Bridge" function. It is also possible in the case where SRST is in place.
The Passive Recording of voice calls means the capture and interpretation of a telephony
signaling protocol and the interpretation of call events based on that information as well as the
capture of voice traffic as it flows between IP endpoints. No direct interaction with a PBX or
with endpoints is necessary. Therefore, you don't need special support on the side of PBX.
Passive Recording works by connecting to the SPAN (Switched Port Analyzer) port. This
allows Call Recording to monitor all network traffic and pick out only the VoIP traffic to record.
Call Recording "sniffs" for signaling and RTP (Real Time Protocol) packets via the SPAN port.
21
These packets are taken directly from the network flow based on the calls header (sender,
recipient, and type of traffic). Call Recording uses a promiscuous network adapter on the
recording server from a SPAN port on a network switch to detect header information.
Since IPT communication happens in real-time, the capture of the packets should also be in
real-time. Captured packets are stored temporarily and processed when the call ends. The
main challenge is the independence of UDP packets used for the transmission of data. As
every packet can use a different path from the sender to the recipient they may arrive out of
sequence.
Therefore, in very wide networks the passive recording system should monitor every possible
route of the packets.
There are two main ways to capture the RTP packets with the SPAN port:
SPAN the VOIP Gateway port for all the inbound and outbound traffic. This offers one
contact point for recording. However, this method can't capture internal, peer-to-peer
(phone to phone) calls since the VOIP traffic is sent directly between the phones and
doesn't flow through the gateway port.
Set up a VLAN (Virtual LAN) and include all phones within it then use a SPAN to
monitor all the phones on that VLAN. This allows the recording of all inbound, outbound,
and internal traffic. Its disadvantage is that not all phones are on the same VLAN at all
times. Therefore, multiple SPANs are often needed.
Multi-Site Passive Recording
In a multi-site deployment for Passive Recording on a Cisco platform (as the signaling is only
available at the SPAN port of each site) you should have a Recording Server on each site.
The media recorded is synchronized to a Replay Server. You can use the Replay Server to
play back the recordings for all sites centrally.
SPAN limitations when using Skinny (SCCP):
SPAN is difficult to configure.
Each site needs its own recorder.
Not all call scenarios may be detected. This is due to the fact that signaling is detected
22
through a Skinny Call Control Protocol (SCCP).
A replay server is needed to listen to calls from remote offices.
Monitoring applications have limited scalability.
No call admission control or region-based codec negotiation.
The use of SPAN puts an extra load on the switches.
Cisco Enhanced Passive Recording with JTAPI Signaling
The active detection of calls through JTAPI is an enhancement on the purely passive method
of recording. A CTI interface provides call events by a CTI. Voice media should be captured
from the network through a SPAN port. The active detection of calls needs interconnection
with a soft switch through the CTI protocol. Direct support on the soft switch is needed to
provide call events.
Advantages of Passive Recording with JTAPI:
Through the use of JTAPI signaling to detect the calls, Call Recording can capture the
RTP streams for more complicated scenarios. For example: Conferences.
Through the use of RSPAN and VLAN, you can direct the RTPs to a switch in another
location.
Disadvantages of Passive Recording with JTAPI:
The use of SPAN ports puts an extra load on the switches since all traffic should be
mirrored.
Branch offices that run Call Manager Express only have Skinny signaling and do not
use JTAPI. Therefore, this limits the call types that can be recorded from these offices.
23
Cisco Active Recording with JTAPI
Active recording captures the call data and call stream through direct connection with the PBX
platform. This means the signaling information can't be lost. Active recording achieves close
to 100% capture reliability. Additionally, other call data contained on the platform can be
captured and stored in Call Recording.
Instead of monitoring the stream directly, as in Passive (SPAN) Recording, the CUCM
controls Active Recording. It identifies the calls to be recorded based on recording profiles.
When a call with a valid recording profile is detected the voice stream is copied directly to the
Call Recording recorder server. When the calls are decoded they are immediately available
within the Call Recording web-based user interface. Cisco also refers to this method as
"phone-based media forking" or "device-based recording". Active Recording through the
CUCM doesn't require the SPAN port to monitor network traffic and identify VoIP traffic.
However, it does require the configuration of system options in the CUCM. Please refer to the
Cisco Unified Communications Manager Features and Services Guide for more details.
24
Only Cisco 3G IP phones can be recorded through Active Recording.
For an up-to-date list of all Cisco phones that support Active Recording see Unified CM Silent
Monitoring Recording Supported Device Matrix.
These IP phones must:
Support Active Recording (silent monitoring)
Have their built-in bridge enabled
Have the Automatic Call Recording Enabled option set in their line appearance
Have a valid Recording Profile associated with their line appearance
Have JTAPI signaling
Advantages of using Active Recording:
Active recording is easy to administer
There is no need for each site to have it's own recorder
There is no need for a replay server that only replays remote sites
Active recording is adaptable to your network topology
Because the PBX is aware of recording it can supply notification tones when legal
compliance is required
Active recording doesn't use SPAN ports. Therefore, it frees resources for network
monitoring
Active recording increases reliability and control
Cisco Selective User Recording
Since Release 5.8 ZQM the Cisco User selective Recording feature. In fact, Selective User
Recording represents a variation of Cisco Active Recording with JTAPI described in the
section above. Active recording captures the call data and call stream through direct
connection with the PBX platform. This means the signaling information can't be lost.
Selective User Recording achieves close to 100% reliability in offering to the user to record
and store its call of an particular interest. Additionally, other call data contained on the
platform can be captured and stored in Call Recording. All the data is immediately available
within the ZQM suite for further use.
Also by this method the CUCM controls active recording. It identifies the calls to be offered to
25
the user for recording based on the User Selective recording profiles. When a call with a valid
recording profile is detected and the user press the Record button, the voice stream is copied
directly to the Call Recording recorder server. When the calls are decoded they are
immediately available within the Call Recording web-based user interface. Cisco refers to this
method as "phone-based media forking" or "device-based recording." User Selective
Recording through the CUCM doesn't require the SPAN port to monitor network traffic and
identify VoIP traffic. However, it does require the configuration of system options in the
CUCM. Please refer to the Cisco Unified Communications Manager Features and Services
Guide for more details.
Only Cisco 3G IP phones can be recorded through Selective User Recording.

For an up-to-date list of all Cisco phones that support Active Recording see Unified CM Silent
Monitoring Recording Supported Device Matrix.
In selective user recording, an agent or an IP Phone user may start or stop a recording
session using a softkey or programmable line key. In selective user recording, the call
recording status displays on the Cisco IP phone.
These IP phones must:
Support Active Recording (silent monitoring).
Have their built-in bridge enabled.
Have the Selective Call Recording Enabled option set in their line appearance.
Have a valid Recording Profile associated with their line appearance.
Have JTAPI signaling.
Following is a typical call flow for selective user recording:
A call is received and answered on a line configured for selective recording (picture 1, 1
and 2).
The called party starts the recording session by pressing the Record softkey or
programmable linke key (Picture 1, 3).
Cisco Unified Communications Manager automatically sends two call setup messages
26
to the BiB (Called) device: one to set up the media stream from the called party and the
second to set up the media stream from the calling party ((Picture 1, 4 and 5).
Cisco Unified Communications Manager sends an INVITE to the recorder via SIP trunk
for both calls (Picture 1, 6 and 7).
The recorder accepts both calls and receives two RTP streams from the device BiB.
The phone displays the status of the recording session. The Record key toggles to Stop
Recording.
The typical use case for the Cisco Selective User Recording is a situation within a company
back office or even a Call Center where for any reason it's not necessary to record all
interactions, only those of particular interest are to be recorded. In such situations the
telephony user can trigger the recording start by pressing a softkey or programmable link key.
The user can stop and restart the recording at any time during the call using the Record and
Stop keys. This is particularly useful for PCI DSS compliance, for example.
Such a recorded call is represented within the Call Recording server User Interface as flows.
The part of the call before the recording start is not displayed at all. The recorded part is
displayed as usual. The sections of the call which were not recorded are represented as
silence, and when the recording is resumed it shows up as usual.
Cisco Active Recording Integrated with UCCE
In addition to active recording the integration with UCCE can provide additional
service-related information. For example: Service, Agent, Skill Group, Caller Entered Digits,
User Variables, and Wrapup Data. This is provided through CTI OS protocol.
Active Recording Integrated with UCCX
27
In addition to active recording the integration with UCCE can provide additional
service-related information. For example: Service, Agent, Skill Group, Caller Entered Digits,
User Variables, and Wrapup Data. This is provided through CCX CTI protocol.
CUBE Active SIP Recording

Video Telephone Recording is supported from QM Suite version 5.7.
Overview
Active SIP Recording (ASR) is a QM Suite recording method that is based on the dial-peer
forking feature of Cisco Unified Border Element (CUBE). QM Suite is able to record calls and
video forked by CUBE regardless what type of communication manager you use in your
Contact center. The only condition is that the calls and video have to go through the Cisco
CUBE:
28
To record internal calls it is necessary to configure your network so that all internal
calls go through the CUBE
ASR requires configuration on CUBE only there is no need for configuration on the CUCM
side. ASR enables recording of all calls that go through the CUBE and it doesn't need a
JTAPI connection to CUCM, therefore you can record non-JTAPI devices such as Cisco
Jabber client.
The Call Recording server accepts all recording sessions based on the pre-configured
recording rules. Any calls that don't match the criteria of the configured call recording rules
are also recorded. Finally, in a situation where no call recording rules have been configured
all calls are recorded.
Enabling CUBE Active SIP Recording
There are two steps necessary to enable the CUBE Active SIP Recording feature:
1. Configure your platform. The steps are described in the section: Configuring CUBE for
Active SIP Recording
2. Configure your QM Suite: Single Server Configuration
List of supported calls scenarios can be found here - Supported Call Scenarios for Recording
Additional topics
Advanced protocol security

MediaSense integration module
CDR Service
29
Advanced protocol security
Overview
Enabling advanced protocol security
Configuration prerequisites
Secure communication in QM Suite
Overview
Working in conjunction with Cisco Unified Communications Manager (CUCM) QM Suite offers
the capability of recording encrypted calls. This allows customers to maintain call security and
compliance with the Payment Card Industry Data Security Standard (PCI DSS).
QM Suite supports the following technologies:
Secure JTAPI
Secure SIP
Secure SRTP
Call recording is established using the highest security level as determined by the capabilities
of the device that is being recorded regardless of the security status of the recorded calls.
QM Suite also supports SRTP Fallback to Non-secure RTP. Thus, if phones don't support
SRTP but recording is set up to use it QM Suite can fall back to non-secure RTP.
Enabling advanced protocol security
Certain configuration steps are required on both CUCM and QM Suite to enable secured
communication.
Configuring CUCM for secure JTAPI

Configuring CUCM for SRTP
30
Secure communication in QM Suite
1. Enabling secure JTAPI

2. Enabling SRTP
3. Certificate management tool
31
MediaSense integration module
In version QM Suite 5.3 and above you can take advantage of using QM Suite features on top
of the Cisco MediaSense recording platform. Integration is provided through the Cisco
MediaSense API and enables the retrieval and storage of MediaSense sessions and media
files on the QM Suite server.
High-level platform architecture
The following chart depicts the call flow from Cisco MediaSense to the QM Suite MediaSense
Integration (MSI) module:
Primary features of integrated deployment:

Search & Replay of recorded calls (in Call Recording)
Media Lifecycle Management tools Synchro, Archive, Backup, Delete, Restore, and
Relocation
User Management
Quality Management
E-learning
Speech Analytics
PCI DSS compliance (call encryption)
Unsupported features of integrated deployment:
Live Monitoring
Screen Capture
Prerecording
Voice of the Customer
Integration with the following contact center platforms: Cisco Unified Contact Center
Enterprise and Unified Contact Center Express
32
Limitations
Limited support of Cisco Unified Border Element. For more information contact a ZOOM
representative through the Partner portal.
Detection of complex call scenarios (for example, transfers or conference calls) are not
supported.
Importation of historical data is not yet supported.
Known issues: Troubleshooting the MediaSense integration module - known issues.
MediaSense integration
Certain configuration steps are required on both Cisco Unified Communications Manager
(CUCM) and QM Suite to integrate QM Suite with Cisco MediaSense.
1. Preparing CUCM for MediaSense integration
2. Configuring the MediaSense integration module
33
CDR Service
This section provides an overview of the QM Suite CDR service:

Overview
CDR Service with MSI module
CDR Service with JTAPI
Next steps
Overview
The CDR service is a QM Suite service that processes CDR files provided by CUCM and,
based on the processed data, adds additional information to the call records stored in the QM
Suite database. For deployments that use JTAPI for recording and/or the MediaSense
Integration module the CDR service provides information about who hung up the call first.
CDR Service with MSI module
CDR Service with JTAPI
34
Only one instance can be processed at any given time. If both MediaSense and JTAPI
are used concurrently the CDR service will not provide information. The CDR service is
only capable of processing information provided by one module.
Next steps
Preparing CUCM for CDR Service

Deploy and configure QM Suite
Configuring CDR Service
35
Genesys Call Recording Architecture
Genesys Active Recording Architecture

Supported Versions of the Genesys CIM Platform
Definitions for the Types of Support Offered
Genesys Active Recording methods
Full-time recording
Selective recording
Dynamic recording
Supported DN monitoring
Types of T-Server Supported
Active Recording Process
Multi-tenant Environment Support
Enterprise Environment
Hierarchical Multi-tenant Environment
Geo-location
Geo-location Overview
Minimizing Latency
Configuration
Usage
Full-time Recording
Selective Recording from a Routing Strategy
Dynamic Recording
Selection Behavior
Applying Audio Tones During the Recording
Configuration
Audio Tones for Recording a Conference
Screen Capture
Active Recording Live Monitoring
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.
36
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 TRequestPr
ivateService 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
QM 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 QM 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
37
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 5.2 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.
38
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 initiates 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.
39
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)
6. The Media Server replicates the RTP streams and:

a. Sends the SIP invite messages to the Call Recording server (2 invite messages,
one each per RTP Stream).
b. Sends the RTPs to the Call Recording Server.
c.
40
c. Recording begins.
d. The Call Recording server requests additional information such as user attached
data via T-Lib.
7. 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.
8. 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 the 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.
41
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
42
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.
43
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.
44
Minimizing Latency
In order to minimize latency the geo-location feature is introduced in the 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.
45
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 Geo-location Geo-location Geo-location Recording Recording Geo-locat

configured in configured configured configured enabled precedence selected
Caller/Customer in Routing in in Agent DN (Preceden
(Trunk DN) Point TRouteCall
extension
Location1 Caller Caller Location1
Location1 Location2 Caller Caller Location2
Location1 Location2 Location3 Caller Caller Location3
46
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
Location1 Caller and Agent Location1

Agent
Location1 Location2 Caller and Agent Location2

Agent
Location1 Location2 Location3 Caller and Agent Location3

Agent
Location1 Location2 Location3 Location4 Caller and Agent Location3

Agent
Location2 Location3 Location4 Caller and Agent Location3

Agent
Location3 Location4 Caller and Agent Location3

Agent
Location4 Caller and Agent Location4

Agent
Geo-location Selection for Outbound Calls:
Geo-location Geo-location Geo-location Geo-location Recording Recording Geo-location

configured configured configured configured enabled precedence selected
in Agent in Routing in in Customer DN (Precedence)
Point TRouteCall (outbound
extension Trunk DN)
47
Location1 Location2 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

and Agent

and Agent

and Agent
Location1 Location2 Location3 Location4 Customer Customer Location3

and Agent

and Agent

and Agent

and Agent
Applying Audio Tones During the Recording
In order to meet 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
48
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
49
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.
50
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.
51
Alternative Genesys Recording Methods
Genesys Active Recording with CIM and Enhanced Passive Methods

Active Recording of CUCM Integrated with Genesys CIM
Enhanced Passive Recording EPR with Genesys CIM
Genesys Active Recording with CIM and Enhanced Passive Methods
Although Active Recording is the preferred recording method when integrating with Genesys
other techniques can also be used successfully.
Genesys Enhanced Passive Recording works by capturing SIP signaling protocol and RTP
streams and integrating the Genesys T-Server and Configuration Manager to get additional
data about the calls.
Call Recording also provides direct support of Cisco Unified Communications Manager
(CUCM) as a third-party PBX on the Genesys Customer Interaction Management Platform
(CIM).
Finally, Genesys also supports recording via Stream Manager to create WAV files that can
then be obtained by a third-party. However, Call Recording does not support this method
because it severely limits product functionality such as live monitoring and provides no
guarantee that the call will be recorded.
Active Recording of CUCM Integrated with Genesys CIM
In the Active (device based) recording method, Genesys CIM calls with CUCM, the Genesys
(CIM) is deployed with CUCM as an underlying PBX.
In this scenario the Cisco T-Server also performs integration. In addition to connecting to
CUCM Call Recording directly communicates with the Cisco TServer to get the call related
data which is not available from the Cisco platform.
52
Enhanced Passive Recording EPR with Genesys CIM
The EPR method on the Genesys SIP Server tracks the SIP signaling protocol.
The Call Recording server monitors the SIP signaling and extracts information about calls
currently in progress. This includes the terminal addresses of the parties involved in the call,
and as a result, the recording server captures the RTP streams. Through the T-Library Call
Recording integrates with the SIP TServer to retrieve data about agents, their interactions,
and any attached data.
This method is highly dependent on the network infrastructure.
53
Genesys Active Recording Failover, Scalability and High Availability
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
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.
54
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.
4. Call Recording Core consolidates all data relating to the call.
Scalability
This chapter discuss the possibilities to scale the recording solution by adding multiple
55
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.
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 a 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 a Call Recording Core instance receives such an event for a
DN that it is not responsible for it may ignore the event.
High Availability
56
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 while working in active mode.
There are multiple recorders (two or more) interconnected with every core.
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.
57
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.
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 R
EC(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, where rm:port is 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).
58
In the diagram the dotted lines indicate interconnections. The solid arrows show a call being
recorded.
Each Call Recording cluster (Call RecordingCore 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.
Make sure the VP_CallRecordingServer_814 application template is installed.

For each Call Recording Core, create an application using the application template from
59
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, where r
ec1:port is the address:port of REC1 (or one of the addresses of recorders if there
are more than one recorders in the FIRST resource group).
Add a parameter recordingclient.recdest2=fixed,sip:rec2:port, where
rec2:port is the address:port of REC2 (or one of the addresses of recorders if there
are more than one recorders in the SECOND resource group).
Important: Disable Detect recorder Ping in Call RecordingConfiguration.
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.
60
Integration with Contact Centers
ZOOM Quality Management supports direct integration with
your contact center platform Cisco UCCE, Cisco UCCX and Why are
Genesys. The contact center integration feature offers integrations so
additional value by attaching customer related metadata to powerful
By default ZOOM
recorded conversations and supports the tight integration of
Quality Management
contact center user databases with ZOOM Quality
protocol drivers can
Management. As a result, contact center users (quality
record only the
managers, supervisors, agents) can easily access and work
information which
with recorded conversations, search and replay them, provide
PBX interchanges
evaluations, reports and statistics.
with the endpoints.
Using this integration feature ZOOM Quality For contact centers it
Management provides access to platform specific call is essential to have
data. Data are saved to the ZOOM Quality Management (Call far more data
Recording) external data table and can be configured according available and
to your needs. Three sets of external data are available: attached to the
conversations.
Basic Call-Related Data
Call-Related User Data
Agent-Related Configuration Data
For each call, the following external data are indicated:
Who handled the contact: Agent ID, Agent Name
The selected skill group to which the call will be routed
Which Service has been requested by the customer
Additional call related properties: Call Variables, Wrapupp
data, Entered digits
Other call identification properties: Call ID, ANI, DNIS,
Peripheral IDs
Integration Module enables a connection between ZOOM
Quality Management and your contact center platform.
Choose your contact center platform:
Cisco UCCX
Cisco UCCE
Genesys
AVAYA
61
Integrating UCCE with QM Suite
General Steps for Integrating with UCCE

Call Recording UCCE Integration Overview
UCCE External Data Handling
ECC Variables
Named Variables
Named Arrays
Agent Related Data
List of All Available Attached Data by UCCE IM
Supported Call Scenarios to Obtain External Data from UCCE
Supported Deployments
This chapter describes integration between Cisco Unified Contact Center Enterprise (UCCE)
and QM Suite. The Cisco UCCE Integration Module is a tool which enables contact center
users to gather all contact related data together with recorded conversations. The tool
enables contact center users to employ this data for additional categorization, selection for
evaluation, or to simply search according to those metadata.
General Steps for Integrating with UCCE
1. General Overview Integrating UCCE with QM Suite

2. Preparing UCCE platform for Integration with QM Integration: UCCE
3. Installation: Select UCCE IM Service during ZQM configuration and configure the
module Single Server Configuration
4. Perform advanced configuration of UCCE Integration Module: Configuring UCCE IM
Call Recording UCCE Integration Overview
The Integration Module is a connector between Call Recording and Cisco UCC Enterprise. Its
connection with Cisco UCCE is based on CTI communication protocol, which provides the
possibility to implement the methods and functions needed to create CTI-enabled client
applications for the UCCE.
To achieve higher backwards compatibility, CTI protocol version 10 is used.
A connection with Call Recording is implemented using Call Recording API. The recording
method must be set to record through the JTAPI adapter, as the lookup of information in both
systems (Call Recording, Cisco UCCE) leverages call identification (GlobalCallID), which is
available in Call Recording only through Cisco JTAPI.
UCCE External Data Handling
The Cisco UCCE Integration Module is designed to enable contact center users to gather
complete contact related data together with recorded conversations and to use these data for
additional categorization, evaluation, or to simply search through the external data received.
All data received from UCCE such as agent name, login ID, skills etc. are called external data.
You can specify what external data should be saved into Call Recording according to your
business needs. Some pre-defined data is available by default. There are three basic classes
of information available:
62
Basic call-related data these are events like answering calls, transferring calls,
hanging up, and so on.
Call-related user data information about the specific user who initiated the call.
Agent-related configuration agent related information such as name, login ID, skills
Specific data is available depending on the system configuration, routing design, network
topology and on other conditions.
Basic call-related data are available from real-time events generated when a CTI Server
notifies a client of call-based activity. These events arise when observed phones perform
actions like answering a call, transferring a call or hanging up, and so on. These events are a
source of essential information about agent activity.
The data are stored using the following naming convention:
External data key: CCE_<FieldName>
Example: CCE_CallID
ECC Variables
Expanded Call Context (ECC) variables are variables that you can define and enable in the
Configuration Manager to store values associated with specific calls. You can specify the
variable name and data type. The name must begin with the string user. These are in addition
to the variables the ICM software defines for each call (PeripheralVariable1 through
PeripheralVariable10, CallerEnteredDigits, CallingLineID, etc.).
Attaching of ECC variables may be enabled or disabled in the IM configuration, see External
Data Settings for details. By default the IM will always attach all the ECC variables. Please
note these variables may be also changed during the wrapup period.
The ECC Variables may appear as Named Variables or Named Arrays:
Named Variables
Named Variables represent call-related variable data that has a scalar variable. For example:
NamedVar[Test]: This is a test
NamedVar[Another]: This is another test
In this case Test is the key name and This is a test is its value. The Integration Module will
prefix the key name with its identifier:
CCE_ECC_<NamedVar>
The example above will then get saved as following KVPs:
CCE_ECC_Test = This is a test
CCE_ECC_Another = This is another test
Named Arrays
Named Arrays represent call-related variable data that have array variables. For example:
NamedArray[0, Test]: first
NamedArray[1, Test]: second
NamedArray[2, Test]: third
NamedArray[3, Test]: fourth
63
In this case Test is the key name and the array has four fields. The Integration Module will
prefix the key name with its identifier and array index:
CCE_ECC_<NamedVar><Index>
The example above is then saved as the following KVPs:
CCE_ECC_Test0 = first
CCE_ECC_Test1 = second
CCE_ECC_Test2 = third
CCE_ECC_Test3 = fourth
Agent Related Data
Agent related information such as name, login ID, skills etc. are unfortunately not available
directly from the CTI Server and therefore those details are retrieved from the AWDB
database and cached in the Integration Module.
The data are stored using the following naming convention:
External data key: CCE_CFG_<FieldName>
Example: CCE_CFG_LoginName
When there is a call between two agents, the first agent (the one who INITIATED the call) is
identified as above, while the other agent (the one who RECEIVED the call) is identified as
follows:
External data key: CCE_CFG_OTHER_<FieldName>
Example: CCE_CFG_OTHER_LoginName
List of All Available Attached Data by UCCE IM
The following table is a summarized list of all available External Data that may be created by
the Integration Module and whether they shall be attached to the call by default.
Name Key Name Source
Agent ID CCE_AgentID AGENT_STATE_EVENT/AgentID

AGENT_STATE_EVENT/ICMAgentID
Other CCE_OTHER_AgentID AGENT_STATE_EVENT/AgentID

Agent ID AGENT_STATE_EVENT/ICMAgentID
Peripheral CCE_PeripheralID BEGIN_CALL_EVENT /PeripheralID

ID CALL_DATA_UPDATE_EVENT/PeripheralID
Peripheral CCE_PeripheralType BEGIN_CALL_EVENT/PeripheralType

Type CALL_DATA_UPDATE_EVENT/PeripheralType
Call Type CCE_CallType BEGIN_CALL_EVENT/CallType

CALL_DATA_UPDATE_EVENT/CallType
Connection CCE_ConnectionCallID BEGIN_CALL_EVENT/ConnectionCallID

Call ID CALL_DATA_UPDATE_EVENT/ConnectionCal
ANI CCE_ANI BEGIN_CALL_EVENT/ANI

CALL_DATA_UPDATE_EVENT/ANI
64
DNIS CCE_DNIS BEGIN_CALL_EVENT/DNIS
CALL_DATA_UPDATE_EVENT/DNIS
Dialed CCE_DialedNumber BEGIN_CALL_EVENT/DialedNumber

Number CALL_DATA_UPDATE_EVENT/DialedNumber
Caller CCE_CallerEnteredDigits BEGIN_CALL_EVENT/CallerEnteredDigits

Entered CALL_DATA_UPDATE_EVENT/CallerEnteredD
Digits
Router Call CCE_RouterCallKeyDay BEGIN_CALL_EVENT/RouterCallKeyDay

Key Day CALL_DATA_UPDATE_EVENT/RouterCallKeyD
Router Call CCE_RouterCallKeyCallID BEGIN_CALL_EVENT/RouterCallKeyCallID

Key Call ID CALL_DATA_UPDATE_EVENT/RouterCallKeyC
Router Call CCE_RouterCallKeySequenceNumber BEGIN_CALL_EVENT/RouterCallKeySequence

Key CALL_DATA_UPDATE_EVENT/RouterCallKeyS
Sequence
Number
Call CCE_CallVariable1 BEGIN_CALL_EVENT/CallVariable1

Variables CALL_DELIVERED_EVENT/CallVariable1
CALL_DATA_UPDATE_EVENT/CallVariable1







65

Call CCE_CallWrapupData BEGIN_CALL_EVENT/CallWrapupData

Wrapup CALL_DELIVERED_EVENT/CallWrapupData
Data CALL_DATA_UPDATE_EVENT/CallWrapupDa
Expanded CCE_ECC_* BEGIN_CALL_EVENT/[NamedVariable, Named

Call CALL_DELIVERED_EVENT/[NamedVariable, N
Context CALL_DATA_UPDATE/[NamedVariable, Name
Variables
Service CCE_ServiceNumber CALL_DELIVERED_EVENT/ServiceNumber

Number CALL_ORIGINATED_EVENT/ServiceNumber
Service ID CCE_ServiceID CALL_DELIVERED_EVENT/ServiceID

CALL_ORIGINATED_EVENT/ServiceID
Service CCE_CFG_ServicePname t_Service/PeripheralName

Peripheral
Name
Service CCE_CFG_ServiceEname t_Service/EnterpriseName

Enterprise
Name
Skill Group CCE_SkillGroupNumber CALL_ORIGINATED_EVENT/SkillGroupNumbe

Number CALL_DELIVERED_EVENT/SkillGroupNumber
Skill Group CCE_SkillGroupID CALL_ORIGINATED_EVENT/SkillGroupID

ID CALL_DELIVERED_EVENT/SkillGroupID
Skill Group CCE_CFG_SkillGroupPName t_SkillGroup/PeripheralName

Peripheral
Name
Skill Group CCE_CFG_SkillGroupEName t_SkillGroup/EnterpriseName

Enterprise
Name
Agent First CCE_CFG_FirstName t_Person/FirstName

Name
66
Other CCE_CFG_OTHER_FirstName t_Person/FirstName
Agent First
Name
Agent Last CCE_CFG_LastName t_Person/LastName

Name
Other CCE_CFG_OTHER_LastName t_Person/LastName

Agent Last
Name
Agent CCE_CFG_LoginName t_Person/LoginName

Login
Name
Other CCE_CFG_OTHER_LoginName t_Person/LoginName

Agent
Login
Name
Agent Full CCE_CFG_FullName [Assembled by the IM]

Name
Other CCE_CFG_OTHER_FullName [Assembled by the IM]

Agent Full
Name
Agent CCE_CFG_EnterpriseName t_Agent/EnterpriseName

Enterprise
Name
Other CCE_CFG_OTHER_EnterpriseName t_Agent/EnterpriseName

Agent
Enterprise
Name
Supervisor CCE_CFG_SupervisorAgent t_Agent/SupervisorAgent

Agent
Other CCE_CFG_OTHER_SupervisorAgent t_Agent/SupervisorAgent

Supervisor
Agent
Temporary CCE_CFG_TemporaryAgent t_Agent/TemporaryAgent

Agent
Other CCE_CFG_OTHER_TemporaryAgent t_Agent/TemporaryAgent

Temporary
Agent
Supported Call Scenarios to Obtain External Data from UCCE
The following table shows call scenarios for which we can obtain external data.
67
Call Scenario
Agent to Agent (Basic call with logged agents on both sides) Data for calling agent only
Basic call (Internal without logged agent)
Call Hold
Blind Transfer
Consultative Transfer
Blind Conference
Consultative Conference
There are also specific scenarios when UCCE Integration Module behaves differently:
When a single UCCE is connected to two Call Managers and a call is made from one
Call Manager to another QM Suite records two calls but UCCE IM will attach external
data to only one of them.
In complex scenarios for example when a transfer occurs during a conference or an
agent makes a consultative call to a phone from a different CUCM the last part of the
calls might not have UCCE attached data. Please contact us at Partner Portal if you
have such scenarios.
Supported Deployments
There are three main scenarios that are covered by the integration:
Single UCCE connected to a single CUCM
Two (or more) UCCE clusters connected to the same CCM
Two (or more) UCCE clusters connected to different CCMs
68
Integrating UCCX with QM Suite
UCCX List of Available External Data

Overview and Requirements
UCCX to Call Recording Information Exchange
Call Variables and User Data
ECC Variables
Named Variables
Named Arrays
Agent-Related Data
Call Types
Scaling and High Availability
UCCX Compatibility
The UCCX Integration Module is a connector between Call Recording and the third-party
contact center solution Cisco Unified Contact Center Express.
Connection with Cisco UCCX is based on the UCCX CTI communication protocol. This
provides the foundation for the implementation of the methods and functions needed to create
CTI-enabled client applications for this platform. A connection with Call Recording is
implemented through the Call Recording API.
The Integration Module connects to the UCCX server in bridge mode. This ensures that it
receives all agent-state and call events. It also subscribes to UCCX configuration updates for
agents and devices.
UCCX List of Available External Data
This table lists all available External Data that may be created by the Integration Module:
Key Name Original Field Name
CCX_CallID CallID
CCX_CallType CallType
CCX_ANI ANI
CCX_DNIS DNIS
CCX_DialedNumber DialedNumber
CCX_CSQID CSQID
CCX_ApplicationID ApplicationID
CCX_CampaignID CampaignID
CCX_CustomerPhoneNumber CustomerPhoneNumber
CCX_CustomerAccountNumber CustomerAccountNumber
CCX_CallerEnteredDigits CallerEnteredDigits
69
CCX_UserToUserInfo UserToUserInfo
CCX_CallVariable1 CallVariable1
CCX_CallWrapupData CallWrapupData
CCX_ECC_* ECC Variables
CCX_CFG_ AgentType AgentType
CCX_CFG_OTHER_ AgentType
AgentType
CCX_CFG_LoginID LoginID
CCX_CFG_OTHER_LoginID LoginID
CCX_CFG_FirstName FirstName
CCX_CFG_OTHER_FirstName FirstName
CCX_CFG_LastName LastName
CCX_CFG_OTHER_LastName LastName
CCX_CFG_FullName FullName (generated)
CCX_CFG_OTHER_FullName FullName (generated)
CCX_CFG_Extension Extension
CCX_CFG_Extension Extension
Overview and Requirements
70
The Cisco JTAPI recording method is required for UCCX integration, as information lookup in
both systems (UCCX and Call Recording) leverages call identification (GlobalCallID), only
available through Cisco JTAPI.
The UCCX Integration Module supports both Active and Passive recording types.
The following call scenarios are fully supported:
Basic
Hold
Transfer (blind, consult)
Conference (blind, consult)
For CUCM version 9 the UCCX Importer requires more than 2 user and more than 2
group to function correctly, otherwise the import will not occur.
UCCX to Call Recording Information Exchange
The data saved by the Integration Module into the Call Recording external data table is
configurable. There are three basic classes of information available:
Basic call-related data
Call-related user data
Agent-related configuration data
The presence of specific data depends on the system configuration, routing design, network
topology, and other conditions. Configuration of specific properties that are to be stored in the
Call Recording external data table is done during Integration Module implementation.
The data is prefixed by the CCX_ prefix or in some cases by the CCX_<DataType>_ prefix.
For example: AgentID is stored as CCX_AgentID.
See the list of available External Data above for all External Data names.
Basic call-related data are available from real-time events, generated when CTI notifies a
client of call-based activity. These events arise when an observed phone performs an action
such as answering or transferring a call, or hanging up. These events are the source of
essential information about agent activity.
The data are stored through this naming convention:
External data key: CCX_<FieldName>
Example: CCX_CallID
Mandatory call-related data is described below:
Field Name Description
CallID The Call ID value assigned to this call by UCCX.
71
CallType The general classification of the call type. See Call
Types for details.
ANI ANI (Automatic Number Identification), the

telephone number of the caller.
DNIS The DNIS (Dialed Number Identification Service)

provided with the call. In other words, the number
associated with a call on a switch. This can differ
(although infrequently) from the number the caller
dials. This differs if the call is transferred.
DialedNumber The telephone number dialed.
CSQID The Contact Service Queue ID of the call.
ApplicationID The Application ID of the call.
Other (optional) call-related data may also appear:
CampaignID The Campaign ID value. Set this field to

zero if unused.
CustomerPhoneNumber Customer phone number.
CustomerAccountNumber Customer account number.
Call Variables and User Data
Call variables are optional call-related data which an agent or routing script can set up. These
might not be available for all calls.
User data can arrive at a client application with any event at any time, even after the call is
cleared. For example: when an agent fills in wrapup information.
Wrapup data are optional as well, but present (and are required) in most contact centers.
Named variables and named arrays represent a set of optional key-value pairs (KVPs)
created within the IVR routing script.
CallerEnteredDigits The digits entered by the caller in response to

the IVR prompting.
UserToUserInfo The user-to-user information element.
CallVariable1 (through to CallVariable10) Ten fields that contain call-related variable

data.
CallWrapupData Call-related wrapup data.
Tip: CallVariable1 through CallVariable10 is only saved if there is a value.
72
ECC Variables
From Cisco documentation:

"Enterprise Expanded Call Context (ECC) data fields are used by all applications in the Cisco
UCCX Cluster. There can be as many as 200 userdefined fields defined in the Field List
(index numbers 0-199) of expanded call variables. These field values do not appear in the
ContactCallDetail records as there are no fields reserved for them."
ECC variables are defined within the CRA Script Editor. Internally in the protocol they are
represented as NamedVariable and NamedArray fields.
The attachment of ECC variables can be disabled in the Integration Module configuration.
See the configuration section for details.
Named Variables
Named Variables represent call-related variable data that have a scalar variable. For
example:
NamedVar[Test]: This is a test
NamedVar[Another]: This is another test
In this case, Test is the key name and This is a test is its value. The Integration
Module prefixes the key name with its identifier:
CCX_ECC_<NamedVar>
The above is then saved as these key value pairs (KPVs):

CCX_ECC_Test = "This is a test"
CCX_ECC_Another = "This is another test"
Named Arrays
Named Arrays represent call-related variable data that have an array variable. For example:
NamedArray[0, Test]: first
NamedArray[1, Test]: second
NamedArray[2, Test]: third
NamedArray[3, Test]: fourth
In this case, Test is the key name and the array has four fields. The Integration Module
prefixes the key name with its identifier and array index:
CCX_ECC_<NamedVar><Index>
The above is then saved as the following KVPs:

CCX_ECC_Test0 = "first"
CCX_ECC_Test1 = "second"
CCX_ECC_Test2 = "third"
CCX_ECC_Test3 = "fourth"
73
Agent-Related Data
Agent-related information such as name, login ID and skills are usually available from a
separate data source either from a database or from a configuration-related API. Cisco
UCCX provides this information in Agent State messages. When it processes these
messages, the Integration Module can create a list of available agents and their detailed user
data.
See the agent-related data table below for a list of required information fields that are stored
with every call. Note that some fields (such as FullName) are unavailable from UCCX and
are created from the other existing fields.
The data are stored through these naming conventions:
External data key: CCX_CFG_<FieldName>
Example: CCX_CFG_LOGIN_ID
When there is a call between two agents, the first agent (the call initiator) is identified as
above, while the other agent (the call recipient) is identified as follows:
External data key: CCX_CFG_OTHER_<FieldName>
Example: CCX_CFG_OTHER_LoginID
AgentType 1: Agent
2: Supervisor
LoginID The agents Unified CCX Login ID.
FirstName The agents first name.
LastName The agents last name.
FullName The agents full name. Created by IM from FirstName

and LastName. Order and form are configurable (same
method as in Genesys IM).
Extension The agents phone extension number.
Tip: The string representation of the AgentType is saved.

Important: The agent's FullName assembly method is configurable. If disabled in
configuration, no external data will be created (CCX_CFG_FullName and
CCX_CFG_OTHER_FullName).
Call Types
Cisco UCCX recognizes several types of conversation based on how the call has been
established. The Integration Module provides this info in the CallType variable.
This table lists the available call types:
74
CallType Value Description
CALLTYPE_INVALID The call type is not valid.
CALLTYPE_CCX_IN Inbound UCCX call.
CALLTYPE _TRANSFER_IN Transferred inbound call.
CALLTYPE _OTHER_IN Inbound call.
CALLTYPE _OUT Outbound call.
CALLTYPE _AGENT_INSIDE Agent inside call.
CALLTYPE _CONSULT Consult call.
CALLTYPE _CONFERENCE Conference call.
CALLTYPE_PREVIEW Call is an outbound preview

call.
CALLTYPE_RESERVATION Call is an outbound reservation

call.
CALLTYPE_ASSIST Call to supervisor for

assistance.
CALLTYPE_EMERGENCY Emergency call.
CALLTYPE_ Supervisor conferenced into

SUPERVISOR_BARGE_IN call.
CALLTYPE_ Supervisor replaces agent on

SUPERVISOR_INTERCEPT call.
Scaling and High Availability
For Cisco UCCX scalability in Single Server deployment and in HA mode please refer to the
vendors documentation. It is fully supported by the UCCX Integration Module.
Cisco UCCX can be run as a two-server cluster in case of a need for high availability. In this
scenario, the Integration Module normally logs into the primary UCCX server first. In case of a
switchover (due to a failure of the primary UCCX ) the Integration Module receives the UCCX
failure event information and the module is immediately directed to the secondary UCCX
server which functions as a backup.
UCCX Compatibility
This table summarizes supported UCCX versions in QMS 5.6 and 5.7.
Fully supported UCCX versions Compatible
10.5 11.0 (only QMS 5.7)
75
10.0
9.0
8.5
76
Integrating Genesys CIM with QM Suite
Active Recording Integration

Genesys Enhanced Passive Recording (EPR)
Genesys Integration Module
Genesys CIM to Call Recording Information Exchange
External Data Available from CIM
Supported Call Scenarios to Obtain External Data from Genesys CIM
Set Genesys Driver Encoding for Attached Data
User Data Configuration
Agent Configuration Data
Extension Data
Other Genesys Driver Data
Notification of Recording
Genesys Customer Interaction Management (CIM) platform supports several underlying
PBXs. Call Recording supports these PBXs for call recording and contact center integration:
Genesys contact center with Genesys SIP Server.
Genesys contact center with Cisco Unified Communications Manager.
Three Call Recording services are available for Genesys integration: GIM, EPR and MSR.
Each service provides the same data.
Active Recording Integration
Genesys Driver has a T-Lib Client that handles all communication via TLib. It also handles
communication with the Configuration Server.
Call Recording caches information from the Configuration Manager. This includes the list of
agents, devices, and other such information. You can configure this to be done at regular
intervals.
Genesys Enhanced Passive Recording (EPR)
77
EPR is a combination of active signaling capture and passive voice capture, often referred to
as hybrid recording. It uses the Voice Monitoring API, which is a part of the Genesys SDK
Platform.
EPR provides a much more stable and reliable method of call recording on the Genesys
platform than the older GIM. Since all phone and agent-based events are received over the
API, there is no risk that some important information will be lost due to a lost packet on the
network.
Voice streams are still delivered from the monitoring (SPAN) port on a network switch.
However, this is not a significant issue. The signaling events are handled reliably by the
"active driver."
EPR also integrates two different recording components; the protocol driver and the
integration module. This means that with EPR, only one component is responsible for all
information that comes from the Genesys platform. This makes the recording process easier.
The attached metadata are more consistent and their delivery and completeness is assured. It
also makes manageability and troubleshooting easier, since one component delivers all the
events together.
Genesys Integration Module
Genesys Integration Module (GIM) is required when SIP or JTAPI based call recording is
deployed. The GIM connects Call Recording and Genesys T-Server using the Voice Platform
SDK and Configuration Platform SDK.
78
Connection with Call Recording is implemented using the Call Recording API. Via its API, Call
Recording notifies the integration library of every newly established call it detects or records.
After the integration library learns of the available call information, it queries T-Server as to
whether the call is controlled by Genesys contact center or not. If it is, it acquires the available
properties of the call and hands selected data over to Call Recording, which saves it as
external data.
If recording is based on the Cisco Unified Communications Manager softswitch Call
Recording must be set to record through JTAPI adapter, since the lookup of information in
both systems leverages call identification (GlobalCallID), which is available in Call Recording
only through Cisco JTAPI.
For Genesys SIP Server deployments no specific settings are required.
Genesys CIM to Call Recording Information Exchange
The data saved in the Call Recording external data table come from various sources. There
are four basic information classes available:
Call-related user data (attached data)
Agent configuration data
Notification of recording
topology, and other conditions. You should configure the specific properties that have to be
stored in the Call Recording external data table during integration library implementation.
External Data Available from CIM
The data saved in the Call Recording external data table comes from various sources. This
information is available:
Basic call-related data.
Call-related user data (attached data).
Agent configuration data.
Extension Data.
79
Notification of recording.
Other GAD Data (only for Genesys Driver).
Other Call Recording Data ( used internally by Call Recording).
topology, and other conditions. You should configure the specific properties that have to be
stored in the Call Recording external data table during integration library implementation.
Supported Call Scenarios to Obtain External Data from Genesys CIM
Call Scenario Genesys SIP JTAPI Avaya
Agent to Agent (Basic call with SUPPORTED SUPPORTED SUPPORTED

logged agents on both sides)
Data for calling agent only
Basic call (Internal without SUPPORTED SUPPORTED SUPPORTED

logged agent)
Basic call (Internal without SUPPORTED SUPPORTED SUPPORTED

logged agent)
Call Hold SUPPORTED SUPPORTED SUPPORTED
Blind Transfer SUPPORTED SUPPORTED UNSUPPORTED
Consultative Transfer SUPPORTED SUPPORTED UNSUPPORTED
Blind Conference UNSUPPORTED UNSUPPORTED UNSUPPORTED
Consultative Conference UNSUPPORTED UNSUPPORTED UNSUPPORTED
Call Park UNSUPPORTED UNSUPPORTED UNSUPPORTED
Call Pickup UNSUPPORTED UNSUPPORTED UNSUPPORTED
Barge UNSUPPORTED UNSUPPORTED UNSUPPORTED
cBarge UNSUPPORTED UNSUPPORTED UNSUPPORTED
Set Genesys Driver Encoding for Attached Data
Genesys Driver assumes that any Attached Data received from the TServer is in the Unicode
(UTF-8) format. However, Genesys Platform SDK encodes this XML data based on the OS on
which it is installed.
Therefore if, for example, the Genesys software is installed on an OS with Czech encoding
('cp1250'), GIM does not store this correctly in the Call Recording database.
To avoid this encoding issue, set an encoding parameter manually in the Call Recording
configuration file:
1. Edit the Call Recording configuration file at:
/opt/callrec/etc/callrec.conf
80
2. Use a text editor to add the parameter ' Dfile.encoding=<encoding>' to the
JAVA_OPTS_GENESYS environment variable found near the end of the file. For example:
JAVA_OPTS_CORE="-server -XX:+DisableExplicitGC -Xmx96m
-Dcom.sun.CORBA.transport.ORBUseNIOSelectToWait=false
-Dfile.encoding=cp1250"
3. Save the file and restart Call Recording:

/etc/init.d/callrec restart
Basic call-related data is available from real-time events generated when the T-Server notifies
a client of call-based activity. These events arise when an observed phone performs actions
such as answering, transferring or hanging up the call. They are a source of essential
information about agent activity.
The data is stored using the following naming convention:
External data key: GEN_TEV_<TEvent.key>
Example: GEN_TEV_AgentID = AG_3017
Default stored data keys are in bold:
Key Description
GEN_TEV_AgentID Available by default. The agent

identifier specified by the PBX or ACD.
GEN_TEV_ANI Available by default. Automatic

Number Identification. Specifies which
number the current inbound call
originates from.
GEN_TEV_CallID Available by default. The call

identifier provided by the switch (as
opposed to connection identifier, or
ConnID, which is assigned by
T-Server).
GEN_TEV_CallUuid Available by default. The UUID of the

call; a unique call identifier provided by
the Genesys platform.
GEN_TEV_CallType Available by default. Type of the call.

One of the following values: Inbound,
Outbound, Internal, Consult, or
Unknown.
GEN_TEV_CollectedDigits Digits that have been collected from

the caller.
81
GEN_TEV_ConnID Available by default. Connection
identifier of the current call handled by
the DN.
GEN_TEV_CustomerID The string that contains the customer

identifier, through which call
processing was initiated.
GEN_TEV_DNIS Available by default. The Directory

Number Information Service. Specifies
to which DN the current inbound call
was made.
GEN_TEV_NetworkCallID In case of network routing, the call

identifier assigned by the switch where
the call initially arrived.
GEN_TEV_NetworkNodeID In case of network routing, the

identifier of the switch where the call
initially arrived.
GEN_TEV_NodeID The unique identifier of a switch within

a network.
GEN_TEV_OtherDN Available by default. The other main

Directory Number (which your
application did not register) involved in
this request or event. For instance, the
DN of the main party of the call.
GEN_TEV_ThisDN Available by default. The Directory

Number (which the application
registered) involved in this request or
event.
GEN_TEV_ThisQueue The queue related to ThisDN.
Important: If the value is empty, that key is not stored in the Call Recording database.
You can change this list manually in the driver configuration in the xml in the equal group
messageDataKeys with the values msgDataKey and coupleMsgDataKey. These define
the call event's attribute name and key that should be used for external data in Call
Recording. If at least one basic call-related data attribute is set, no default data keys are used.
In this case, you should manually configure all required attributes. This code shows you how
to store CallID and ThisDN where ThisDN is renamed to SomeDN for storage in Call
Recording.
82
<SpecifiedConfiguration name="genesysDriver">
...
<EqualGroup name="messageDataKeys">
<Value name="msgDataKey">CallID</Value>
<Value name="coupleMsgDataKey">CallID</Value>
</EqualGroup>
<EqualGroup name="messageDataKeys">
<Value name="msgDataKey">ThisDN</Value>
<Value name="coupleMsgDataKey">ThisDN</Value>
</EqualGroup>
...
For the Legacy GIM integration, the Specified Configuration name is "genesys".
<SpecifiedConfiguration name="genesys">
The rest of the listing is the same as in the example above.
User data or attached data is a set of call-related information predefined by the agent or
application that handles the call. A user data object is structured as a list of data items
described as key-value pairs.
User data can arrive at a client application with any event, at any time, even after the call has
been cleared. For example: when the agent fills in wrap-up information.
Any value extracted from user data is attached through the following naming convention:
External data key: GEN_USR_<UserData.key>
Example: GEN_USR_RStrategyName = default
Important: You should define the list of the user data to attach in the configuration. By default,
no user data gets attached.
User Data Configuration
The User data configuration option allows you to define Genesys User Attached Data.
Navigate to Settings> Configuration > Protocol Drivers >Genesys Driver and scroll down
to User Data Configuration.
You can add only user data in the column User Defined Parameters in the GIM configuration
section of the Call Recording GUI. You can specify other non-default, pre-defined keys in the
integration configuration file (/opt/callrec/etc/integration.xml) in XML format. You
should not modify these values unless completely necessary.
83
To add a User data key definition to GIM configuration:
1. Type the User data key and User data name (value).
2. Click New to add another key value pair if necessary.
3. Click Save Configuration to save the changes.
Agent Configuration Data
Configuration data objects enable the client to get any information about the user, agent,
server, or other object configuration stored in the Genesys configuration database, in addition
to information about the current state of the specific object.
You should use this naming convention to attach any value available from the configuration
library:
External data key: GEN_CFG_<CfgData.key>
Example: GEN_CFG_UserName = jsmith
This information is available from Configuration Platform SDK:
Default stored agent data keys are in bold:
Key Description
GEN_CFG_EmployeeID Available by default. The code that

identifies the person within the tenant
staff.
GEN_CFG_FirstName Available by default. The person's first

name.
GEN_CFG_LastName Available by default. The person's last

name.
GEN_CFG_UserName Available by default. The name the

person uses to log into a CTI system.
GEN_CFG_AdminType Specifies whether the person is

configured as =Admin. Yes=1, No=0
GEN_CFG_AgentType Specifies whether the person is

configured as =Agent. Yes=1, No=0
GEN_CFG_PlaceDbid A unique identifier of the place assigned

to this agent by default.
GEN_CFG_State The current state of the person object.
84
Some of the properties, namely LoginInfo and SkillInfo, contain more items, since an agent
can have more logins or skills. In this case, Call Recording saves them as indexed fields:
Key Description
GEN_CFG_AgentLoginInfo_:_LoginDbid agentLoginDBID A unique

identifier of the Agent Login
identifier.
GEN_CFG_AgentLoginInfo_:_WrapupTime wrapupTime Wrap-up

time in seconds associated
with this login identifier. Can't
be a negative value.
GEN_CFG_AgentSkillLevels_:_SkillDbid skillDBID A unique

identifier of the skill the level
relates to.
GEN_CFG_AgentSkillLevels_:_Level Level Level of the skill.

Can't be a negative value.
Important: If the value is empty, that key is not stored in the Call Recording database.
You can change this list manually in driver configuration in xml in the equal group
agentDataKeys with the values agentDataKey and coupleAgentDataKey, These
define the event Telephonic attribute name and key which should be used for external data in
Call Recording. If at least one Agent Data attribute is set, no default data keys are used. In
this case, you should manually configure all required attributes.This listing shows the
configuration of storing only EmployeeID.
...
<EqualGroup name="agentDataKeys">
<Value name="agentDataKey">EmployeeID</Value>
<Value name="coupleAgentDataKey">EmployeeID</Value>
</EqualGroup>
...
For Passive GIM integration, the SpecifiedConfiguration name is "genesys".
The rest of the listing is the same as the example above.
Extension Data
Extension data is stored with the GEN_EXT_ prefix. This data is taken from the Extensions
section of Genesys voice events. None of this data is stored by default.
85
You can configure the required data manually in driver configuration in the xml in the equal
group extensionDataKeys with the values extDataKey and coupleExtDataKey.
These define event Extension attribute name and key which should be used for external data
in Call Recording. This listing shows the configuration of storing BusinessID.
...
<EqualGroup name="extensionDataKeys">
<Value name="extDataKey">BusinessID</Value>
<Value name="coupleExtDataKey">BusinessID</Value>
</EqualGroup>
...
For Passive GIM integration, the SpecifiedConfiguration name is "genesys".

Other Genesys Driver Data
Genesys Driver and GIM also store some other Genesys-related data. These are not
configurable.
GEN_REC_ External data with the signaling of recording state for audio and video.
GEN_CONFERENCE_MEMBERS List of parties that participate in conference Couple.
Only available from Genesys Driver, not GIM.
GEN_CFG_FULLNAME Full name of agent created based on the configuration.
GEN_CFG_Tenant Call Tenant. Only available from Genesys Driver in Active
Recording mode, not GIM.
GEN_CFG_Switch Call Switch. Only available from Genesys Driver in Active
Recording mode, not GIM.
GEN_TEV_CSUP_MODE Call supervision mode, with the value Monitoring or Coach
ing. Only available from Genesys Driver in EPR or Active Recording mode, not GIM.
GEN_TEV_CSUP_SCOPE Call supervision scope, with the value Call or Agent. Only
available from Genesys Driver in EPR or Active Recording mode, not GIM.
GEN_TEV_CSUP_SUPID The agent ID of the monitoring Supervisor. Only available
from Genesys Driver in EPR or Active Recording mode, not GIM.
GEN_TEV_CSUP_SUPDN The DN of the Monitoring Supervisor. Only available from
Genesys Driver in EPR or Active Recording mode, not GIM.
Notification of Recording
The Notification of Recording option allows the system to provide information that concerns
whether a particular call is being successfully recorded. It is necessary for banks or financial
institutions that undertake financial transactions and need to ensure that a specific call is
being recorded. Add a preconfigured key in the attached data to provide notifications.
86
The principle of notification is that Call Recording ensures that the call has been detected and
all actions that lead to successful recording have been performed. After this, it provides status
information. This usually takes one second. However, in general we can't guarantee that the
state information will be available in only one second. The waiting timeout for for the state is
configurable. The default is 3 seconds.
When the state is known or the timeout expires, Call Recording provides state information
within pre-configured attached data. You can configure both key and value strings. For
example:
RecordingStatus_GIM1 = Recording
RecordingStatus_GIM2 = Unknown
The example demonstrates that you can configure different key names for different servers
that record the same Genesys platform. This is useful in case of redundant deployment.
Important: Note that in some situations the notification may not be 100% correct. For
example, in the case that the recorder does not get any voice data during the call, it can't be
recognized and reported. You should solve such situations through an additional monitoring
system that monitors SPAN ports and recording results.
87
Integrating with Avaya Contact Center
QM Suite supports limited integration with Avaya Contact Center Elite and provides the
following features:
The ZQM Avaya driver is able to collect contact center related attached data. A full list of
the attached data can be found here External Data from Avaya Platform
All collected data can be used for searching and displaying the calls in Call Recording
Web UI
All collected data can be used as a recording rule in order to decide which calls to
record
Limitations:
Quality Management importer doesn't support importing agents from Avaya CC, i.e.
Avaya CC agents cannot login using their CC credentials to Quality Management Web
Interface
88
Deployment Types
Single Server Deployment

Limitations
Multi Server Deployment
Cluster Deployment
Replay Server
Example of the Replay Server Deployment
ZOOM Quality Management offers the flexibility of various deployment options:
Single Server Deployment
Standalone installation means that all ZOOM Quality Management modules are installed on
the same server. All functionality is deployed on a single server.
Limitations
The limitation of a single server deployment depends on the platform, included QM Suite
product and HW.
The table below shows guaranteed count of calls that can be handled under in respect of
certain conditions such as hardware specifications, average length of calls
Enabled Hardware Storage Average Maximum

Products specifications length of count of
calls(min) concurrent
calls
Call Dell PowerEdge RAID controller with RAM cache 2 600

Recording R410 minimum 512 MB and battery
enabled
6 x CPU
(Intel(R)
Xeon(R) CPU
E5645 @
2.40GHz)
8 GB RAM,
dual channel
Call 6 x Virtual CPU, Dedicated storage for Call 2 500

Recording 2.4GHz Recording, RAID controller with
RAM cache minimum 512 MB and
8 GB RAM,
battery enabled
dual channel
89
Call Dell PowerEdge RAID controller with RAM cache 2 100
Recording, R410 minimum 512 MB and battery
Speech enabled
6 x CPU
Analytics
(Intel(R)
Xeon(R) CPU
E5645 @
2.40GHz)
8 GB RAM,
dual channel
Please contact us at https://portal.zoomint.com/ in order to get more info about other

variations of products and HW specifications.
Multi Server Deployment
In some cases a single server deployment doesn't meet the customer requirements and that
leads to go for more complex solution as Multi server deployment. Main reasons to go for a
multi server deployment can the following
Customer demands exceeds single server deployment's limitations
Required High Availability(HA)
Centralized system that integrates all QM Suite solutions in different branches
Cluster Deployment
Cluster deployment enables the recording of large telephone installations, load balancing and
the ability to record geographically distributed networks.
Requirements:
Solution design, descriptions of the roles of particular servers
Scaling of the solution, scaling the individual server parameters based on anticipated
call loads
Descriptions of individual server properties installed components, partitioning, network
connections, file system sharing
The Installation of individual servers
The Configuration of individual servers, network connection setup, files system sharing
setup
Individual servers are installed using the procedure described in this document. Contact
Support at the Partner Portal for additional information on configuration and integration of
cluster installations.
High Availability deployment is a special kind of multi server installation. ZOOM Quality
Management is installed on several servers in order to provide a High Availability solution. In
the case of the failure of one of the servers there are backup servers which will continue to
provide recording capabilities, usually with no impact on recording functionality and the
availability of recorded calls.
More detailed information about supported scenarios of High Availability can be found in the
following sections:
90
HA scenarios for screen recording
High Availability - Call Recording
High Availability - Replay Servers
Replay Server
The typical larger deployment of the ZOOM Quality Management spans over multiple
locations, utilizes doubled server cluster in order to maintain high availability or a combination
of both. In all those various cases there are multiple servers or clusters serving as recorders
and providing recorded conversations. Those recorded media and associated metadata are
always stored locally at the cluster, however customers require centralized access and
management of all of them, including the life cycle management, reporting, auditing, and so
on. And of course Quality Management as the quality management tools needs to have
access to consolidated data regardless of where the particular recording has been made.
These requirements led to introducing of the Replay Server as the central point of access to
all the recorded data, meaning media and metadata. The Replay Server:
Consolidates all the recorded media and metadata on one place, combining them and
eliminating duplication at the same time
Provides single user access point to all of the recorded data
Provides single user access to quality management application Quality Management
Provides single access to live monitoring console Live Monitoring
Acts as an interface to backup solution to provide lifecycle management of the recorded
media
Replay Server requires a special license file. It can be requested at

https://portal.zoomint.com/
Example of the Replay Server Deployment
The following diagram depicts an example of the distributed deployment.
91
There are two contact centers in two geographically distributed locations: London and Paris.
Both locations operate more or less independently so there are separate recording cluster at
each. Moreover those recording clusters utilize redundancy in order to guarantee high
availability of the recording solution - if one of the recording clusters fails, the other one keeps
providing service.
This means there are four recording clusters in total providing media and metadata:
Recording cluster one in London
Recording cluster two in London
Recording cluster one in Paris
Recording cluster two in Paris
The users of the solution, contact center managers, supervisors and administrators obviously
require a single point of access where all the recorded media and metadata are available.
Also, the quality management application, Quality Management, needs to have all the data
available as a one consolidated set.
The Replay Server is actually a modified installation of the QM Suite where some features are
disabled and where most of the resources are dedicated for the database and the application
server running Web UI. The essential component running there is the Synchro, one of the
Media Lifecycle Management tools. The Synchro tool collects all data (call information, mp3,
recd, mp4, Speech Analytics index files) and synchronizes them to the Replay server. More
information about the Synchro Tool and it's configuration can be found here Synchro Tool.
92
Advanced topics about Replay Server configuration:
Synchro Tool Configuration of the Synchronization process from Recording clusters
Live Monitoring with Replay Server Using a centralized Live Monitoring from the
Replay server in order to listen all calls from all branches
QM Suite Services Distribution of ZQM Services for the Replay Server
93
HA scenarios for screen recording
This chapter describes the supported high-availability (HA) scenarios for Screen Capture.
To provide HA for Screen Capture:

Deploy two or more Call Recording clusters (no limitations are set for backup Screen
Capture servers) with a configured Screen Capture server.
Each cluster must have separate media uploaders and media encoders because these
devices cannot be shared.
Configure the Screen Capture client to connect to all Screen Capture servers by
entering the address list during the capture client installation.
Note
Please note that in deployments where Screen Capture and Screen Capture Uploader
are on different servers NFS mountpoint with lookupache=positive option is
mandatory. The Screen Capture can thus verify that the RECD file exists and the
information about RECD file can be saved to the DB.
The following diagram presents how the Screen Capture client connects to the Screen
Capture server and media uploader modules during HA situations.
During normal operation, the capture client connects to the primary Screen Capture server
(the one in Cluster A). The Screen Capture server provides the IP address of the media
94
uploader so that the capture client can send media (images of agent screens) to the media
uploader. In this situation, the Cluster B Screen Capture server and media uploader are
running but not processing data.
In the event of a system failure, the capture client uses backup communication to connect to
the Screen Capture server of Cluster B. The Screen Capture server then provides the IP
address of its own media uploader (the one in Cluster B) so that the capture client starts
sending the media stream through the backup media upload connection.
If the Screen Capture server fails during recording, the current recordings (screens only) will
be lost. After reconnecting to the other Screen Capture server, new requests are processed
normally.
If Screen Capture fails on the primary server but the call recording is saved, you can replay
the screen images using the backup connection and the audio files from the primary
connection.
95
High Availability - Call Recording
This section describes the various High Availability Recording cluster options that QM Suite
supports. The section covers call recording functionality.
High Availability Terms
Cisco
Cisco - Active Recording - Hot Standby HA
Normal Operation
Failover
Cisco - Active Recording - Warm Standby HA
Normal Operation
Failover
Cisco - Passive Recording - Active-Active HA
Normal Operation
Failure
Cisco - CUBE Active SIP Recording - Hot Standby HA
Genesys
Genesys - Active Recording (MSR) with Stream Duplication - Active-Active HA
Normal Operation
Failure
Genesys - Active Recording (MSR) without Stream Duplication - Hot Standby HA
Normal Operation
Failover
Genesys - Passive Recording (EPR) - Active-Active HA
Normal Operation
Failure
Avaya
Avaya Recording - Active-Active HA
Normal operation
Failure
Avaya Passive Recording - Active-Active HA
Normal operation
Failure
High Availability Terms
In the examples below we describe three types of High Availability:

Active-Active - RTP streams are sent to both Recorder clusters and calls are recorded in
parallel. The synchronization process can be configured to ensure that data replication
occurs.
Hot Standby - RTP streams are sent to one of the Recorder clusters(primary). The
stream is then replicated in real-time to the second cluster.
Warm Standby - RTP streams are sent to one of the Recorder clusters. The stream is
not replicated to the second cluster.
Warm Standby Hot Standby Active-Active

Cisco Active Recording
Cisco Passive Recording NOT REQUIRED NOT REQUIRED
96
Genesys Active Recording NOT REQUIRED
Genesys Passive Recording NOT REQUIRED NOT REQUIRED
Avaya Active Recording NOT REQUIRED NOT REQUIRED
Avaya Passive Recording NOT REQUIRED NOT REQUIRED
- supported mode
- not supported
NOT REQUIRED - the mode can be configured but it is not commonly used because of
availability and the obvious benefits of utilizing a higher level mode.
Cisco
Cisco - Active Recording - Hot Standby HA
RTP streams are primarily sent to server/cluster A.

SLR recorders are cross-connected between both Cores.
When SLR A fails the CUCM automatically switches the destination for RTP streams to
the next available SLR.
When one Core fails, the second core still operates as normal and commands both
recorders. This results in full availability, even if Core B fails together with SLR A the
recording will still continue.
Pay attention to Core/SLR limitations when planning this deployment.
Normal Operation
Failover
97
Cisco - Active Recording - Warm Standby HA
This deployment is the same as the previous, except that in this case the SLRs are not
cross-connected between the Cores.
This implies that there is no HA for the Core module.
When SLR A fails the CUCM switches the destination path to the next available SLR.
However, when Core A fails there is no built-in mechanism to notify the CUCM that it
should switch to another SLR. This needs to be handled by monitoring the components
and either manually correcting the problem or creating a custom script that is
tailor-made to resolve, or workaround, the problem in the particular deployment that is
installed.
In general it is recommended to implement a "hot standby" deployment whenever
possible.
Normal Operation
98
Failover
Cisco - Passive Recording - Active-Active HA
This deployment assumes the presence of a switch with the capability to monitor two
(SPAN) sessions.
To achieve full resilience against the failure of one Core and one RS the recorders can
be cross-connected to both Cores in order to keep recording calls even if, for example,
Core A and RS B fail. However, this may unnecessarily increase the amount of data
transmitted over the network.(in some deployments).
In the case that only one SPAN session can be configured the recorders can be
cross-connected with Cores, however, there will still be only one recorder receiving the
99
RTP packets. If that recorder fails and the problem cannot be resolved in a reasonable
amount of time the destination of the SPAN port needs to be changed manually in order
to continue recording. In this case the deployment is not considered as "active-active
HA".
Normal Operation
Failure
Cisco - CUBE Active SIP Recording - Hot Standby HA
RTP streams are primarily sent to server/cluster A.

SLR recorders are cross-connected between both Cores.
100
When SLR A overloads, SLR A redirects sessions to SLR B.
When SLR A fails the CUBE automatically switches the destination for SIP and RTP
streams to SLR B.
When one Core fails the other one continues to operate and commands both recorders.
This ensures that even if Core B fails together with SLR A the system will continue to
record.
Genesys
Genesys - Active Recording (MSR) with Stream Duplication - Active-Active HA
This deployment assumes that the Genesys platform is configured to duplicate the RTP
streams to two different destinations (recorders).
Cross-connection is possible but is rarely used. This is primarily due to the fact that this
type of deployment is usually used for large deployments where limitations of the Core
do not allow for the cross-connection of the recorders with multiple Cores.
Normal Operation
101
Failure
Genesys - Active Recording (MSR) without Stream Duplication - Hot Standby HA
This deployment can be used in environments where it is not possible to set up stream
duplication on the Genesys platform.
The Genesys platform is configured to primarily send the RTP streams to SLR A. If SLR
102
A becomes unreachable the RTP streams will be sent to the next available SLR, in this
example to SLR B.
The recorders can be cross-connected with both Cores to achieve simultaneous
recording on both servers/clusters.
Normal Operation
Failover
103
Genesys - Passive Recording (EPR) - Active-Active HA
This deployment assumes a switch that is capable of monitoring two (SPAN) sessions.
If only one SPAN destination can be configured then the recorder which is the
destination is the single point of failure. In the case of failure the SPAN settings may
need to be modified manually.
Normal Operation
104
Failure
105
Avaya
Avaya Recording - Active-Active HA
HA deployment on Avaya has the following requirements:

Each Core (Avaya driver) must use a different range of virtual devices.
Each Core (Avaya driver) must have the other Core's virtual devices excluded
from the list of observed devices.
If the configuration is correct the calls are recorded on both servers/clusters at the same
time.
Cross-connection of recorders is not supported.
Normal operation
Failure
106
Avaya Passive Recording - Active-Active HA
This deployment assumes the presence of a switch with the capability to monitor two
(SPAN) sessions.
To achieve full resilience against the failure of one Core and one RS the recorders can
be cross-connected to both Cores in order to keep recording calls even if, for example,
Core A and RS B fail. However, this may unnecessarily increase the amount of data
transmitted over the network.(in some deployments).
In the case that only one SPAN session can be configured the recorders can be
cross-connected with Cores, however, there will still be only one recorder receiving the
RTP packets. If that recorder fails and the problem cannot be resolved in a reasonable
amount of time the destination of the SPAN port needs to be changed manually in order
to continue recording. In this case the deployment is not considered as "active-active
HA".
Normal operation
107
Failure
108
High Availability - Replay Servers
This section describes supported scenarios of High Availability of QM Suite Replay Servers.
Deploying your Replay server in HA reduces the risk of losing data (for example: when the DB
is not backed up) and the downtime of the service in case a problem occurs
Minimum Requirements
Recommended
Limitations
Possible Deployments
Two QM Suite servers, two database servers
Two QM Suite+database servers
One QM Suite server, two database servers
Minimum Requirements
Shared or replicated storage for media files

QM Suite 5.0.x or higher
PostgreSQL 9.0 or higher (older versions of PostgreSQL do not have the built-in
replication mechanism)
Recommended
QM Suite 5
PSQL 9.3
(optional) load balancer for Web UI user access
Limitations
Configuration stored outside of the database is not replicated (for example, .conf files,
.xml files etc.), basically everything under "Settings->Configuration" except for User
Setup
this means that every time a change in configuration is made on the active Replay
server, it also has to be done manually on the standby server
If WebUI finds a configured Advanced search column for particular attach data
key in the database, but this Adv. search is not defined in the configuration
(WebUI->Search / webadmin.xml), the WebUI will remove it from the database.
Therefore the Advanced search settings must be manually replicated to the
standby server before QM Suite services are started (mainly the WebUI) after
you switch over.
Possible Deployments
All deployments listed below require 2 database servers.

However, it is not mandatory to have 2 servers for the QM Suite applications.
You can run just one Replay server with 2 databases (master and slave) and use a script to
switch the IPsof the DB in the config files when the DB switchover is performed.
Two QM Suite servers, two database servers
109
Let's assume that QM Suite server 1 and its database server (1) are considered as "primary".
QM Suite server 2 and its database server (2) are considered as "backup".
Normally, QM Suite services only run on server 1 and on server 2 they are stopped (however
the server 2 itself is up and running).
At the same time, DB server 1 is running in Master mode (read-write) and DB server 2 is
running in Slave mode (read-only).
When a problem occurs either on QM Suite 1 or DB 1 which cannot be resolved in a timely

manner, the roles can be manually switched over to make servers 2 Masters and servers 1
Slaves.
In this deployment, the switchover is done as follows:
Stop QM Suite services on server 1 (if applicable - server may be down completely)
Switch the DB 1 from Master to Slave (if applicable - server may be down completely)
Switch the DB 2 from Slave to Master
Start QM Suite services on server 2
Then, after the switchover the state looks like this:
110
This deployment has one great benefit, which stems from the fact that there are two identical
pairs of servers:
When a problem occurs simultaneously for example on QM Suite server 1 and DB server 2,
it is possible to switch the DB IP addresses in the configuration of QM Suite server 2 to make
it connect to DB server 1.
111
The grey dashed line means that the connection has been configured, but is not active.
Two QM Suite+database servers
The configuration of this scenario is very similar to the first one. The only difference is that the
PSQL databases are running on the same servers as the QM Suite services.
112
In this deployment, the switchover is done as follows:
Stop QM Suite services on server 1 (if applicable - server may be down completely)
Switch the DB 1 from Master to Slave (if applicable - server may be down completely)
Switch the DB 2 from Slave to Master
Start QM Suite services on server 2
Then, after the switchover the state looks like this:
113
One QM Suite server, two database servers
This scenario provides redundancy only for the PSQL database.

Normally the QM Suite services are running and are configured to connect to DB on DB
server 1:
114
When a switchover needs to be done, the procedure is as follows:
Stop QM Suite services
Switch DB on server 1 from Master to Slave
Switch DB on server 2 from Slave to Master
Shange DB IP addresses in the configuration of QM Suite to point to the new Master
(server 2)
this can be done either by manually editing core.xml and config_manager.xml
or using a pre-configured script that automatically detects which DB is the Master and
modify the DB IP address in the configurataion files
Start QM Suite services
Afterwards the state looks like this:
115
116
Planning Hardware Requirements
This guide will help you to evaluate the hardware requirements for your QM Suite solution. As
a main factor for scaling your hardware, we take count of concurrent calls to be recorded by
the system. By concurrent calls we mean the maximum number of calls that your server will
ever record simultaneously. The second leading factor is QM Suite products that you're
planning to have on the server(s).
Expected load, disk space, and licence inputs
Hardware Platforms and Sizes
117
Expected load, disk space, and licence inputs
This section describes the required data for planning recording solutions in contact centers or
offices. Data-collection requirements, data retention policies, and storage estimations of
contact centers are critical for designing optimal solutions. Ensure that the inputs used in the
following calculations are accurate. In the tables below you will find an overview of information
that you will need to collect before calculating requirements. After the tables you will find links
to several spreadsheets intended to aid you in performing calculations.
The following information is necessary to keep in mind when calculating the disk space
necessary for recorded media. It is better to overestimate disk space than to underestimate it
as insufficient storage will hinder call recording after a period.
Calculating disk space and expected load
To begin with please download the relevant files below, then proceed to calculate disk space
and bandwidth requirements. A list of requirements and points to consider follows below.
The ZOOM Call Recording Disk Space Calculator will help you to calculate your storage
requirements for a single server replay setup utilizing PostgreSQL. Simply enter the
required information into the cells highlighted in yellow.
The ZQM Bandwidth Calculator provides you with a calculation of potential bandwidth
requirements. After downloading the file you can replace the example data and generate
an estimate of bandwidth utilization.
Things to take into account when estimating data traffic or disk space requirements.
It is important to keep in mind that each organization is unique and any calculation of
expected data usage will be dependent on not only the factors listed below but may also be
affected by growth of the business or other unforeseen events. The type of organization being
recorded is relevant because each industry has unique recording requirements. In come
cases businesses must record all calls while maintaining compliance with media retention
regulations. For example, in many countries all financial transactions must be stored for at
least 7 years. The recordings may also be utilized for training and quality control purposes or
to ensure that agents are representing the company properly.
The following table provides a general overview of the type of information required in order to
adequately predict data usage which is dependent on business specific practices.
Business
Specific
Information
Number If staff work in multiple locations, call recording can occur in all locations.
of sites Understanding the network topography and available signaling protocols
ensuring the events required by Call Recording for detecting and recording calls
is vital. Having access to the recordings when required is critical.
118
Number The number of seats is the number of physical workstations where agents can
of seats make or answer calls. To calculate the maximum seat capacity, count the
number of seats to be recorded including any expected expansions.
The seat number is used to calculate the maximum capacity so that a sufficient
number of recorded calls is provided in the Call Recording license, ensuring that
all calls are recorded. Theoretically, all agents on duty could be on calls
concurrently.
In a small call center (up to 100 agents), the following is true:
number of seats = maximum number of concurrent calls
Based on data from the contact center platform if less than 100% of agents are
likely to be on a call concurrently, then:
number of seats * percentage of agents calling
simultaneously = maximum number of concurrent calls
Number This is the total number of agents. If the organization uses a shift system the
of organization can have more agents than actual seats. This scenario increases
agents the number of hours recorded per day and the amount of recorded data .
Average This is the average total number of hours per day during which the contact
number center operates, not the number of hours that an individual agent works. For
of example, if the call center seats are occupied and producing calls for 16 hours a
working day then the average number of working hours per day is 16, even if individual
hours agents only work for 8 hours per day. Consequently, the total number of calls
per day per day is affected.
per seat
If the number of hours varies, then:
average number of working hours per day = average
number of hours per week/number of working days
Average The average number of working days per month for the call center.
number
For example, if the contact center operates 5 days a week all year (52 weeks)
of
and is closed 15 days for national holidays that occur on working days, use the
working
following calculation:
days
per ((5 * 52) -15) / 12 = 20.47 working days per month.
month
If your call center operates during national holidays, the calculation is:
(5 * 52) / 12 = 21.72 working days per month.
The following table will help you to understand the various factors affecting data usage and
demand which is dependent on the specific operational practices of the business.
Expected load The following sections explain how to calculate the expected call
center load.
119
Number of If real data are available from the call center, use them for the following
calls recorded calculations. The number of calls recorded per day is required to plan
per day the storage amount required for the media.
If real data are unavailable, use your call center estimated data to obtain
an approximate calculation of the calls per day.
The required daily storage for calls is calculated as follows:
(the number of calls per day) * (the average length

of calls) * (multiplying factor for bitrate and
media format)
If capturing screens add the result to that determined for the storage
required.
Maximum load Maximum load occurs when all available agents are engaged in calls. In
a fully occupied contact center this is the same as the seat number. For
example, if you have 100 agent seats and at peak hours all agents are
engaged in calls, the maximum load is 100 concurrent calls. Your call
center software should be able to provide you with maximum load data.
Average call The call center platform should be able to provide a report on the
length in average length of calls. Be careful to exclude data concerning calls that
seconds don't need to be recorded.
average length of call = total duration of calls

in seconds / number of calls.
Wrap-up Wrap-up or after-call work is post-call clerical work that a contact center
(after-call agent completes after a call has ended. This period is important because
work) when agents are performing after-call work they can't actively be on the
phone; however, the contact center may wish to record screen captures
of agent activity during this period.
Average The total time from when a call starts until the agent wraps up, including
handling time any hold time.
Idle time Idle time is any time when agents are not calling or performing after-call
work.
120
Media storage Media storage is a crucial planning factor because media files
accumulate rapidly and if storage is unavailable, media can't be
recorded.
Call storage The period for which calls must be stored depends on contact center
period on the type. Regulations mandating storage length depends on the specific
recording contact center's location.
server
Despite whether no laws mandate how long the media must be stored,
organizations frequently have their own policies regarding record
retention. Only store media on the recorder server for the period that the
media must be accessed quickly. After this period archive, relocate, or
back up the media files and delete them from the recorder server using
the media lifecycle tools provided with Call Recording.
Screen-capture Screen capture media files are large. The storage period for screen
storage period captures is usually shorter than that for calls.
on the
recording
server
Percentage of Typically, all screens don't need to be captured. To reduce the amount
screens to of media stored, record a percentage of the screens (each captured
capture screen is associated with a call). The percentage of screens recorded
can be set in the recording rules and is dependent on the percentage of
calls recorded. For example, for 100 calls, if 50% of all calls recorded
and 20% of screens are recorded, the actual number of screens
recorded is 10 screens.
Screen A high screen resolution increases the screen capture media file. If the
resolution screens captured have a low resolution, the size of the media file is
small. The bitrate is variable because the capture technology uses
MPEG compression technology. When each screen capture differs
substantially from the previous screen capture, the data for each capture
increases.
RECD file The RECD files are generally smaller than the fully mixed MP4 files. An
storage MP4 file is typically twice the size of a RECD file of the same screen
calculation capture. In addition, the size of the RECD file varies depending on how
much the image being captured changes per frame.
The bitrate for a RECD file is approximately 2,000 kB/min.
121
MP4 storage The following calculation is useful for establishing the size of one MP4
calculation file in storage.
The result should be multiplied by the number of files in storage.
video bitrate = Dx * Scale/100 * Dy * Scale/100 * FR

* Q
Where:
Dx is the X axis of the desktop size in pixels, for example, 1024.
Dy is the Y axis of the desktop size in pixels, for example, 768.
Scale is the scale of resulting video in % (default = 100; range 20 -
100).
FR is the video frame rate in frames per second, fps) (default = 2;
range 0.5 - 5).
Q is the quality coefficient (default = 0.25; max = 0.5, high = 0.25;
medium = 0.2; low = 0.125).
Audio bitrate = MP3 bitrate (24 kbps) or 32 kbps for WAV files.
MP4 bitrate = video bitrate + audio bitrate in kbps.
MP4 size (in kB) = (video length * video bitrate + audio
length * audio bitrate) * (1 + overhead).
ZOOM has estimated the overhead coefficient to be approximately
0.002.
Call Recording To operate QM Suite it is necessary to have sufficient registered

license terminal, recorded call, and concurrent screen attributes included in the
requirements license.
Registered For Cisco JTAPI sufficient registered terminals must be in the Call
terminals Recording license to account for every recorded agent seat. If you have
100 agents and a license with only 50 agent seats, Call Recording
registers only 50 agents. Registered terminal limitations apply only to
Cisco JTAPI.
Concurrent Concurrent calls are the number of observed terminals. To ensure that
calls all seats are observed the number of concurrent calls should be the
same as the total number of seats.
Concurrent This is the maximum number of screens that can be recorded

screens simultaneously.
Recorded calls Call Recording License properties must have sufficient recorded calls to
record all agents that need to be recorded. If you have 100 agents and a
license with only 50 recorded calls, Call Recording records only a
maximum of 50 agents at one time.
122
Connectivity The number of servers and the configuration of data recording between
between sites them will have an impact on bandwidth. These variables will be specific
to the installation and particular specifics of the installation.
Files:
ZOOM Call Recording Disk Space Calculator
ZQM Bandwidth Calculator
123
Hardware Platforms and Sizes
Sizes
Hardware Platforms
HP Details
IBM Details
Dell Details
This section gives examples of suitable available servers from several manufacturers.
Sizes
For the following tables the definitions for the sizes are:
Small: Small/remote sites (up to 100 calls).
Distributed deployments servers without storage (RS, DS, RTS).
Medium: Medium size sites (up to 250 calls) 2 servers.
Distributed deployments higher processing power demands DS.
Large: DB and Storage for Replay Servers.
The only difference between Large and Medium size servers is disk space (and/or
SAN/NAS).
Hardware Platforms
Small Medium Large
HP ProLiant DL320 G6 ProLiant DL360 G7 ProLiant DL380

G7 + StorageWorks
D2600/D2700
IBM IBM x3250 M3 IBM x3550 M3 IBM x3550 M3 + Storage

DS3500
DELL PowerEdge R310 PowerEdge R510 PowerEdge R710

+ PowerVault MD3200
Cisco UCS UCS C200 M2 Rack UCS C210 M2 Rack UCS C250 M2 Rack Svr,
C-series Svr, Svr, 2x X5650, 8x4 GB, 2 PS
rack-mount 1x E5620, 1x4GB, 2x E5620, 4x4GB,
1PS 2PS
Cisco UCS UCS B200 M2 Blade UCS B200 M2 Blade UCS B200 M2 Blade
B-series Server, Server, Server,
blade 1x E5620, 1x4GB 2x E5620, 4x4GB 2x X5650, 4x8 GB
HP Details
Small server ProLiant DL320 G6

Max. 1 CPU (2 or 4 core), max. 96GB RAM
2 NIC, 2 expansion slots
Up to 4 LFF or 8 SFF SAS/SATA/SSD disks up to 2.4TB RAID10 with 600GB HDDs
124
Medium server ProLiant DL360 G7
Max. 2 CPU (2, 4 or 6 core), max. 192GB RAM
Up to 8 SFF SAS/SATA/SSD disks - up to 2.4TB RAID10 with 600GB HDDs
Large server ProLiant DL380 G7
Up to 16 SFF SAS/SATA/SSD disks (with optional 2nd drive cage) - up to 8.4TB
RAID5 with 600GB HDDs, but external NAS/SAN storage recommended.
IBM Details
Small server IBM System x3250 M3

Up to 2 LFF or 4 SFF SAS/SATA/SSD disks up to 1.2TB RAID10 with 600GB HDDs
Medium server IBM System x3550 M3
Up to 8 SFF SAS/SATA/SSD disks up to 2.4TB RAID10 with 600GB HDDs
Large server IBM System x3630 M3
Up to 24 SFF SAS/SATA/SSD disks up to 11TB RAID5 with 500GB HDDs, but
external NAS/SAN storage recommended
Dell Details
Small server PowerEdge R310

Up to 4 LFF/SFF SAS/SATA/SSD disks up to 1.2TB RAID10 with 600GB HDDs
Medium server PowerEdge R510
Up to 14 SFF SAS/SATA/SSD disks up to 7.2TB RAID5 with 600GB HDDs
Large server PowerEdge R710
Up to 8 SFF SAS/SATA/SSD disks up to 2.4TB RAID10 with 600GB HDDs, but
external NAS/SAN storage recommended.
125
Basic hardware requirements.

IOPS
Network Requirements
NFS Performance
Database Performance
Call Data
Acronyms for Call Recording Services
Recommendations for All Configurations
Record up to 50 Concurrent Calls - Call Recording Only
Record up to 100 Concurrent Calls - Call Recording and Quality Management
Additional Screen Capture Requirements
Modular Solution for 1000 Concurrent Calls
In the sections that follow, there are examples of the components and hardware requirements
for different sizes of call recording solutions.
However, critical factors related to network and I/O conditions are examined first.
Basic hardware requirements.
Before installing Call Recording please ensure that the drive has at least 20 Gigabytes of
space free for the OS. If there is less than 20 Gb of space the install process will fail.
IOPS
A very important parameter in QM Suite storage performance is Input/Output Operations Per

Second (IOPS).
Recording is the most demanding operation for storage systems in QM Suite. Recording
storage should always be independent from other storage if the IOPS limit is being
approached.
Each call recording requires around 4 IOPS, so for 500 concurrent calls this is around 2000
IOPS.
The Decoder requires 3 I/O operations during operation, while a local database and Screen
Capture add further I/O operations.
The QM Suite database is very demanding on both storage and CPU capacity, particularly if
Quality Management is installed and is heavily used for evaluations. We recommend that for
large installations, the database should be running on a separate server.
Typical IOPS values for current HDD drives are as follows - only fast SAS drives should be
considered for call recording storage.
7,200 rpm SATA drives HDD ~75-100 IOPS SATA 3 Gb/s
10,000 rpm SATA drives HDD ~125-150 IOPS SATA 3 Gbit/s
10,000 rpm SAS drives HDD ~140 IOPS SAS
15,000 rpm SAS drives HDD ~175-210 IOPS SAS
126
Solid State Drives (SSD) offer much higher IOPS performance, so are an ideal candidate for
the role as a call recording cache (short term storage, before calls are archived to permanent
storage consisting of slower HDD drives).
Network Requirements
The following factors are critical in determining the response and quality of an IP-based call
recording system:
Latency: Latency is a measure of time delay experienced in a system.
Jitter: Jitter is the variability over time of the packet latency across a network.
Bandwidth: Bandwidth is the rate of data transfer, bit rate or throughput, measured in
bits per second (bps).
Good network throughput in a multi-server environment is essential, particularly where the
NFS (Network File System) is used. Network throughput is characterized by a combination of
bandwidth usually 100 Mbit/sec or 1 Gbit/sec and the latency. Higher jitter factors, where
in the worst case packets are lost during transit, also negatively affect the throughput.
Resources shared between servers can also affect throughput, such as:
A decoder loading recorded calls over the network
SQL queries and result sets
Call data in transit to network storage
NFS Performance
NFS (Network File System) performance degradation is caused by the following:

Network connection speed much lower than the local disk connection (SAS has 3-6
Gbits / sec).
No caching (the file being loaded over the network could be modified any time by
another process).
Network latency being much higher than local latency (all switches / routers on the way,
and so on).
Network overhead being much higher than local transfer. The worst case is transferring
a large number of small files.
Database Performance
Database performance is dependent on the distribution of CPU, RAM and storage:

Small database queries (SQL Selects) produce potentially huge results, that need to be
transferred across the network.
Call Data
Calls that are delivered to recorders over the same network interface reduce the
network bandwidth available for other network services.
There is always a tradeoff between sharing resources (CPU, RAM, storage) and
limitations imposed by the network.
In summary, it is beneficial to ensure that a multi-server implementation shares the resources
and distributes the load (to obtain more CPU horsepower, for example), but this is dependent
on the servers being connected to a network that is fast enough to deliver data without
127
allowing servers to enter an idle state, waiting for further tasks.
Acronyms for Call Recording Services
In the following hardware configurations, Call Recording services are referred to by the
following acronyms:
RMI: Remote Method Invocation. The RMI is used to communicate between modules.
CONFIG: The Configuration Manager.
CORE: The central Call Recording control module.
RS: SPAN recorder.
SLR: Active recorder.
DECODER: decoder server.
CC IM: Contact Center Integration Module, for example, Cisco UCCE, UCCX, and
Genesys CIM.
TOOLS: Media Lifecycle Management tools, for example, the Archive utility.
WEB UI: Call Recording Web-based user/administration interface.
DATABASE: The main call information database.
RTS: Real-time protocol sniffer (for example, JTAPI, SIP, Skinny).
Recommendations for All Configurations
If a server with CentOS or RedHat 32 bit has more than 4 GB RAM, make sure that the
Physical Address Extension (PAE) enabled kernel is installed.
If the storage system causes a bottleneck in Call Recording performance, especially during
peak hours, use a fast SLC SSD as a write through cache where the recorded files are stored
in addition to the slower permanent storage (based on HDD).
The size of the SSD cache should be at least as large as the amount of data recorded during
the peak hours of one business day.
The recommended server hardware configuration for 50 concurrent calls is as follows:
Call Recording Only - 50 Calls
Running Services: RMI, CONFIG,CORE, RS/SLR, DECODER, CC IM, TOOLS,

WEB UI, DATABASE, RTS
CPU Dual core (Intel CORE2) processor 2.0Ghz or better
RAM 4 GB RAM minimum
HDD 2x Drives RAID 1, 7,200 rpm (approximately 200 IOPS

required)
Network Cards 2x 100 Mb Ethernet minimum for Passive recording 1x 100

Mb Ethernet minimum for Active recording
Storage Example
Average length of calls 180 seconds
128
Average handle time 270 seconds ( 90 seconds After Call Work)
Maximum concurrent calls 50
Number of calls per day 4800 for an 8 hour day
Percentage of calls 100%

recorded
Storage required for one 86 GB + 20GB for system

month of mp3 media
Storage required for 12 1 TB + 20 GB for system

months of mp3 media
The recommended server hardware configuration is as follows:
Running Services: RMI, CONFIG, CORE, RS/SLR, DECODER, CC IM, TOOLS,

WEB UI, DATABASE, RTS
CPU Quad core (Intel CORE2) 2.0Ghz or better
RAM 4 GB Minimum, 8 GB Recommended
HDD 4x 10,000 rpm Hard Drive, RAID 10 (approximately 400 IOPS

required)

Storage Example
Average length of calls 180 seconds ( 3 minutes)
Average handle time 270 seconds
Number of calls a day 9600 for an 8 hour day

month of mp3 media
Storage required for 12 2.2 TB + 20 GB for system

months of mp3 media
This scenario assumes that there will be around 10 supervisors (one supervisor to every ten
129
agents) accessing Quality Management simultaneously. The recommended server hardware
configuration is as follows:
Call Recording and Quality Management - 100 Calls
Running Services: RMI, CONFIG,CORE, RS/SLR, DECODER, CC IM,

TOOLS, WEB UI, DATABASE, RTS
CPU Intel Quad Core 55XX 2.0Ghz or better (4 Cores)
RAM 16 GB RAM
HDD 4x RAID 10, 10,000 rpm Hard Drive

Storage Example
Average length of calls 180 (3 min)
Average handle time 270 seconds (4.5 minutes)
Number of calls a day 9600
Storage required for one 180 GB + 20GB for System

month of mp3 media
Storage required for 12 2.2 TB + 20GB for System

months of mp3 media
Storage required for Quality 20 GB

Management Database
Running Services: RMI, CONFIG,CORE, RS/SLR, RTS, DECODER, CC IM,

TOOLS, WEB UI, DATABASE
CPU Intel Quad Core 55XX 2.3 Ghz or better
RAM 8 GB Minimum
130
HDD Two options for recording cache (approx 1000 IOPS
required):
1. SSD having a total minimum 1,000 IOPS using 4 kB
blocks
2. 4x SAS 10,000 rpm for RAID 10 partition with write cache
enabled to decrease HDD IOPS
Dedicated HDD for permanent storage: 4 x 7200 rpm for
RAID 10
Network Cards 2x 1 Gigabit Ethernet
Storage Example
Number of calls a day 24,000 for an 8 hour day
Percentage of calls recorded 100%

month of mp3 media
Storage required for 12 5.4 TB + 20GB for system

months of mp3 media
This scenario assumes that there will be around 25 supervisors (one supervisor to every ten
agents) accessing Quality Management simultaneously. This solution requires two servers:
Server 1: Call Recording recording and decoding modules
Server 2: Quality Management including database, MLM Tools and Call Recording Web
UI
Server 1: Call Recording - 250 Calls
Running Services: RMI, CONFIG,CORE, RS/SLR, RTS, DECODER, CC IM
CPU Intel Quad Core 55XX 2.3 Ghz or better
RAM 8 GB Minimum, 16 GB Recommended
131
HDD Two options for recording cache (approx 1000 IOPS required for
recording, additional IOPS produced by Quality Management)
1.SSD having a total minimum 1,000 IOPS using 4 kB blocks
enabled to decrease HDD IOPS
Additional HDD requirements are produced in relation to how
heavily (and when - if off peak or during peak hours) Quality
Management is used.
If more concurrent users use Quality Management, it is
recommended to deploy the database on a separate HDD.
Dedicated HDD for permanent storage: 4 x 7,200 rpm for RAID 10
Storage Example
Average length of 180 seconds

calls
Maximum 250
concurrent calls
Number of calls a 24,000 for an 8 hour day

day

recorded
Storage required for 450 GB + 20GB for system

one month of mp3
media
Storage required for 5.4 TB + 20GB for system

12 months of mp3
media
Server 2: Quality Management
Running Services: RMI, TOOLS, WEB UI, DATABASE
CPU Intel Quad Core 55XX 2.0Ghz or better
RAM 16 GB RAM
HDD Fast storage: 4 x 10,000 rpm for

RAID 10
132
Storage required for Quality Management Databa 200 GB to support external data.
se
Running Services: RMI, CONFIG,CORE, RS/SLR, RTS, DECODER, CC IM,

TOOLS, WEB UI, DATABASE
CPU Intel 8 Core XEON (or dual socket Intel XEON Quad Core) 2.3
Ghz or better
RAM 16 GB
HDD Two options for recording cache (approx 2000 IOPS required by
recording in peaks):
1. SSD having as a total minimum 2,000 IOPS.
enabled to decrease HDD IOPS to acceptable levels
or a combination of both as an ideal candidate: SSD as a fast
write through cache and HDD RAID 10 as a permanent storage.
Storage Example
Maximum concurrent 400

calls

recorded

one month of mp3
media
Storage required for 12 8.8TB + 20GB for system

months of mp3 media
133
This scenario assumes that there will be around 50 supervisors (one supervisor to every eight
agents) accessing Quality Management simultaneously.
This scenario requires two servers:
Server 1: Call Recording recording and decoding modules
Server 2: Quality Management including database, MLM Tools and Call Recording Web
UI
Server 1: Call Recording - 400 Calls
Running Services: RMI, CONFIG,CORE, RS/SLR, RTS, DECODER, CC IM
CPU Intel 8 Core XEON (or dual socket Intel XEON Quad Core) 2.3
Ghz or better
RAM 16 GB
HDD Two options for recording cache (approx 2000 IOPS required by
recording in peaks):
1. SSD having as a total minimum 2,000 IOPS.
enabled to decrease HDD IOPS to acceptable levels
or a combination of both as an ideal candidate: SSD as a fast
write through cache and HDD RAID 10 as a permanent storage.
Storage Example
Maximum concurrent 400

calls

recorded

one month of mp3
media
Storage required for 12 8.8 TB + 20GB for system

months of mp3 media
Server 2: Quality Management
134
Running Services: RMI, TOOLS, WEB UI, DATABASE
CPU Intel XEON Quad Core 2 Ghz or better
RAM 32 GB RAM
HDD Fast storage: 4 x 10,000 rpm for

RAID 10
Storage required for Quality Management Databa 400 GB to support external data.
se
Additional Screen Capture Requirements
Screen Capture deployments require the following hardware specifications in addition to the
Call Recording or Call Recording+ Quality Management scenarios outlined earlier.
The following figures are calculated using the assumption that the estimated bandwidth
required for one Screen Capture session is 400 Kbps.
Screen Capture Sessions CPU MEM HDD
Up to 500 1x Quad (2.5GHz+) 8GB RAM 2xHDD [RAID 1]
Up to 1000 2x Quad (2.5GHz+) 8GB RAM 4xHDD [RAID 10]
Modular Solution for 1000 Concurrent Calls
This scenario distributes Call Recording, Quality Management and Screen Capture modules
(if required) between four or five servers, which have a similar hardware configuration,
differing only in allocated RAM. It is assumed that active recording will be implemented:
Server 1: Config, Call Recording Core, Decoder, Active Recorder
Server 2: Decoder, Active Recorder
Server 3: Decoder, Active Recorder
Server 4: Web Server including Quality Management, Database, MLM Tools. If Quality
Management is not required, only half the RAM is needed.
Server 5: Screen Capture Media Upload Server
The recommended server hardware configuration for these servers is as follows:
Server 1: Main Recorder / Decoder
Running Services: RMI, CONFIG,CORE, SLR, DECODER
CPU Intel XEON Quad Core E55XX 2.3 Ghz or better
RAM 16 GB RAM
HDD Fast storage: 4 x 10,000 rpm for RAID 10
Servers 2 and 3: Recorder / Decoder
135
Running Services: RMI, SLR, DECODER
RAM 8 GB RAM
Server 4: Web Server, Database, Tools
Running Services: RMI, DATABASE, WEB, TOOLS
RAM 32 GB RAM
Server 5: Screen Capture
Running Services: RMI, Screen Capture
RAM 8 GB RAM
The overall recording parameters and storage requirements for this configuration are in the
table below.
Recording Parameters
Percentage of calls recorded 100%
Storage required for one month of mp3 media 1.8 TB + 20GB for system
Storage required for 12 months of mp3 media 22 TB + 20GB for system
136
Ports usage
This section presents a list of the TCP and UDP ports that QM Suite uses for intracluster
connections and communication with external applications or devices. The ports are defaults
and most can be changed by local administrators.
NOTE
In the tables below, we use the following QM Suite service name format: QM Suite
<service name> meaning the server on which a particular QM Suite service is running.
For example, QM Suite configuration service is the QM Suite server on which your
configuration service is operating. This information is crucial for multi-server
deployments. If you have a single-server solution, this server is always your QM Suite
server.
When access is required to or from all QM Suite servers, the term QM Suite server is
used.
QM Suite server ports

External connections
Intracluster communication ports
Databases
Live Monitoring
Screen recording
Cisco Active and Passive Recording
Genesys Active Recording media stream replication
Integration modules
Other services
Additional firewall requirements
Intracluster communication
QM Suite server ports
External connections
Source Destination Port UDP or Purpose

TCP
SSH client QM Suite server 22 TCP Remote shell access
Workstation QM Suite web UI 80 TCP Remote web access http
Workstation QM Suite web UI 8080 TCP Remote web access http
Workstation QM Suite web UI 443 TCP Remote secure web access

https
Workstation QM Suite web UI 8443 TCP Remote web access https
SNMP QM Suite server 199 TCP Monitoring

client
137
SNMP QM Suite server 161 UDP Monitoring (SNMP requests)
client
SNMP QM Suite server 162 UDP Monitoring (SNMP traps)

client
Workstation QM Suite RabbitMQ 55672 TCP RabbitMQ web UI
CIFS client Windows file sharing 445 TCP Sharing windows network
server drives
Intracluster communication ports
The following ports are used for communication between QM Suite servers in a multi-server
deployment. If you have a single-server solution you can disregard this table.
Source Destination Source Destination UDP Purpose

Port Port or
TCP
QM Suite server PostgreSQL - 5432 TCP PotsgreSQL database

server
NFS client NFS server - 111, 2049, TCP NFS file sharing
4001 - +
4004 UDP
QM Suite recorder, QM Suite - 5672 TCP Communication

QM Suite decoder, RabbitMQ between the QM Suite
QM Suite core core, recorder, and
decoder services
QM Suite server QM Suite 1024- 30400 TCP Default RMI port for
server 65535 QM Suite service
intercommunication
QM Suite server QM Suite 1024 - 30401 TCP Communication with

Key 65535 Key Manager
Manager
QM Suite core QM Suite 1024 - 30100 TCP Communication with

SKINNY 65535 the SKINNY service

SIP 65535 the SIP service

JTAPI 65535 the JTAPI service

MSR 65535 the MSR service
138
Databases
Source Destination Port UDP or TCP Purpose
QM Suite server Oracle server 1521 TCP Oracle database
QM Suite server PostgreSQL server 5432 TCP PotsgreSQL database
Live Monitoring
Source Destination Source Port Destination UDP Purpose

Port or
TCP
Workstation QM Suite web UI - 8080 TCP Live Monitoring

session
initialization
Workstation QM Suite - 30400, TCP Loading

configuration service 30500, configuration
30501
QM Suite Workstation 37000-37100 40000-40100 TCP Audio stream

core
QM Suite QM Suite core - 4000-5000 UDP Audio stream

recorders
Workstation QM Suite Screen - 8080 TCP Loading video

Capture uploader stream
Workstation QM Suite core - 30600, TCP Communication

30601 with CORE
Screen recording

TCP
Recorded QM Suite Screen Capture 7003 TCP Registering client with

workstation server server
Recorded QM Suite Screen Capture 8080 TCP Uploading recorded

workstation uploader screens
139
Cisco Active and Passive Recording

TCP
QM Suite CUCM server 80 TCP Downloading of the JTAPI.JAR library

JTAPI
QM Suite CUCM server 2748 TCP Connecting with the CTI Manager
JTAPI
QM Suite CUCM server 8443 TCP Downloading of the JTAPI.JAR library

JTAPI
Phone QM Suite 16384 - UDP Forwarding RTP stream using BIB (4

active recorder 18432 ports per concurrent call)
CUCM QM Suite 5060 TCP or SIP communication

server active recorder UDP
Agent QM Suite web 80, 8080 TCP Prerecording service and requesting call
phone UI lists
QM Suite Agent phone 80 TCP Prerecording service and requesting

web UI device information
Cisco Unified Communications Manager TCP and UDP port usage
Genesys Active Recording media stream replication

TCP
Genesys Resource QM Suite active 5060 TCP SIP communication

Manager recorder
Genesys media QM Suite active 16384 - UDP RTP streams (4 ports per
control platform recorder 18432 concurrent call)
QM Suite core Genesys 2020 TCP Configuration service

configuration connection
server
QM Suite core Genesys T-Server 3000 TCP T-Server communication
QM Suite recorder QM Suite core 30350 TCP Media stream replication

sniffer
140
Source Destination Port UDPor Purpose

TCP
QM Suite Avaya AES 4721 TCP DMCC

core communication
QM Suite Avaya AES 450 TCP TSAPI

core communication
Media QM Suite recorder 9000 - UDP RTP stream port

gateway service 9099
Integration modules
Source Destination Port UDP Purpose

or
TCP
QM Suite UCCE UCCE AWDB 1433 TCP UCCE database

integration module connection
QM Suite UCCE UCCE AWDB 42027 + (instance TCP Connection to CTI

integration module number * 40) Server Side A
QM Suite UCCE UCCE AWDB 42027 + (instance TCP Connection to CTI

integration module number * 40) Server Side A
QM Suite UCCX UCCX server 12028 TCP UCCX integration

integration module
QM Suite Genesys Genesys 2020 TCP Configuration

integration module configuration service connection
server
QM Suite Genesys Genesys 3000 TCP T-Server

integration module T-Server communication
141
Other services

TCP
QM Suite LDAP 389 TCP Log in to web UI using LDAP verification

web UI server
QM Suite LDAP 636 TCP Log in to web UI using LDAPS (over TLS or
web UI server SSL) verification
QM Suite SMTP 25 TCP SMTP port used for emailing from QM Suite
server server server
Additional firewall requirements
Intracluster communication
Additional rules must be followed for the normal functioning of QM Suite clusters:
Heartbeat messages are sent every 15 minutes between the core service and the
active/passive recorders through the AMQP broker. Therefore, if there is a firewall
between the active/passive recorders and the AMQP broker, the firewall must allow the
idle TCP sessions to last for at least 15 minutes.
142
Supported Call Scenarios for Recording
The tables below show the call scenarios that are supported and which can be recorded by
Call Recording:
Cisco Call Scenarios Supported
Genesys SIP Server Call Scenarios Supported
Avaya Call Scenarios Supported
Generic SIP server recording
Cisco Call Scenarios Supported
Call Scenario Cisco Cisco Cisco P Cisco Cisco P CUBE

Active Selective assive Passive assive Active SIP
JTAPI recording Skinny SIP JTAPI recording
Agent to Agent (Basic

call with logged agents
on both sides)
Basic call (Internal

without logged agent)
Call Hold
Blind Transfer
Blind Conference
Call Park
Call Pickup
Barge
cBarge
Join
Direct Transfer
Join Across Lines
Direct Transfer Across

Lines (DTAL)
Shared Lines
Extension Mobility
Ring-Back
143
For Cisco selective recording, the recording starts at the moment the recording request
is triggered by a user.
Genesys SIP Server Call Scenarios Supported
Call Scenario Passive Genesys Driv Genesys Driver

SIP er EPR Active MSR
Agent to Agent (Basic call with logged

agents on both sides)
Basic Call (Inbound and outbound)
Call Hold
Blind Transfer
Blind Conference
Barge
Call Supervision - Monitoring
Call Supervision - Coaching
Avaya Call Scenarios Supported
Call Scenario Avaya Active Avaya EPR
Agent to Agent (Basic call with logged agents on both sides).
Basic call (Internal without logged agent).
Call Hold
Blind Transfer
Blind Conference
144
Generic SIP server recording
To record any other SIP server, the support is as is. Only simple call flows between two
parties are supported. The names of the caller and calling parties are always taken from "TO"
and "FROM" fields. Transfer is supported only via the re-INVITE message. UPDATE message
support isn't implemented.
145
Cisco Selective User Rerecording - Observed Devices concurrence cases
This section describes the behavior of ZOOM Call Recording Server in cases where both/all
call participating parties are using Recorder observed devices. It also describes the expected
Call Recording Server behavior in concurrence cases of automated and selective recording
profiles on participating devices.
The call from A is received and answered by B (figure 1, 1 and 2).

Media streams are sent from device to device (figure 1, 3).
Under (figure 1, 4) a concurrence of recording control methods / rules / actions
can occur.
Below is a summary of the expected results of different recording control concurrence cases.
# concurence Actions result Note
1 A+B press start / First action takes recording control None of

Selective stop / pause the second
/ resume party
actions are
going to
have an
impact.
146
2 A automatic No Automatic Call Recording hold precedence. None of
matching the second
Call is not going to be recorded.
recording party
B selective rule. actions are
going to
press start /
have an
stop / pause
impact.
/ resume
2 A automatic Matching Automatic Call Recording hold precedence. None of

recording the second
Call is going to be recorded.
rule exists. party
B selective actions are
press start /
going to
stop / pause
have an
/ resume
impact.
3 A automatic Matching Automatic Call Recording hold precedence. None of

/ recording the second
Call is going to be recorded.
prerecording rule exists. party
actions are
B selective press start /
going to
stop / pause
have an
/ resume
impact.
4 Conference press start / Recording in conference couple is Each party

stop / pause separated by request of each agent. controls its
All selective
/ resume Recording request started before own
conference is still valid in conference. conference
recording.
4 Conference Same as in Automatic Call Recording hold precedence.

2 Automatic recording requires recording
Automatic
rules to be set, otherwise it blocks selective
and
recording. By matching recording rule each
selective
party with selective recording controls its
mix
own conference couple.
4 Conference press start / Disabled parties are not able to start

stop / pause recording and their conference couples are
selective
/ resume not recorded.
and
disabled mix
5 A Selective no action The Live Monitoring user cannot listen to

the call until the Record button is pressed
and the recording triggered.
147
5 A Selective no action The Live Monitoring user can listen to the
call but not monitor the agent's screen,
since Screen Capture will record only if
there is a recording rule which applies to
the device (such as the phone) or the call.
The Live Monitoring Audio + Screen and
Selective User recording cannot be
configured at once.
5 A Selective Record The Live Monitoring user can listen to the

button call in progress. The monitoring will be
pressed continued even if the phone user press the
Stop button.

button call in progress. The monitoring will be
pressed continued even if the phone user press the
Stop button, and then Start and Stop again.

button call in progress. Not pressing the Stop and
pressed Start buttons nor the use of the Pause and
Resume buttons will stop the monitoring
functions.
6 A selective Using Not supported at the moment. Selective

ZOOM User Recording support will be included in
Finesse an upcoming release.
gadget
7 A Screen Since ZOOM Screen Capture requires

Capture recording rules to be set and applied on a
call, and Selective User Recording
assumes their absence, no actions on
Selective User Recording device will have
any effect since Automatic Recording
based on rules take precedence.
8 A Automatic On selective Since Automatic recording takes

press start precedence, whether the call will or will not
B selective
button. be recorded depends on whether a
recording rule was present at the call arrival
On
time or not. No subsequent recording rule
Automatic
changes, at the automatic or any action at
change
the selective site, will have any impact.
recording
rule
148
8 A+B Trigger Both call parties having Selective
REC.STATE Recording profile, this action will result in
A Selective
for COUPLE NO_STREAM recording.
B Automatic
One party Automatic one Selective,
Automatic takes precedence so the entire
call will be recorded.
9 A+B Record and In environments where, beside the SLR, the

selective and Stop RS recorder is actively used for
button redundancy, a user can trigger the
pressed Selective User recording by pressing the
Record button, and both recorders will start
the recording. But only the SLR can stop
and start again the recording according to
the softkey commands. The RS, once
started, will continue the recording until the
end of the call.
10 A selective Record In a case where the observed extension

button has selective recording profile, the other
B not
pressed/ party isn't observed, and there is a
observed
matching recording rule for that same
no acttion
extension, the call's attached data will be
stored in ZQM while no streams will be
stored.
1. Selective vs. selective

2. Selective vs. automatic
3. Selective vs. prerecording
4. Conference
5. Selective combined with Live Monitoring
6. Selective combined with ZQM Finesse Gadgets
7. Selective combined with screen capture
8. Changing Recording rules or REC STAT
9. Two different recorders in use
10. Selective and a matching rule
149
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
RMI
AMQP Messaging
Core
Protocol Adapters
Passive Recorder Server
Active Recorder Server
Temporary Storage
Decoder Server
Database
Web Application Server
Application Communicator
API
Media Lifecycle Management Tools
Network and Operational Structure Infrastructure
Network Attached Storage
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
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.
150
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.
151
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.
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.
152
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 Management 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.
153
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
customers 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.
154
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.
Network Attached Storage
ZOOM provides support for integration with the following backup solutions.
The following solutions are supported:
Storage solution or type Supported Requirement
SAN (via NFS Protocol) IP of storage and shared directory.
NAS (via NFS Protocol) IP of storage and shared directory.
Centera EMC Storage IP of storage, two EMC Libraries and Pea

file.
Windows Shared Directory (via Username, Password, IP of Windows

CIFS protocol) Server and shared directory.
iSCSI (via IP networks) IP of storage and shared directory.
FTP
SFTP
All storage systems using the NFS (Network File System) protocol are supported by
ZOOM.
155
VMware Recommendations
General VM prerequisites
Storage Recommendations
SAN Requirements for VM machines
SAN Requirements for Interaction Storage
General VM prerequisites
The following prerequisites are minimum standards for virtual machines. If these
standards are not met performance and/or stability issues can occur!
Supported versions of VMware: VMware ESX/ESXi 4.1 and later.
CPU resources must be reserved for each machine (CPU frequency to be reserved,
vCPUs to be mapped to physical cores).
Memory resources must be reserved for each machine.
Redundancy for virtual HDDs is provided the level of the SAN.
VMware Tools must be installed on each machine and be up to date.
Physical servers with Intel CPU 55XX/56XX (5.86GT/s QPI or higher).
I/O throughput is guaranteed (Average Disk sec/Read Write of less than 10ms).
Balloon Driver must be disabled.
Usage of VMXNET 3 network card type is strongly recommended (A corresponding
vmxnet3 driver must be used by the network card(s) within the Linux system).
It is highly recommended that the iputils package should be upgraded to the latest
version (more info: http://rhn.redhat.com/errata/RHBA-2013-1290.html).
ZQM v4.x:
Network card type: Flexible or VMXNET 3
Virtual Hard Drive controller: LSI Logic Parallel or LSI Logic SAS
ZQM v5.x:
Network card type: VMXNET 3
Virtual Hard Drive controller: VMware Paravirtual
Storage Recommendations
Please note that 175 IOPS is roughly the performance of one dedicated 15k rpm HDD.
It is recommended that separate HDDs be split based on their functions and purposes,
however, it is not absolutely necessary:
# Purpose Mount point examples Requirements and

recommendations
1 DB, pcap and recd files /opt/callrec/data/psql High IOPS - 15k rpm
/opt/callrec/data/pcap
2 Media Storage(mp3 and /opt/callrec/data/calls High capacity

mp4 files)
/opt/callrec/data/archive
156
3 Rest, i.e. system and ZQM / -
/tmp/
/home
SAN Requirements for VM machines
The Data Store will use a low latency connection (Fiber Channel or iSCSI).
RAID controller must have sufficient cache .
Storage will consist of SAS 15k rpm HDDs.
SAN Requirements for Interaction Storage
Data Store will use low latency connection (Fiber Channel or iSCSI).
RAID controller must have sufficient cache.
SAS 10k rpm HDDs or faster will be used.
157
HW Server Recommendations
This sections provides recommendations based on our PSS best practices.

Using Broadcom network cards
Using Broadcom network cards
If your QM Suite servers use Broadcom network cards, we recommend checking to see if the
firmware and driver have been updated to the latest version. Old Broadcom drivers and
firmware can cause problems during voice recording.
Both the firmware version and the driver version can be determined using the command:
ethtool -i eth0
Check the versions against the information available from the hardware vendor, and if either
is not up-to-date, then update the driver and/or firmware.
Please note that it is usually necessary to update the driver first, and then update the
firmware.
However, it is strongly recommended that you check the documentation related to the driver
and firmware update procedures in order to avoid any potential issues.
158
Database Type
The type of database chosen depends on the size of recording needs and on how much
evaluation and retrieval of media is needed.
PostgreSQL
Versions
Oracle
PostgreSQL
For small to medium recording solutions the default PostgreSQL database is adequate and is
the most cost effective way of storing calls, screen captures and related data. The
PostgreSQL database is limited to around 200 million call records; above this number queries
are not returned within acceptable limits.
Versions
DBMS QMS QMS QMS QMS QMS QMS QMS QMS

4.9 5.1 5.2 5.3 5.4 5.5 5.6 5.7
PostgreSQL 8.4 9.1.7 9.3.2 9.3.2 9.3.2 9.3.6 9.3.6 9.3.6
Oracle
For larger solutions with over 50 million call records, Quality Management and many
input/output operations per second (IOPS) an Oracle database should be considered. An
Oracle database is also often part of an enterprise database strategy, enabling more efficient
corporate maintenance and backup procedures to be used.
An Oracle database can be used as the only configured database (storing all system and call
data), or it can be used in addition to the embedded PostgreSQL database for specific data,
such as call information. These database mappings can be modified after QM Suite
installation, although a system restart is required after each change is made.
A typical case for the use of mixed database deployments is a larger cluster scenario, where
multiple smaller distributed recorder installations (using embedded PostgreSQL databases)
provide call data to a central Oracle-powered Replay Server.
All Oracle-specific operations such as database installation, setup and maintenance

are the responsibility of the customer; ZOOM doesn't provide direct support for
maintaining Oracle databases as we do for the embedded PostgreSQL database.
QM Suite 5.5.x supports Oracle database versions 11g and above.
159
Operating System
QM Suite can be installed on two operating systems: CentOS (32bit and 64bit) and RedHat
(32bit and 64bit). Based on your requirements choose what operation system you will install:
CentOS
RedHat
32bit/64bit Architecture
CentOS
The QM Suite 5 DVD/ISO contains packages for CentOS 6.6 and starting with release 5.8
CentOS 6.8 so that both the OS and QM Suite packages can be installed from a single
DVD/ISO file.
RedHat
It is necessary to install RedHat before attempting to install any ZOOM products. QM Suite 5
supports Red Hat version 6.6 and starting with release 5.8 Red Hat Enterprise Linux 6.8
edition. Please make sure that your system is properly licensed.
32bit/64bit Architecture
QM Suite 5 can be installed on a 64bit OS. Use of a 64bit OS has the following benefits:
The ability to allocate more than 2GB of memory per process. Which is crucial for
services such as Recorders, Decoders, Integration Modules and Core service.
The ability to use more than 4GB of memory per server without using PAE. Using PAE
in order to allocate more memory on a 32 bit system can cause stability issues.
Using 32 bit software on 64 bit hardware will never allow you to fully utilize the full
potential of your hardware.
You can have a 64 bit PostgreSQL DB installed on the same server as QM Suite. There
is no need for a dedicated DB server.
There is a one limitation associated with moving to a 64 bit solution. The upgrade process for
your existing QM Suite solution from 32 bit to 64 bit will require a full re-installation of your
server along with the restoration of a data backup. This process requires downtime that can
be critical for some customers.
Useful facts about the 64 bit version of QM Suite:
QM Suite 5 is distributed in both architectures: 32bit and 64bit
The Synchro process supports synchronization between 32bit QM Suite deployment
and 64 bit QM Suite deployment. In other words, you can have Recorder clusters in
32bit and the Replay server in 64bit.
The Screen Capture client will remain in 32bit even if you have a 64bit QM Suite.
160
Supported Platforms
This section describes supported platforms and audio/video codecs supported by ZOOM QM
Suite.
Description of support levels
CUCM Cisco Unified Communications Manager
Cisco UCCE Unified Contact Center Enterprise
Cisco UCCX Unified Contact Center Express
Cisco Media Sense
Cisco Finesse
Cisco CUBE
Genesys
AVAYA Aura Communications Manager
Supported codecs
Description of support levels
Fully Supported:
Compatibility with a 3rd party platform version was tested and verified.
Full support is provided by ZOOM.
Limited Support:
3rd party vendors stop providing SW patches for any of their platform version that
reached the End of Software Maintenance state.
ZOOM allows customers to run Call Recording with such a version, however with limited
support.
Call Recording will report a warning when connecting to such a version (currently
implemented in JTAPI only).
Not Supported:
3rd party vendors no longer maintain any of their platform version in the Last Date of
Support state.
Call Recording will connect to such a version, however ZOOM will not support it
anymore.
Call Recording will report a warning when connecting to such a version (currently
implemented in JTAPI only).
Compatible:
Applies to cases where, according to the 3rd party vendor, a platform version is
compatible with our product on the protocol level, however this particular version
combination has not been thoroughly tested.
ZOOM supports this version and customers receive full support in case of any issues.
161
CUCM Cisco Unified Communications Manager
UCM ZQM ZQM ZQM ZQM 5.2 ZQM 5.3 ZQM 5.4 ZQM 5.5 ZQM 5.6
Version 4.9 5.0 5.1
11.0 Compatible Compatible Compatible Compatible Compatible
10.5 Compatible Compatible Compatible Full Full
10.0 Full Full Full Full Full
9.1 Full Full Full Full Full Full
8.6 Full Full Full Full Full Full Full
8.5 Full Full Full Full Full Full Full Full
8.0 Full Full Full Limited Limited Limited Limited N/S
7.0 Full Limited Limited N/S N/S N/S N/S N/S
5.0 N/S N/S N/S N/S N/S N/S N/S N/S
Cisco UCCE Unified Contact Center Enterprise
New CTI based Integration Module (since ZQM 5.2) requires CTI Protocols Version 14
(implemented in UCCE 8.0) or higher.
UCCE ZQM ZQM ZQM ZQM ZQM ZQM ZQM ZQM ZQM 5.7 ZQM
Version 4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.8
11.0 Compatible
10.5 Full Full Full Full
162
8.5 Full Full Full Full Full Full Full Full Full
8.0 Full Full Full Full Full Full Full N/S N/S
7.5 Full Full Full N/S N/S N/S N/S N/S N/S
7.2 Full Limited Limited N/S N/S N/S N/S N/S N/S
Cisco UCCX Unified Contact Center Express
New CTI based Integration Module (since ZQM 4.9) requires CTI Protocols Version 12
(implemented in UCCX 5.0) or higher.
UCCX ZQM ZQM ZQM ZQM 5.2 ZQM 5.3 ZQM 5.4 ZQM 5.5 ZQM 5.6
Version 4.9 5.0 5.1
11.0 Compatible Compatible Compatible Compatible Compatible
10.5 Compatible Compatible Full Full Full
8.0 Full Full Full Full Full Full Full N/S
5.0 Full Limited Limited Limited Limited Limited Limited N/S
163
Cisco Media Sense
MS Version ZQM 5.3 ZQM 5.4 ZQM 5.5 ZQM 5.6 ZQM 5.7 ZQM 5.8
11.0
8.5 N/S N/S N/S N/S N/S
Cisco Finesse
Cisco Finesse integration is available since ZQM version 5.7.
Finesse Version ZQM 5.7 ZQM 5.8
11.0
10.5 Full
10.0 Full
9.1 Full
9.0 Full
8.5 N/S
Cisco CUBE
The direct integration with CUBE is supported from ZQM 5.5 and higher. Older versions are
not listed as they can not be integrated.
CUBE/IOS Version ZQM 5.5 ZQM 5.6 ZQM 5.7 ZQM 5.8
15.4 Full Full Full
Genesys
Genesys Enhanced Passive Recording requires Genesys SIP Server version 7.5 and
newer.
Genesys Active Recording requires Genesys SIP Server and Genesys Media Server version
8.0 and newer.
164
SIPS ZQM ZQM ZQM ZQM ZQM ZQM ZQM ZQM ZQM
Version 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8
8.5
7.5 Limited Limited Limited Limited Limited Limited Limited Limited
AVAYA Aura Communications Manager
CM ZQM ZQM ZQM 5.2 ZQM 5.3 ZQM 5.4 ZQM 5.5 ZQM 5.6 ZQM 5.7
Version 5.0 5.1
6.3 Compatible Compatible Compatible Compatible Compatible Compatible
5.2 N/S N/S N/S N/S N/S N/S N/S
Supported codecs
QM Suite Call Recording supports the following audio and video codecs for recording (each
stream of the call must have the same codec):
G.711 A-law / -Law
G.722 (wideband) - this codec is not supported by Live Monitoring.
G.729 (with Annexes A, B, AB)
H.264 Advanced video codec (MPEG-4 AVC)
165
166
Workstation Requirements
Your desktop or mobile workstation must meet hardware and software requirements so
that QM Suite Web Interfaces function properly:
Minimum Hardware
CPU Intel Core 2 Duo 2GHz+
Memory 2GB RAM
HDD 50 MB
Screen resolution 1024 x 768
Check additional requirements for Screen Capture workstation.
167
Supported Software
Operating Windows 8.1, Windows 8, Windows 7, Windows XP (complete QM Suite)

systems Mac OS X (not supported for Screen Capture only)
Browsers Google Chrome 18+ (33+ is recommended)

Universal Player will not work with the newest version of Chrome
(version 45 and above) as Java is not supported, please deploy
Interaction Player or consider switching browsers.
Internet Explorer 9 with Compatibility View mode disabled (Press F10
and go to Tools > Compatibility View Settings menu. Uncheck Display
Intranet Sites in Compatibility View.)
Internet Explorer 10 and 11 in Desktop mode only and with
Compatibility View mode disabled (Press F10 and go to Tools >
Compatibility View Settings menu. Uncheck Display Intranet Sites in
Compatibility View.)
Firefox 14+ (The replay of video call recordings is not supported within
Firefox.)
For Mac OS X: Safari 7+ and Firefox 14+
The replaying of video call recordings is not supported on the Max OS.
Please download the video files and replay them within an external
player.
Java The latest Java update is recommended.

For Quality Management and Speech Analytics users: Check the list of
supported browsers and Java combinations.
Flash A version of flash is required for playback of media in browsers which do not
support HTML5.
Security Internet Explorer requires additional configuration in order to playback calls

settings from Quality Management Web Interface.
Media Microsoft Windows Media Player

players VLC
QuickTime
Read best practices for choosing the right media player to fit your needs.
Internet Explorer in Metro mode
Internet Explorer 10 or 11 in Windows 8 or 8.1 can run in Metro mode or Desktop mode.
Desktop mode is fully supported and recommended for Windows 8 or 8.1 users.
Internet Explorer 10 or 11 in Metro mode doesn't support plug-ins, therefore audio
playback in Call Recording application and audio/screen capture playback in Quality
Management application does not work. Users shall use Internet Explorer in Desktop
mode, which is fully supported.
168
VMware Fusion Compatibility Notice
Environment: VMware Fusion on Mac OS X running Windows virtual machine, network

connection of virtual machine configured to Shared Network.
Symptoms: When a user accesses the Quality Management application from Windows
virtual machine Quality Management frequently shows the login dialog (as often as once
per minute) even if session timer on the server side is set to long time period (120 minutes
by default).
Solution: Reconfigure the network connection of the virtual machine to Bridged Network.
Supported Browsers according to feature
*Not all features function on all of the browsers listed here! Please refer to
documentation of the specific feature you will use.
The following table lists browser requirements for particular ZOOM features.
Feature Supported browser

Quality Google Chrome 18+ (33+ is recommended)
Management Universal Player will not work with the newest version of Chrome
and (version 45 and above) as Java is not supported, please deploy
Call Internet Explorer 9 with Compatibility View mode disabled (Press
Recording F10 and go to Tools > Compatibility View Settings menu. Uncheck Dis
play Intranet Sites in Compatibility View.)
Firefox 14+ (The replay of video call recordings is not supported
within Firefox.)
Automatic Internet Explorer 10/11

Pause and
Resume
Speech N/A as it requires that Call Recording be installed. (see above
Analytics requirements)
Screen N/A as the software is run independently on an agent desktop

Capture.
Live Live Monitoring runs as a standalone JAVA application separately
Monitoring from the internet browser. The user must have JAVA Runtime
Environment installed for it to work (minimally Version 6). Download it
for free from this URL http://www.java.com/en/download/
169
Cisco Video Google Chrome 18+ (33+ is recommended)
Telephone Universal Player will not work with the newest version of Chrome
(version 45 and above) as Java is not supported, please deploy
Internet Explorer 9 with Compatibility View mode disabled (Press
F10 and go to Tools > Compatibility View Settings menu. Uncheck Dis
play Intranet Sites in Compatibility View.)
Firefox 14+ (The replay of video call recordings is not supported
within Firefox.)
Detailed requirements
The following pages provide more detailed requirements for particular features, media
players and combinations.
Browsers and Java Combinations for Universal Player
Media Player Requirements for Audio and Video Playback in Call Recording
Internet Explorer Security Settings
Screen Capture client PC requirements
170
171
Browsers and Java Combinations for Universal Player
Supported Browsers and Java Combinations for Universal Player
Browser and Version Java Version
Chrome 34.0.1847.116 Java 1.6.0_45
Chrome 34.0.1847.116 Java 1.7.0_40
Chrome 34.0.1847.116 Java 1.7.0_45
Chrome 34.0.1847.116 Java 1.7.0_51
Internet Explorer 9.0.8112.16421 Java 1.6.0_45
Firefox 14.0.1 Java 1.6.0_41-b02
Firefox 14.0.1 Java 1.6.0_45-b06
Firefox 14.0.1 Java 1.7.0_17-b02
Firefox 14.0.1 Java 1.7.0_21-b11
Firefox 28.0 Java 1.6.0_45
Firefox 28.0 (Max OS X) Java 1.7.0_51
Safari 7.0.3 (Mac OS X) Java 1.7.0_51
Unsupported Browsers and Java Combinations for Universal Player
172
The following combinations of Browser version and Java cause issues with Universal
Player.
All versions of Internet Explorer cause issues when combined with Java 1.6. You should
use Java 1.7 with Internet Explorer.
Safari 5 for Windows is unsupported by Apple and does not work with Java applets.
Browser and Version Java Version
Firefox 15.0.1 Java 1.6.0_45-b06
Firefox 15.0.1 Java 1.7.0_21-b11
Firefox 20.0.1 Java 1.6.0_39-b04
Firefox 20.0.1 Java 1.7.0_13-b20
Firefox 20.0.1 Java 1.7.0_21-b11
Internet Explorer 8.0.7601.17514IS Java 1.6.0_37-b06
Internet Explorer 9.0.8112.16421IS Java1.6.0_37-b06
Safari 5.1.7 (Windows only) Java 1.6.0_45
Safari 5.1.7 (Windows only) Java 1.7.0_51
Expired certificate security warning
Java 7 update 55 updated security settings for Java applets, from this version will user get
following security warning in case that certificate used for signing Universal Player expired.
This is applicable only to certain versions of ZQM lower than 5.1.4. It's not applicable to
5.2.0 release.
Security warnings
173
Proposed solution
1. Upgrade to 5.1.5 or 5.2.0 release

2. Change security level in Control Panel - Java - Security to Medium:
174
When Java Security is set to Medium then user will see following dialog where can
user select I accept the risk and want to run this application and press Run butto
n:
175
176
Media Player Requirements for Audio and Video Playback in Call Recording
The following media players are recommended for successful video and audio playback in
Call Recording. The media players are listed in order of preference, for the reasons stated
below:
Player Requirements
Microsoft Plays all audio and video media on the Windows 7 OS. Previous versions of
Windows Windows, for example, Vista and XP, need additional codecs to play video
Media media.
Player Download the K-Lite Codec Pack (BASIC or BASIC Mirror versions) from:
http://www.free-codecs.com/K_Lite_Codec_Pack_download.htm.
VLC Plays combined video and audio recordings, including dual-screen recordings
of 1920x1080 or larger. It is not integrated into browsers such as Internet
Explorer and Firefox for audio playback. VLC is recommended for Mac and
Linux-based systems for combined audio and video reviewing. VLC can be
downloaded at: http://www.videolan.org/vlc/.
QuickTime Plays audio and is integrated into Internet Explorer, but does not support
playing mp3 audio and H.264 format video together for combined audio and
video playback.
Windows Media Player Configuration
The Screen Capture Media Encoder creates the final screen capture media files in MPEG-4
(.mp4) format, which contain H.264 or MPEG-4 2 encoded video and MP3 encoded audio.
Windows-based computers using a version of Microsoft Windows earlier than Windows 7
(Windows Vista, Windows XP, etc.) do not by default include the required MP4 codecs within
the Windows Media Player, so an error will be returned to these systems when attempting to
view downloaded files.
The default Microsoft Windows Media Player version included with Windows 7 is unable to
play H.264 video with dimensions greater than 1920x1080, often making Screen Capture
recordings from PCs with a dual monitor configuration unplayable. To view these large size
recordings on Windows 7, the following workarounds are recommended:
Use an alternative media player, such as the free VLC player, downloadable at:
http://www.videolan.org/vlc/.
OR
Install good quality MP4 codecs as plug-ins for Windows Media Player:
Download the K-Lite Codec Pack (BASIC or BASIC Mirror versions) from the following
web url:
http://www.free-codecs.com/K_Lite_Codec_Pack_download.htm
Run the downloaded .exe installer file, select the simple installation mode and set the
options as follows:
177
After completing the codec installation wizard, downloaded MP4 files will display a Wind
ows Media Player icon in Windows Explorer, and will play correctly when double-clicked
Even though the ZQM mixed audio and Video output files are fully conform with the
MPEG-4 standards some customers reported issues being not able to play these files
on Windows 7 machines with the standard Windows Media Player.
It was not possible to reproduce the situation nor to find any reasons for that behavior.
However such inconveniences can be passed by installing third party Codec pack,
such as
K-Lite Mega Codec Pack for example
178
Internet Explorer Security Settings
Internet Explorer requires additional configuration in order to playback calls from Quality Management Web
Interface
Platform Recommendation
Windows The following recommendations are encouraged for the Web GUI running on
XP Windows XP:
Ensure that the Call Recording URL is included in "Trusted sites", adding it if
necessary. If a user does not have administrator privileges, contact the
system administrator or set the security level of the zone that contains the
server to Low.
Check that there is no proxy enabled in the web browser. If there is, try to
disable it. The proxy can affect the functionality.
Set the security level of trusted sites to Low.
For Internet Explorer 10 and 9 make sure that Document Mode is set to IE8
standards. Press F12 in your Internet Explorer to check the mode.
For Internet Explorer 10 and 9 make sure that Compatibility View mode is
disabled. Press F10 and go to Tools - Compatibility View settings menu.
Make sure that Display intranet sites in Compatibility View is unchecked.
7 Windows 7:
Check that the Call Recording URL is included in "Trusted sites". If not,
include it there. If the user does not have administrator privileges, contact
the system administrator or set security level of the zone that contains the
server to Low.
disable it.
Disable protected mode for all zones. If protected mode is Enabled for the
internet zone, it affects functionality, even if the server is on trusted sites, this
recommendation is for Internet Explorer only.
For Internet Explorer 10 and 9 make sure that Document Mode is set to IE8
standards. Press F12 in your Internet Explorer to check the mode.
For Internet Explorer 10 and 9 make sure that Compatibility View mode is
disabled. Press F10 and go to Tools > Compatibility View settings menu.
179
8, 8.1 Windows 8 and Windows 8.1:
Check that the Call Recording URL is included in "Trusted sites". If not,
include it there. If the user does not have administrator privileges, contact
the system administrator or set security level of the zone that contains the
server to Low.
disable it.
Disable protected mode for all zones. If protected mode is Enabled for the
internet zone, it affects functionality, even if the server is on trusted sites, this
recommendation is for Internet Explorer only.
For Internet Explorer 9 and above make sure that Document Mode is set to I
E8 standards. Press F12 in your Internet Explorer to check the mode.
For Internet Explorer 9 and above make sure that Compatibility View mode
is disabled. Press F10 and go to Tools > Compatibility View settings menu.
Compatibility View settings:
180
Screen Capture client PC requirements
CAUTION
If you have a firewall between the QM Suite servers and agent workstations, you must
open the appropriate ports so that the Screen Capture clients can connect to your QM
Suite server. Further information regarding port usage can be found on Ports usage.
Hardware requirements
Minimal hardware requirements:

CPU: Intel Core 2 Duo 2 GHz+
Memory: 2 GB RAM
HDD: 50 MB
Operating systems
Supported systems:
Windows XP SP3 32 bit
Windows Vista
Windows 7 86 and 64
Windows 8 86 and 64
Unsupported systems:
Windows XP 64 bit
Bandwidth
The required bandwidth can be easily calculated using this formula:

(X*Y*CD/8*FPS)/1024*0.33*0.08
Where:
X x- is the resolution of the recorded monitor.
Y y- is the resolution of the recorded monitor.
CD is the color depth of the recorded monitor.
FPS are the frames per second (this is a configurable parameter in the screen
recording service).
The equation result is the required bandwidth per monitor in kB/sec. If agents have two
monitors, use the equation to calculate the bandwidth for each monitor and add the results.
Examples
The following table presents the most common outputs from agent workstation and Screen
Capture settings.
We use 24 bits for the color depth.
X resolution Y resolution Number of LCDs FPS Required bandwidth

between SCC* and SRU* (kB/sec)
181
1024 768 1 1 61
1280 1024 1 1 101
1600 1200 1 1 149
1920 1080 1 1 160
1920 1200 1 1 178
1920 1080 2 1 321
1024 768 1 2 122
1280 1024 1 2 203
1600 1200 1 2 297
1920 1080 1 2 321
1920 1200 1 2 356
1920 1080 2 2 642
1024 768 2 2 243
1280 1024 2 2 406
1600 1200 2 2 594
1920 1080 2 2 642
1920 1200 2 2 713
1920 1080 2 2 642
*SCC Screen Capture client

*SRU Screen Capture uploader The part of the Screen Capture service that can run on a
dedicated server in cluster deployments.
182
Installation
The installation process consists from two separate steps that should be done one after
another
Prerequisites: Preparing for Oracle
183
Before you install ZOOM Quality Management, follow these steps to prepare your contact
center platform for recording:
Cisco Active 1. Configure CUCM for all types of recording.

Recording 2. Configure CUCM for Active Recording.
3. If the solution is integrated with a Contact Center, complete the
corresponding steps:
Configuring UCCE for integration with ZQM.
Configuring UCCX for integration with ZQM.
Configuring Genesys CIM for integration with ZQM.
4. If the solution includes the Prerecording service, configure CUCM
for Prerecording.
Cisco Passive Preparatory steps:

Recording
1. Configure CUCM for all types of recording.
2. Configure SPAN ports.
3. If the solution is integrated with a Contact Center, complete the
corresponding steps:
Configuring UCCE for integration with ZQM.
Configuring UCCX for integration with ZQM.
Configuring Genesys CIM for integration with ZQM.
Genesys Active 1. Configure Genesys CIM For Active recording.

Recording
Genesys Passive 1. Configure Genesys CIM for Enhanced Passive Recording (EPR)
Recording
Avaya Active 1. Configure Avaya CM for Active Recording.
Recording 2. If the solution is integrated with Genesys CIM, configure your
Genesys platform for integration with ZQM.
184
Preparing Avaya for integration
This section describes the steps you need to take in order to prepare your Avaya environment
for integration with QM Suite.
Please choose your recording method:
Preparing Avaya for Active Recording
Preparing Avaya for EPR
Limiting the number of observed devices on Avaya
185
Preparing Avaya for Active Recording
Adding a CTI User

Enabling Unrestricted Access for the CTI User
Configuring the DMCC Port
Enabling the Security Database
Determining What the Alias for the Switch Is
Setting the IP Address for the H.323 Gatekeeper
Determining the Tlink Name
Create a virtual device on Avaya CM
Final checks
Next steps
Adding a CTI User
QM Suite requires a CTI user to access Application Enablement Services.

1. Access the OAM web interface of the Applications Enablement Services. The Manag
ement Console login page displays.
2. Log on to the AES Management console using the appropriate username and
password.
The Welcome to OAM page displays:
3. On the AES Management Console navigate to User Management > User Admin >
Add User.
The Add User page displays:
4. Type the username in the User Id field, for example, zoom.
Type the name in the Common Name field.
Type the name in the Surname field.
Type the password in the User Password field.
Confirm the password in the Confirm Password field.
5. Select Yes from the CT User drop-down list.
6. Click Apply at the bottom of the screen.
Retain the user ID and password so that they can be used when setting up Call Recording.
1. On the AES Management Console navigate to Security > Security Database > CTI
Users > List All Users.
In the CTI Users window, select the User ID set up in the Add User page and select
the Edit option.
The Edit CTI User page displays.
Verify that the user created appears in the list:
2. Select the Unrestricted Access checkbox.
3. Click Apply Changes.
Configuring the DMCC Port
1. On the AES Management Console navigate to Networking > Ports.

The Networking Ports screen displays:
2. In the DMCC Server Ports section, set the Unencrypted Port (usually 4721) and select
Enabled.
186
1. On the AES Management Console, navigate to Security > Security Database

>Control.
The SDB Control for DMCC and TSAPI page displays:
2. Select the Enable SDB for DMCC Service checkbox.
Select the Enable SDB TSAPI Service, JTAPI and Telephony Service checkbox.
Determining What the Alias for the Switch Is
1. On the AES Management Console navigate to Communication Manager Interface >

Switch Connections.
The Switch Connections page displays.
The Alias for the switch is in the Connection Name field.
1. On the AES Management Console navigate to Communication Manager Interface

>Switch Connections:
2. Add CM Name or IP Address:
1. On the AES Management Console navigate to Security > Security Database >Tlinks:
2. Make sure you select the non-secure Tlink Name. Secure Tlink is not supported.
a. Determine whether the Tlink is not secure with the "CSTA" keyword:
If there is "CSTA-S" it means that the Tlink is secure.
If there is "CSTA" it means the Tlink is non-secure.
b. If there is no non-secure Tlink in the list, set Tlink to either "Unencrypted" mode or to "Both"
mode under "AE Services - TSAPI - TSAPI Links" in the configuration of AES.
This section covers how to create a virtual device on Avaya CM.

1. On CM create new station (in ZOOM terminology = device):
CMD: add station extension Number|next
Device type: 4624 (it's represents all soft phones)
IP Soft Phone: Y
Security code: <for all device same, used in CR configuration> =
Associate COR: x (COR with enable Service Observation)
187
2. Validate COR:
CMD: display cor x
CMD change: change cor x
Can be a Service Observer?: Y
Next configure AES.

Final checks
After following the steps above you should be able to provide the following info:
AES server IP address.
Switch connection
TSAPI Provider Tlink
TSAPI username and password(CTI User for TSAPI can be same as for DMCC)
TSAPI port
DMCC username and password(CTI User for DMCC can be same as for TSAPI)
DMCC port.
Recording Device Range
IP Station Security Code
UCID configuration check

QM Suite is using UCID (Universal Call Identification) for call identification.
188
This UCID must be correctly propagated to Avaya driver in QM Suite. To have this
UCID propagated correctly make sure:
On Avaya Site Administrator command window
Type the command 'change system-parameters features'.
Enable the following features on the CM in order to get UCID in service initiated
event:
Create Universal Call ID (UCID) to 'y' (Setting to 'y' indicates that UCID will be
generated for each call) (Page 5.).
UCID network Node ID to 1 (or any number between 1 to 32767 and unique to
the switch in the network)(Page 5.).
Send UCID to ASAI to 'y' (Setting to 'y' enable transmission of UCID information)
(Page 13.).
Type the command 'change trunk-group N'.
Enable the 'Send UCID' field from page 3 for each trunk group that is used for
communication between CM systems. This field specifies whether or not the
trunk should transmit Universal Call IDs. Sending UCIDs in a network of CMs
allows an application server that interworks with all of them to realize it already
has handled a call when it is transferred to an agent on another switch.
If the UCID is not propagated correctly the default value of UCID is captured:
00000000000000000000
Next steps
Configure QM Suite
189
Providing access to SMS WS

Creating an Administrator user in the Communication Manager
Downloading a certificate
Configuring AES
Adding a CTI User
Finding out What the Alias for the Switch Is
Configure SPAN
Final checks
Next steps
The following configuration is a prerequisite to using Enhanced Passive recording via the
Avaya platform with the Avaya Aura Communication Manager. The following configuration is
not configured on the AVAYA environment but within the network environment.
Providing access to SMS WS
Creating an Administrator user in the Communication Manager
An Administrator account on Communication Manager is required to be used to access SMS

WS. To create it follow these steps:
1. Login to your Avaya Communication Manager and go to Administration >
Server(Maintenance) > Security > Administrator Accounts:
190
Select Privileged Administrator and click Submit.
2. Provide a Login Name and Password:
Click Submit.
3. You should see the following confirmation if user creation went well:
Click Continue.
Downloading a certificate
QM Suite requires a SMS WS certificate to communicate with the service. The certificate can
be easily downloaded by accessing the Avaya AES using your browser via https. The server
will provide you the web certificate that is used to communicate with the SMS WS.
191
Later, when you install your QM Suite, you will need to upload the certificate there: Certificate
management tool
Configuring AES
Adding a CTI User
QM Suite requires a CTI user to access Application Enablement Services.

1. Access the OAM web interface of the Applications Enablement Services. The Manag
ement Console login page displays:
2. Log on to the AES Management console using the appropriate username and
password.
The Welcome to OAM page displays:
3. On the AES Management Console navigate to User Management > User Admin >
Add User.
The Add User page displays:
4. Type the username in the User Id field, for example, zoom.
Type the name in the Common Name field.
Type the name in the Surname field.
Type the password in the User Password field.
Confirm the password in the Confirm Password field.
5. Select Yes from the CT User drop-down list.
6. Click Apply at the bottom of the screen.
Retain the user ID and password so that they can be used when setting up Call Recording.
1. On the AES Management Console navigate to Security > Security Database > CTI
Users > List All Users.
In the CTI Users window, select the User ID set up in the Add User page and select
the Edit option.
The Edit CTI User page displays.
Verify that the user created appears in the list:
2. Select the Unrestricted Access checkbox.
1. On the AES Management Console, navigate to Security > Security Database

>Control.
The SDB Control for DMCC and TSAPI page displays:
192
2. Check that Enable SDB for DMCC Service checkbox is deselected. (It is deselected by
default).
Select the Enable SDB TSAPI Service, JTAPI and Telephony Service checkbox.
Finding out What the Alias for the Switch Is
1. On the AES Management Console navigate to Communication Manager Interface >

Switch Connections.
The Switch Connections page displays.
The Alias for the switch is in the Connection Name field.
1. On the AES Management Console navigate to Communication Manager Interface

>Switch Connections:
2. Add CM Name or IP Address:
1. On the AES Management Console navigate to Security > Security Database >Tlinks:
Configure SPAN
It is necessary to configure the SPAN port. Please follow the recommended steps on the page
SPAN port configuration.
Final checks
After following the above steps you should be able to provide the following info:
AES server IP address
Switch connection
TSAPI Provider Tlink
TSAPI username and password - CTI user credentials created on AES.
TSAPI port - default port: 450
SMS URL - https://<AES server hostname or IP
address>/smsxml/SystemManagementService.php
SMS username and password - user credentials created on Communication Manager.
Recording Device Range
193
IP Station Security Code(optional)
Next steps
Configure QM Suite
194
Limiting the number of observed devices on Avaya
Within the Avaya Application Enablement Services console it is possible to limit the number of
observed devices by limiting the users ability to monitor specific devices.
To limit a users access to a particular set of devices it is necessary to first edit a user and limit
that user so that they may only control or monitor a specific Device Group.
Limiting the number of observed devices
To configure this follow the steps below:

1. Log into the Avaya Application Enablement Services console.
2. Create a new user under User Management.
Ensure that the user has useradmin rights and that the CT User checkbox is
checked
195
3. Create a new Device group under Security > Security Database > Device Groups.
Check the box of each phones or recording devices that you want to add as a
member of this group.
4. Edit the user you created in step #2 under Security > Security Database > CTI Users.
196
4.
5. Limit the user to be able to Control/Monitor only the devices from the group you created
in step #2. To do this select the group from the drop down menus.
Make sure to check the box Call Monitoring
Please note that this is not possible to do when the user is set to "Unrestricted" mode.
therefore the Station Security Codes must be configured correctly on the devices as
well as in Call Recording.
197
Preparing Cisco for integration
This section describes the steps preparing the Cisco environment for integration with QM
Suite:
Preparing CUCM for All Recording Types
Preparing CUCM for active recording for phone BIB
Preparing CUCM for selective recording
Configuring CUBE for Active SIP Recording
Configuring CUBE for Video Call Recording
Integration: UCCE
Integration: UCCX
Preparing CUCM for prerecording
Preparing CUCM for MediaSense integration
198
Preparing CUCM for All Recording Types
Create an Application User, for CUCM 6.x and higher

Partitions and Calling Search Spaces
Extension Mobility
Create an Application User, for CUCM 6.x and higher
The creation of an Application User enables Call Recording to observe controlled devices
(phones). Include a device in Controlled Devices only for phones to be recorded. The
omission of a phone in controlled devices results in a No streams recorded error in Call
Recording.
Login to Cisco Unified Communications Manager Administration.
Navigate to User Management > Application User.
Click Add New. This dialog displays:
199
1. Type a User ID, for example, callrec.
2. Type a password in the Password field. For example, callrec. Type the same password in
the Confirm Password field. Write down the login name and password. Enter the same
username and password when you install the JTAPI Client Library.
1. Select the Available Devices, using the arrows.
Please note that one JTAPI process can handle maximum 1000 devices. So if you
have more than 1000 devices to observe by this user then create additional users and
assign them to appropriate JTAPI adapters in QM Suite. More information about
creating more JTAPI adapter can be found here Connecting to Two Independent
CUCM Clusters
200
2. Click Add to User Group. The Find and List dialog box opens.
Click Find. The Find and List dialog opens.
This user should have privileges to see all users to be recorded or monitored.
Assign these roles to the Application User:
1. Standard CTI Allow Call Park Monitoring.
2. Standard CTI Allow Call Recording (For Active recording only. Unnecessary for
SPAN-based recording).
3. Standard CTI Allow Control of Phones supporting Connected Xfer and conf (Cisco
89xx and 99xx series phones in CUCM 7.1 and higher).
4. Standard CTI Allow Control of Phones supporting Rollover Mode
5. Standard CTI Enabled.
6. Standard CCM Read-only - required only if Prerecording service is used.
Click Add Selected.
201
Click Save On the Application User Configuration.
Partitions and Calling Search Spaces
Partitions and Calling Search Spaces enable calling restrictions and closed dialing plans on
Cisco CallManager. They also allow the use of the most cost-effective routes.
Partitions
A partition contains a group of directory numbers (DNs), translation patterns, and route
patterns with similar characteristics.
Calling Search Spaces
Enable users to find DNs, translation patterns, and route patterns within partitions.
A calling search space is an ordered list of partitions that you can view before you place a
call. The calling search spaces determine the partitions that calling devices can search when
they try to complete a call. This effectively limits which DNs the device can contact. The
partitions' order in the calling search space can determine the partition selected, where two
otherwise equal partitions would be selected.
Further Reading
For CUCM 9, see Partitions and Calling Search Spaces in the Cisco CallManager
Administration Guide.
Extension Mobility
Where Extension mobility is used in addition to the device configuration, the device profile
should be configured.
202
Configuring CUCM for secure JTAPI
There is an option to secure the connection between the Cisco Unified Communications
Manager (CUCM) and QM Suite. The following steps are additional to the steps required for
Preparing CUCM for all recording types.
If your deployment does not require a secure JTAPI connection please skip this section.
Secure the JTAPI user
Create a CAPF profile
Secure the JTAPI user
Add the JTAPI application user to the following groups:

1. Standard CTI Secure Connection
2. Standard CTI Allow Reception of SRTP Key Material
Create a CAPF profile
1. Go to User Management > User Settings > Application User CAPF Profile.
2. Click Add new.

3. Type in the following fields.
203
a. Application User - Select the application user you configured when you were Pre
paring CUCM for all recording types.
b. Instance Id - Type a unique identification string which is used in the authentication
process.
c. Certificate Operation - Choose Install/Upgrade.
d. Authentication Mode - Choose By Authentication String.
e. Authentication String - Type or generate the string that will be used by the QM
Suite JTAPI service to download the CUCM certificate.
4. Click Save.
You are now ready to install the CUCM certificate on the QM Suite server. The
certificate-installation process is described here: Configuring the JTAPI adapter - Configuring
the security settings.
204
Preparing CUCM for active recording for phone BIB
Create an SIP trunk to point to the recorder

Create a route group and assign the SIP trunk (for HA only)
Create a route list and assign the route group (for HA only)
Create a route pattern for the recorder
Create a recording profile
Apply the recording profile to the device
Enable the phone BIB to allow recording
Enable the phone BIB for all devices
Enable the phone BIB and control from CTI phone by phone
Configure tones for recording (optional)
Reset the trunk
The SIP trunk points to the recorder.

Create one standard, non-secure SIP trunk for each recorder.
1. Select Device > Trunk. The Find and List Trunks dialog opens.
2. Select Add New.
1. Select the relevant Trunk Information, as shown in the following image.

2. Leave the default values for all the other options. The number of options varies based
on your application version.
3. Select Next.
205
The Trunk Configuration window opens.
Type the Device Name and a (optional) Description, as shown in the following image.
Select a Device Pool from the drop-down menu. The device pool should be the same as the
one that the phones are in.
206
Scroll down to SIP Information:
1. Set the Destination Address to the SLR server IP address.
2. Select an SIP Trunk Security Profile from the drop-down menu.
3. Click Save.
The following two sections are required for high-availability (HA) scenarios only. If you have
only one recorder, continue preparing CUCM here.
Add a route group and a pattern to ensure that the recording profile and SIP trunk are
associated.
NOTE
For an installation with only one active recorder (SLR), configure the route pattern of
the SIP trunk directly. Redundant (HA) installations require the configuration of route
groups and route lists.
The correct distribution algorithm is the top-down method. If you select the circular
method, each stream is forwarded to a different recorder server, which is inefficient.
To create a route group and assign the SIP trunk, complete the following steps:
207
Select Call Routing > Route/Hunt > Route Group.
Click Find.
Select the Route Group.
The Route Group Name displays.

1. Assign the SIP trunks to the Selected Devices.
2.
208
2. Click Add to Route Group. The SIP trunk appears in the Current Route Group
Members list.
3. Click Save.
NOTE
Skip this task if HA is not required.
The route list contains only one route group. This includes both primary and secondary
recorders (SIP trunks).
Select Call Routing > Route/Hunt > Route List.
Click Find.
209
Select the Route List.
Click Add Route Group.
1. Select the Route Group from the drop-down menu.

2. Click Save.
210
The route pattern points to the route list in HA scenarios only. Otherwise, the route pattern
points directly to the SIP trunk.
Select Call Routing > Route/Hunt > Route Pattern.
Click Add New.
211
1. Enter the Route Pattern.
2. Select the SIP trunk or route list that you created as the Gateway/Route List.
3. Click Save.
The recording destination address is not an IP address. The address is a directory number.
For example: 9105.
NOTE
Refer to the numbering plan to select a number for the recording profile. Use an
extension number that is not already assigned.
Select Device > Device Setting > Recording Profile.
212
The Recording Profile dialog opens.
Select Add New.
The Recording Profile Configuration dialog opens.

1. Name the profile.
2. Type the Recording Destination Address (the number assigned to the route pattern
that you created in the previous section).
3. Click Save.
213
Select Device > Phone:
The Phone dialog opens.

Click on your Device. The device is agent1 in this example.
The Phone Configuration dialog opens.

Click Line [1] -1111 (no partition):
The Directory Number Configuration dialog opens.

Under the Directory Number Information section, note that the Allow Control of Device
from CTI is enabled. Typically this check box is enabled by default, but verification is vital
214
because calls won't be recorded otherwise.
Next:
1. Scroll down to the Line 1 section on [your device's name]. In this example, this is
labeled Line 1 on Device agent1.
2. For the Recording Option*, select Automatic Call Recording Enabled.
3. Set the Recording Profile.
4. Click Save.
5. Click Apply Config to activate the configuration on the phone.
You can activate the Built-In Bridge (BIB) on the service parameter level for all devices. You
can also activate it phone by phone. For an up-to-date list of all Cisco phones that support
active recording, see the Unified CM Silent Monitoring Recording Supported Device Matrix.
This method is useful for recording all phones.

Select System > Service Parameters:
215
1. Select your Server.
2. Then select the service Cisco CallManager (Active).
The Service Parameter Configuration screen opens:

1. Scroll down to Clusterwide Parameters (Device Phone).
2. Ensure that Builtin Bridge Enable is On.
216
This method is useful for adding specific phones or devices to be recorded. Enable recording
for each line. A phone or device can have several numbers. Configure each number
separately.
1. Select a parameter from the Find Phone where drop-down menu. For example, select
Device Name and type in the first letters or first digits to select an individual phone
2. Click Find:
Select the device:

In the Device Information section:
1. Set the Built In Bridge to On.
2.
217
2. Enable the Allow Control of Device from CTI option.
3. Click Save.
4. Click Apply Config to apply the configuration to the phone.
Skip this step if you don't want an audible recording notification tone.
218
The Service Parameter Configuration dialog displays.
1. Select the server from the drop-down menu.
2. Select Cisco CallManager (Active) from the drop-down menu.
Scroll down to Clusterwide Parameters (Feature Call Recording). Use CTRL+F to find it
quickly.
1. Set Play Recording Notification Tone to Observed Target to True.
2. Set Play Recording Notification to Observed Connected Parties to True.
Reset the trunk
To complete the changes, reset the trunk.

Select Device > Trunk:
Click Find to obtain a list of trunks.
219
Enable the check box for your trunk and click Reset Selected:
Select the check box of your trunk and click Reset Selected.
A the Device Reset dialog opens.
Click Reset and then click Close,
220
Configuring CUCM for SRTP
This section describes the prerequisites for enabling secure SIP and secure RTP (SRTP).
Secure SIP trunk configuration
Create a SIP trunk security profile
Apply the user profile to the secure SIP trunk
Secure SIP trunk configuration
Before you can start configuring the trunk, you must create an SIP trunk security profile that
enables the SIP trunk to communicate over TLS.
Create a SIP trunk security profile
1. Select Cisco Unified CM Administration from the Navigation drop-down menu.
2. Log in as the Cisco Unified Communications Manager (CUCM) application

administrator.
3. Go to System > Security > SIP Trunk Security Profile.
221
4. Click Add new.
5. Type in the following details:
222
a. Name - Enter a unique identification for the profile. For example, SIP_Trunk_Secu
re_profile_Call Recording.
b. Description - Enter an optional description of the profile.
c. Device Security Mode - Choose Encrypted from the drop-down menu.
d. Incoming Transport Type - Select TLS from the drop-down menu.
e. Outgoing Transport Type - Select TLS from the drop-down menu.
f. X.509 Subject Name - Type the common name of your active recorder's
certificate. This is usually the fully qualified domain name of your QM Suite server.
For example: callrec.company.com (type the value without first typing CN=).
g. Incoming Port - Type in 5061.
h. Select the Transmit security status check box.
6. Click Save.
Apply the user profile to the secure SIP trunk
The following steps are required to enable a secure connection to your existing SIP trunk after
you have prepared CUCM for active recording. Directions for preparing CUCM can be found
at the following link: Preparing CUCM for active recording - Create an SIP trunk to point to the
recorder.
1. Go to Device > Trunk.
223
1.
2. Click Find to display your existing SIP trunks.

3. Select the desired trunk.
4. Go to the Device Information section:
Select SRTP Allowed.

Select When using both sRTP and TLS from the Consider Traffic on This
Trunk Secure drop-down menu.
Verify that the Media Termination Point Required option is not selected because
the media termination points (MTPs) don't support secure media.
5. Scroll down to the SIP Information section.
Ensure the Destination Port is 5061.

Select the created security profile from the SIP Trunk Security Profile drop-down
menu.
6. Click Save.
CUCM is now configured for SRTP.
There are additional steps that need to be performed on your QM Suite server to have
Secure RTP enabled. They can be found here: Configuring SRTP for the active
recorder
224
Preparing CUCM for selective recording

Reset the trunk
The SIP trunk points to the recorder.

Create one standard, non-secure SIP trunk for each recorder.
1. Select Device > Trunk. The Find and List Trunks dialog opens.
2. Select Add New.
1. Select the relevant Trunk Information, as shown in the following image.

2. Leave the default values for all the other options. The number of options varies based
on your application version.
3. Select Next.
225
The Trunk Configuration window opens.
Type the Device Name and a (optional) Description, as shown in the following image.
Select a Device Pool from the drop-down menu. The device pool should be the same as the
one the phones are in.
226
Scroll down to SIP Information:
1. Set the Destination Address to the SLR server IP address.
2. Select an SIP Trunk Security Profile from the drop-down menu.
3. Click Save.
The following two sections are required for high-availability (HA) scenarios only. If you have
only one recorder, continue preparing CUCM here.
Add a route group and a pattern to ensure that the recording profile and SIP trunk are
associated.
NOTE
For an installation with only one active recorder (SLR), configure the route pattern of
the SIP trunk directly. Redundant (HA) installations require the configuration of route
groups and route lists.
The correct distribution algorithm is the top-down method. If you select the circular
method, each stream is forwarded to a different recorder server, which is inefficient.
To create a route group and assign the SIP trunk, complete the following steps:
227
Select Call Routing > Route/Hunt > Route Group.
Click Find.
Select the Route Group.
The Route Group Name displays.

1. Assign the SIP trunks to the Selected Devices.
2.
228
2. Click Add to Route Group. The SIP trunk appears in the Current Route Group
Members list.
3. Click Save.
NOTE
Skip this task if HA is not required.
The route list contains only one route group. This includes both primary and secondary
recorders (SIP trunks).
Select Call Routing > Route/Hunt > Route List.
Click Find.
229
Select the Route List.
Click Add Route Group.
1. Select the Route Group from the drop-down menu.

2. Click Save.
230
The route pattern points to the route list in HA scenarios only. Otherwise, the route pattern
points directly to the SIP trunk.
Select Call Routing > Route/Hunt > Route Pattern.
Click Add New.
231
1. Enter the Route Pattern.
2. Select the SIP trunk or route list that you created as the Gateway/Route List.
3. Click Save.
The recording destination address is not an IP address. The address is a directory number,
for example, 9105.
NOTE
Refer to the numbering plan to select a number for the recording profile. Use an
extension number that is not already assigned.
Select Device > Device Setting > Recording Profile.
232
The Recording Profile dialog opens.
Select Add New.
The Recording Profile Configuration dialog opens.

1. Name the profile.
2. Type the Recording Destination Address (the number assigned to the route pattern
that you created in the previous section).
3. Click Save.
233
The Phone dialog opens.

Click on your Device. The device is agent1 in this example.

Click Line [1] -1111 (no partition):
The Directory Number Configuration dialog opens.

Under the Directory Number Information section, note that the Allow Control of Device
from CTI is enabled. Typically this check box is enabled by default, but verification is vital
234
because calls won't be recorded otherwise.
Next:
1. Scroll down to the Line 1 section on [your device's name]. In this example, this is
labeled Line 1 on Device agent1.
2. For the Recording Option*, select Selective Call Recording Enabled.
3. Set the Recording Profile.
4. Click Save.
5. Click Apply Config to activate the configuration on the phone.
You can activate the Built-In Bridge (BIB) on the service parameter level for all devices. You
can also activate it phone by phone. For an up-to-date list of all Cisco phones that support
active recording, see the Unified CM Silent Monitoring Recording Supported Device Matrix.
This method is useful for recording all phones.

235
1. Select your Server.
2. Then select the service Cisco CallManager (Active).
The Service Parameter Configuration screen opens:

1. Scroll down to Clusterwide Parameters (Device Phone).
2. Ensure that Builtin Bridge Enable is On.
236
This method is useful for adding specific phones or devices to be recorded. Enable recording
for each line. A phone or device can have several numbers, so configure each number
separately.
1. Select a parameter from the Find Phone where drop-down menu. For example, select
Device Name and type in the first letters or first digits to select an individual phone.
2. Click Find:
Select the device:

In the Device Information section:
1. Set the Built In Bridge to On.
2.
237
2. Enable the Allow Control of Device from CTI option.
3. Click Save.
4. Click Apply Config to apply the configuration to the phone.
Skip this step if you don't want an audible recording notification tone.
238
The Service Parameter Configuration dialog displays.
1. Select the server from the drop-down menu.
2. Select Cisco CallManager (Active) from the drop-down menu.
Scroll down to Clusterwide Parameters (Feature Call Recording). Use CTRL+F to find it
quickly.
1. Set Play Recording Notification Tone to Observed Target to True.
2. Set Play Recording Notification to Observed Connected Parties to True.
Reset the trunk
To complete the changes, reset the trunk.

Select Device > Trunk:
Click Find to obtain a list of trunks.
239
Enable the check box for your trunk and click Reset Selected:
Select the check box of your trunk and click Reset Selected.
A Device Reset dialog opens.
Click Reset and then click Close.
240
Configuring CUBE for Active SIP Recording
The following steps describe how to configure the Cisco Unified Border Element (CUBE) for
Cisco Active SIP Recording
Preparing CUBE
Configuration steps
Preparing CUBE
The following conditions are required in order to start configuring CUBE for ASR:
you must have the router configured as the voice gateway. Please review Cisco docume
ntation for complete details.
Configuration steps
Log in to the command line of your voice gateway:

1. Switch the command line to privileged mode:
enable
2. Enable the configuration mode:

configure terminal
3. Add Call Recording to the list of trusted IP addresses

voice service voip
ip address trusted list
ipv4 <ipaddress1> <mask>
4. Validate the codec voice preference: <codecTag>
NOTE
For various codecs please refer to codec preferences in the Cisco
documentation.
5. Create the media profile recorder:

media profile recorder <mediaTag>
media-recording <recordNumber1> <recordNumber2>
More record numbers for HA only. There can be up to 6 numbers.

6. Create the media class:
241
6.
media class <mediaClass>

recorder profile <mediaTag>
7. Modify the dial peer voice <tag> voip by adding this line:
media-class <mediaClass>
8. Define the connection to the recorder by adding all of the following lines:
dial-peer voice <dialPeerTag1> voip
destination-pattern <recordNumber1>
signaling forward none
session protocol sipv2
session target ipv4:<IP address of Call Recoding server
cluster A>
voice-class codec <codecTag>

cluster B>
voice-class codec <codecTag>
9. Terminate your use of configuration mode:

end
10. Save the configuration:

copy running-config startup-config
For a detailed description of CUBE configuration, see the Cisco documentation on dial-peer
forking.
Your CUBE platform is now ready for integration with QM Suite. To start recording calls
please complete the configuration of your QM Suite server by following the steps described in
the page: Single Server Configuration
242
Configuring CUBE for Video Call Recording
Preparing CUBE
Configuration steps
Additional Configuration
Preparing CUBE
The following steps describe how to configure the Cisco Unified Border Element (CUBE) for
video call recording
The following conditions are required in order to start configuring CUBE for ASR:
You must have the router configured as the voice gateway. Please review Cisco docum
entation for complete details.
For limitations of the Cisco Video Call Recording please refer to the Vendors Website.
Configuration steps
For the configuration related to Cisco Video recording please review Cisco documentation.
Log into the command line of your voice gateway:
1. Switch the command line to privileged mode:
enable
2. Enable the configuration mode:

configure terminal
3. Add Call Recording to the list of trusted IP addresses
voice service voip

ip address trusted list
for video recording

asymmetric payload full
4. Validate the codec voice preference: <codecTag>
For various codecs please refer to codec preferences in the Cisco

documentation.
5. Create the media profile recorder:
243
5.
media profile recorder

media-recording <recordNumber1> <recordNumber2>
More record numbers for HA only. There can be up to 6 numbers.

6. Create media profile video.
Please configure this part only if video recording is deployed.
media profile video <mediaTag>

monitor-ref-frames ref-frame-req rtcp retransmit-interval 50
retransmit-count 4
ref-frame-req sip-info
7. Create the media class:

recorder profile <mediaTag>
For video recording:

video profile <mediaTag>
8. Modify the dial peer voice <tag> voip by adding this line:
9. Define the connection to the recorder by adding all of the following lines:
cluster A>
For video:
voice-classcodec <codecTag>
voice-class sip options-keepalive

cluster B>
voice-classcodec <codecTag>
For video:
244
session transport tcp
voice-class codec <codec Tag>
media-class <media class tag>
dtmf-relay rtp-nte
10. Terminate your use of configuration mode:

End
11. Save the configuration

copy running-config startup-config
For a detailed description of CUBE configuration, see the Cisco documentation on dial-peer
forking.
Your CUBE platform is now ready for integration with QM Suite. To start recording calls
please complete the configuration of your QM Suite server by following the steps described in
the page: Single Server Configuration
Additional Configuration
In the event that you encounter difficulty recording video files please ensure that the following
configuration settings are set as described:
Failure during decoding: If decoding fails, the error log may indicate something related to
oversize file. If this occurs check that the Decorder settings are correctly configured. To do
this go to:
The Call Recording Web UI and open Settings > Decorders > Decorder Servers
Configuration. Increase the limit of the Max Size of File.
245
Integration: UCCE
Create an AWDB Database User

Create a CTI Server User
Creating a Supervisor
Allow the Supervisor to Observe Agents' Events
Configure ECC Variables in UCCE (Optional)
Enable ECC
Create new ECC variables
Final Checks
UCCE platform has to be configured in order to integrate with QM Suite.
Starting with version 5.2 ZOOM products connect to the CTI Server directly, not to the
CTI Object Server as previously was the case. As a result the default port has changed
from 42028 (5.1.x and older) to 42027.
This means for example while the primary (first) server callrec-a is connected to the
CTI Server on 42067, the secondary server callrec-b has to use a different port, such
as 43067.
Please perform the following steps in order to configure UCCE for integration with QM Suite:
Create an AWDB Database User
Create a new MSSL username and Password with access to the configuration database (for
example, <instanceName>_awdb).
This user should only be able to view the agents which are to be recorded.
Create a CTI Server User
This step is only required if you have the option "Agent Login Required for Client Events"
enabled:
246
If the option is disabled please skip the step.
Creating a Supervisor
Open your Configuration Manager and go to Explorer Tools -> Agent Explorer
247
Agent Explorer window opens:
1. Select the same peripheral of the agents that you want to observe in QM Suite.
2. Click Retrieve
Add a new agent by clicking the Add agent button and fill in the details:
248
Go to the Supervisor tab:
1. Enable Supervisor Agent

2. Select the Domain name
3. As username and password information use the same credentials as in the Agent tab
4. Click Save and close the Agent Explorer
Allow the Supervisor to Observe Agents' Events
Open your Configuration Manager and go to List Tools -> Agent Team List
249
Agent Team List window opens:
1. Select the same peripheral from the steps above

2. Click Retrieve
3. Select the Agent team
4. Click Add
5. Select the supervisor created for QM Suite and click OK
6. Click Save.
Configure ECC Variables in UCCE (Optional)
Enable ECC
1. Open your Configuration Manager and go to Tools - Miscellaneous Tools - System

Information:
250
2. Enable the option Expanded call context enabled
3. Save and Close the window
Create new ECC variables
Create new Expanded Call Context (ECC) variables to interconnect UCCE and Call
Recording, and store references to recorded calls.
1. Open your Configuration Manager and go to Tools > List Tools > Expanded Call
Variable List.
2. Create a new ECC variable named user.zoom.callrec.
3. Enter the Maximum length:
The Maximum length value is created (by the user or system) as timestamp +
CTIOS_UNIQUEOBJECTID (for example,
1223300194808_call.5000.16778244.2003).
timestamp = 13 characters.
There are six characters for _call.
CTIOS_UNIQUEID = peripheral ID + timestamp + agent extension
If peripheral ID = 4 and agent extension = 4, the total key length is 37 characters.
4. Enter the Maximum array size which:
Is usually a value between 5-10.
Equals the number of single connections during the whole conversation. For
example, an incoming call transferred to another agent has three parts, the original
call, consultation call, and the transferred call.
5. Save changes.
251
Please note that All ECC variables have a maximum size restriction of 2KB.
Important: For redundant deployments of the Call Recording server with the UCCE IM
enabled, two IMs access the UCCE objects. Due to a lack of write-locking in UCCE objects,
the IM tries to overwrite ECC variables with the same index. This can be prevented by setting
each deployed IM to use a different key for each ECC variable.
For example:
IPCC IM 1: user.zoom.callrecA[0]
IPCC IM 2: user.zoom.callrecB[0]
Final Checks
By the end of these steps you should be able to provide the following information:
CTI Server Side A IP address and port
CTI Server Side B IP address and port
CTI Server username and password
AWDB Server IP address
AWDB database name
AWDB database login and password
252
Integration: UCCX
To configure UCCX you need:

The primary UCCX Server address.
The primary UCCX Server Port.
The secondary UCCX Server address.
The secondary UCCX Server Port.
Application user login*
Application user password*
To integrate with UCCX you are required to create an application user in CUCM. The
user doesn't need to have any specific privileges or devices associated.
To find out the server port number:
1. Login to the Cisco UCCX Administration as a CRAAdmin.
2. Navigate to the System > System Parameters menu.
3. See the value of the RmCm TCP Port in the System Ports Parameters box.
Please note that in the event that you have only one team configured within CUCM or if
any team is empty the import will fail.
253
Preparing CUCM for prerecording
To provide prerecording to selected end-points, log in to Cisco Unified Communications

Manager (CUCM) configuration and make these changes:
Application user permissions
Add the Prerecording Service
Make Prerecording Available for Users, CUCM 5 and Higher
Configuring Prerecording in CUCM 4
Adding the Prerecording Service in CUCM 4.3
Making Prerecording Available for Users in CUCM 4.3
Next steps
Application user permissions
From QM Suite version 5.3 the prerecording service requires a certificate to communicate
with CUCM. To obtain the certificate we use the application user created during Preparing
CUCM for All Recording Types.
Ensure that the user has Standard CCM Read-only permission.
Add the Prerecording Service
The following figures may vary between CUCM versions, but the main concept remains the
same.
1. Log into Cisco Call Manager Administration.
2. On the Device menu, navigate to Device Settings > Phone Services.
The Find and List IP Phone Services page displays.
3. Click Add New. The IP Phone Services Configuration page displays:
254
4. Enter the following parameters:
a. Service Name: For example: Prerecording Service.
b. ASCII Service Name: For example: Prerecording Service.
c. Service URL, http://XXX.XXX.XXX.XXX/prerecording/#DEVICENAME#, where
XXX.XXX.XXX.XXX represents the IP address of the Call Recording Core server.
For example:
http://192.168.100.1/prerecording/#DEVICENAME#
d. Enable: Select this option to enable the service. For CUCM 7 and higher only.
In CUCM 7 and higher, there are two other required fields. Leave those with their default
values. These are Service Category: XML Service and Service Type: Standard IP
Phone Service.
5. Click Save.
Make Prerecording Available for Users, CUCM 5 and Higher
The next step is to activate the service on users phones.

1. Select the device on which to enable prerecording. Go to Device > Phone:
2.
255
2. Select Subscribe/Unsubscribe Services from Related Links: and click Go:
3. The Subscribed Cisco IP Phone Services page displays:
Select the service from the Select a Service* drop-down menu. Click Next:
4. Click Subscribe, then Save. This enables prerecording on the selected device:
256
Repeat these steps for each user or device that requires prerecording functionality.
To enable prerecording for multiple users simultaneously, edit the default Cisco Unified
Communications Manager configuration. Assign the prerecording service for the users and/or
groups within the system. For more information, see the CUCM Administration Guide.
Configuring Prerecording in CUCM 4
To provide prerecording to selected end-points, log in to Cisco Unified Communications

Manager Configuration and make these two changes:
1. Add Call Recording prerecording as a new service
2. Enable this service on selected end-points
Adding the Prerecording Service in CUCM 4.3
1. Log into CUCM Administration.

2. On the Feature menu, select Cisco IP Phone Service Configuration. The Find and
List IP Phone Services page displays.
3. Click Add a New IP Phone Service. The IP Phone Services Configuration page
displays.
4. Enter the following parameters:
Service Name for example Call Recordingcr-show
Service URL http://XXX.XXX.XXX.XXX/prerecording/#DEVICENAME# where
XXX.XXX.XXX.XXX represents the IP address of the Call Recording Core server.
For example: http://192.168.100.1/prerecording/#DEVICENAME#
Character Set choose a character set according to the preferred language
5. Click Insert to save the changes.

The IP Phone Services Configuration screen displays with a list of installed services.
6. Select the Call Recording service from the list. If the service is not listed, try the search
function on the top of the page.
7. In the Service Parameter Information area, click New.
Enter the following parameters to ensure the proper functioning of automatic language
parameters passing from the end point device:
Parameter Name: type lang
257
Parameter Display Name: type lang
Default Value: type en for English, cs for Czech, ru for Russian, etc.
Parameter Description: type Language
8. Click Insert to save the changes made.
Making Prerecording Available for Users in CUCM 4.3
Once prerecording is set up in CUCM and Call Recording, the next step is to activate it on
users' phones.
1. Log in to CUCMand select User Options. This is usually located on the server under /c
cmuser.
2. Select the device to enable with prerecording from the drop-down list, and click Configu
re your Cisco IP Phone Services.
3. Click Continue to set its parameters.

4. In the Service Name* field, type the name to display on the IP phone in its Services
menu.
5. In the lang* field, type the preferred language code, en for English, cs for Czech, ru fo
r Russian, and so on.
6. Click Subscribe to save the changes made.
Prerecording is now enabled on the selected device. Repeat these steps for each user that
requires Prerecording.
To enable Prerecording for multiple users simultaneously, edit the default CUCM
configuration and assign the prerecording service for the user or groups or users within the
system. For details, consult the CUCM Administration Guide.
Next steps
As a next steps please configure the Prerecording Service on your QM Suite server.
258
Preparing CUCM for MediaSense integration
The QM Suite MediaSense integration (MSI) module requires a MediaSense API user to
access the MediaSense server. This section describes how to create the MediaSense API
user.
Creating an end user
Adding the user to the MediaSense API user configuration list
Creating an end user
1. Log in to Cisco Unified Communications Manager (CUCM) Administration:
2. Go to User Management > End User.
Click Add New. The End User Configuration window displays:
259
Type in:
User ID
Password
Confirm Password
Last name
1. Click Save.
2. Scroll down to the section labeled Permissions Information and click Add to User
Group:
3. The Find and List User Groups dialog displays. Click Find and select the check box St
andard CCM End Users.
4. Click Add Selected.

5. Click Save.
Adding the user to the MediaSense API user configuration list
1. Log in to Cisco MediaSense Administration:
2. Go to Administration > MediaSense API User Configuration:
260
3. Click Manage MediaSense Users, select the end user that you created from the Availa
ble Unified CM Users and click the arrow to add this user to the MediaSense API
Users list.
4. Click Save. Your user is now added to the list.

Now you can configure the MSI module in QM Suite by following the steps at this link:
Configuring the MediaSense integration module.
261
This section describes how to configure CUCM to upload CDR files into an FTP directory.
These steps are prerequisite steps for enabling CDR Service_old.
Configuration
To enable storing Cisco UCM Call Detail Records to your QM Suite server perform the
following steps:
1. Open Cisco Unified Serviceability UI.
2. Go to Tools > CDR Management:
3. Click Add new
Where:
Host Name/IP Address - IP address, FQDN or hostname of your QM Suite server
where you want to store the CDR files.
User Name - Username for the FTP server. Default: ftpcdr.
Password - Password for the FTP server. Default: zoomcallrec. We recommend
to use a custom password for that user. The password can be changed during FT
P configuration.
Protocol - Choose the preferred protocol. Make sure that you will enable it later
on your QM Suite server.
Directory path - specify ./upload/ which the default directory for CDR records on
262
your QM Suite server.
4. Click Add
5. Restart your CDR agent service. For that go to Tools > Control Center Network
Services
6. Select CDR Agent and click Restart:
7. Similarly to the above two steps also restart the Cisco CDR Repository Manager servi
ce.
8. Go back to CUCM Administration console
9. Go to System > Service Parameters and select the desired server and Cisco
CallManager service.
10. In the section System find the CDR Enabled parameter and set it to True and if you're
using the CDRs only for call recording we recommend that you have disabled the
option CDR Log Calls with Zero Duration Flag Required Field for better performance
of your QM Suite CDR Service:
11. Click Save.

12. Go to System > Enterprise parameters
13. In the section CDR Parameters find CDR File Time Interval option and specify the
desired value. This parameter is optional and applying changes of the parameter
reloads the configuration of all connected devices.
The next step is to configure the FTP on your QM Suite server
263
Preparing Genesys for integration
This section describes the steps required for preparing the Genesys environment for
integration with QM Suite. Go to the listed section relevant to your deployment
Common steps for Genesys integration
Preparing Genesys Platform for Active Recording - MSR
Preparing Genesys Platform for Enhanced Passive Recording - EPR
264
Common steps for Genesys integration
This section describes the steps that are common for all types of integration of your Genesys
environment with QM Suite which are:
Integrating your Genesys CIM for obtaining Contact center data (attached data).
These steps are the only ones you need to perform in your Genesys platform for this
type of integration.
Genesys Active Recording. Here you will need to perform additional steps described
in the section: Preparing Genesys Platform for Active Recording - MSR
Genesys Enhanced Passive Recording. Here you will need to perform additional
steps described in the section: Preparing Genesys Platform for Enhanced Passive
Recording - EPR
To integrate with Genesys Environment using the Genesys Integration Module perform the
following steps:
Adding the Call Recording Application to the Configuration Manager
Adding a New Person to the Configuration Manager
Prepare T-lib server and Configuration Manager IP addresses
Adding the Call Recording Application to the Configuration Manager
Open Genesys Administrator and go to Provisioning > Environment > Applications and
click New
1. Specify the name

2. The application template is located on your Call Recording server in /opt/callrec/e
tc with the name CallREC-GenesysIntegrationModule.apd
3. Type - Third Party Application
4. Click Save & Close.
265
Adding a New Person to the Configuration Manager
The Integration Module requires a configured person for authorization when connecting to the
T-Server and Configuration Server. This same account can be used for both T-Server and
Configuration Server connections. If two separate accounts are required simply proceed by
repeating this step.
Open Genesys Administrator and go to Provisioning > Accounts > Users and click New
1. Type at a minimum: Last Name, Employee ID, User Name and Password. Select the
State Enabled check-box and ensure that the Is Agent check-box is not selected.
2. Add the Access Group membership in the Member Of tab.
Important: The person that Call Recording uses for authentication must only have
permission to see Agent DNs that will be recorded.
It may be useful to limit the number of observed DNs and thus decrease the number of
processed events. (only the DNs that are interesting will be observed) This will reduce
the load on the system. To achieve this goal one possible approach is to make the
selected person a member of the Users group and block access to all sub trees in the
SWITCH directory except for the SWITCH\DNs directory which is mandatory for
successful events processing.
In certain installations it may be necessary to add the selected person to additional
groups in order to see Agents DNs.
3. Click OK to save the new person.
266
We highly recommend to set the permissions of the user to observe the Agents, DNs
and Switches related to call recording only. Observing objects not related to call
recording, especially switches that do not support MSR/EPR recording,(for example
Cisco switches) can cause issues to the recording process.
Prepare T-lib server and Configuration Manager IP addresses
Prepare the following IP addresses

T-Lib Primary server IP address
T-Lib Backup server IP address
Config Primary server IP address
Config Backup server IP address
267
Preparing Genesys Platform for Active Recording - MSR
These are additional steps for Common steps for Genesys integration and they are required
only for the Genesys Active Recording method.
Configuring the SIP Server for Active Recording
Configuring the Application Level
Configuring resource-management-by-rm
Configuring msml-support
Configuring msml-record-support
Configuring recording-filename
Configuring record-consult-calls
Creating the MSML DN resource
Description of the TServer Section Parameters
Configuring the Extension, record parameter
Configuring the Trunk record parameter
Configuring the Genesys Voice Platform for Active Recording
Checking the configured Recording Servers
Creating a Resource Access Point
Configuring the Logical Resource Groups of Recorder servers
Resource Assignment
Configuring Media Control Platform Options
Configuring the Media Control Platform logical resource groups
Configuring the IVR Profile
The Genesys Configuration Server and TServers must be configured to enable Call
Recording to communicate with the system. Upload and enable the Genesys
Integration Module application template and create a new user account for Call
Recording in both the primary and backup servers.
Configuring the SIP Server for Active Recording
Configuring the Application Level
The following configurations are necessary at the application level:

Navigate to: Provisioning > Enviroment > Applications > SIP Server > Options Tab >
TServer.
Configuring resource-management-by-rm
In the TServer section of the SIP Server application, configure:

resource-management-by-rm to true to support the call recording solution.
The valid values are:
true: Resource Monitoring and Notification will be done by the RM. The SIP Server will
contact the Media Server (MS) through RM.
false: Resource Monitoring and recovery will be done by the RM. The SIP Server will
contact MS directly.
The default value is true.
268
Configuring msml-support

msml-support as true to support the call recording solution.
true: The msml service is enabled for treatment and conference and recording service.
false: The msml service is disabled for treatment and conference and recording
service.
The default value is false.
Configuring msml-record-support

msml-record-support to true to support the msml based call recording solution.
true: This enables SIP Server to engage GVP as a media server through the msml
protocol for call recording (SIP Server uses msml protocol for call recording).
false : The SIP Server uses existing NETANN protocol for call recording.
The default value is false.
Configuring recording-filename

recording-filename to an empty field.
The Value of this option must be set to empty field, otherwise QM Suite won't be able to
match RTP received from MCP with TLib events.
The default value is an empty field.
Configuring record-consult-calls

record-consult-calls
This can have either a true or a false value depending on whether consult calls are to be
recorded.
Creating the MSML DN resource
The following configurations are necessary at the DN Level. Create a DN per Resource
Manager.
Navigate to: Provisioning > Switching > Switches > "name of SIP switch" > tab DNs.
Create a special DN, for example: MSML_Service_DN with the type:
Voice_over_IP_service.
This specifies which implementation of hold media SDP is used by the SIP Server for
third-party call control (3pcc) hold operations.
When set to true, it is RFC3264-compliant.
When set to false, it is RFC2543-compliant.
269
When this option is set at the DN level in the Annex tab > TServer section, it will
override the Application level value.
Creating a TServer Section for msml in DN for VOIP

Select edit Options of this DN and on Annex tab, create a TServer section with the
parameters:
Name: contact Value: sip:[rm-ip]:[rm-port]
Name: make-call-rfc3725-flow, Value: 1
Name: prefix, Value: msml=
Name: refer-enabled, Value: false
Name: ring-tone-on-make-call, Value: false
Name: service-type, Value: msml
Name: subscription-id, Value: Environment
Description of the TServer Section Parameters
contact: This is a mandatory parameter. Point the option contact of the msml servic
e to the IP address and port of the Resource Manager.
contact=sip:<ResourceManager_IP:port>
make-call-rfc3725-flow: This parameter should be set with a value = 1.
prefix: This is a mandatory parameter in the MSML service and the value of prefix
should be msml=
refer-enabled: This is a mandatory parameter. If not used, some transfer functions
won't work.
Configure the option refer-enabled as false.
ring-tone-on-make-call: Configure the option parameter ring-tone-on-make-
call in the MSML service. This parameter should be set to false
service-type=msml: If multiple DNs of same type are created, then round robin is
done by Genesys between these automatically.
subscription-id: This is a mandatory parameter:
Configure the option subscription-id in the MSML service, and the value of the
service must be set to <TenantName> where <TenantName> is the name of the tenant.
subscription-id=<TenantName>
Configuring the Extension, record parameter
Configure the record parameter in Extension to true to enforce recording without a

request from QM Suite. This completely bypasses the recording rules on the QM side.
This step is optional. You can either control recording per DN level via these options or
by recording rules on QM side. It is recommended to use recording rules on QM side.
The two recording methods can't be mixed.
Configuring the Trunk record parameter
270
Configure the record parameter in Trunk to false.
The option can't be set to true as this would cause QM Suite not to record calls (If the value
were set to true, QM Suite would receive the number of a calling party in SIP signaling as a
recorded DN and QM Suite would not be able to match TLib events for the stream).
Configuring the Genesys Voice Platform for Active Recording
Checking the configured Recording Servers
If there is no recording server configured, proceed to the next section, Creating a Resource
Access Point.
The Recording Servers are also configured and represented in Genesys Administrator (GA)
Configuration Manager. Recording servers can be found in GVP folders by going to:
Provisioning -> Applications -> and selecting the Top folder /. There can be found GVP*
folders containing these applications.
Creating a Resource Access Point
Each recording server is assigned to Logical resource group via Resource Access Point. This
application template can be imported using VP_CallrecordingServer<version>.apd from the
Resource Manager installation directory. Please note that the host part of this application is
fake only.
It won't be monitored by LCA in any way. The Resource Access Points are monitored by
Resource Managers themselves.
The access points are simply representations and do not include any configuration data for
the SLR servers. The Host and Listening Port from configuration has to be filled, but this has
no effect on the recording itself. Use any host / ip and any port.
The configuration itself is done in Options tab in gvp.rm section:
Option: aor Value: <sip:[Recorder_IP_Address]:[SLR_Port]>
In the make-call-rfc3725-flow: This parameter should be set with a value = 1.
Ensure, that in provision section, there's recording-server option which equals to 1.
Configuring the Logical Resource Groups of Recorder servers
To create a new Logical Resource Group for Recording Servers:

Under PROVISIONING > Voice Platform > Resource Groups, click New. This will start the
Resource Group Wizard.
In Resource Manager Selection, select the appropriate Resource Manager.
In Group Name and Type, enter the group name and select Recording Server group type.
Use the defaults for Tenant Assignment and Group Properties.
See the next section for Resource Assignment screen shot and instructions.
Resource Assignment
1. Set the IP Address and SIP Port of the Recording Servers to those of the installed
271
1.
zoom component. IP Address and SIP port matches the gvp.rm/aor option of Resource
Acess point. You can edit it in this window. Always ensure a valid IP address and that
the SIP port used represent the Spanless recorder of QM.
2. Set the Max Ports option to double the number of calls you are able to record. This has
to correspond to -S setting for Spanless recorder component from callrec.derived
configuration file.
3. When configuring recording servers each one must have Redundancy set to Active. If
not they won't be seen as an available resource to RM and calls won't be recorded. Upo
n selecting Active, the Resource Manager should immediately start to send SIP options
pings to the SLR port and monitor its availability.
Configuring Media Control Platform Options
Configure the following Media Control Platform (MCP) parameters:

1. Navigate to the MCP application section in Top level GVP folders or Applications in
Configuration Manager MCP > Properties > Options > vrmrecorder
Set sip.routeset to <sip:[rm-ip]:[rm-port];lr>
For example: <sip:172.10.1.1:5060;lr>
This defines the route that the MCP uses to access the recording server. Set to RM to
allow the RM to invite the SLR servers from Call Recording. The syntax is very
important -- the expression must have < and > (without the < and > the MCP would
not invite the RM and recordings would fail).
2. In the mcp section, edit rtp.multichantimeout and set value equals to zero. Default is
60000. It's in milliseconds and keeping it 60000 will make recordings create a new
couple each minute.
3. Also as for any resource group, select which RM should manage the group.
Please note, that the flowing step is optional.
4. Configuring MTInternal Transmit Rate

Navigate to MCP > Properties > Options > mtinternal.
The parameter transmit_rate specifies the transmission rate limit as a multiple of
real time.
A value of 1 means real time, 2 means twice real time, and so on.
Set to a smaller number to lower transmit to real time in order to improve overall
processing power if there is a more constant load on the servers.
Configuring the Media Control Platform logical resource groups
1. When configuring the Media Control Platforms (MCPs) the IP address and Port must
match the details of the MCP.
2. Set the Max ports option to double the number of calls you want to handle with the
MCP. The reason for the number being doubled is that one port is used per stream in
the call, one for the customer leg and one for the caller leg. With the Max Ports set to
1000 the MCP can handle 500 calls.
Configuring the IVR Profile
1. Navigate to Environment > Tenants, select Environment, go to the Options tab -

check what the default profile for tenants is (look under the gvp.general section, gvp.ge
272
1.
neral/default-application. The value is set to Default application).

2. Then go to Voice platform > IVR profiles > Default application, go to the Options tab
, look under gvp.service-parameters,
if it is not there click on New and create:
Section > gvp.service-parameters
Name > recordingclient.recmediactl
Value> fixed,2
3. Click OK.
The value says we want to separate the dialog for each call-leg.
4. If it is not there, click New and create:
Please note the settings below are valid only for non HA deployment. For Media
Steam Replication with duplication of Recording recdest and recdest2 points
each LRGs clusters 1st SLRs.
Section > gvp.service-parameters

Name > recordingclient.recdest
Value > fixed,sip:[rm-ip]:[rm-port]
5. Save changes.
273
Preparing Genesys Platform for Enhanced Passive Recording - EPR
These steps are additional steps to Common steps for Genesys integration and they are
required only for Genesys Active Recording method.
Configuring SPAN ports
Setting rtp-info-password
Configuring SPAN ports
These steps are described here Pre-configure the SPAN ports. For enhanced passive
recording (JTAPI sniffer) it is sufficient to SPAN only RTP traffic. Typically it is sufficient to
configure one SPAN session that provides all necessary traffic to Call Recording on one port
(eth1). If this is not possible there is the option to connect multiple SPAN sessions to one
server (of course more NICs will be required). Refer to Cisco documentation Configuring
SPAN and RSPAN for more details on SPAN port configuration on Cisco switches.
Setting rtp-info-password
Genesys 7.5, 7.6, 8.0, and 8.1 T-Server are supported.

The Genesys T-Server (SIP server) must have the configuration option rtpinfo-password
set.
For Genesys 7.6 T-Server this option is located in the Configuration Manager: Configuration
> Environment > Applications >T-Server_Switch on the Options tab:
If the rtp-info-password option is not configured, or the passwords do not match,

the Genesys Driver can't receive any information about call RTP streams which
effectively disables the recording capabilities of QM.
274
SPAN port configuration
VMware SPAN Port Configuration
VMware SPAN Port Configuration
For SPAN and combination recording, the server must have one or more SPAN ports
connected to the second NIC. The SPAN port must provide all the RTP packets related to the
calls being made. If the data is not available, the system shows that the call was made, but
does not contain any audio data.
Navigate to the control for the vSwitch and ensure that the following in Default Policies are
all set to Accept.
Promiscuous Mode
MAC Address Changes
Forged Transmits
Navigate to the Virtual Machine Properties:
1. Ensure that there are two network adapters
2. Ensure that each adapter is set to the correct Vlan
Please refer to Cisco documentation Configuring SPAN and RSPAN for more details.
In a non-virtual network environment by default eth0 is connected to local Intranet network
and eth1 is connected to the Span-port of the switch. This Span-port mirrors the voice traffic
that we should record.
Important:If deploying an Active recording solution, SPAN ports are not required. Combination
solutions, require both Passive (SPAN) and Active configuration.
275
Preparing for Automatic Pause and Resume
Automatic Pause and Resume functionality can be integrated into the contact center in order
to ensure Payment Card Industry Data Security Standard (PCI DSS) compliance. As this
standard obliges companies which take payment card details to protect cardholder data it is
necessary to ensure that sensitive data is not recorded. By using a third party application
such as OpenSpan it is possible to ensure compliance through the automated sending of
requests to the Call Recording server which pause and resume recording of calls and/or
screens.
Pre-installation requirements
Environment requirements:
Desktop Minimum Requirements:
Pre-installation requirements
In order to utilize the API based feature which allows for Automatic Pause and Resume
triggers to be sent directly from agents desktops to the Call Recording database the following
information must be provided to ZOOM before setup and configuration can go ahead:
Windows platform and system configuration.
Operating system version and edition (32/64 bit).
Browser Version.
List of browser plugins.
Template of agents desktop. (if available, physical access to the agents workstation may
be required if no template or virtual machine is available)
List of programs or applications that will be in use when an automated pause or resume
request is sent.
A detailed description of the work flow shall be provided the describes the business use
case of the pause and resume functionality. This will include:
Which action triggers call pause and how an agent gets there flow description
and screenshots.
Which action triggers call resume and how an agent gets there flow description
and screenshots.
Environment requirements:
The following requirements are necessary in order to ensure that automation will work
correctly:
1. All desktops must be using the same version of Internet Explorer.
2. There must be a test machine available that is exactly the same as the production
environment.
3. The desktops must meet the minimum requirements as listed below:
Desktop Minimum Requirements:
Component Requirement
Processor 1 GHz or faster
RAM 512 MB
Disk Space 100 MB available
276
Operating Only Microsoft Windows environment is supported:
System Windows 7 (32- and 64-bit)
Browser Only Microsoft Internet Explorer is supported at the moment. These 32-bit
versions are supported:
Internet Explorer version 10
Internet Explorer version 11
Other Microsoft .NET Framework 3.5 SP1

applications: Microsoft Windows Installer 3.1 or later
277
Prerequisites: Preparing for Oracle
Preparing for Oracle
Before beginning a QM Suite installation, complete the following tasks:

1. Set up access and credentials, administrative database username & password and
optional tablespace for QM Suite, in a running Oracle database instance. An
administrative username and password is needed when Creating DB Schema in Oracle.
2. Set NLS_LANG Environment variable, via the following steps:
a. Determine the NLS_LANG value.
i. In the data warehouse database, run the command:
SELECT * FROM V$NLS_PARAMETERS
ii. Make a note of the NLS_LANG value, which is in the format

[NLS_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET].
For example: American_America.UTF8
b. Set the variable for windows:
i. Navigate to Control Panel > System and click the Advanced tab. Click Env
ironment Variables.
ii. In System variables section, click New.
iii. In the Variable Name field, enter NLS_LANG.
iv. In the Variable Value field, enter the NLS_LANG value that was returned in
a
The format for the NLS_LANG value should be
[NLS_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET].
For example: American_America.UTF8.
c. To set the value of the NLS_LANG parameter in UNIX, NLS_LANG is set as a
local environment variable.
If your data is 7-bit or 8-bit ASCII and the Informatica Server is running on UNIX,
then set the value of NLS_LANG as
<NLS_LANGUAGE>_<NLS_TERRITORY>.WE8ISO8859P1
Make sure you set the NLS_LANG variable correctly, as

stated in this procedure, or your data will not display
correctly.
d. Reboot your machine after creating the variable.

3. Mising requirements regarding database replication utils
For versions 4.9.7, 5.1.5, 5.2.1, 5.3.0, db schemas must have permissions to access the
DBMS_REPUTIL package, even when the replication is not used.If the permissions are
missing, the triggers cannot be successfully compiled, there will be errors in log files and
none of the db operations related to the triggers will work.
See some examples:
webadmin.log
278
Oct 30 01:18:04 ERROR [ajp-8009-1]
cz.zoom.callrec.webadmin.audit.WebAdminAuditDB - An exception
occured when writing audit:
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in
cz/zoom/callrec/core/callstorage/pojo/oracle/UserAudit.xml.
--- The error occurred while applying a parameter map.
--- Check the insertUserAudit-InlineParameterMap.
--- Check the statement (update failed).
--- Cause: java.sql.SQLSyntaxErrorException: ORA-04098: trigger
'CALLREC.USER_AUDIT_TRIGINS' is invalid and failed re-validation
tools.log
Oct 30 01:33:04 ERROR [SynchroThreadTask-0]
cz.zoom.callrec.tools.synchro.Synchronizator - Synchro faild for
couple 'couple {id=7336583, callId=5866915,
sid=006c025351755efe_11002620_11008428_1, status=NO_PROBLEM,
start=Wed Oct 29 23:11:39 IST 2014, end=Wed Oct 29 23:12:00 IST
2014, created=Thu Oct 30 01:26:04 IST 2014,
callingNumber=11002620, originalCallednumber=11008428,
finalCalledNumber=, callingIP=null, calledIP=null,
evaluated=null, syncronized=null, deleted=null, restored=null,
archived=null, mixed=null, cfileTypes=1, cfilesCount=1}' changing
b_flag back to null.
Oct 30 01:33:04 ERROR [SynchroThreadTask-0]
cz.zoom.callrec.tools.SynchroTool -
cz.zoom.callrec.tools.SynchroTool$ProcessGroupOfSources@771eb1
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in
cz/zoom/callrec/core/callstorage/pojo/oracle/tools/Couple.xml.
--- The error occurred while applying a parameter map.
--- Check the couple.insertCoupleExmap.
--- Check the statement (update procedure failed).
--- Cause: java.sql.SQLSyntaxErrorException: ORA-04098: trigger
'CALLREC.COUPLES_TRIGINS' is invalid and failed re-validation
ORA-06512: at "CALLREC.ADD_COUPLE_3", line 55
ORA-06512: at line 1
When trying to compile the trigger and requesting to see the errors, you will see the
following:
279
> alter trigger USER_AUDIT_TRIGINS compile;
Warning: Trigger altered with compilation errors.
> show errors

Errors for TRIGGER USER_AUDIT_TRIGINS:
LINE/COL ERROR
--------
-----------------------------------------------------------------
3/3 PL/SQL: Statement ignored
3/6 PLS-00201: identifier 'DBMS_REPUTIL' must be declared
Final Checks
by the end of these steps you should be able to provide the following info:
Oracle Server IP address
Oracle Server port
Oracle Service Name
280
Installation of OS and QM Suite
QM Suite Installation
Installation Media
Verify ISO File Integrity
Default Installation
Install CentOS Linux
Set up Partitions Manually
Network Configuration for CentOS
Select the Time Zone
Set the Partition Type
Reboot CentOS
Install ZQM on an Existing Installation
OS Version
Disable SELinux
ZQM Packages Installation
Installing Base OS Packages Required by ZQM
Installing ZQM Packages
Installing VMWare Tools on a Virtual Server
Begin the Installation Process
Check that the CD/DVD is Connected:
Install the VMware tools
Domain Naming Conventions
QM Suite Installation
We deliver the ZOOM QM Suite as a single ISO image file or DVD. These can be downloaded
from the ZOOM Partner Portal: http://portal.zoomint.com. The ISO file contains both the OS
and ZQM packages. The OS that comes in the image/DVD is CentOS. OS versions may vary
based on ZQM version. You can install the default version of OS that comes with the ISO
image or install a custom version of CentOS/RHEL, and then install the packages on it.
Before installing Call Recording please ensure that the drive has at least 20 GB of
space free for the OS. If there is less than 20 GB of space the install process will fail!
Installation Media
The installation media set has these items:

ZOOM QM Suite ISO image file
ISO checksum files for ISO integrity checks.
In areas with poor connectivity, we can optionally supply the installation as a DVD. It is
bootable and used as the default.
Verify ISO File Integrity
Verify the integrity of all downloaded ISO image files. Use the MD5 checksum that comes with
the ISO download file. Download WinMD5Sum and install it based on the manufacturer's
instructions from:
http://www.nullriver.com/products/WinMD5Sum
This is the MD5 verification procedure that uses WinMD5Sum for a QM Suite ISO:
281
1. Click ... to browse for the downloaded ISO image file.
2. The MD5 Sum field checksum appears. Use a text editor to open the
zqm-x.x.x-xxx.iso.md5 file. Copy the number from the text file. Paste it into the Compare
field. The checksum is 32 characters long.
3. Click Compare.
4. If the checksums are the same, the confirmation dialog displays.
Default Installation
ZQM ISO/DVD comes with these versions of CentOS:
ZQM version CentOS version Architecture
5.1.X 6.2 i386
5.2.X 6.5 i386, x86-64
5.3.X 6.5 i386, x86-64
5.4 6.5 i386, x86-64
5.5 6.6 i386, x86-64
5.6 6.6 i386, x86-64
5.7 6.6 i386, x86-64
5.8 6.8 i386, x86-64
Install CentOS Linux
282
If you use the ISO image file, download it and mount the ISO file as the DVDROM image. You
can mount the installation image (ISO) file directly. For example: with VMware, or written to a
bootable installation DVD.
If you use a DVD, insert the ZOOM QM Suite installation DVD and start the server. If the
server does not show the splash screen, check the servers BIOS to ensure that the server
boot order identifies the CD/DVD drive as the first boot device.
To install CentOS Linux:

Type zqm and press Enter to start the installation.
If there is no user input within 60 seconds, installation is canceled and the OS boot sequence
continues. This feature prevents reinstallation from a forgotten disc in the drive. If the OS boot
sequence starts, reset or reboot the machine and start again.
Set up Partitions Manually
283
Select which disk device to used for partitioning. Perform one of these:
Select only one disk device for no redundancy.
Select two disks to create RAID1 mirroring.
Select OK and press Enter.
The Volume Size Configuration screen displays the default sizes of the volumes.
Following three situation can arise:
1. The disk is smaller than 20 GB, then the installer will not proceed at all.
2. The disk is smaller than 100 GB the installer will propose you the following partitioning:
tmp partition (/tmp) - 2 GB
284
swap - 2 GB
root partition ( / ) - the rest
3. The disk is larger than 100 GB, suggested default partitioning will be:
root partition ( / ) - 20 GB
home partition (/home) - 10 GB
tmp partition (/tmp) - 4 GB
swap - 2 GB
opt partition (/opt) - the rest
If a value for any partition is not provided or the value is set to zero, then the installer will
not create the partition.
A root partition must always be created. The installer will not allow you to proceed
without the them.
In case you shrink the default size for opt (or other partitions), then the remaining disk
space remains unused and stays available for additional manual partitioning after the OS
is installed
Click OK to accept the sizes or Click Cancel to return to the previous dialog.
A primary partition/boot (size 248 MB) is created. That is not included in LVM. It is a standard
BIOS-type partition needed for booting. For a RAID variant, there are two /boot and /boot1
partitions on both devices.
Network Configuration for CentOS
If CentOS has no support for the network interface fitted, it displays the warning message "No
Ethernet interface detected! Please configure networking after the first boot". An administrator
should install NIC drivers after the first boot.
285
Configure the first NIC. Use the Tab key to move from element to element. Type:
1. The IPAddress and Netmask
2. The Gateway
3. The Primary DNS (Domain Name Server)
4. The Secondary DNS
5. The Hostname as a FQDN (fully qualified domain name)
Select the Time Zone
Set the time zone for the ZQM Suite.
Select the System clock uses UTC option if the system clock uses Coordinated Universal
Time (UTC).
Otherwise, scroll through the list to select the location.
Set the Partition Type
If Partitioning has been done manually in previous steps, this dialog won't display.
286
Select how to partition your hard drive:
1. Use the entire drive
2. Replace the existing Linux system
3. Use free space
Select which drive(s) you want to use for this installation. On large systems there may be
several drives, select at least one.
Reboot CentOS
The installation program now installs and configures all the Suite and CentOS packages. This
may take time. You should not be asked any other questions at this stage.
287
Once the installation finishes, the installer requests a system reboot.
Ensure that you have removed the DVD or disconnected the ISO installation volume (on a
virtual server) before you reboot.
During the reboot, immediately after the OS is installed, the End User License Agreement
(EULA) appears.
288
Select ACCEPT (use Tab and Enter) if you agree with the terms and conditions. Then,
CentOS Linux restarts and displays the login prompt.
Install ZQM on an Existing Installation
OS Version
The ZOOM QM Suite requires a specific release of the operating system. It is not
recommended to use another version of the operating system. Doing so may lead to an
installation failure, as the Suite expects exact matches for package names and
configuration files. If you need a custom version of CentOS or RHEL, please contact us
at https://portal.zoomint.com/
When installing RHEL/CentOS from other then ZOOM sources, it is mandatory to
install Basic Server Install Type. Do not add or update any other packages and
disable the update service. Otherwise the installation process is not supported!
This guide doesn't cover the installation process of RHEL or CentOS that don't come with the
Suite ISO/DVD. It explains how to install the packages on your already-installed OS.
To make the packages installation process easy, we recommend that you choose the
following installation type: Basic Server
The Suite supports these CentOS and RHEL versions:
ZQM Version CentOS Version RHEL Version Architecture
5.1.X 6.2 6.2 i386
5.2.X 6.2, 6.4, 6.5 6.2, 6.4, 6.5 i386, x86-64
5.3.X 6.2, 6.4, 6.5 6.2, 6.4, 6.5 i386, x86-64
289
5.4 6.2, 6.4, 6.5 6.2, 6.4, 6.5 i386, x86-64
5.5 6.4, 6.5, 6.6 6.4, 6.5, 6.6 i386, x86-64
5.6 6.4, 6.5, 6.6 6.4, 6.5, 6.6 i386, x86-64
5.7 6.4, 6.5, 6.6 6.4, 6.5, 6.6 i386, x86-64
5.8 6.8 6.8 i386, x86-64
Disable SELinux
When you install RHEL, this enables SELinux (Security-Enhanced Linux) by default.
The Suite does not have policy files for SELinux. Therefore, SELinux blocks some
functionality.
To disable SELinux after the RedHat installation edit /etc/selinux/config, set these
values:
SELINUX=disabled
SELINUXTYPE=targeted
This disables SELinux on the next reboot.

To disable SELinux without having to reboot, use the following command:
setenforce 0
ZQM Packages Installation
The packages installation has two steps:

1. The installation of base OS packages required by ZQM. Install the package qm-meta-os
which triggers all necessary system packages through its dependencies.
2. The installation of the ZQM packages themselves. Install the package qm-meta that has
all the packages in its list of dependencies.
Installing Base OS Packages Required by ZQM
Firstly, get the qm-meta-os package from the ZQM image so that you can use it to install the
system packages required by ZQM.
To do so, insert the media into the server and mount it to /media/cdrom
mkdir -p /media/cdrom/
mount /dev/cdrom /media/cdrom/
If you have the ISO file uploaded to your server, use the following commands:
mkdir -p /media/cdrom/
mount -o loop /home/admin/zqm-XXX.iso /media/cdrom/
Where XXX is your current version.

You should see this message:
290
Next, copy over the qm-meta-os package. This includes the .repo file. Umount the media:
cp /media/cdrom/ZQM_Suite/RPMS/qm-meta-os*.rpm /tmp/
cp /media/cdrom/rhel.repo /etc/yum.repos.d/
umount /media/cdrom/
Then, initiate the system packages installation:

Insert the RHEL media used in the OS installation and mount it to /media/cdrom:
Execute the installation of the qm-meta-os package:

yum localinstall --nogpgcheck -y /tmp/qm-meta-os*.rpm
The installation process is executed:
If there are any dependency problems when running the yum localinstall command, you
will see messages that state which packages are involved. These should be removed. Note
that you can remove the Open JDK package (for example: java-1.6.0-openjdk), which
often causes dependency issues.
First, use the yum remove command to remove the affected packages. For example:
yum remove java xalan-j2 bsf
Next, re-enter the yum localinstall command as before. Repeat this procedure until the
command is successful.
291
As soon as the installation finishes successfully, switch to the installation of the packages
themselves.
Installing ZQM Packages
First, Umount the RHEL disc used for the installation of the system packages:
umount /media/cdrom/
Insert the ZQM instalation media and mount it to /media/cdrom:

Next, you need to download the metadata from the callrec repository. For this, you need to
either disable other repositories or move/delete them.
yum clean all
yum makecache --disablerepo=rhel
If you have any other enabled repositories, you will face this error:
To avoid it, rename the problematic repo file so that it doesn't have the .repo extension and
won't be read by in the yum makecache process:
mv /etc/yum.repos.d/custom.repo
/etc/yum.repos.d/custom.repo.backup
Then, initiate the installation of the packages:

yum install -y qm-meta --disablerepo=rhel --nogpgcheck
The installation process is executed:
292
When the installation finishes, umount the media:
umount /media/cdrom
Installing VMWare Tools on a Virtual Server
Begin the Installation Process
In the vSphere Client:
1. Right-click the virtual server from the server list.

2. Select Guest from the menu.
3. Select Install/Upgrade VMWare Tools. The Install VMware Tools dialog box displays:
293
3.
4. Click OK.
294
Check that the CD/DVD is Connected:
1. Right-click the virtual server from the server list.

2. Select Edit Settings from the menu.The VMware Tools dialog displays:
3. Click OK to remove it.

The Virtual Machine Properties page appears:
4. Click CD/DVD drive 1.

5. Ensure that the Connected checkbox is selected, the File Datastore ISO radio button is
selected, and the path is shown as:[ ]
/usr/lib/vmware/isoimages/linux.iso. If the checkbox and radio button are
not selected, reset the machine and start again.
6. If the checkbox and radio button are selected, click OK.
Install the VMware tools
Use any SSH client. For example: PuTTY.

1. Select the virtual server from the server list.
2.
295
2. Login as root.
3. Enter these commands:
mkdir /mnt/cdrom
mount -o loop /dev/cdrom /mnt/cdrom
cd /tmp
4. To get the correct version of VMwareTools-X.X.X-XXXXX.tar.gz in the next command

line, type: tar zxpf /mnt/cdrom/VM and press the Tab key to auto-complete the
filename:
tar zxpf /mnt/cdrom/VMwareTools-X.X.X-XXXXX.tar.gz
umount /dev/cdrom
cd vmware-tools-distrib/
./vmware-install.pl
5. Press Enter after the last command (./vmware-install.pl).

6. Press Enter for every prompt to install the tools in their default locations.
7. Follow the instructions at the end of the installation to update the drivers.
8. The ssh client displays this message at the end:
Enjoy,
--the VMware team
9. Close the SSH client.
Always check which VNIC adapter type is configured on the VM before you load the
VNIC driver! Note that E1000 may not work properly under a heavy load. We
recommend that you use Flexible or VMXNET VNIC adapter types. There are reported
bugs in the VMXNET adapter. Check their ESXi version and apply any updates
available. Refer to VMware Recommendations for more details.
Domain Naming Conventions
Ensure that any domain name conforms to the international RFC 1034 standard on domain
names and the DNS system:
The labels must follow the rules for ARPANET host names. They must start with a letter, end
with a letter or digit, and have as interior characters only letters, digits, and hyphens. There
are also length restrictions, therefore labels must be 63 characters or less.
[RFC 1034 section 3.5: Preferred name syntax]
296
Configuration
Depending on your solution perform configuration of QM Suite services:
1. Single Server Configuration
2. Cluster Configuration
3. High Availability Configuration
297
Single Server Configuration
Configuration Prerequisites
Beginning the Setup and Configuration Process
Configuration from a Cache File
Manual Configuration
Executing Manual Configuration
Selecting the QM Suite services
Service Configuration
Finishing Configuration
Configuration Prerequisites
Before starting to configure ZOOM Quality Management, you must:

Configure the call center platform for recording - Cisco UCM, Genesys SIP server or
Avaya CM
Configure the call center platform for integration - UCCX, UCCE or Genesys CIM
Have installed both OS and ZQM packages
Configure SPAN ports in the case of passive recording
All these steps are covered in the Installation guide.
Beginning the Setup and Configuration Process
Access the Call Recording server via an ssh client, for example PuTTY.
The setup and configuration process on the Call Recording server are as follows:
1. Type your administrative login and password as, login: admin password: zoomcallr
ec.
2. Switch to the root user account by typing "su -" and enter the password (default:
zoomcallrec).
You are strongly recommended that you change the root password from the
default one to one of your own choosing.
3. Run the callrec-setup script using the command:
/opt/callrec/bin/callrec-setup
4. QM Suite setup initializes and asks if you want to start Call Recording (QM Suite)
configuration process:
298
Navigation hot keys in the Setup tool:
TAB to navigate forward
Shift+TAB to navigate backwards
ENTER to select an option
UP and DOWN to navigate between options
SPACEBAR selects the chosen option
5. Select Yes to continue or No to abort setup
If you need to change any of these settings later, you can either run this setup
again (the setup remembers the values entered earlier) or edit them manually,
either through the Call Recording Web GUI Admin Interface (preferred), or
directly in the configuration files.
Configuration from a Cache File
If your configuration information is saved in a cache file you can save time by using this file to
configure QM Suite.
For first-time installations without a cache file please proceed to Manual Configuration.
1. In order to open the cache file list select Load:
2. The list of cache files opens:
299
2.
3. Navigate to your cache file.

4. Click Next
5. QM Suite setup uses the cache file to load your configuration settings.
The QM Suite Configuration Verification screen appears:
300
6. Verify your settings and click Next to complete the configuration.
7. Refer to Completing Configuration in the Manual Configuration section.
Please note, that the use of the setup cache file is supported only on within identical
ZQM Suite version. The typical use case consist in using the setup cache file for the
setup of multiple servers within one or multiple recording clusters.
Manual Configuration
Executing Manual Configuration
If you have configured QM Suite from a cache file you do not need to manually
configure QM Suite.
QM Suite configuration and setup requires information about the operating environment to
function properly. Before you begin be sure you have all the IP addresses, user names, and
passwords for your existing infrastructure prepared.
1. Select Manual to begin manual configuration:
301
1.
Selecting the QM Suite services
QM Suite offers a number of services. Please see the QM Suite Services section to evaluate
which services you require and which services can be combined.
Use the select bar to select or deselect services and select Next when you have finished
selecting the services.
Service Configuration
The following section describes all possible service configurations. The configuration visible to
you will depend on your solution.
Server's IP address:
1. Confirm the server's IP address.

2. Select Next.
Installation Type:
302
We recommend confirming the single server installation. The installation of a cluster solution
is discussed in the Cluster Configuration section.
Select Yes to continue with single server configuration.
Avaya Service Configuration:
Enter the values that were prepared during the Avaya platform configuration.
Avaya EPR Settings
This feature is available from QM Suite version 5.6 in conjunction with Passive
Recording.
303
Enter the values that were prepared during the Preparing Avaya for EPR steps.
Cisco JTAPI Service Configuration:
1. CUCM IP Address: Type the address of your CUCM. If you have a CUCM cluster then
separate the distinct IP addresses with a comma. The JTAPI driver will always connect
to the first one and in the case of failure it is able to reconnect to the next one in the list.
2. CUCM User: Type the login of the application user created in the step Preparing CUCM
for All Recording Types.
3. CUCM Password: Type the application user's password.
4. Retype the application user's password.
5. Select Next.
To ensure a better load-balance or to enable your system to receive call information from
multiple Cisco CUCM clusters it is now possible to run multiple JTAPI instances on one
Callrec server.
The first JTAPI instance is configured during the Callrec server setup against the primary
CUCM publisher as described above. Additional JTAPI instances are configured later on
through the web UI.
Please note, that in the case that additional JTAPI instances are connecting to the
304
same CUCM cluster for load-balancing reasons or to differing CUCM clusters a specific
JTAPI User account must be created on the Cisco CUCM server and each JTAPI
instance must connect to the CUCM with their own user credentials.
Genesys MSR Service Confguration:
Enter the values that were prepared during the Genesys platform preparation steps for Active
Recording.
Genesys EPR Service Configuration:
Enter the values that were prepared during the Genesys platform preparation steps for
Enhanced Passive Recording.
UCCE IM Configuration:
305
Enter the values that were prepared during the UCCE Configuration steps.
When configuring Cisco UCCE online and offline integration modules at the same time both
modules are configured during this step.
UCCE Offline Configuration
If you choose to enable the UCCE Offline integration module and the UCCE Online IM has
already been configured the credential are copied over.
If you configure UCCE Offline IM without the use of UCCE IM only the UCCE database
connection must be configured as follows.
306
Enter the values that were prepared during the UCCE Configuration steps.
UCCX IM Cofiguration:
Enter the values that were prepared during the UCCX Configuration steps.
Genesys IM Configuration:
Enter the values that were prepared during the Genesys platform preparation steps.
307
Instreamer Service Configuration:
Confirm the installation by selecting Yes.
1. Type the IP address of the instreamer in the following format: http://<IP

address>/xstream.
2. Type the name of the Instreamer.
3. 'From' and 'To' are phone numbers that will be used for saving calls in the DB. They will
be visible in Call Recording's Web UI and you can search through them.
4. Recording max. length - If a stream is longer than this setting it will be cut and the
second part will be recorded as a separate call.
5. Sop time for silence - The Instreamer service is able to detect if an RTP stream stops
coming to the server, if so it will close the calls within the given period.
Packet Sniffing:
308
In case you tag your RTP stream and only want to record what is tagged then chose "Tagged
UDP in VLAN". The recommended setting is: "Every UDP".
Database Service Configuration:
309
Choose your locale and select Next.
310
There are certain situations where you are required to allow remote access to your ZQM
database. For example in cluster installations where the DB is located on a separate machine.
To add access select Add.
A new window will open asking you to provide access details:
Type the IP address of the source machine and select Add. You can add more connections
by repeating this step.
Enabling FTP for CDR Service
QM Suite CDR Service requires the CDR files to be uploaded to the QM Suite server using
either secure FTP or unsecure FTP. During callrec-setup you can enable unsecure FTP. This
steps has a prerequisite - Preparing CUCM for CDR Service
For Secure FTP you can follow the guide - FTP Configuration
Oracle Database Client Configuration:
311
1. Oracle IP Address (or hostname): for example oracle.mycompany.com.
2. Oracle Port: default is 1521.
3. Oracle Database (or Service name for Call Recording schema): for example zoomd
b.
4. Oracle User (Call Recording database user): for example callrec.
5. Oracle Password (Call Recording user password): default is callrec.
6. Oracle WBSC Database (or service name for Quality Management schema): for
example zoomdb.
7. Oracle WBSC User (Quality Management database user): for example wbsc.
8. Oracle WBSC Password (Quality Management user password): default is wbsc
In steps 4 and 7 you are predefining the scheme names. On completion create the schemas
and restart Call Recording services.
SMTP/Email relay Configuration:
Provide your email server IP address if required and type the address that will be used as a
sender address in all emails sent from your ZQM server.
Tomcat Memory Settings:
312
Evaluate the usage of the Web Interface on this particular server. For example, if it is a
recording cluster then it is not necessary to allocate larger amounts of memory for it . If it is a
replay server with Quality Management installed then it will require more memory.
Call Recording Automatic Start Configuration:
It is recommended that Call Recording starts automatically after the server is booted up. If you
select No at this prompt Call Recording must be started manually.
Select Yes to start Call Recording automatically.

Monitoring settings
313
Select only SNMP if you dont need access to the Nagios web page or Nagios is already
running. We recommend using the SNMP and Nagios setting. If you select SNMP and
Nagios you must enable Apache HTTPD in QM Suite service configuration.
Further information can be found in the Call and Screen Recording Administration Guide in
the section for active monitoring.
X.509 details for QM Suite certificates
QM Suite offers advanced protocol security to communicate with the Cisco UCM and phones.
These configuration parameters allow you to predefine company details for issuing certificates
that will be used for secure communication.
The question doesn't appear if you have Key Manager enabled in this case you will be directly
prompted to provide the company details.
314
Select Yes if you want to configure the X.509 details and fill in the company details:
Key Manager Keys Configuration:

If the Key Manager service has been enabled during the service selection step you will be
prompted at this point to decide whether you wish to create a self-signed certificate and keys
for the Key Manager.
Using a self-signed certificate (as opposed to a commercial encryption certificate offered by
companies such as Thawte and Verisign) enables you to encrypt client-server
communications and audio/video calls immediately after setup but can lead to issues with
browsers and servers rejecting the certificate due to their weaker security status. It is,
however, suitable for testing purposes.
Please see the QM Call and Screen Recording Admin Guide for more information about
certificates, keys and PCI-DSS compliancy.
Select Yes if you want to generate certificates and keys.

Call Recording restart:
315
In the case that you have selected the Oracle Database client service:
1. Select No.
2. Create schemas for Call Recording and Quality Management(if required).
3. Restart ZQM services:
service callrec restart
If you select Database Service instead of Oracle client, select Yes.

Configuration Overview:
Before QM Suite setup completes the configuration and setup, it displays the information you
have entered so far. This allows you to verify the settings and change them if needed:
316
Scroll to the bottom of the Configuration Verification screen using the up and down
arrow keys.
Verify your configuration and setup settings.
Click Yes to complete configuration.
Click Back to change configuration and setup settings.
Click Exit to abort configuration and setup.
Completing Configuration
QM Suite setup requires up to several minutes to run the configuration and setup. A progress
bar displays the current setup progress.
If there is an error during configuration QM Suite setup displays a warning and continues. For
troubleshooting contact us at https://portal.zoomint.com/.
317
When setup and configuration are complete, QM Suite setup displays a notification message
with 30 seconds timeout:
Select OK
The QM Suite setup utility returns you to the command line prompt and (re)starts Call
Recording if configured to do so.
Starting Call Recording Services
If you did not select the automatic (re)starting of Call Recording after configuration, type
service callrec start at the command prompt.
Call Recording now starts each service and displays a status message for each service. This
can take several minutes.
The screenshot below is merely illustrative (you may have different services enabled), though
note the following:
Some services may fail when initially attempting to start.
318
This may be because they require further independent configuration (for example,
Synchro) or additional libraries or licensing (for example, UCCE).
If you have enabled Key Manager and have opted to generate self-signed certificates
the final stage of the encryption certificate generation is performed after Call Recording
has been fully started.
If the Call Recording restart is not successful (particularly if the 'Call Recording WEB'
component fails to start), this can indicate that the server doesn't have enough memory
available, which can be an issue particularly with virtual servers. Check the logs.
For example the web server log (less /opt/callrec/logs/web.log) and check for the
following lines which indicate that the Java VM needs more RAM:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Finishing Configuration
If everything went well please proceed with the Post Configuration Tasks.
319
Multi Server Configuration
Prerequisites
All servers in a muliti server deployment must share the same user and group IDs
A license file required per a CORE server. By a CORE server we mean the server
where the CORE services is enabled. So if you have two recording clusters with a
replay server then you require 3 license files.
DNS, NTP and SMTP on all servers should be configured same. For that check the
following files:
Configuration Location
DNS /etc/resolv.conf
/etc/hosts
Time/NTP /etc/ntp.conf
SMTP /etc/postfix/main.cf
Autostart of the following services should be enabled:

nfs, netfs, ntpd, postgreSQL, postfix
On Virtual machines ensure that VMWare tools are installed and running on all servers
of the cluster
The multi server deployment:

Cluster Configuration
320
Cluster Configuration
ZQM Suite can be deployed as a cluster server installation on a two or more independent
servers that work collectively as a single QM solution.
This guide covers the following topics
General steps for cluster installations
Functional Diagram
Installation of OS and ZQM
Configuration of ZQM packages
Database access
NFS configuration
ID of callrec user
System configuration verification
ZQM cluster configuration
ZQM cluster tuning
General steps for cluster installations
Functional Diagram
Prepare a functional diagram before every cluster installation. This diagram serves as a
graphical guide to the required installations steps and module distribution.
The functional diagram reflects the stages of the installation described in the following
sections.This stage should include both the module distribution and the NFS shares between
the servers.
Installation of OS and ZQM
After preparing the functional diagram of your ZQM solution install OS and ZQM packages on
all nodes of the cluster including the all prerequisites.
Configuration of ZQM packages
Configuration of ZQM packages for a cluster installation consists from the following steps:
1. Run callrec-setup in single server mode on every node of the cluster and choose the
services according to your functional diagram.
2. Perform additional configuration in order to interconnect the ZQM modules.
The first step is covered in Single Server Configuration.
In this document we'll focus on the second step, on interconnecting the ZQM modules.
Database access
Access to the server database must be configured manually if this step was not done during
the callrec-setup phase. It is suggested to configure the database access for all of nodes of
the cluster. If a replay server is to be installed, then this replay server must have access to the
database on the recording cluster as well.
The database is initialized by default to the /opt/callrec/data/psql directory. Access to the
database is configured in the /opt/callrec/data/psql/pg_hba.conf configuration file. It is
necessary to reload the PostgreSQL service to apply the changes.
321
For example:
host all all 192.168.10.1/32 trust
NFS configuration
ZQM works with local paths only. Because of this it is necessary to share the folders with the
media files within the cluster installation. The database records do not contain any server
names, hostnames or IP addresses, therefore all modules have to be able to find the media
files on the file system under the same path.
Example:
The decoder runs on server callrec-XX-b while the Web UI runs on server callrec-XX-a. The
decoder is configured to save mp3 files to the /opt/calrec/data/calls directory on
the callrec-XX-b server (that is, the mp3 file will be saved on the filesystem as
/opt/callrec/data/calls/20130801/aaa.mp3). The same location of the mp3 file is saved to the
database.
The database record in the cfiles table will contain in the cfpath column value of local path of
the mp3 file (that is, /opt/callrec/data/calls/20130801/aaa.mp3).
When the call is to be played in the Web UI of GQM call recording, then the Web UI sends
select to the database for mp3 file location. The answer will be the local path (in the same
example /opt/callrec/data/calls/20130801/aaa.mp3 ). Web UI starts to search the mp3 on
the callrec-XX-a server local filesystem (in this example
/opt/callrec/data/calls/20130801/aaa.mp3).
If the folders are not shared under the same location, then the Web UI reports error message
"No media file found". The /opt/callrec/data/calls needs to be exported from callrec-XX-b
to callrec-XX-a and mounted the same way on this callrec-XX-a server.
Note
Please note that in deployments where Screen Capture and Screen Capture Uploader
are on different servers NFS mountpoint with lookupache=positive option is
mandatory. The Screen Capture can thus verify that the RECD file exists and the
information about RECD file can be saved to the DB.
ID of callrec user
In cluster installations, it may happen that the ID and GID of callrec user differs between the
servers. This can result in a situation when callrec user on one server cannot read/write the
media files onto another server because of insufficient permissions.
It is necessary to unify the IDs of callrec user between the servers to eliminate this issue. This
issue mostly happens when a new server is added to the call recording cluster while
previously installed servers are upgraded to the same ZQM version as the new server has
installed.
Other possibility for the ID difference is when some servers are hardware servers while other
are virtual machines, or when someone starts to create Linux users after the OS is installed,
before ZQM installation is performed.
System configuration verification
Verify that the system configuration on all of the servers in the cluster is the same. It is
important to pay attention to the following configuration:
322
DNS:
/etc/resolv.conf
/etc/hosts
time/NTP:
/etc/ntp.conf
Email sending:
/etc/postfix/main.cf
Enable automatic startup of important services upon server bootup (nfs, netfs, ntpd,
postgreSQL, postfix)
On virtual machines it is needed to verify that the VMware tools are installed and running.
Verify which network driver is used. It is suggested to use vmxnet3 driver. If this driver is not
supported then it is possible to use vmxnet driver as well.
ZQM cluster configuration
This step usually requires the manual editing of configuration files.

All .properties files (configuration of loggers), callrec.conf and callrec.derived are
read locally by each module.
All .xml configuration files(except *log4j.xml files) are read by the ConfigManager
module. All other modules then retrieve their configuration by communicating with the
ConfigManager module.
All PSQL config files (postgresql.conf, pg_hba.conf) are also read locally by the
PSQL instance.
ZQM cluster tuning
This part requires good knowledge of customer's environment. Several parameters can be
tuned based on the network and server performance. When a huge amount of calls is
expected to be recorded, then the JVM parameters of the correspondent modules need to be
increased. The JVM parameters can be also changed to support different character sets
there. NFS mounting parameters are sometimes modified to improve performance of file
sharing within the servers.
323
QM Suite Services
QM Suite offers a number of services.

QM Suite Services
List of required services based on products
Examples of QM Suite solutions
Example 1:
Example 2:
Some of the features require a separate license file or a license feature
QM Suite Services
The following table lists the QM Suite services that are available for selection:
Service Name Obligation Type Notes
RMI Service Obligatory Core RMI Service is always installed so that the
per QM modules within Call Recording can
server communicate with each other. Contains the
naming service.
Configuration Obligatory Core Configuration Manager is installed in all

Manager per QM cases apart from clustered recorder and
solution decoder servers and provides a standard
configuration file system.
Key Manager Optional Security Provides call and screen key encryption and
decryption to comply with PCI DSS.
Passive Optional Recorder Records calls from network SPAN ports.

Recorder Note: Do not select for MSR.
Active Recorder Optional Recorder Records calls using Active recording

technology.
Note: You must select the Active Recorder
for MSR do not select thePassive Recorder.
Decoder Optional Decoder Decodes the PCAPs and encodes the

Service media to MP3 files.
Core Service Obligatory Core Provides the business logic for all recording
per QM operations. Core service is always installed
solution on a single server installation. Every cluster
must have one server with core installed.
324
Cisco JTAPI Optional Active Driver A module that processes JTAPI events
Service received from CUCM to catch the call
signaling.
Note: If you select this service do not select
EPR, or MSR. You must already have
access credentials to CUCM to configure
this service. Please see QM Suite
Implementation Guide for details.
Cisco Skinny Optional Protocol Enables Call Recordingto sniff Cisco Skinny
Service protocol data for information about calls.
Note:If you select this service do not select
EPR, or MSR services.
Genesys EPR Optional Active Driver Connects to Genesys T-Server for

Service Enhanced Passive Recording. This driver
also provides Genesys CIM integration.
Note:If you select this service do not select
MSR, JTAPI, SIP, Skinny, or GIM services.
You must add a new user (username and
password) for Call Recording to
communicate with Genesys Configuration
Manager.
Genesys MSR Optional Active Driver Connects to Genesys T-Server for Media
Service Stream Replication
services. This driver also provides Genesys
CIM integration.
EPR, JTAPI, SIP,Skinny, or GIM. You must
add a new user (username and password)
for Call Recording to communicate with the
Genesys Configuration Manager.
Avaya Service Optional Active Driver Connector to Avaya Communication Driver.

You may combine this driver with the GIM
service if you require integration with
Genesys CIM to provide attached data.
EPR, MSR, JTAPI, SIP or Skinny
services. You must have a user for
communication with TSAPI and a user for
communication with DMCC.
325
Avaya EPR Optional Enhanced Connects to Avaya TSAPI to provide
Service Passive Enhanced Passive Recording of an Avaya
Driver platform based on the Communication
Manager.
Note: If you select this service do not select:
Avaya service, Genesys EPR, Genesys
MSR, JTAPI, SIP or Skinny services. You
must have a user configured for
communication with TSAPI and a user for
communication with Avaya SMS WS. A
more detailed description can be found in
ASR Service Optional Active Driver Connects to Cisco CUBE platform and
provides recording of CUBE forked calls.
EPR, MSR, SIP or Skinny services.
SIP Service Optional Protocol SIP service enables Call Recording to sniff
SIP data information about calls.
EPR, or MSR services.
Call Recording Obligatory Web Web User Interface for the Call Recording
Web User per QM application - application.
Interface solution UI
Tomcat server for Call Recording and
Quality Management GUI.
Apache HTTPD Optional For large installations. Provides load

balancing when there are a lot of users and
multiple Tomcat servers.
Speech Optional Speech Main speech analysis and search

Analytics Analytics application.
Service
UCCE IM Optional Integration Cisco UCCE integration, often used with the
Service Module JTAPI service.
Note: You must already have access
credentials to CUCM to configure this
service. Please see QM Suite
Implementation Guide for details. If you
select the UCCE service do not select the
UCCX service.
326
UCCX IM Optional Integration Cisco UCCX integration, often used with the
Service Module JTAPI service.
select the UCCX service do not select the
UCCE service.
Genesys IM Optional Integration Genesys CIM integration, often used with

Service Module the SIP service.
EPR, or MSR. You must add a new user
(username and password) for Call
Recording to communicate with Genesys in
the Genesys Configuration Manager.
Synchro Optional Synchro Call and Screen synchronization tool for

Service cluster configurations.
Screen Capture Optional Screen Server-side screen recording component.

Service Recorder
Media Encoder Optional Encoder Encodes raw screen data into MP4 files.
Service
Tools Service Obligatory Tools Maintenance (MLM) tools scheduling

per QM service.
solution
Fixpayloads Optional Payloads Enables the recovery of couples where

Service there are different Codecs in each stream.
Instreamer Optional Other Barix Instreamer service provides interface

Service to record analogue lines.
Database Obligatory Database Embedded PostgreSQL database.

Service per QM Note: If you select this service do not select
solution* Oracle Database Client.
Oracle Obligatory Database Client for connecting to external Oracle

Database Client per QM databases.
solution*
Database Service.
Web Services Optional Web SOAP-based Web API. Currently used to

API application - stop/start/pause/resume recording and
API check the recording status.
327
Prerecording Optional Web Backend application used in Cisco
application environments where Prerecording is used
- backend on the agent phones.
Ad-hoc, on demand call recording feature
Screen Capture Optional Web Backend application used in Screen

Uploader application Capture process which receives captured
- backend screens from the Screen Capture Client
running on agent desktops.
Cannot run without the Call Capture
Service.
Quality Optional Quality Main Quality Management web application.

Management Management
Interaction Optional Web HTML5-based player currently used as

Player application - opt-in replacement for the default
player Java-based Universal Player in Quality
Management application.
Cannot run without Quality Management
Universal Optional Web Backend application used to communicate

Communicator application - with the Java-based Universal Player in
player Quality Management application.
backend
Cannot run without Quality Management.
Logi Reports Optional Web Used in Quality Management application to

application compute and display specific reports.
- UI
Cannot run without Quality Management.
MediaSense Optional Integration Integration with Cisco MediaSense

Integration Module recording platform
CDR Service Optional Integration Processes CDR files provided by CUCM

module and adds additional information to the calls.
UCCE Offline Optional Integration Cisco UCCE offline integration, often used
Service Module with the JTAPI service.
select the UCCE service do not select the
UCCX service.
*Only one of the database services has to selected, either Database Service or Oracle
Database Client.
The Obligation column indicates whether the service is optional or not:
1.
328
1. Obligatory per QM server means that this service must be enabled on every server
which has any QM Suite services. QM services won't function without it. However, if you
have a dedicated DB server that has only a database service (PostgreSQL or Oracle)
running, then you don't need to have this service enabled.
2. Obligatory per QM solution means that this service must be enabled on a ZQM
solution. In the case that you have a cluster solution with more than one server, then
this service has to run on one of them. The solution won't function without it.
3. Optional means that the service doesn't have to run at all. It brings additional features
and the solution can function without them.
List of required services based on products
Product Call Recording Avaya Active Cisco Active Cisco

Recording Recording Passive
Recording
Required RMI Service Avaya Cisco JTAPI Cisco

Services Configuration Service Service JTAPI
Manager Passive Active Recorder Service
Core Service Recorder Decoder Passive
Web Service Decoder Service Recorder
Tools Service Service Decoder
Database Service
Service or
Oracle
Database Client
Optional Apache HTTPD Fixpayloads Fixpayloads Fixpayloads

Services UCCE IM Service Service Service
UCCX IM
Genesys IM
Synchro Service
Product Genesys Active Genesys Passive Screen Capture

Recording - MSR Recording - EPR
Required Genesys MSR Genesys EPR Service Screen Capture

Services Service Passive Recorder Service
Active Recorder Decoder Service Media Encoder
Decoder Service Service
Optional Fixpayloads Service Fixpayloads Service

Services
Product Live PCI DSS Quality Management, E-learning, Voice of

Monitoring the Customer
Required One of the Key Quality Management

Services drivers Manager
329
Optional Speech Analytics Service
Services
Note that Call Recording is a base for all other products. Therefore you can combine:
Call Recording+Avaya Active Recording+Screen Capture for example.
Examples of QM Suite solutions
Example 1:
Solution Description: CUCM Active Recording with Screen recording and UCCE integration,
DB type: PostgreSQL
ZQM products: Call Recording+Cisco Active Recording, Screen Capture, UCCE Integration
Required components table:
Installation Type Single Server Cluster Example 1 Cluster Example 2

Required RMI Service Server 1: Server 1:
Components Configuration
RMI Service RMI Service
Manager
Configuration Configuration
Active Recorder
Manager Manager
Decoder Service
Core Service Active Recorder
Core Service
Cisco JTAPI Decoder Service
Cisco JTAPI
Service Core Service
Service
Screen Capture Cisco JTAPI
Web Service
Service Service
Screen Capture
Media Encoder Tools Service
Service
Service
Media Encoder Server 2:
Service Server 2:
RMI Service
Tools Service
RMI Service Web Service
Database Service
Active Recorder Database Service
Decoder Service Screen Capture
Tools Service Service
Media Encoder
Server 3:
Service
RMI Service
Web Service
Database Service
Installation Type HA Replay Server
330
Required Components Server 1: RMI Service
Configuration Manager
RMI Service
Core Service
Synchro Service
Active Recorder
Media Encoder Service
Decoder Service
Tools Service
Core Service
Database Service
Web Service
Web Service
Screen Capture Service
Tools Service
Database Service
Cisco JTAPI Service
Server 2:
RMI Service
Active Recorder
Decoder Service
Core Service
Web Service
Screen Capture Service
Tools Service
Database Service
Cisco JTAPI Service
Example 2:
Solution Description: Genesys Passive Recording with Live Monitoring, Quality Management
and E-learning. DB type: Oracle
ZQM products: Call Recording+Genesys Passive Recording, Live Monitoring, Quality
Management, E-learning.
Required components table:
Installation Type Single Server Cluster Example 1 Cluster Example 2
331
Required RMI Service Server 1: Server 1:
Components Configuration
RMI Service RMI Service
Manager
Configuration Configuration
Passive Recorder
Manager Manager
Decoder Service
Core Service Passive Recorder
Core Service
Genesys EPR Decoder Service
Genesys EPR
Service Core Service
Service
Screen Capture Genesys EPR
Web Service
Service Service
Tools Service
Media Encoder Tools Service
Oracle Database
Service
client Server 2:
Quality Server 2:
RMI Service
Management
RMI Service Web Service
Passive Recorder Oracle Database
Decoder Service client
Tools Service Screen Capture
Service
Server 3:
Media Encoder
RMI Service Service
Web Service Quality
Oracle Database Management
client
Quality
Management
Installation Type HA Replay Server
332
Required Server 1: RMI Service
Components Configuration Manager
RMI Service
Core Service
Configuration
Genesys EPR Service(Required by Live
Manager
Monitoring)
Passive Recorder
Synchro Service
Decoder Service
Tools Service
Core Service
Oracle Database client
Genesys EPR
Web Service
Service
Quality Management
Web Service
Tools Service
Oracle Database
client
Quality
Management
Server 2:
RMI Service
Configuration
Manager
Passive Recorder
Decoder Service
Core Service
Genesys EPR
Service
Web Service
Tools Service
Oracle Database
client
Quality
Management
333
Creating DB Schema in Oracle
Installing the Database Schema

Additional Tasks
Update Oracle Schema
Start Call Recording
Removing the Database Schema
Troubleshooting Database Parameters
Installing the Database Schema
When configuring an Oracle connection for the first time, create Call Recording and Quality
Management user schema (database tables, triggers, etc.) in the Oracle database. This is
achieved in one operation by running a schema creation script in the
/opt/callrec/dbscripts/oracle directory.
To remove the existing Call Recording and Quality Management schema from the Oracle
database, see Removing the Database Schema.
The script is available in two versions: The create_schemas.sh script is a Linux shell
script, while the create_schemas.bat script is a Windows DOS script. In both cases, the
script must be run on a host server that has the Oracle 11g database client installed. This
Oracle client software is automatically included as part of the QM Suite installation process,
so the create_schemas.sh. Linux script can be run directly on the QM Suite server, as
described here. An additional benefit of running the schema creation script on the QM
Suite server, is the possibility of ensuring that there is correct connectivity between the server
and Oracle database.
If you are running the command from your QM server, make sure to execute the
create_schemas script after the Call Recording-setup process.
The Linux version of the script must be run by the root user. The scripts usage and
parameters are as follows:
/opt/callrec/dbscripts/oracle/create_schemas.sh system_user
system_password server database_name callrec_schema_name
wbsc_schema_name [options]
The DOS version is similar to the Linux version, though create_schemas.bat is run.
The following parameters are required:
system_user - Username of database administrator account (see Prerequisites:
Preparing for Oracle).
system_password - Password of database administrator account.
server - IP address or hostname or FQDN of your Oracle server.
database_name - Oracle Service name for QM Suite.
callrec_schema_name - Call Recording schema user entered as Oracle User earli
er during QM Suite setup.
wbsc_schema_name - Quality Management schema user entered as Oracle WBSC
User earlier during QM Suite setup.
The following parameters are optional:
334
--tbscallrec value - Name of tablespace used for Call
Recording (default: USERS)
--tbswbsc value - Name of tablespace used for Quality Management (default: USE
RS).
--temptbs value - Name of tablespace for temporary files (default: TEMP).
--create_admin Y [or] N - create the user callrec_wbsc_admin(with password: a
dm) with administrative rights for the Call Recording and Quality Management schema
(default: N).
--data Y [or] N - create default data: User admin, roles, etc. (default: Y) This
should normally be set to Y for new installations the only case where the data is not
required is when preparing a new database for the migration of existing data.
--admin - Use the system user for creating the DB structure.
--port - Oracle server port. Default: 1521.
--callrec_pwd - Password for Call Recording schema user. Default: callrec
--wbsc_pwd - Password for Quality Management schema user. Default: wbsc
See the following Linux example:
/opt/callrec/dbscripts/oracle/create_schemas.sh system sys
oracle.mycompany.com zoomdb callrec wbsc --create_admin Y
Additional Tasks
Update Oracle Schema
After the create_schema.sh script is run, the new Call Recording and Quality Management
schema users have their passwords set to the default password values on the Oracle
configuration screen in the QM Suite setup. See the Oracle User Password and Oracle
WBSC User Password properties in the chapter: Single Server Configuration for more
details. If the default values were used, no updates are required.
If different password values were used, reset the passwords for these Call Recording and
Quality Management schema users within Oracle.
Consult the Oracle documentation for how to reset database user passwords.
Start Call Recording
After schema installation is complete, start Call Recording at the command line, ensuring that
the Call Recording Core service starts (indicating correct database connection):
service callrec start
Note that some other services may not start as they are not fully configured or await license
activation, see the QM Suite Implementation Guide for more details.
Installation and basic setup are now complete.
Removing the Database Schema
If an attempt at installing the Call Recording and Quality Management database schema was
only partially successful, or they are no longer required in the Oracle database, remove the
schema using the drop_schemas script (in the same scripts directory as the
335
create_schemas script: /opt/callrec/db_oracle_scripts/scripts).
The removal script is available in two versions; the drop_schemas.sh script is a Linux shell
script, and the drop_schemas.bat script is a Windows DOS script.
The scripts usage and parameters (for the Linux version) are as follows:
/opt/callrec/dbscripts/oracle/drop_schemas.sh system_user
system_password server database_name callrec_schema_name
wbsc_schema_name [options]
The DOS version is similar to the Linux version, but drop_schemas.bat is run without the
sh command preceding it.
The following parameters are required:
system_user - Username of database administrator account (see Prerequisites:
Preparing for Oracle).
system_password - Password of database administrator account.
server - IP address or hostname or FQDN of your Oracle server.
database_name - Oracle Service name for QM Suite.
callrec_schema_name - Call Recording schema.
wbsc_schema_name - Quality Management schema.
The following parameters are optional:
--drop_admin Y [or] N: delete the user callrec_wbsc_admin. This user is
created by the create_schemas script when the create_admin Y option is
specified. The user has administrative rights for the Call Recording and Quality
Management schema. See the topic Install the DB Schema for more information
--port - Oracle server port. Default: 1521.
See the following Linux example:
/opt/callrec/dbscripts/oracle/drop_schemas.sh system sys
oracle.mycompany.com zoomdb callrec wbsc --drop_admin Y
Troubleshooting Database Parameters
If there are any issues in starting up, check the database parameters in
/opt/callrec/etc/core.xml, and the error log at /opt/callrec/logs/error.log.
After completing the QM Suite setup with the Oracle Database Client service activated, the
core.xml file should contain database pool configuration entries similar to the following (here
with the default entries used earlier):
336
<Pool name="callrec"
poolType="cz.zoom.util.db.pool.ibatis.IbatisPool">
<Url dbName="zoomdb" host="oracle.mycompany.com" port="1521"/>
<Login password="callrec" userName="callrec"/>
<Connections init="1" max="20" timeOut="5"/>
<SpecificSetting>
<Value name="sqlMapClass">
cz.zoom.callrec.core.callstorage.pojo.oracle.SqlMap</Value>
</SpecificSetting>
</Pool>
<Pool name="scorecard"
poolType="cz.zoom.util.db.pool.ibatis.IbatisPool">
<Url dbName="zoomdb" host="oracle.mycompany.com" port="1521"/>
<Login password="wbsc" userName="wbsc"/>
<Connections init="1" max="20" timeOut="5"/>
<SpecificSetting>
<Value name="sqlMapClass">
cz.zoom.scorecard.business.data.xmlOracle.SqlMap</Value>
</SpecificSetting>
</Pool>
Modify the dbName, host, password, and username properties (for all occurrences) if
required, then restart Call Recording:
service callrec restart
If there are issues with connections between Call Recording or Quality Management and the
Oracle database instance, contact us at https://portal.zoomint.com/
337
Post Configuration Tasks
After finishing the configuration of ZQM packages please proceed with the following checks
and tasks
Time Synchronization
Setting a Custom Locale for QM Suite Modules
Time Synchronization
If the Call Recording installation is part of a multiple site cluster configuration including Cisco
CUCM, all the servers in the cluster should be time-synchronized with the same server as
Cisco CUCM. We recommend you to use the NTP service, more info can be found here: NTP
configuration
If the servers are not properly synchronized, some recordings may have issues with stream
synchronization.
Setting a Custom Locale for QM Suite Modules
By default QM Suite modules have the en_US locale set and if a custom locale is required it
should be configured manually. This can be set in the file
/opt/callrec/etc/callrec.conf by adding additional parameters: -Duser.language
and -Duser.country
The following example shows how to set certain modules to the en_GB locale. Based on your
solution modify the appropriate lines in your /opt/callrec/etc/callrec.conf file:
For Quality Management and Call Recording Web UI:
JAVA_OPTS_WEB="-jvm server -XX:NewSize=256m -XX:SurvivorRatio=16
-XX:MaxNewSize=256m -XX:MaxPermSize=256m -XX:PermSize=256m
-Xms512m -Xmx512m -XX:+DisableExplicitGC -Duser.language=en
-Duser.country=GB"
For the Genesys Integration module:

JAVA_OPTS_GENESYS="-server -Xmx64m -Duser.language=en
-Duser.country=GB $JAVA_OPTS"
For the UCCE Integration module:

JAVA_OPTS_IPCC="-server -XX:-UseGCOverheadLimit
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
-Duser.language=en -Duser.country=GB -Xmx256m $JAVA_OPTS"
For the UCCX Integration module:

JAVA_OPTS_IPCCEX="-server -Xmx64m -Duser.language=en
-Duser.country=GB $JAVA_OPTS"
For the CORE module
338
JAVA_OPTS_CORE="-server -Xmx96m
-Dcom.sun.CORBA.transport.ORBUseNIOSelectToWait=false
-Duser.language=en -Duser.country=GB $JAVA_OPTS "
The range of values for these parameters can be found at the following URLs:
user.language: ISO 639-1 / ISO-639-2 code list
(http://www.loc.gov/standards/iso639-2/php/code_list.php).
user.country: ISO 3166 code list
(http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html).
339

Deployment Guide 5 8 1.0 English

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Deployment Guide 5 8 1.0 English

Transféré par

Droits d'auteur :

Formats disponibles

ZOOM Quality Management Suite

ZOOM International s.r.o.

Europe, Czech Republic Americas Russia, CIS

Karolinsk 650/1, 186 00 810 Crescent Centre Drive TN Ulitsa Krzhizhanovskogo,

Poland, Baltics Middle East Ukraine

44 Market St, Level 26,

You can always reach us at: sales@zoomint.com

Avaya Call Recording Architecture

Prerequisites: Configuration of platform for recording

Single Server Configuration

Avaya Call Recording Architecture CentOS

Select a Deployment Architecture Select Database

Single Server Deployment Postgres

Planning Hardware Requirements Support of VMware ESX/ESXi 4.1 and

Platforms and features not supported

Overview Any Avaya PBX solution based on a

500 agents to be recorded

License Type Number of Licenses

TSAPI 700 (500 for Service Observing

DMCC 200 (for Single Step Conference)

MedPro 200 (for Single Step Conference)

DMCC = Device Media Call Control

This feature is available from QM Suite version 5.6.

This sections describes Avaya Enhanced Passive Recording(EPR) in the QM Suite.

PBX platform: Avaya Communications Manager 5.2.1 and above

Preparing Avaya for integration

External data obtained by Avaya Active Recording

Property Name Description

AVCM_stationName The name administered for this device.

AVCM_callId Holds the call ID (Integer) assigned to the call by the

AVCM_universalCallId Holds the Universal Call ID (Long) assigned to the

AVCM_universalCallIdStr Holds the Universal Call ID (String) assigned to the

AVCM_so_active Indicates whether the service which is observing is

AVCM_incoming Indicates whether an incoming call is to the requested

AVCM_incomingTrunkCall Indicates that an outside call is coming in from a trunk

AVCM_recordingExtension The extension that has requested the recording.

AVCM_recordingExtensionName The name administered for the station which is

AVCM_agentName If a call center agent is involved in a call, this field

External data obtained by Avaya EPR

Property Name Description

AVCM_tsapiCallID Holds the call ID (Integer) assigned to the call by the

AVCM_UCID Holds the Universal Call ID (Long) assigned to the call by

AVCM_conferenceMembers The participants are alphabetically sorted in ascending

Avaya Integration with Genesys CIM

ZOOM Quality Management communicates with the Communication Manager by exchanging

Number of communication messages each C-LAN card is able to handle:

Number of connections to C-LAN:

Cisco Recording Methods

Passive SPAN Based Recording

Multi-Site Passive Recording

Cisco Enhanced Passive Recording with JTAPI Signaling

Cisco Selective User Recording

Only Cisco 3G IP phones can be recorded through Selective User Recording.

Cisco Active Recording Integrated with UCCE

Active Recording Integrated with UCCX

CUBE Active SIP Recording

This feature is available from QM Suite version 5.5.

Enabling CUBE Active SIP Recording

Advanced protocol security

This feature is available from QM Suite version 5.3.

Enabling advanced protocol security

Configuring CUCM for secure JTAPI

1. Enabling secure JTAPI

This feature is available from QM Suite version 5.3.