recorder sysinfra guide

Impact 360 Recorder

System Infrastructure Guide

Release 7.8 SP3January, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Intended Audience for This Guide . . . . . . . . . . . . . . . . . . . . . . . 10Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Summary of Information in This Guide . . . . . . . . . . . . . . . . . . . . . 11Conventions Used in This Guide . . . . . . . . . . . . . . . . . . . . . . . . 12If You Need Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Before You Contact Technical Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . 15Verint Witness Actionable Solutions Website and the Customer Interaction Center (CIC) . . . . . 15Telephone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Direct internet FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Other support and training alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1 Recorder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Recorder-at-a-Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Recorder Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Using Recorder Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Using Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Recorder Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . 23Enterprise Manager Features and Benefits . . . . . . . . . . . . . . . . . . . . 24

2 Recorder Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Recorder Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 26PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26PBX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27CTI Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Agent Telephones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Unify Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Integration Service Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Recorder Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Search and Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Centralized Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Live Monitoring via Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Contents

Full-time Recorder System Infrastructure Guide 4

© 2005-2008 Witness Systems, Inc. Confidential and Proprietary Information of Witness Systems, Inc. All rights reserved, worldwide.

Live Monitoring via Web Observer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Screen Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Inline Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Common Recording Methods . . . . . . . . . . . . . . . . . . . . . . . . . 37Trunk-Side TDM Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Gateway Recording (IP Recording) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Station-Side TDM Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Extension-Side Recording (IP Recording) . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Single-node Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Multi-node Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Enterprise Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45Call Control Forwarding and Intelligent Call Control Distribution (IP Recording Only) . . . . . . .46

Network Topology and Traffic Routing . . . . . . . . . . . . . . . . . . . . . . 48Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Supported Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . 50Physical Connectivity Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50CTI Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Voice Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51Label Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Media Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

3 Recording and Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Recording Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Before Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Capturing and Recording Voice and Screen Data . . . . . . . . . . . . . . . . . . . . . . . .55Capturing and Recording Associated Call Data . . . . . . . . . . . . . . . . . . . . . . . . .56Recording Calls With the Call Control Engine. . . . . . . . . . . . . . . . . . . . . . . . . .56Recording Calls Without the Call Control Engine . . . . . . . . . . . . . . . . . . . . . . . .57TDM Control Fallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57IP Recording Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Using VOX Detection in IP Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

Using non-CTI Recording Methods . . . . . . . . . . . . . . . . . . . . . . . 61Understanding VOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Difference between VOX and D-channel, line voltage, and CASS . . . . . . . . . . . . . . . .63CCE Control Option/Fallback Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Triggering a Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Recorder Manager Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Enterprise Manager Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

4 Recorder Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Recorder Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Contents



Recorder Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Collaboration Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 72Collaboration Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Collaboration Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Configuration Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 74Retrieval Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Retrieval Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Content Server Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

Disk Management Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 78Disk Management Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78Disk Management Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78Disk and System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Application Server and Workstation Applications . . . . . . . . . . . . . . . . . . 83Application Server Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Application Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Workstation Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

Live Monitor Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 85Live Monitor Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85Live Monitor Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86Live Monitor Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

ContactStore Plus Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 88Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Live Monitor and Archive Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Streaming Retriever Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89ContactStore Plus Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Screen Capture Architecture . . . . . . . . . . . . . . . . . . . . . . . . .91Screen Capture Support in CTI Environments . . . . . . . . . . . . . . . . . . . . . . . . .91Screen Capture Support in non-CTI Environments . . . . . . . . . . . . . . . . . . . . . . .92Understanding Workstations, Seating, Phones and Workspaces . . . . . . . . . . . . . . . . .93

5 Recording with DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Recording with Cisco DMS . . . . . . . . . . . . . . . . . . . . . . . . . 100Cisco Call Recording Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Recording Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Recording Invocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Recorder Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Call Recording dScenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Recording with Nortel DMS . . . . . . . . . . . . . . . . . . . . . . . . . 106Nortel Call Recording Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Recording Invocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Call Recording Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6 Passive Recording with Avaya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Recording Avaya Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Tagging Avaya Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Avaya System Configurations . . . . . . . . . . . . . . . . . . . . . . . . 113

Contents



Functionality without a CTI component . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Functionality with CTI integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Configuration Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . 114Configuring Avaya with the CTI Component . . . . . . . . . . . . . . . . . . . . . . . . . 114Configuring Avaya without the CTI Component. . . . . . . . . . . . . . . . . . . . . . . . 115

7 User Defined Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

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

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

B High Availability IP Recording Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 133TopLayer IDS Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Link Protector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138IP Recorder Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Redundant Network Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 141TopLayer IDS Load Balancing Algorithms . . . . . . . . . . . . . . . . . . . . 142Round Robin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Weighted Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Source-Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Recording Styles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Gateway Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Extension Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

IP Topology Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Single Recorder Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Remote Call Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15210,000+ Phones Gateway Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154High Availability Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Wiring for IP Environments . . . . . . . . . . . . . . . . . . . . . . . . . 158IP Recorder Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Recording Scenario Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Traffic Mirroring Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Common Challenges in Gateway Recording . . . . . . . . . . . . . . . . . . . . . . . . . 161

C Enterprise Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Recording System Overview . . . . . . . . . . . . . . . . . . . . . . . . 166Recording System Security Features. . . . . . . . . . . . . . . . . . . . . . 168RSA Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Contents



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

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Contents



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 guide’s audience, a summary of each chapter, and where to find additional resources and assistance.

This introductory section to the guide describes the following topics:

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

A b o u t T h i s G u i d e

Intended Audience for This Guide



Intended Audience for This GuideThis guide is designed to be used by:

Company and Business Partner professional services staff responsible for planning and setting up systems.

Customers’ IT staff responsible for system maintenance.

Related DocumentsThe following documents are referenced in this document

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

The following documents are referenced if system security is enabled in the recording system:

RSA Key Manager Server 2.0 Administration Guide

RSA Key Manager Installation Guide.

Summary of Information in This Guide



Summary of Information in This GuideInformation 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 4Recorder Functionality, page 69

This chapter provides an overview of the Recorder’s functionality from an architectural perspective.

Chapter 5Recording with DMS, page 99

This chapter provides an overview of Cisco’s call recording functionality as related to Duplicate Media Streaming (DMS)

Chapter 6Passive 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 AHigh 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.

Conventions Used in This Guide



Conventions Used in This GuideThe following two tables describe some of the conventions that are used in this document:

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:

Refer to the Quality Monitoring 7.8 Installation Guide for more information.

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:

Click OK, and then choose the Restore Database dialog box.

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:

<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.

Conventions Used in This Guide



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: Harm to software Loss of dataAn interruption in service

If You Need Help



If You Need HelpOur 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:

Verint Systems website and Customer Interaction Center (CIC)

Telephone

E-mail

Direct Internet FTP

Other support and training alternatives

Before You Contact Technical SupportHelp 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.

2 Have at least the following information available when you contact Technical Support.

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 company’s 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?

Contacting Technical Support



Contacting Technical SupportOnce 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.

TelephoneWitness 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.

Contacting Technical Support



EmailIf you are a new customer and need a logon ID and password, you can e-mail [email protected] to obtain your new logon information.

Direct internet FTPThis 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 alternativesIn 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.

C h a p t e r 1

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:

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

Impact 360 Recorder System Infrastructure Guide 18


Recorder-at-a-GlanceThe Recorder consists of software components in a standard PC that interfaces with telephony or data network components. The Recorder’s 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:

PBX/SoftswitchCalls and Screens

Recorder(s)

Unify/Integration Service

APPLICATIONS:Recorder ManagerEnterprise ManagerSearch and Replay

APPLICATIONS

RECORDING AND DATABASE

TELEPHONY CTIServer

ApplicationServer

Database Server

Recording System Infrastructure Hierarchy

Station-side, Trunk-side, or IP Tapping

Chapter 1: Recorder Overview Recorder-at-a-Glance



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:

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.

Some OEM partners may already have proprietary IP tapping/recording technologies.

PBX/Softswitch

Application LANDATASOURCE

TELEPHONY/NETWORK Recorder

CTIServer

ACD/PBX

Telephony/Network Infrastructure Overview

Station-side, Trunk-side, or IP Tapping

UnifyINTEGRATIONFRAMEWORK

IntegrationService

RecorderController

Chapter 1: Recorder Overview Recorder Management



Recorder ManagementThe 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 ManagerRecorder 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.




Using Enterprise ManagerRecorder 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.

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:

RM RM RM

EM Enterprise Manager

Recorders, each with Recorder Manager installed

RM




You can launch a Recorder’s 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.

