Recorder SysInfra Guide

Impact 360 Recorder
System Infrastructure Guide
Release 7.8 SP3

January, 2009
2008 Verint Systems Inc. All Rights Reserved Worldwide.

Confidential and Proprietary Information of Verint Systems Inc.
The Verint Systems Inc. products are protected by one or more of the following U.S., European or
International Patents: USPN 5,659,768; USPN 5,790,798; USPN 6,278,978; USPN 6,370,574; USPN
6,404,857; USPN 6,510,220; USPN 6,757,361; USPN 6,782,093; USPN 6,952,732; USPN 6,959,405;
USPN 7,047,296; USPN 7,149,788; USPN 7,155,399; USPN 7,203,285; USPN 6,959,078; USPN
6,724,887; USPN 7,216,162; European Patent 0 833 489; GB 2374249; and other provisional rights
from one or more of the following Published US Patent Applications: US 10/061,469; US 10/061,489;
US 10/061,491; US 11/388,854; US 11/388,944; US 11/389,471; US 10/818,787; US 11/166,630;
US 11/129,811; US 11/477,124; US 11/509,553; US 11/509,550; US 11/509,554; US 11/509,552;
US 11/509,549; US 11/509,551; US 11/583,381; US 10/181,103; US 09/825,589; US 09/899,895;
US 11/037,604; US 11/237,456; US 09/680,131; US 11/359,356; US 11/359,319; US 11/359,532;
US 11/359,359; US 11/359,358; US 11/359,357; US 11/359,195; US 11/385,499; US 11/394,496;
US 11/393,286; US 11/396,061; US 11/395,992; US 11/394,410; US 11/394,794; US 11/395,350;
US 11/395,759; US 60/799,228; US 11/479,926; US 11/479,841; US 11/479,925; US 11/479,056;
US 11/478,714; US 11/479,899; US 11/479,506; US 11/479,267; US 60/837,816; US 11/528,267;
US 11/529,132; US 11/540,281; US 11/540,322; US 11/529,947; US 11/540,902; US 11/541,056;
US 11/529,942; US 11/540,282; US 11/529,946; US 11/540,320; US 11/529,842; US 11/540,904;
US 11/541,252; US 11/541,313; US 11/540,086; US 11/540,739; US 11/540,185; US 11/540,107;
US 11/540,900; US 10/610,780; US 10/832,509; US 11/608,340; US 11/608,350; US 11/608,358;
US 10/771,315; US 10/771,409. Other U.S. and International PatentsPending.
VERINT, the VERINT logo, ACTIONABLE INTELLIGENCE, POWERING ACTIONABLE INTELLIGENCE,
STAR-GATE, RELIANT, VANTAGE, X-TRACT, NEXTIVA, ULTRA, AUDIOLOG, WITNESS, the WITNESS
logo, IMPACT 360, the IMPACT 360 logo, IMPROVE EVERYTHING, EQUALITY, CONTACTSTORE, and
CLICK2STAFF are trademarks or registered trademarks of Verint Systems Inc. or its subsidiaries.
Other trademarks mentioned are the property of their respective owners.
Doc Version 7.8.3.5
2009-01-07
C o n t e n t s
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intended Audience for This Guide . . . . . . . . . . . . . . . . . . . .
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of Information in This Guide . . . . . . . . . . . . . . . . . .
Conventions Used in This Guide . . . . . . . . . . . . . . . . . . . . .
If You Need Help . . . . . . . . . . . . . . . . . . . . . . . . . .
Before You Contact Technical Support. . . . . . . . . . . . . . . . . . . . . . . . .
Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . .
Verint Witness Actionable Solutions Website and the Customer Interaction Center (CIC) .
Telephone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Direct internet FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other support and training alternatives . . . . . . . . . . . . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . 9
. 10
. 10
. 11
. 12
. 14
. . 14
. 15
. . 15
. . 15
. . 16
. . 16
. . 16
Recorder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Recorder-at-a-Glance . . . . . . .
Recorder Management . . . . . . .
Using Recorder Manager . . . . . . . .
Using Enterprise Manager . . . . . . .
Recorder Features and Benefits . . . .
Enterprise Manager Features and Benefits
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Recorder Infrastructure
. . .
. . .
. . . .
. . . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . .
. . .
. . 18
. . 20
. . . 20
. . . 21
. . 23
. . 24
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Recorder Environment . . .
PSTN . . . . . . . . . . . .
PBX . . . . . . . . . . . .
CTI Server . . . . . . . . .
Agent Telephones . . . . . .
Unify Server . . . . . . . .
Integration Service Server . .
Recorder Server . . . . . . .
Search and Replay . . . . .
Database . . . . . . . . . .
Centralized Archiving . . . .
Live Monitoring via Observer .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
. . 26
. . 27
. . 27
. . 27
. . 27
. . 28
. . 29
. . 33
. . 34
. . 34
. . 34
Contents
Live Monitoring via Web Observer . . . . . . . . . . . . . . . . . . . . . . . .

Screen Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inline Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Recording Methods . . . . . . . . . . . . . . . . . . . .
Trunk-Side TDM Recording . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gateway Recording (IP Recording) . . . . . . . . . . . . . . . . . . . . . . .
Station-Side TDM Recording . . . . . . . . . . . . . . . . . . . . . . . . . .
Extension-Side Recording (IP Recording) . . . . . . . . . . . . . . . . . . . .
Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . .
Single-node Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multi-node Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enterprise Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Control Forwarding and Intelligent Call Control Distribution (IP Recording Only)
Network Topology and Traffic Routing . . . . . . . . . . . . . . . . .
Time Synchronization . . . . . . . . . . . . . . . . . . . . . . .
Supported Hardware and Software . . . . . . . . . . . . . . . . . .
Physical Connectivity Options . . . . . . . . . . . . . . . . . . . . . . . . . .
Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CTI Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voice Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Label Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Media Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Recording and Administration
.
.
.
.
.
.
.35
.35
.35
.35
.36
. 37
.37
.39
.40
.41
. 42
.42
.44
.45
.46
. 48
. 49
. 50
.50
.50
.50
.51
.52
.52
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Recording Process . . . . . . . . . . . . . . . . .
Before Recording . . . . . . . . . . . . . . . . . . . . . .
Capturing and Recording Voice and Screen Data . . . . . . . .
Capturing and Recording Associated Call Data . . . . . . . . .
Recording Calls With the Call Control Engine . . . . . . . . . .
Recording Calls Without the Call Control Engine . . . . . . . .
TDM Control Fallback. . . . . . . . . . . . . . . . . . . . .
IP Recording Modes . . . . . . . . . . . . . . . . . . . . .
Using VOX Detection in IP Recording . . . . . . . . . . . . .
Using non-CTI Recording Methods . . . . . . . . . . .
Understanding VOX . . . . . . . . . . . . . . . . . . . . .
Difference between VOX and D-channel, line voltage, and CASS
CCE Control Option/Fallback Feature . . . . . . . . . . . . .
Triggering a Recording . . . . . . . . . . . . . . . . . . . .
System Administration . . . . . . . . . . . . . . .
Recorder Manager Functionality. . . . . . . . . . . . . . . .
Enterprise Manager Functionality . . . . . . . . . . . . . . .
Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 54
. .54
. .55
. .56
. .56
. .57
. .57
. .57
. .58
. . 61
. . .61
. . .63
. . .64
. . .64
. . 66
. . .66
. . .66
. . .67
.
.
.
.
.
.
.
.
Recorder Functionality
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recorder Architecture .
69
. . 70
Full-time Recorder System Infrastructure Guide

2005-2008 Witness Systems, Inc. Confidential and Proprietary Information of Witness Systems, Inc. All rights reserved, worldwide.
Contents
Recorder Server Components . . . . . . . . . .

Collaboration Architecture . . . . . . . . .
Collaboration Description . . . . . . . . . . . .
Collaboration Components . . . . . . . . . . .
Configuration Architecture . . . . . . . . .
Retrieval Architecture . . . . . . . . . . .
Retrieval Description . . . . . . . . . . . . . .
Content Server Component. . . . . . . . . . .
Disk Management Architecture. . . . . . . .
Disk Management Description . . . . . . . . .
Disk Management Components . . . . . . . . .
Disk and System Performance . . . . . . . . .
Application Server and Workstation Applications .
Application Server Description . . . . . . . . .
Application Server Components . . . . . . . . .
Workstation Component . . . . . . . . . . . .
Live Monitor Architecture. . . . . . . . . .
Live Monitor Description . . . . . . . . . . . .
Live Monitor Interfaces . . . . . . . . . . . . .
Live Monitor Components . . . . . . . . . . .
ContactStore Plus Architecture . . . . . . . .
Description . . . . . . . . . . . . . . . . . .
Live Monitor and Archive Exceptions . . . . . .
Streaming Retriever Enhancement . . . . . . .
ContactStore Plus Components . . . . . . . . .
Screen Capture Architecture . . . . . . . .
Screen Capture Support in CTI Environments . .
Screen Capture Support in non-CTI Environments
Understanding Workstations, Seating, Phones and
5
. .
.
. .
. .
.
.
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
.70
. 72
.72
.73
. 74
. 76
.76
.76
. 78
.78
.78
.79
. 83
.83
.83
.84
. 85
.85
.86
.86
. 88
.88
.89
.89
.89
. 91
.91
.92
.93
Recording with DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
Recording with Cisco DMS . .

Cisco Call Recording Overview
Recording Sessions . . . . .
Recording Invocations . . . .
Recorder Integration . . . . .
Call Recording dScenarios . .
Recording with Nortel DMS . .
Nortel Call Recording Overview
Recording Invocations . . . .
Call Recording Scenario . . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
Passive Recording with Avaya

Overview . . . . . . .
Recording Avaya Calls . . .
Tagging Avaya Calls . . .
Avaya System Configurations
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . .
. . . .
. . . . . .
. . . . . .
. . . .
. . . .
. . . . . .
. . . . . .
. . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . . . .
. . . . . .
Workspaces
.
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
. .
.
.
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
. .
.
.
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
. .
.
.
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 100
. 100
. 101
. 101
. 101
. 102
. 106
. . 106
. . 107
. . 107
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
112
113
113

Contents
Functionality without a CTI component . . . .

Functionality with CTI integration . . . . . . .
Configuration Procedures. . . . . . . . .
Configuring Avaya with the CTI Component . .
Configuring Avaya without the CTI Component.
7
User Defined Fields
.
.
.
.
.
. . .
. . .
. .
. . .
. . .
.
.
.
.
.
. . .
. . .
. .
. . .
. . .
.
.
.
.
.
. . .
. . .
. .
. . .
. . .
.
.
.
.
.
. . .
. . .
. .
. . .
. . .
.
.
.
.
.
. . .
. . .
. .
. . .
. . .
.
.
.
.
.
. . 114
. . 114
. 114
. . 114
. . 115
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Understanding Call Data . . . . . . . . .

Unify or Integration Service to Search and Replay
Attributes With Integration Service . . . . .
Attributes Provided by Card Model Families . .
Attributes Provided by E1/T1 Voice Cards . . .
Attributes Provided by SCCP . . . . . . .
Attributes Provided by SIP . . . . . . . .
UDFs Provided in the Standard Recorder Script .
Custom Data . . . . . . . . . . . . .
Conditional Custom Data Fields . . . . . .
. . . .
Mapping .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
118
119
120
121
122
123
124
125
126
127
Ports Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
High Availability IP Recording Systems . .

TopLayer IDS Device . . . . . . . . .
Link Protector . . . . . . . . . . .
IP Recorder Filtering . . . . . . . . .
Redundant Network Feeds . . . . . . .
TopLayer IDS Load Balancing Algorithms . .
Round Robin. . . . . . . . . . . . . . . .
Weighted Round Robin . . . . . . . . . . .
Source-Destination . . . . . . . . . . . .
Recording Styles. . . . . . . . . . .
Gateway Recording . . . . . . . . . . . .
Extension Recording . . . . . . . . . . . .
IP Topology Examples . . . . . . . . .
Single Recorder Cluster . . . . . . . . . .
Remote Call Manager . . . . . . . . . . .
10,000+ Phones Gateway Solution . . . . .
High Availability Design . . . . . . . . . .
Wiring for IP Environments . . . . . . .
IP Recorder Protocols . . . . . . . . . . .
Recording Scenario Requirements. . . . . .
Traffic Mirroring Technologies . . . . . . . .
Common Challenges in Gateway Recording .
Enterprise Security . . . . . . . . . .
Recording System Overview . . . .
Recording System Security Features . .
RSA Key Management . . . . . . .
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . .
. .
. .
. .
. .
.
.
.
.
.
. .
. .
. .
.
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
. .
. .
. .
.
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
. .
. .
. .
.
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
. .
. .
. .
.
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
. .
. . .
. .
. .
. .
.
.
.
.
. . .
. .
. .
. .
.
.
.
.
. . .
. .
. .
. .
.
.
.
.
. . .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
. .
. .
. .
.
. .
. .
.
. .
. .
. .
. .
.
. .
. .
. .
. .
. . . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . 133
. . 134
. . 138
. . 141
. . 141
. . 142
. . . 143
. . . 143
. . . 144
. . 146
. . . 146
. . . 147
. . 149
. . . 150
. . . 152
. . . 154
. . . 156
. . 158
. . . 158
. . . 158
. . . 159
. . . 161
. . .
. .
. .
. .
.
.
.
.
165
166
168
169

Contents
How Do I......?. . . . . . . . . . . . . . .
Recording with the IS . . . . . . . . . .
Performing Common Recorder Tasks . . .
Data Sources Quick Reference . . . . . .
Glossary
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 171
. 171
. 175
. 182
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Contents

About
This
Guide
The System Infrastructure Guide describes the hardware and software infrastructure
of the Recorder. It is designed to provide a technical understanding of major system
components and how they work together to record contacts. This chapter provides
details about the guides audience, a summary of each chapter, and where to find
additional resources and assistance.
This introductory section to the guide describes the following topics:
z
Intended Audience for This Guide, page 10
Related Documents, page 10
Summary of Information in This Guide, page 11
Conventions Used in This Guide, page 12
If You Need Help, page 14
Contacting Technical Support, page 15
Intended Audience for This Guide
Intended Audience for This Guide

This guide is designed to be used by:
z
Company and Business Partner professional services staff responsible for planning
and setting up systems.
Customers IT staff responsible for system maintenance.
Related Documents
The following documents are referenced in this document
z
System Administration Guide
Enterprise Manager Administration Guide
Enterprise Security Administration Guide
The following documents are related to this document:

z
Recorder Installation Guide
Integration Service Guide
Viewer User Guides
The following documents are referenced if system security is enabled in the recording
system:
z
RSA Key Manager Server 2.0 Administration Guide
RSA Key Manager Installation Guide.

10
Summary of Information in This Guide
Summary of Information in This Guide

Information in this guide is summarized as follows:
Chapter 1
Recorder Overview, page 17
This chapter provides an overview of the Recorder and the

Workforce Optimization Suite.
Chapter 2
Recorder Infrastructure on
page 25
This chapter describes the Recorder environment, common

recording methods, deployment scenarios, and supported
hardware and software.
Chapter 3
Recording and Administration,
page 51
This chapter explains the process by which calls are

recorded, and the system administration tools that are
available for the Recorder.
Chapter 4
Recorder Functionality, page 69
This chapter provides an overview of the Recorders

functionality from an architectural perspective.
Chapter 5
Recording with DMS, page 99
This chapter provides an overview of Ciscos call recording

functionality as related to Duplicate Media Streaming (DMS)
Chapter 6
Passive Recording with Avaya,
page 111
This chapter provides an overview of passive recording

using Avaya hardware and Avaya protocols.
Chapter 7
User Defined Fields, page 117
This chapter explains associated and non-associated call

data, and how it relates to user defined fields.
Appendix A
High Availability IP Recording
Systems, page 133
This appendix provides system designers with the

information they need to build high availability IP recording
systems.
Appendix B
Enterprise Security, page 165
This appendix provides an overivew of security features in

the Recording system.
Appendix C
Ports Usage, page 129
This appendix lists default TCP server port usage for the
Recording systems.
Appendix D
How Do I......?, page 171
This appendix provides answers to common questions you

may have on your Recording System.

11
Conventions Used in This Guide

The following two tables describe some of the conventions that are used in this
document:
z
The Standard Conventions table highlights conventions used to describe user

interaction, as well as special notations
The Information Icons table describes the icons used to highlight information of
special interest to the user
Standard Conventions
Area
Description
Menu Items
Menu items are highlighted in bold as in the following example:

From the menu, choose File > Preferences > Options.
Document
Names
Other documents are referred to using italics. For example:
Buttons,
Functions, and
Dialog Box and
Window Names
Specific button or function names are highlighted in bold. The

following example shows how a button and dialog name are
referred to in the documentation:
User Variables
When the user is expected to type a value, the name of the

variable to be replaced is surrounded by < > . The following are
examples:
Refer to the Quality Monitoring 7.8 Installation Guide for more

information.
Click OK, and then choose the Restore Database dialog box.
<Your ER Server Name>

The notation <Your ER Server Name> refers to the name of
your Enterprise Reporting server.
When you see this notation, replace it with the actual name of
your Enterprise Reporting server.

12
Information Icons
Icon Type
Function
Note
Important details that we want to make sure that you do not

overlook.
Tip
Helpful hints that can improve the efficiency or effectiveness of

your work.
Caution
Advice that can help you avoid undesirable results.
Warning
Situations that can result in:

z
z
z
Harm to software
Loss of data
An interruption in service

13
If You Need Help
If You Need Help

Our goal at Verint Systems is to provide you with the best products backed by a high
quality support network with a variety of resource options. These include:
z
Verint Systems website and Customer Interaction Center (CIC)
Telephone
E-mail
Direct Internet FTP
Other support and training alternatives
Before You Contact Technical Support

Help from Technical Support is as near as your keyboard or telephone. However, before
you contact us, read this section carefully. We can provide faster and better service if
you have certain information available when you contact us.
You can solve many problems quickly with the information in the online Help system or
in this manual. When running the product, you can select the Help button in the
upper-right portion of the window to get help for the active window or dialog box.
If you are unable to solve a problem by using the online Help or this manual, and you
need help from Technical Support, use the guidelines in the following checklist before
you contact us:
1
Write down the problem and details that may help us solve the problem. If you can
consistently reproduce the problem, list the steps to reproduce it.
Have at least the following information available when you contact Technical
Support.
z
Your name and customer site number, and identify yourself as a customer, Verint
Systems partner, or Verint Systems employee. Customer-initiated CIC contact is
restricted to customers that are one of the designated support contacts on your
companys service level agreement.
Product name and version number.
Server and client operating systems and service pack version numbers
Supporting files and screenshots (if available)
ACD type and reporting package (for ACD-related issues)
The wording of any error messages from the product and/or operating system
Has this problem occurred previously? If it is new, did you change your system
configuration recently?

14
Contacting Technical Support

Once you have determined that you need technical support, and you have gathered as
much information as you can based on the checklist, the following provides a list of the
various support options and alternatives:
Verint Witness Actionable Solutions Website and the Customer

Interaction Center (CIC)
This facility allows users worldwide fast access to product information, marketing and
sales information, information about the company, technical documentation, support
case management, and support solutions information.
You can access the VerintWitness Actionable Solutions Customer Interaction Center
(CIC) support site at www.witness.com/support, or through www.witness.com by
clicking the Support Login link from the Home page.
Once you have successfully logged on to the CIC, use the navigation tree on the right
to access available user manuals, troubleshooting guides, FAQs, and more.
For help using the site, refer to the CIC Support Website Navigation Guide. To access
this document, click the link at the right on the CIC Home page. The guide is a PDF file
that you can save or print locally for future reference.
Telephone
Witness Systems' Customer Interaction Center (CIC) provides the self-service tools and
information you need to get the most out of your investment.
Americas:
+1 800 4 WITNESS (USA toll-free)
+1 770 754 1870
Europe/Middle East/Africa:
+ (0) 845 843 7333
Hong Kong/Asia Pacific:
+852 8103 0104
Australia:
1 800 600 806
New Zealand:
+61 2 8223 9493
Japan:
+81 (0)3 5919 1875
For geographic locations and hours of operation, refer to www.witness.com\support\
and click on Contact Centers.

15
Email
If you are a new customer and need a logon ID and password, you can e-mail
support@witness.com to obtain your new logon information.
Direct internet FTP

This facility greatly speeds up transfer of new and upgraded software to all Witness
Systems customers. Contact us for more information about access to Direct Internet
FTP services.
Other support and training alternatives

In addition to documentation, online Help, and support services, Witness Systems also
offers both classroom-based and online learning alternatives to suit your specific
needs. Contact us for more information about other support and training alternatives.

16
Chapter
Recorder Overview
The Recorder represents a new generation of contact recording focused on
improving processes for contact recording. By using a software-based Recorder
architecture housed in a standard PC using standard PC components, the
Recorder offers cost-saving opportunities while leveraging existing
infrastructure. This is summarized in the following sections:
z
Recorder-at-a-Glance, page 18
Recorder Management, page 20
Recorder Features and Benefits, page 23
Enterprise Manager Features and Benefits, page 24
Chapter 1: Recorder Overview
Recorder-at-a-Glance
The Recorder consists of software components in a standard PC that interfaces with
telephony or data network components. The Recorders primary purpose is to record
calls or screens continuously or according to business rules, using either TDM (Time
Division Multiplexing) or IP (Internet Protocol to record VoIP calls). Combined with the
ease of use and management of a portal-style interface, the Recorder allows
centralized control of all recording activities.
The Recorder can be installed as either a TDM Recorder or an IP Recorder. Thereafter,
each Recorder type uses the same industry-standard databases (MSDE, SQL or
Oracle), the same industry-standard archive media (such as DVDs or tapes), and
similar architectures. For organizations with more than one Recorder, Enterprise
Manager can be used to manage multiple Recorders as one.
The Recorder system infrastructure for TDM and IP recording consists of three general
sections: Applications, Recording/Database, and Telephony, as shown in the following
illustration:
Recording System Infrastructure Hierarchy

APPLICATIONS
Application
Server
RECORDING
AND
DATABASE
TELEPHONY
Database
Server
APPLICATIONS:
Recorder Manager
Enterprise Manager
Search and Replay
Recorder(s)
Station-side, Trunk-side, or IP Tapping
Calls and Screens
Unify/
Integration
Service
CTI
Server
PBX/
Softswitch
Impact 360 Recorder System Infrastructure Guide

18
Some OEM partners may already have proprietary IP tapping/recording

technologies.
The Telephony/Network infrastructure can be expanded into Data Source, Integration
Framework, and the Telephone/Network components that carry out the recordings, as
shown in the following illustration:
Telephony/Network Infrastructure Overview

DATA
SOURCE
Application
CTI
Server
LAN
ACD/
PBX
INTEGRATION
FRAMEWORK
Unify
Recorder
Controller
Integration
Service
TELEPHONY/
NETWORK
Station-side, Trunk-side, or IP Tapping
Recorder
PBX/
Softswitch
The Data Source identifies the source of the call or screen to be recorded. The Data
Source can be either the ACD/PBX (phone) switch, the LAN, Trader, or Dialer switches.
Integration Framework refers to the Integration Service used, which can be either
CTI-based (Integration Service for integration with different switch vendors), Unify, or
Recorder Controlled. CTI Adapters are available for a wide range of mainstream
switches.
At the Telephoney/Network level is the Recorder, the switch, and workstations and
extensions. These components are contained in the network, which can also be used as
a Data Source.
Recorder features are further described in Recorder Features and Benefits on page 23.

19
Recorder Management
Recorder Management
The Recorder is accessed and managed from any Internet Explorer 6 or later web
browser. The interface allows simplified access to control, manage, and monitor all
features in the call or screen recording process, including specific programs and add-on
components. Through a tabbed interface, users select specific areas to access features
and configurations.
Access depends on security privileges, which are assigned at an enterprise level when
using Enterprise Manager. Administration and management of the Recorder is
accomplished through the Recorder Manager and Enterprise Manager. Recorder
Manager is installed automatically on each Recorder PC, supporting up to 10
concurrent users. Enterprise Manager is typically installed centrally, such as at a head
office, supporting up to 120 concurrent users. Each Recorder Manager can be
associated to no more than one Enterprise Manager.
Using Recorder Manager

Recorder Manager is installed on all Voice Recorder, Screen Recorder, Analyzer, Archive,
and Integration Server PCs. This management tool controls all components, alarms,
and other activities on the installation. The Recorder Manager interface is dictated by
the role of the installation, which can be either TDM or IP Recorder, Screen Recorder,
Analyzer, Archive or Integration Server. Either one can be selected in the installation
wizard at installation time. Thereafter, only the relevant software components are
installed and only the relevant tabs display in Recorder Manager. The following is a
typical Recorder Manager interface:
Recorder Manager functionality is described in the System Administration Guide.

Recorder features are summarized in Recorder Features and Benefits on page 23.

20
Recorder Management
Using Enterprise Manager

Recorder Manager can also be accessed from, and controlled by, Enterprise Manager.
Enterprise Manager is an enterprise management tool normally located in a central
facility such as head office, which manages all Recorders in the organization as a
group, as well as managing enterprise-wide security, events and diagnostics.
EM
RM
RM
RM
Enterprise
Manager
RM
Recorders, each with

Recorder Manager installed
The Enterprise Manager allows enterprise administrators to connect to individual TDM

and IP Recorders, Integration Service or Unify servers, Search and Replay, IP
Analyzers, and Centralized Archive. Such connection allows the management and
monitoring of all Recorders in the organization.
Mixed Recorder types are supported. Organizations can have TDM Recorders in one
location, and IP Recorders in another or can have both types in the same location.
Other Recorder types such as Contactstore can collaborate with the new Recorder
system but are managed only with their own management tools. A typical view of
Enterprise Manager, showing selectable items in the left pane and the working area in
the right pane, is shown in the following example illustration:

21
Recorder Management
You can launch a Recorders Recorder Manager from Enterprise Manager, providing you
have the necessary security privileges. To do this, select the Recorder in the left pane,
and then click the Launch button in the right pane.
Search and Replay is an exception. It is not administered by Enterprise Manager but is
managed instead by its own management tool, launched separately. Search and Replay
shows in the installation tree for configuration purposes.
Enterprise Manager functionality is described in the Enterprise Manager Administration
Guide.

22
Recorder Features and Benefits
Recorder Features and Benefits

Recorder features and benefits include the following:
Feature/Benefit
Description
Distributability
The Recorder uses standard protocols that enable

deployment for call recording and screen
recording in a wide variety of environments and
compatibility with a wide variety of devices.
Extensibility
The Recorder can be deployed in dynamic

environments and supports industry-standard
Ai-Logix and Cybertech voice cards (for TDM
recording), standard network interface cards (for
IP recording), new technologies, and integration
with new encoding formats.
Reliability
If the network goes down, the Recorder can fall

back on tap-sense control (TDM environment) or
redundant devices (IP environment).
Scalability
Recording capabilities can be scaled to any

organization size by simply adding Recorder
servers, which is similar to adding a node to a
data network.
Security (optional)
The Recorder supports a number of security

features, including 256-bit encryption for static
and in transit data, configuration of user account
and password policies, including password length
and complexity, account locked policies.
Diagnostics
The Recording system is easy to support and the

flow of data between components is intuitive,
supported by extensive audit trails, resulting in
easier analysis and support for technical staff.

23

Enterprise Manager allows simplified system administration functions for the recording
system, and provides the following features and benefits:
Feature/Benefit
Description
Account
management
Simplifies the management of user accounts to a

single point of administration, thereby reducing
operational costs and errors.
Usability
Provides high visibility to all your installed

products.
Customizable
Allows integration with diverse data sources, such

as ACD/PBX switches and LANs, through the use
of integration adapters.
Simplified login
Allows a single source of managing multiple

Recorders through a single point of login. The
features and the ability to manage/control the
different parts of the Recorder are based on the
access rights granted to the logged in user.
Adherence to rules
Allows recording based on business rules

enforced by the Integration Service.
Alerting
Provides centralized alerting, auditing, and

notification delivery capability, including SNMP
support.
Ease of deployment
and use
Decreases IT support costs and reduces system

configuration errors resulting in increased
satisfaction and increased competitiveness in the
marketplace.

24
Chapter
Recorder Infrastructure
This chapter describes the main components of the Recorder environment. This
includes the different recording methods for which the Recorder can be used,
the various configurations in which the Recorder can be deployed, and the
hardware and software that the Recorder supports. Information is presented in
the following topics:
z
Recorder Environment, page 26
Deployment Scenarios, page 42
Network Topology and Traffic Routing, page 48
Supported Hardware and Software, page 50
Chapter 2: Recorder Infrastructure
Recorder Environment
The Recorder is designed to record continuously, and to serve a variety of purposes
that meet the diverse needs of customers. Recording is done by extracting voice data
and metadata from voice cards and CTI adapters, and then persisting the data in such
a way that it can be retrieved later.
The Recorder environment is composed of a number of components that interface
using HTTP and other protocols. The following diagram shows a typical TDM recording
configuration with its main components.
Station-Side Recording
PSTN
Centralized
Archive
Server
Search and
Replay
Server
PBX
Content
Server
Local
Archive
Archiver
CTI
Server
Recordings out (after retrieving from

call buffer/conversion
to .wav/.scn files)
Each recorded
contact has
corresponding
metadata
.wav/.scn files
Compressor
Database
Consolidator
Metadata out
(after retrieving
from call buffer)
Workflow
Manager
Metadata
files
Disk
Manager
Call Control
Server
Capture
Engine
Raw
Metadata
Tagged Metadata in (to capture engine)
Voice
Card
rit
Recordings in (to capture card)
te
le
De
Call Buffer
These main components are described in the following sections.
PSTN
Telephone calls that will be recorded originate from the public switched telephone
network (PSTN). Trunk lines carry those calls from the PSTN to an organizations

2005-2008 Verint Systems, Inc. Confidential and Proprietary Information of Verint Systems, Inc. All rights reserved, worldwide.
26
private branch exchange (PBX). Trunk lines can be Category 5 network or coaxial
cables.
PBX
The private branch exchange is the switch that communicates with the PSTN on one
side and an organization's telephony equipment on the other. Unlike the PSTN, the PBX
provides audit trails of all incoming calls, such as time the call started and stopped.
This is known as event data or metadata, which may or may not be used. If used, a
Contact Center Manager Server (CCMS) is normally involved as part of a chain of
hardware that allows the event data to be passed to, and interpreted by, recording
hardware.
CTI Server
The Computer Telephony Interface (CTI) server acts as a broker interface to the PBX.
The CTI server communicates with the many different models of PBX so that the
complicated and ever-changing task of programming a device to interface with the PBX
switch is eliminated. The CTI server extracts event data, and renders it acceptable to
the existing telephony hardware in an organization.
Agent Telephones
Agents use telephones to participate in the customer calls that are being recorded.
Each extension has a unique identifier, usually 4-digits. These calls originate from the
PBX, and are recorded by the capture engine.
Unify Server
Unify is a recording control engine that connects to the CTI server. Unify can be
replaced by Integration Service. For more information on Integration Service, see
Integration Service Server on page 28.
Unify uses a standard script that is customized for a specific telephony environment,
and does one or all of the following.
z
Acquires data directly from the PBX
Passes data to telephony middleware (i.e. the Recorder)
Allows interaction with other system components.
For call recording purposes, Unify (or Integration Service) receives data directly
relating to call events (for example, when the call started or stopped) from the PBX.
Unify (or Integration Service) uses these events along with programmed business rules
to determine if a call should be recorded. In addition to deciding if a call should be
recorded Unify (or Integration Service) also uses this data, along with data from other
sources such as a CRM system, to tag the calls with business information. It is this
business information that enables the identification of calls of interest from the many
calls that are recorded. Tags or metadata are then passed to the capture engine of the
Recorder for conversion to a machine-readable XML file.

27
Integration Service Server

The Integration Service can be used in place of Unify as an alternative method of CTI
integration. The Integration Service processes events from the server interfaces,
detects state or data changes, and passes them along to other subsystems. It can
capture CTI event streams to file for later playback and viewing, and holds agent state,
device state, call state, and data associated with all known devices and calls. In
addition, it provides a unified call model across all types of switches, media, and
back-office functions.
The Integration Service comprises the Integration Framework and the Recorder
Controller. The Integration Framework and Recorder Controller use business rules
configured in the Enterprise Manager to control recording and types of recording.
Configuration of adapters through the Recorder Manager enables the translation of
recorded events from third-party systems into key-value pairs that are then sent to the
Integration Framework component.