Chapter 1: Recorder Overview Recorder Features and Benefits



Recorder Features and BenefitsRecorder 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.

Chapter 1: Recorder Overview Enterprise Manager Features and Benefits



Enterprise Manager Features and BenefitsEnterprise 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.

C h a p t e r 2

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:

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


© 2005-2008 Verint Systems, Inc. Confidential and Proprietary Information of Verint Systems, Inc. All rights reserved, worldwide.

Recorder EnvironmentThe 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.

These main components are described in the following sections.

PSTNTelephone calls that will be recorded originate from the public switched telephone network (PSTN). Trunk lines carry those calls from the PSTN to an organization’s

WorkflowManager

DiskManager

CaptureEngine

VoiceCard

Call Buffer

Write

Delete

Compressor

Consolidator

Archiver

ContentServer

Metadatafiles

.wav/.scn files

PSTN

Station-Side Recording

LocalArchive

Database

Call ControlServer

CTI Server

CentralizedArchiveServer

Search and ReplayServer

PBX

Recordings in (to capture card)

Recordings out -(after retrieving fromcall buffer/conversion to .wav/.scn files)

Tagged Metadata in (to capture engine)

Metadata out (after retrievingfrom call buffer)

Each recorded contact has corresponding metadata

Raw Metadata




private branch exchange (PBX). Trunk lines can be Category 5 network or coaxial cables.

PBXThe 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 ServerThe 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 TelephonesAgents 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 ServerUnify 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.

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.




Integration Service ServerThe 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.




Recorder ServerThe 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.

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.

WorkflowManager

DiskManager

CaptureEngine

VoiceCard

Call Buffer

Write

Delete

Compressor

Consolidator

Archiver

ContentServer

Metadatafiles

PSTN

Station-Side Recording

LocalArchive

Database

Call ControlServer

CTI Server

EnterpriseArchiveServer

PBX

Search andReplayServer

Call #7 Voice

Call #7Raw Metadata

600001000000007.xml

600001000000007.wav

Mapped Metadata for call #7

Voice (audio) data for call #7

Capture ComponentSN: 600001

Voice Recordings out -(after retrieving fromcall buffer/conversion to audio file)

Metadata out (after retrievingfrom call buffer)

.wav files




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:

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.

Item Description

HP DAT72

DDS5 Tape Drive - 36 GB capacitySony AIT-3 Tape drives

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.

Iomega REV drive

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).




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.

DVD-RAM, DVD RW, +/-, 4.7 GB

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 devicesIt 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/index.htmlEach side of the DVD media can hold approximately 550 hours of voice recording based on typical call lengths.

EMC Centera Remote Storage

Scalable, high-volume, fault-tolerant remote storage device supporting CAS, SAN, and NASArchive TAR bundles are written to Centera drives through Centera API.Files contain a fingerprint (metadata) for disaster recovery.Internet: www.emc.com

Item Description




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 server’s 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.




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 Recorder’s 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 Recorder’s 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 ReplayThe 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.




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:

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 ArchivingCentralized 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

2 Navigate to SQL Server Agent->Jobs

3 Right click on EWareArchiveFailSafeNotification and select Disable.

4 Exit Server Enterprise Manager/ SQL Server Management Studio

For more information on installed SQL jobs, refer to the Recorder Installation Guide.

Live Monitoring via ObserverSupervisors 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




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 RecordingScreen 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

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 SourcesData 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

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.




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:

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 CompressionThe inline compression feature compresses audio recordings directly in the capture engine, as opposed to post-recording compression performed in the Compressor component.

Chapter 2: Recorder Infrastructure Common Recording Methods



Common Recording MethodsCalls 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:

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 RecordingIn 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.




PSTN

T1 LineNote: 1 junction box/Y Splitter(the tap point) is required per T1 line.

PBX

PunchdownBlock

Junction Box/Y Splitter

Trunk Side Recording (TDM)

Recorder Server

Sysadmin/SupervisorServer

AgentWorkstations

LAN

Call ControlServer

CTIServer




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.

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.

PSTN

T1 Line

Voice Gateway/Conference Bridge

Gateway Recording (IP)

Recorder Server


AgentWorkstationsLAN

M

Call Manager

CTIServer

V

IS/UnifyServer




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 system’s 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 RecordingIn 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

PSTN

Recorder Server


AgentWorkstations

PBX

LAN

RECORDING

PunchdownBlock

T1 Line

CTIServer

Call ControlServer




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)

Recorder Server


Voice Gateway/Conference Bridge

LAN

M

Call Manager

AgentWorkstations

PSTN

T1 Line V

CTIServer

IS/UnifyServer

Chapter 2: Recorder Infrastructure Deployment Scenarios



Deployment ScenariosThe 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:

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 DeploymentThe 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.




RecorderManager

CTIAdapter

IntegrationService

Single Node Deployment

Search and Replay

SQL/Oracleor MSDE DB




Multi-node DeploymentWhen 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

Recorder Manager

TMD Recorder

Recorder Manager

IP Recorder

Viewer

DatabaseServer

Viewer/Database

Recorder Manager

Centralized ArchivingEM Server

EnterpriseManager

IntegrationService

CTI Adapter




Enterprise DeploymentMany 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.

Load Balancer/IDS

Database

Voice Switch

Viewer

Unify/IntegrationServer

Branch A: TDM Recorders

Main Office

Branch B: IP Recorders

Reco

rder

(s) A

Reco

rder

(s) B

Enterprise Installation: Multi-site setup with Enterprise Database

V

Viewer/Central

Database/EM

Server

L

E

G

E

N

D

CTIServer

V




Call Control Forwarding and Intelligent Call Control Distribution (IP Recording Only)

In IP recording environments, the Analyzer enables the following types of deployments:

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.

MCall Manager

VLEGEND: Voice Gateway Voice Switch Recorder

Viewer/Database/Integration

Server

V

IP

1 2 IP

Analyzer

V

V

IP

PSTN

V

IP

IP

3V

SITE A

SITE B

Call Control

Forwarding

IP

V

1 2




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.

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.

VLEGEND: Voice Gateway

10.10.1.100

10.10.2.101

10.10.2.100

Voice Switch Load Balancer/IDS Device

RecorderV

IP

V

IP

IP

SITE A

SITE BSearch&Replay/

Database/IS/UnifyServer

IP

1 2 3 4

Intelligent Call

Control Distribution

MCall Manager

IP Analyzer

V

PSTN

V

IP5

V

V

Chapter 2: Recorder Infrastructure 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 RoutingInstalling 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:

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.

Chapter 2: Recorder Infrastructure Time Synchronization



Time SynchronizationTime 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.

Chapter 2: Recorder Infrastructure Supported Hardware and Software



Supported Hardware and SoftwareThe 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 OptionsData 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 SystemThe 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 ServersIt 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.




Voice CardsThe 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-ehLD809, LD809-ehLD1609, LD1609-ehLD2409, 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.

Digital Station Side

NGX800NGX800-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.

NGX1600NGX1600-eh

Voice card that records 16x2-wire digital stations (8x4-wire). It is triggered by D-channel events. It can have one MX80 daugtherboard attached.

NGX2400NGX2400-eh

Voice card that records 24x2-wire digital stations (12x4-wire) triggered by D-channel events.

MX80 Daughterboard that can be installed on NGX800 and NGX1600 voice cards.

Digital and Analog

DSC-16-PCIDSC-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.




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 PrintingStandard 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 LimitationsThe Recorder has the following media limitations:

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).

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.

PCM3209PCM3209-ehPCM6409PCM6409-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.

DT3209TEDT3209TE-ehDT6409TEDT6409TE-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.

Type Ai-Logix Model* Description

C h a p t e r 3

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:

Recording Process, page 54

Using non-CTI Recording Methods, page 61

System Administration, page 66

Chapter 3: Recording and Administration Recording Process



Recording ProcessRecording 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 Recorder’s Call Buffer. These tasks are described in the following sections:

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 RecordingBefore 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




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:

Missing

Tampered

Invalid or expired

Configuration mismatch

Channel not licensed

The Recorder supports the following license types:

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 DataThis 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 Recorder’s 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




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 DataRecording 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 EngineWhen 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.




Recording Calls Without the Call Control EngineWhen 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 ModesThe IP Recorder supports the following recording modes:

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.




For the Default Recording modes, there are two options:

Record and

Do not Record

For individual extensions, there are five options:

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:

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 RecordingVOX 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.




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:

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:

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.

Time/Duration (Mins)

VOX Detection in the IP Call Recording Process

Call In Progress

0 10 20 30 40 50 60 70 80 90 100 110 120 140 160 180

CTI IndicatesStart of Call(e.g. SIP 200 OKResponse to anINVITE)

CTI IndicatesEnd of Call(e.g. SIP BYE)

* VOX AlgorithmDetects Silenceand StopsRecording

StopRecording *

StopRecording *

StopRecording *

StartRecording **

StartRecording **

** VOX AlgorithmDetects Audioand Starts anew Recording

Recording 1 Recording 2 Recording 3

Speech Speech SpeechSilence Silence Silence




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.

Chapter 3: Recording and Administration Using non-CTI Recording Methods



Using non-CTI Recording MethodsVOX 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 VOXYou 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 Recorder’s capture engine. The two categories are presented in the following table:

CTI-driven events Non-CTI-driven events

VOX Non-VOX

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.

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.

It is also less desirable because call volume can vary and this can lead to a single call being captured in multiple call segments.

– D-channel – Line Voltage – CASS idle code.

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.




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 VOX- based 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




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 card’s 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 set’s LCD screen in most cases.




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 FeatureAs 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 RecordingRegardless 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:




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.

Chapter 3: Recording and Administration System Administration



System AdministrationEnd 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 FunctionalityRecorder Manager provides the functionality to perform the following tasks:

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

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 Administration Guide.

Enterprise Manager FunctionalityEnterprise Manager provides the functionality to perform the following tasks:

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.




AuditingEvery 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.

C h a p t e r 4

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:

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



Recorder ArchitectureThe Recorder architecture consists of software components that interact to enable full-time recording. The following diagram shows the main components.

Recorder Server ComponentsThe following table summarizes the functionality of each Recorder server component, and contains references to additional information.

Recorder Server Application Server

Archiver

WorkflowManager

ContentServer

DiskManager

CaptureEngine

Config.WebService

IntegrationService/ Unify

Search andReplay

Architecture

Consolidator

Compressor

Database

ArchiveCTI Server

Recorder Manager is installed on the Recorder.Enterprise Manager would be installed on the Application server.

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 Recorder’s Call Buffer.

Chapter 4: Recorder Functionality Recorder Architecture



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 Recorder’s 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.

Chapter 4: Recorder Functionality Collaboration Architecture



Collaboration ArchitectureThe 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 DescriptionIn 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.

Recorder Server

eWare/IS/Unify/Search and Replay Server

eWare2CCConsolidator

Archiver

Workflow Manager

CTI Source

Unit Service

Capture Engine

VoiceCard /NIC

CTI Server

Unify

Control Interface NGA Capture / TCP

Smartworks API

CTI Events: Protocol varies by vendor

NetCom UDP

MediaStore

NetCom UDP

Proprietary Tape Driver

Collaboration Recording Scenario

Archive

Tape Archival Storage

MS Tape API

ODBC

ODBC

DB

Chapter 4: Recorder Functionality Collaboration Architecture



Collaboration ComponentsAdditional 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.

Chapter 4: Recorder Functionality Configuration Architecture



Configuration ArchitectureThe 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 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.

Recorder Server

Archiver

Config.,Status,Alarming

CaptureEngine

Recorder Manager

Config. Web Service

System Administrator or Supervisor Workstation

EnterpriseManager

SNMP Application SNMP

HTTP,gSOAP WebService

Configuration Scenario

Consolidator

Tomcat Web Server

Chapter 4: Recorder Functionality Configuration Architecture



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.

Chapter 4: Recorder Functionality Retrieval Architecture



Retrieval ArchitectureThe 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 DescriptionThe 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 contact’s data for display and playback.

Content Server ComponentThe 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 Recorder’s 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.

Tomcat Weblogix

Recorder Server

ContentServer

Archiver

RecorderManager

EnterpriseManager

Database

HTTP

Retrieval Scenario System Administratoror Supervisor Workstation

Search andReplay

ODBC

Chapter 4: Recorder Functionality Retrieval Architecture



2 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.

3 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.

4 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 .

Chapter 4: Recorder Functionality Disk Management Architecture



Disk Management ArchitectureThe 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 Management DescriptionThe 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 ComponentsThe 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

Recorder Server

Consolidator

WorkflowManager

Disk Manager

Capture Engine

TelephonyCard

Call Buffer (Internal Disk Drive)

Delete Write

Database

Disk Manager Architecture

NGA/ TCP

NGA/ TCP

Smartworks API




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 Administration Guide.

Disk and System PerformanceDisk 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:

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:

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




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.

2 Over 240 channels the database should be moved to a separate RAID 5 or RAID 10 logical drive.

3 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:

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.




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

2 Choose the TRACING menu option

3 Uncheck (if checked) the Tracing Enabled option. This will disable tracing for the source DLLs.

Logging in TDM Recorder’s 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.

2 Select Default in the Choose Components selection box.

3 Set the Trace Level to Info

4 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.

2 Right click Database Maintenance and select New Maintenance Plan.

3 Setup a backup job, choose all databases and leave the default options on the Optimization and Integrity settings.

4 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.

5 Create another maintenance plan for the Optimization and Integrity Checks job.

6 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.

7 Setup the Optimization job with the first option of Reorganize Data and Index Pages.




8 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.

9 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.

2 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).

3 Exclude the following from being scanned:

The configured Calls folder–call 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, *.tmpExclude 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.

Chapter 4: Recorder Functionality 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:

Application Server DescriptionSystem 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 ComponentsAdministration server components include Search and Replay and Enterprise Manager. These are described in the following sections.

Recorder Server

Application Server

Archiver

Compressor

WorkflowManager

ContentServer

DiskManager

CaptureEngine

Config.WebService

IntegrationService


Search andReplay

EnterpriseManager

Observer

Recorder Manager is located on the Recorder Server.

Architecture

Consolidator

Database ArchiveCTI Server

RTP

HTTP

CTI Events Protocol varies

by vendor

Control Interface NGA Capture /

TCP

MS Tape API ODBC

Chapter 4: Recorder Functionality 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 ComponentWorkstation 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.

Chapter 4: Recorder Functionality Live Monitor Architecture



Live Monitor ArchitectureRecorder 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:

Live Monitor DescriptionObserver 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

Recorder Server

Live Monitor Streaming Interface using RTP

Live Monitor Control/ Recorder State Interface using NGA Capture TCP

eWare/IS/Unify Search&Replay/Server

Tomcat Web Server

Capture Engine

Observer

Live Mon-itor StateComponent


Observer

Live Monitor Architecture

Database

ODBC




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 InterfacesThe 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 ComponentsLive 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




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 supervisor’s desktop using the organization’s 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 supervisor’s desktop using the company’s telephone system.

Chapter 4: Recorder Functionality ContactStore Plus Architecture



ContactStore Plus ArchitectureThe 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.

DescriptionQuality 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.

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.


Balance BDR/ eRecorder Server

Recorder Server

eWare/Unify/Viewer Server

HTTP Retrieval Interface

Search and Replay Server

Balance DB

ODBC

Inserts Contact Info. and INUM

CS PlusStreamingRetriever

ContentServer

CaptureEngine

BDR Server

IntegrationService

ContactStore Plus Architecture

CTI Server

Balance Replay

eRecorder

Streaming Retrieval Interface HTTPS Web Service TCP Streams Audio




Live Monitor and Archive ExceptionsThe 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 EnhancementAn 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.

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 ComponentsAdditional 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:

Unify or Integration Service: sends call recording begin and end events.

WAV is not a streaming file format.




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.

Chapter 4: Recorder Functionality Screen Capture Architecture



Screen Capture ArchitectureThe 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 EnvironmentsThe Screen Capture module resides on an agent’s 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:

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.

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

Screen Capture

Workflow

Consolidator

DiskManager

Archiver

Screen Capture (Agent)

Agent Desktop

Screen Recorder




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 EnvironmentsThe 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.

2 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




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.

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.

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 WorkspacesThis section lists the different types of seating, workstation, phone and workspace configurations possible in Enterprise Manager. These can be broken into three configuration concepts:

Dynamic and Static Workspaces

Seating Arrangements for Phones and Workstations

Dynamic Workstations




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:

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:




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

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 Administration Guide.

1 Set the Data Source to Free Seating

2 Configure the Workstation subnet

3 Configure the Phone

4 Assign a LAN Data Source Agent ID to the Person

5 Assign a Phone Data Source Agent ID to the Person

6 Execute CTI logon to phone which will associate extension to the Agent.

7 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.