28
Recorder Server
The Recorder server consists of software components that capture call data and
propagate the metadata about the recordings to databases to allow search, retrieval
and viewing. Software components include the Capture Engine, Workflow Manager,
Archiver, Consolidator, Compressor, Content Server, Live State Engine, and Disk
Manager. These are shown in the following diagram and described in the sections
below.
Station-Side Recording
PSTN
Search and
Replay
Server
Enterprise
Archive
Server
PBX
Content
Server
Local
Archive
Archiver
600001000000007.wav
Voice Recordings out (after retrieving from
call buffer/conversion
to audio file)
CTI
Server
Call #7
Voice
.wav files
Compressor
Database
Consolidator
600001000000007.xml
Metadata out
(after retrieving
from call buffer)
Call Control
Server
Workflow
Manager
Metadata
files
Disk
Manager
Capture
Engine
Call #7
Raw Metadata
Mapped Metadata for call #7
Voice
Card
rit
Voice (audio) data for call #7
te
le
De
Capture Component
SN: 600001
Call Buffer
Content Server
The Content Server component is an HTTP-based Web Service that is used by both the
call replay and Archive applications to retrieve calls and metadata from the Recorder.
For example, the Search and Replay application, as described in Search and Replay on
page 33, interacts with the content server component to replay selected calls based on
the query criteria specified by the user. Similarly, the Centralized Archiving application
interacts with the content server component to extract selected calls from the Call
Buffer of one or more Recorders, and to copy those calls to the centralized archive
described in Centralized Archiving on page 34.

29
For IP recording there are other variations. For example, recording can be
done in G711 format and compressed to a single G726 recording. If calls are
being recorded in stereo the capture engine generates two .XML and two .WAV
files. Each set of .XML and .WAV files corresponds to a stereo channel.
Archiver
The Archiver component persists the audio and screen portion, as well as metadata
portion, of each recorded contact (the .WAV, .XML, and .SCN files) to the local or
centralized archive for long term storage or for disaster recovery. The archive can be a
DVD-RAM, DVD-RW, Iomega REV, or tape storage device. EMC Centera systems can
also be used, as in the following table:
Item
z
HP DAT72
DDS5 Tape
Drive - 36 GB
capacity
Sony AIT-3
Tape drives
Iomega REV
drive
Description
z
z
z
HP DAT72 tapes are supported. Use the device driver on the

installation CD that comes with the device or download at
the HP driver website (www.hp.com, clicking Support and
Drivers and searching for DAT72).
Each tape can hold 36 GB (without compression) or 72 GB
(with compression) of voice recording based on typical call
lengths.
Sony AIT tapes supported are AITI260S (OEM part number
SDX-700V/RB). Any drive used must support partitioning of
the tape. Note: AIT-4 and AIT-5 drives cannot be used as
they do not support tape partitioning.
High-capacity storage device consisting of a drive and
removable, exchangeable disks (effectively, removable hard
drives).
Each disk can hold 35 GB of uncompressed data.
Can be located externally (using USB or Firewire) or
internally (using SCSI , SATA, or ATAPI).

30
Item
Description
DVD-RAM, DVD
RW, +/-, 4.7 GB
z
z
EMC Centera
Remote
Storage
z
z
z
z
The Panasonic range of DVD devices are widely supported,

though others can be used. Panasonic models are:
- LF-D311,
- LFD521E or OEM equivalent
- SW-9571,
- LF-M621U or OEM equivalent SW-9572-CPN devices.
- DMR Series Recorder devices
It is recommended that you use only 4.7 GB cartridges, as
opposed to disks without cartridge.
Use the device driver on the installation CD that comes with
the device or download at the Panasonic driver website at
the following url:
http://panasonic.co.jp/psec/support/dvdram/lim/eoem/inde
x.html
Each side of the DVD media can hold approximately 550
hours of voice recording based on typical call lengths.
Scalable, high-volume, fault-tolerant remote storage device
supporting CAS, SAN, and NAS
Archive TAR bundles are written to Centera drives through
Centera API.
Files contain a fingerprint (metadata) for disaster recovery.
Internet: www.emc.com
Recorder Manager provides the user interface to manage the archive. It provides the
functionality to eject media, format tapes, print labels, verify media, and perform
sequential or parallel archiving.
A Recorder writes to the archive device each time there are 100MB of calls that have
finished recording. If it has not built up 100MB in one hour since the last time it has
written, then it writes what has been gathered so far. Therefore the Recorder writes
every 100MB or one hour, whichever comes first. It only writes calls after they have
finished recording. Lag time, therefore, is at most one hour behind real-time, assuming
there is room on the media to write.
Archive operates in one of two modes: sequential or parallel.
In sequential archiving, the archive component persists .WAV and .SCN files
one-after-another to the media until it is full then flows over to the next available
media. If two drives are available, when the first drive fills the second one
automatically receives files. At some point, a system administrator must insert other
media for sequential archiving to continue.
In parallel archiving, the archiver component persists .WAV and .SCN files to two
media at the same time, such as two tapes or two DVDs. The media types need not be
the same. Parallel archiving enables the storage of a copy of the local archive in an
off-site location for disaster recovery, for example.
Note: In parallel mode the media are independently managed archive streams and are
not copies of each other. The two drives work independently of each other. In most
cases, if they are archiving the same content, then the contents of each media will be
the same. However, they are not binary copies of each other, so you are not
guaranteed to have pairs of media that contain exactly the same information.
Therefore media devices may not contain the same calls.

31
For more information about using Recorder Manager to configure the local archive,
refer to the System Administration Guide.
For organizations that wish to centralize their contact storage or use alternate archive
systems that have a large volume of contacts, recordings can be stored on storage
devices in a central archive that is separate from the local archive. Centralized
archiving is described in Centralized Archiving on page 34.
Compressor
The compressor component compresses calls that are received in uncompressed G711
or G722 format, either from Cybertech voice cards (TDM) or from an IP stream.
Compressor compresses IP calls, which are recorded in stereo format, or calls that are
captured in a G711 format from the Cybertech voice cards. The compression of stereo
files results in a reduction from two .WAV and .XML files into one .WAV and two .XML
files, which take up less space when they are stored. The compression of G711 and
G722 format files also results in files that require less space for storage.
If compressor finds that the audio files are encrypted, the compressor component
decrypts the files using a decryption key before beginning compression.
Consolidator
The consolidator component, under the direction of the workflow manager, persists the
metadata portion of each recorded call (the .XML file) to the database. The
consolidator component invokes a stored procedure in the database such that the data
is disseminated into the call records.
Workflow Manager
The workflow manager manages the state of each call after it is recorded by the
capture engine. It does this by initiating different operations on recorded calls. When
the capture engine notifies the workflow manager that recording has stopped for a call,
the workflow manager, in turn, notifies three other software components to begin their
operations on the recorded call: the archiver, consolidator, and compressor
components.
Call Buffer and Disk Manager

The Call Buffer is the storage area in the Recorder servers hard disk where the capture
engine stores recorded contacts and metadata. Recorder Manager provides the user
interface to specify the location and size of the Call Buffer. For information on the
recommended Call Buffer sizes for small and large systems, refer to the Recorder
Installation Guide.

32
Recorder Manager is also used to specify a

capacity threshold in the Call Buffer. This threshold
indicates how much free space must always be
available in the Call Buffer to store recordings.
When this free space falls below the specified
threshold, the disk manager component deletes
recordings, beginning with the oldest, and notifies
the workflow manager that it has done so.
The Call Buffer threshold overrides the retention setting. That is, a retention period can
be entered so that all contacts are deleted after the specified period. If the Call Buffer
threshold is reached before the retention period, contacts are deleted according to the
threshold.
For more information about using Recorder Manager to configure the Call Buffer, refer
to the System Administration Guide.
Capture Engine
The capture engine records calls, screen images of agents' desktop PCs, and call
metadata. The capture engine interacts with the telephony interface card (the voice
card in TDM recording) or the NIC port (NIC card in IP recording) in the Recorder
server to record a call or screen images of agents' desktop PCs. The capture engine
starts recording a call in response to Integration Service or a command from Unify , or
a call control event within the feed that contains the audio, and then stores the call in
the Recorders Call Buffer.
Unify or Integration Service passes call metadata to the capture engine or the capture
engine extracts metadata from the call control protocol flowing between the PBX and
the agent telephones. In TDM recording, the call control protocol is the D-channel or
handset protocol. In IP recording, the call control protocol is SCCP, H.323, or SIP. The
capture engine stores the metadata in the Recorders Call Buffer along with the audio
and content. When the Recorder is finished recording a call or capturing screen images,
it notifies the workflow manager that recording is complete for the call.
After recording a call, the capture engine also converts the audio, content, and
metadata in the Call Buffer into files: .WAV files for the audio, .SCN files for screen
content, and .XML files for the metadata. Each file has the same or related name, but a
different file extension. This process, simplified for illustration purposes, is shown in
the diagram on page 29.
Search and Replay

The Search and Replay application is used to replay recorded contacts. By entering
queries into Search and Replay, a supervisor or other authorized person can obtain
details about a call or screen, such as the agent who took the call, and when the call
started and stopped.

33
Database
The database is where call metadata is stored by the consolidator component. The
metadata in the .XML file contains all the known details about the recorded call,
including:
z
Channel
Duration
Start and end time in ISO format, giving local time and offset from GMT
A link to any related recording (for example, the other side of a stereo recording)
User defined fields
Additional information if extended Unify scripts are used
(IP) Caller and called extension information
(IP) Call reference number
Centralized Archiving
Centralized Archiving, also known as Enterprise Archive and CAM, transfers contacts
from one or more Recorders to remote storage media. This allows calls to be retrieved
at a later stage after they have rolled off the Recorder's Call Buffer. Archive
Administration, a separate application, is used to configure campaigns, create a
schedule, and view audit events for the entire enterprise. The Recorder Manager on an
Centralized Archiving server is used to configure storage drives and monitor archive
performance. Centralized Archiving is typically used by organizations that have a high
volume of recorded calls. For more information, refer to the Centralized Archiving
Installation and Administration Guide. For details of supported media, refer to
Archiver on page 30.
A centralized archiving failsafe procedure is installed automatically on all Recorders, in
the form of a SQL Job. This job, scheduled to run automatically every day at midnight,
lists all non-archived records (that is, their inums) for the configured parameters. If
you don't have local archive or centralized archiving running, then you should disable
the job to prevent unnecessary processing.
To disable the SQL job, do this:
1
Open SQL Server Enterprise Manager/ SQL Server Management Studio
Navigate to SQL Server Agent->Jobs
Right click on EWareArchiveFailSafeNotification and select Disable.
Exit Server Enterprise Manager/ SQL Server Management Studio
For more information on installed SQL jobs, refer to the Recorder Installation Guide.
Live Monitoring via Observer

Supervisors can monitor calls that are in progress from their desktop PCs using the
Observer product. In addition to monitoring calls, supervisors can use Observer to view

34
call status information, such as all currently active calls, and the activity on a particular
phone extension. Observer is installed by default along with Recorder Manager.
Live Monitoring via Web Observer

Supervisors can monitor calls that are in progress from their telephone by selecting the
replay extension using the Web Observer product. In addition to monitoring calls,
supervisors can use Observer to view call status information, such as all currently
active calls, and the activity on a particular phone extension.
Screen Recording
Screen Recording records workstation screens, including mouse movements, from
agent workstations, defined in the LAN Screen Data Source in Enterprise Manager
Capturing screens can be done regardless of logged in agent, known as dynamic
workspaces. Here, network addresses (subnets) and subnet masks can be created
along with Workstations, allowing the recording of contacts by any available agent in
the Workstation Group. Because extensions in a workspace are not associated to
agents, they can be recorded without an agent ID to extension association. The
recorded screen captures can be played back from Search and Replay. For more
details, see Screen Capture Architecture on page 91.
Business Rules
This section applies specifically to the Integration Service and does not apply
to Unify controlled Recorders. If Unify is used, then Business Rules are
implemented in Unify scripting, described in separate Unify documentation.
Manage rules associated with recordings to control the recording of contacts (that is,
calls and screen recordings) in your organization, regarding the type of recording, who
records, when, and according to which criteria. This is also known as Selective
Recording.
Rules add flexibility to recording, making the recording process more effective and
closely tied to organization goals. For example, you can associate a rule that can
determine the schedule of recording and what action is to be taken during the
recording. With Enterprise Manager, you can easily create and edit all aspects of rules,
as described in the Integration Service Guide and the Enterprise Manager
Administration Guide.
Data Sources
Data Sources are third-party Systems, such as private branch exchanges (PBXs) and
CTI Middleware Servers, that generate agent state, device state, and data change
events. Unify, BDR, or the Recorder make business decisions on the interactions to

35
record based on the events supplied by the Integration Framework. They also provide
business views of interactions based on different logic.
Types of data sources include the following:
z
Phone or PBX Data Sources, which are used for voice recording
Dialer Data Sources, which are used for voice recording for a dialer
LAN Data Sources, which are used for screen capture
Trader Data Sources, which are used for voice recording in trading environments
Inline Compression
The inline compression feature compresses audio recordings directly in the capture
engine, as opposed to post-recording compression performed in the Compressor
component.

36
Common Recording Methods

Calls can be recorded by tapping into telephone lines at different points in the
telephone network. Two common methods of recording calls are trunk-side (TDM
recording) or gateway (IP recording) recording and station-side (TDM recording) or
extension-side (IP recording) recording. The Recorder can be used in environments
where either of these recording methods are used. This section describes these
recording methods in the following topics:
z
Trunk-Side TDM Recording, page 37
Gateway Recording (IP Recording), page 39
Station-Side TDM Recording, page 40
Extension-Side Recording (IP Recording), page 41
Recording with DMS, page 99
Trunk-Side TDM Recording

In TDM environments, trunk-side recording taps directly into a T1 or E1 line to record
all incoming calls at the demarcation point before going to a switch. Passive tap
trunk-side recording requires a physical connection directly between the demarcation
point and the switch system. The following diagram illustrates a typical passive tap
trunk-side configuration scenario within a Call Center environment.

37
Trunk Side Recording (TDM)

Call Control
Server
CTI
Server
Recorder
Server
Junction Box/
Y Splitter
LAN
PBX
PSTN
Agent
Workstations
Sysadmin/
Supervisor
Server
Punchdown
T1 Line
Block
Note: 1 junction box/Y Splitter
(the tap point) is required per T1 line.

38
Gateway Recording (IP Recording)

Gateway recording in IP environments can be compared to trunk-side recording in TDM
environments. Gateway recording is accomplished by SPANning the gateway and the
call control server. In Cisco environments, the call control server is Call Manager. To
record conference calls, any and all conference bridge resources/participants must be
SPANned. At the same time, care must be taken to ensure that SPANning the
conference bridge resources does not take the IP Recorder over the maximum number
of concurrent channels for which it is configured. A possible limitation of this
configuration is that it may be difficult to record agent to agent calls, since these do not
usually go over the gateway.
The following diagram illustrates a typical gateway recording configuration.
Gateway Recording (IP)

Recorder
Server
Voice Gateway/
Conference Bridge
T1 Line
IS/Unify
Server
LAN
CTI
Server
Agent
Workstations
V
Sysadmin/
Supervisor
Server
PSTN
M
Call Manager
Spanning the gateway enables the Recorder to see the RTP traffic between the IP
device and the gateway. When a conference is established, the RTP traffic flows
between the gateway and the conference bridge, meaning that the IP Recorder cannot
associate it with any device. The conference bridge must be SPANned, therefore, to
enable the IP Recorder to access and record the RTP streams going to and from IP
devices.
The SCCP protocol only flows between the IP device and the call control server. The
gateway does not use the SCCP protocol, and therefore SPANning just the gateway is
not sufficient to allow recording, since it has no way to initiate the recording process.
This necessitates SPANning of the call control server to allow the IP Recorder to see all
SCCP packets for the entire system.

39
Using Gateway Recording Configurations

Before implementing a gateway recording configuration, system designers should
consider carefully whether a gateway recording solution is appropriate for their
network. This is because SPANning a large call control server cluster means that each
IP Recorder is forced to monitor and track every call in the cluster. Designers should
also consider the systems fail-over configuration, since very often upon failure of a
server/cluster the IP device will register with another call control server in the network.
If this is not SPANned, then recording will not be possible.
Another consideration for gateway recording is the ability to SPAN gateway channels.
Currently a single IP Recorder can support up to 400 concurrent recording channels.
With gateway recording a channel is more likely to be utilized. A gateway supporting
more than 400 channels via a single network port cannot be SPANned directly, so a
top-layer device would be required to load balance the traffic to multiple Recorders.
Station-Side TDM Recording

In TDM environments, station-side recording initiates recordings between the
switch/PBX and a phone. This is done by tapping into the line that connects the switch
to the telephone using a punch-down block. A cable is installed so that each extension
connects directly to a port on the voice card. The following diagram illustrates a typical
passive tap station-side configuration within a Call Center environment.
Station Side TDM Recording

Call Control
Server
CTI
Server
LAN
Sysadmin/
Supervisor
Server
Agent
Workstations
PSTN
PBX
T1 Line
Punchdown
Block
Recorder Server
RECORDING

40
Extension-Side Recording (IP Recording)

Extension-side recording in IP environments can be compared to station-side recording
in TDM environments. Extension-side recording is achieved by SPANning (that is,
copying) the traffic to and from an IP phone, typically using either port or VLAN
SPANning.
SPANning the IP device itself means that the IP Recorder will receive all RTP traffic to
and from that device, as well as SCCP protocol traffic between the device and the Cisco
Call Manager Server/Cluster. In this configuration, it is not necessary to explicitly SPAN
the Call Manager or any of the conference bridge resources.
The following diagram is an example of extension-side recording. In this configuration,
the access switches to which the IP phones connect are SPANned directly.
Extension Recording (IP)

IS/Unify
Server
CTI
Server
LAN
Sysadmin/
Supervisor
Server
Call Manager
T1 Line
PSTN
Agent
Workstations
V
Voice Gateway/
Conference Bridge
Recorder Server

41
Deployment Scenarios
The Recorder can be deployed in a variety of configurations, ranging from a small
single-box deployment to an enterprise-wide deployment across several sites with
uploading to a centralized database. The deployment scenarios outlined in this section
give you an idea of the types of deployments in which the Recorder can be used. These
examples are not intended to be exhaustive, but are intended to describe the way in
which the Recorder can be distributed and scaled.
This section describes the following types of deployment scenarios:
z
Single-node Deployment, page 42
Multi-node Deployment, page 44
Enterprise Deployment, page 45
Call Control Forwarding and Intelligent Call Control Distribution (IP Recording
Only), page 46
The deployment diagrams in this section illustrate the hardware nodes used for a
particular deployment, the software components installed on those nodes, and the
communication protocols used between the software components.
Single-node Deployment
The deployment of the Recorder on a single node is targeted at small-size customers
who have few channels to record, and where relatively little processing power is
required. If CTI information is not required by the customer, there is no need to deploy
Unify. The Recorder can function on its own using only tap-sense to start/stop
recording and to provide metadata.
This type of deployment can also be used for customers who require a more
sophisticated CTI or Unify integration, but have a small enough load on the system that
a single node will suffice. Enterprise Manager may also be installed in this scenario.

42
Single Node Deployment
Search and
Replay
Recorder
Manager
SQL/Oracle
or MSDE DB
Integration
Service
CTI
Adapter

43
Multi-node Deployment
When an environment has more channels than a single Recorder node can handle, the
Recorder Subsystem can scale Recorder components horizontally across several
hardware nodes. As a customer organization grows, it can simply purchase another
Recorder node and set of software licenses to accommodate its growth. Enterprise
Manager would also be installed on a separate server to manage all Recorders and
Centralized Archiving, if installed. The following diagram is a typical example of a
multi-node Recorder deployment.
Multi-Node Deployment Scenario

EM Server
TMD Recorder
IP Recorder
Centralized Archiving
Viewer
Enterprise
Manager
Integration
Service
CTI
Adapter
Viewer/Database
Recorder
Manager
Database
Server
Recorder
Manager
Recorder
Manager

44
Enterprise Deployment
Many telephony environments have branch or satellite offices which all report to a
single main office or headquarters. Often each branch office is independent and wants
to optimize performance at its local level, while the main office also wants to optimize
performance at the enterprise level.
This type of environment calls for an enterprise-style deployment, as shown in the
following diagram.
Enterprise Installation: Multi-site setup with Enterprise Database

Branch B: IP Recorders
Branch A: TDM Recorders

CTI
Server
Recorder(s) B
Recorder(s) A
Load Balancer/IDS
L
Viewer/
Central
Database/
EM
Server
Main Office
E
G
E
N
D
Database
V
Voice Switch
Viewer
Unify/Integration
Server

45
Call Control Forwarding and Intelligent Call Control

Distribution (IP Recording Only)
In IP recording environments, the Analyzer enables the following types of
deployments:
z
Call Control Forwarding: enables the forwarding of call control packets across a
TCP/IP connection in situations where the point of interception is in a remote
location relative to the IP Recorders, and where the Recorders cannot be supplied
with a Switch Port Analyzer (SPAN) of the call control packets.
Intelligent Call Control Distribution: enables the forwarding of only call control
packets by the Analyzer to IP Recorders configured to be aware of associated calls.
This can reduce the call state tracking of Recorders in deployments with large
numbers of handsets.
The following sections describe these deployments in more detail.
Call Control Forwarding

In the following diagram, the recorder at Site A cannot receive a SPAN of the Call
Manager on Site B due to the lack of layer 2 network connectivity. By configuring the
Analyzer at Site B to receive a SPAN of the Call Manager, you can enable the forwarding
of call control packets and control commands to the recorder at Site A.
IP
Analyzer
SITE B
IP
IP
Viewer/
Database/
Integration
Server
IP
Call Manager
V
PSTN
IP
Call Control
Forwarding
LEGEND:
IP
SITE A
V
Voice Gateway
Voice Switch
Recorder

46
In this deployment, Recorder Node 1 on Site B receives a SPAN of one of the gateways
and the Call Manager, it interprets the call control protocol directly, and then it records
calls leaving using its gateway.
Recorder Node 3 on Site A receives a SPAN of one of the gateways, but does not
directly receive the call control protocol. Instead, it receives forwarded call control
commands from the Analyzer.
Intelligent Call Control Distribution

In the following diagram, the Recorder nodes receive only the Realtime Transport
Protocol (RTP) traffic for the gateways that they are configured to record.
IP
Analyzer
SITE B
IP
Search&Replay/
Database/
10.10.2.100
IS/Unify
Server
IP
IP
M
Call Manager
V 10.10.2.101
PSTN
10.10.1.100
IP
Intelligent Call
Control Distribution
LEGEND:
Voice Gateway
IP
SITE A
V
Voice Switch
Recorder
Load Balancer/
IDS Device
The Analyzer on Site B receives the call control protocol of the Call Manager, then
distributes call control commands to the recorder nodes based on the following
configuration:
10.10.1.100 >> Recorder Node 5
10.10.2.100 >> Recorder Node 4
10.10.2.101 >> Recorder Node 1, Recorder Node 2, Recorder Node 3
Recorder Node 5 only sees call control commands from the Analyzer for calls for which
it sees RTP traffic. This is because the Analyzer knows the IP address of the gateway
that Recorder Node 5 is watching, and therefore only sends call commands for calls
where 10.10.1.100 is one of the end points.

47
Network Topology and Traffic Routing
Recorder Node 4 only sees call control commands from the Analyzer for calls where
10.10.2.100 is one of the endpoints.
Recorder Nodes 1, 2, and 3 are configured as a cluster of recorder nodes behind a
TopLayer IDS device. The IDS device is running a weighted round robin load-balancing
algorithm of the RTP traffic. It is impossible, therefore, to predict which recorder node
within the cluster will see the RTP traffic for a particular call. The Analyzer distributes
all call control commands where 10.10.2.101 is an endpoint to all recorder nodes
within the cluster.
Network Topology and Traffic Routing

Installing a recording environment within a VoIP network requires careful planning. To
route traffic to the Recorders the setup must be examined to ensure that the routed
traffic enables the system to meet its recording requirements. The best location for
physical installation of the Recorder must be identified, based on requirements.
Topology including where the Recorder is physically installed is affected by the
type of recording: station-side/extension-side or trunk-side/gateway recording. For
example, if the recording system takes a port SPAN of the gateway, it will only record
calls going in and out of the Call Center, not the internal calls within the Call Center. If
the recording system takes a VLAN SPAN at the access level switch of the physical
phone devices, then it will record all calls (incoming, outgoing, and internal) to those
phones.
It must be known how the following types of network traffic are routed to the Recorder
from the VoIP network:
z
Call Control Packets: It is possible to route call control traffic to the Recorder
using technology such as port SPAN, VLAN SPAN, remote SPAN, and VACL. In
addition to these more standard routing techniques, other deploy devices can
assist in routing, such as GRE Tunneling, or the Analyzer for IP Recorders. The
control protocol traffic may be intercepted by directly SPANning the traffic to the
physical phones or by SPANning the traffic to the soft switch itself.
RTP Audio Packets: It is possible to route RTP traffic to the Recorder such that
no Recorder sees more than its handling capability at any moment in time. As with
call control packets, port SPAN, VLAN SPAN, remote SPAN and VACL technologies
can be used to achieve this. In addition to these more standard network routing
techniques, other deployment devices can be used to assist in routing, such as IDS
devices for SPAN port multiplexing and load balancing.

48
Time Synchronization
Time Synchronization
Time synchronization is not mandatory*, but if multiple Recorders are installed or are
added, synchronization ensures that call time details are consistent for all recorders
across the network. Without synchronization, for example, it may appear that calls
arrived in a different order than they were actually recorded.
It is recommended that a time synchronization service be used in networked
environments. For organizations using Windows 2003, the Network Time Protocol time
synchronization utility that is bundled with the operating system is recommended, as it
provides accuracy to within tens of milliseconds. For all other Operating Systems, the
third-party Tardis time synchronization utility is recommended, as it has proven to
provide acceptable time synchronization.
Organizations are free to use their own time synchronization tool as this will not affect
recording operations. Administrators in these organizations should be aware however
that being out even a second or two can lead to problems with data being out of
synchronization and playback timing problems. As a guideline, network times should
be synchronized to within 0.5 seconds.
The Viewer server may be used as a time synchronization server. This is possible since
Viewer is centrally located and has no other real-time tasks.
*Time synchronization is mandatory in ContactStore Plus environments as playback
from Balance is not possible without synchronization.

49
Supported Hardware and Software

The Recorder uses a variety of hardware and software components to integrate voice
and data monitoring, and to interface with databases, archive mechanisms, and CTI
and other servers. The following sections describe the hardware and software
components supported by the Recorder, and provide guidance for installing those
components.
Physical Connectivity Options

Data application servers may be installed on Ethernet (100/1000 Mb/s) server
backbones. The server operating system must be configured with the network's default
router IP address, and must be able to reach all agent workstations and playback users
by way of ping.
Installers have flexibility on where to deploy the Recorder server in the enterprise
environment. However, they should bear in mind that data capture response times will
fluctuate in proportion to the average packet delivery times provided by the network
segments traveled. WAN data capture is fully supported, but may result in reduced
quality of playback for users.
In all circumstances, installers should try to physically co-locate the Recorder server
with replay users.
Operating System
The Recorder installs on Windows 2003 Server (Enterprise and Standard) using
Windows server software. Windows 2000 Server with service pack 4 can be used for
the attributes (eWare) database. By default, the server is installed as a stand-alone
server in the NT domain model. It is recommend that the Recorder server is not
configured as a backup or Primary Domain Controller. The server should not be
configured to participate in any NT replication scheme.
The Recorder can also be used in a Windows XP Professional Service Pack 2
environment for small Recorders (120 channels or less) and Enterprise Manager (EM)
only.
Recorder application servers allow several different hostname-to-IP address resolution
methods for simple deployment in heterogeneous LAN environments, including the
following: DNS/WINS/HOSTS/LMHOSTS.
The Recorder server software does not directly interface with TCP/IP, relying on the
server's operating system to handle all IP resolution.
CTI Servers
It is strongly recommended that CTI server software be installed on a separate server
from the Recorder application server. The Recorder uses a separate server so that
other servers can access the data without degrading the performance of the Recorder.

50
Voice Cards
The following table lists the voice cards supported by the Recorder for different
recording methods, such as station-side or trunk-side. The supported voice data format
is G726.
For detailed information about voice card installation and wiring, refer to the Recorder
Installation Guide.
Type
Ai-Logix Model*
Description
Analog
Station Side
LD409, LD409-eh
LD809, LD809-eh
LD1609,
LD1609-eh
LD2409,
LD2409-eh
Newer versions of Ai-Logix's analog station-side

recording voice cards capable of recording 4, 8, 16,
and 24 ports respectively.
PT409,
PT809,
PT1609
Voice cards capable of recording 4, 8, and 16 ports

respectively. These cards are currently supported by
ContactStore Express and are supported for
backwards-compatibility with those customers. They
do not generate a loss of signal (LOS) alarm.
NGX800
NGX800-eh
Voice card that records 8x2-wire digital stations

(4x4-wire). It is triggered by D-channel events. It
can have up to two MX80 daughterboards attached.
NGX1600
NGX1600-eh

(8x4-wire). It is triggered by D-channel events. It
can have one MX80 daugtherboard attached.
NGX2400
NGX2400-eh

(12x4-wire) triggered by D-channel events.
MX80
Daughterboard that can be installed on NGX800 and

NGX1600 voice cards.
Digital and
Analog
DSC-16-PCI
DSC-xP-PCI
(Cybertech)
Voice cards from Cybertech that record 16 digital

channels (DSC-16) and modular tapping (DSC-xP),
which allows inserting analog and digital detection
devices (that is daughterboards) into a blank
Cybertech motherboard. These show as 16-PCI and
P-PCI.
Digital and
Analog
DSC-16-PCI
DSC-xP-PCI
(Cybertech)
Voice cards from Cybertech that record 16 digital

channels (DSC-16) and modular tapping (DSC-xP),
which allows inserting analog and digital detection
devices (that is daughterboards) into a blank
Cybertech motherboard. These show as 16-PCI and
P-PCI.
Digital
Station Side

51
Type
Ai-Logix Model*
Description
Digital
Trunk Side
DP3209,
DP3209-eh
DP6409,
DP6409-eh
Passive-tap recording voice cards capable of recording

30 (DP3209) and 60 (DP6409) channels. They are
software switchable between E1 and T1 trunk spans.
PCM3209
PCM3209-eh
PCM6409
PCM6409-eh
Passive-tap recording voice cards capable of recording

32 (PCM3209) and 64 (PCM6409) channels. These
cards use the PCM32 protocol, which is similar to E1 in
that they are cabled over twisted pair cable and
terminated with RJ-45 connectors.
DT3209TE
DT3209TE-eh
DT6409TE
DT6409TE-eh
Active and passive-tap recording voice cards capable

of recording 24 or 30 channels (for T1 and E1
respectively on the DT3209TE model) and 48 or 60
channels (for T1 and E1 respectively on the
DT6400TE model). These cards are cabled over
twisted pair cable and terminated with RJ-45
connectors.
See also: http://www.ai-logix.com and http://www.parrot-dsc.com (Cybertech).

Notes: 1. NGX 800 appears in Windows Device Manager regardless of NGX card model.
2. -eh refers to PCI express card versions.
*Except where otherwise noted.
Archiving Media
Recorded contacts for local or central archive that need to be archived can be stored on
DVD-RAM, DVD-RW, Iomega REV drives, or tape storage devices. These are described
in Archiver on page 30. Labels for the media may be printed by the label printer
described in Label printing below.
Label Printing
Standard address labels are suitable for labelling the cartridge held disks, and the
labels can be produced automatically from one of the label printers supported. The
Seiko Smart Label Printer 100 is currently supported. Other printers, such as CoStar
and Brother, with Windows 2000/2003 compatible drivers also can be used.
No manual steps beyond plugging in the printer and installing the vendor-provided
drivers is required to start printing labels. Printing is performed as each media is
completed and ejected.
Media Limitations
The Recorder has the following media limitations:
z
Double-sided media are treated as two single-sided media with each side being
given a unique identifier. This is because it is difficult to be 100 percent confident
that a disk inserted is actually the other side of the disk requested.
Manual formatting of media is required (Panasonic does not provide API driven
format).

52
Chapter
Recording and
Administration
This chapter describes how voice, screen, and associated call data are captured,
the different ways in which contacts are initiated, and what activities the
Recorder performs before it begins capturing. This chapter also describes the
administration tools that are available to control the functionality of the
Recorder. This information is presented in the following topics:
z
Recording Process, page 54
Using non-CTI Recording Methods, page 61
System Administration, page 66
Chapter 3: Recording and Administration
Recording Process
Recording Process
Recording calls for playback is the primary function of the Recorder. Before recording
can begin, the capture engine of the Recorder verifies that a valid license exists, and
then checks for voice or NIC cards. Once these prerequisite activities are completed,
the capture engine proceeds to capture and record voice data and metadata. When
recording is complete, the capture engine persists the recorded data to the Recorders
Call Buffer. These tasks are described in the following sections:
z
Before Recording, page 54
Capturing and Recording Voice and Screen Data, page 55
Capturing and Recording Associated Call Data, page 56
Recording Calls With the Call Control Engine, page 56
Recording Calls Without the Call Control Engine, page 57
TDM Control Fallback, page 57
Using VOX Detection in IP Recording, page 58
The IP Recorder supports several recording modes for any phone extension. Those
recording modes are described in IP Recording Modes on page 57.
Before Recording
Before recording can begin, the Recorder must detect voice or NIC cards, and validate
licensing. The following sections describe these recording prerequisites.
Auto-Detecting Voice or NIC Cards

The Recorder's capture component probes the system while initializing to detect the
existence of any voice or NIC cards. The capture component then compares the
detected card(s) with those that already exist in the configuration file. If any mismatch
is reported, such as new cards added or existing cards removed, moved, or replaced, a
new file is generated. This file contains details of detected mismatches, such as type of
card, serial number, number of channels, and PCI slot occupied. The capture engine
then recalculates logical to physical channel mappings and writes to a log file, sounding
an alarm if a card fails to initialize. A system administrator then needs to acknowledge
the alarm, and perform the required corrective actions.
Validating Licensing
The Recorder's capture component loads and decodes the license key during startup,
and then enforces channel licensing when requests to record calls are received. During
startup, the license key is read from the system's configuration file. The license key is
then decoded, and its authenticity verified. Upon verification, channel configurations
are loaded from the configuration file, and the number of configured channels are
compared to the actual number of channels licensed. Next, the call controller initiates
call recording by the capture engine. After checking that the requested channel to be

54
Recording Process
recorded is licensed, the capture engine starts recording the channel, generating an
audit log at the same time.
If one or more of the following license key conditions exists, the capture engine is not
initialized:
z
Missing
Tampered
Invalid or expired
Configuration mismatch
Channel not licensed
The Recorder supports the following license types:

z
Temporary: This is a 10-day trial license that licenses up to a maximum of 400

concurrent IP or TDM recordings. Contacts that are recorded during this time are
maintained when the license is upgraded to a full license.
Full: This is a license for a specified number of concurrent contacts that can be
recorded.
The licensing key includes options to enable or disable audio and screen channels
(Enable Audio and Enable Screen). The Number Of Channels field is a common field in
the license key for both audio and screen channels. It gives the total number of
concurrent licensed recordings for Audio if enabled (Enable Audio is selected) and the
total number of concurrent licensed recordings for Screen if enabled (Enable Screen) is
selected.
For more information about activating temporary or full licenses refer to the Recorder
Installation Guide or the System Administration Guide.
Capturing and Recording Voice and Screen Data

This section describes capturing the voice and screen data portion of a contact and
converting it into a .WAV file or a .SCN file for later retrieval and playback. The
non-voice data portion of a call, known as associated call data or metadata, is captured
separately in a .XML file, as described in Capturing and Recording Associated Call
Data on page 56.
Call recording is initiated by the capture engine in response to a request from the call
controller. The call controller can be either Unify/Integration Service or the Recorders
voice card (TDM recording) or NIC port (IP recording). If the call controller is
Unify/Integration Service, then the request to start recording is based on a CTI event
sent by the CTI server. If the call controller is the voice card or NIC port, the request to
start recording is based on a call control event within the data stream that contains the
audio or screen.
In TDM recording/ITS IP Recording, if Unify/Integration Service cannot initiate
recording because the CTI source is disconnected for some reason, recording is
initiated from the voice card as described in TDM Control Fallback on page 57.
When the call is finished, the call controller requests the capture engine to stop
recording. The capture engine terminates the recording operation, and confirms to the
call controller that recording has stopped. The end result is a named .WAV file and/or a
.SCN file in the Call Buffer. The file name for the audio or screen is correlated with the

55
Recording Process
file name for the call's metadata (.XML file) using a unique index number (inum), as
described in the next section.
Capturing and Recording Associated Call Data

Recording associated call data involves capturing the metadata portion of a call, such
as call start time and call end time, and converting this information into a .XML file for
later retrieval and playback. The voice and screen data portion of a call are captured
separately, as described in Capturing and Recording Voice and Screen Data on
page 55.
As with call recording, metadata recording is initiated and terminated by a request
from the call controller. If the call controller is Unify/Integration Service, it passes
metadata to the capture engine. If the call controller is the voice card (TDM recording)
or NIC port (IP recording), the capture engine extracts metadata from the call control
protocol flowing between the PBX and the agent telephones. In TDM recording, the call
control protocol is the D-channel in Trunk-side recording, or handset protocol
(D-channel from PBX) in Station-side recording. In IP recording, the call control
protocol is SCCP or SIP.
When the call controller issues the request to start and stop recording, it generates
static metadata tags, such as start and end time. During recording, a variety of
metadata can be recorded, including channel name, channel number, dialed digits, CLI
digits, DNIS, call ID, call direction, and user defined fields. In addition, the call
controller can append any other type of business data or user defined fields that are
relevant to the call. The metadata that is recorded depends on the recording and
business environment. For more information about user defined fields, refer to User
Defined Fields on page 117.
The end result of the metadata recording process is a named .XML file in the Call
Buffer. The file name for the metadata is correlated with the file name of the
audio/screen portion of the call by using the same unique index number (inum) that is
used for the .WAV/.SCN file.
Recording Calls With the Call Control Engine

When calls are recorded under the direction of Unify/Integration Service,
Unify/Integration Service monitors CTI events for configured extensions from the PBX.
Based on incoming CTI events, Unify/Integration Service decides to start or stop call
recording according to customer needs. The recording process is controlled by a Unify
script or Business Rules.
Unify or Integration Service initiates the capture of voice data as described in
Capturing and Recording Voice and Screen Data on page 55, and the capture of
metadata as described in Capturing and Recording Associated Call Data on page 56.
In TDM recording, when CTI event-initiated recording is not possible, Unify/Integration
Service or the voice card invokes control fallback mode to continue recording as
described in TDM Control Fallback on page 57.

56
Recording Process
Recording Calls Without the Call Control Engine

When calls are recorded under the direction of the voice card - (TDM recording) or NIC
port (IP recording), the interface card or NIC port monitors the call control protocol
flowing between the PBX and the agent telephones. The capture engine starts and
stops call recording in response to call control events that the interface card or NIC
port detects in the tapped telephone line. This method of recording is also called tap
sense recording.
The interface card or NIC port initiates the capture of voice data as described in
Capturing and Recording Voice and Screen Data on page 55, and the capture of
metadata as described in Capturing and Recording Associated Call Data on page 56.
TDM Control Fallback

Control fallback is the backup recording method in TDM recording when
Unify/Integration Service detects that the CTI source is disconnected or when the
capture engine detects that the connection between Unify/Integration Service and
itself is no longer functioning. Control fallback provides a fail-safe method for
continuous call recording.
When Unify/Integration Service detects that the CTI source is disconnected, it turns
call control over to the voice card, and recording is performed as described in
Recording Calls Without the Call Control Engine on page 57. When Unify/Integration
Service detects that the CTI source is reconnected, it discontinues fallback mode, and
recording continues as described in Recording Calls With the Call Control Engine on
page 56.
When the capture engine detects that the connection between Unify/Integration
Service and itself is no longer functioning, the capture engine invokes the voice card as
the call controller, and recording continues as described in Recording Calls Without the
Call Control Engine on page 57. When the capture engine detects that the connection
between itself and Unify/Integration Service is functioning, it discontinues fallback
mode, and recording continues as described in Recording Calls With the Call Control
Engine on page 56.
IP Recording Modes
The IP Recorder supports the following recording modes:
z
z
z
z
z
z
Do not Record: Nothing is recorded, and the extension cannot be monitored.

Live Monitor: No recordings are kept beyond the end of a call, but calls can be
monitored in real-time using the Observer product.
Record: All calls are recorded and retained.
ExecRecord: Selective recording of individual calls. The following section describes
this mode in detail.
Start at Business Rule: Recording begins depending on the Business Rule.
Duplicate Media Streaming (DMS): You can specify whether to ignore the network
card, record passively, or actively. For more information, see Recording with DMS,
page 99.

57
Recording Process
For the Default Recording modes, there are two options:

z
Record and
Do not Record
For individual extensions, there are five options:

z
Record
Do not Record
ExecRecord
Start at Business Rule
Live Monitor - this is not applicable if the Do not Record option is chosen.
For each NIC detected, there are three options:

z
Active (DMS)
Passive
Do not Record
Selective Recording via ExecRecord

In cases where only selected calls need to be recorded under end user control, the
Recorder supports executive record or ExecRecord mode. In this mode, a user
performs an action to record a call, such as pressing a Record button.
On extensions configured for this mode of recording, all call segments are recorded. If
a user wants to retain the recording, and the extension is in ExecRecord mode, the
user must press the appropriate record button to retain the recording. If the user does
not press the record button, the recording is automatically deleted as the call segment
ends.
This is a selective recording system in which only chosen call segments are recorded. A
call segment is the period from the start of conversation to either call end, call hold, or
call transfer from the specified device. If a call is broken into multiple segments, the
user needs to select ExecRecord for each segment they want to keep. If these
segments have the same call reference, then the segments can be presented as a
single call at replay time.
Call Manager systems can have a mixture of extensions, recording all calls of some
extensions and only selected calls on other extensions. This is possible because
individual extensions can be associated with the ExecRecord service.
Call Manager Express systems function slightly differently. Each phone cannot be
assigned individually to the ExecRecord service. The ExecRecord feature must be
configured on all extensions or on no extensions.
Using VOX Detection in IP Recording

VOX detection in IP recording prevents the recording of long periods of silence on
speaker channels. This significantly reduces the amount of storage space used by
ensuring that storage space is not wasted recording long periods of silence.

58
Recording Process
Understanding VOX IP Detection

Traditionally, call recording is controlled by using either CTI information (either active
or passively sniffed), or in TDM by sensing audio on the line (VOX Detection, as
decribed in Understanding VOX on page 61). VOX IP recording is a combination of the
above two methods for controlling the recording of a single call.
Here, CTI (SIP messaging for example) is used to initiate and terminate recording but
also VOX Detection within the call to prevent the recording of long periods of silence.
As a result this means that there may be multiple recordings for a single call, and the
sum total of the recording duration may not equal the total call duration, such as when
periods of silence have not been recorded.
The purpose of VOX detection is to prevent the recording of long periods of silence on
speaker calls such as 10+ hours of silence over night, and not to break long speaker
calls into smaller recordings. This concept is shown in the following diagram:
VOX Detection in the IP Call Recording Process
Time/Duration (Mins)
0
10
20
30
40
50
60
70
80
90
100
110
120
140
160
180
Call In Progress
Speech
Speech
Silence
Recording 1
Speech
Silence
Recording 2
Stop
Recording *
Start
Recording **
CTI Indicates
Start of Call
(e.g. SIP 200 OK
Response to an
INVITE)
* VOX Algorithm
Detects Silence
and Stops
Recording
Silence
Recording 3
Stop
Recording *
Start
Recording **
** VOX Algorithm
Detects Audio
and Starts a
new Recording
Stop
Recording *
CTI Indicates
End of Call
(e.g. SIP BYE)
The diagram shows a speaker call, lasting approximately 180 minutes, with the start
and end of the call indicated by CTI events. During the call there are 3 periods of audio
and 3 periods of silence. When the VOX algorithm detects the transition from audio to
silence it stops the recording, and correspondingly when it detects the transition from
silence to audio it starts a new recording. As a result the periods of speech are
recorded and the silence is not.
Some important points to note about the above example scenario:
z
z
z
The diagram does not take into account the fact that calls will be broken every 15
minutes or so by the receipt of a reINVITE message.
There are 3 separate recordings (i.e. they will not be stitched at replay time)
The start and end time of each recording (as stored in the XML and in the
database) will be the real start and end time of that individual recording, and not
the start and end time of the overall call.
The sum total duration of the 3 recordings do not add up the duration of the call.

59
Recording Process
The tagging information for each recording will inherit the tagging information
from the call at the point that the recording stops. So in the above example, if a
tag is received at time 10 then it will be tagged to all 3 recordings, but if another
tag is received at time 90 then it will only be associated with the 3rd recording.
Implementing and Configuring VOX IP Recording

The VOX Detection algorithm should only apply to Speaker Calls (as identified by the
X-CallType tag with a value of Intercom or PrivateWire), and not for normal calls.
The VOX detection algorithm is integrated into the capture engine to simplify future
integrations, including both CTI controlled and Recorder Controlled recordings.
The following settings for the VOX Detection algorithm are exposed through Recorder
Manager/Enterprise Manager. For more information, refer to Configuring NICs in the
Impact 360 Recorder System Administration Guide.
VOX Activity Sensitivity

This setting determines how sensitive the VOX algorithm is in determining whether a
sound should be considered to be audio or just low level background noise and
effectively reated as silence.
VOX Stop Trigger Duration

This setting controls how long a continuous period of silence must be before the VOX
algorithm stops the recording. Setting this value too low results in short pauses in a
call resulting in the call being stopped.
VOX Start Trigger Duration

This setting controls how long audio must be detected for before the VOX algorithm
starts recording. Setting this value too low means that occasional clicks and sounds in
the background noise could trigger recording. Setting the value too high means that
some audio may not be recorded after a period of silence.

60
Using non-CTI Recording Methods

VOX is a possible method for starting and stopping the recording of a telephone call.
Here, sound-waves from calls trigger the recording. You can enable VOX recording in
any TDM Recorder telephony interface card (voice card). VOX, however, is not
recommended, as there are better alternatives. The best alternative is a CTI-driven
event from a CTI server through Unify. Failing a CTI-driven configuration, the
D-channel, line-voltage, and CASS (i.e non-CTI) events are preferred before VOX. This
information is detailed in the following sections:
Understanding VOX, page 61
Difference between VOX and D-channel, line voltage, and CASS, page 63
CCE Control Option/Fallback Feature, page 64
Triggering a Recording, page 64
Understanding VOX
You can categorize how call-recording is initiated to better understand the role of VOX.
Call recording can be started and stopped by either CTI-driven events and
non-CTI-driven events. CTI-driven events are metadata information extracted from the
switch by the CTI server and passed to Unify. Unify converts the metadata information
into tags (also known as call attributes) that are used by the Recorders capture
engine. The two categories are presented in the following table:
CTI-driven events
The combination of a
CTI-server and a Unify
server is the most
desirable method for call
identification, because it
provides the greatest
amount of tagging
information. This
information is used to
identify the call and allow
search and replay using a
variety of criteria, such as
time or caller ID or caller
number.
Non-CTI-driven events
VOX
Non-VOX
VOX is the least

desirable option for call
identification as it
provides only two
criteria - start and stop
time - which does not
allow effective search
and replay.
D-channel
Line Voltage
CASS idle code.
It is also less desirable

because call volume can
vary and this can lead to
a single call being
captured in multiple call
segments.
These call identification options are

preferred before VOX but are not as
desirable as CTI-driven events.
D-channel is the data channel that is
included on T1/E1 ISDN lines and digital
extension taps. The D-channel can provide
limited associated call data that can be
used for call tagging, allowing at least
minimal call search and replay.
Line Voltage is the inherent electrical
current that exists in an analog telephone
line. Start and stop events can be detected
from the electrical impulses. Line voltage
is not available when tapping between the
telephone and the handset or headset.
CASS idle codes (or channel associated
signaling idle codes) provide start and stop
information.

61
When a Recorder detects that the TCP/IP socket connection to Unify has been broken
the Unify script sends a command to the Recorder to enable secondary mode. Then the
Recorder will go into fallback mode. For example if the CTI server or Unify server has
gone down, and no data is being received at the TCP/IP socket on the Recorder the
Unify script will enable either enable D-channel, Line Voltage, CASS idle codes, or VOXbased recording, if configured. If the VOX checkbox on the voice card is checked, VOX
is enabled. If not, the other methods are available.
When VOX is enabled and used as the secondary mode for starting and stopping
recording, the decision to start or stop recording is based on the audio signal on the
line. The VOX Enabled checkbox in Recorder Manager looks like the following:
Each line type Trunk, NGX (DET), or Analog has a VOX Turn On and a VOX Detect
Level control. VOX operates from the audio signal coming across the cards. The signal
has a VOX detect level between a threshold of 0 and -57 decibels. The VOX turn on
setting determines how long the voice on the line must be above the VOX detect
threshold to trigger the start of a recording.
The VOX run on determines the length of silence period that will trigger the stopping of
a recording. The value -57 is the most sensitive VOX level while 0 would require
infinitely loud noise to trigger a recording. For example, if a the VOX detect level is set
to -45 decibels a voice registers at -40 decibels for a period of at least 250ms then VOX
will send a start_record command to the capture engine. Similarly, if there is no voice
detected for a period of, say 5 seconds, the VOX Run On settings will send a
stop_record command. The two VOX controls on each voice card, allowing millisecond
(ms) adjustments, are shown in the following:
VOX Run On is another measurement, also in milliseconds, of how long recording will
continue with no sounds audible. VOX turn On is the amount of time in milliseconds
that sound must be detected for recording to begin.
The weakness of VOX is that beyond the settings, VOX cannot differentiate between
gaps in the conversation. VOX therefore stops recording at pauses. For example, if an
agent places his hand over the mouthpiece while VOX is enabled, the recording stops.
Even a voice that has a low tone can end a call if the sound is below the threshold, say
-50 decibels for more than 5 seconds. On the other hand, on-hold music provides
sound that keep VOX recording going.
The appeal of VOX recording in trading environments is great because the act of
trading calls typically lasts for only a few seconds as orders to bid on stock are placed
and then the caller hangs up. The VOX capabilities of the PCM 32 card are an example

62
of VOX recording as the preferred recording method. This is because in trading

environments, no CTI equipment is used because of the brevity of telephone calls.
Difference between VOX and D-channel, line voltage, and

CASS
The non-VOX recording methods (D-channel, line voltage, and CASS) are preferred to
VOX recording. The reason for this is that the signals provided by the line are more
reliable than VOX levels which can vary based on the parties in the conversation. In
some configurations more metadata can be extracted from the non-VOX methods,
resulting in better search and replay. You enable non-VOX recording by unchecking the
VOX Enabled checkbox (circled) in voice card property pages, as in the following
example of a NGX voice cards settings.
D-Channel
D-Channel, or data channel, recording refers to the 24th or 31st channel in a T1 or E1
line configured for ISDN. With D-Channel, there are effectively 23 and 29 channels
available for E1 and T1 respectively. Metadata from the 23 and 29 channels
(respectively) is received on the D-Channel. In the NGX environment, where
station-side TDM recording occurs, the digital signals decoded by the tap card provide
the digital signaling.
The D-Channel on ISDN trunks provides more metadata than VOX, such as Called
Number and Caller Number. It is the D-channel on digital extension taps that can
provide the message displayed on the telephone sets LCD screen in most cases.

63
Line Voltage
When a phone rings, 48 volts of electricity are transmitted across the telephone line
between the wall jack and the telephone set. When the phone goes off hook this
typically drops to between 6-8 volts. This is enough for the analog tap card to detect
the change and to issue Start on Tap and Stop on Tap instructions.
Neither digital nor analog line voltage occurs between the telephone set and the hand
set (that is, the "curly" cord that stretches from the telephone set and the hand set).
This means that if the phone is being tapped at this point, such as a Y-connector placed
at the telephone set, line voltage cannot be used as there is no electrical impulse to
start and stop the tap.
CASS Idle Codes

Recording based on CASS (Channel Associated Signaling) Idle codes depend upon the
type of card and its configuration. For one thing, this type of fall-back recording can be
used only in Non-ISDN environments with T1 and E1 lines. Here, one of the 8 bits of
data packet information is used to "piggy-back" on the other bits. An idle code of 4
binary digits (e.g. 0001) can be configured on an idle-code slider bar. The idle code can
be set to any combination of the 4 bits, such as 0000-0001-0000-0010, so that when
this formation of digits are detected, Start on Tap and Stop on Tap events occur so only
VOX detection is available. Due to the weakness of the signal when using this type of
tap, telephone amplifiers specifically designed for recording are recommended.
CCE Control Option/Fallback Feature

As a general statement, these settings determine the what (Start on Tap and Stop on
Tap) and the how (how quickly will fallback occur) of fallback recording. These settings
appear on all voice cards.
CCE (Command Control Engine - Unify) control can be compared to an On/Off valve for
whether start and stop events can come from Unify. The default is set to Yes. This
means that where Unify exists, recording is based on Unify call tagging. Normally there
is no reason to turn off CCE control, except for security reasons in extreme cases. CCE
must be set to ON for Live Monitoring.
The FallBack timer determines the implementation of CCE control. This timer acts as a
grace period so that if a Unify server fails, then a short period is assigned to allow the
server to correct itself before assignment of functionality is passed to the backup
server. This setting should be set to a value other than zero (0) if a Unify hot failover
configuration is being used.
Triggering a Recording
Regardless of the recording method chosen (VOX or non-VOX) you start and stop
recording on a per channel basis. This requires you to view the voice card and
configure each channel. In Recorder Manager, click General Setup > Voice Cards
> Channels, select the channel(s) to be configured for recording, and click
Configure. The result is shown in the following window:

64
Click the arrows beside Start on Tap and Stop on Tap and choose an option
(Always, Never, and In Fallback). These must be set to Always or In Fallback to
enable the tap sense (both VOX and non-VOX) to actually trigger recording. For more
detailed information, refer to the Voice Cards chapter in the System Administration
guide.

65
System Administration
End users can access and manage a single Recorder using Recorder Manager, and
multiple Recorders across the enterprise using Enterprise Manager. These Recorder
management tools run in the Microsoft Internet Explorer Web browser.
Recorder Manager Functionality

Recorder Manager provides the functionality to perform the following tasks:
z
Add and authorize users of the Recorder Manager who can access and manage the
Recorder
Choose and configure CTI Adapters
Manage telephone extensions
Configure common components, such as the local archive, the Call Buffer, and the
database
Configure voice cards and network interface cards
Configure Analyzer for IP recording
z
z
Configure and monitor alarms that are triggered by predefined and programmed
events and conditions
Configure the Recorder license
Perform routine maintenance, such as adding an archive device, changing a voice
card, and restarting the Recorder
For detailed information about using Recorder Manager, refer to the System
Enterprise Manager Functionality

Enterprise Manager provides the functionality to perform the following tasks:
z
z
z
Specify the server name and port number of the Enterprise Manager server, and
assign an enterprise administrator with the appropriate privileges.
Manage application licenses.
Create or edit Site Groups, Sites, and users, including user security (roles and
privileges).
Manage Recorders across the enterprise, including copying Recorder configurations
across the enterprise, viewing Recorder alarms across the enterprise, and
managing user replay restrictions through Search and Replay.
Manage IP recorder extensions as a group or individually using cluster or uncluster
modes, respectively.
For detailed information about using Enterprise Manager, refer to the Enterprise
Manager Administration Guide.

66
Auditing
Every change to configuration, whether in Enterprise Manager or Recorder Manager
creates an audit entry that records the actions made and the items that were changed.
In Recorder Manager, auditing is accomplished by intercepting the calls to the adapter
layer in the Recorder Manager. The Auditor component intercepts method calls on the
adapter, creates an audit record, and publishes it to the enterprise database via the
Remote Component Auditing Web Service. This web service writes the audit record to
the enterprise database via the Audit API. Auditing in Enterprise Manager is done
through the Audit API (that is, by clicking System > Administration > Audit
Viewer).
Deletion of audit database records can be done for performance reasons, but
is not recommended, as this will affect audit and compliance data. If you
must delete old data, then first make a backup of the Audit database. The
EventLog table is the main table in the Audit database, which can grow large
over time. Data can be deleted from this table by identifying (filtering) old
data by EventTime column.

67

68
Chapter
Recorder Functionality
This chapter describes the overall architecture of the Recorder environment,
and includes the components with which the Recorder interacts along with
descriptions of their functionality. This information is presented in the following
topics:
z
Recorder Architecture, page 70
Collaboration Architecture, page 72
Configuration Architecture, page 74
Retrieval Architecture, page 76
Disk Management Architecture, page 78
Application Server and Workstation Applications, page 83
Live Monitor Architecture, page 85
ContactStore Plus Architecture, page 88
Screen Capture Architecture, page 91
Chapter 4: Recorder Functionality
Recorder Architecture
The Recorder architecture consists of software components that interact to enable
full-time recording. The following diagram shows the main components.
Architecture
CTI
Server
Application Server
Archive
Recorder
Server
Archiver
Compressor
Search and
Replay
Integration
Service/
Unify
Consolidator
Content
Server
Workflow
Manager
Disk
Manager
Database
Capture
Engine
Config.
Web
Service
Recorder Manager is installed on the Recorder.

Enterprise Manager would be installed on the Application server.
Recorder Server Components

The following table summarizes the functionality of each Recorder server component,
and contains references to additional information.
Component
Description
Configuration Web
Service
Provides a single entry point to the configuration, status,

and alarm interface of the Recorder. The Recorder Manager
interacts with the Web service to configure the Recorder. For
more information, refer to Configuration Architecture on
page 74.
Capture Engine
Responds to commands from Unify or Integration Service to

start and stop recording, and persists calls and metadata to
the Recorders Call Buffer.

70
Disk Manager
Manages the storage of recorded calls in the Call Buffer, and

notifies the workflow manager when calls are deleted from
the buffer. The Recorder Manager interface is used to set the
free space threshold in the Call Buffer that the disk manager
monitors and maintains. For more information, see Disk
Management Architecture on page 78.
Workflow Manager
Manages the post-recording state of calls, and directs the

archiver, consolidator, and compressor components to
perform operations on recorded calls. For more information,
refer to Workflow Manager on page 32.
Content Server
Provides an HTTP-based Web Service that the Search and

Replay and Archive applications use to retrieve contact and
contact data from the Recorders Call Buffer. For more
information, refer to Retrieval Architecture on page 76.
Consolidator
Responds to commands from the workflow manager to

synchronize the database with the state of recorded
contacts, and to upload contact metadata to the database.
For more information, refer toConsolidator on page 32. .
Archiver
Responds to commands from the workflow manager to

persist contacts to the local archive. For more information,
refer to Archiver on page 30.
Compressor
Compresses calls that are captured in stereo format during

IP recording or calls that are captured in a verbose format
from the Cybertech voice cards, and decrypts calls that are
encrypted. For more information, refer to Call Buffer and
Disk Manager on page 32.

71
Collaboration Architecture
The Recorder can work with existing MediaStore solutions. In this collaboration
environment, Recorders share the database for call recording, but use different
transmission protocols and archiving systems. MediaStore continues to archive to the
ContactStore tape archive, while the Recorder archives to DVD-RAM, DVD-RW, Iomega
REV, or tape storage devices using the Microsoft tape API. This is shown in the
following diagram:
Collaboration Recording Scenario

CTI
Server
eWare/IS/Unify/Search
and Replay Server
Recorder
Server
Archive
CTI Events: Protocol

varies by vendor
NetCom UDP
MediaStore
NetCom UDP
Proprietary
Tape Driver
Tape Archival
Storage
Archiver
CTI
Source
MS Tape API
ODBC
eWare2CC
Unify
Unit
Service
Consolidator
Workflow
Manager
DB
Capture
Engine
ODBC
Voice
Card /
NIC
Control Interface
NGA Capture / TCP
Smartworks
API
Collaboration Description
In the collaboration environment, Recorder server components behave as described in
Recorder Server on page 29, with the exception of the MediaStore recorder and the
eWare2CC module used by Unify or Integration Service. Since the eWare2CC module
issues commands to both legacy Recorders such as Mediastores, and the new
Recorders, it communicates with both using different protocols (Netcom UDP and NGA
Capture/TCP respectively). Maintaining the different protocols allows the addition of a
new Recorder without modifying Unify scripts, a capability essential where customers
add more extensions and trunks to their current configuration to handle increased load.

72
Collaboration Components
Additional collaboration components include the MediaStore Recorder and the Recorder
Manager/eWare 2CC module. These are described in the following sections.
MediaStore Recorder
The MediaStore Recorder component records calls based on commands from Unify or
commands from tap-sense. It archives call data and metadata to tape for disaster
recovery and long-term storage.
eWare 2CC module

This module provides a set of APIs to the Unify script to enable it to communicate with
one or more legacy and current Recorders. It also adapts function calls to the NetCom
message protocol and sends them to the Recorders.

73
Configuration Architecture
The Recorder configuration mechanism consists of the Configuration Web Service
running on a Tomcat Web Server. The Web Service provides a single entry point to the
Configuration, Status, and Alarming (CSA) component of the Recorder, and uses HTTP
to communicate with Recorder Manager and Enterprise Manager. If the optional system
security using the RSA KMS is licensed, HTTPS is used.
The Recorder configuration architecture is used by the Recorder Manager to configure a
single Recorder, and by Enterprise Manager to configure multiple Recorders across the
enterprise. The configuration architecture with Recorder Manager is shown in the
following diagram:
Configuration Scenario
Recorder
Server
System Administrator
or Supervisor Workstation
Archiver
Consolidator
Capture
Engine
SNMP
SNMP
Application
Enterprise
Manager
Recorder
Manager
Config.,
Status,
Alarming
HTTP,
gSOAP
Web
Service
Config.
Web
Service
Tomcat Web
Server
Configuration Components
Configuration architecture components include the Configuration, Status, and Alarming
component on the Recorder server, and the SNMP (Simple Network Messaging
Protocol) Application and Enterprise Manager on the System Administrator/Supervisor
workstation. Recorder Manager and Enterprise Manager are described in System
Administration on page 64. The archiver, consolidator, and capture engine components
are on the Recorder server, and are described in Recorder Server on page 29.

74
Configuration, Status, and Alarming Component (CSA)

This component coordinates calls to various components on the Recorder as well as
providing SNMP-based configuration, status, and alarming information. Note, however,
that component configuration cannot be changed using SNMP; it can only be queried.
The configuration, status, and alarming (CSA) component calls Web services for the
capture engine, consolidator, and local archive components to query status and
alarming information, and to configure available properties on each. The CSA
component serves as a front-end for Recorder sub-components to allow collaboration
with any other sub-component.
SNMP Application
The SNMP application interacts with all SNMP-enabled hardware and software in the
enterprise to display configuration and status information. It also provides an
integration interface to existing third-party software components, such as HP Open
View, that might already be in place in larger organizations.
SNMP trap configurations that are used in setting up alarm notification profiles can be
created using Recorder Manager. For more information about creating SNMP trap
configurations, refer to the System Administration Guide.
Recorder Manager
Recorder Manager is used to access the configuration Web service component.
Recorder Manager provides a web-based user interface that is used typically by system
administrators to configure the Recorder. For more information about Recorder
Manager, refer to Recorder Manager Functionality on page 64.

75
Retrieval Architecture
The retrieval architecture in the Recorder enables the Search and Replay application to
view and replay contacts.
A typical retrieval architecture is shown in the following diagram:
Retrieval Scenario
Recorder
Server
Database
Recorder
Manager
Enterprise
Manager
ODBC
Tomcat
Archiver
HTTP
Weblogix
Search and
Replay
Content
Server
Retrieval Description
The Search and Replay application interacts with the database to produce a list of
contacts for the end user. The end user, who is anyone with permission to view
recorded contacts using Search and Replay, makes a query in the Search and Replay
browser window to display a list of contacts. Search and Replay queries the database
to produce the list. When the user selects a contact for playback, the Search and
Replay application requests the contact from the Recorder. The Content Server
component retrieves and stages the contacts data for display and playback.
Content Server Component