Dynamic Workstations with Static Workspaces

Description

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


2 Configure the Workstation subnet




6 Build the workspace by assigning the phone to a Workstation or a Workstation to the phone

7 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

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


2 Configure the Workstation




6 Execute the CTI logon to the phone. This associates the extension to the Agent.

7 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.




Static Workstations with Static Workspaces with Login

Description


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



3 Configure the phone

4 Build workspace by assigning the phone to the Workstation or Workstation to the phone.


6 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


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


3 Configure the phone

4 Build the workspace by assigning phone to Workstation or Workstation to phone

5 Assign a Phone Data Source Extension to the Person

Workspaces are established on startup and the assigned agent is associated to the workspace.




Dynamic or Static Workstations with Dynamic Workspaces

Description

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.

C h a p t e r 5

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:

Recording with Cisco DMS, page 100

Recording with Nortel DMS, page 106

Chapter 5: Recording with DMS Recording with Cisco DMS



Recording with Cisco DMSRecording with Cisco DMS provides an overview of Cisco’s 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 Information is presented in the following topics:

Cisco Call Recording Overview

Recording Sessions

Recording Invocations

Recorder Integration

Call Recording dScenarios

Cisco Call Recording OverviewThe following figure illustrates different network components involved in a call recording session and the protocols that they use.

Cisco DMS is not supported against encrypted phone calls or softphone endpoints. For a list of DMS-supported devices, please contact Cisco.

CallManager

MGC/H.323NGA/RCP

NGA: New Generation Architecture. RCP: Realtime Control Protocol. SIP: Session Initiated Protocol. SCCP: Skinny Call ControlProtocol. MGC: Media Gateway Control. H.323: Multi-media Transport Protocol

SIP

SIP/SCCP

Integration Service Server

RecorderVoice Gateway Agent

ProtocolAgent’s voice streamCustomer’s voice stream

Customer

PSTN / WAN

V

M

IP

Cisco Call Recording Process




Recording SessionsCall 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.

Recording InvocationsCisco 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 IntegrationThe 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.




Call Recording dScenariosThis section describes the various permutations of a phone call from a customer to an agent. The following scenarios are described:

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.

The followings steps are shown in the figure:

1 Customer calls into the call center.

2 The call is routed to Agent1. Agent1 answers the call. The agent's IP phone starts to exchange media streams with the customer.

3 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.

4 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.

Automatic Call Recording Process

Integration Service ServerDN=3000

RecorderAgent 1DN=2000

Customer

dial answer

INVITE

INVITE

BIB

setupsetup

setup

setup

IP

4

7

8

1 2

Agent1’s voice Customer’s voice DN = Domain Name, BIB = Build in Bridge

3

65

M

M M

M M




5 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.

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.

Call on hold while being recorded



Customer

Music On Hold Server

hold disconnectdisconnect

disconnect

BIB

IP

3

X

XX

X X

21

Agent1’s voice stream Customer’s voice stream DN = Domain Name, BIB = Build in Bridge



Customer

setup

resumesetup

setup

BIB

IP

654




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.

The followings steps describe the Conference scenario illustrated in the figure:

1 Agent1 presses the conference key and then dials Agent3.

2 The call between Agent1 and the Customer is put on hold and so the recording session is torn down.

Conference Call Integration Service ServerDN=3000

RecorderVoice Gateway Agent 1DN=2000

Customer

Agent 3DN=2001

Music on Hold Server

disconnect disconnect

disconnectconference

holddisconnect

IP

V

BIB

IP

2

3

41



Customer

Agent 3DN=2001

Conference Bridge

setup

setup

setup

answer

BIB

6

7

8

5V

Protocol/actionAgent 1 voice streamCustomer voice streamAgent 3 voice streamAgent 3 + Customer voice Agent 3 + Agent 1 voice BIB: Build in Bridge

DN: Dialed Number

IP

IP

Agent1 starts a conference to include Agent3 in the conversation with the customer.LEGEND: MOH = Music on hold, DN = Dialed number, IF = Integration Service.




3 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.

4 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.

Agent1DN=2000

IntegrationService ServerDN=2000

Recorder2

Recorder1

Recorder3Customer

Protocol /SIP Agent 1’s voice Customer’s voice DN = Domain Name, BIB = Build in Bridge

setup setup

setup

setup

BIB

Load Balancing

M

M M

M M

IP

Chapter 5: Recording with DMS Recording with Nortel DMS



Recording with Nortel DMSRecording with Nortel DMS provides an overview of Nortel’s 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:

Nortel Call Recording Overview

Recording Invocations

Call Recording Scenario

Nortel Call Recording OverviewDMS 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.

CS 1000

MLS

Integration Service Server

RecorderVoice Gateway Agent

ProtocolAgent’s voice streamCustomer’s voice stream

Customer

PSTN / WAN

V

M

IP

Nortel Call Recording Process




Recording InvocationsRecording 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 ScenarioThis 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:

Nortel DMS Recording Process, page 108

Calls to or From Agent's Line, page 109

Load Balancing and Redundancy Support, page 110




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.

MLS

Nortel CS 1000

customer

agent

PSTN/ WAN

customer’s voice streamagent’s voice stream

Recorder’s

Integration

Service

NGA/ RCP

Nortel IP Protocol

Recorder




Calls to or From Agent's Line

The followings steps are shown in the figure below:

1 Customer calls into the call center.

2 The call is routed to Agent1. Agent1 answers the call. The agent's IP phone starts to exchange media streams with the customer.

3 The CS 1000 sends call events to the Recorders Integration Service via the MLS link notifying him of the call starting.

4 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.

5 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.

dial1

customer’s voice agent 1' s voice

agent 1DN=2000

customer

answer2

Recorder

Recorder’s Integration Service

CTI Call Events3

SetFeatureStartRecord4

Startstream Startstream 5 6

7

Nortel CS 1000




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 Recorder’s 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 Recorder’s 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.

C h a p t e r 6

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:

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 CallsImpact 360 Recorders record Avaya IP calls by analyzing H.323 call control messages and then processing RTP/RTCP packets in a similar fashion to Cisco’s 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:

The H323 messages and RTP/RTCP packets are routed to the Recorders by the network switches via standard mirroring or SPAN methods.

Agent PhonesAvaya Media Gateway CTI Server

Verint Recording System

RecorderServer

Integration ServicesServer

Call Center Network

CTI Events

Call Center Premises (Avaya IP)

AES/MAPDTSAPI, CVLAN,DLG, CT Connect

GenesysCLANCard

MedProCard

Communication Manager

H323 RTP/RTCP

IP PhonesSoft Phones

H323RTP/RTCP

H323RTP/RTCP CTI Events

ApplicationServer

Packets required forstation side recording

Packets required forgateway recording

Mirrored (SPANed)packets for recording

Chapter 6: Passive Recording with Avaya 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 CallsWithout 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:

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

Chapter 6: Passive Recording with Avaya 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 componentIf 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 integrationWith 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:

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 ProceduresConfiguration 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 ComponentConfigure 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.




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

1 In Enterprise Manager, create an Avaya Data Source.

2 Add an IP Extension Group to the Data Source and type the extensions of the Avaya phones to be recorded.

3 Set the Record Control Type of the member group to Recorder Controlled

4 Set the Recording Mode of the extensions to Record.

5 Assign the Extension Group to the IP Recorder being used.

6 In Recorder Manager (on the Integration Service server), click Integration Service, and then add either an Avaya TSAPI or Genesys adapter.

7 In Enterprise Manager, assign the adapter to the Avaya Data Source created in step 1.

8 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 ComponentConfigure 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.

2 Configure extensions (click Operations > Extensions) and license (click System > License) as usual.

3 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.

4 Click General Setup > Network Settings > Protocols and check the Avaya H.323 checkbox. Make sure all others are unchecked.

5 Click Save.

6 Restart the IPCapture service.

C h a p t e r 7

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.

Information is presented in the following topics:

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 DataCall 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:

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)

Chapter 7: User Defined Fields 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

Chapter 7: User Defined Fields Attributes With Integration Service



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

Chapter 7: User Defined Fields Attributes Provided by Card Model Families



Attributes Provided by Card Model FamiliesThe 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

Direc- tion

DTMF Digits

CLI First Message

Last Message

DP Trunk-Side N Y Y Y Y Y N N

NGX Digital Extension side

Y N N N Y Y Y Y

PT Analog Extension side

N N N N Y Y N N

LD Analog Extension side

N N N N Y Y N N

PCM Digital Trunk Side