The Content Server component exposes an HTTP-based Web service that Search and
Replay uses to retrieve and view contact data. The Content Server component reads
contact data and metadata directly from the Recorders Call Buffer, or from local
archive, as in the following steps:
1
Search and Replay sends an HTTP request for the inum of the call to Content
Server.

76
Content Server queries the local Call Buffer and returns results if found. Content
Server should be able to retrieve successfully from the Call Buffer 99 percent of the
time.
If the contact is not found in the Call Buffer, Content Server then queries the
database to see if the inum is on any media in a local archive drive.
If the inum is found in the local archive drive, Content Server communicates with
the Archiver component to get the file, then return it to Search and Replay .

77
Disk Management Architecture

The disk management architecture ensures that Recorders record continuously. The
architecture makes this possible by maintaining enough free space in the Call Buffer to
always record contacts. This is accomplished by using a component named the disk
manager, as shown in the following diagram:
Disk Manager Architecture

Recorder Server
Database
Consolidator
Workflow
Manager
NGA/
TCP
NGA/
TCP
Disk
Manager
Call Buffer
(Internal
Disk Drive)
rit
Telephony
Card
let
Smartworks
API
Capture
Engine
De
Disk Management Description

The disk manager is configured with a threshold of free space that must be kept
available in the Call Buffer. When the free space drops below this threshold, the disk
manager begins deleting the oldest calls until the threshold is above the configured
level. After deleting a call, the disk manager notifies the workflow component, which
ensures that the database, by way of the consolidator, is synchronized with the latest
state of a call.
Disk Management Components

The disk management architecture centers around the disk manager component. Other
components in the disk manager architecture have been described previously in this
guide.
Disk Manager
The disk manager component maintains the amount of free disk space on the disk
drive used for the Call Buffer at or above a configurable threshold. It achieves this by

78
deleting the oldest calls when the free space falls below the threshold. The disk
manager notifies the workflow manager whenever it deletes a call. The disk manager
can be configured using the Recorder Manager as described in the System
Disk and System Performance

Disk and System performance describes system problems that might appear in your
recording system from time to time. One or more of the following problems may be a
result of improper hardware sizing, configuration or installation, or a result of incorrect
3rd party software configuration:
z
Slow or unresponsive query or replay performance from Search and Replay

(Viewer)
Slow replay or 1263 errors from Quality Monitoring (Balance) Interactions in
Contact Store Plus configurations
NTI Driver errors in the Recorder's Windows Event Log describing a buffer overflow
which causes the error Recording Error: Recorded Less Than Expected Data Alarm
Media or Calls Consolidation errors with a description of any timeouts exceeded
Unify queue overflows
The TDM/ITS IP and IP Recorder is a real-time application requiring high performance

access to disk and operating system resources. In addition to following the hardware
specifications and requirements recommended in installation guides, certain steps
must be followed as ongoing system maintenance to ensure optimal operation. Failure
to follow these guidelines may result in slow system performance and the potential for
loss of recording.
It is recommended that you use Windows Performance Monitor to assess system
performance at any time. As a general rule the current disk queue length for each
physical drive should average less than 5 (calls) and should touch zero every few
seconds. If this average goes above 50 for more than 10 seconds at a time, you should
investigate disk issues as described in the following topics:
z
Patches, page 80
Disk Subsystem Hardware, page 80
Application File Locations and Disk Partitioning, page 80
Logging, page 80
Database Configuration, page 81
Virus Scanning, page 82

79
Patches
The PostgreSQL Database requires a nightly database wide vacuum. PostgreSQL
should be vacuumed by using the PGAdmin III database maintenance utility (located
in the Contactstore directory on each Recorder) on a monthly basis.
To execute this utility interactively, log into PGAdmin III and execute a maintenance
vacuum with the default options.
The Recorder Consolidator Service can be turned off if Centralized Archiving is not
being used.
To avoid needless alarms, the following patch should be applied to disable the alarm:
\\holsten\patches\tdmrecorder761\TDMR761_15
If slowdowns occur when multiple users replay at once, there is a Viewer patch that
speeds up the number of HTTP retrievals that can occur simultaneously from a
recorder:
\\holsten\patches\Contact_Viewer761\CVWR761_10
Disk Subsystem Hardware

1
For 64 to 239 channels, the system should have a 128MB caching RAID controller
with the calls on a RAID 5 and the OS, Applications and Database on a RAID 1.
Over 240 channels the database should be moved to a separate RAID 5 or RAID 10
logical drive.
The RAID Logical Drives should be configured for write back, cached IO
(input/output) and adaptive read ahead.
Application File Locations and Disk Partitioning

The Program Files\Witness Systems folder which contains the application logs and
PostgreSQL Workflow database must be on a separate RAID drive from the Call Buffer.
The system should be configured as follows:
z
Logical Drive 1 (RAID 1)
C: Partition Operating System, Retrieval Cache
D: Partition Applications, Logs, PostgreSQL
E: Partition Database
Logical Drive 3 (RAID 5)
F: Partition Call Buffer (64k block size required)
Logging
Unify debug logging should be turned off. Unify should only log warning and errors to
the log file for normal operation. This type of script-based logging is inefficient because
of the way Unify executes disk write operations. It scans the log files from beginning to
end during each write operation causing the disk head to thrash.

80
To disable logging, the LogLevel in tblConfig should be set to 0. In tblLogMsg, the

Link and Linkinfo fields should be set to TRUE in the Trace column, which should be
set to FALSE.
Tracing for the Source DLLs should be turned off. This should not be turned on unless
you are attempting to debug a problem with a source DLL. To turn off tracing for the
source DLL, do this:
1
Launch CTI Studio
Choose the TRACING menu option
Uncheck (if checked) the Tracing Enabled option.

This will disable tracing for the source DLLs.
Logging in TDM Recorders Witness Debug Logging Service (WDLS) should be set to the
debug level of Info for all components for normal operations, by doing this:
1
Navigate to your <Install Dir>\ContactStore directory, and then click

LogManager.exe, where <Install Dir> is the folder where the Recorder software is
installed.
Select Default in the Choose Components selection box.
Set the Trace Level to Info
Click Apply Changes.
Database Configuration
Using MS SQL Enterprise Manager, you should set the MS SQL Calls and Media
database to the maximum size projected for the system, using the metrics in the
Product Note. You should do this immediately after installation of the system. Allowing
it to grow automatically will lead to the database files being fragmented, requiring you
to defragment the disk containing the database files.
You can also schedule the MS SQL Nightly Backup and Maintenance Jobs as follows:
1
Setup a backup database maintenance plan under Enterprise Manager under

Management > Database Maintenance.
Right click Database Maintenance and select New Maintenance Plan.
Setup a backup job, choose all databases and leave the default options on the
Optimization and Integrity settings.
Select the directory where you want to backup the files to, and specify how many
days/weeks you want to keep the backups.
This will now create a job just for the backup.
Create another maintenance plan for the Optimization and Integrity Checks job.
Select all of the Witness Databases except EyretelSite.

Selecting EyretelSite can cause the optimization job and ContactViewer to deadlock
each other when they execute, which will cause slowdown or halt of the database
and ContactViewer.
Setup the Optimization job with the first option of Reorganize Data and Index
Pages.

81
Select the first radio option under that for Reorganize Pages with the original
amount of free space. Failure to not select this option will default to the bottom
radio option which will remove free space from the database resulting in severe
database file fragmentation on the disk and undoing the manual grow of the
database. You can leave the Integrity Check options as the default.
Set the time for the Optimization job after the time for the Integrity check.
Integrity checks normally take up to an hour.
10 Set this job to Daily to keep the index pages in order and keep the queries and
stored procedures running quickly.
Virus Scanning
Norton AntiVirus version 7.50 or greater and McAfee VirusScan Enterprise 7.0 have
been certified to be compatible with TDM/ITS IP and IP Recorders. However, you must
make the following changes to your anti-virus software to ensure that it does not affect
Recorder performance.
1
Disable any corporate anti-virus policy enforcement to prevent the following

customizations from being lost.
Disable File System Realtime Protection for Norton and On-Access Scanning
for McAfee since they reduce system performance (which is critical in real-time
recording).
Exclude the following from being scanned:
The configured Calls foldercall buffer (by default C:\calls)
SQL Server or Oracle database files
The PostgreSQL database
Local DVD-RAM drives, if one or more are being used
Exclude the following file types from virus scanning: *.xml, *.wav, *.outee,
*.open.wav, *.open.xml, *.dat, *.tar, *.tmp
Exclude the following directory locations from virus scanning:
C:\Program Files\Witness Systems\ContactStore\

C:\Program Files\Witness Systems\Unify\
C:\RetrievalCache.
If scanning is not performed in real-time, you should schedule periodic virus
scans for non-peak hours.

82
Application Server and Workstation Applications
Application Server and Workstation

Applications
The application server typically includes the Search and Replay, Enterprise Manager,
and Unify or Integration Service applications, while the supervisor or system
administrator workstation can include the Observer application. These applications are
shown in the following diagram:
Architecture
CTI
Server
Application
Server
Archive
Recorder
Server
MS Tape
API
Archiver
Database
ODBC
Compressor
Observer
Integration
Service
CTI Events
Protocol varies
by vendor
Search and
Replay
Enterprise
Manager
Consolidator
HTTP
Content
Server
Workflow
Manager
Disk
Manager
RTP
Capture
Engine
Control Interface
NGA Capture /
TCP
Config.
Web
Service
Recorder Manager is located on the Recorder Server.
Application Server Description

System administrators or supervisors use the applications running on the application
server to view and monitor calls, and to configure several Recorders across multiple
sites in a large enterprise. Daily administration changes can be made without
interrupting recording or playback operations. Tasks such as user administration and
device administration do not affect performance.
Application Server Components

Administration server components include Search and Replay and Enterprise Manager.
These are described in the following sections.

83
Application Server and Workstation Applications
Search and Replay

The Search and Replay application is used for viewing and replaying recorded calls.
Search and Replay interacts with the Content Server component to retrieve the call
data that it displays. Search and Replay is used typically by system administrators and
supervisors.
Enterprise Manager
The Enterprise Manager is used to access the configuration Web service component.
The Recorder Manager provides a Web-based user interface that is used typically by
system administrators to configure multiple Recorders across the enterprise. For more
information about Enterprise Manager, refer to Enterprise Manager Functionality on
page 64.
Workstation Component
Workstation components include Observer. That component is described in the
following section.
Observer
The Observer application is used for monitoring calls in real time, and is implemented
using the live monitor architecture as described in Live Monitor Architecture on
page 85. Observer is used typically by system administrators and supervisors, and is
installed automatically along with Recorder Manager.

84
Live Monitor Architecture

Recorder uses the Observer application for the live monitoring of calls. The live monitor
state component runs on a designated Recorder node, and connects to the capture
engine processes on each Recorder node. The state component aggregates the state
information about each active call from all the Recorders, and presents a unified
picture of state to each Observer client.
The following simplified diagram shows one possible configuration of the live monitor
architecture:

Database
eWare/IS/Unify
Search&Replay/Server
Recorder
Server
Observer
ODBC
Tomcat Web
Server
Observer
Live Monitor State

Component
Capture
Engine
Live Monitor Control/

Recorder State Interface
using NGA Capture TCP
Live Monitor
Streaming Interface
using RTP
Live Monitor Description

Observer queries the state of active contacts from one or more Recorder by using the
live monitor state component. The state component maintains an aggregate state of all
Recorder channels as well as all tag values that have been applied to calls on those
channels. Observer determines which tags are interesting for supervisors, and displays
the values of those tags. Typically, these values include Agent Id, Extension, DNIS, and
Call Direction, among others.
When a supervisor indicates to Observer that they want to monitor a channel on the
Recorder, Observer requests a voice stream from the Recorder. The voice is streamed
back to the desktop using the real-time protocol (RTP). Observer implements a native

85
component that can play the voice over a sound card on the supervisor's PC. RTP is
used because it is the industry-standard for voice streaming.
Live monitor replay restrictions can be set using Enterprise Manager or Search and
Replay, which provides the functionality to specify the tag values that can or cannot be
monitored. Replay restrictions are used to identify which telephone extensions a
supervisor can monitor in real time. For more information about setting replay
restrictions for live monitor replay, refer to the System Administration Guide.
Live Monitor Interfaces

The interfaces used by live monitor enable communication with the various recorder
components, and include: live monitor control/ recorder state interface, live monitor
state interface, and live monitor streaming interface. These are described in the
following sections.
Live Monitor Control/ Recorder State Interface

This interface is used by the live monitor state component to receive the state of
Recorder channels. The state component connects to each capture engine on a site,
and each capture engine streams state change information to the live monitor state
component in real-time using the NGA Capture TCP text protocol
Live Monitor State Interface

This interface is used by Observer to query the state of Recorder channels, and to
provide information to display to the user regarding the calls on those channels. It uses
the same TCP text protocol used by Observer and Unify or Integration Service.
Live Monitor Streaming Interface

This interface is used by the capture engine to stream voice data to the Observer
application, using RTP.
Live Monitor Components

Live monitor components and applications that are accessed from the respective live
monitor interface include: capture engine, live monitor state component, Observer, and
Web Observer. These are described in the following sections.
Capture Engine
The capture engine is used with the live monitor control/recorder state interface.
Essentially the same as the NGA capture protocol, the capture engine forwards its
response messages to all connected clients rather than to only the client that issued
the request. The capture engine collaborates with the live monitor state component to

86
aggregate states across many Recorders, and signals to the capture engine to begin
streaming voice data.
Live Monitor State Component

This component effectively listens to each capture engine's state change events to
maintain the current state of all channels and the metadata for contacts on those
channels. At the same time, the state component aggregates the state of many
individual Recorders so that it can present an aggregate view to Observer. This
component works with the capture engine and Observer to listen to state change
events on one or more capture engines and provide aggregate state information to
Observer.
Observer
The Observer component enables supervisors to monitor calls in real time from their
desktops. Observer does this by collaborating with Web services and the capture
engine to initiate RTP streaming of any live call on the Recorder.
Web Observer and AudioServer

The Web Observer component enables supervisors to monitor calls in real time from
their desktops using a Web-based interface. The live monitor architecture can include
AudioServer which provides the functionality to manage a scalable pool (up to 40
concurrent users/playbacks) of telephony ports that can be used by replay
applications, such as Web Observer. For more information about AudioServer, refer to
the AudioServer Installation Guide.
Web Observer is used only with AudioServer. The Web Observer component streams
voice data to the supervisors desktop using the organizations telephone system
instead of RTP. In this configuration, the Web Observer component collaborates with
the capture engine to stream voice data to itself first. Web Observer then converts the
voice data to 16-bit linear format, and streams the voice data to AudioServer.
AudioServer, in turn, streams the voice data to the supervisors desktop using the
companys telephone system.

87
ContactStore Plus Architecture

The Recorder can provide the compliance-recording capabilities of Voice Recording
Search and Replay (formerly ContactStore) with the video recording and
quality-monitoring capabilities of Quality Monitoring (formerly eQuality Balance). The
ContactStore Plus solution allows two Recorders using different Unify or Integration
Service servers to collaborate in recording contacts.
Description
Quality Monitoring and the Recorder work in unison because of Unify or Integration
Service. Unify or Integration Service is adapted to send call recording begin and end
events to the Business Driven Rules (BDR) Server component of Quality Monitoring.
Unify or Integration Service also sends a list of inums associated with the call to allow
Quality Monitoring to store this key in the Balance database, so that the Quality
Monitoring playback applet can replay the voice portion of the call later. The BDR
Server also directs the Recorder to record the corresponding screen of the agent, and
to synchronize it with the voice.

Search and Replay Server
CS Plus
Streaming
Retriever
Recorder Server
HTTP Retrieval Interface
Balance
DB
Streaming Retrieval
Interface
HTTPS Web Service
TCP Streams Audio
Balance
Replay
ODBC
Content
Server
Capture
Engine
Inserts
Contact Info.
and INUM
BDR
Server
Integration
Service
CTI
Server
eRecorder
Balance BDR/
eRecorder Server
eWare/Unify/Viewer
Server
The Recorder behaves in the same way in a ContactStore Plus environment as it does
in other recording environments during recording. This is because Unify or Integration
Service delivers the inum information to the BDR Server. The Recorder configuration in
the ContactStore Plus environment is unchanged, since the ContactStore Plus product
does not provide a configuration interface.

88
Live Monitor and Archive Exceptions

The ContactStore IP Plus product provides a live monitor feature only via a service
observe voice card that is deployed on the Quality Monitoring Recorder. Therefore
there is no Live Monitor scenario in which the Recorder may participate at this time.
Similarly, Centralized Archive is not integrated with Quality Monitoring, and therefore
operates according to Recorder requirements.
Streaming Retriever Enhancement

An additional component, the ContactStore Plus streaming retriever, is included in the
ContactStore Plus scenario. This component allows voice data to be downloaded by the
Quality Monitoring client in a streaming format.
WAV is not a streaming file format.
This enables improved synchronization between voice and screen data, and allows
replay to begin faster since it does not have to wait for the entire voice file to be
downloaded before playing.
ContactStore Plus Components

Additional components included in the ContactStore Plus product to enable integration
with Quality Monitoring include the Balance replay, BDR Server, and ContactStore Plus
streaming retriever components, as described in the following sections.
Balance Replay
The Balance replay component displays recorded calls in the Balance database to
end-users, who select the ones they wish to play. The replay client uses one or more
inum foreign keys in the Balance database to pull the call voice data from the Recorder.
This component works with the ContactStore Plus streaming retriever to convert WAV
files for a call on the Recorder to a streaming format. The replay component also
passes the list of inums to Search and Replay, which provides a stitched audio stream
of the inums.
BDR Server
The Business Driven Rules (BDR) Server plays the role of Unify or Integration Service
in the Quality Monitoring system. This component receives call recording begin and end
events from Unify or Integration Service, along with the list of inum foreign keys
associated with the call, and persists metadata to the Balance database. This
component also directs the Balance Recorder to record the corresponding screen of the
agent on the call. It collaborates with other components as follows:
z
Unify or Integration Service: sends call recording begin and end events.

89
Recorder: directs screen recording
Balance database: persists call metadata to the Balance database.
ContactStore Plus Streaming Retriever

The streaming retriever component works in a similar manner to the Content Server
component, except that it converts the WAV file to an audio format that can be
streamed. The streaming retriever streams the audio to the replay client by stitching
the list of inums it received from the replay client into a single audio stream. The
streaming retriever also enables the Content Server component to download call data
using the HTTP interface.

90
Screen Capture Architecture

The Recording System can record screen images of agents' desktop PCs. This is done
by deploying Screen Capture software on agents' desktop PCs to capture the screen
images and to transfer them to Recorder servers. The Screen Capture module in
Recorders is installed by default with all Recorder installations. For Screen Capture
installation information, see the Recorder Installation Guide. Screen live monitor is not
supported.
Screen Capture Support in CTI Environments

The Screen Capture module resides on an agents desktop. Upon request of the
Recorder, this module captures desktop activity and sends the captured data to the
Recorder. The Recorder notifies the Workflow manager to manage the post-recording
state of calls. Workflow directs the Archiver, Consolidator, and Compressor components
to perform operations on recorded calls. For each Screen Recording, Screen Capture
Engine generates:
z
a content file (.scn), which contains captured screen data
a metadata xml file (.xml), which contains Recording metadata
The recorded screens can be replayed using Search and Replay.
Screen
Capture
(Agent)
Screen
Capture
Workflow
Consolidator
Agent Desktop
Disk
Manager
Archiver
Screen Recorder
The configuration for recording screens is divided between Recorder Manager and
Enterprise Manager. In Enterprise Manager, the configuration is stored in a LAN Screen
data source. This data source has information about workstations, workstation groups,
and user login information for these. In Recorder Manager, the maximum number of
screen recordings and the maximum record time for the screen recording can be

91
configured. For information about setting up screen recording, if your system supports
it, refer to the System Administration Guide.
For information on setting up dynamic workspaces through the use of subnets and
subnet masks, refer to the Enterprise Manager Administration Guide.
Screen Capture Support in non-CTI Environments

The following sections apply to recording systems that use the Integration Service. For
systems that do not use IS, functionality is provided through custom Recorder
Controller (Unify) scripting.
Screen capture support in non-CTI Environments provides two different types of
functionality:
1
Screen Recording Functionality in non-CTI Environments

Where there is no CTI to trigger Business Rules, the Recorder Controller creates
calls based upon the messages received directly from the Recorder without any
other CTI feed. These calls are then sent to the Business Rules engine, as with any
other call, whereby rules to record video content can be triggered based on
conditions of the user's choosing. The attributes (used in the conditions) that are
available are limited, and are described below.
Business Rule Functionality on Recorder Attributes

Regardless of the Recorder configuration, Business Rules can be written to trigger
on select attributes sent to the Recorder Controller by the Recorder. The attributes
(used in the conditions) that are available are limited, and are described below.
1. Screen Recording Functionality in non-CTI Environments

Screen recording functionality in non-CTI environments is supported in both TDM and
IP Recorder environments. The behavior of the feature differs slightly based on the
environment (station-side TDM recording or IP Recording) as described below. Screen
Recording in Trunk-Side TDM environments without CTI is not supported (due to
insufficient information in the Recorder events).
Station-Side TDM Recording Environments

Due to the TDM Recorder sending separate messages for the recording start and for
each separate attribute on the recording, and since the order in which the attributes
will be received from the Recorder is not defined, the Recorder Controller must wait
until the Extension attribute is received from the Recorder before the Recorder
Controller can create the call and submit the event to the Business Rules Engine for
evaluation. This may cause slight latency between the time when the Recorder starts
recording and the time when the Business Rule is triggered to start Screen Recording.
IP Recording Environments
In some IP environments, such as Avaya Passive IP, the IP Recorder sends multiple
start and stop recordings for a single call. This results in multiple segments in Search

92
and Replay, since there is no way to distinguish one start message from another. There
is one screen recording segment for each STARTED message sent by the recorder.
Triggering Screen Recording Functionality in non-CTI Environments

A Business Rule is required to trigger Screen Recording functionality in non-CTI
environments. A Business Rule based on Event Type Begin_Call or based on Extension
can be used to trigger Screen Recording functionality in all non-CTI environments. In
addition, a Business Rule based on Recorder Attributes can also be used to trigger
screen recordings as detailed in the next section.
2. Business Rule Functionality on Recorder Attributes

Business Rule Functionality on Recorder attributes can be used in any Recorder
environment. The attributes available for use in Business Rules depend on the Recorder
Environment.
TDM Recording Environments

The following Recorder Attributes can be used in Business Rules in TDM environments.
The exact content of the attributes will depend on your environment.
z
FirstMessage - First message displayed on phone set display
LastMessage - Last message displayed on phone set display
DTMFDigits - Dual Tone Multi frequency digits on TDM Recorder
IP Recording Environments
The following Recorder Attributes can be used in Business Rules in IP environments.
The exact content of the attributes will depend on your environment.
z
CallingParty - Number of the line from which call is made
CalledParty - Number of the line to which call arrived
CallingPartyName - Agent ID of the calling person in the case of a Cisco Switch
CalledPartyName - Agent ID of the called person in the case of a Cisco switch
CallType - Type of Call
Understanding Workstations, Seating, Phones and Workspaces

This section lists the different types of seating, workstation, phone and workspace
configurations possible in Enterprise Manager. These can be broken into three
configuration concepts:
z
Dynamic and Static Workspaces
Seating Arrangements for Phones and Workstations
Dynamic Workstations

93
Dynamic and Static Workspaces

Workspace is a term for the imaginary entity of a phone associated to a workstation.
This association can be done dynamically, based on People logging into the individual
devices at run time, or statically at configuration time.
To have a static association between a phone and a workstation you can either:
z
Associate a Workstation to a Phone Data Source / Extension in the LAN Data

Source > Workstations edit/create screen, or
Associate a LAN Data Source / Workstation to the Phone in the Phone Data Source
> Phone edit/create screen.
If either of the above assignments is not done then the association of phones to
workstations is considered to be dynamic.
Seating Arrangements for Phones

This section describes how People can be associated to phones.
A single Person can be associated to a phone either dynamically, using logins to the
individual devices at runtime, or statically by assigning them at configuration time. The
setting that determines which of these options are available for a particular Data
Source is located in the Phone Data Source > Settings screen under Recorder Settings
> Seating Arrangement. The option you choose here determines what assignment
fields are going to be available for each person on the People screen for this Data
Source. The three options are:
Fixed This setting means that People are only associated to Phones at configuration
time. This will give the user the ability to ONLY assign a Phone to a Person in the People
screen for this Data Source. If a Device login event is received it will be used instead of
the fixed seating assignment to determine what People are assigned to which Phones.
Dynamic (Free) This setting means that only device login events will be used to
determine what People are associated to each device. People are assigned only Agent
ID's in the People screen for this Data Source. Either a CTI login to the phone, or a
Workstation login to the workstation (if a phone is associated to the workstation) can
be used to associate the Person to a Phone.
Hybrid This setting means that for any single Person either one above options can be
used. Whether any specific Person is associated to a phone statically at configuration
time or dynamically at run time is determined by which fields are populated for the
Person in the People screen for this Data Source. If the Person is assigned only an
Agent ID for this data source they will be considered Dynamic. If the Person is assigned
a Phone for this Data Source they will be considered Fixed.
Seating Arrangements for Workstations

This section describes how people can be associated to workstations.
Unlike People associations to phones, People associations to Workstations can only be
done dynamically at run time. The run time association is determined by People
logging into either the Workstation directly, or by a CTI login to a Phone that is
associated to a Workstation.
People can log into a Workstation directly though one of several methods:

94
AIM login from the workstation,
eQConnect API login
Use of the Dynamic Workstation feature (described below).
Dynamic Workstations
In the previous version, Workstations had to be entered into the system individually for
the system to record them. A new option is now available where the administrator only
needs to define a subnet to allow any Workstations with Agent Capture installed that
fall into the range defined by the subnet to automatically have the ability to be
recorded. Agent logins are also sent automatically to the Integration Service for these
Workstations. The subnet is defined in the LAN Data Source > Workstations screen.
Agent Capture on each workstation is also configured with the IP/hostname and port of
the Integration Service.
Free Seating Arrangement Scenarios

Dynamic Workstations with Dynamic Workspaces
Description
z
Workstations: Dynamic
Workspaces: Dynamic
Seating: Free
Logins: Workstations and CTI
In this scenario workstations are not individually configured but subnets are used.
Phones are not statically assigned to workstations. A Login is then received from the
Workstation and CTI to associate the agent to the workspace.
Configuration steps:
The following general steps describe how to set up Dynamic Workstations with
Dynamic Workspaces. For details on each step, refer to the Enterprise Manager
1
Set the Data Source to Free Seating
Configure the Workstation subnet
Configure the Phone
Assign a LAN Data Source Agent ID to the Person
Assign a Phone Data Source Agent ID to the Person
Execute CTI logon to phone which will associate extension to the Agent.
Execute Capture Service logon which will associate workstation to the Agent
Integration Services will build the association between the workstation and extension
dynamically from the two logon notifications.

95
Dynamic Workstations with Static Workspaces

Description
z
Workstations: Dynamic
Workspaces: Static
Seating: Free
In this scenario Workstations are not individually configured. Instead, subnets are
used. Phones are statically assigned to workstations. A Login is then received from the
Workstation and CTI to associate the agent to the workspace.
Configuration steps
1
Configure the Workstation subnet
Configure the Phone
Build the workspace by assigning the phone to a Workstation or a Workstation to

the phone
Execute either a CTI logon to the phone, or a Capture Service logon. This associates
the extension and Workstation to the Agent.
Static Workstations with Dynamic Workspaces

Description
z
Workstations: Static
Workspaces: Dynamic
Seating: Free
In this scenario Workstations are configured individually and extensions are statically
assigned to Workstations. A Login is then received from either the workstation or CTI
to associate the agent to the workspace.
Configuration steps
1
Configure the Workstation
Configure the Phone
Execute the CTI logon to the phone. This associates the extension to the Agent.
Execute a Capture Service logon. This associates the Workstation to the Agent
The Integration Services builds the association between the Workstation and
extension dynamically from the two logon notifications.

96
Static Workstations with Static Workspaces with Login

Description
z
Workspaces: Static
Seating: Free
Logins: Either Workstation or CTI only
In this scenario, Workstations are configured individually and extensions are statically
assigned to Workstations. A Login is then received from the Workstation to associate
the agent to the workspace.
Configuration steps
1
Configure the phone
Build workspace by assigning the phone to the Workstation or Workstation to the

phone.
Execute either a CTI logon to the phone or a Capture Service logon. This associates
the extension and Workstation to the Agent.
Fixed Seating Arrangements

Static Workstations with Static Workspaces
Description
z
Workspaces: Static
Seating: Fixed
Logins: None
In this scenario workstations are configured individually and extensions are statically
assigned to workstations. Fixed seating is assigned so no login is required to associate
the agent to the workspace.
Configuration steps
1
Set the Data Source to Fixed Seating or Hybrid
Configure the phone
Build the workspace by assigning phone to Workstation or Workstation to phone
Assign a Phone Data Source Extension to the Person
Workspaces are established on startup and the assigned agent is associated to the
workspace.

97
Dynamic or Static Workstations with Dynamic Workspaces

Description
z
Workstations: Dynamic or Static
Workspaces: Dynamic
Seating: Fixed
Logins: None
In this scenario, Workstations may or may not be individually configured. Phones are
not statically assigned to Workstations. People are associated to workspaces by
assigning extensions to them. This scenario is not a core scenario and takes on the
behavior of a Free seating arrangement, since logins from both the Workstation and
the extension are required to associate the two.

98
Chapter
Recording with DMS

Recording with DMS provides an overview of call recording functionality as
related to Duplicate Media Streaming (DMS) and how Cisco and Nortel switches
interact with Recorders to support IP recording using DMS.
DMS information is presented in the following topics:
z
Recording with Cisco DMS, page 100
Recording with Nortel DMS, page 106
Chapter 5: Recording with DMS
Recording with Cisco DMS

Recording with Cisco DMS provides an overview of Ciscos call recording functionality
as related to Duplicate Media Streaming (DMS) and how the Cisco Call Manager (CM)
interacts with Recorders to support recording. Different call recording scenarios are
also presented, to illustrate the interaction between each system.
Cisco DMS is not supported against encrypted phone calls or
softphone endpoints. For a list of DMS-supported devices, please
contact Cisco.
Cisco DMS Information is presented in the following topics:
z
Recording Sessions
Recording Invocations
Recorder Integration
Call Recording dScenarios

The following figure illustrates different network components involved in a call
recording session and the protocols that they use.
Cisco Call Recording Process
Protocol
Agents voice stream
Customers voice stream
CallManager
SIP
PSTN / WAN
MGC/H.323
Integration
Service
Server
SIP/SCCP
NGA/RCP
Customer
Voice Gateway
IP
Agent
Recorder
NGA: New Generation Architecture. RCP: Realtime Control Protocol. SIP: Session Initiated Protocol. SCCP: Skinny Call Control
Protocol. MGC: Media Gateway Control. H.323: Multi-media Transport Protocol

100
Recording Sessions
Call recording relies on the relaying of two separate media streams (one is the
customer's voice and the other is the agent's voice) to the Recorder. Call Manager
establishes two independent call signaling sessions with the Recorder's Integration
Service (IS), each one managing a single one-way stream, to relay these two separate
media streams to the Recorder.
To establish a recording session, as a first step, CM initiates two server calls to the
agent for the two media streams of the customer-agent call (a server call is a call
initiated by CM without an originating party). These two server calls, referred to as
recording calls, are made to the build-in-bridge of the agent's IP phone and therefore
are not presented to the agent either visually or audibly. As part of establishing the
media connections, CM sends media relaying or forking instructions to the phone. In
the first of the two calls, the relaying instruction is for the agent's voice, also called the
local stream. In the second call, the relaying instruction is for the customer's voice,
called the remote stream. These recording calls are automatically accepted by
build-in-bridge of the agent's IP phone without any user action. CM then redirects the
two calls to the SIP trunk pointing to the Recorder's IS. The result of the recording
session is the two media streams of the recorded call (customer-agent call) being
forked or relayed from the agent's IP phone to the Recorder.
Cisco call recording provides for two ways of invoking call recording: automatic call
recording, and application-invoked selective call recording. A line appearance
configuration determines which mode is enabled. This line configuration is imported
into the Recording System configuration from CM, easing setup.
If automatic call recording is enabled, a recording session is triggered whenever a call
is received or initiated from the line appearance.
When application-invoked call recording is enabled, a recording application can start a
recording session for a call after it becomes active.
Selective recording can occur in the middle of the call, whereas automatic recording
always starts at the beginning of the call.
Recorder Integration
The Recorder's Integration Service (IS) is configured in Call Manager (CM6 and later)
as a Session Initiated Protocol (SIP) trunk device to receive calls for recording. It must
support the SIP protocol to accept them.
The SIP proxy provided by IS has a SIP stack that communicates with the CM to
exchange SIP signaling messages.
The Control Client provided by IS communicates with the IP Capture Engine, which
uses NGA/RCP protocol, to control the recording.
Cisco DMS integration has limited tagging in Call Manager 6. Calls are tagged with the
DN being recorded, Display name of the DN, and the CallRef. If more tagging is
required, then you must use the Integration Service JTAPI.

101
Call Recording dScenarios

This section describes the various permutations of a phone call from a customer to an
agent. The following scenarios are described:
z
Automatic Recording Session Invocation for All Calls to or From Agent's Line, page
102
Agent Puts Call on Hold While Being Recorded, page 103
Conference and Recording, page 103
Load Balancing, page 105
Automatic Recording Session Invocation for All Calls to or From

Agent's Line
The following figure illustrates the process of an automatic call recording session. Here,
two recording calls are established for the recording session.
Automatic Call Recording Process

M
Integration
Service Server
DN=3000
INVITE
M
INVITE
M
setup 3
1 dial
setup
setup 8
4 setup
answer 2
BIB
IP
Customer
Agent1s voice
Agent 1
DN=2000
Customers voice
Recorder
DN = Domain Name, BIB = Build in Bridge
The followings steps are shown in the figure:

1
Customer calls into the call center.
The call is routed to Agent1. Agent1 answers the call. The agent's IP phone starts to
exchange media streams with the customer.
Call Manager (CM) first makes a recording call to the Build in Bridge (BIB) of the
agent's IP phone for the agent's voice. CM then makes the 2nd recording call to the
BIB of the agent's IP phone for the customer's voice.
The Recorder's IS receives and answers the recording call setup messages from CM
for the agent's voice using SIP. The Recorder's IS sends a STARTCALL command to
the Recorder using NGA/RCP, to start the recording of this call. It also sends out a
STARTSTREAM command to the Recorder to start receiving RTP data for this stream.
Agent1's IP phone starts to fork the agent's voice stream to the Recorder.

102
In steps 5 to 8, the Recorder's IS receives and answers the recording call setup
messages from CM for the customer's voice, using SIP. The Recorder's IS sends a
STARTCALL command once to the Recorder using NGA/RCP to start the recording of
this call. From the second call on, it sends out a STARTSTREAM command to the
Recorder to start receiving RTP data for this stream. Agent1's IP phone starts to
fork the customer's voice stream to the Recorder.
Agent Puts Call on Hold While Being Recorded

The following figure illustrates a scenario in which the call being recorded is put on hold
by the agent. When the call being recorded is put on hold by the agent, the two
associated recording calls are terminated by CM. After the call being recorded is
resumed, two new recording calls are established.
Call on hold while being recorded

Integration
Service Server
DN=3000
X
Music On Hold
Server
hold
1
disconnect
2 3
disconnect
disconnect
BIB
IP
Agent 1
DN=2000
Customer
Recorder
Integration
Service Server
DN=3000
resume
4
setup
5 6
setup
setup
BIB
IP
Customer
Agent1s voice stream
Agent 1
DN=2000
Recorder
DN = Domain Name, BIB = Build in Bridge
Conference and Recording

The following figure illustrates a case where Agent1, when the call with the Customer is
being recorded, creates a conference to include Agent3 in the conversation.

103
During the conference setup process, the recording calls are torn down. After the
conference is completed, the recording calls from Agent1 to the Recorder's IS are
re-established. The two streams that are sent to the Recorder are Agent1's voice and
the stream coming from the conference bridge, namely the mix of the customer's and
Agent3's voices.
Conference Call
IP
Integration
Service Server
DN=3000
Agent 3
DN=2001
conference 1
disconnect 3
4
Music on
Hold Server
hold
disconnect
disconnect
disconnect
BIB
IP
Voice Gateway
Customer
Agent 1
DN=2000
IP
Recorder
Integration
Service Server
DN=3000
Agent 3
DN=2001
Conference
Bridge
setup
answer 5
6
7
setup
setup 8
BIB
Customer
Protocol/action
Agent 1 voice stream
Customer voice stream
Agent 3 voice stream
Agent 3 + Customer voice
Agent 3 + Agent 1 voice
IP
Agent 1
DN=2000
Recorder
BIB: Build in Bridge

DN: Dialed Number
Agent1 starts a conference to include Agent3 in the conversation with the customer.
LEGEND: MOH = Music on hold, DN = Dialed number, IF = Integration Service.
The followings steps describe the Conference scenario illustrated in the figure:
1
Agent1 presses the conference key and then dials Agent3.
The call between Agent1 and the Customer is put on hold and so the recording
session is torn down.

104
Agent3 answers the conference consultation call. To complete the conference,

Agent1 presses the conference key again. As a result, the customer, Agent3 and
Agent1 are all connected to the conference bridge. The incoming stream to Agent1's
phone is now the mixed voices of the customer and Agent3.
A new recording session is established for Agent1.
Load Balancing
The following figure illustrates a scenario where SIP proxies are used in a load
balancing environment. The SIP proxy knows the configuration and current status of
each of the Recorders configured. For example, when two SIP INVITE messages are
sent from a Call Manager to the Recorder's IS, the SIP proxy determines which
Recorder to forward the recording sessions on to.
In the figure, the SIP proxy knows the configuration and current status of Recorders 1,
2 and 3. Consequently, it forwards the recording sessions to Recorder3.
Load Balancing
setup
Integration
Service Server
DN=2000
setup
M
M
M
M
setup
setup
Recorder1
BIB
IP
Customer
Protocol /SIP
Agent1
DN=2000
Agent 1s voice
Recorder3
Recorder2
Customers voice DN = Domain Name, BIB = Build in Bridge

105
Recording with Nortel DMS

Recording with Nortel DMS provides an overview of Nortels call recording functionality
as related to Duplicate Media Streaming (DMS) and how the Nortel CS 1000 interacts
with Meridian Link Services (MLS) and the Recorder's Integration Service to support
recording. Different call recording scenarios are also presented, to illustrate the
interaction between each system.
Nortel DMS Information is presented in the following topics:
z
Call Recording Scenario

DMS is the preferred method of recording calls with Nortel IP phones. The Recorder
sends an instruction to the phone, via a Meridian Link Services (MLS) interface, to
stream copies of the audio that it is transmitting and receiving directly to the Recorder.
The Nortel switch must be a CS 1000 operating at V4.5 with Symposium V5 or greater.
The following figure illustrates different network components involved in a call
recording session and the protocols that they use.
Nortel Call Recording Process
Protocol
Agents voice stream
CS 1000
MLS
Integration
Service
Server
PSTN / WAN
Customer
Voice Gateway
IP
Agent
Recorder

106
Recording of calls in a Nortel CS 1000 Duplicate Media Streaming environment is
accomplished by directing the Nortel CS 1000 to send real-time protocol (RTP) data for
each audio stream of the conversation to the Recorder via the Meridian Link Services
(MLS) link. The Integration Service establishes two media streams between the
Recorder and the CS 1000 by monitoring calls via the MLS link on the Nortel CS 1000
and then initiating a duplicate stream command telling the Nortel CS 1000 the IP
address and Ports on the Recorder that the RTP for a particular call is to be sent.
Call Recording Scenario

This section describes IP recording with DMS using a MLS adapter, configured in
Recorder Manager, to integrate the Recorder with the switch. This forms the foundation
for the illustrated typical scenario of a phone call from a customer to an agent.
Information is presented in the following topics:
z
Nortel DMS Recording Process, page 108
Calls to or From Agent's Line, page 109
Load Balancing and Redundancy Support, page 110

107
Nortel DMS Recording Process

The following figure illustrates the process of recording with DMS. The Recorder is
configured with a CS 1000 and MLS CTI adapter that integrates all devices. In effect,
the switch tells the phone to send duplicate media streams of all calls to the Recorder.
customers voice stream

agents voice stream
Nortel CS 1000
PSTN/ WAN
customer
MLS
Nortel
IP Protocol
Recorders
Integration
Service
NGA/ RCP
agent
Recorder

108
Calls to or From Agent's Line

The followings steps are shown in the figure below:
1
Customer calls into the call center.
The call is routed to Agent1. Agent1 answers the call. The agent's IP phone starts to
exchange media streams with the customer.
The CS 1000 sends call events to the Recorders Integration Service via the MLS link
notifying him of the call starting.
The Recorder's IS sends the duplicate streaming command to the CS 1000 over the
MLS link, telling the IP and Port to send the customer and agent RTP audio to.
In steps 5 to 7, the Recorder's IS sends a STARTCALL command to the Recorder

using NGA/RCP, to start the recording of this call. It also sends out two
STARTSTREAM commands to the Recorder to start receiving RTP data for the two
streams. Agent1's IP phone starts to fork the agent's voice stream to the Recorder.
Nortel CS 1000
3
CTI Call Events

Recorders
Integration
Service
SetFeatureStartRecord
4
Startstream
5
2 answer
dial
Startstream
6
agent 1
DN=2 000
custome r
customers voice
agent 1' s voice
Recorder

109
Load Balancing and Redundancy Support

Load Balancing with Nortel CS 1000 DMS is accomplished by associating multiple
Recorders to an extension through its Member Group association in Enterprise
Manager. The Recorders Integration Service determines the configuration and current
status of each Recorder configured, and chooses which Recorder is best suited to
record a particular call.
When the Recorders Integration Service detects a failure from a Recorder it initiates a
new Duplicate Media Stream to one of the other Recorders that are configured to
record that same extension. Audio is lost between the time when the Recorder goes
down (that is, when the old streams are torn down) and when new streams are set up
on a new Recorder.
Audio before the failure is lost if the Recorder fails in such a way that it cannot write
the saved data to disk. In many cases, the voice before the failure is retained and
stitched with the rest of the call.

110
Chapter
Passive Recording with

Avaya
Avaya uses H.323 as its call control protocol. H.323 messages communicate
information such as a call has started or a call has terminated. Once these
messages are received, it is a signal that RTP packets from the call exist and
that processing must take place. Information is presented in the following
topics:
z
Overview, page 112
Recording Avaya Calls, page 112
Tagging Avaya Calls, page 113
Avaya System Configurations, page 113
Configuration Procedures, page 114
Chapter 6: Passive Recording with Avaya
Overview
Overview
VoIP calls have two primary components. The first, out-of-band call signaling, informs
all interested parties such as IP phones, IP switches and the IP Recorder, that a specific
call has started or terminated or has been transferred to another party. The signaling
information helps to populate the contact metadata. RTP, the second VoIP component,
contains the actual audio packets that are to be recorded.
The Integration Service is the primary interface to the CTI integration. IP packet
sniffing by the Avaya handler drives the call-control mechanism. In the absence of the
Integration Service, the existing generic Unify script continues to work as designed,
and can still be used.
Recording Avaya Calls

Impact 360 Recorders record Avaya IP calls by analyzing H.323 call control messages
and then processing RTP/RTCP packets in a similar fashion to Ciscos SCCP (Skinny)
recording process. The session description information in the RTCP packets contains
the extensions of the phones, which are used by the Recorders to decide if the call
needs to be recorded. A simplified diagram of Avaya IP recording is shown below:
Call Center Premises (Avaya IP)
Avaya Media Gateway
Communication Manager
CLAN Card
MedPro Card
Packets required for

gateway recording
H323
RTP/
RTCP
CTI Server
Agent Phones
AES/MAPD
TSAPI, CVLAN,
DLG, CT Connect
Genesys
IP Phones
Soft Phones
CTI Events
H323
RTP/RTCP
Packets required for

station side recording
Call Center Network

Mirrored (SPANed)
packets for recording
H323
RTP/RTCP
Recorder
Server
CTI Events
Application
Server
Integration Services
Server
Verint Recording System
The H323 messages and RTP/RTCP packets are routed to the Recorders by the network
switches via standard mirroring or SPAN methods.

112
Tagging Avaya Calls
In a gateway recording scenario (the IP equivalent of Trunk-side Recording), the H.323

call control messages in and out of the CLAN card(s) and the RTP/RTCP packets in and
out of the MedPro card(s) are routed to the Recorders. In a station-side recording
deployment, routing all traffic in and out of the phone ports on the access layer
switches will capture all the needed packets for recording.
In gateway recording, Recorders in an Avaya IP solution support the use of the
TopLayer Load Balancer. See 1+1 TopLayer IDS Topologies on page 140 for more
information on TopLayer devices. All H.323 call control packets required for recording
are TCP packets. These TCP packets must be flooded (that is, distributed) to all
Recorders connected to the Load Balancer. Because the Recorders parse the phone
(extension) node in the RTCP packets, all RTP and RTCP packets must be load balanced
using the source-destination distribution algorithm instead of the weighted round
robin. This ensures that RTP and RTCP streams associated with a call are delivered to
the same Recorder.
Tagging Avaya Calls

Without any CTI events, Impact 360 Recorders extract only limited metadata from
H.323 messages, such as the IP and port of the phone, and the start up time of the
call. The Recorder is unaware of which party initiates the call. The extension extracted
from the RTCP packet is tagged as the Called Party by default. In addition, a typical
Avaya IP call consists of several call segments, including the DTMF or the ring tone, and
the conversation. By analyzing the H.323 messages alone, each one of these segments
constitutes a call and displays as a standalone call in Viewer.
A CTI link is required to do the following:
z
tag searchable metadata to recorded calls
accurately populate the Calling and Called Party fields
stitch the multiple segments associated with a call
Integration Services provide a number of adapters to process CTI events via different
CTI server interfaces, such as TSAPI, supported by Avaya switches. These CTI
interfaces are supported on the AES servers or on the MAPD cards, shown in the
diagram. The CTI interfaces supported by Integration Services are listed in the Avaya
Integration Guide on the Recorder installation DVD.
Enterprise Manager must be used to create Data Sources and Member Groups and to
associate them with the Integration Service. Details of configuring Recorders and
Integration Service can be found on the Enterprise Manager Administration Guide and
Integration Service Guide on the Recorder installation DVD.
Avaya System Configurations

113
Configuration Procedures
The Passive Avaya recording system records with and without a CTI component. A CTI
component is recommended, as it provides both richer call tagging and greater
Integration Service-driven functionality.
Expected behavior and product limitations for each configuration are discussed in the
next two sections.
Functionality without a CTI component

If the Recorder has no CTI component, then Audio recording has only basic tagging
(extension information only) from the IP Recorder. In addition, all extension
management and configuration is performed directly in Recorder Manager.
Functionality with CTI integration

With a CTI component, which consists of a CTI adapter set up in Recorder Manager and
associated to a Data Source in Enterprise Manager, extension configuration is disabled
in Recorder Manager. All extension management and configuration is performed in
Enterprise Manager.
Functionality resulting from CTI integration includes:
z
Enhanced tagging.
Use of the business rules engine.
Ability to perform Screen recording.
ContactStorePlus support
Note that ContactStorePlus works best with a CTI integration. For Balance to properly
play back content recorded by ContactStore, CTI tagging must be in place or
functionality such as Follow the Call and Call Stitching does not work properly.
If the CTI link goes down or the Integration Framework service fails for some reason;
the functionality is the same as a system without CTI, as described previously.
Configuration procedures describe steps for configuring the Passive Avaya Handler in
Recorder Manager and Enterprise Manager, both with and without the CTI Component.
Configuring Avaya with the CTI Component

Configure the passive Avaya CTI handler component using both Enterprise Manager
and Recorder Manager. First create a Data Source in Enterprise Manager, then an
adapter in Recorder Manager, and then finally associate the two in Enterprise Manager.

114
To set up the passive Avaya handler with the CTI component:

1
In Enterprise Manager, create an Avaya Data Source.
Add an IP Extension Group to the Data Source and type the extensions of the Avaya
phones to be recorded.
Set the Record Control Type of the member group to Recorder Controlled
Set the Recording Mode of the extensions to Record.
Assign the Extension Group to the IP Recorder being used.
In Recorder Manager (on the Integration Service server), click Integration Service,
and then add either an Avaya TSAPI or Genesys adapter.
In Enterprise Manager, assign the adapter to the Avaya Data Source created in step
1.
Start the adapter.
After performing these steps, calls on the Avaya phones should be stitched according
to the Integration Service rules, and tagged according to the UDF map configured in
Enterprise Manager.
Configuring Avaya without the CTI Component

Configure the passive Avaya handler directly in Recorder Manager when no CTI
component is available.
To configure the passive Avaya handler without the CTI component:

1
Start Recorder Manager.
Configure extensions (click Operations > Extensions) and license (click System
> License) as usual.
Make sure the NIC is configured for passive recording by clicking General Setup >
Network Settings > Cards and Filters, and then choosing Passive as the
Recording Type.
Click General Setup > Network Settings > Protocols and check the Avaya
H.323 checkbox. Make sure all others are unchecked.
Click Save.
Restart the IPCapture service.

115

116
Chapter
User Defined Fields

This chapter describes associated and non-associated call data captured by the
Recorder, and how that data is related to user defined fields (UDF). Custom
Data and Calculated Custom Data are also discussed in this section.
z
Understanding Call Data, page 118
Unify or Integration Service to Search and Replay Mapping, page 119
Unify or Integration Service to Search and Replay Mapping, page 119
Attributes With Integration Service, page 120
Attributes Provided by Card Model Families, page 121
Attributes Provided by E1/T1 Voice Cards, page 122
Attributes Provided by SCCP, page 123
Attributes Provided by SIP, page 124
Custom Data, page 126
Conditional Custom Data Fields, page 127
Chapter 7: User Defined Fields
Understanding Call Data
Understanding Call Data

Call data captured by the Recorder includes associated and non-associated call data.
Associated call data represents parameters of the call such as the start time, stop time
and call length. In addition to the call data values, other data fields can be appended
that contain any relevant data that is associated with the call. This data can be from
switch CTI ports, and can be information such as an agent extension or wrap-up codes
or data from back office systems, such as the value of sale.
Non-associated call data represents the concept of data channels which can be any
data associated with channels. These allow Unify or Integration Service to place
records into the database when they cannot be directly associated with a voice call.
This is because the call has either finished or the inum of the call is unknown. At this
point, a join is performed between some common element within the associated data,
such as a unique ID from the CTI system, to allow this non-associated data to be
added to the call details.
Associated call data, as shown in the following list, is specified in the Recorder
environment through UDFs. The following call details are logged with every call
recorded:
z
Start Date and Time
End Date and Time
Call length
Dialed Digits (outbound)
CLI Digits
DNIS
Call ID (unique to the call and Recorder)
Call direction
User Definable Fields (UDF)

118
Unify or Integration Service to Search and Replay Mapping
Unify or Integration Service to Search and

Replay Mapping
The following table shows the mapping between UDFs specified by the Unify Scripts or
Integration Service to columns in the Search and Replay default application query.
In this chapter, reference to a TDM Recorder includes the ITS IP

Recorder, which uses the pseudowire emulation (PWE3) protocol.
In this protocol, IP data packets replace time frames on a TDM
trunk.
UDF Field in Unify

Script/IS
Search and Replay column name in the default

query template
udf1
CLI (Called Line Identifier)
udf2
Extension
udf3
Agent ID
udf4
Trunk
udf5
DNIS
udf6
Direction
udf7
Call ID
udf8
Third Party
udf9
Channel Name
udf10
Spare3
udf11
Spare4
udf12
Spare5
udf13
Spare6
udf14
Spare7
udf15
Spare8

119
Attributes With Integration Service
Attributes With Integration Service

For detailed information on UDFs created from the Integrate Service, refer to the
Integration Service Guide and to the System Administration Guide.

120
Attributes Provided by Card Model Families
Attributes Provided by Card Model Families

The following table describes which attributes are available, based on the family of
voice card chosen for recording. Different models in the same brand support the same
attributes.
Voice Card
Type
Digits
Caller
No
Called
No
Direction
DTMF
Digits
CLI
First
Message
Last
Message
DP Trunk-Side
NGX Digital
Extension side
PT Analog
Extension side
LD Analog
Extension side
PCM Digital
Trunk Side
Cybertech
Digital and
Analog

121
Attributes Provided by E1/T1 Voice Cards
Attributes Provided by E1/T1 Voice Cards

The following table describes the Viewer attributes available based on the combination
of T1/E1 protocol and recording mode. Some attributes can only be supplied if switches
using the T1/E1 spans are configured to populate that information. The switch
administrator must be consulted to confirm that the switch is providing these
attributes.
Protocol/
Recording
Mode
Caller
No
Called
No
Direction
DTMF Digits
CLI
None/VOX
ISDN/VOX
ISND/ D Channel
NFAS/VOX
NFAS/ D Channel
CAS/VOX
CAS/CAS
RBS/VOX
RBS/CAS
DASS2/VOX
DASS2/ D Channel
Legend:
* Only available when present on trunk bearer channel

# Only available when trunk span is configured to deliver this information

122
Attributes Provided by SCCP
Attributes Provided by SCCP

The following table describes user defined fields (UDFs) resulting from the Skinny Call
Control Protocol (SCCP) from the Cisco CallManager.
UDF Field
SCCP column names
udf1
Callparty = value primary party tag (2 if none specified), SrcIP

:DstIP. (example "1 ,10.56.7.141:10.56.7.142 ")
udf2
CallingParty
udf3
CalledParty
udf4
CallingPartyName
udf5
CalledPartyName
udf6
CallRef
udf7
CallType
udf8-15
ICM tags 1-7

123
Attributes Provided by SIP
Attributes Provided by SIP

The following table describes user defined fields (UDFs) resulting from the use of the
session-initiated protocol (SIP).
UDF Field
SIP column names
udf1
Callparty = value primary party tag (2 if none specified), SrcIP :

DstIP. (example "1 ,10.56.7.141:10.56.7.142 ")
udf2
FromNumber
udf3
ToNumber
udf4
FromName
udf5
ToName
udf6
CallRef
udf7
CallType
udf8-15
Generic tags 1-7

124
UDFs Provided in the Standard Recorder Script
UDFs Provided in the Standard Recorder

Script
The following table describes User Defined Fields (UDFs) created in the standard Unify
script. Unify interacts with the CTI server by way of the Unify script.
.
UDF Field in
Unify Script
Description
udf1
CLI (Called Line Identifier)
udf2
Extension
udf3
Agent ID
udf4
Trunk
udf5
DNIS
udf6
Direction
udf7
Call ID
udf8
Third Party
udf9
Not supplied
udf10
Queue
udf11
Not Supplied
udf12
Not Supplied
udf13
Not Supplied
udf14
Not Supplied
udf15
Not Supplied

125
Custom Data
Custom Data
Many standard attributes, such as ANI and DNIS, are stored in dedicated fields in the
legacy database. You do not need to map those attributes to particular user-defined
fields (as you can with the EWare database). However you may wish to store additional
attributes in the legacy database as custom data. The legacy Recorder may define up
to 75 possible custom data fields that may be mapped on this screen to one of the
standard attributes.
Mapping custom data is a manual process done from within Enterprise Manager.

126
Conditional Custom Data Fields

Both Impact and ULTRA Recorders support Conditional Custom Data fields, whose
values are derived from another fields value. This is done by analyzing this additional
contact information to provide more significant business information. The process does
not appear in the Recorders user interface, and cannot be configured.
Conditional Custom Data allows the tagging of contacts with additional information not
available directly from other sources, such as the CTI, but derived from the values in
other data fields. For example, an enterprise may want to tag a contact with an
indication of the line of business to which it belongs, when this data is not available
from CTI. It may be possible to determine the line of business based on the dialed
number (DNIS). In this case, a Conditional Custom Data field can be dedicated to the
Line of Business information. Users can configure rules that determine how this field
is populated, e.g., If DNIS is 1800-222555 then Line of Business is Car Insurance and
If DNIS is 1800-333555 then Line of Business is Health Insurance.
CCDFs are configured in the ULTRA Toolboxs Conditional Custom Data application.
Once configured, the values can be shared and used in both Recorder types.

127

128
Appendix
Ports Usage
The following table shows default TCP server port usage for Recorder systems
and whether they can be configured.
Server
Component
Server
Port
Configurable
?
Accept
Connections
only from
localhost?
Description
IPCapture Engine
1464
No **
No
TCP port for recorder

control clients such as
Unify, Recorder
Controller, and Live
Monitor State
7734
Yes
No
TCP port for IP Analyzer
42421*
Yes
Yes
HTTP Diagnostic Interface
1462
No **
No

Unify, Recorder
Monitor State
42421*
No
Yes
1463
No **
No

Unify, Recorder
Monitor State
42423*
No
Yes
TDM Capture
Engine
Screen Capture
Engine
Appendix A Ports Usage
Server
Component
Server
Port
Configurable
?
Accept
Connections
only from
localhost?
Description
Alarmer
50001*
Yes
Yes
Archiver
2500
Yes
Yes
Archive Media Control

Interface
Recorder
Manager
8080
Yes
No
Tomcat Web Server HTTP

port
Recorder
Manager
8443
Yes
No
Tomcat Web Server

HTTPS port
Attributes
(eWare) DB
(Oracle)
1521
No
No
Oracle Server port
Attributes
(eWare) DB (SQL
Server)
1433/
1434
No
No
SQL Server port
Workflow DB
(Postgres)
5432*
Yes
Yes
PostgressSQL Server port
Live State
3500
Yes
No
TCP port for live

monitoring applications,
such as Observer and
Web Observer
Viewer
80
Yes
No
HTTP port for Viewer

search and replay client
applications
443
Yes
No
HTTPs port for Viewer

search and replay client
applications
1430,
1431
No
No
UDP ports for receiving

RTP streams
1433
No
No
RTP Audio
1430
No
No
1431
No
No
RTP Audio
3435*
Yes
Yes
Used by the Recorder

Manager application to
communicate with the
recorder web services
Observer
Web Observer
Recorder Web
Service

130
Server
Component
Server
Port
Configurable
?
Accept
Connections
only from
localhost?
Description
Enterprise
Manager
7001
Yes
No
Weblogic Server HTTP

port
7002
Yes
No
Weblogic Server HTTPS

port
Content Server
50100
Yes
No
HTTP retrieval port
Content Server
50150
Yes
No
HTTPS retrieval port
Recorder
Controller
3082
No
No
Control and Diagnostic

port for Recorder
Controller (Unify).
eQuality Connect
Adapter V6
3020
Yes
Yes
Port has been replaced

with the Integration
Framework listening on
port 3081
Integration
Framework
3080
No
No
Adapter, Control, and

Diagnostic port for
Integration Framework.
Typically used for
AIM/Capture Service
connections to the IF.
Also used for dynamic
workstations and logons.
Tomcat
8080
Yes
No
Tomcat HTTP port for

AudioServer, Web
Observer, Adapter, and
Archive Admin
Tomcat
8443
Yes
No
Tomcat HTTPS port for

AudioServer, Web
Observer, Adapter, and
Archive Admin
Viewer/IIS
80
Yes
No
HTTP port for voice and

screen replay
applications.
Viewer/IIS
443
Yes
No
HTTPS port for voice and

screen replay applications
RSA Key Manager

Server
7443
Yes
No
HTTPS port for KMS

administration and Key
Manager Clients.
Screen Capture
Module
4001
Yes
No
Server Port for Screen

Capture engine
4004
Yes
No
Admin port

131
Server
Component
Server
Port
Configurable
?
Cisco Viewer
User configurable during install
Nortel DMS
Viewer B
User configurable during install
Accept
Connections
only from
localhost?
Description
* These ports are local to the server and do not require to be allowed on firewalls.
** While the port is configurable on the capture engines, the changed port value is not
communicated to Integration Services. Therefore, the port is configurable if integrated with
Unify. The port is not configurable when integrated with Integration Services

132
Appendix
High Availability IP
Recording Systems
This appendix provides system designers with guideline information for building
high availability IP recording systems. It presents a series of technical design
tools that designers can use to deploy high availability IP configurations.
z
TopLayer IDS Device, page 134
Link Protector, page 138
IP Recorder Filtering, page 141
Redundant Network Feeds, page 141
TopLayer IDS Load Balancing Algorithms, page 142
Recording Styles, page 146
IP Topology Examples, page 149
Wiring for IP Environments, page 158
Appendix B High Availability IP Recording Systems
TopLayer IDS Device
TopLayer IDS Device

The TopLayer IDS (Intrusion Detection System) device enables the IP Recorder to scale
and offer enhanced features when configured in a multi-Recorder configuration. The
following image shows a TopLayer IDS device:
IDS Features
- Aggregation of traffic
- Filtering by IP address and application
- Intelligent load balancing
- Policy-based traffic distribution
- Wizard-based configuration
- Stop/reset packet forwarding
The IDS device enables the formation of an IP Recorder monitor group, which can have
RTP streams load balanced among the Recorders in the group. This enables the IP
Recorders to be deployed against higher density Gateways than would not be
supported otherwise.
For example, previously if a Gateway contained 36 E1s on a single IP Address, the IP
Recorder could not have been used to carry out recording. However, by configuring
three IP Recorders into a monitor group on the IDS device, and then load balancing the
Gateway traffic to the monitor group, the Gateway can now be reliably recorded. The
following diagram illustrates this configuration.
Monitor Group
of 3 Recorders
IDS Device
Incoming SPAN,
containing RTP and SCCP
V
The key features that the IDS device makes available to system designers are:
z
Load Balancing of RTP which enables the RTP traffic to be spread across a group of
Recorders.

134
TopLayer IDS Device
Call control flooding which enables the call control protocol to be flooded to all
Recorders without the need for large amounts of SPAN resource.
Using these features enables designers to configure IP recording environments that

also derive several secondary features, which are presented in the following sections.
When using the IDS device, all 100MB ports should be explicitly set to 100MB full
duplex and not auto-sense. monitor groups must not be configured to ignore link
status, as this will result in the IDS not being able to detect a Recorder network failure.
Use of the TopLayer IDS device provides the benefits described in the following
sections.
High Density Gateways

High Density Gateways are an emerging issue within VoIP environments for recording
vendors. A High Density Gateway is defined as a Gateway containing more concurrent
channel capability than a single IP Recorder can deal with. They also provide only a
single IP address to the network infrastructure, meaning that no voice traffic
segmentation can take place at the network level.
An example is either the CMM card within a Cisco Catalyst that contains eighteen E1s
on a single IP Address (540 channels), or a 7206 VXR chassis with twelve E1s (360
channels), again on a single IP Address.
By utilizing the TopLayer IDS device, IP Recorders can be configured into a monitor
group; this acts as a Recorder cluster. When this monitor group is configured with the
weighted round robin load-balancing algorithm, the RTP streams representing the
two-way voice conversation are load-balanced evenly around the Recorders in the
cluster.
Using the monitor group ensures that no one Recorder is forced to process and record
all of the traffic for a Gateway, resulting in the capability to record high density
Gateways.
The IDS device also has the capability to flood specific traffic that it receives.
Therefore, it can easily provide all of the call control protocol to the Recorders within
the monitor group, while at the same time load-balancing the RTP streams around the
group.
Up to ten IP Recorders are currently supported in a single monitor group. This provides
a maximum of 3900 channels of concurrent recording capability.
Ten Recorders can now be supported by Unify since it is no longer a requirement for all
the individual services of a Recorder to connect to Unify. Only the IPCapture service
connects directly to the central Unify server. All of the workflow elements of the Unify
script have been moved into the IP Recorder software directly, which is capable of
acting as an autonomous box.
In Gateway-based recording solutions, where many Recorders need the same
extension configuration, it is recommended that Enterprise Manager be used to
maintain synchronization. For more information about Enterprise Manger, refer to the
Enterprise Manager Administration Guide.

135
TopLayer IDS Device
In order for the IP Recorder to successfully record a call, it must see both sides
of the call; that is, the RTP that flows in both directions. In some topologies, it
may become necessary to use the source-destination load-balancing algorithm
available within the IDS device.
Note:
N+1 Recorder Topologies