N N N N Y N N N

Cybertech Digital and Analog

Y N N Y N Y N Y

Chapter 7: User Defined Fields Attributes Provided by E1/T1 Voice Cards



Attributes Provided by E1/T1 Voice CardsThe 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 N N N * *

ISDN/VOX N N N * *

ISND/ D Channel # # Y * *

NFAS/VOX N N N * *

NFAS/ D Channel # # Y * *

CAS/VOX N N N * *

CAS/CAS N N N * *

RBS/VOX N N N * *

RBS/CAS N N N * *

DASS2/VOX N N N * *

DASS2/ D Channel # # Y * *

Legend: * Only available when present on trunk bearer channel

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

Chapter 7: User Defined Fields Attributes Provided by SCCP



Attributes Provided by SCCPThe 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

Chapter 7: User Defined Fields Attributes Provided by SIP



Attributes Provided by SIPThe 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

Chapter 7: User Defined Fields 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

Chapter 7: User Defined Fields Custom Data



Custom DataMany 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.

Chapter 7: User Defined Fields Conditional Custom Data Fields



Conditional Custom Data FieldsBoth Impact and ULTRA Recorders support Conditional Custom Data fields, whose values are derived from another field’s value. This is done by analyzing this additional contact information to provide more significant business information. The process does not appear in the Recorder’s 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 Toolbox’s Conditional Custom Data application. Once configured, the values can be shared and used in both Recorder types.

Chapter 7: User Defined Fields Conditional Custom Data Fields



A p p e n d i x A

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

TDM Capture Engine

1462 No ** No TCP port for recorder control clients such as Unify, Recorder Controller, and Live Monitor State

42421* No Yes HTTP Diagnostic Interface

Screen Capture Engine

1463 No ** No TCP port for recorder control clients such as Unify, Recorder Controller, and Live Monitor State

42423* No Yes HTTP Diagnostic Interface

Appendix A Ports Usage



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

Observer 1430, 1431

No No UDP ports for receiving RTP streams

1433 No No RTP Audio

Web Observer 1430 No No -

1431 No No RTP Audio

Recorder Web Service

3435* Yes Yes Used by the Recorder Manager application to communicate with the recorder web services

Server Component

Server Port

Configurable?


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

Server Component

Server Port

Configurable?


Description




Cisco Viewer User configurable during install

Nortel DMS Viewer B

User configurable during install

* 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

Server Component

Server Port

Configurable?


Description

A p p e n d i x B

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. Information is presented in the following topics:

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 DeviceThe 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:

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 E1’s 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.

The key features that the IDS device makes available to system designers are:

Load Balancing of RTP which enables the RTP traffic to be spread across a group of Recorders.

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

Monitor Group of 3 Recorders

IDS Device

1 2 3

Incoming SPAN,containing RTP and SCCP

V




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 E1’s on a single IP Address (540 channels), or a 7206 VXR chassis with twelve E1’s (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.




Note:

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.

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 E1’s, 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 Enterprise Manager Administration Guide.

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 E1’s 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.

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.




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.

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 Recorder’s 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.

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

If the utilization of the Gateway increases before the configuration of additional recording resource, it may result in the existing Recorders overloading and failing.

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

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.

Appendix B High Availability IP Recording Systems 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.

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 ProtectorIP 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:

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.




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.

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.

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

Recorders (one passive)

Link Protector

1 2

V




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.

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

Group of Recorders

IDS Devices (one redundant)

Link Protectors (one redundant)

Voice Switch Call Manager

1 2 3

Incoming SPANcontaining only RTP (no SCCP)


V M

Appendix B High Availability IP Recording Systems IP Recorder Filtering



devices be configured identically. For more information about load balancing, refer to TopLayer IDS Load Balancing Algorithms on page 142.

IP Recorder FilteringIP 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 FeedsRedundant 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.

During fail-over, some voice recording is likely to be lost.

Appendix B High Availability IP Recording Systems 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.

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.

TopLayer IDS Load Balancing AlgorithmsDesigners can use the following three load balancing algorithms:

Round Robin

Weighted Round Robin

ComplianceRecorder

NIC1

NIC2

NIC3

NIC4

NIC5

Cat 1

Gateway 1

Redundant

Network

Feeds

Trunked Core

CM1 CM 2CallManager Cluster Gateway 2

Cat 2

M

V

CatalystSwitch

LEGEND:

Voice Gateway

CallManager

M MV V




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 RobinUsing the balancing algorithm with three Recorders configured in the monitor group, the following call distribution would be achieved.

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.

Weighted Round RobinUsing the balancing algorithm with three Recorders configured in the monitor group, the following call distribution would be achieved.

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

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.

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




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-DestinationUsing the balancing algorithm with three Recorders configured in the monitor group, the following call distribution would be achieved.

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.

Call 3 0 0 Call 30 0 0 0

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

Call 1 Call 4 Call 3

Call 3, Call 4, Call 5

Call 5, (assuming 1 finishes before 5 starts, and is made between the same extension and Gateway as 1)

Call 4 Call 3

Call 3, Call 4, Call 5, Call 6, Call 7

Call 5, Call 6, Call 7

Call 4 Call 3

Call 3, Call 4, 0 Call 4 Call 3Call 3 0 0 Call 30 0 0 0




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.

Appendix B High Availability IP Recording Systems Recording Styles



Recording StylesThe 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 RecordingGateway 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.

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

Group of Recorders

IDS Devices (one redundant)

Link Protectors (one redundant)

Voice Switch Call Manager

1 2 3

Incoming SPANcontaining only RTP (no SCCP)


V M




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 RecordingExtension 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.




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

RTP + SCCP

RTP + SCCP

RTP + SCCP

RTP + SCCP

RTP + SCCP

NIC 1

NIC 4

NIC 3

NIC 5

NIC 2

IP

IP

IP

IP

IP

Appendix B High Availability IP Recording Systems IP Topology Examples



IP Topology ExamplesThis 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




Single Recorder ClusterThe 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.

Single Recorder Cluster Components

Components in a single Recorder cluster include:

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.

V

LEGEND:

Voice Switch

Cluster

ClusterIntegrationService

Incoming SPANcontainingSCCP and RTP

Data Network

Recorder (IP) Single Cluster Deployment

Enterprise Manager Recorder

V

Load Balancer/Intrusion DetectionSystem (IDS)

Viewer/Central

Database/EM

Server

EM:




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.




Remote Call ManagerThe 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.

Remote Call Manager Components

Components in a remote Call Manager configuration include:

IP Recorder, Cluster, or any combination

IP Analyzer x 1 per remote Call Manager Server/Cluster




V

LEGEND:

Voice Switch

Cluster

ClusterIntegrationService

Incoming SPANcontaining RTP

Data Network


Analyzer

V


Viewer/Central

Database/EM

Server

EM =

V

Recorder (IP) Cluster with Remote CallManager

Incoming SPANcontaining SCCPfrom Call Manager Cluster

Incoming SPANcontaining SCCP and RTP




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.




10,000+ Phones Gateway SolutionConfigurations 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 Call Manager Components

Components in a large capacity Gateway configuration include:

IP Recorder, Cluster, or any combination

IP Analyzer x 1 per remote Call Manager Server/Cluster




V

LEGEND:

Voice Switch

Cluster



Data NetworkEnterprise Manager Recorder Analyzer

Analyzer. Analyzers are configured with the Recorders and end points for each cluster.

V

ClusterIS/UnifyServer

Cluster 1 Cluster 2

ClusterIS/UnifyServer

Load Balancer

Search&Replay/Central

Database/EM Server

EM =

V

Distributed/Multiple CallManager Clusters (Thousands of Extensions)

Incoming Call Control Commands for Analyzer in each cluster




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 site’s 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




High Availability DesignThis 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).

The cluster is designed to be fault tolerant of key elements being offline for periods, and includes the following components:

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

V

LEGEND:

Voice Switch

Cluster

1 2 3 4 5 6 7 8 9 10

High Availability (Full Fault Tolerance) Recorder (IP) Cluster


CentralArchive Server

RedundantLinkProtector

ClusterIntegrationServer


EM =

Viewer/Central

Database/EM

ServerV

Data Network

V

Incoming SPANcontaining SCCP and RTP




the Recorders. The hard disks on the Recorders should be sized such that they can be tolerant of the Archive system running behind.

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.

Appendix B High Availability IP Recording Systems Wiring for IP Environments



Wiring for IP EnvironmentsDifferent 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:

IP Recorder Protocols, page 158