Using the TopLayer IDS device to build a monitor group of Recorders enables the
support of N+1 topologies. N+1 is achieved by providing over capacity in the monitor
group receiving traffic. For example, if the IDS is receiving traffic from a CMM blade
containing eighteen E1s, at 100% utilization, this would require five IP Recorders,
which is equivalent to 540 channels of Gateway recording. By adding an extra Recorder
to the monitor group, making it six Recorders, the monitor group can still support a
fully utilized Gateway even when one of the Recorders fails.
This use of the monitor group to provide N+1 support only protects against either a IP
Recorder power failure (assuming the network port does not remain powered) or a
network connection loss. It does not protect against a software failure, since the
network will still appear to be functioning correctly.
When an IP Recorder fails within the monitor group, the IDS device detects that the
network connection is no longer available, and it routes traffic to the remaining
Recorders within the monitor group.
Ten IP Recorders are currently supported in a single monitor group. This provides a
maximum of 3510 channels of concurrent recording capability with N+1 support.
In Gateway-based recording solutions, where many Recorders need the same
extension configuration, it is recommend that Enterprise Manager be used to keep
them all in synchronization. For more information about Enterprise Manger, refer to the
One hundred percent utilization of a Gateway is rare; therefore, resilience of
Recorder failure may be achieved without explicit over capacity, since if a
Recorder fails the traffic will be routed to the remaining Recorders. Calls that
are being recorded on the failed Recorder are likely to be lost.
Resource Scalability
Utilizing a TopLayer IDS device enables the IP Recorder to expand as the utilization of
the VoIP system expands.
For example, if a Gateway SPAN into a IDS device contained 36 E1s that only have a
maximum of 60% concurrent utilization then a monitor group containing just two IP
Recorders could be created. Once the system is expected to utilize the remaining 40%
capacity, another Recorder can be added to the monitor group without any need for
network reconfiguration.

136
TopLayer IDS Device
If the utilization of the Gateway increases before the configuration of additional

recording resource, it may result in the existing Recorders overloading and
failing.
Once the network traffic has been provided to the TopLayer IDS device and the monitor
group configured, IP Recorders can easily be added to the configuration without the
need for significant network engineering or further SPAN resource.
Added IP Recorders will need an IP address and network port for data network
connectivity, and may require updates to the Unify integration depending on
the nature of the integration
Even Resource Utilization

In both the IP and TDM environments, when recording in a Gateway or trunk-side
configuration, a common problem has been that the Recorders hard disks fill at
varying rates due to the different utilization of the trunks. This often has the knock on
effect of giving varying degrees of online availability, and the Recorder hard disk having
to being sized for the worst-case scenario.
By configuring the IP Recorders into a monitor group on the TopLayer IDS device, and
selecting the weighted round robin algorithm this problem can be over come. The
weighted round robin algorithm will ensure the calls are evenly distributed between the
Recorders, thus resulting in even hard disk usage. This means that the size of hard
disks in the Recorders no longer has to be based on the worst-case scenario for
recording, but purely the talk time of the voice source being recorded. For more
information about the weighted round robin algorithm, refer to Weighted Round
Robin on page 143.
Utilization will not be even if individual Recorders experience down time that
results in them being out of the weighted round robin for substantial periods of
time.
Less Network Traffic

The IP Recorder can deal with up to 40,000 packets per second. The TopLayer IDS
device can be used to flood only the call control protocol and load-balance the UDP.
This has the advantage of not requiring the IP Recorder to process any traffic it does
not require for recording. The goal in all configurations should be to only deliver
packets to the Recorder that are needed for recording.
If the IP Recorder is receiving traffic that it does not require (for example, when
directly taking a SPAN of a Gateway), the IP Recorder will also see the MGCP protocol
between the Gateway and the Call Manager. System and network interface level
filtering can be applied to reduce the load on the IP Recorder. This filtering takes place
at low level within the network driver and is extremely efficient. System and network
interface level filtering is configured using Recorder Manager. The use of filtering

137
Link Protector
should be considered a last resort; if possible. The TopLayer device and the network
infrastructure should be used to remove unwanted traffic.
Less SPAN Resource Required

The TopLayer IDS device has the ability to flood defined incoming traffic to any
combination of its monitor ports. This means that a single SPAN feed into the IDS
device can be used to flood the call control protocol to all ten IP Recorders within a
monitor group. This flooding capability greatly reduces the restrictions placed on the IP
Recorder by the lack of SPAN resources in the network infrastructure layer.
Flooding must be explicitly configured within the IDS device at both the
application and port level. Flooding must be avoided on anything other than
the required call control protocol.
Network Complexity Abstraction

Utilization of the TopLayer IDS device enables system designers to abstract themselves
to some extent from the complexity of the customers network topology.
Use of the TopLayer IDS device means that as long as a SPAN of the required RTP and
call control protocol can be provided, the TopLayer IDS device can perform all of the
complexity of routing to the correct IP Recorder and duplicating the call control
protocol packets to all the IP Recorders requiring the call control protocol.
If the IP Recorder requires a SPAN of a remote Call Manager server, but there is no
layer 2 connectivity, then the IP Analyzer can be used to forward call control protocol
packets through the network infrastructure to the Recorder. This means the system
designer only needs to get a basic SPAN of the Call Manager cluster to the Analyzer,
which will then deal with the delivery of call control to the IP Recorder. For more
information about call control forwarding using the IP Analyzer, refer to Call Control
Forwarding on page 46.
Link Protector
IP recording supports the use of standard link protection hardware. Shore Micro
Systems SM-2512 and SM2503 have been validated. When selecting a link protector,
we recommended that the model selected has support for power failure fail through.
An alternative supplier to Shore Micro Systems is NetOptics, which also has a range of
link protectors with various port count options.
The link protector should typically be used to build 1+1 warm standby solutions. This
warm standby could be for either the IP Recorder or the TopLayer IDS device. Where
several links into a device are to be protected, consideration should be given to
scenarios involving a single link failure, to ensure recording would continue in
accordance with the design. Features of the Link Protector are shown in the following
diagram:

138
Link Protector
Link Protector Features

- Provides automatic backup for critical equipment
- Notifies of cable cuts, disconnects, hub failures, malfunctions
- Provides immediate link failure notification via SNMP
- Controls network configuration/topology via SNMP scripts
- Simplifies network maintenance through
forced switching to hot standby
Use of link protection provides the benefits described in the following sections.
1+1 Recorder Topologies

The use of a standard network link protector enables deployment of 1+1 topologies. In
this mode, one of the IP Recorders is completely passive. If the link protector detects a
link failure between the Recorder node and the link protector, it switches the traffic to
the secondary Recorder node (Recorder Node 2 in the following diagram). This type of
solution only protects against a power failure or network failure of the Recorder.
Recorders
(one passive)
Link Protector
In the case of a power failure to the link protector, the protector should be a model that
ensures it fails through. This means that even during a power failure to the link
protector, the network path between the switch and the primary node (Recorder Node
1) stays active.
Link protectors from Shore Micro Systems have been verified. An alternative supplier
would be Netoptics.
During the fail over between the two Recorders, packet loss and failure to
record some calls is likely.

139
Link Protector
1+1 TopLayer IDS Topologies

The TopLayer IDS device is available with external dual power supply. However, if there
is a requirement to have no single point of failure in the system, a Link Protector can
be used to protect against failure of any individual link into the IDS device.
Group
of Recorders
IDS Devices (one redundant)
Link Protectors (one redundant)

Incoming SPAN,
containing
RTP and SCCP
Incoming SPAN
containing only
RTP (no SCCP)
Voice Switch
Call Manager
In the above diagram, the IDS device connected to the secondary port of the link
protector is passive. If the links fail-over together or independently into the secondary
IDS device, it will immediately proceed to either load balance the RTP or flood the
SCCP.
Each of the IP Recorders in this configuration require two network cards, so that a feed
can be taken from both IDS devices. An important difference between this
configuration and the redundant link configuration is that assuming the two input feeds
into the IDS device do not contain the same information the Recorders should never
see the same traffic twice.
If multiple feeds are provided into the IDS devices containing RTP streams, the
weighted round robin load-balancing algorithm will ensure that no one Recorder has
more than two active recordings more than any other Recorder. If the
source-destination load-balancing algorithm is in use, then it is critical that both IDS

140
IP Recorder Filtering
devices be configured identically. For more information about load balancing, refer to
TopLayer IDS Load Balancing Algorithms on page 142.
During fail-over, some voice recording is likely to be lost.
IP Recorder Filtering
IP recording contains two levels of filtering that are available to the solution designer.
This filtering takes place in the WinPCap network driver, which is extremely efficient.
However, wherever possible the solution designer should seek to reduce the number of
packets arriving at the IP Recorder NICs by ensuring only needed packets are
forwarded from the network.
IP recording allows specification of the WinPCap filter at the system level: that is, the
same filter will be applied to all enabled NICs, and at the NIC level. When NIC level
filters are used, they are appended with the system level filter if it is configured.
An example system level filter might be tcp port 2000 or udp for a Cisco-based
solution where the SCCP is transmitted on the default port number of 2000.
An example of a NIC level filter might be tcp port 2000 for a Cisco-based solution
where the CallManager cluster has been spanned into a specific NIC, and the SCCP is
the only information required from the SPAN.
When configuring system and interface level filters, care must be exercised to ensure
that they do not conflict with each other.
The filters are configured using Recorder Manager, and do not require the restart of the
IPCapture service. When reconfiguring the filters packet loss may occur during the
filter application period. Use of IP Recorder filtering allows less network traffic, as
described in Less Network Traffic on page 137. For information about configuring IP
recording filters, refer to the System Administration Guide.
Redundant Network Feeds

Redundant network feeds into the IP Recorder are fully supported. The use of
redundant network feeds enables the IP Recorder to take feeds from multiple sources
to protect against network failures.
When using duplicate network feeds, care should be taken to ensure that the IP
Recorder is not overloaded. This is because the total number of packets that an IP
Recorder can process does not increase, and duplicating the traffic into the IP recording
system will reduce the number of concurrent recordings supported by fifty percent.
The IP Recorder will support duplicate RTP packets being received. However, it does not
support the receipt of duplicate call control packets. Therefore, if redundant network
feeds are used, duplicate call control packets must be avoided.

141
TopLayer IDS Load Balancing Algorithms
The IP Recorder and Analyzer both use kernel memory when receiving packets from
network interface ports. RAM is a performance factor. If the machine has 1GB of RAM,
then four network interface ports can be enabled for recording. If the machine has 2GB
or more of RAM, then five network interface ports can be enabled for recording.
1 + 1 Network Feeds
Both the IP Recorder and Analyzer support the use of redundant network feeds. In this
configuration, the IP Recorder receives duplicate packets for calls which are taking
place. If either feed fails, the call is still recorded since the duplicate feed will still
provide the packets required. Using duplicate feeds on the IP Recorder does, however,
double the amount of traffic the server is required to handle. Therefore, when using
duplicate feeds, the overall recording capability of the IP Recorder is reduced by
exactly fifty percent.
Gateway 1
Gateway 2
CallManager Cluster
CM1
CM 2
Trunked Core
Cat 2
Cat 1
NIC1
LEGEND:
NIC2
Catalyst
Switch
Voice
V Gateway
Call
Manager
NIC3
NIC4
Compliance
Recorder
NIC5
Redundant
Network
Feeds
The IP Recorder supports a maximum of five network interfaces for recording when
2GB of physical memory is used in the server.If less than 2GB of memory is available,
then only four network interface ports are supported.

Designers can use the following three load balancing algorithms:
z
Round Robin
Weighted Round Robin

142
Source-Destination
Weighted Round Robin is used by default. If issues with regard to RTP going to different
Recorders are experienced, then Source-Destination should be used.
Round Robin
Using the balancing algorithm with three Recorders configured in the monitor group,
the following call distribution would be achieved.
Calls Active
0
Call 1
Call 1, Call 2
Call 1, Call 3
Call 1, Call 3, Call 4
Call 3, Call 4,
Call 3
0
Recorder Node 1
0
Call 1
Call 1
Call 1
Call 1, Call 4
Call 4,
Call 4,
0
0
Recorder Node 2
0
0
Call 2
0
0
Call 5,
0
0
0
Recorder Node 3
0
0
0
Call 3
Call 3
Call 3
Call 3
Call 3
0
The distribution does not take into consideration the load on any one Recorder node.
The distribution is purely based on round robin distribution to the active Recorder
nodes in the monitor group.
A call made up of several different call sections is likely to have the different sections of
the call recorded on different record nodes. During replay, it is a requirement that the
different call segments are presented as a single call, and that they can be replayed
correctly from the Search and Replay application as a stitched call.
The above only works if the two RTP flows making up the voice call are
between the same end points, and an endpoint is sending and receiving on the
same UDP port number. This requirement is usually met in the field since it
optimizes the RTP voice flow for flow-based switches.
Weighted Round Robin

Calls Active
0
Call 1
Call 1, Call 2
Call 1, Call 3
Call 3, Call 4,
Recorder Node 1
0
Call 1
Call 1
Call 1
Call 1
Call 5
0
Recorder Node 2
0
0
Call 2
0
Call 4
Call 4
Call 4
Recorder Node 3
0
0
0
Call 3
Call 3
Call 3
Call 3

143
Call 3
0
0
0
0
0
Call 3
0
The call distribution shows that with a weighted round robin, the algorithm now
considers the load on each of the Recorder nodes before routing the RTP flow in the
monitor group. This will have the effect of providing a more even distribution of calls
across the Recorders in the monitor group. This means that hard-disk space is used in
a more even manner.
A call made up of several different call sections is likely to have the different sections of
the call recorded on different record nodes. During replay, it is a requirement that the
different call segments are presented as a single call and can be replayed correctly
from the Search and Replay application as a stitched call.
Source-Destination
Calls Active
0
Call 1
Call 1, Call 2
Call 1, Call 3
Call 1, Call 3, Call
4
5

5, Call 6, Call 7
Call 3, Call 4,
Call 3
0
Recorder Node 1
0
Call 1
Call 1
Call 1
Call 1
Recorder Node 2
0
0
Call 2
0
Call 4
Recorder Node 3
0
0
0
Call 3
Call 3
Call 5, (assuming
1 finishes before 5
starts, and is
made between the
same extension
and Gateway as
1)
7
0
0
0
Call 4
Call 3
Call 4
Call 3
Call 4
0
0
Call 3
Call 3
0
This algorithm for the distribution of calls is based on the Source-Destination IP

Address, and has been specifically added to the TopLayer product to provide an
alternative to the round robin and weighted round robin load distribution algorithms
when the sending and receiving from the same port number rule is not met.
When this algorithm is used, calls to and from the same endpoint pair are always
routed to the same record node, unless one of the record nodes fails, in which case the
call would go to a different Recorder node. The round robin and weighted round robin
distribution algorithms do not apply to this mode in any way.

144
The hash of the source-destination IP address pair into a static lookup table dictates
the Recorder node to which a call is routed. This means a flow pair will always go to the
same Recorder node.
The above only works if the two RTP flows making up the voice call are
between the same end points.

145
Recording Styles
Recording Styles
The following sections detail the two main styles of IP recording: Gateway Recording
and Extension Recording. Gateway recording can be compared to Trunk-side recording
in the TDM world. Similarly, Extension Recording can be compared to station-side
recording in the TDM world. The style of recording dictates which calls are recorded,
and which segment of any call is recorded.
Gateway Recording
Gateway Recording is accomplished by spanning (that is, duplicating data streams) the
Gateway and the Call Manager Server/Cluster. If there is a requirement to record
conference calls, then the conference bridge resources - that is, all the telephones that
will participate in the conference through the conference bridge - must also be
spanned. Care should be taken to ensure that spanning the conference bridge resource
does not take the IP Recorder over it's maximum concurrent channel configuration
limitations.
The following diagram is an example of a Gateway recording solution, since the voice
Gateway and the Call Manager are SPANned.
Group
of Recorders
IDS Devices (one redundant)
Link Protectors (one redundant)

Incoming SPAN,
containing
RTP and SCCP
Incoming SPAN
containing only
RTP (no SCCP)
Voice Switch
Call Manager
Spanning the Gateway enables the Recorder to see the RTP traffic between the IP
device and the Gateway. When a conference is established, the RTP traffic flows
between the Gateway and the Conference bridge. This means that the IP Recorder

146
Recording Styles
cannot associate it with any device. This necessitates the need to span the conference
bridge. By doing this the CS IP Recorder will see the RTP streams going to and from IP
devices, and therefore will be able to record.
The SCCP only flows between the IP device and the Call Manager Server/Cluster. The
Gateway does not use the SCCP protocol, and therefore spanning just the Gateway
results in the Recorder not being able to record since it has no way of initiating the
recording. This necessitates the need to span the Call Manager Server/Cluster. Doing
this enables the Recorder to see all the SCCP packets for the entire system.
Careful consideration must be given to the use of Gateway recording solutions because
SPANning a large Call Manager cluster means that each IP Recorder is being forced to
monitor and track every call in the cluster. Fail-over configuration is an important
consideration since very often, after detecting the failure of a server/cluster, the IP
device will register with another Call Manager in the network. If this other Call Manager
is not spanned, then recording will not be possible.
Another consideration for Gateway recording is the ability to span the Gateway
channels. Currently the IP Recorder can support up to 390 concurrent recording
channels. With Gateway recording, a channel is more likely to be utilized. A Gateway
supporting more that 4 E1's worth of traffic (120 channels) via a single network port
cannot be spanned directly. A TopLayer device is required to load balance the traffic to
multiple Recorders.
Extension Recording
Extension recording is achieved by spanning the traffic to and from an IP phone, like
station-side recording in the TDM world. This can typically be achieved using either
port or VLAN spanning. Current Cisco best practice calls for IP device VLANs to be
created with up to 100 devices in a VLAN.
Spanning the IP device itself means that all RTP traffic to and from that device, as well
as SCCP traffic between the device and the Cisco Call Manager Server/Cluster, will be
received by the Recorder. In this configuration, there is no need to explicitly SPAN the
call manager or any of the conference bridge resources.

147
Recording Styles
The following diagram illustrates an example of extension-side recording since the

access switches to which the IP phones connect are directly SPANned.
IP Recorder
IP
NIC 1
RTP +
SCCP
IP
NIC 2
RTP +
SCCP
IP
NIC 3
RTP +
SCCP
IP
NIC 4
RTP +
SCCP
IP
NIC 5
RTP +
SCCP

148
IP Topology Examples
This chapter describes typical topology examples that designers can use when
deploying IP Recorder systems. Each section itemizes components required, typical
usage in the workplace, licensing requirements, and a system diagram. For more
information on configuring extensions, refer to the Enterprise Manager Administration
guide. Information is presented in the following topics:
Single Recorder Cluster, page 150
Remote Call Manager, page 152
10,000+ Phones Gateway Solution, page 154
High Availability Design, page 156

149
Single Recorder Cluster

The single Recorder cluster contains up to ten Recorders configured from Enterprise
Manager. Traffic is distributed across all Recorders. Recorder nodes are configured in a
monitor group using Weighted Round Robin for load balancing and call distribution. For
more information on load balancing, refer to TopLayer IDS Load Balancing
Algorithms on page 142.
Recorder (IP) Single Cluster Deployment

Data Network
Cluster
Integration
Service
Viewer/
Central
Database/
EM
Server
Incoming SPAN
containing
SCCP and RTP
LEGEND:
Load Balancer/
Intrusion Detection
System (IDS)
Cluster
V
Voice Switch
Recorder
Enterprise
EM: Manager
Single Recorder Cluster Components

Components in a single Recorder cluster include:
z
IP Recorder x n (1-10) per cluster
Unify x 1 per cluster
Search and Replay x 1 per system
Database x 1 per system
Enterprise Manager x 1 per system
TopLayer IDS device x 1 per cluster
Usage for Single Recorder Cluster

Typically, the Recorder cluster should be used when recording at the Gateway and is
necessary for high density Gateways. This configuration may also be used when
recording intersite links with large numbers of concurrent calls present.

150
If N+1 is required on an extension-side solution, then this configuration can also be

used. In the extension-side solution, the traffic is distributed across the Recorder
cluster.
Licensing for Single Recorder Cluster

IP Recorders configured in a cluster require a license equal to the total number of
extensions that need to be recorded. Each Recorder in the cluster must have all the
extensions that the cluster will record entered into their configuration.

151
Remote Call Manager

The remote Call Manager configuration separates the Recorder cluster from the IP
Analyzer which directs data traffic through the network to the Recorders. Each
Recorder is configured to identify all extensions that are to be recorded by the cluster.
The following diagram illustrates an IP Recorder cluster configuration that uses a
remote Call Manager. One to ten Recorder nodes are configured in a monitor group
using Weighted Round Robin for load balancing and call distribution, as described in
TopLayer IDS Load Balancing Algorithms on page 142. Here, the Analyzer is remote to
the cluster. Analyzer receives the SCCP via a SPAN and forward call control commands
to the remote cluster.
Recorder (IP) Cluster with Remote CallManager

Data Network
Analyzer
Cluster
Integration
Service
Viewer/
Central
Database/
EM
Server
Incoming SPAN
containing RTP
Incoming
SPAN
containing
SCCP and
RTP
Incoming SPAN
containing
SCCP
from Call
Manager Cluster
LEGEND:
Load Balancer/
Intrusion Detection
System (IDS)
Cluster
V
Voice Switch
Recorder
EM = Enterprise
Manager
Remote Call Manager Components

Components in a remote Call Manager configuration include:
z
IP Recorder, Cluster, or any combination
IP Analyzer x 1 per remote Call Manager Server/Cluster

152
Usage of Remote Call Manager Configuration

IP Analyzer should be used where the point of interception for the call control protocol
is remote to the location of the Gateway Recorders, and no layer two network
connectivity is available. This is likely to be the case for central dark-site systems
where the Call Manager cluster exists in a different location or is distributed.
Licensing for Remote Call Manager

The IP Analyzer is a server-based license fee. IP Recorders continue to require the
appropriate Recorder license.

153
10,000+ Phones Gateway Solution

Configurations with hundreds of thousands of extensions are known as 10,000+
Phones Gateway Solutions. Multiple IP Recorder clusters using an Analyzer per cluster
characterize this solution. The following diagram, showing cluster 2 condensed for
illustration purposes, shows an analyzer in each cluster as well as an IDS device. Each
Analyzer is configured using Analyzer Manager (a software application similar to
Recorder Manager that is built into each Recorder) with all the Recorders and their end
points for each cluster. The Enterprise Manager is used to configure and manage all
clusters. Not shown in the diagram is a monitor port containing flooded SCCP. Flooding
is described in the configuration guide for the IDS device.
Distributed/Multiple CallManager Clusters (Thousands of Extensions)

Cluster 2
Cluster 1
Incoming Call Control Commands for Analyzer in each cluster
Cluster
IS/Unify
Server
Cluster
IS/Unify
Server
Incoming SPAN
containing RTP
Search&
Replay/
Central
Database/
EM Server
LEGEND:
Cluster
Load Balancer
V
Voice Switch
Incoming SPAN
containing RTP
Data Network
EM = Enterprise
Manager
Recorder
Analyzer
Analyzer. Analyzers are configured with the Recorders and end points for each cluster.
Distributed Call Manager Components

Components in a large capacity Gateway configuration include:
z
IP Recorder, Cluster, or any combination
IP Analyzer x 1 per remote Call Manager Server/Cluster

154
Distributed Call Manager Usage

For large central Gateway solutions involving a distributed or multiple Call Manager
cluster(s), the IP Analyzer can be used to reduce the call state-tracking load on the
Recorders. By configuring the IP Analyzer with the endpoints that the Recorders are
recording, it can ensure that only call control commands relating to the endpoints
SPANNED by a particular Recorder/cluster are forwarded to the Recorder/cluster.
The system diagram shown below assumes that each cluster typically sees about 5000
extensions. By using the IP Analyzer at each site, only call control commands for the
calls that leave the call centers by the remote sites Gateways are forwarded across the
inter-site link.
Licensing for Distributed Call Manager Configurations

The Analyzer is a server-based license fee. IP Recorders continue to require the
appropriate extension licensing

155
High Availability Design

This section describes two high availability design options: a high availability IP
Recorder cluster system, and a redundant Analyzer-based system. In both cases, fault
tolerance is implicit. In the first, redundant IDS and link protector devices are used. In
the second option, a redundant Analyzer component is used.
High Availability Recorder Cluster

The below diagram illustrates a fully fault tolerant Recorder cluster containing
redundant devices (IDS, Link Protector, Voice switch and Recorder). In this
configuration, the failure of any single component will not result in the loss of
recording. The cluster has a recording capacity of 3,600 channels (9x400).
High Availability (Full Fault Tolerance) Recorder (IP) Cluster
10
Cluster
Integration
Server
Incoming
SPAN
containing
SCCP and
RTP
V
LEGEND:
Load Balancer/
Intrusion Detection
System (IDS)
Cluster
V
Voice Switch
Central
Viewer/
Archive
Central
Server Database/
EM
Server
V
Data Network
EM = Enterprise
Manager
Recorder
Redundant
Link
Protector
The cluster is designed to be fault tolerant of key elements being offline for periods,
and includes the following components:
z
Central DB, Search and Replay and EM Server: This server has no effect on
the ability of the system to record. If it is unavailable, the Recorders queue up
their recorded calls for the next time the database is available. Once the database
comes back online, the Recorders will upload their calls.
Central Archive: This server is designed to run behind real-time archiving of the
calls. The system would only be detrimentally affected if it was offline for a
sustained period, such that when it came to archive calls they were no longer on

156
the Recorders. The hard disks on the Recorders should be sized such that they can
be tolerant of the Archive system running behind.
z
Cluster Unify: In this configuration, the central Unify is utilized for providing extra
tagging such, as agent ID from the ICM, as well as connectivity to the Exec Record
services. If the Unify fails, then Live Monitor and extra tagging will be lost. Also,
any Exec Record requests will fail. If an extension is required to record even during
a Unify failure, then it should not be configured in Exec Record mode.
IP Recorder Nodes: The configuration in the diagram contains 10 Recorders, but
is specified as providing 3,600 channels of concurrent recording. This provides
spare capacity of 1 Recorder or 400 concurrent channels, meaning that the system
is tolerant of one Recorder node failure at any moment in time.
IDS device: If either TopLayer IDS device fails, the other passive device will be
presented with the links via the Link Protectors. A network port failure would result
in that individual link being activated to the redundant IDS device.
Link Protectors: If the Link Protector fails, then the network connection will be
maintained to the primary TopLayer IDS device via the protector's fail through
capability. The system is likely not to be fault tolerant of a Link Protector and IDS
device failure at the same time.
High Availability Analyzer

The IP Analyzer is supported in redundant configurations. Pairs of Analyzers can be
deployed to interpret and issue call control commands to Recorders. If either Analyzer
in a pair fails, then the remaining Analyzer will continue to send it's call control
commands. The receiving IP Recorder will ignore duplicate call control commands that
it receives from multiple Analyzers.

157
Wiring for IP Environments

Different options exist for cabling and wiring in an IP environment, where a LAN is used
for Recording, instead of a telephony infrastructure. In a TDM environment, recording
is achieved by tapping phone lines either trunk side or station side. In an IP
environment, recording is achieved by duplicating data streams, known as packet
mirroring. Here, the IP data received by telephones (IP handsets) is duplicated at a
switch such as an access switch, and then sent to the IP Recorder. This information is
described in the following topics:
z
IP Recorder Protocols, page 158
Recording Scenario Requirements, page 158
Traffic Mirroring Technologies, page 159
Common Challenges in Gateway Recording, page 161
IP Recorder Protocols
The IP Recorder records calls and screens in a VOIP telephony environment. Recording
is achieved by using 3rd party packet mirroring technology, such as Cisco SPAN, to
deliver call and screen traffic to each IP Recorder. One to five NICs in each Recorder
collaborate with the software's IP Capture engine to make the recordings. The IP traffic
(IPT) data required to record calls and screens takes the form of:
z
Real Time Protocol (RTP) - dual voice stream between handsets and voice
gateways
Skinny Call Control Protocol (SCCP, Cisco AVVID environments) - dual SCCP
packets between Cisco Call Manager Subscriber and handsets, or
Session Initiated Protocol (SIP) - dual SIP packets between handset and IPT
handler communicating SIP for handset call control.
Recording Scenario Requirements

Call and screen recording scenarios may be broken into two general areas: 1. Inbound
and Outbound, and 2. Internal.
Inbound and Outbound Call and Screen Recording

To capture and record inbound and outbound calls and screens, it is necessary to
mirror the voice traffic at the voice gateways, which provide the Real Time Protocol
(RTP) data. In addition, call control traffic (SCCP or SIP) must be captured for the
handsets that need to be recorded.
Disaster recovery and survivability scenarios may require additional planning, as there
may be other devices that provide call control in these scenarios.

158
Internal Call and Screen Recording

to capture and record internal calls, as well as Inbound/Outbound, it is necessary to
mirror the handset voice data (RTP and call control) at the local level. This is typically
achieved by mirroring the handset access switch, which provides all of the localised
traffic required.
The advantage of access switch data mirroring is that calls continue to record as long
as the handsets are active. Disaster Recovery (DR) and survivability scenarios are
naturally accounted for.
Traffic Mirroring Technologies

Switch Port Analyzer (SPAN) is a Cisco technology for mirroring network traffic for use
with analysis products such as packet sniffers and intrusion detection devices (IDS).
For the IP Recorder, this technology is used to capture and mirror local IPT data for call
and screen recording. Several SPAN methods exist, including Port SPAN, VLAN SPAN,
RSPAN and ERSPAN.
Port SPAN
A port SPAN captures and mirrors traffic on a specified switch port. This could be the
interface for a number of network devices, such as handsets or Cisco Call Managers.
This is shown in the following diagram.
Port SPAN
IP
IP Handset
Access
Switch
Handset port traffic mirrored

and sent to Recorder
LAN
IP Recorder
Most Cisco switches have limitations in terms of the number of destination ports per
switch for a SPAN (normally limited to two destination ports per switch). A destination
would typically be the interface where a Recorder resides. For more information, refer
to Cisco switch-specific documentation.

159
Conference Bridge Recording

The conference bridge, if used, also needs to be spanned. This means that data from
the recording of a conference session (that uses a conference bridge with many
participants) must be mirrored in the bridge and from each extension, and sent to the
Recorder. For example, if 5 people participate in a conference session using a
conference bridge, the traffic between each of the 5 extensions and the bridge is
recorded. In addition, traffic to and from the conference bridge is recorded, which is
why the bridge must be spanned/data mirrored.'
VLSPAN
VLAN SPAN
In most IPT environments, handset data is grouped by

using voice VLANs (Virtual Local Access Networks).
This provides separation between voice and data
networks. Voice VLANs can reside on local network
switches or be spread across multiple switches.
A VLAN SPAN captures and mirrors local switch traffic
for a named VLAN, ensuring that only relevant voice
traffic is captured for voice recording purposes. This is
shown in the following diagram:
IP Handsets
IP
Access
Switch
IP
Voice VLAN
Handset port traffic mirrored

LAN
Remote SPAN
IP Recorder
Remote SPAN, also known as RSPAN, is a Cisco

technology for capturing and mirroring traffic and
sending it to a remote destination such as another switch within the Recording
infrastructure. For example, data from a number of access switches can be
captured/mirrored and sent to a remote VLAN on another switch. This remote VLAN is
the mirrored and sent to a local interface where a Recorder resides, providing the
ability to pool data into a single location, as shown in the following diagram:
Remote SPAN
Remote
VLAN
Local traffic
mirrored and
sent to remote
destination
IP
Remote VLAN traffic mirrored

LAN
IP
IP
Layer 2
Link
IP Recorder
IP
Access Switches
IP Handsets

160
The alternative would be to run a network cable from each access switch to a Recorder,
which is limiting because each Recorder can have a maximum of 5 NICs, as well as
being high maintenance. Another limitation of RSPAN is that data cannot be
transmitted over layer 3 (routed) LAN links. This limitation is overcome with the
Encapsulated RSPAN, as described in the following section. For more information, refer
to the switch-specific Cisco documentation.
Encapsulated Remote SPAN

Cisco encapsulated remote SPAN, also known as ERSPAN, is a relatively new
technology and an extension of RSPAN. ERSPAN provides the ability to transmit
mirrored traffic across layer 3 (routed) links using network tunnel technology. In the
following diagram, Layer 3 repeater switches connect LAN segments:
ER SPAN
Remote
VLAN
Local traffic
mirrored and
sent to remote
destination
IP
Remote VLAN traffic mirrored

LAN
IP
IP
Layer 3
Routed Link
(Tunnel)
IP Recorder
IP
Access Switches
IP Handsets
Because ERSPAN is a new technology, it may be unavailable on older Cisco devices. In