Recording Scenario Requirements, page 158

Traffic Mirroring Technologies, page 159

Common Challenges in Gateway Recording, page 161

IP Recorder ProtocolsThe 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:

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 RequirementsCall 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.




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 TechnologiesSwitch 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.

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.

IP Handset

Access Switch

LAN

Port SPAN

IP Recorder

IP

Handset port traffic mirrored and sent to Recorder




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

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:

Remote SPAN

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:

IP Handsets

LAN

VLAN SPAN

IP Recorder

Voice VLAN

IP IP

Handset port traffic mirrored and sent to Recorder

Access Switch

IP HandsetsAccess Switches

LAN

Remote SPAN

IP Recorder

Layer 2 Link

IP

IP

IP

IP

Remote VLAN traffic mirrored and sent to Recorder

Remote VLAN

Local traffic mirrored and sent to remote destination




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:

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 RecordingCommon 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 the following topics:

Gateway recording with survivability, page 162

Gateway recording for more that 360 extensions, page 163

IP Data Testing, page 163

IP HandsetsAccess Switches

LAN

ER SPAN

IP Recorder

Layer 3 Routed Link

(Tunnel)

IP

IP

IP

IP

Remote VLAN traffic mirrored and sent to Recorder

Remote VLAN

Local traffic mirrored and sent to remote destination




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.

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:

V V

M MM

IP IP

IP Recorder IP Recorder

Subscriber Subscriber

SPAN

IP WAN

PSTNSite 1 Site 2

Publisher

Voice Switch Voice Switch

Voice Voice

IP Handset IP Handset

Gateway




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

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:

RTP data (Voice) - in both directions for all handsets to be recorded.

V V

M MM

IP IP

IP Recorder IP Recorder

Subscriber Subscriber

SPAN

IP WAN

PSTNSite 1 Site 2

Publisher

Voice Switch Voice Switch

Voice Voice

IP Handset IP Handset

Gateway

AnalyzerAnalyzer

Call Control

Call Control

SPAN SPAN

SPAN

LAN

Load Balancer (Top Layer device)

Recorder 1 Recorder 2 Recorder 3

IDS Load Balancer

IPTData




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.

A p p e n d i x C

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.

Information is presented in the following topics:

Recording System Overview, page 166

RSA Key Management, page 169

Appendix C Enterprise Security Recording System Overview



Recording System OverviewThe 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.

Witness Recording System

Replay Server

Recorder Server

Configuration Server

Database Server

Archive Server

System Administrator’s PC

Supervisor’s PCAgent’s PC

CTI Server

Recorder Controller

Server

Call Center’s IP or TDM Telephony Network

PhonesSwitches &

IVR

Call Center’s Data Network

Key Management

Server

Data Storage

Storage Area Network

Security Administrator’s PC

Call Center Premises

Appendix C Enterprise Security Recording System Overview



Components of the Recording System include:

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

Appendix C Enterprise Security Recording System Security Features



Recording System Security FeaturesSystem 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:

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.

Appendix C Enterprise Security RSA Key Management



RSA Key ManagementThe 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:

More information on RSA’s Key Management software can be found in the RSA Key Manager Server 2.0 Administration Guide and in the RSA Key Manager Installation Guide.

Witness Recorder/Archive Servers

Call Center’s Data Network

Encrypted Recording Data On

Storage Devices

AES256

RSA Key Management Server

Encryption Key Database

SSL

SSL

RSA Key Manager Server RSA Key Management Client

Recorder /Archiver Components

Call Center’s IP or TDM Telephony Network

RecordingData

Appendix C Enterprise Security RSA Key Management



A p p e n d i x D

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 the following topics:

Recording with the IS, page 171

Performing Common Recorder Tasks, page 175

Data Sources Quick Reference, page 182

Recording with the ISRecording 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:

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:

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 Enterprise Manager Administration Guide.

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.

2 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




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 Administration Guide.

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 guide’s index then locate the terms Tutorial or Call Manager to obtain the exact page number.




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.

2 Click System > Data Sources. If a Data Source that you want to create already exists, skip steps 3-6. Go to Step 7.

3 Click Create.

4 Select the type of Data Source. (Note: The import utility is valid only for Phone (PBX/ACD), LAN and Trader Data Sources.)

5 Complete all necessary details such as name and description and then click Save.

6 With the Data Source still selected, click Import. The Import window displays.

7 Complete the Import window: Fill in the Name, and select Browse to browse to the file that has the import information.

8 If you need to import the file at a scheduled time, select Import Using Specified Date and Time.

9 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.




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:

For more information on Data Source Import/Export, including formats and examples, refer to the Enterprise Manager Administration Guide.

Performing Common Recorder TasksPerforming 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:

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

.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.




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:

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.

Recorder Recording Modes

RecordDo Not RecordStart at Business RuleApplication Controlled

Start/Stop on Tap = AlwaysStart/Stop on Tap = Never or in Fallback

Recorder ControlledCTI ControlledUnify Controlled

Recorder Channel Setting

Extension Recorder Control Type

Recording Modes for TDM




1 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).

2 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 Enterprise Manager Administration Guide.

3 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.

2 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.

2 With these settings, IS controls recording and records every call for the extension 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.




1 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).

2 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 Administration Guide.

3 Choose the Recorder Recording Mode. In EM, choose Data Sources > Phones, and then choose CTI Controlled from the Recording Mode menu.

With these settings, IS controls recording and records every call for the extension 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.

With these settings, IS controls recording and records every call for the extension 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.

Recorder Recording Modes

RecordDo Not RecordStart at Business RuleApplication Controlled

Protocol (Packet Handler) = NoneProtocol (Packet Handler) = SIP or SCCP

Recorder ControlledCTI ControlledUnify ControlledDuplicate Streaming Controlled

Recorder Channel Setting

Extension Recorder Control Type

Recording Modes for IP




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 PC’s 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 PC’s 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




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.




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 organization’s 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




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 guide’s 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.

2 Click the User tab, and type a username, password, and account status for the user.

3 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 User’s 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.

4 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.

2 In the Roles Setup tab, click Create New Role or select a role and click Edit Existing Role.

3 Follow procedures as described in help, or in the Creating Roles and Privileges section of the Enterprise Manager Administration Guide.

Data Sources Quick ReferenceThis 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




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:

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 Administration Guide.

Information is presented in the following sections:

Call Recording QuickStart, page 184

Screen Recording QuickStart, page 189

General Notes, page 191




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.

2 Create a Site. Click System > Installations, select Enterprise or a Group Site and then click Create.

3 Create a Recorder. Select the site you just created, and then click Installations > Create Installations > Server.

4 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.

5 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.

6 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.




7 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.




9 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.




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.

2 Configure the Recorder. Setup basic Recorder tasks such as archive and database settings. See Configuring Common Components.

3 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.




4 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.

5 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.

6 Assign Channels. Click Channels (TDM Recording only) and review extensions created earlier in the Data Source, and then click Save.

7 Restart servers. Click Operations > Start and Stop to restart RM(s).

You are now ready to record




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.

2 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).

3 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.

4 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.




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

6 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.

7 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.




8 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

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.

G l o s s a r y

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.

G l o s s a r y

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.

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

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.

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).

Glossary



I n d e x

Aadditional resources . . . . . . . . . . . . . . . . . 14administration server . . . . . . . . . . . . . . . . 83Ai-Logix

voice card attributes . . . . . . . . . . . . . . .121alarming component . . . . . . . . . . . . . . . . 75analyzer

high availability configuration . . . . . . . . . . .15710,000+ phones use . . . . . . . . . . . . . . .154

applicationSNMP. . . . . . . . . . . . . . . . . . . . . . 75

architectureadministration server . . . . . . . . . . . . . . . 83configuration . . . . . . . . . . . . . . . . . . 74ContactStore Plus . . . . . . . . . . . . . . . . 88disk management . . . . . . . . . . . . . . . . 78live monitor . . . . . . . . . . . . . . . . . . . 85retriever. . . . . . . . . . . . . . . . . . . . . 76

archivecentralized archiving . . . . . . . . . . . . . . . 34devices supported . . . . . . . . . . . . . . . . 52local . . . . . . . . . . . . . . . . . . . . . . 30parallel archiving. . . . . . . . . . . . . . . . . 31permitted drives . . . . . . . . . . . . . . . . . 30sequential archiving . . . . . . . . . . . . . . . 31tape drives . . . . . . . . . . . . . . . . . . . 30verify media . . . . . . . . . . . . . . . . . . . 31