particular, release 12.2 (18)SXE and later releases support ERSPAN. Refer to Cisco
documentation for more information.
Common Challenges in Gateway Recording

Common challenges in IP gateway recording include redundancy and scalability.
Fortunately, the dual objectives of ensuring backup capability and the ability to easily
expand recording capacity can be achieved by adding hardware. This is described in
z
Gateway recording with survivability, page 162
Gateway recording for more that 360 extensions, page 163
IP Data Testing, page 163

161
Gateway recording with survivability

Gateway-side recording requires call packets from the Voice Gateway(s) and the CCM
Subscriber(s) (or SIP handling device) to be delivered to the IP Recorder(s). This RTP
and SCCP/SIP traffic allows the Recorder to record all inbound and outbound calls only.
Gateway-side recording can be more complex if multiple sites are used with multiple
Call Managers, and if complex call routing is implemented. Cisco SPAN has limited
ability to send mirrored traffic across Layer 3 (routed) links in a network. This often
proves difficult if there is a requirement to send RTP and/or SCCP/SIP data to a remote
recorder, since the recorder requires both voice (RTP) and call control data (SCCP/SIP)
to record.
The diagram below illustrates a simple Gateway-side recording solution. Problems
would arise if handsets in Site 1 were using a Call Manager in Site 2, such as in a
Survivable scenario). In this scenario the Recorder in Site 1 would not receive the Call
Control (SCCP/SIP) traffic and therefore would not record.
IP Recorder
IP Recorder
Publisher
IP Handset
Subscriber
IP WAN
Subscriber
IP Handset
M
M
IP
SPAN
IP
Gateway
Voice
Voice
Voice Switch
PSTN
Site 1
Voice Switch
Site 2
The solution would be to ensure that both Recorders received all SCCP/SIP for both
sites. However, issues arise when sending SCCP/SIP traffic across layer 3 links. One
option is to introduce an Analyzer node at each site. The IP Analyzer node takes a
SPAN of the local SCCP/SIP traffic and forwards it to other Recorders on other sites,
separated by layer 3 links.
This would ensure that the site 1 Recorder is able to record calls even if another,
non-local, Cisco Call Manager (that is, the Recorder in Site 2) is used to control a call
that has been started at the site 1 Recorder local gateway.
The following diagram illustrates an IP Analyzer implementation:

162
Call Control
IP Recorder
IP Recorder
Publisher
IP Handset
Subscriber
IP WAN
Subscriber
M
M
IP
SPAN
IP Handset
SPAN
IP
Gateway
Voice
Voice
Analyzer
SPAN
SPAN
Analyzer
V
Site 1
PSTN
Voice Switch
Voice Switch
Site 2
Call Control
Another option is to implement Cisco ERSPAN, where available, to copy RTP and
SCCP/SIP traffic across the network. Because the Analyzer server is typically a
Recorder without storage media, minimal software impact is realized.
Gateway recording for more that 360 extensions

A requirement may arise when recording within
an IPT environment that has in excess of 360
gateway channels within a single cluster. SPAN
configuration becomes complex when the SPAN
destination limit has been reached (usually
limited to two destinations per switch) and/or
there is a requirement to implement two or more
IP Recorders, due to concurrently limits. In such
scenarios, it is recommended that a top layer
device be implemented. This device load
balances traffic and distributes call data to the IP
Recorders, as shown in the illustration:
IP Data Testing
Load Balancer (Top Layer device)

IPT
Data
IDS Load Balancer
LAN
Recorder 1
Recorder 2
Recorder 3
For all IP recording solutions it is recommend that the mirrored data be tested, by
means of a packet trace, to determine that it meets the requirements as highlighted in
this document. This should be done prior to the software installation as part of general
project management prerequisite procedures.
The data should be verified to ensure that it meets, but is not limited to, the following
specifications:
z
RTP data (Voice) - in both directions for all handsets to be recorded.

163
z
z
Call Control data (SCCP or SIP) - in both directions for all handsets to be recorded.
This may include scenarios where survivability functionality is used.
Data must be in a clean format, without duplicated packets.
Data must be in order - it is assumed that data will be received in an orderly
fashion and tools, such as QOS, are implemented to govern this (as per
networking best practice guidelines).
The concurrent limit (both calls and packets per second) per IP recorder must not
be exceeded.
Interfaces used for SPAN destinations for Recorder devices must be hard set to
100 MB Full Duplex.

164
Appendix
Enterprise Security
This appendix provides a brief overview of security features in the Recording
system. It is recommended that you consult the Enterprise Security
Administration Guide if your system uses security.
Recording System Overview, page 166
RSA Key Management, page 169
Appendix C Enterprise Security
Recording System Overview

The primary functions of the Recording System include recording, archiving, and
replaying of interactions between call center agents and customers for quality
monitoring and compliance purposes. These interactions are recorded as telephone
audio data and metadata, screen images of agents' desktop PC or data captured from
interactive voice response (IVR) such as customer account information. The recorded
interactions may contain customer's payment card information. Therefore, as an
integrated part of the customer's call center operations, the Recording System provides
security options to help our customers meet their security requirements such as
Payment Card Industry (PCI) compliance.
The Recording System can record telephone calls by analyzing CTI events received
from the telephony switches and/or by processing call control messages, as well as
audio data received either on the network adapter cards or voice cards of the PC. The
Recording System can also record screen images of agents' desktop PCs by deploying
Agent Capture software on agents' desktop PCs to capture the screen images and to
transfer them to recorder servers. In addition, the Recording System can archive the
recorded data on various storage devices and play back recorded data as well as live
monitor calls that are being recorded. An overview of a typical Recording System
scenario is shown below.
Call Center Premises
Switches &
IVR
Phones
CTI
Server
Data Storage
Call Centers IP or TDM Telephony Network
Storage Area Network
Witness Recording System
Recorder
Controller
Server
Recorder
Server
Replay
Server
Configuration
Server
Database
Server
Key
Management
Server
Archive
Server
Call Centers Data Network
Agents PC
System
Security
Supervisors PC
Administrators PC Administrators PC

166
Components of the Recording System include:

z
Recorder with or without Search and Replay
Standalone Search and Replay
Enterprise Manager
Enterprise Archive
AudioServer
Adapter/Locator
RSSearch
Web Observer/Observer
Attributes Database
RSA Key Manager

167
Recording System Security Features
Recording System Security Features

System security features can be configured in the recording system after the
appropriate RSA key management system license has been activated. Many of these
features are optional and configurable. The objective is to secure recorded
customer-sensitive information, such as payment card information, as well as
application authentication parameters.
Security requirements vary from customer to customer. Even for standard compliance,
such as PCI, requirements on security technology and configuration depend on the
security policies, procedures, and network configurations of each customer.
This section focuses on the security features included in the Recording System, and
how to configure them. Security administrators of call centers must decide, based on
their particular security policies, what security features need to be enabled.
Recording System security features include:
z
Optional encryption of recorded data persisted on any storage devices of the

Recording Systems using the standard AES256 algorithm and RSA Security's
Enterprise Key Manager. This also referred to as Encryption of Data at Rest.
Optional encryption of recorded media data while being transmitted over the
networks for archiving and replaying, using standard technologies, such as
SSL/TLS. This is also referred to as Encryption of Data in Transit.
Optional encryption, using standard AES256 technology, of captured screen
images, if applicable, of agent desktop PCs before transmitting these images to
screen recorders.
User account and password policies. This includes role based administrative
accounts, account lockout, password length and complexity on Enterprise Manager.
Changeable application account login credentials. This includes Windows accounts,
Database accounts, and Application Administration accounts. All login credentials
stored on hard drives are encrypted.
Configurable pass-phrase for the security token used for retrieving recorded
content from either Recorder or Archive servers.
Auditing and tamper proofing of changes to configuration parameters. Enterprise
Manager audits all configuration changes. The tamper proofing mechanism
detects, audits, and alarms users of any back-door configuration changes, namely
not via administrative UI. The tamper proofing feature is always enabled.
Optional finger printing of recorded media files. This feature allows users to verify
the integrity of the recorded data.
Successful operation in locked-down servers and networks based on the
benchmarks provided by Center for Internet Security. This includes: (1) The
documentation of a minimum list of services and protocols necessary for recording
systems, (2) Identification of the Windows Services/Privileges, protocols, and
ports required to install or run the Recording System, (3) Thorough testing in
locked-down environments, based on benchmarks published by the Center for
Internet Security.

168
RSA Key Management
RSA Key Management

The encryption of data at rest utilizes RSA Key Management software for the
generation, update, and management of symmetric encryption keys. RSA Key
Management software consists of key management server(s) (KMS) and key
management clients (KMC). An RSA key management server, or servers for scalability
and/or redundancy, serves as a centralized key management module for configuring
key policies and managing the generation, update, and archive of encryption keys. An
RSA KMS is typically deployed on a stand alone PC. RSA key management clients are
API libraries, deployed on application servers, which provide functions for
encryption-key aware applications, such as Recorder components, to communicate via
SSL with KMS, and to get and cache encryption keys. RSA KMC libraries are installed
on recorder servers by the Recorder installation program. This is shown in the following
illustration:
Call Centers IP or TDM Telephony Network
Recording
Data
RSA Key Management Server
Witness Recorder/Archive Servers
Recorder /Archiver Components
Encryption Key Database
RSA Key Manager Server
RSA Key Management Client
Encrypted Recording
Data On
Storage Devices
SSL
SSL
AES256
Call Centers Data Network
More information on RSAs Key Management software can be found in the RSA Key
Manager Server 2.0 Administration Guide and in the RSA Key Manager Installation
Guide.

169
RSA Key Management

170
Appendix
How Do I......?
How do I ... ? topics provide answers to common questions you may have about
your recording system. These topics include answers about recording with
different Data Sources and about the daily Recorder tasks you perform. In most
cases, reference is made to existing documentation. Information is described in
z
Recording with the IS, page 171
Performing Common Recorder Tasks, page 175
Data Sources Quick Reference, page 182
Recording with the IS

Recording with the Integration Service (IS) answers common How do I ...
questions you may have about using the IS to record or replay calls and
screens. IS connects with the CTI server through a CTI adapter, simplifying
communication by relaying information from the switch (the Data Source) to
the Recorder without requiring a script. Information is described in the following
topics:
z
How do I record with the Integration Service?, page 172
How do I record using the combination of IS and Unify, page 172
How do I record using only Unify?, page 172
How do I setup a Data Source for the different telecom switches?, page 173
How do I configure Station-Side Recording?, page 173
How do I configure IP Recording?, page 173
How do I configure Trunk-Side Recording?, page 173
How do I setup a Cisco Call Manager to do Duplicate Media Streaming

recording?, page 173
Appendix D How Do I......?
How do I choose between Active and Passive Recording?, page 174
How do I import into a Data Source?, page 174
How do I record with the Integration Service?

Record with the Integration Service to simplify communication between your switch
and the Recorder. You record with the Integration Service (IS) by installing a CTI
adapter specific to your switch in the Server where IS is installed. Next, use Recorder
Manager to associate the adapter with the CTI Server and the Recorder. See
Configuring IS CTI Adapters in the System Administration Guide.
Setting up IS also includes:
z
setup of Recorders and association to IS
setup of Data Sources
setup of UDF, Attributes, and Rules. Finally, you need to associate Data Sources to
IS in RM and configure CTI Adapters in RM.
In this way, IS facilitates the relay of information from the switch to the Recorder (via
the CTI Adapter) without the use of a script. See Working with Data Sources in the
How do I record using the combination of IS and Unify

You have two options for recording with both the Integration Service (IS) and Unify:
1
IS is controlling recording and Unify is adding tagging. For this mode you configure
IS for a normal CTI Controlled recording environment. Here you set Member Groups
to use CTI Controlled as the recording mode (click Data Sources > Member
Groups and choose CTI Controlled as the recording method). It is then up to the
System Integrator to tailor the Unify script to perform the tagging based on
messages received from the Recorder.
Unify is controlling recording and IS is adding tagging. For this mode you configure
the Member Groups as Unify Controlled (click Data Sources > Member Groups
and choose Unify Controlled as the recording method). It is then up to they
System Integrator to tailor the Unify script to control recording. Here, the IS
attempts to match the recordings it sees from the Recorder to the CTI events and
tag them according to settings in the UDF mapping section of Enterprise Manager.
For more information on recording modes, refer to the System Administration Guide,
and also to How do I choose the right Recording mode? on page 176.
How do I record using only Unify?

Record with Unify after connecting a CTI Server to your switch and then connecting
Unify to the CTI Server and to your network. Once these steps are followed and you
have installed the Unify software in the Unify Server, you need to use the existing Unify
script or create a new one to allow Unify to communicate with the Recorder. Basically,
the Unify script extracts call metadata from the switch (via the CTI server) and relays it
to the capture engine of the Recorder. There are no changes from previous releases in

172
Unify scripting or recording with Unify. See also How do I record using the combination
of IS and Unify on page 172.
How do I setup a Data Source for the different telecom

switches?
When you create a Data Source (in Enterprise Manager, click System > Data Sources
> Create Data Source) select your switch from the switch drop down menu and
following screen instructions. You may also refer to online help for information. To
import data for a specific switch, refer to Data Source Import Formats in the Enterprise
Manager Administration Guide.
How do I configure Station-Side Recording?

Refer to the Data Sources Quick Reference on page 182, and Call Recording
QuickStart on page 184. This assumes that you have installed and configured a CTI
Adapter card in Recorder Manager, and associated that card in Enterprise Manager.
Information is described in the System Administration Guide and Enterprise Manager
How do I configure IP Recording?

How do I configure Trunk-Side Recording?

How do I setup a Cisco Call Manager to do Duplicate Media

Streaming recording?
You can set up for DMS Recording (IP) by first typing settings into the Call Manager,
then setting up Enterprise Manager, and then finally using Recorder Manager to
complete the settings. You can find detailed procedures in the System Administration
Guide. To locate the information, refer to the guides index then locate the terms
Tutorial or Call Manager to obtain the exact page number.

173
How do I choose between Active and Passive Recording?

You can record IP calls unobtrusively by copying audio packets from the network using
passive sniffing technology. This is known as passive recording. All packets are
recorded. You can also specify start and end points for packets to be mirrored and
sniffed. This is known as Active Recording. Specify Active or Passive in General Setup
> Network Settings > Cards and Filters in RM.
How do I import into a Data Source?

Import into a Data Source by through the Data Sources tab in EM, selecting a Data
Source, and clicking Import. The import utility creates/updates the Data Source and its
associations to Installations. The elements in a Data Source depend on the type of
Data Source. For example, a phone Data Source contains phones/extensions, Trunk
Spans and members. The LAN Data Source contains Workstations and Workstation
Groups.
The import utility helps when large number of phones/extensions or workstations need
to be added to a Data Source. The import format currently available is in the .CSV file
format, where the elements of the data source that need to be created or updated in a
Data Source are included in the .CSV file
You can import the following:
PBX/ACD: Phones/Extensions, Associations of phones to Member Groups, Member
Groups (IP Extension Pool, Station Extension Group and Trunk Spans), Associations of
Member Groups to Recorders.
LAN: Workstations, Association of Workstations to Extensions, Workstation Groups,
Association of Workstation Groups to Recorders, Association of Workstations to
Workstation Groups.
Trader:PCM32 Trunk Spans
To import a .CSV file into a Data Source

1
Login to EM as a user who has privilege to create/update /Data Sources.
Click System > Data Sources. If a Data Source that you want to create already
exists, skip steps 3-6. Go to Step 7.
Click Create.
Select the type of Data Source. (Note: The import utility is valid only for Phone
(PBX/ACD), LAN and Trader Data Sources.)
Complete all necessary details such as name and description and then click Save.
With the Data Source still selected, click Import. The Import window displays.
Complete the Import window: Fill in the Name, and select Browse to browse to the
file that has the import information.
If you need to import the file at a scheduled time, select Import Using Specified
Date and Time.
Click Import. The Data Source members contained in the .CSV file will be imported
into the Data Source. If an error occurs in the import, a warning message displays.

174
To delete existing Data Source members while importing:

You can specify in the import file whether to delete and re-import, or only update the
members if they already exist, as outlined in the following table:
.CSV File
Statement
What Elements will be Deleted Before Import
Property, Reset
Datasource,
TRUE
Phones/Extensions, Member Groups (Trunk Spans, Station Extension

Group and IP Extension Pool) if the Data Source is a PBX/ACD Data Source.
In the case of a LAN Data Source, Workstations and Workstation Groups
are deleted before importing.
Property, Reset
Membergroup,
TRUE
Member Groups (Trunk Spans, Station Extension Group and IP Extension

Pool) if the Data Source is a PBX/ACD Data Source.
In the case of a LAN Data Source, Workstation Groups are deleted before
importing.
For more information on Data Source Import/Export, including formats and examples,
refer to the Enterprise Manager Administration Guide.
Performing Common Recorder Tasks

Performing regular Recorder tasks answers common How do I ... questions relating to
tasks you perform on a day-to-day basis while recording and replaying calls and
screens. This is included in the following topics:
z
How do I check the status of an export or import?, page 176
How do I choose the right Recording mode?, page 176.
How do I replay calls and screens?, page 179.
How do I access the real time diagnostic pages for IP, TDM and Screen
recordings?, page 179
How do I set up the media for archiving from different locations?, page 179
How do I record agent screens?, page 179
How do I audit my recording system?, page 180
How do I delete calls?, page 180
How do I work with UDFs?, page 180
How do I use log files to troubleshoot?, page 180
How do I Move/Add /Change Agents, Devices and Workstations?, page 181
How do I find extensions that have not been associated to any data source?, page
181
How do I find the association of Recorders to IS?, page 181
How do I implement Recorder security?, page 181
How do I set up user security privileges?, page 182

175
How do I check the status of an export or import?

Exporting and Importing functionality is available in Recorder Manager and Enterprise Manager. In RM,
you can export/import configuration files (using the Export/Import tab), audit logs, and component
logs. In EM, you can import users, export/import Data Sources, and export/import Replay Restrictions.
Check the status of EM imports by clicking the Import Status tab in Enterprise Manager. If you are
exporting, check that the file was created in the specified location. For Data Sources, If the format of
the import is not correct, the export/import will fail. For this, you need to refer to Data Source
Import Formats in the Enterprise Manager Administration Guide.
If you are checking the export/import status in a Recorder (after using the Export/Import tab), the only
method for verifying the status is by checking if the export file was created, or if data in the import file
appears in your system.
How do I choose the right Recording mode?

Depends on whether you have TDM Trunk- or Station-side Recording, or IP. Basically,
you have four Recorder Recording Modes: Record, Do not Record, Application
Controlled, and Start at Business Rule, and three primary Extension Recorder
Control Types: Recorder Controlled, CTI Controlled, Unify Controlled. Setting up
for CTI Controlled recording is described here. For other choices such as Unify or
Recorder Controlled, refer to the Integration Service Guide. Information is described in
two sections:
z
TDM RECORDING, page 176
IP RECORDING, page 177
TDM RECORDING
Record Mode
In the TDM Record scenario using Integration Service (CTI Controlled recording), you
choose the Record Recording Mode. IS then tells the Recorder when to start and stop
recording.
Recording Modes for TDM

Recorder Recording Modes
Extension Recorder Control Type
Record
Recorder Controlled
Do Not Record
CTI Controlled
Unify Controlled
Application Controlled
Recorder Channel Setting
Start/Stop on Tap = Always
Start/Stop on Tap = Never or in Fallback

176
Create your channel setting. In RM, click General > Voice Cards, and for
Start/Stop on Tap choose Never or In Fallback. (If you choose Always for this
setting, collisions occur as the Recorder and IS attempt to record the same call at
the same time).
Choose CTI Controlled. In EM, choose System > Data Sources > Member
Groups. Select your Member Group, click Edit, and choose from the Recorder
Control Type menu. For more information on Member Groups, refer to the
Choose Record as the default extension recording mode. In EM, choose

Data Sources > Phones and choose Record from the Recording Mode menu.
With these settings, IS controls recording and records every call for the extension
regardless of BR trigger.
Start at Business Rule Mode
In this scenario, a business rule cooperates with IS to tell the Recorder when to start
Recording. To learn how to create business rules and why, refer to the Integration
Service Guide.
1
Follow the steps for Record (above) only choose Start at Business Rule instead of
Record.
With these settings, IS records contacts, starting on the business rule trigger and
the Recorder records only from the BR trigger forward.
Application Controlled Mode

In this scenario, an application such as Exec Record, or Live Monitor cooperates with IS
to tell the Recorder not to delete a Recorded contact.
1
Follow the steps for Record (above) only choose Application Controlled instead of
Record.
regardless of BR trigger but deletes the recording after the call is over unless a
trigger to keep the recording has occurred. For example, a user pressing the Record
button on an Exec Record phone would save the call. As another example, BR's
would trigger the saving of the contact.
Do Not Record Mode

It is recommended that you do not use this Extension Recording Mode. Instead, disable
the channels. To do this, select the card in Recorder Manager, click the Channels tab,
and click the Disable checkbox beside the channel.
IP RECORDING
Record Mode
In the IP Record scenario using Integration Service (that is, CTI Controlled recording),
you choose the Record Recording Mode. IS then tells the Recorder when to start and
stop recording.

177
Recording Modes for IP

Recorder Recording Modes
Extension Recorder Control Type
Record
Recorder Controlled
Do Not Record
CTI Controlled
Unify Controlled
Application Controlled
Duplicate Streaming Controlled
Recorder Channel Setting

Protocol (Packet Handler) = None
Protocol (Packet Handler) = SIP or SCCP
Create your channel setting.

In IP, this is really a protocol setting. In RM, click General Setup > Network
Settings, choose a NIC, and then click Protocol. Deselect SIP and SCCP. (If you
choose a protocol, you effectively tell the Recorder to record when it detects the
protocol, and collisions occur as both the Recorder and IS attempt to record the
same call).
Choose the Extension Recorder Control Type.

In EM, choose System > Data Sources > Member Groups. Select your member
group, click Edit, and choose Record from the Recorder Control Type menu. For
more information on Member Groups, refer to the Enterprise Manager
Choose the Recorder Recording Mode.

In EM, choose Data Sources > Phones, and then choose CTI Controlled from the
Recording Mode menu.
regardless of any business rule trigger.
Start at Business Rule Mode
To learn how to create business rules and why, refer to the Integration Service Guide.
Follow the steps for Record above, only choose Start at Business Rule instead of
Record as the Recorder Recording Mode.
With these settings, IS records starting on the business rule trigger and the Recorder
records only from the BR trigger forward.
Application Controlled Mode
Follow the steps for Record above, only choose Application Controlled instead of
Record as the Recorder Recording Mode.
regardless of BR trigger but deletes the recording after the call is over, unless a trigger
to keep the recording has occurred. For example, a user pressing the Record button on
an Exec Record phone would save the call. As another example, business rules would
trigger keeping the call.

178
Do Not Record Mode

It is recommended that you do not use this Extension Recording Mode.
How do I replay calls and screens?