Associated . . . . . . . . . . . . . . . . . . . . . 56associated call data, capturing . . . . . . . . . . . . 56audioserver, web observer . . . . . . . . . . . . . . 87auditing . . . . . . . . . . . . . . . . . . . . . . 67auto-detecting voice cards . . . . . . . . . . . . . . 54Avaya . . . . . . . . . . . . . . . . . . . . . . .111

configuring with CTI . . . . . . . . . . . . . . .114configuring without CTI . . . . . . . . . . . . .115DataSource . . . . . . . . . . . . . . . . . . .115

H.323 . . . . . . . . . . . . . . . . . . . . . 111Passive Recording . . . . . . . . . . . . . . . . 111recording calls. . . . . . . . . . . . . . . . . . 112tagging calls . . . . . . . . . . . . . . . . . . 113

BBalance replay . . . . . . . . . . . . . . . . . . . 89BDR server . . . . . . . . . . . . . . . . . . . . . 89business decision rules

as selective recording . . . . . . . . . . . . . . 35Contactstore Plus . . . . . . . . . . . . . . . . 89

Ccalculated custom data (See conditional custom data) . 127call buffer . . . . . . . . . . . . . . . . . . . . . 32call data

associated and non-associated . . . . . . . . . . 118associated, capturing . . . . . . . . . . . . . . 56

Call Manager, remote recorder cluster . . . . . . . . 152capture engine . . . . . . . . . . . . . . . . . . . 86CASS idle codes . . . . . . . . . . . . . . . . . . 64CCD. See conditional custom data . . . . . . . . . . 127CCE control . . . . . . . . . . . . . . . . . . . . 64centralized archiving . . . . . . . . . . . . . . . . 34CIC . . . . . . . . . . . . . . . . . . . . . . . . 15Cisco Call Manager . . . . . . . . . . . . 99, 100, 106Cisco Call Recording

DMS . . . . . . . . . . . . . . . . . . . . . . 100Cisco DMS . . . . . . . . . . . . . . . . . . . . . 100cluster

remote Call Manager . . . . . . . . . . . . . . 152single recorder . . . . . . . . . . . . . . . . . 150

collaboration recording scenario . . . . . . . . . . . 72component

call buffer. . . . . . . . . . . . . . . . . . . . 32

Index



configuration, status, and alarming . . . . . . . . 75disk manager . . . . . . . . . . . . . . . . .32, 78live monitor. . . . . . . . . . . . . . . . . . . 86

conditional custom data. . . . . . . . . . . . . . . 127conference bridge recording . . . . . . . . . . . . . 160configuration

architecture. . . . . . . . . . . . . . . . . . . 74components . . . . . . . . . . . . . . . . . . 74SNMP . . . . . . . . . . . . . . . . . . . . . 75status and alarming component . . . . . . . . . 75

Connectivity . . . . . . . . . . . . . . . . . . . . 50connectivity . . . . . . . . . . . . . . . . . . . . 50consolidator . . . . . . . . . . . . . . . . . . . . 32ContactStore Plus

Balance replay . . . . . . . . . . . . . . . . . 89streaming retriever . . . . . . . . . . . . . . . 90

ContactStore Plus, architecture . . . . . . . . . . . 88controll fallback . . . . . . . . . . . . . . . . . . 57conventions used in this guide . . . . . . . . . . . . 12CTI server . . . . . . . . . . . . . . . . . . . .27, 50CTI-driven events . . . . . . . . . . . . . . . . . . 61CTI-initiated contacts, capturing . . . . . . . . . . . 56custom data . . . . . . . . . . . . . . . . . . . . 126Customer Interaction Center. . . . . . . . . . . . . 15

Ddata sources, types . . . . . . . . . . . . . . . . . 35database

calls and media . . . . . . . . . . . . . . . . . 34configuration . . . . . . . . . . . . . . . . . . 81

D-channel . . . . . . . . . . . . . . . . . . . . . 63DDS5 Tape Drive . . . . . . . . . . . . . . . . . . 30delete by date . . . . . . . . . . . . . . . . . . . 32deployment

enterprise . . . . . . . . . . . . . . . . . . . 45multi-node . . . . . . . . . . . . . . . . . . . 44single-node . . . . . . . . . . . . . . . . . . . 42

diagnostic tools . . . . . . . . . . . . . . . . . . 179disaster recovery . . . . . . . . . . . . . . . . . . 30disk management architecture . . . . . . . . . . . . 78disk manager. . . . . . . . . . . . . . . . . . . . 78disk partitioning . . . . . . . . . . . . . . . . . . 80disk subsystem hardware . . . . . . . . . . . . . . 80DMS . . . . . . . . . . . . . . . . . . 99, 100, 106

Call Recording Scenarios . . . . . . . . . . 102, 107Cisco. . . . . . . . . . . . . . . . . . . . . . 100Load Balancing . . . . . . . . . . . . . . 105, 110load balancing, Cisco . . . . . . . . . . . . . . 105load balancing, Nortel . . . . . . . . . . . . . . 107Nortel . . . . . . . . . . . . . . . . . . . . . 106Recording Invocations . . . . . . . . . . . 101, 107recording scenarios, Cisco . . . . . . . . . . . . 102

recording scenario, Nortel . . . . . . . . . . . 107duplicate media streaming. See DMS . . . . . . . . 100DVD-RAM, DVD RW, +/-, 4.7 GB . . . . . . . . . . . 31dynamic workspaces. . . . . . . . . . . . . . . . . 91

Eenterprise deployment . . . . . . . . . . . . . . . . 45Enterprise Manager . . . . . . . . . . . . . 21, 66, 84ERSPAN . . . . . . . . . . . . . . . . . . . . . 161eWare 2CC module . . . . . . . . . . . . . . . . . 73express deployment . . . . . . . . . . . . . . . . . 42extension recording . . . . . . . . . . . . . . . . 147E1/T1 voice card attributes . . . . . . . . . . . . . 122

Ffailsafe procedures, archive. . . . . . . . . . . . . . 34fallback feature . . . . . . . . . . . . . . . . . . . 64file locations . . . . . . . . . . . . . . . . . . . . 80

Ggateway

high density . . . . . . . . . . . . . . . . . . 135recording . . . . . . . . . . . . . . . . . . . 14610,000+ phones . . . . . . . . . . . . . . . . 154

HHow do I ...

Active versus Passive recording . . . . . . . . . 174agents and workstations, work with . . . . . . . 181audit . . . . . . . . . . . . . . . . . . . . . 180calls, delete . . . . . . . . . . . . . . . . . . 180check import/export status . . . . . . . . . . . 176choose a Recorder Control Type . . . . . . . . . 176choose a recording mode . . . . . . . . . . . . 176Cisco Call Manager, DMS recording . . . . . . . 173contacts, replay . . . . . . . . . . . . . . . . 179data sources, different telecom switches . . . . . 173data sources, import . . . . . . . . . . . . . . 174Enterprise Archive, set up for . . . . . . . . . . 179find Agents not associated to an IS . . . . . . . 181find Recorder associations to IS . . . . . . . . . 181Integration Service, record with . . . . . . . . . 172IS and Unify, record using both . . . . . . . . . 172record station-side content . . . . . . . . . . . 173record trunk-side content . . . . . . . . . . . . 173recording events, view . . . . . . . . . . . . . 179record, IP content . . . . . . . . . . . . . . . 173screen recording, set up . . . . . . . . . . . . 179security, system . . . . . . . . . . . . . . . . 181

Index



troubleshoot with log files . . . . . . . . . . . . 180UDFs, work with . . . . . . . . . . . . . . . . 180Unify, record with . . . . . . . . . . . . . . . . 172

HP DAT72 . . . . . . . . . . . . . . . . . . . . . 30

IIDS load balancing algorithms . . . . . . . . . . . . 142implementation

CTI Servers . . . . . . . . . . . . . . . . . . . 50network operating system . . . . . . . . . . . . 50physical connectivity . . . . . . . . . . . . . . . 50voice cards . . . . . . . . . . . . . . . . . . . 51

implementation of TDM Recorder . . . . . . . . . . 50Intelligent Call Control Distribution . . . . . . . . . . 46intended audience . . . . . . . . . . . . . . . . . 10interfaces

live monitor. . . . . . . . . . . . . . . . . . . 86live monitor control . . . . . . . . . . . . . . . 86live monitor state . . . . . . . . . . . . . . . . 86recorder state . . . . . . . . . . . . . . . . . . 86streaming . . . . . . . . . . . . . . . . . . . 86

intrusion detection system (IDS), TopLayer. . . . . . . 134inum . . . . . . . . . . . . . . . . . . . . . . . 76Iomega REV drive . . . . . . . . . . . . . . . . . . 30IP Analyzer . . . . . . . . . . . . . . . . . . . . . 46IP routing . . . . . . . . . . . . . . . . . . . . . 48

Kkey management. See RSA key manager . . . . . . . 169

Llicense validation . . . . . . . . . . . . . . . . . . 54line voltage . . . . . . . . . . . . . . . . . . . . 64link protector

1+1 recorder topologies . . . . . . . . . . . . . 1391+1 TopLayer topologies . . . . . . . . . . . . . 140

live monitorarchitecture. . . . . . . . . . . . . . . . . . . 85capture engine . . . . . . . . . . . . . . . . . 86ContactStore Plus . . . . . . . . . . . . . . . . 89description . . . . . . . . . . . . . . . . . . . 85interface . . . . . . . . . . . . . . . . . . . . 86observer . . . . . . . . . . . . . . . . . . . . 87state component . . . . . . . . . . . . . . . . 87state interface. . . . . . . . . . . . . . . . . . 86streaming interface . . . . . . . . . . . . . . . 86web observer . . . . . . . . . . . . . . . . . . 87

live monitor control . . . . . . . . . . . . . . . . . 86live monitor state interface . . . . . . . . . . . . . 86load balancing

round robin . . . . . . . . . . . . . . . . . . 143source-destination . . . . . . . . . . . . . . . 144weighted round robin . . . . . . . . . . . . . 143

logging. . . . . . . . . . . . . . . . . . . . . . . 80

MManager . . . . . . . . . . . . . . . . . . . . . . 66MediaStore recorder . . . . . . . . . . . . . . . . . 73

Nnetwork operating system . . . . . . . . . . . . . . 50network topology . . . . . . . . . . . . . . . . . . 48non-CTI-driven events . . . . . . . . . . . . . . . . 61Nortel DMS . . . . . . . . . . . . . . . . . . . . 106n+1 recorder topology . . . . . . . . . . . . . . . 136

Oobserver . . . . . . . . . . . . . . . . . . . . . . 87

in administration server . . . . . . . . . . . . . . 84operating system, network . . . . . . . . . . . . . . 50

Pparallel archiving . . . . . . . . . . . . . . . . . . 31passive tap

Avaya . . . . . . . . . . . . . . . . . . . . . 114passive tap station-side recording . . . . . . . . . . . 40patches . . . . . . . . . . . . . . . . . . . . . . 80PBX . . . . . . . . . . . . . . . . . . . . . . . . 27PGAdmin III utility . . . . . . . . . . . . . . . . . . 80port span . . . . . . . . . . . . . . . . . . . . . 159PSTN . . . . . . . . . . . . . . . . . . . . . . . . 26

Rrecorder

scaling . . . . . . . . . . . . . . . . . . . . . 44Recorder Manager. . . . . . . . . . . . . . . . 20, 66recorder scaling (multi-node deployment) . . . . . . . 44recorder state interface . . . . . . . . . . . . . . . 86recording

supported . . . . . . . . . . . . . . . . . . . . 57recording system

security overview. . . . . . . . . . . . . . . . 166security summary . . . . . . . . . . . . . . . 168

redundant network feeds . . . . . . . . . . . . . 141remote Call Manager . . . . . . . . . . . . . . . 152resource scalability and IDS . . . . . . . . . . . . . 136retention period, in call buffers . . . . . . . . . . . . 32Retriever . . . . . . . . . . . . . . . . . . . . . . 89retriever

architecture . . . . . . . . . . . . . . . . . . . 76

Index



content server. . . . . . . . . . . . . . . . . . 76description . . . . . . . . . . . . . . . . . . . 76

round robinload balancing algorithm. . . . . . . . . . . . . 143

round robin, weighted . . . . . . . . . . . . . . . 143routing, IP . . . . . . . . . . . . . . . . . . . . . 48RSA . . . . . . . . . . . . . . . . . . . . . . . . 169RSA key manager. . . . . . . . . . . . . . . . . . 169

Sscaling. . . . . . . . . . . . . . . . . . . . . . . 44scaling, recorder . . . . . . . . . . . . . . . . . . 44SCCP

and IDS device . . . . . . . . . . . . . . . . . 135attributes, UDF . . . . . . . . . . . . . . . . . 1231+1 networks . . . . . . . . . . . . . . . 135, 140

screen recordingarchitecture. . . . . . . . . . . . . . . . . . . 91

search and replayin application server . . . . . . . . . . . . . . . 83in Contactstore Plus . . . . . . . . . . . . . . . 88in Enterprise Manager . . . . . . . . . . . . . . 21in live monitor . . . . . . . . . . . . . . . . . 86in retrieval architecture . . . . . . . . . . . . . 76in screen recording . . . . . . . . . . . . . . . 35in screen replay . . . . . . . . . . . . . . . . . 91security. . . . . . . . . . . . . . . . . . . . . 181server environment . . . . . . . . . . . . . . . 33unify mapping . . . . . . . . . . . . . . . . . 119

securityfeatures . . . . . . . . . . . . . . . . . . . . 168RSA key management . . . . . . . . . . . . . . 169

selective recording . . . . . . . . . . . . . . . . . 35sequential archiving. . . . . . . . . . . . . . . . . 31session-initiated protocol (SIP) . . . . . . . . . . . . 124single recorder cluster . . . . . . . . . . . . . . . . 150single-node deployment . . . . . . . . . . . . . . . 42SIP

attributes, UDF . . . . . . . . . . . . . . . . . 124SNMP application . . . . . . . . . . . . . . . . . . 75Sony AIT-3 Tape drives . . . . . . . . . . . . . . . 30source-destination, load balancing algorithm . . . . . 144SPAN

conference bridge . . . . . . . . . . . . . . . . 160encapsulated remote (ER) . . . . . . . . . . . . 161extension recording . . . . . . . . . . . . . . . 147gateway recording . . . . . . . . . . . . . . . 146port . . . . . . . . . . . . . . . . . . . . . . 159remote . . . . . . . . . . . . . . . . . . . . . 160VLSPAN . . . . . . . . . . . . . . . . . . . . 160

standard recorder script fields . . . . . . . . . . . . 125station-side, passive tapping . . . . . . . . . . . . . 40

status, configuration, and alarming component . . . . 75streaming interface, live monitor . . . . . . . . . . . 86streaming retriever

ContactStore Plus . . . . . . . . . . . . . . 89, 90subnets . . . . . . . . . . . . . . . . . . . . . . 91

Ttagging calls, Avaya . . . . . . . . . . . . . . . . 113TopLayer IDS device . . . . . . . . . . . . . . . . 134topologies

IP routing . . . . . . . . . . . . . . . . . . . . 48

UUDFs . . . . . . . . . . . . . . . . . . . . . . . 117unify

control fallback . . . . . . . . . . . . . . . . . 57features summary . . . . . . . . . . . . . . . . 27fields in standard script . . . . . . . . . . . . . 125search and replay mapping . . . . . . . . . . . 119

user defined fields . . . . . . . . . . . . . . . . . 117Ai-Logix card attributes . . . . . . . . . . . . . 121E1/T1 card attributes . . . . . . . . . . . . . . 122

Vverify media . . . . . . . . . . . . . . . . . . . . 31Viewer

in administration server . . . . . . . . . . . . . . 84viewer. See Search and Replay . . . . . . . . . . . . 33virus scanning. . . . . . . . . . . . . . . . . . . . 82VLSPAN . . . . . . . . . . . . . . . . . . . . . 160voice card

auto-detecting. . . . . . . . . . . . . . . . . . 54capturing voice-card iinitiated contacts . . . . . . . 57

voice cards . . . . . . . . . . . . . . . . . . . . . 51voice gateway . . . . . . . . . . . . . . . . . . 146VOX . . . . . . . . . . . . . . . . . . . . . . . . 61

Wweb observer, audioserver . . . . . . . . . . . . . . 87weighted round robin . . . . . . . . . . . . . . . 143Witplayer . . . . . . . . . . . . . . . . . . . . . 179workflow manager . . . . . . . . . . . . . . . . . 32

Numerical1+1 network feed topology . . . . . . . . . . . . 1411+1 recorder topology . . . . . . . . . . . . . . . 1391+1 TopLayer topology . . . . . . . . . . . . . . 140