You can replay calls and screens (contacts) in several ways, depending on your setup.
If you have a server that has Search and Replay (Viewer) installed, replay contacts by
launching Search and Replay and starting existing queries or creating new queries. If
Search and Replay is on a different server, open up Internet Explorer and enter the URL
of the Search and Replay server (http://<servername>/Witness), then proceed as
above. If your system is down, you can replay contacts by using the Witplayer utility
installed with all Recorders. To do this, navigate to the ContactStore directory in your
PCs installations folder, and then click Witplayer.exe. You can then replay calls and
screens offline. You can also use the Vision application to replay contacts.
How do I access the real time diagnostic pages for IP, TDM and
Screen recordings?
In Windows Explorer, navigate to the ContactStore directory in your PCs Installation
folder, and then launch the diagnostics tools. With these tools you can view a variety of
details pertaining to current recording operations to help troubleshoot and diagnose
potential problems. This is described in Using the Diagnostics Tools in the appendixes
in the System Administration Guide.
How do I set up the media for archiving from different

locations?
If you want to set up media on a central server for archiving contacts from Recorders in
different locations, you need to follow procedures for Enterprise Archiving. First, you
must plan your Enterprise Archive (EA) system. Identify the server to be used as the
EA server, and identify all the Recorders to be part of the EA system. Next, install the
Enterprise Archive software on the EA server. This software is provided on a separate
installation DVD. An EA version of Recorder Manager is installed on the EA server,
showing only tabs applicable to archive management. Finally, you need to configure
the media drives to be used in the EA system, as described in the Archive section of the
System Administration Guide. You can also refer to the Enterprise Archive Installation
and Administration Guide that accompanies EA, for information on setting up
campaigns.
How do I record agent screens?

Refer to the Data Sources Quick Reference on page 182, and Screen Recording
QuickStart on page 189. First you set up a LAN Data Source in Enterprise Manager

179
then create and associate Workstations and Workstation Groups. Refer also to Setting
up for Screen Recording in the Enterprise Manager Administration Guide.
How do I audit my recording system?

In Enterprise Manager, click System > Administration > Audit Viewer to select
components to audit and time frames. If you do not use Enterprise Manager, you can
view log files in Recorder Manager by clicking System > Log and selecting Log
Viewer or Log Manager. See also, How do I use log files to troubleshoot? on
page 180.
How do I delete calls?

You cannot delete calls, as this defeats the purpose of full-time, compliance recording.
You need to wait for calls to be deleted by the system, according to settings in
Recorder Manager > Database Settings > Purge Calls data.
How do I work with UDFs?

Working with user defined fields (UDFs) is simplified since you pick and choose from
pre-populated lists. This allows you to easily identify the metadata being streamed
from the CTI server into the Recorder (either through the IS or Unify, depending on
your setup). If you are using a combination of IS and Unify, the Unify scripter must
ensure that the Unify script does not overwrite the fields being created automatically
by the IS. In the UDF Mapping window you can add and delete attributes. In fact, if you
are using IS, 3 additional UDF fields (14, 15, and 16) become available, allowing
additional functionality.
Refer to the Integration Service Guide for a detailed description of UDFs and their
purpose. If you do not use Enterprise Manager, refer to the appropriate section in the
System Administration Guide.
How do I use log files to troubleshoot?

In Recorder Manager, choose System > Logs > Log Viewer. In this window you can
select components, time periods, and error severity levels to view all logged errors and
incident messages logged by this Recorder. You can then view all the messages for one
severity level and base troubleshooting on this. You can also load different log
reporting mechanisms (that is, different log .xml files) so that your Recorder will create
different error logs and messages. To do this, click System > Logs > Log Manager.
In Enterprise Manager, you can view audit logs for selected components and times.
Click System > Administration > Audit Viewer to generate a customized audit log
for a specific component or time. Audit logs do not show errors, however; to view
errors, click System > Log.

180
How do I Move/Add /Change Agents, Devices and

Workstations?
Use the People Profiles window to easily assign agents and phones. Select an agent in
the left pane and view their work assignment(s) in the right (Data Sources) pane. This
area shows all Data Sources in your recording system, and any Agent ID and
associated extension(s). To move and change phones for an agent, simply edit the
Agent mapping in the Agents window. For large numbers of agents, use the Find
feature in the People window. This is located above the list of agents in the People
window. You can even select a Filter to narrow the search.
If a selected agent does not show an Agent ID or extension, you must create them. To
create Agent IDs, click the Agent tab in either a Phone or LAN Data Source, select the
employee and type an ID according to your organizations policies. To assign an
extension, click the Agent Mapping button (remember to always select the Data
Source), and choose from the list. For a Trader switch, Agent IDs are not required. You
can assign Agent IDs and Extensions in the People tab based on whether it is Free
Seating (type only the Agent ID), Fixed Seating (type only the extension number) or
Hybrid (both Agent ID and extension).
Add and change Workstations by selecting a LAN Data Source and clicking
Workstations. In the Workstation window, you select one or more Extensions from a
Phone Data Source, optionally specify a Workstation Group (recommended).
Workstations do not move. Instead, agents and phones are assigned or reassigned to
Workstations. For large numbers of Recorders, you can create Workstation Groups to
save time, by selecting two or more Recorders. For more information, refer to
Configuring Data Sources in the Enterprise Manager Administration Guide.
How do I find extensions that have not been associated to any

data source?
Click the People tab, select an employee, and review the Data Sources section of the
window. If the employee is not associated to a Data Source, nothing shows here. Then
you can refer to How do I Move/Add /Change Agents, Devices and Workstations? on
page 181.
How do I find the association of Recorders to IS?

In Enterprise Manager click System > Installations and select a Recorder. Click
Associations to view the mapping of Recorders to Integration Service servers.
How do I implement Recorder security?

Setting up security in a recording environment, while far from a trivial configuration
task, involves setting up Enterprise Manager, then Recorder Manager, then visiting
each PC or Server to which security is to be applied. First, in EM you select the
Enterprise, Site Group or Site and apply security settings to all Recorder and Search
and Replay installations in the selection. Do this in the Installations > Security tab in

181
Enterprise Manager, as described in the Enterprise Manager Administration Guide. To

see this tab, you need the requisite user privileges.
Next you can set up archive Encryption and Tamperproofing options in RM in each
Recorder. This is described in the System Administration Guide. It is recommended that
you locate the guides Index and go to the Security entry to locate the specific pages.
Finally, you must set up security on individual PCs and Servers. At each individual PC
and Server, you install security certificates, tokens and keys, all managed by RSA key
manager, so that all data is encrypted or uses Secure Socket Layer (SSL). This process
is described in detail in the Enterprise Security Administration Guide.
How do I set up user security privileges?

You can quickly set up one or more system administrators with superuser security
privileges by following these steps:
1
Click the People tab and create a user profile. You must enter at least a first and
last name.
Click the User tab, and type a username, password, and account status for the
user.
Click the Access Rights tab, and complete fields as follows:
For Role name choose Enterprise Manager Administrator. This assigns a role
with the necessary security access privileges for all Recorder configuration
functions (modules).
For Organization Scope, click Users Current Organization. This provides access
that will allow you to configure all RMs and EMs in the organization.
For Installation Scope, check the Enterprise level.
Click Save.
To restrict user access to Recorder configuration functions, you can limit user security
privileges. To do this, you need to choose an appropriate role from the Access Rights
window. The Access Rights window lists all available roles and their applicable
functions/modules. You then have to assign an organization and group scope to the
role. If you wish the user to have installation privileges, you need to additionally select
an installation scope.
You can also create new Roles. To create Roles additional to those showing in the
Access Rights tab, follow these steps:
1
Click App Admin > Security.
In the Roles Setup tab, click Create New Role or select a role and click Edit
Existing Role.
Follow procedures as described in help, or in the Creating Roles and Privileges

section of the Enterprise Manager Administration Guide.
Data Sources Quick Reference

This quickstart describes the steps you need to follow to configure Recorder Manager
(RM) or Enterprise Manager (EM) for initial use with the Integration Service (IS) using

182
Data Sources. Each type of recording scenario (that is, trunk-side, station-side, and IP
recording) has similar setup requirements, except that with TDM recording, you need
to associate voice cards and channels to Recorders. All recording scenarios require
that:
z
RM and the Integration Service component are installed on all Recorders
Voice Cards (TDM) and NICs (IP) are installed and configured on all Recorders.
EM is installed and used to administer the Integration Service.
The necessary licenses for screen or call recording have been obtained and are
installed.
In the following steps, it is assumed that the Recorder has RM installed in one or
multiple PCs but is not yet configured, and the correct path to the EM Server was
entered during installation. This allows the EM to recognize and communicate with the
RM. If you did not enter a correct path at installation, see the General Notes on
page 191.
For more information on CTI Adapter configuration for RM, refer to the Configuring CTI
Adapters chapter of the System Administration Guide. For more information on Data
Sources for EM, refer to the Data Sources chapter of the Enterprise Manager
Information is presented in the following sections:
z
Call Recording QuickStart, page 184
Screen Recording QuickStart, page 189
General Notes, page 191

183
Call Recording QuickStart

This quickstart provides the general steps needed to perform call recording using Data
Sources and the Integration Service. For a more information on trunk-side and
station-side recording wiring, refer to diagrams in the Installation Guide. For more
information on IP recording, refer to the Infrastructure Guide.
To configure call recording in EM:

Perform the following steps from Enterprise Manager. All References are to sections in
the Enterprise Manager Administration Guide. In this guide you will find a description of
all information you need to type, as well as detailed procedures you can follow.
1
Log in to EM. Login to EM using the username and password as provided in the
Installation Guide.
Create a Site. Click System > Installations, select Enterprise or a Group Site and
then click Create.
Create a Recorder. Select the site you just created, and then click Installations >
Create Installations > Server.
Create an IS server. Select the site you just created, and then click Installations >
Create Installations > Server. If IS is installed on the server, then IS becomes a
role.
Associate the Recorder to IS. Select the Recorder you just created, click
Associations, and then select the IS server to be associated with the Recorder.
Create a Data Source. With the Recorder still selected, click System > Data
Sources > Create Data Source > Phone, complete the fields, and then associate the
Data Source to the IS by clicking Manage IF Association.

184
Create a Telephony Group (Member Group). Select the Phone Data Source you
just created, and create a Member Group, according to your recording environment,
by clicking Member Group > Create, as follows:
For Trunk-Side Recording, create a Trunk Span group.
For Station-Side Recording, create a Station Extension Group.
For IP Recording, create an IP Extension Pool group.
NOTE: Make sure you select a Phone (PBX/ACD) Data Source. If

you select a LAN Data Source, the Member Group tab does not
display.
8
Associate the Telephony Group to a Recorder. While in the Member Group area
double-click the telephony group or select it and click Edit, click Manage Recorder
Association and assign the group to one or more Recorders. Assign by choosing
one or more Recorders and then clicking Assign.

185
Create Extensions. While in the Member Group area with the group selected, click
Manage Extensions, (for IP telephony groups) or Generate Members (for TDM
groups), selecting or creating extensions to be included in the Member Group, and
then clicking Assign.

186
10 Setup Agent IDs, VDNs, Hunt Groups, etc, if needed. Click Data Source Groups
and then create new Data Source groups specific to your switch.
11 Assign Agent IDs and Extensions. Select your Data Source and then click Agent
> Add Agent Mapping or Phones > Create or Create Range, and complete these
windows to create Agent Login IDs and phone extensions respectively. Create
phones here only if you did not create extensions during the telephony group
creation process.
You are done with setting up for call recording in EM.
To configure recording in RM:

Perform all the following steps from Recorder Manager. All References are to sections in
the System Administration Guide.
1
Log in to RM. Login to RM using the username and password as provided in the
Installation Guide.
Configure the Recorder. Setup basic Recorder tasks such as archive and database
settings. See Configuring Common Components.
Set up the IS. Choose a CTI Adapter that matches your switch by clicking System
> Integration Service > Settings > Create. See the Configuring CTI Adapters
chapter.
NOTE: If the Integration Tab does not display, then the Integration Service was not
installed on your Recorder. You can check the Server Role in EM (System > Installations >
Settings). You may need to reinstall the service.

187
Create Custom Attributes. While in the adapter window, click Custom Attributes
and type the necessary information for the attributes to adapter mapping, as
described in the Configuring Adapter Custom Attributes chapter.
Associate Voice Cards. In the Voice Card properties page (TDM Recording only),
associate voice card(s) to the Data Sourc/Member Group, and then save the card.
Assign Channels. Click Channels (TDM Recording only) and review extensions
created earlier in the Data Source, and then click Save.
Restart servers. Click Operations > Start and Stop to restart RM(s).
You are now ready to record

188
Screen Recording QuickStart

The screen recording quickstart describes the steps for setting up for screen recording
using Data Sources and the Integration Service (as opposed to using Unify scripts).
You set up a LAN Data Source to allow the capture of screens from workstations. You
then set up Workstation Groups, then Workstations within the groups, and then
associate the Workstations with the Groups and with Recorders.
To configure screen recording in EM:

1
Log in to EM. Login to EM using the username and password as provided in the
Installation Guide.
Create a LAN Data source. Create a Site, Recorder, and Data

Source as described in the Call Recording Quickstart, only choose
LAN instead of Phone, (that is, click System > Datasources >
Create Data Source > LAN).
Create a Workstation Group. Select the LAN Data Source you

just created, then click Workstation Groups > Create and type
General Settings and Capture Settings for the Workstation Group.
These settings apply to all Workstations in the Workstation Group.
Assign the Workstation Group to a Recorder. With the Workstation Group you
just created still selected, click Manage Recorder Association (to open the
Recorder Association window), and then check all Recorders to be assigned to the
Workstation Group and click Save.

189
Create Workstations. With the Workstation Group still selected, click Workstations
> Create. Create new Workstations and assign them to the Workstation Group you
just created.
Assign Workstations to Workstation Groups. Select the Workstation Group you

just created, click Workstation Group and then click Manage Workstation. Select
all Workstations to be assigned to the Workstation Group, and then click Assign.
You can also Unassign Workstations in this window by clicking Unassign.
Create Workstation Phones. If you need to associate the workstation with a

telephone, click the Phone Data Source specified while creating the Workstation,
and then choose an extension.

190
Associate the Workstation to the Phone
If you are setting up Attributes, UDF Mapping and Rules, click the corresponding tabs
under System and follow screen instructions or click Help.
You are done with setting up the LAN Data Source for screen recording.
General Notes
z
If you did not type the correct path to the EM server at install, you can manually
configure the Recorder to EM relationship. Do this by editing the
configmanager.xml file under the config table in the Tomcat folder. Complete
the edit by changing EMSERVER to the server name used, and then restarting
Tomcat. You can find the IP address and port number of the EM by clicking System
> Administration > EM Location.
When the Integration Service is used to create extensions, then extension
management by Recorder Manager is disabled.
Although it is recommended that EM be installed on a separate server from RM, an
exception can be made for an installation on a Single Server solution that uses the
IS. Although the EM is not needed for controlling a single Recorder, it is necessary
for managing the IS.
A different set of tabs appears when you select a LAN Data Source than when you
select a Phone (PBX/ACD) Data Source. For example, the Workstation tab does not
display when you select a Phone Data Source and the Phones tab does not display
when you select a LAN Data Source.

191

192
Glossary
Term
Definition
ACD
Abbreviation for Automatic Call Distribution. A system used to

distribute calls placed to a call center to Agents when they are
free. The system manages customer queues to make this process
as efficient as possible. Unlike a PBX, there are more inbound
telephone lines than Agents. The switch is typically non-blocking
in that any call can be routed to any agent.
Agent
Any person who receives or makes contact with customers or

prospects on behalf of an organization in a customer interaction
center environment. Agents receive contacts via telephone,
e-mail, and web interactions with customers, and are usually the
first point of contact with customers.
Business Rule
A simple or complex logical statement, which determines the

action to occur when a set of defined attributes and conditions
are met for a customer interaction to become a Contact. Contacts
are used to play back, annotate, and evaluate agent performance
to achieve business goals and professional development.
Business rules can be as simple as recording contacts, which
occur on scheduled days of the week, or when a specific event
happens. They can be as complex as including many AND/OR
statements in a logical structure.
Capture Engine
A software component in all Recorders forming part of the

Recorder subsystem. that interfaces with the TDM telephony
infrastructure or IP Telephony network infrastructure to capture
and record the audio/video contents plus associated or
non-associated metadata of a customer Contact. A Capture
Engine can be either a TDM type (eRecorder) or an IP type
(IPCapture).
Content
Server/Retriever
See Retriever/Content server.
Data Source
A term for any source of recordable data or agent state

information that an integration in the Integration Service will plug
into, such as a customer's switch, capture system, or
e-mail/e-mail integration system.
Glossary
D-Channel
Recording
A non-CTI voice recording method that uses one of the 24

channels included on T1/E1 ISDN lines and digital extension taps.
D-channel recording is different for Trunk-side and Station-side
recording: one is a data channel for the PRI lines on the inbound
trunks coming into the PBX (23B channels +1D channel) and the
other (Station-side recording) is the data channel that the PBX
uses to send the data to the phone set display.
DNIS
Dialed Number Identification Service. A feature of 800 and 900

lines that provide the number that the caller dialed to reach the
attached telephony system. The switch uses the DNIS to route
calls to the appropriate agent or groups of agents.
DTMF
Dual Tone Multi Frequency, the mechanism of using dual tones to

identify the keys pressed on a telephone set.
DTMFDigits
A call data attribute that indicates the MTMF digits that were
pressed during the call. These digits could have been pressed by
either party. This attribute is often used when the line itself does
not encode called party information, so that the DTMF digits are
use to determine who the agent was calling.
Duplicate Media
Streaming
A means of recording telephone calls by having the phoneset

duplicate the packet streams it is receiving and transmitting
sending the copies to a specified IP address (the Recorder).
Enterprise
Manager
A software enterprise management tool that allows you to control

all aspects of recording and workforce optimization within an
organization, such as adding workers and setting up sites and
recorders. The Enterprise Manager is connected to, and can
control, all recorders within the enterprise by interfacing with
each Recorder Manager.
Extension
The telephone extension or line used by the party to be recorded

or monitored.
Full time
recording
Telephony term for recording the majority of contacts rather than

"selective" recording. "Full time" replaces the term compliance
recording as many users wish to record all of their contacts even
though there is no legal requirement. The term also replaces
"100%" recording in that in reality even in a large-scale recording
system there are extensions that are not to be recorded or only
parts of calls that are to be recorded due to security or business
requirements. In addition, in Full-time Recording the recorder
monitors a fixed set of lines as defined by its configuration. The
delivery of Full-time Recording is primarily through passive tap
techniques because it does not require expensive switch
resources as the number of recording channels increases.
HTTPS (also
S-HTTP)
Abbreviation for secure Hypertext Transfer Protocol. This is the

same protocol as HTTP except it is encrypted to allow security,
requiring a digital key to encrypt and decrypt HTTPS packets.
Usually used with the Secure Socket Layer (SSL) enabling of web
servers.
Integration
Service
A system of hardware and software devices that integrates

third-party data sources (such as switches) and drives in the
recording subsystem with content and state information.

194
Glossary
INum
A unique eWare database content identifier, typically identifying

contact file names, generated on each Recorder, consisting of 15
decimal digits of which the first 6 are the Recorder's serial
number and the rest are sequentially incremented by the
Recorder as new contacts arrive, such as 600001000000001,
where 60001 is the Recorder serial number and 000,000,001 is
the incremented number. Each Recorder can generate a billion
unique INUMs before it must assume a new serial number.
Content identifiers are different on Recorders that do not use
eWare databases.
IP Analyzer
An optional hardware component used in some IP recording

environments to analyze call control messages on the attached
network and forward recording control messages to remote
recorders.
IP Recording
A type of contact recording system where the capture engine

detects (that is, sniffs) voice signals in a data network using the
Internet Protocol of packets of information in a virtual envelope
(VoIP), as opposed to TDM channel recording.
Live Monitoring
An application that enables users with authority based on their

roles to observe both sides of the agent-customer interaction.
Users can see and hear a contact in real time, while the
interaction is actually taking place.
Local Archiver
A software component in all Recorders that archives a Contact's

audio and video content plus associated metadata to a removable
storage media, such as a DVD or tape. Local Archiver is part of
the Recording Subsystem.
Observer
A thick-client Visual Basic application, related to the thin client

Web Observer application, used to live monitor Contact(s).
Passive Tap
Recording
A method of recording the voice portion of a contact from the

incoming trunk (T1 line) between public switching and the PBX.
This process is implemented by placing a junction box on the
inbound T1s. There must be one junction box per T1 to be used
for trunk-side recording. For example, to monitor five trunks, five
junction boxes are needed.
Passive Tap
Station-Side
Recording
A method of recording contacts between the switch and a phone

by tapping into the line that connects the switch to the telephone
punch-down block, using a Y-cable so that each extension
connects directly to a port on the voice card.
Passive Tap
Trunk-Side
Recording
A CTI method of recording voice data directly from an incoming

trunk (T1 or E1 line) between public switching and a PBX,
allowing the recording of every call that comes into the PBX on
the tapped trunk.
PBX
See Private Branch Exchange.
PCM32
Abbreviation for Pulse Code Modulation 32. PCM32 is a

transmission system with a 2048 KB/s rate. All 32 channels are
available for voice transmission. In the voice recording market,
this is primarily used by trading systems as a link from their
switch to the voice recorder.
Private Branch
Exchange (PBX)
A PBX is a telephone switch owned privately, usually by a large

company. If it owns a PBX, a company does not need to lease a
telephone line for each telephone set at a site

195
Glossary
Punch-Down
Block
A wiring device used in telecom environments to connect wires

between the switch and the telephone. It creates a junction point
for connecting additional devices to the same set of wires without
disconnecting the phone.
Recorder Manager The software management tool installed locally on every Recorder
that allows you to control all aspects of the Recorder, such as
setting up media devices and managing voice cards. Each
Recorder Manager within an organization connects to, and can be
controlled by, the Enterprise Manager.
Retriever/Content
Server
A software component in Recorders that retrieves recorded

content from the Recorder's storage media, such as hard drives,
DVD disks, or tapes, after an HTTP-based request from
applications, such as search and replay, has been made.
SCCP
Abbreviation for Cisco's Skinny Call Control Protocol, which is a

proprietary protocol used between Cisco Call Manager and Cisco
VoIP phones that defines a simple and easy-to-use architecture
for transporting data packets by using the phone as the thin (i.e.
skinny) client over IP in the context of H.323.
Screen recording
The term used for the capture of a graphical representation of

what was displayed on the Agent's PC or other terminal screen
within the Call Center. When the screen recording is replayed by
the Supervisor, the screen activity is played like a movie of the
screen. Not all data is captured in order to reduce the bandwidth
of the recording. Various schemes are used to capture only those
areas of change.
SIP
Session Initiated Protocol. SIP is a standard, multi-media protocol

for setting up, modifying, and terminating VoIP connections that
operates at the application layer to negotiate reliable VoIP
channels.
Station-side tap
Term used to indicate passive tapping of the user phone lines or

extensions, rather than the incoming phone lines from the Public
Switched Telephone Network (PSTN) to the PBX or ACD.
Station-side
Recording
In passive tap-station-side recording, information is recorded

between the switch and an extension itself. This is done by
tapping into the line leaving the switch (PBX) to the telephone
punch-down block (as opposed to trunk-side recording, which
taps lines coming from the PSTN).
TDM
Abbreviation for Time-Division Multiplexing. In TDM, data

streams are assigned different time slots on a single channel,
which distinguishes TDM from other types of multiplexing.
Trunk
A single circuit or channel from a PBX to a carrier (for example, a

T1 has 24 trunks). As a business rule attribute, this name
identifies the specific circuit or channel being used in an external
call.
Trunk Span
A group of related trunks that all form the same connection.

Unlike a single trunk, a trunk span can conduct multiple
exchanges of data simultaneously. A trunk span is used when
high bandwidth is required.
Trunk-side
Recording
A method of recording information from the incoming trunk (T1

line) between public switching and the PBX.

196
Glossary
UNC
Uniform Naming Convention. A format for specifying the location

of resources on a local-area network. UNC uses this format:
\\server-name\shared-resource-pathname
For example, to access the file test.txt in the directory
examples on the shared server silo, you would write:
\\silo\examples\test.txt
You can also use UNC to identify shared peripheral devices, such
as printers. The idea behind UNC is to provide a format so that
each shared resource can be identified with a unique address.
VoIP
Voice Over Internet Protocol. This is a technology used to

transmit voice conversations over a data network using the
Internet Protocol of data packets of information in a virtual
envelope.
VOX
Voice Operated Transmitter. This term refers to the method by

which the Recorder detects that a call has begun (that is,
tap-sense). The VOX method "listens" for voice on the line rather
than using signaling information.
Web Observer
Web based thin-client application, related to the Observer thick

client application, used to live monitor contact(s).

197
Glossary

198
Index
H.323 . . . . .
Passive Recording
recording calls . .
tagging calls . .
A
additional resources . . . . . . .
administration server . . . . . .
Ai-Logix
voice card attributes . . . . .
alarming component . . . . . .
analyzer
high availability configuration .
10,000+ phones use . . . . .
application
SNMP . . . . . . . . . . . .
architecture
administration server . . . . .
configuration . . . . . . . .
ContactStore Plus . . . . . .
disk management . . . . . .
live monitor . . . . . . . . .
retriever . . . . . . . . . . .
archive
centralized archiving . . . . .
devices supported . . . . . .
local . . . . . . . . . . . .
parallel archiving . . . . . . .
permitted drives . . . . . . .
sequential archiving . . . . .
tape drives . . . . . . . . .
verify media . . . . . . . . .
Associated . . . . . . . . . . .
associated call data, capturing . .
audioserver, web observer . . . .
auditing . . . . . . . . . . . .
auto-detecting voice cards . . . .
Avaya . . . . . . . . . . . . .
configuring with CTI . . . . .
configuring without CTI . . .
DataSource . . . . . . . . .
. . . . . . . . . . 14
. . . . . . . . . . 83
. . . . . . . . . .121
. . . . . . . . . . 75
. . . . . . . . . .157
. . . . . . . . . .154
. . . . . . . . . . 75
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 34
. 52
. 30
. 31
. 30
. 31
. 30
. 31
. 56
. 56
. 87
. 67
. 54
.111
.114
.115
.115
83
74
88
78
85
76
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 111
. 111
. 112
. 113
B
Balance replay . . . . .
BDR server . . . . . . .
business decision rules
as selective recording
Contactstore Plus . .
. . . . . . . . . . . . . . 89
. . . . . . . . . . . . . . 89
. . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . 89
C
calculated custom data (See conditional custom data) . 127
call buffer . . . . . . . . . . . . . . . . . . . . . 32
call data
associated and non-associated . . . . . . . . . . 118
associated, capturing . . . . . . . . . . . . . . 56
Call Manager, remote recorder cluster . . . . . . . . 152
capture engine . . . . . . . . . . . . . . . . . . . 86
CASS idle codes . . . . . . . . . . . . . . . . . . 64
CCD. See conditional custom data . . . . . . . . . . 127
CCE control . . . . . . . . . . . . . . . . . . . . 64
centralized archiving . . . . . . . . . . . . . . . . 34
CIC . . . . . . . . . . . . . . . . . . . . . . . . 15
Cisco Call Manager . . . . . . . . . . . . 99, 100, 106
Cisco Call Recording
DMS . . . . . . . . . . . . . . . . . . . . . . 100
Cisco DMS . . . . . . . . . . . . . . . . . . . . . 100
cluster
remote Call Manager . . . . . . . . . . . . . . 152
single recorder . . . . . . . . . . . . . . . . . 150
collaboration recording scenario . . . . . . . . . . . 72
component
call buffer . . . . . . . . . . . . . . . . . . . . 32
Index
configuration, status, and alarming

disk manager . . . . . . . . . .
live monitor . . . . . . . . . . .
conditional custom data . . . . . . .
conference bridge recording . . . . .
configuration
architecture . . . . . . . . . . .
components . . . . . . . . . .
SNMP . . . . . . . . . . . . .
status and alarming component .
Connectivity . . . . . . . . . . . .
connectivity . . . . . . . . . . . .
consolidator . . . . . . . . . . . .
ContactStore Plus
Balance replay . . . . . . . . .
streaming retriever . . . . . . .
ContactStore Plus, architecture . . .
controll fallback . . . . . . . . . .
conventions used in this guide . . . .
CTI server . . . . . . . . . . . . .
CTI-driven events . . . . . . . . . .
CTI-initiated contacts, capturing . . .
custom data . . . . . . . . . . . .
Customer Interaction Center . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 75
. 32, 78
. . 86
. . 127
. . 160
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 89
. . 90
. . 88
. . 57
. . 12
. 27, 50
. . 61
. . 56
. . 126
. . 15
.
.
.
.
.
.
.
74
74
75
75
50
50
32
D
data sources, types . . . . . .
database
calls and media . . . . . .
configuration . . . . . . .
D-channel . . . . . . . . . .
DDS5 Tape Drive . . . . . . .
delete by date . . . . . . . .
deployment
enterprise . . . . . . . .
multi-node . . . . . . . .
single-node . . . . . . . .
diagnostic tools . . . . . . .
disaster recovery . . . . . . .
disk management architecture .
disk manager. . . . . . . . .
disk partitioning . . . . . . .
disk subsystem hardware . . .
DMS . . . . . . . . . . . .
Call Recording Scenarios . .
Cisco . . . . . . . . . . .
Load Balancing . . . . . .
load balancing, Cisco . . .
load balancing, Nortel . . .
Nortel . . . . . . . . . .
Recording Invocations . . .
recording scenarios, Cisco .
. . . . . . . . . . . 35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
81
63
30
32
. 45
. 44
. 42
. 179
. 30
. 78
. 78
. 80
. 80
99, 100, 106
. . 102, 107
. . . . . 100
. . 105, 110
. . . . . 105
. . . . . 107
. . . . . 106
. . 101, 107
. . . . . 102
recording scenario, Nortel . . .

duplicate media streaming. See DMS
DVD-RAM, DVD RW, +/-, 4.7 GB . .
dynamic workspaces . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . 45
21, 66, 84
. . . 161
. . . . 73
. . . . 42
. . . 147
. . . 122
107
100
. 31
. 91
E
enterprise deployment . .
Enterprise Manager . . .
ERSPAN . . . . . . . .
eWare 2CC module . . .
express deployment . . .
extension recording . . .
E1/T1 voice card attributes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F
failsafe procedures, archive . . . . . . . . . . . . . . 34
fallback feature . . . . . . . . . . . . . . . . . . . 64
file locations . . . . . . . . . . . . . . . . . . . . 80
G
gateway
high density . . . . . . . . . . . . . . . . . . 135
recording . . . . . . . . . . . . . . . . . . . 146
10,000+ phones . . . . . . . . . . . . . . . . 154
H
How do I ...
Active versus Passive recording . . . .
agents and workstations, work with . .
audit . . . . . . . . . . . . . . . .
calls, delete . . . . . . . . . . . . .
check import/export status . . . . . .
choose a Recorder Control Type . . . .
choose a recording mode . . . . . . .
Cisco Call Manager, DMS recording . .
contacts, replay . . . . . . . . . . .
data sources, different telecom switches
data sources, import . . . . . . . . .
Enterprise Archive, set up for . . . . .
find Agents not associated to an IS . .
find Recorder associations to IS . . . .
Integration Service, record with . . . .
IS and Unify, record using both . . . .
record station-side content . . . . . .
record trunk-side content . . . . . . .
recording events, view . . . . . . . .
record, IP content . . . . . . . . . .
screen recording, set up . . . . . . .
security, system . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
174
181
180
180
176
176
176
173
179
173
174
179
181
181
172
172
173
173
179
173
179
181

200
Index
troubleshoot with log files

UDFs, work with . . . .
Unify, record with . . . .
HP DAT72 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 180
. 180
. 172
. 30
round robin . . . . .
source-destination . .
weighted round robin
logging . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
143
144
143
. 80
IDS load balancing algorithms . . . . . .

implementation
CTI Servers . . . . . . . . . . . . .
network operating system . . . . . .
physical connectivity . . . . . . . . .
voice cards . . . . . . . . . . . . .
implementation of TDM Recorder . . . .
Intelligent Call Control Distribution . . . .
intended audience . . . . . . . . . . .
interfaces
live monitor . . . . . . . . . . . . .
live monitor control . . . . . . . . .
live monitor state . . . . . . . . . .
recorder state . . . . . . . . . . . .
streaming . . . . . . . . . . . . .
intrusion detection system (IDS), TopLayer.
inum . . . . . . . . . . . . . . . . .
Iomega REV drive . . . . . . . . . . . .
IP Analyzer . . . . . . . . . . . . . . .
IP routing . . . . . . . . . . . . . . .
. . . . . . 142
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 86
. 86
. 86
. 86
. 86
. 134
. 76
. 30
. 46
. 48
50
50
50
51
50
46
10
K
key management. See RSA key manager . . . . . . . 169
L
license validation . . . . . .
line voltage . . . . . . . .
link protector
1+1 recorder topologies .
1+1 TopLayer topologies .
live monitor
architecture . . . . . . .
capture engine . . . . .
ContactStore Plus . . . .
description . . . . . . .
interface . . . . . . . .
observer . . . . . . . .
state component . . . .
state interface. . . . . .
streaming interface . . .
web observer . . . . . .
live monitor control . . . . .
live monitor state interface .
load balancing
. . . . . . . . . . . . 54
. . . . . . . . . . . . 64
. . . . . . . . . . . . 139
. . . . . . . . . . . . 140
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
86
89
85
86
87
87
86
86
87
86
86
Manager . . . . . . . . . . . . . . . . . . . . . . 66
MediaStore recorder . . . . . . . . . . . . . . . . . 73
N
network operating system
network topology . . . .
non-CTI-driven events . .
Nortel DMS . . . . . . .
n+1 recorder topology . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 50
. 48
. 61
106
136
O
observer . . . . . . . . . . . . . . . . . . . . . . 87
in administration server . . . . . . . . . . . . . . 84
operating system, network . . . . . . . . . . . . . . 50
P
parallel archiving . . . . . . . .
passive tap
Avaya . . . . . . . . . . . .
passive tap station-side recording .
patches . . . . . . . . . . . .
PBX . . . . . . . . . . . . . .
PGAdmin III utility . . . . . . . .
port span . . . . . . . . . . . .
PSTN . . . . . . . . . . . . . .
. . . . . . . . . . 31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 44
20, 66
. . 44
. . 86
114
40
80
27
80
159
. 26
.
.
.
.
R
recorder
scaling . . . . . . . . . . . . . .
Recorder Manager. . . . . . . . . . .
recorder scaling (multi-node deployment)
recorder state interface . . . . . . . .
recording
supported . . . . . . . . . . . . .
recording system
security overview. . . . . . . . . .
security summary . . . . . . . . .
redundant network feeds . . . . . . .
remote Call Manager . . . . . . . . .
resource scalability and IDS . . . . . . .
retention period, in call buffers . . . . .
Retriever . . . . . . . . . . . . . . .
retriever
architecture . . . . . . . . . . . .
. . . . . . . 57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
166
168
141
152
136
. 32
. 89
. . . . . . . 76

201
Index
content server. . . . . .
description . . . . . . .
round robin
load balancing algorithm .
round robin, weighted . . .
routing, IP . . . . . . . . .
RSA . . . . . . . . . . . .
RSA key manager . . . . . .
. . . . . . . . . . . . 76
. . . . . . . . . . . . 76
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 143
. 143
. 48
. 169
. 169
S
scaling . . . . . . . . . . . . . . . . . .
scaling, recorder . . . . . . . . . . . . .
SCCP
and IDS device . . . . . . . . . . . .
attributes, UDF . . . . . . . . . . . .
1+1 networks . . . . . . . . . . . . .
screen recording
architecture . . . . . . . . . . . . . .
search and replay
in application server . . . . . . . . . .
in Contactstore Plus . . . . . . . . . .
in Enterprise Manager . . . . . . . . .
in live monitor . . . . . . . . . . . .
in retrieval architecture . . . . . . . .
in screen recording . . . . . . . . . .
in screen replay . . . . . . . . . . . .
security . . . . . . . . . . . . . . . .
server environment . . . . . . . . . .
unify mapping . . . . . . . . . . . .
security
features . . . . . . . . . . . . . . .
RSA key management . . . . . . . . .
selective recording . . . . . . . . . . . .
sequential archiving . . . . . . . . . . . .
session-initiated protocol (SIP) . . . . . . .
single recorder cluster . . . . . . . . . . .
single-node deployment . . . . . . . . . .
SIP
attributes, UDF . . . . . . . . . . . .
SNMP application . . . . . . . . . . . . .
Sony AIT-3 Tape drives . . . . . . . . . .
source-destination, load balancing algorithm
SPAN
conference bridge . . . . . . . . . . .
encapsulated remote (ER) . . . . . . .
extension recording . . . . . . . . . .
gateway recording . . . . . . . . . .
port . . . . . . . . . . . . . . . . .
remote . . . . . . . . . . . . . . . .
VLSPAN . . . . . . . . . . . . . . .
standard recorder script fields . . . . . . .
station-side, passive tapping . . . . . . . .
. . . . . 44
. . . . . 44
. . . . . 135
. . . . . 123
. . 135, 140
. . . . . 91
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 83
. 88
. 21
. 86
. 76
. 35
. 91
. 181
. 33
. 119
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 168
. 169
. 35
. 31
. 124
. 150
. 42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 124
. 75
. 30
. 144
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 160
. 161
. 147
. 146
. 159
. 160
. 160
. 125
. 40
status, configuration, and alarming component

streaming interface, live monitor . . . . . . .
streaming retriever
ContactStore Plus . . . . . . . . . . . .
subnets . . . . . . . . . . . . . . . . . .
. . . . 75
. . . . 86
. . 89, 90
. . . . 91
T
tagging calls, Avaya . . . . . . . . . . . . . . . . 113
TopLayer IDS device . . . . . . . . . . . . . . . . 134
topologies
IP routing . . . . . . . . . . . . . . . . . . . . 48
U
UDFs . . . . . . . . . . . .
unify
control fallback . . . . .
features summary . . . .
fields in standard script . .
search and replay mapping
user defined fields . . . . . .
Ai-Logix card attributes . .
E1/T1 card attributes . . .
. . . . . . . . . . . 117
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 57
. 27
125
119
117
121
122
V
verify media . . . . . . . . . . . . . .
Viewer
in administration server . . . . . . . .
viewer. See Search and Replay . . . . . .
virus scanning . . . . . . . . . . . . . .
VLSPAN . . . . . . . . . . . . . . . .
voice card
auto-detecting . . . . . . . . . . . .
capturing voice-card iinitiated contacts .
voice cards . . . . . . . . . . . . . . .
voice gateway . . . . . . . . . . . . .
VOX . . . . . . . . . . . . . . . . . .
. . . . . . 31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 84
. 33
. 82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 54
. 57
. 51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 87
160
146
. 61
W
web observer, audioserver
weighted round robin . .
Witplayer . . . . . . . .
workflow manager . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
143
179
. 32
Numerical
1+1 network feed topology . . . . . . . . . . . . 141
1+1 recorder topology . . . . . . . . . . . . . . . 139
1+1 TopLayer topology . . . . . . . . . . . . . . 140

202

Recorder SysInfra Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Recorder SysInfra Guide

Загружено:

Авторское право:

Доступные форматы

Impact 360 Recorder

System Infrastructure Guide

Release 7.8 SP3

2008 Verint Systems Inc. All Rights Reserved Worldwide.

Live Monitoring via Web Observer . . . . . . . . . . . . . . . . . . . . . . . .

Recording and Administration

Full-time Recorder System Infrastructure Guide

Recorder Server Components . . . . . . . . . .

Recording with DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Recording with Cisco DMS . .

Passive Recording with Avaya

Full-time Recorder System Infrastructure Guide

Functionality without a CTI component . . . .

User Defined Fields

Understanding Call Data . . . . . . . . .

Ports Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

High Availability IP Recording Systems . .

Full-time Recorder System Infrastructure Guide

Full-time Recorder System Infrastructure Guide

Full-time Recorder System Infrastructure Guide

Intended Audience for This Guide, page 10

Related Documents, page 10

Summary of Information in This Guide, page 11

Conventions Used in This Guide, page 12

If You Need Help, page 14

Contacting Technical Support, page 15

Intended Audience for This Guide

Intended Audience for This Guide

System Administration Guide

Enterprise Manager Administration Guide

Enterprise Security Administration Guide

The following documents are related to this document:

Recorder Installation Guide

Integration Service Guide

Viewer User Guides

RSA Key Manager Server 2.0 Administration Guide

RSA Key Manager Installation Guide.

Full-time Recorder System Infrastructure Guide

Summary of Information in This Guide

Summary of Information in This Guide

This chapter provides an overview of the Recorder and the

This chapter describes the Recorder environment, common

This chapter explains the process by which calls are

This chapter provides an overview of the Recorders

This chapter provides an overview of Ciscos call recording

This chapter provides an overview of passive recording

This chapter explains associated and non-associated call

This appendix provides system designers with the

This appendix provides an overivew of security features in

This appendix provides answers to common questions you

Full-time Recorder System Infrastructure Guide

Conventions Used in This Guide

Conventions Used in This Guide

The Standard Conventions table highlights conventions used to describe user

Menu items are highlighted in bold as in the following example:

Other documents are referred to using italics. For example:

Specific button or function names are highlighted in bold. The

When the user is expected to type a value, the name of the

Refer to the Quality Monitoring 7.8 Installation Guide for more

<Your ER Server Name>

Full-time Recorder System Infrastructure Guide

Conventions Used in This Guide

Important details that we want to make sure that you do not

Helpful hints that can improve the efficiency or effectiveness of