Avaya IX WEM V15 2 Technical Overview

Avaya Workforce Engagement
Technical Overview
Version 15.2
June 14, 2023

Revision 1.29
Third Party Components
Certain software programs or portions thereof included in the Software may contain
© 2023 Avaya Inc. software (including open source software) distributed under third party agreements
All Rights Reserved. ("Third Party Components"), which may contain terms that expand or limit rights to use
Notice certain portions of the Software ("Third Party Terms"). Information regarding distributed
While reasonable efforts have been made to ensure that the information in this document is Linux OS source code (for any Software that has distributed Linux OS source code) and
complete and accurate at the time of printing, Avaya assumes no liability for any errors. Avaya identifying the copyright holders of the Third Party Components and the Third Party
reserves the right to make changes and corrections to the information in this document without Terms that apply is available in the Software, Documentation or on Avaya's website at:
the obligation to notify any person or organization of such changes. http://support.avaya.com/Copyright (or a successor site as designated by Avaya).
Documentation disclaimer The following applies only if the H.264 (AVC) codec is distributed with the product. THIS
"Documentation" means information published in varying mediums which may include product PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR
information, operating instructions and performance specifications that are generally made THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT
available to users of products. Documentation does not include marketing materials. Avaya RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE
shall not be responsible for any modifications, additions, or deletions to the original published AVC STANDARD ("AVC VIDEO") AND/OR (ii) DECODE AVC VIDEO THAT WAS
version of Documentation unless such modifications, additions, or deletions were performed ENCODED BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS
by Avaya. You agree to indemnify and hold harmless Avaya, Avaya's agents, servants and OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO
employees against all claims, lawsuits, demands and judgments arising out of, or in LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY OTHER USE.
connection with, subsequent modifications, additions or deletions to this documentation, to the ADDITIONAL INFORMATION MAY BE OBTAINED FROM MPEG LA, L.L.C. SEE
extent made by You. HTTP://WWW.MPEGLA.COM
Link disclaimer Service Provider
Avaya is not responsible for the contents or reliability of any linked websites referenced within THE FOLLOWING APPLIES TO AVAYA CHANNEL PARTNER'S HOSTING OF
this site or documentation provided by Avaya. Avaya is not responsible for the accuracy of any AVAYA PRODUCTS OR SERVICES. THE PRODUCT OR HOSTED SERVICE MAY
information, statement or content provided on these sites and does not necessarily endorse USE THIRD PARTY COMPONENTS SUBJECT TO THIRD PARTY TERMS AND
the products, services, or information described or offered within them. Avaya does not REQUIRE A SERVICE PROVIDER TO BE INDEPENDENTLY LICENSED DIRECTLY
guarantee that these links will work all the time and has no control over the availability of the FROM THE THIRD PARTY SUPPLIER. AN AVAYA CHANNEL PARTNER'S HOSTING
linked pages. OF AVAYA PRODUCTS MUST BE AUTHORIZED IN WRITING BY AVAYA AND IF
Warranty THOSE HOSTED PRODUCTS USE OR EMBED CERTAIN THIRD PARTY
Avaya provides a limited warranty on Avaya hardware and software. Refer to your sales SOFTWARE, INCLUDING BUT NOT LIMITED TO MICROSOFT SOFTWARE OR
agreement to establish the terms of the limited warranty. In addition, Avaya's standard CODECS, THE AVAYA CHANNEL PARTNER IS REQUIRED TO INDEPENDENTLY
warranty language, as well as information regarding support for this product while under OBTAIN ANY APPLICABLE LICENSE AGREEMENTS, AT THE AVAYA CHANNEL
warranty is available to Avaya customers and other parties through the Avaya Support PARTNER'S EXPENSE, DIRECTLY FROM THE APPLICABLE THIRD PARTY
website: SUPPLIER.
http://support.avaya.com/helpcenter/getGenericDetails?detailId=C20091120112456651010 WITH RESPECT TO CODECS, IF THE AVAYA CHANNEL PARTNER IS HOSTING
under the link "Warranty & Product Lifecycle" or such successor site as designated by Avaya. ANY PRODUCTS THAT USE OR EMBED THE G.729 CODEC, H.264 CODEC, OR
Please note that if You acquired the product(s) from an authorized Avaya Channel Partner H.265 CODEC, THE AVAYA CHANNEL PARTNER ACKNOWLEDGES AND AGREES
outside of the United States and Canada, the warranty is provided to You by said Avaya THE AVAYA CHANNEL PARTNER IS RESPONSIBLE FOR ANY AND ALL RELATED
Channel Partner and not by Avaya. FEES AND/OR ROYALTIES. THE G.729 CODEC IS LICENSED BY SIPRO LAB
"Hosted Service" means an Avaya hosted service subscription that You acquire from either TELECOM INC. SEE WWW.SIPRO.COM/CONTACT.HTML. THE H.264 (AVC)
Avaya or an authorized Avaya Channel Partner (as applicable) and which is described further CODEC IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR THE
in Hosted SAS or other service description documentation regarding the applicable hosted PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT
service. If You purchase a Hosted Service subscription, the foregoing limited warranty may RECEIVE REMUNERATION TO: (I) ENCODE VIDEO IN COMPLIANCE WITH THE
not apply but You may be entitled to support services in connection with the Hosted Service as AVC STANDARD ("AVC VIDEO") AND/OR (II) DECODE AVC VIDEO THAT WAS
described further in your service description documents for the applicable Hosted Service. ENCODED BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS
Contact Avaya or Avaya Channel Partner (as applicable) for more information. OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO
Hosted Service LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY OTHER USE.
THE FOLLOWING APPLIES ONLY IF YOU PURCHASE AN AVAYA HOSTED SERVICE ADDITIONAL INFORMATION FOR H.264 (AVC) AND H.265 (HEVC) CODECS MAY
SUBSCRIPTION FROM AVAYA OR AN AVAYA CHANNEL PARTNER (AS APPLICABLE), BE OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM.
THE TERMS OF USE FOR HOSTED SERVICES ARE AVAILABLE ON THE AVAYA Compliance with Laws
WEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO UNDER THE LINK "Avaya You acknowledge and agree that it is Your responsibility for complying with any
Terms of Use for Hosted Services" OR SUCH SUCCESSOR SITE AS DESIGNATED BY applicable laws and regulations, including, but not limited to laws and regulations related
AVAYA, AND ARE APPLICABLE TO ANYONE WHO ACCESSES OR USES THE HOSTED to call recording, data privacy, intellectual property, trade secret, fraud, and music
SERVICE. BY ACCESSING OR USING THE HOSTED SERVICE, OR AUTHORIZING performance rights, in the country or territory where the Software is used.
OTHERS TO DO SO, YOU, ON BEHALF OF YOURSELF AND THE ENTITY FOR WHOM Preventing Toll Fraud
YOU ARE DOING SO (HEREINAFTER REFERRED TO INTERCHANGEABLY AS "YOU" "Toll Fraud" is the unauthorized use of your telecommunications system by an
AND "END USER"), AGREE TO THE TERMS OF USE. IF YOU ARE ACCEPTING THE unauthorized party (for example, a person who is not a corporate employee, agent,
TERMS OF USE ON BEHALF A COMPANY OR OTHER LEGAL ENTITY, YOU subcontractor, or is not working on your company's behalf). Be aware that there can be
REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY TO THESE a risk of Toll Fraud associated with your system and that, if Toll Fraud occurs, it can
TERMS OF USE. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT WISH result in substantial additional charges for your telecommunications services.
TO ACCEPT THESE TERMS OF USE, YOU MUST NOT ACCESS OR USE THE HOSTED Avaya Toll Fraud Intervention
SERVICE OR AUTHORIZE ANYONE TO ACCESS OR USE THE HOSTED SERVICE. If You suspect that You are being victimized by Toll Fraud and You need technical
Licenses assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at
THE AVAYA GLOBAL SOFTWARE LICENSE TERMS FOR VERINT SOFTWARE +1-800-643-2353 for the United States and Canada. For additional support telephone
PRODUCTS AVAILABLE ON THE AVAYA WEBSITE, numbers, see the Avaya Support website: http://support.avaya.com, or such successor
HTTP://SUPPORT.AVAYA.COM/LICENSEINFO, OR SUCH SUCCESSOR SITE AS site as designated by Avaya.
DESIGNATED BY AVAYA, ARE APPLICABLE TO ANYONE WHO DOWNLOADS, USES Security Vulnerabilities
AND/OR INSTALLS THE SOFTWARE (AS DEFINED IN THE AVAYA GLOBAL SOFTWARE Information about Avaya's security support policies can be found in the Security Policies
LICENSE TERMS FOR VERINT SOFTWARE PRODUCTS), AND WHO PURCHASED THE and Support section of https://support.avaya.com/security Suspected Avaya product
LICENSE FROM AVAYA OR AN AVAYA CHANNEL PARTNER (AS APPLICABLE) UNDER security vulnerabilities are handled per the Avaya Product Security Support Flow
A COMMERCIAL AGREEMENT WITH AVAYA OR AN AVAYA CHANNEL PARTNER. (https://support.avaya.com/css/P8/documents/100161515).
REFER TO THE AVAYA SOFTWARE LICENSE TERMS FOR VERINT SOFTWARE Trademarks
PRODUCTS FOR INFORMATION REGARDING THE APPLICABLE LICENSE TYPES The trademarks, logos and service marks ("Marks") displayed in this site, the
PERTAINING TO THE SOFTWARE. Documentation, any Hosted Service(s), and product(s) provided by Avaya are the
All Rights Reserved registered or unregistered Marks of Avaya, its affiliates, or other third parties. Users are
Avaya and/or its licensors retain title to and ownership of the Software, Documentation, and not permitted to use such Marks without prior written consent from Avaya or such third
any modifications or copies thereof. Except for the limited license rights expressly granted in party which may own the Mark. Nothing contained in this site, the Documentation,
the applicable Avaya Global Software License Terms for Verint Software Products, Avaya Hosted Service(s) and product(s) should be construed as granting, by implication,
and/or its licensors reserve all rights, including without limitation copyright, patent, trade estoppel, or otherwise, any license or right in and to the Marks without the express
secret, and all other intellectual property rights, in and to the Software and Documentation and written permission of Avaya or the applicable third party.
any modifications or copies thereof. The Software contains trade secrets of Avaya and/or its Avaya is a registered trademark of Avaya Inc. All non-Avaya trademarks are the
licensors, including but not limited to the specific design, structure and logic of individual property of their respective owners.
Software programs, their interactions with other portions of the Software, both internal and Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
external, and the programming techniques employed. Downloading Documentation
Virtualization For the most current versions of Documentation, see the Avaya Support website:
The following applies if the product is deployed on a virtual machine. Each product has its own http://support.avaya.com, or such successor site as designated by Avaya.
ordering code and license types. Note that each Instance of a product must be separately Contact Avaya Support
See the Avaya Support website: http://support.avaya.com for product or Hosted Service
licensed and ordered. For example, if the end user customer or Avaya Channel Partner would
notices and articles, or to report a problem with your Avaya product or Hosted Service.
like to install two Instances of the same type of products, then two products of that type must
For a list of support telephone numbers and contact addresses, go to the Avaya Support
be ordered.
website: http://support.avaya.com (or such successor site as designated by Avaya),
scroll to the bottom of the page, and select Contact Avaya Support.
C o n t e n t s
About this guide 10

Workforce Optimization Overview 16
System Overview 17
Products 19
Recording Interactions 19
Interactions 20
Speech Analytics 21
Text Analytics 22
Interaction Analytics 23
Workforce Management 24
Branch Forecasting 24
Scorecards 25
Coaching 25
eLearning 26
Customer Feedback 26
Desktop and Process Analytics (DPA) 26
Management Services 28
Dashboard 28
System Management 29
Organization Management 29
User Management 30
Framework Layer 31
Web Services 31
Authentication 31
Mobile Apps 32
Logical Architecture 33
Logical Architecture Overview 34
Logical Building Blocks—Server Roles 35
Data Center 36
Databases 37
Web Applications 38
Data Processing 38
Reporting Services 39
Sites 40
Content Access 43
Integration Services 43
Recorder, Content Access, and Integration Services 44
Recorder (ACR only) 44
Recorder (ACRA only) 44
Recorder Ingestion Web Service 44
Content Storage 45
Content Processing 45
Recorder Analytics Framework 45
Analytics Service 46
Data Processing Types 47
Analytics Engines 47
Desktop 49
Customer Environment 50
Deployment and Scalability 51
Deployment Overview 52
Platforms and Server Roles 54
Deployment Principles 55
Deployment Levels 56
Databases by Platform 58
Physical Deployment Use Case 59
Data Flows 61
User Management Data Flows 62
Generic User Setup 63
Applications User Setup 64
Recording Data Flows 67
Setting Recording Environment Properties Data Flow 67
Recording Process and Media Storage Data Flow 69
Recording and Storage 69
Recording and Storage: Recorders Using Import Manager 72
Playback Interaction Data Flows 74
Playback Interaction Data Flow: Query and Select Interaction 75
Playback Data Flow: Search for Interaction 77
Search for Interaction in Recorder Site 79
Search for Interaction Using Site-Dependent Playback 84
Playback Interaction Data Flow: Retrieve Interaction using ActiveX 87
Playback Interaction Data Flow: Retrieve Interaction using HTML5 Streaming 89
Real-Time Monitoring Data Flow 90
Real-Time Monitoring—Retrieving Employee Information 90
Real-Time Monitoring—Streaming Audio 93
Automated Quality Management(AQM) Data Flows 95
Fully automated evaluation setup data flow 96
Avaya Workforce Engagement Technical Overview 4
Confidential and Proprietary Information of Verint Systems Inc.

Fully automated evaluation data flow 98
Speech Analytics Data Flows 102
Import Ontology Data Flow 102
Speech Analytics Transcription Data Flow 104
Transcription Configuration Data Flow 104
Retrieve Tasks for Transcription Data Flow 107
On-premises transcription data flow 109
Cloud Verint Da Vinci Speech Transcription Service data flow 110
Interaction Analytics Export Service data flow 113
Training Data Flow 116
Speech Analytics Index & Themes Data Flow 118
Index Data Flow 118
Indexed Data Integration Flow 120
Themes Data Flow 124
Speech Analytics Application Data Flow 126
Speech Analytics Agent Signature Builder Data Flow 128
Speech Analytics Pipeline Flow 130
Text Analytics data flows 131
Text Analytics data ingestion flow 132
Text Analytics application data flow 134
Text Analytics model management data flow 135
Text Analytics alarms and monitoring flow 136
TAS alarms and services mapping reference 137
Interaction Analytics application data flow 138
Encryption Data Flows 140
Recording With Encryption Data Flow 141
Recording Using Import Manager With Encryption Data Flow 142
Playback Interaction with Encryption using ActiveX Data Flow 145
Playback Interaction with Encryption using HTML5 Streaming Data Flow 146
Speech Analytics Encryption Flows 148
Speech Analytics Audio and Video File Decryption Data Flow 148
Speech Analytics Transcript Storage Data Flow 150
Speech Analytics Transcript Retrieval Data Flow 152
Desktop Messaging Data Flows 154
Desktop Message Sent On Demand 155
Desktop Messages Sent by Organization Alert Rules 156
Desktop and Process Analytics Data Flows 157
DPA client/server data flow 157
DPA Reporting data flow 158
DPA Integration with WFM Data Flows 160
View DPA Applications in Player Data Flow 162
View Interactions Data in Timeline Report Data Flow 163

Archive Topologies 165
Local Archive Topology 165
Central Archive Topology 167
Local vs. Central Archive 168
Database Processes 171
Database ETL Flows 171
Database Retention and Purging 173
Reporting data flow 175
System Redundancy 177
Introduction to System Redundancy 178
Data Center Zone High Availability Solutions 179
Data Center Redundancy 179
Database High Availability solutions 179
Windows and SQL Cluster solution 180
SQL Server AlwaysOn solution 181
Application Server High Availability Solution 184
End-to-End Encryption 185
Additional High Availability Solutions 185
Site Zone High Availability Solution 187
Archive Server High Availability Solution 187
Speech Transcription Servers High Availability Solution 187
Product High Availability Support 188
System Management 191
System Management Overview 192
System Management Services 193
Configuration Data Flow 197
Alarms Data Flows 202
Generation of Alarms on a Server 202
Display of Alarms in the Alarm Dashboard 204
Networking and Security 206
Security Overview 207
Secure Sockets Layer (SSL) Protocol 208
End-to-End Encryption (ACR only) 209
End-to-End Encryption (ACRA only) 210
Pausing and Resuming Recording 211
Networking 212
Data Center SSL offload 212
Mobile Networking 212
Firewalls 213
Domain Trust 214
Remote Access 215

System Rights, Settings, and Services 216
Anti-Virus Support 217
Server and Service Authentication Methods 218
Token authentication methods 218
Application Security 223
Mobile device management 224
User Management Permissions 226
Generic User Permissions 226
Audit Trail 227
Time Management 228
Time Management Overview 229
System Time, User Time and Local Time 230
Time Configurations 231
Time Zone Settings Use Case 232
Daylight Savings Time (DST) Handling 234
System Monitor, Audit Trail and Recording Rules Time Settings 235
Recording 236
Overview 237
Recording Functions 238
Contacts and Interactions 238
Call Data and CTI Tagging 239
Recording Decisions 240
Recording Types 243
IP Recording 243
Gateway Recording 243
Extension-side Recording 245
VoIP Delivery 245
RTP Detection 245
SIP Trunk Recording 246
Implementation 246
RTP Proxy Recording 247
TDM Recording 247
TDM Trunk-Side Recording 247
TDM Station-Side Recording 249
Attributes Provided by Card Model Families 250
Attributes Provided by E1/T1 Voice Cards 250
Topologies 252
ADC 252
High Density Gateways 253
Resource Scalability 253
Even Resource Utilization 254

Less Network Traffic 254
Fewer Resources Required 254
Simplification of Network Topology 254
Single Recorder Cluster 255
Single Recorder Cluster Components 255
Usage for Single Recorder Cluster 256
Licensing for Single Recorder Cluster 256
Application-level Recorder Health Check 256
High Availability 256
High Availability Design Examples 257
Redundant Network Feeds 258
IP Recorder Filtering 260
Text Analytics Architecture 261
Text Analytics architecture overview 262
Interaction Capture 263
Text Application 264
Text Analytics Service (TAS) 264
Text Analytics Service deployment levels 269
TAS service mapping 271
Mobile solution 273
Verint mobile solution overview 274
Mobile networking and communication security 275
Typical network topology 275
Supported HTTPS configurations 275
Access to Google (FCM) and Apple (APNS) 276
VPN tunneling 276
Authentication and authorization 277
User authentication 277
Authorization 277
Session (access) token 278
Refresh token (long-term sign in token) 278
Authentication flows 278
OpenID Connect initial authentication flow 279
OpenID Connect silent re-authentication using the refresh token 280
LDAP/DB authentication initial authentication flow 281
LDAP/DB authentication silent re-authentication using the refresh token 282
User termination 282
Data-at-rest and mobile device security 283
High availability and redundancy 284
High availability 284

Denial of Service (DoS) protection 284
Disaster recovery 284

P r e f a c e
About this guide
The Workforce Optimization Technical Overview provides an overall description of the

Workforce Optimization Suite.
It includes logical and physical architectures, deployment models, data flows, time
management, system management, security, redundancy configurations and recording.
Intended audience
This guide is designed to be used by:
 Company and Business Partner professional services staff or any party responsible for
planning and setting up systems
 All customer staff involved in system deployment
 Customer system administration and IT staff responsible for site preparation and
installing workstations
 Systems Field Services and partners responsible for installing workstations as part of the
suite installation and site acceptance testing
Document revision history
Revision Description of changes
1.29 Access to Google (FCM) and Apple (APNS):

 Renamed from Access to Google (FCM), Apple (APNS), and Verint Cloud
Services (VCS).
 Removed the need for the mobile gateway to have access to the VCS.
1.28 In the End-to-End Encryption topic, clarified that files are encrypted with a
certified industry standard string algorithm (AES 256 using CTR mode).
1.27 In the End-to-End Encryption topic, deleted RSA KMS content and updated
Thales KMS content.
About this guide
1.26 Minor corrections.
1.25  In the System Overview, removed the bulleted list of products, and
replaced it with the main products in the WFO suite.
 In Products, rearranged the list of products and removed Branch
Forecasting from the list.
 In Data Center, updated the Data Center graphic to include the
Interaction Analytics Application and Recorder Central Web Services
application under Web Applications, and removed the Web Services
group.
 In the topic, Token authentication methods, removed the description for
Additional security.
 In the Data Flows chapter, removed the Web Services component from
many different data flows, and updated the corresponding text.
1.24 Updates for V15.2 2021R1:

 Removed the requirement to enable outband communication to VCS
for automated certificate renewal.
 Speech Analytics Data Flows:
 Speech Analytics Transcription Data Flow: Updated transcription data
flow description to differentiate between on-premises and cloud-

based transcription flows.
 On-premises transcription data flow: Changed title to indicate on-
premises flow.
 Cloud Verint Da Vinci Speech Transcription Service: New data flow
describing the transcription flow in the cloud.
1.23 Speech Analytics Data Flows:

 Interaction Analytics Export Service data flow: New data flow describing
how interaction transcriptions are exported using PRM rules.
 Speech Analytics Pipeline Flow: Added a note that the maximum number
of interactions in the queue is 3 Million (default).
1.22 Updated the ETL job names in the Database ETL dataflow.
1.21 Updates for V15.2 2020R1:

 Transcription Data Flow: Updated flow diagram and step 2 to indicate
that media is retrieved from the Media Provider on the Recorder
instead of the Content Server.
 Added "Secure RIS to remote recorder communications" in the End-to_
End Encryption topic.
 Avaya renaming.

About this guide
1.20  Added a new flow for HTML5 streaming replay with encryption,
Playback Interaction with Encryption using HTML5 Streaming Data Flow.
 Renamed Playback Interaction with Encryption Data Flow to Playback
Interaction with Encryption using ActiveX Data Flow.
1.19 Updated the platforms and server roles mapping table.
1.18 Mobile solution section: Under Data-at-rest and mobile device security, added
user's first name and last name to the list of data that is saved on mobile
devices.
1.17  Updated Mobile Solution section with more in-depth information.

 Under Networking and Security, added new section 'Mobile device
management'.
1.16 Updates for V15.2 HFR7:

 Renamed "Recorder Platform Analytics" to "Real-Time Analytics
(RTA) Framework"
 Changed Text Capture to Interaction Capture
 Added chapter on Desktop Process Analytics Architecture
 Avaya renaming.
1.15  Changed title of Introduction to Workforce Optimization Technical

Overview
1.14  HFR5 Updates

 Under "Authentication", removed that Azure is the only supported
IdP for OpenID Connect.

 Updated the mobile app names to Verint Mobile Team View and
Verint Mobile Work View

 Updates to Mobile solution:
 Under Mobile Gateway architecture, updated the diagram
 Updated Mobile Gateway security to include the IdP sign in process
1.13  Removed references to the legacy Mobile App, which has been
deprecated
 Clarified the possible implementations of the SQL Server AlwaysOn
feature
1.12  Added new Automated Quality Management (AQM) data flows for fully
automated evaluations
 Updated "Additional Resources" in the Recording chapter to reflect
currently supported integrations

About this guide
1.11 The "Configuration Data Flow" topic in the "System Management" chapter
is modified to show that the EMA now pulls configuration changes from
Enterprise Manager. In previous releases, Enterprise Manager pushed
configuration changes to EMA.
1.10 Updates for HFR4:

 Updated the Deployment Overview section regarding the applicable
hardware types
 Section Products in Chapter 1: Added Discover Highlights workspace to
Interaction Analytics
 Chapter 10: Added new section, TAS service mapping.
 Updated the Sites section to include Avaya Contact Recorder Advanced
(ACRA)
 Added the Recording Data Flows, Playback Interaction Data Flows, and
Archive Topologies sections to the Data Flows chapter for ACRA
 Added the Archive Server High Availability Solution section for ACRA
 Added the End-to-End Encryption (ACRA only) section for ACRA
1.09 Added the SQL Server AlwaysOn solution to the Database High Availability
Solutions section
1.08 Revised Thales KMS description in the End-to-End encryption topic
1.07 Added description of new Verint TeamView mobile app to Mobile Solution
section

About this guide
1.06 Updates for HFR3:

 Chapter 1- Introduction:
 Section Products: Added description of "Interaction Analytics".
 Section: System Management: Removed Information collector
service from list.

 Section: Transcription Data Flow:
 Updated diagram to include DAS Web API component
 Added steps 4 and 5 to data flow description
 Section: Text Analytics data flows: added "Text Analytics alarms and
monitoring flow"
 Added topic for "Interaction Analytics application data flow"
 Section: System Management Services: Removed Information Collector
service from list of services.
 Modified "Real-Time Monitoring–Retrieving Employee Information" and
"End-to-End Encryption" for Cloud Screen Capture.
 Section Text Analytics Service (TAS): added description of Alarms and
Monitoring Service (AMS) to list of TAS services
 Updated with new document template.
1.05 Updates
1.04 Updated diagram in Databases by platform section: Moved ETL Staging

Database from Framework Database to Data Warehouse
1.03 Updates for V15.2 HFR2 for Real-Time Analytics (RTA) Framework:
 Renamed server role "Biometrics Engine" to "Voice Biometrics Engine".
 Renamed server role "Enrollment Engine" to "Voice Enrollment Engine".

About this guide
1.02 The following changes were made for this release:

 Chapter 1- Introduction
 Products section: Added description of Text Analytics
 Chapter 2 - Logical Architecture

 Data Center section diagram: Added Text Indexing Service (TINS) to
Databases, and Text Analytics Services to Data Processing

 Data Processing section: Added paragraph on Text Analytics
 Chapter 3 - Deployment and Scalability

 Deployment Levels section: Replaced Speech Analytics in diagram
with Speech & Text Analytics

 Chapter 4 - Data Flows
Added new section entitled Text Analytics data flows with the following:
 Text Analytics data ingestion flow
 Text Analytics application data flow
 Text Analytics model management data flow
 Chapter 10 - Text Analytics Architecture

 New chapter describing Text Analytics Services architecture and
deployment levels
1.01 Logical Architecture chapter:

 Sites section: Added the Real-Time Analytics Engine to the Analytics
Engine section in the diagram and in the table.
 Recorder Analytics section: Added the Real-Time Analytics Engine to the
diagram.
 Server and Service authentication methods section: content which was
previously in the Security Configuration guide. New service web token
(SWT) added to this section as well.
1.00 Initial release.

C h a p t e r 1
Workforce Optimization
Overview
Workforce Optimization products and services are designed to help organizations of all
sizes. The WFO suite reduces operating costs, identify revenue opportunities and
competitive advantages, and improves performance, profitability, and the customer
experience.
Topics
System Overview 17
Products 19
Management Services 28
Framework Layer 31
Workforce Optimization Overview System Overview
System Overview
Workforce Optimization products and services are designed to help organizations of all sizes. The
WFO suite reduces operating costs, identifies revenue opportunities and competitive advantages. In
addition, it improves performance, profitability, and the customer experience.
The solution provides functionality for Recording, Workforce Management (WFM), Desktop and Process
Analytics (DPA), Speech Analytics, Text Analytics, and others.
The system offers the Verint Mobile Work View and Verint Mobile Team View mobile apps. The mobile
apps provide employees and managers with the core benefits of the Workforce Optimization Suite
from their mobile devices.
The WFO solution is a feature rich, end-to-end enterprise solution that provides a modular
architecture and deployment model, and a modern and customizable user interface.
The core elements of the system include:
 Rich, client application with modern UI capabilities (such as drag & drop and dynamic resizing)
 Single workspace with inter-application functionality and data sharing
 Efficient user application workflows with enhanced reporting and dashboards
 Market-leading speech performance with unique Semantic Intelligence capability
 Enhanced serviceability, simplified deployment, secure operations, and low TOC

Workforce Optimization Overview System Overview
Workforce Optimization Suite
Recording Interactions Coaching Text Analytics

Interactions eLearning Customer Feedback
Workforce Management (WFM) Real-Time Analytics (RTA)
Products Desktop and Process Analytics (DPA) Interaction Analytics
Scorecards Speech Analytics
System Management Dashboard Management
Management
Organization Management User Management
Services
Configuration Authentication Services
Web Services Mobile App Services

Framework
System Layer Description
Products, page 19 Provides all the products in the system suite, which
together provide functionality and services to users.
Management Services, Provides applications and utilities that allow users to

page 28 view, manage, and configure system entities and
product functionality.
Framework Layer, page 31 Provides the software infrastructure layer in the system,
enabling system configurations, web services,
authentication, and mobile apps.

Workforce Optimization Overview Products
Products
The system products include:
 Recording Interactions, page 19: Provides a recording and archiving infrastructure that records and
stores audio, video, and screen data for compliance, customer analytics, and Workforce
Optimization.
 Interactions, page 20: Provides you with the ability to search and play back employee-customer
interactions, and perform quality monitoring activities to improve the customer experience.
 Workforce Management, page 24: Helps measure and take advantage of the individual talents and
preferences of each employee. WFM uniquely ensures that employee skills and proficiencies are
aligned with business objectives and customer needs, and helps produce optimum schedules.
 Desktop and Process Analytics (DPA), page 26: Captures events and data from employee desktops
and makes them easy to act on.
 Scorecards, page 25: Helps agents, supervisors, and all contact center employees focus on critical
aspects of their performance and identify opportunities for improvement.
 Coaching, page 25: Addresses the needs of managing all aspects of inter-personal performance
optimization efforts.
 eLearning, page 26: Provides hard skills and soft skills training applicable for the entire agent life
cycle (before, during, and after the hiring process). eLearning provides training assessment and
design tools.
 Interaction Analytics, page 23: Provides unified data from both Speech and Text Analytics for
category and term trends, and themes.
 Speech Analytics, page 21: Analyzes ongoing changes in customer behavior and drives effective
organizational changes needed to address challenging market conditions.
 Text Analytics, page 22: Analyzes text-based interactions to identify what customers are engaging
with in organizations, and how they are engaging with the products and services for insights into
customer experience.
 Customer Feedback, page 26: Provides a highly reliable, scalable, and flexible voice and Web/email
system for conducting intelligent and dynamic post-call and post-contact surveys.
Recording Interactions
Contact recordings provide the raw intelligence for subsequent customer analytics and workforce
optimization.
The Recording and Archiving system provides the following features:
 Records VoIP and TDM audio through a variety of passive interception and delivery/termination
interfaces
 Records IP-based video conferencing

 Efficiently records PC screens, minimizing network bandwidth requirements

 Integrates to PBX, ACD and Dialer CTI interfaces for call events, meta-data and business rules driven
recording
 Provides real-time monitoring of phones calls and PC screens
 Optionally encrypts contact content for secure storage and transmission
 Flexibly manages contact for short-term storage and long term archive on many different types of
storage devices
 Provides telephony and PC speaker-based playback
 Provides real-time speech analysis on recorded audio
Interactions
The Interactions application provides you with the ability to search and play back employee-customer
interactions. It also performs quality monitoring to improve employee performance and the
customer experience.
The Interactions application supports the following:
Search and playback

You can search for and play back recorded interactions, and save frequently used searches for easy
access.
 If the screen capture feature is available to record employee workstation screens, the recorded
screens are played back alongside the audio portion of an interaction.
 If video recording is available, the video conference portion of an interaction can be played back
alongside the audio portion of an interaction.
 If speech analytics is available, the speech transcription is displayed alongside the audio portion of
an interaction.
 If interaction capture is available, the text interaction can be viewed.
 If full-text search is available, you can search for interactions that include specific terms or phrases,
and use operators to optimize your search.
Evaluations
You can manage the entire employee evaluation, feedback and development process, quickly
highlighting gaps in employee skill sets, and enabling prompt corrective action to improve
performance.
Using the Inbox, you can let the system automatically select which interactions are pushed for
evaluation. You can evaluate employee recorded interactions. In addition, employees can use the
evaluation process to perform their own self-evaluation. You can also assess the entire customer
experience among multiple interactions.

AQM automated and partially automated evaluations

You can fully or partially automate the evaluation process. In fully automated evaluations, the system
selects interactions that match specific criteria and automatically evaluates them. In partially
automated evaluations, users select the interactions to evaluate, and upon accessing the evaluation
form, the system automatically answers some of the questions in the form.
Workflow
You can flag interactions and evaluations and place them in folders for subsequent review and action.
Alerts inform employees and managers that a new interaction or evaluation has been placed in a
folder for their review and action.
Real Time Monitoring and Evaluation

You can monitor and evaluate interactions and screens in real time.
Reports
You can generate canned and ad hoc reports on evaluation scores, evaluation activities and recorded
interactions. You can also run analysis reports to uncover trends and relationships within
interactions.
Speech Analytics
Speech Analytics provides you with valuable insight into the key business issues in your enterprise. By
analyzing critical business data from millions of customer-employee interactions, you can understand
the performance issues and act quickly.
The Speech Analytics application delivers fast results through main workflows that are designed
around user tasks.
The main features include:
 Discover: Displays what the system has automatically surfaced for you.
 Analyze: Provides tools to analyze what you have discovered, and to perform ad-hoc analysis. You
can drill down and interact with the data in a meaningful way to find specific information.
 Report & Design: Generates and stores reports created during your analysis. Design allows you to
create and change categories.
Discover
Discover tells you what is happening or changing, and what to look into that you did not know about:
 Discover Trends: Trends surface changes in categories and terms stated in employee-customer
interactions. By analyzing these changes, you can understand emerging business phenomena, and
pinpoint significant events that require close attention. Trends also reveal critical information you
were not aware of, and identify process or service issues before they escalate.
 Discover Themes: Themes are groups of expressions that have similar meaning in your data. Themes
help you understand what is happening in your calls, without the need to know what to look for in
advance. By reviewing the volume of interactions represented by a theme, you can understand the
magnitude of the business issue.

Analyze
Analyze allows you to perform an ad-hoc analysis. It is helpful when you know what you need to
investigate and want to find the drivers and impact of the business issue:
 Search Capabilities and Suggest: You can focus on a specific business issue by searching for
interactions that include specific terms or phrases stated in the conversation. The enhanced
Suggest feature displays a list of words used within the same context as your search entry. You can
also view more terms with which your term is closely related, and longer phrases that include your
term.
 Analyze Categories: Speech Analytics categories group interactions that deal with specific business
issues. View statistical information about the categories defined in the system. Investigate how
interactions are distributed among the categories to understand the nature of employee-customer
interactions.
 Analyze Charts: You can use charts to view and analyze statistical information about all interactions
or a subset of interactions retrieved by your search. Charts help you identify trends in the
interactions.
 Analyze Context: Focus your search on interactions that are most related to the business issue you
are investigating by analyzing the context in which specific terms are used. Analyze Context displays
terms used within the same context in a visual term tree view.
 Analyze Root Cause: You can understand the potential drivers of a defined data set by analyzing
possible root causes surfaced automatically by the system.
Tune
Allows language model managers to review the suggestions submitted by employees for incorrectly
transcribed terms and phrases, collated per language and vocabulary. You can then replace with a
different suggestion, and approve or reject the suggestion. Approved suggestions are exported for
integration into the language model through Phonetics Boosting.
Report & Design

You can view reports you have generated during your analysis, and export these reports into
different formats. You view use reports to view specific data, analyze the data with external tools, or
share the data with users throughout the enterprise.
You can also design new categories based on the information that you want to focus on in your
business, in preparation of the analyze stage. Design categories that define the type of interactions
you want to analyze, and after, focus your business on what your customers want and need.
Text Analytics
Text Analytics provides data on text-based interactions in your enterprise. View and analyze the data in
the Text Analytics application to gain valuable insights into key business issues in the enterprise.
You can analyze the data by themes, key terms, and categories, which represent classifications of text-
based data. Themes and key terms are automated classifications, while categories are user-defined
classifications. In addition, you can analyze the sentiment associated with themes, key terms, and
categories.

The main features include:

 Discover: Displays what the system has automatically surfaced for you.
 Analyze: Provides tools to analyze what you have discovered, and to perform ad-hoc analysis. You
can drill down and interact with the data in a meaningful way to find specific information.
 Content analysis allows you to visualize and analyze the data across interactions by themes and
categories, and correlate the data with operational metrics.
 Interaction analysis allows you to preview the entire text of interactions in dialog formats, and
analyze the context in which terms are used.
Discover trends
Discover Trends to view what the Analytics Engine automatically surfaces for you, and track what is
trending for different content types over different periods of time — current or historical:
 Check Trending tables to identify text elements with the maximum change, based on the relative
change within selected period of time.
 Leverage Speaker Separation to isolate topics and relations according to usage by the employee or
the customer.
 Analyze Trend View charts to view day-to-day trend behavior over time for individual text elements
from Trending tables.
Analyze content and interaction text

Analyze content to perform an ad-hoc analysis, investigate and identify the drivers and impact of the
business issue:
 Quick Filters: Locate the text-based interactions to analyze by project and date range. Filter also by
predefined content types such as topics and relations, by user-defined categories, by system-
generated metadata elements, by sentiment, and by organizations or employees.
 Free-text search: In parallel, use free-text queries, with or without conditional operators, to search for
specific terms or phrases.
 Analyze Content : Get a visual representation of how the text elements are distributed across
interactions for different content types, and compare operational metrics for the current search.
 Analyze Interactions: Display the text of selected interactions or contacts, and data relevant to the
interaction.
Interaction Analytics
Interaction Analytics provides unified data on interactions from both Speech and Text-based sources
in your enterprise in the same location. Viewing related data from different media such as calls, emails,
and chats, provides valuable insights for better understanding performance issues, and find solutions.
Create an Interaction Analytics project by mapping the Speech and Text projects that best represents
the business issue you want to analyze, and see trends and themes the system surfaces from the
millions of interactions.

Discover highlights
View short-term or long-term snapshots of key interaction metrics and trending categories for the
Speech and Text projects mapped to an Interaction Analytics project.
Discover trends and themes

Discover trends and themes surfaced by the system for all sources in the same location:
 Discover Trends: See which categories and terms are trending, based on the relative change within
the selected period of time, and in the Trend View compare day-to-day trend behavior over time for
specific categories and trends.
 Discover Themes: Themes are groups of expressions that have similar meaning in your data. Review
theme content as either relations or concepts to understand what is happening, without the need to
know what to look for in advance.
 Analyze trends and themes: Analyze trending categories, terms, or themes, based on their source, in
the Speech and Text workspaces for further investigation.
Workforce Management
The Workforce Management (WFM) solution helps measure and capitalize on the individual talents
and preferences of each employee. WFM uniquely ensures that employee skills and proficiences are
aligned with business objectives and customer needs, and helps produce optimum schedules.
WFM is part of a unified analytics-driven WFO solution. It interoperates with Quality Monitoring to
incorporate agent quality scores easily for better schedules that have the right blend of agent quality.
It interacts with eLearning and Coaching to receive learning and coaching requests that can be
scheduled at the appropriate time without impacting service levels. Integrated Scorecards come with
pre-defined quality and productivity KPIs that are displayed in role appropriate Scorecards for
consistent communication across all levels of the center.
Branch Forecasting
Branch Forecasting provides an intuitive solution for resource scheduling at your branches. Branch
Forecasting pushes forecasting and planning data to Workforce Management to use when scheduling
resources.
Branch Forecasting is an application that predicts the number of resources required for bank branches
to complete their forecasted daily banking transactions. The forecasted data is then pushed and used
alongside Branch Forecasting scheduling, to create work schedules for the bank branch resources.
A resource is an employee of the bank, which could include a bank teller, customer service agent, or
manager. Branch Forecasting generates volume (transaction) forecasts, resource forecasts, and staff
mix forecasts. A variety of standard reports are also provided that allow you to view the forecasted
data in different scenarios. The forecasts can then be integrated with a Branch Workforce
Management site to create schedules based on your forecasted needs.
Branch Forecasting uses past transactional history to help you predict future resource requirements.
The application's algorithms use data from time studies and your organization's Electronic Journal (EJ)
system to develop an accurate forecast for your resource requirements.

The application uses a highly customized model of your organization to provide forecasting and
reporting services related to your resources and their workload. The most important part of this is a
forecast of resource requirements, measured in full time equivalents (FTE). A standard resource
forecast is stored by 30-minute increments.
Branch Forecasting is part of the Workforce Optimization suite. Many of the Branch Forecasting
features are optimized by the applications in the WFO suite.
Related topics
Workforce Management, page 24
Related information
Branch Forecasting User Guide
Scorecards
The Scorecards module helps agents, supervisors, and all contact center employees to focus on
critical aspects of their performance and identify opportunities for improvement.
With Scorecards, users can address complex questions such as:
 Which agents and teams are performing to expectations?
 Where do I spend my coaching time? Which agents? Which teams?
 How is one agent performing relative to their peers?
 How much did Team B improve since completing the new training?
The Scorecards component can be deployed rapidly with no custom integrations.

Pre-defined KPIs and integration adaptors are available out-of-the-box for Quality Monitoring,
Workforce Management, Learning, Interaction Analytics, and qualified ACD systems. These tools
enable an organization to be up and running with role-appropriate Scorecards based on best practice
KPIs in a minimum of time.
Scorecards allow users to understand their KPIs in context by displaying the KPI results relative to
goal, relative to peers, and as trend graphs. Supervisors and Managers can provide feedback beyond
the automated scoring provided in the scorecard with the Assessments feature.
Coaching
Coaching directs, instructs, and trains a person or group of people, with the aim of achieving a set
goal or developing specific skills. The Coaching solution effectively addresses the needs of managing
all aspects of inter-personal performance optimization efforts.
Coaching:
 Provides employees with personalized guidance on how to improve their performance and extend
their skills.
 Helps ensure visibility, accountability, and fairness in staff development practices.

 Improves staff morale and retention.

 Delivers better service to customers.
eLearning
The eLearning offering is divided into the following components:
 Lesson Management: Provides both hard skills and soft skills training. Lesson Management
enables employees to do their jobs successfully, no matter what stage of the life cycle—before,
during, and after the hiring process.
 Competency Based Learning: Provides everything provided by Lesson Management, in addition to
automatically assigning, delivering, and assessing training. Competency Based Learning simplifies
the tasks associated with assigning and managing training. It also enables your contact center to
deliver personalized learning efficiently through the entire agent life cycle — before, during, and
after the hiring process.
Customer Feedback
The Customer Feedback solution provides a highly reliable, scalable, and flexible Voice and
Web/email system for conducting intelligent and dynamic post-call and post-contact surveys.
Customer Feedback is installed on site (behind company firewalls using internal security policies). It
directly interacts with existing telephony and company networks to provide efficient capture and
analysis of customer feedback.
Capturing customer feedback as part of every interaction allows an organization to gain a
comprehensive view of customer perception of their whole business. Customer Feedback is different
than traditional survey projects that typically capture biased feedback about a narrow aspect of
customer perception. The Customer Feedback solution enables organizations to capture easy to act
on census-level feedback from every interaction.
Desktop and Process Analytics (DPA)

Desktop and Process Analytics (DPA) is a family of products that capture events and data from
employee desktops and makes them easy to act on.
The DPA products are part of the WFO suite and can be licensed independently, or as unified
components of a Workforce Optimization solution.
Desktop and Process Analytics is the only solution in the industry that can:
 Capture and monitor employee desktop application activities
 Provide data as tags to recorders to be used in Search & Replay, business rules, and Speech
Analytics
 Provide data to WFM to be used as volume, primary or secondary Time Tracking in adherence

 Identify, count, and visualize processes and workflow based on user interaction with software
applications
 Provide real-time processing of data to make Next Best Action recommendations to users
 Replicate data elements from one application to other applications without expensive data
integration
 Incorporate biometric status messages into Desktop rule processing for employee alerts

Workforce Optimization Overview Management Services
Management Services
Management Services consist of applications and utilities that allow users to view, manage, and
configure system entities and product functionality:
 Dashboard, page 28: Allows users to have a single view of valuable information across multiple
applications and evaluate it.
 System Management, page 29: Enables users to perform system management activities from a
single, Web-based application (Enterprise Management). Changes are saved and processed centrally
in one single, secure, highly available database. These activities are fully integrated and unified for
all products.
 Organization Management, page 29: Allows administrators to set up different hierarchies that allow
them to manage users.
 User Management, page 30: Allows administrators to set up and create user profiles for every
employee in their organization using the unified, single user management solution.
Dashboard
The WFO suite-wide unified dashboard allows users to generate multiple dashboards. Users can
select reports from multiple applications out of the collections of available reports.
The Dashboard is based on a powerful user interface that supports drag & drops, dynamic resizing,
and dynamic repositioning of widgets and portlets on the screen. The Dashboard also offers a highly
flexible sharing scheme and management console.
The Dashboard supports dashboard viewing and creation from the same single screen. Users with
the right level of privileges can also share a dashboard with other users. Dashboard sharing is also
done from the same single screen.
A management console is available for high-level administration needs. From the management
console, the administrator can see dashboards per organization or users. Administrators can delete
dashboards, change dashboard owners, or create new dashboards.
The Dashboard allows users to have a single view of valuable information across multiple
applications and evaluate it.
For example, one can present information that relates to analyzed or evaluated interactions. In
addition, dashboards can present information available from other applications, such as Scorecards,
Analytics, and WFM. This data can be displayed in a single location using one or more dashboards.
Dashboards facilitate the access to frequently used reports and data, while providing a unified view
of team performance across multiple applications.
For example, from a single dashboard, a manager in a contact center can now view the following:
 Quality scores of each of their teams (from QM)
 Overall contact center Performance KPIs (from Scorecards)
 Trend of a specific KPI (from Scorecards)
 Major reasons why customers are calling (from Speech Analytics)

System Management
System management activities are performed from a single, Web-based application (Enterprise
Management), and saved and processed centrally in one single, secure, highly available database.
These activities are fully integrated and unified for all products.
They include:
 License management
 Configuration
 Status and alarm monitoring
 Version information
 User management
 Generating a topology report
For example, using the Enterprise Management application, you can define configurations for all
applications and view system status and all active alarms in the enterprise. The application sends all
management changes and requests to the system database, where the changes are centralized,
processed and distributed to the relevant servers accordingly.
In addition, because all management information is centralized, management activities are fully
integrated.
Customers and Field Engineers (FEs) can use the application because it is highly secure. The activities
that are available for users to perform are based on their roles and privileges (permissions) assigned
to them in their user profile. For examples, users who do not have permissions to add new servers in
the enterprise are not able to perform this change.
Organization Management
Administrators can set up different hierarchies that allow them to manage users:
 Organizational hierarchies are structured according to the managerial and employee hierarchy in
the company.
 Group hierarchies are structured according to a specific logical structure defined by the
administrator.
These hierarchies allow administrators to set rules for users, based on their position in the
organization or their association with a specific defined group.
Related information
User Management Guide

User Management
Administrators set up and create user profiles for every employee in their organization using the
unified, single user management solution for the suite. The User Management application then sends
the changes to one, single central database, where all system management data is saved for the
whole enterprise.
Administrators assign specific user privileges and permissions to each profile (called roles and
privileges). When a user logs in to the Portal, the system authenticates and authorizes them. The user
is only authorized to view and access the applications and functionality defined within their scope
and visibility.
Related information
User Management Guide

Workforce Optimization Overview Framework Layer
Framework Layer
The Framework controls the overall software infrastructure and mechanisms in the solution,
including:
 Web Services, page 31: Allows communication and a service layer between the application and the
different services provided by the suite.
 Authentication, page 31: Supports two main authentication models—Windows Integrated
Authentication and DB Realm.
 Mobile Apps, page 32: Provides quick and easy access to view calendar and work schedule
information from any iPhone or Android phone.
Web Services
Web services allow communication, and a service layer between the application and the different
services provided by the suite.
These Web access services are used to allow a simple and consistent interface to the application,
databases, and alarms. They provide the base for allowing different services to interact with each
other.
Authentication
The system supports several methods of user authentication. These include DB Realm, Windows Active
Directory with LDAP or SSO, Security Assertion Markup Language (SAML), and OpenID Connect (OIDC).
Each method uses a specific authentication principle (federated or form based), and can be used for
specific applications (desktop/web, mobile, reports) within the system. The authentication process is
implemented in the WebLogic component.
DB Authentication (DBRealm)
The DB Realm (system or internal) is a Form-based authentication method. DBRealm authenticates
the user with a user name and password that is maintained solely within the system’s database. The
password hashes are managed securely in the database. When DB Realm authentication method is
used, password and account locking policies are also managed within the system.
Windows Active Directory (LDAP)

The Windows Active Directory (LDAP) is a Form-based authentication method, which uses a simple
bind authentication process. The user is identified by the Active Directory and the proof of identity
comes in the form of a password. When a more secure method is required, Secure LDAP (SLDAP) can
be used.
Windows Active Directory (SSO)

Windows Active Directory (SSO) is a Federated authentication method. SSO allows users, once they
have signed in to Windows, to automatically sign in to the system. Password verification takes place
during Windows sign in. Upon success, a Kerberos ticket is generated. When the user is authenticated
by the system the Kerberos ticket is validated.

Workforce Optimization Overview Framework Layer
Security Assertion Markup Language (SAML)

SAML is a Federated authentication method, which uses XMLs for exchanging user authentication
between the customer identity provider (IdP) and WFO as the Service Provider (SP), or Relying Party
(RP). Similar to the Kerberos ticket exchange in Windows Active Directory (SSO), SAML SSO works by
transferring the user's identity from the IdP to SP. This is done through an exchange of digitally
signed XML documents (SAML assertion).
OpenID Connect (OIDC)

OpenID Connect is a Federated authentication method, and a standard for single sign-on and identity
provision on the internet. Similar to SAML, OIDC is an authentication method where the user's
credentials are held with a third-party identity provider (IdP) and not within the system. The system
verifies the user's identity based on a simple JSON- based identity token. This is delivered on top of
the OAuth protocol and is suitable for mobile applications, such as Verint WorkView.
Mobile Apps
Verint Mobile Team View and Verint Mobile Work View provide managers and employees quick and
easy access to view their calendar and work schedule information from any iPhone or Android phone.
Work View also provides performance data for objectives and Key Performance Indicators (KPIs) in an
easy-to-read format.
The mobile apps can be downloaded directly from the AppStore™ or Google Play™ at no charge.
However, because it is not standalone, the user must be logged into a system server for it to work.

C h a p t e r 2
Logical Architecture
The system logical architecture is based on three logical deployment zones: Data Center,
Sites, and Desktop. The Data Center and Site zones each contain server roles that provide
specific functionality for the system.
Topics
Logical Architecture Overview 34

Logical Building Blocks—Server Roles 35
Data Center 36
Sites 40
Desktop 49
Customer Environment 50
Logical Architecture Logical Architecture Overview
Logical Architecture Overview

The system logical architecture is based on three logical deployment zones:
 Data Center, page 36: Serves as a centralized, single point of access where application data and
content metadata are accessed, managed, and maintained
 Sites, page 40: Provides recording (content acquisition), content storage, and integration with the
customer environment
 Desktop, page 49: Provides the employee or supervisor working environment
Every system deployment includes one Data Center, and one or more Sites and Desktops (depending
on system size and scaling issues).
Dividing the system functions into logical zones supports flexibility for different system scaling levels.
It also streamlines the flow of data, enables easier and more efficient upgrade paths, and provides
system security.
Maintaining the data in one single location (Data Center Zone) both protects sensitive system data
and provides centralized access to data by authorized users. The Site zone can be configured in
multiple instances with multiple servers, providing system flexibility and scalability.
Main system data is sent from the Site zone to the Data Center Zone. The Site zone sends recorded
content and other stored data to the Data Center Zone. The Data Center Zone provides a centralized,
single location where users can access this data to view and modify it. In turn, the Data Center Zone
sends user information and system configuration information to the Site zone, where it is then
integrated into the customer environment. For more information on logical system building blocks
used in the Data Center and Site zones, see Logical Building Blocks—Server Roles, page 35.
The software in the Data Center and Site zones can be upgraded separately, which enables easier
upgrade processes. For example, the customer can upgrade the Data Center Zone for new
applications or new features, without the need to invest in upgrading the entire enterprise.

Logical Architecture Logical Building Blocks—Server Roles
Logical Building Blocks—Server Roles

The Data Center and Site Zones each contain server roles that provide specific functionality for the
system.
A server role contains a logical, predefined set of components (software or certified third-party
software) that can be installed on a single server or multiple servers. Two or more server roles can
share component.
Server roles provide logical services corresponding to one of the functions provided by the Data
Center Zone or Site Zone.
For example, the Interactions Applications server role enables all interactions-related applications in
the Data Center Zone. Similarly, the Speech Transcription Engine server role enables the transcription
of contacts in the Site zone.
Server roles are also used to enforce deployment constraints and scope. Server roles can limit the
number of allowed instances in the enterprise or site levels of a specific server role. They can also
determine whether a specified server role can be associated with one or multiple different server role
instances.
Related topics
Data Center, page 36
Sites, page 40

Logical Architecture Data Center
Data Center
The Data Center provides a single, central point of access for application and content metadata. Every
system deployment includes one Data Center zone.
Users access the Data Center to view and modify system stored and real-time data. Users who do not
have access to the Data Center zone cannot log in to an application or access any of the data.
The following graphic shows the server roles defined in the Data Center Zone.

Functional Area Description Server Roles
Databases, page 37 Store system management data,  Framework Data

application management data, Warehouse
and operational data.  Interaction Data
Warehouse
 DPA Database
 Framework Database
 Contact Database
 QM Database
 Contact OLTP Database
 Speech Analytics
Database
 Speech Products
Database
Web Applications, Includes a cluster of various Web-  Framework Applications

page 38 based applications that serve all  Interaction Applications
users in the organization and  DPA Application
present different user interface  Interaction Analytics
options according to user
Application
privileges.
 Recorder Central Web
Services
Data Processing, Includes offline services used for  Interaction Flow Manager
page 38 data processing hosted on one or  Framework Integration
more servers. Service
 Speech Application
Service
 Forecasting and
Scheduling Service
 Interaction Analytics
Services
Reporting Services, Provides the SQL Server  Reporting Services

page 39 Reporting Services
Databases
The Data Center Zone hosts one or more database servers, depending on the size of the system
deployment.
Data Center Zone databases contain the following information:

 System Management Data: Includes IT-oriented information on licenses, configuration, and data
sources.
 Application Management Data: Includes business-oriented information on:
 User management: Includes users, hierarchy, roles, and user preferences
 Application management: Includes forms, flags, reports, and Custom Data (for Workforce
Optimization Interactions & Analytics), and Key Performance Indicators (for Scorecards).
 Application Data: Includes raw contact information, evaluations, agent adherence to workflow
procedures, scorecard source measures, DPA data, Speech content, Biometrics information, and
excludes audio and screen information.
 Operational Data: Includes archived segment data indicating which segments are archived,
including the information required to restore and play back a segment. The system generates
operational data and maintains it in the database. The system manages acquired structured and
unstructured data.
Web Applications
The Web Application layer includes Web UI Application and Web Services.
The application cluster consists of one or more application servers, depending on the deployment
size. In large deployments with more than one server, the application servers are deployed behind a
Load Balancer (LB). Each server exposes the same set of applications and services.
All users log on to the system through Web applications. A single point of authentication—Single Sign-
On (SSO)—provides application access in the system, as defined by user privileges.
Web applications run application pages with system management and application management data.
It is structured information. Unstructured information is accessed directly from the Site zone in which
it was recorded or archived.
All application servers run the same version of software and have an identical configuration. Users
access the system from the URL of the LB. The LB routes the user to one of the application servers.
Web services provide a secure interface for the upload, retrieval, and updating of Data Center Zone
database information. They also provide a secure interface for real-time information received from
the CTI switch. This information includes the status of an employee, the number of active employees,
and other user data.
Web services include Marking Web Services, Data Access Services, which enable third-party
integration and professional services that enhance the product. Extra services include the
transcription web service, DPA services, and Desktop messaging.
Data Processing
The Data Center zone includes services used for data processing hosted on one or more servers.
These offline services are common to all deployments and operate on data that is synchronized
between two databases, or uploaded to a database.
For Speech Analytics, the Data Center hosts one or more Speech Application servers according to the
number of speech instances required by the customer. Each Speech Application server hosts a single
speech instance.

For Text Analytics, the Text Analytics Service (TAS) receives the data from the Interaction Capture
Service, parses the data, tags it with semantically meaningful information, creates indexed search,
and generates analytics. Accordingly to functionality, the TAS can be divided into three types of logical
servers: TAS Application, TAS Datastore, and TAS Installation. Based on the type of deployment, they
can be consolidated on the same or on different physical servers. Each server is associated with a set
of services.
The following are examples of offline services executed in the Data Center as offline processes:
 Business workflows, such as:
 Inbox selection
 Call distribution—Managed by CTI Contact End rules defined in the Rule Editor.
 Cradle-to-Grave—Partial contacts originating from different CTI servers are gathered into a single
contact with corrected contact-level information in the Contact Database.
 Forecasting and Scheduling Services, to manage and plan your contact center activities.
 Operational workflows, such as:
 Offline maintenance jobs.
 ETLs (Export, Transform and Load) data from one database to another.
 Integration with external data sources.
 ETLs (Export, Transform and Load) data from external sources into a database.
Reporting Services
The Data Center Zone provides Reporting Services for Workforce Management (WFM), Scorecards,
eLearning, Coaching, Customer Feedback, and Interactions and Analytics.
In addition, there are other reporting mechanisms that are implemented as part of the system
proprietary applications. These reports include DPA reports and Speech Analytics reports (which are
implemented over the Speech index).

Logical Architecture Sites
Sites
The Site zone is responsible for recording (known as content acquisition), content storage, and
integration with the customer environment. The Site zone hosts components used for integration
with the customer environment for Full-Time Recording and Workforce Management.
The number of Site zones varies according to the geographical deployment of the call center,
switches, and network infrastructure. You can deploy Site zones at any location in the organization.
You can store audio and video content at any Site zone, regardless of where you recorded the call.
Usually, there is a correlation between the number of Site zones and the size of the deployment, and
the number can reach tens of sites.
When a Site zone is disconnected from the Data Center Zone, users at the Site cannot connect to
applications, search calls, or playback calls.
Avaya Contact Recorder Advanced (ACRA)

Avaya Contact Recorder (ACR)
Content Access, Enables users and background  Content Server

page 43 offline processes to retrieve  Telephone Playback Service
audio and screen real-time and
recorded content.
Integration Provide integration with the  Recorder Integration Service

Services, page 43 customer environment, and
include services such as agent
information, interaction
information, and third-party
systems integration.

Recorder, Content Allows creating, capturing, and  Customer Feedback Survey

Access, and managing short, context-
Integration sensitive surveys to capture
Services, page 44 data immediately after the
customer interaction with
agents. Surveys are delivered to
customers based on defined
rules.
Recorder (ACRA ACRA only: ACRA only:

only), page 44
Captures audio, video, and  IP Recorder
screen activity of agent calls.  IP Recorder Video
When an agent screen is  Screen Recorder
recorded, screen images are  TDM Recorder
uploaded from the agent  IP Analyzer
desktop to the screen recorder.
 Recorder Ingestion Web
ACRA and ACR: Service
Imports recorded content ACRA and ACR:
(audio and metadata) from  Import Manager
external source systems into
the recorder local call buffer for
system use and processing.
The external source systems
from which the Import Manager
extracts the content includes
the following:
 OEM Recorders
 Third-party Recorders by the
Generic adapter
Content Storage, (ACRA only) Stores content on  Central Archive

page 45 both a short-term and long-
term basis, using different
components.
Content Processes audio content, and  Speech Transcription Service

Processing, performs offline processing of
page 45 speech transcription files for
analytics using the Speech
Transcription Engine.

Recorder Analytics (ACRA only) The Recorder  Recorder Analytics

Framework, Analytics Framework Framework
page 45 architecture provides a
framework that enables the
system to support multiple
analytics solutions concurrently
for metadata and audio
captured by recorders.
Because the architecture for
the framework is recorder-
based, it is both extensible and
scalable for all deployments
supported by the system.
Analytics Engines, (ACRA only) An Analytics Engine  Voice Biometrics Engine

page 47 analyzes the metadata and  Voice Enrollment Engine
audio provided by the Recorder  Real-Time Acoustic Engine
Analytics Framework.  Real-Time Speech Engine
The Recorder Analytics
Framework supports multiple
Analytics Engines, which
function as plug-ins to the
Recorder Analytics Framework.
Each Analytics Engine runs on a
recorder platform.
Content Access
Content access enables users and background offline processes to retrieve audio and screen real-
time and recorded content. Playback can be done over the telephone, over computer speakers, or by
downloading the file.
Integration Services
The system integration services provide integration with the customer environment, and include the
following:
 Employee Information: Provides information about the following:
 Which employees are currently logged on
 Which employees sit at which desktop

 What calls are in progress

 Employee adherence to specified working practices
 Integration Information: Provides integration with telephony switches and Desktop Process
Analytics (DPA) components.
Recorder, Content Access, and Integration Services

Customer Feedback Survey allows creating, capturing, and managing short, context-sensitive
surveys to capture data immediately after the customer interaction with agents. Surveys are
delivered to customers based on defined rules.
Recorder (ACR only)

For Avaya Contact Recorder (ACR), the Import Manager is used to import recorded content (audio and
metadata) from external source systems into the recorder local call buffer. The imported content is
used for system use and processing.
The external source systems from which the Import Manager extracts the content includes the
following:
 OEM Recorders
 Third-party Recorders by the Generic adapter
Recorder (ACRA only)

Recorders can capture audio, video, and screen activity. An integration service can control a recorder
located in another Site zone.
Every Recorder has its own storage (local buffer), and it records and saves the file locally. The
Recorder supports the following recording modes: —VoIP, Video, Screen, TDM, and Import (extracting
data from external recorders). The same Recorder can operate in any of these modes, depending on
the recording requirements.
Recorder Ingestion Web Service

(ACRA only) The Recorder Ingestion Web Service is a web service that enables the Recorder to save
content captured from an external source to the Recorder call buffer.
Where does the service run?

As a component of the Recorder, the web service runs on the Recorder or the Consolidated platform.
The Recorder Ingestion Web Service essentially acts as a Capture Engine for that Recorder.
Which engines use it?

The Recorder Ingestion Web Service can provide its services to any number of engines. The Recorder
Ingestion Web Service is called by the Biometrics Application during manual enrollment. It saves
external audio used for creating voiceprints of caller voices on the Recorder.

Why save external audio on the Recorder?

After the Recorder Ingestion Web Service converts the audio into a simulated Call Recording, the
audio can be processed as any other suite Call Recording. This audio conversion enables customers
to search, analyze, and report audio content, like other recorded media types.
Some of the benefits of ingesting all audio used for enrollment into simulated call recordings include
the following:
 Audio used for enrollment can be archived using the same mechanism as all other recorded calls
are archived.
 External audio used for enrollment can be replayed using the same mechanism as all other
recorded calls use.
Content Storage
(ACRA only) The system supports both short-term and long-term content storage:
 Short-Term Storage: Every Recorder has its own storage (local buffer), and it records and saves the
file locally. Data is stored in the local recorder buffer according to how long the data needs to be
saved. For example, the requirements are that the data needs to be saved for six months locally.
Therefore, the size of the Recorder (for example, 15,000 MB) is configured accordingly.
 Long-Term Storage: The Archive Manager provides long-term storage, and can archive content
recorded in another Site zone. In this deployment, the Archive Manager is located next to the
network storage infrastructure.
Content Processing
Audio transcription servers can process audio content recorded in another Site zone. Typically, the
system is designed to minimize the transition of unstructured data because the volume of
unstructured data is significantly larger than the structured data.
The system also performs offline processing of speech transcription files for analytics using the
Speech Transcription engine.
Recorder Analytics Framework

(ACRA only) The Recorder Analytics Framework comprises the recorder-based set of components shared
by all Real-Time Analytics (RTA) Framework solutions.
The framework includes:
 Software interfaces
 Services
 Recorder Analytics Rules processing

 Infrastructure used to support a common enterprise solution for analyzing all metadata and audio
captured by recorders
The Recorder Analytics Framework includes the Analytics Service; the analytics engines are separate
from the framework.
Analytics Service
(ACRA only) The Analytics Service is a core component of the Real-Time Analytics (RTA) Framework that
runs on the recorder platform. The Analytics Service functions as the interface between calls and the
analytics engines (which process the calls and metadata).
The Analytics Service is a separate process that can run on any server. The Analytics Service usually
runs on the recorder, especially for real-time processing. When contact information is processed after
a call is completed (such as in campaign-based processing), the service can easily be run on other
servers.
Analytics Service responsibilities

The main responsibilities of the Analytics Service are:
 Receiving selection rule information, looking up the corresponding Recorder Analytics Rule, and
triggering the correct action to the appropriate analytics engines.
 Obtaining call metadata and providing it to analytics engines.

 Obtaining audio data is in a suitable format (decompressing it if necessary), and passing it to the
analytics engines. If the audio stream is stereo, it can be supplied to any analytics engine as one of
the following:
 Single interleaved stereo stream
 Single mixed mono stream
 Two separate mono streams
 Obtaining and processing results from analytics engine (including both Recorder Analytics Rule
matches and raw metadata), and processing the results.
Data Processing Types

(ACRA only) The Recorder Analytics Framework supports the following types of data processing:
 Real-time: Processes call based on metadata supplied by the Recorder Integration Service as the
contact capture occurs. Real-time processing relies on the Capture Engine for the audio stream. The
Recorder Analytics Framework performs real-time call selection based on call attribute
events/metadata.
For example, a real-time Recorder Analytics Rule could process all recordings as they occur for a
specific department or a group of agents.
 Campaign-based: Processes calls based on criteria in a campaign that determines which contacts
to include or exclude. The Recorder Analytics Framework processes the metadata and audio.
For example, campaigns can:
 Process all calls during the after hours period when the recorders would otherwise be idle.
 Automatically enroll employees and customers using historically recorded calls.
Analytics Engines
(ACRA only) Engines analyze the metadata and audio provided by the Analytics Service. The Recorder
Analytics Framework supports multiple analytics engines, each of which functions as plug-ins to the
Analytics Service. Each analytics engine runs on a recorder platform.
An analytics engine will:
1. Process audio and associated metadata
2. Return the processing results to the Analytics Service for further action
An analytics engine can provide specific custom results. These results could be actions taken as a
result of its analysis, depending on how the analytics engine is configured.
Examples of specific analytics engines include:
 Metadata Detection
 Real-Time Acoustics
 Real-Time Speech Analytics (RTSA)

 Voice Biometrics
 Voice Enrollment

Logical Architecture Desktop
Desktop
The Desktop is the main component in the customer environment that hosts software and certified
third-party software.
Depending on the package, the Desktop optionally contains the following types of clients required by
agents to work with system servers:
 Integration Services Agent: Retrieves and acquires agent information, and extend contact
metadata with data available only on the agent desktop.
 Content Recorder Agent: Records agent screen activity.
 Content Access Client: Provides Playback Control (Interactions and Analytics)
 Thick Client Applications: Includes Form Designer (Interactions and Analytics)
 Real-time Agent Notification: Enables the system to send notifications to the employee desktops.

Logical Architecture Customer Environment
Customer Environment
The hardware infrastructure that supports the customer software environment includes the following
types of components:
 Telephony: Provides a CTI link, which enables integration with PBXs, Automatic Call Distributors,
and Interactive Voice Response mechanisms
 Storage: Serves as the archive drives for recorded content. Long-term and short-term content
storage, data files, backup location, and advance storage solutions are all critical components for
disaster recovery.
Examples of storage solutions include Storage Area Networks, Network-attached storage, and
Content Addressable Storage.

C h a p t e r 3
Deployment and Scalability
The system is deployed with one Data Center Zone, one or more Site Zones, and multiple
Desktops in the customer environment. The system supports various deployment levels (or
scales). The levels range from a small deployment of 250 agent seats (level 1) to an
enterprise scale of 50 K agent seats (level 6).
Topics
Deployment Overview 52
Platforms and Server Roles 54
Deployment Principles 55
Deployment Levels 56
Databases by Platform 58
Physical Deployment Use Case 59
Deployment and Scalability Deployment Overview
Deployment Overview
The system is deployed with one Data Center Zone, one or more Site Zones, and multiple Desktops in
the Customer Environment.
The Data Center and Site Zones each contain server roles that provide specific functionality for the
system. A predefined logical group of server roles that are installed together on a physical server is
defined as a platform. Only one single platform can be installed on a server.
The system contains approximately 16 different platforms. Two or more platforms can include the
same server role. Platforms are hardware and operating system-independent—you can install the
same platform on servers with different hardware specifications and operating systems.
Hardware specifications of servers include specific parameters (such as CPU, memory, hard drive,
RAID Controller, and disk partitions). Two or more physical servers can have the same installed
platform.
A server includes third-party software (such as Windows and SQL), which is a part of the platform and
the responsibility of the customer. It is installed in advance on the server, and the customer verifies it
using the Server Readiness Tool.
Servers and Hardware

The concept of servers and hardware is used when sizing the system.
A server installed with a platform can serve different purposes according to the enabled server roles
of that platform.
For example, the Recording platform, which is a general platform, maps to a few different servers:
 Recorder Server
 Recorder Integration Service Server
 Import Manager Server
 Centralized Archive Server
 IP Analyzer Server
 Post-Processing Voice Biometrics Server
 Speech Transcription Server

Deployment and Scalability Deployment Overview
Platform
Software only
Server Role 1
Component (MSI)
Server Role 2
Component (MSI) Servers
 Installed with a single

platform
 Two or more physical

Server Role n servers can have the
Component (MSI) same installed
platform
In addition, a server can be hosted on several different hardware types, where the hardware type
represents the minimum specifications of the underlying machine.
Hardware types are specified by the number of vCPU’s or HW threads required, and by the amount of
memory required in GB.
Additional HW requirements per server are specified in the Server Details section of the Customer
Furnished Equipment (CFE) Guide.
Related information
Server Details section (Customer Furnished Equipment (CFE) Guide)

Deployment and Scalability Platforms and Server Roles
Platforms and Server Roles

There are different platforms in each logical zone in the system (Data Center and Site zones). Every
platform consists of specific server roles.
Platforms can include multiple server roles, and one or more platforms can include the same server
roles.

Deployment and Scalability Deployment Principles
Deployment Principles
The following include the core deployment principles that have been integrated into the system
architecture:
 Same Deployment Concepts for All Applications: The same deployment concepts, scales, and
installation procedures are used, regardless of the application (QM, REC, WFM, or WFO) the
customer has purchased. The fact that different applications are installed does not change the
common deployment practices implemented for all applications.
 OS/HW Independent Platforms: All defined platforms are hardware and operating system-
independent. The same platform can be installed on multiple servers with different hardware
specifications and operating systems.
 High Availability and SQL Remote Access: Application and database high availability is supported,
and also remote SQL capabilities.
 Flexible Deployments, Sizing and Scalability:
 Deployment scaling is driven by whether or not a deployment has reached any given physical or
logical limit.
 In Data Center zones, database servers scale up and then out, separating each database to its
own server. Application servers scale out through load balancing.
 In deployments including Recorders and Speech Analytics, servers scale out through multiple
units.

Deployment and Scalability Deployment Levels
Deployment Levels
The system supports various deployment levels (or scales), ranging from a small deployment (level 1)
to an enterprise scale (level 6). To support this range, the system can be deployed in one server or
multiple servers, depending on the size of the deployment.
The smallest deployment is a single box solution where the two logical zones, Data Center and Site,
reside on the same physical server. A single box deployment is a consolidated platform that consists
of almost all the server roles that are part of the WFO analytics offering.
In a Multiple Box solution, the deployment is distributed over multiple servers with multiple
platforms. The single box solution becomes a Multiple Box solution under the following
circumstances:
 Number of supported agent seats increases
 Customer environment is distributed and requires deployment of remote sites
 Customer requires databases and application high availability
 Security considerations require physical separation of database and application servers.
The following diagram illustrates the different deployment levels and the platforms that can be
installed on the servers in the different levels. Level 1 is the Single Box or consolidated deployment,
and levels 2–6 represent various levels of Multiple Box deployment solutions.
Level Description
1 Smallest deployment size with recording. A consolidated server has both Data
Center and Site Zone server roles.

Deployment and Scalability Deployment Levels
Level Description
2 Next scaling level for one of the following deployments:

 Data Center platform with Recorder, and optionally Speech Analytics
 Starting point for deployments of data center platform without any
recorders.
Levels 1 and 2 represent low-end scaling for single-server WFM deployments.
3–6 Provides a physical separation between the database and application.

Levels 4, 5 and 6 are required for larger deployment sizes.
 The Data Center deployment level depends on the number of employee seats and the
applications being deployed. The deployment can also include more parameters (such as
database size).
The Workforce Optimization Suite supports SQL cluster and SQL farm deployments, where
SQL Server and databases are hosted externally to the database platform. In this case,
Database Management services are required. Database Management services are used to
configure and manage the databases in the cluster. The services are also for hosting reports
and post processing functions (see Data Processing, page 38 and Reporting Services,
page 39).

Deployment and Scalability Databases by Platform
Databases by Platform
Platforms host specific databases. The databases hosted by the platform depend on the deployment
level and the platform itself.

Deployment and Scalability Physical Deployment Use Case
Physical Deployment Use Case

One example of a large WFO analytic deployment has 22,000 seats, distributed over six sites.
Site Description
Recording Archive Site The system enables an archive server from one site to
archive calls from other, multiple sites.
Another type of recording site can be a site with a single
recorder that is configured to act as an archive server.
This recording site can be located physically in the Data
Center Zone.
In this example, the site is a pure archive site that archives
calls recorded by recorders located in other sites (new and
existing). The site could also include recorders that act as
audio recorders.

Deployment and Scalability Physical Deployment Use Case
Site Description
Recording Site The number of Recorder servers depends on:

 Number of agents
 Whether screen or audio is recorded
 Redundancy configuration (N+N or N+1)
 Whether calls are archived
 Whether telephony playback is supported
The role that each server plays is determined during
system configuration and not during the installation.
The number of servers installed with the Speech
Transcription Server is determined according to the audio
hours that need to be processed.
Data Center The Data Center Zone, in this example, is deployed with
the following:
 Databases: There are six database servers. Each server
is installed using a different platform, and has a local
instance of SQL.
 Applications: The application cluster resides behind
load-balancers and up to 11 servers installed with an
application platform.
 Speech: For every speech instance, there is a server
with a Speech Analytics platform installed. The server is
configured with a Speech Application Service server
role.

C h a p t e r 4
Data Flows
There are many different data flows, or processes, that are implemented in the system. User
requests, product activities, and system events trigger these flows.
Topics
User Management Data Flows 62

Recording Data Flows 67
Playback Interaction Data Flows 74
Real-Time Monitoring Data Flow 90
Automated Quality Management(AQM) Data Flows 95
Speech Analytics Data Flows 102
Interaction Analytics application data flow 138
Encryption Data Flows 140
Desktop Messaging Data Flows 154
Desktop and Process Analytics Data Flows 157
Archive Topologies 165
Database Processes 171
Reporting data flow 175
Data Flows User Management Data Flows
User Management Data Flows

The system provides a unified, single user management solution by a single point of access.
There are two types of user setup:
1. Generic User Setup, page 63: Administrators create main user management data using the User
Management application by means of using the Portal, and saved in one, single central database.
Administrators set up and create user profiles for every employee in their organization, and assign
specific roles and privileges to each profile.
2. Applications User Setup, page 64: Users can then be defined with specific application permissions.
For example, users can be defined with permissions for the Interactions and Analytics applications
(Speech Analytics and Quality Monitoring), Scorecard and WFM applications.
For example, administrators have an Interactions and Analytics license. After administrators set up
users with the User Management module, they use a different application called the Assignment
Manager (also accessed by means of the Portal). They use this application to define user access
permissions and scope of the Interactions and Analytics applications.
Administrators define the scope of what users can do in the Interactions and Analytics applications
based on user groups and role affiliations defined in the system.
Administrators then assign entities to groups and roles, such as forms, flags, reports, and folders. For
example, by default, the Ad Hoc Query Analyst role can only access the Ad Hoc Reports section of the
Reports application.
Related information
Interactions and Analytics Administration Guide

Generic User Setup

Administrators use one single unified application to define user profiles, and organizational and
group hierarchies in the system.
When a user logs in to the Portal, the system authenticates and authorizes them. The user is only
authorized to view and access the applications and functionality defined within their profile and
scope.
Every user profile contains one or more roles, where each role contains a set of privileges:
 Roles are assigned to users to define their access permissions to applications. For example, a user
with the Supervisor role has a different level of access to an application than a user with only the
Agent role.
 Privileges associated with user roles define the features of the application a user is able to view.
They also define the functionality in the application the user can access.
In addition to setting up user profiles with defined roles and privileges, administrators can set up
different hierarchies that allow them to manage users:
the company.
administrator.
organization or their association with a specific defined group. (For more information on user roles
and privileges and organization and group hierarchies, see the User Management Guide).

Seq.# Source Destination Description
1 Desktop Framework To set up user profiles and

Applications organizational or group hierarchies, the
administrator logs in to the Portal from
the Desktop. They then access the
Framework Application in the Data
Center.
2 Framework Framework The Framework application stores all

Applications Database user management information to the
Framework Database.
When users log in to the system, they
only view and have access to the
applications and functionality within the
applications defined in their profile.
Applications User Setup

When the user is originally set up in the system, the Framework Database synchronizes the user data
with the QM Database (Interactions and Analytics user repository).
When administrators use the Assignment Manager (Interaction Application) to add permissions for
the Interactions and Analytics application, this full set of permissions is then combined. The
combined permissions allow users to access and use all relevant Enterprise Suite applications and
application functionality defined for them.

1–2 Administrator Framework See Generic User Setup, page 63.

Applications
Framework Framework
Applications Databases

3 Framework QM Database On an automatic, scheduled basis, the

Database Framework Database synchronizes the
main user setup information with the
QM Database.
The QM Database then combines this
information with the specific
organization and server role entities
assignments for the Interactions and
Analytics applications.
When the users log on to the system,
they can only access entities that were
assigned to their roles or to the
organization and group to which they
belong.
Users can view, edit, or create
(according to their permissions) entities
they are assigned, and are limited to
the organization that is under their
visibility.
4 QM Database Interaction On an automatic, scheduled basis, the

Data QM Database sends all user
Warehouse information (including generic user
setup and application definitions) to
the Interaction Data Warehouse.
5 Desktop Interaction From Organization Management, the

Applications administrator uses the Assignment
Manager to define user access
permissions and scope in the
Interactions and Analytics applications.
6 Interaction QM Database The Assignment Manager (Interaction

Applications Application) saves organization, groups,
and roles entities assignments to the
QM Database.
7 Interaction Interaction The Interaction applications use the

Applications Data synchronized user information updated
Warehouse in the databases for report visibility and
Inbox selection, and perform other
scheduled system activities.
Related topics
Generic User Setup, page 63

Data Flows Recording Data Flows
Recording Data Flows

(ACRA only) Recording is the process of recording contacts (or events) for playback and evaluation
purposes.
The following main data flows relate to the recording processes:
 Setting Recording Environment Properties Data Flow, page 67: Describes how recording rules and
configurations are set up in the system to control the behavior of recorders and the recording
process.
 Recording Process and Media Storage Data Flow, page 69: Describes how the Recorders record
media data, and store the data in the system.
Setting Recording Environment Properties Data Flow

(ACRA only) Recording modes, levels, and properties are defined using the Enterprise Manager
(Recording Management) and Recording Manager. Once the recording configurations are defined,
they are saved in the Framework Database in the Data Center. You can configure the following:
 Recorder installations across sites in the enterprise.
 Recorder roles, which define the functionality of servers.
 Data sources, which include PBX/ACDs and associated phones and extensions and local area
network (LAN) workstations (for screen recording).
 Administrators with the Voice Recording, Search, and Replay license can define more recording
properties at the user level. (In Enterprise Manager, recording properties are located under
Organization Management > Interactions and Analytics > Interactions Settings).
The Enterprise Manager then distributes two types of information:

 Environmental Data To Recorders: Information related to the recording environment is sent from
the Database to the Recorders. (This information can include whether a PBX exists, information
about the Integration Service, and which extensions are recorded.)
 Environmental and Hierarchal Data, Recording Rules, and Parameters to Integration Service:
Information related to the recording environment, organizational data, recording rules and
parameters is sent from the Database to the Integration Service. This information transfer allows the
Integration Server to control the behavior of the Recorders, as defined in the application.

1 Desktop Framework The administrator configures environmental

Applications settings and the behavior of the recording
system.
This configuration includes configuring
recorder installations across sites, and
defining recorder roles and data sources
using the Enterprise Manager.

2 Framework Framework Recording properties are saved to the

Applications Database Framework Database.
3 Framework Recorder The Enterprise Manager sends all data

Applications Integration related to the recording environment,
Service recording properties and rules to the
Integration Service. This data transfer
includes hierarchical data related to the
organization.
The Integration Service then uses this
information to control the behavior of the
Recorders.
Recorders The Enterprise Manager sends only

information related to the recording
environment to the Recorders (such as
whether a PBX exists).
Related information
Recorder Configuration and Administration Guide
Recording Process and Media Storage Data Flow

(ACRA only) The high-level recording process and media storage data flow is as follows:
1. Recorder records the contact (media and metadata).
2. Recorder saves the contact data in a specific format and location.
Every Recorder has its own storage (local buffer), and it records and saves files locally. The local
storage data requirements are measured according to how long the data needs to be saved. For
example, if the requirements are that the data must be saved for six months locally, the size of the
Recorder is configured accordingly.
3. Recorder notifies the database about the contact.

See the following for a more granular breakdown of these steps in the data flow:
 Recording and Storage, page 69: Describes the high-level recording data flow.
 Recording and Storage: Recorders Using Import Manager, page 72. If you use the Import Manager to
extract and processes data from external Recorders, the data flow will be a little different from the
basic recording flow.
Recording and Storage

(ACRA only) The Recorder records the data, stores it locally, and triggers the delivery of information
about the recording to different applications and databases.

1 Recorder Recorder The Recorder records the data (media and

metadata), and stores it locally.
 Audio data is stored in .WAV format
 Video is stored in MP4 format
 Screen content is saved as .SCN format

2 Recorder Interaction The Recorder sends information about the

Applications recording to the Interactions Application for
processing.
3 Interaction Contact OLTP The Interactions Applications send the

Applications Database recording data to the OLTP Database.
4 Contact OLTP Contact After a predefined time interval, the Contact

Database Database OLTP Database sends the recording data to
the Contact Database for long-term storage
management.

Recording and Storage: Recorders Using Import Manager

(ACRA only) The Import Manager extracts and processes data from external Recorders.

1 Import Recorders The Import Manager extracts the

Manager (Sources) by audio and metadata from the relevant
means of recorders (or sources) by the
Adapters corresponding adapters according to
the configured job schedule. The
Import Manager does the extraction
based on the settings defined for the
Import Manager (including extraction
jobs, selection plans, and sampling
plans).
2 Import Media Processing The Import Manager places the audio

Manager Cache (MPC) and metadata of the calls in the MPC,
a temporary cache on the local
recorder, while it processes the data.
This placement can include audio
compression and Speaker Separation,
depending on system requirements.
3 Import Call Buffer After processing the call data, the

Manager Import Manager transfers both the
metadata and audio to the local call
buffer. It then sends a notification
message to the Recorder Workflow
service that new extracted calls are
available.
4 Consolidator Call The Consolidator retrieves the call

Buffer/Contact metadata from the Call Buffer and
OLTP Database sends it to the Contact OLTP Database
(by Interaction by the Marking Web Service.
Applications Web Call audio data is saved in the Call
Services) Buffer to be used by other
applications (such as the Speech
Transcription Service).
5 Contact OLTP Contact Database After a predefined time interval, the

Database Contact OLTP Database sends the
recording data to the Contact
Database for long-term storage
management.
Related information
Interaction Data Import Manager Configuration Guide

Data Flows Playback Interaction Data Flows
Playback Interaction Data Flows

(ACRA only) Playback is the process of selecting a (recorded) interaction and playing it back to listen to
the contents of the call.
The Playback Interaction scenario includes the following data flows:
1. Playback Interaction Data Flow: Query and Select Interaction, page 75: Users can run a query to
play back an interaction using one of the Interactions Applications (such as Quality Monitoring or
Speech). Based on the search criteria, the application queries the database for the list of
interactions, and presents the list to the user. The user then selects a specific interaction to play
back.
2. Playback Data Flow: Search for Interaction, page 77: The way the system searches for interactions
varies, depending on the location where the interaction is saved and found (archive and non-
archive storage locations).
If a special registry key is set, the system first searches in a specific site before searching in other
locations (called Site-Dependent Playback).
3. For interaction retrieval, the application or browser sends a request for the URL to the Content
Server. The Content Server retrieves the file—either directly from a non-archive file system, or by
an Archiver to an archive medium, for delivery to the Desktop. Content delivery uses one of the
following flows, depending on the type of playback used on the Desktop:
 Playback Interaction Data Flow: Retrieve Interaction using ActiveX, page 87: The Content Server
delivers the interaction content to the Playback Application running in the Desktop (Browser).
 Playback Interaction Data Flow: Retrieve Interaction using HTML5 Streaming, page 89: The
Content Server streams portions of interaction content to the the Desktop (Browser) as needed
for replay.

Playback Interaction Data Flow: Query and Select Interaction

(ACRA only) Users run a query to retrieve a list of interactions to play back. From the retrieved list, the
user selects a specific interaction to play back.
1 Desktop Interaction User performs a query to search for

Applications interactions to play back using one of the
applications that allows searching for
and retrieving files. (Applications can
include Quality Monitoring or Speech.)

2 Interaction Contact The application sends the user request to

Applications Database the Contact Database to retrieve the
interactions according to the search
criteria the user entered.
NOTE: To search for recent
interactions—such as interactions
created in the past hour—the application
sends the request to the Contact OLTP
Database.
3 Contact Interaction The Contact Database processes the

Database Applications search request, builds the list of
interactions, and sends the list back to
the application.
As part of this process, the Contact
Database checks the user profile and
permissions (visibility and scope). It then
uses this criteria when building the list of
interactions.
4 Interaction User The application presents the list of

Applications interactions generated by the database
to the user.
5 Desktop Interaction From the list, the user selects the

Applications interaction to play back.

6 Interaction Locator The Interactions Applications uses an

Applications internal DLL, Locator, to obtain a set of
URLs which provide access to the
selected interaction.
A key identifies the interaction the user.
The key has three parts, which are the
Module, Channel, and Start Time (M, C,
ST):
 M (Module): Represents the recorder
that recorded the interaction.
 C (Channel): ID number created by
the database to identify the
interaction in a unique way.
 ST (Start Time): Represents the time
stamp in UTC (GMT).
The identifying data is used to obtain the
details of the individual recordings that
form the interaction from the Contact
Database.
For each type of desired file (for example,
audio and screen), a request is given to
the Locator. The Locator uses these
details to determine a list of the Content
Servers which can provide the desired
file. The Locator then contacts one
Content Server at a time until the file is
found.
For information on how the Content
Server searches for interactions, see
Playback Data Flow: Search for
Interaction, page 77.
Playback Data Flow: Search for Interaction

(ACRA only) The way the system searches for interactions varies, depending on the location where the
interaction is saved and found.
When the user selects to play back a specific interaction, the application DLL (Locator) looks for the
interaction using unique characteristics (key). It looks for it in the following locations according to the
following sequence:
1. Non-Archive Storage: The Locator searches for the interaction in the Recorder local buffer
storage.

2. Archive Storage: If the Locator does not find the file in the non-archive storage, it then searches
the archive storage of all sites until it finds the interaction. Files can be archived on online media
(such as fileshares or SANs) or offline media (such as tapes or DVDs).
To search for interactions, the Locator uses an HTTP/HTTPS Web-based file retrieval component
called a Content Server. The Locator sends a request to the relevant Content Server—first in non-
archive storage, and then in archive storage, until it finds the requested interaction.
Usually, if a special registry key is set, the system first searches in a specific site to find the interaction.
It then searches in other locations (called Site-Dependent Playback).
Refer to the following examples:
 Search for Interaction in Recorder Site, page 79: The Locator searches in a Recorder Site for the
interaction, both in the non-archive and archive storage locations.
 Search for Interaction Using Site-Dependent Playback, page 84: When site-dependent playback is
enabled (through a registry key), the Locator first searches in the site that is specified in the registry
(both in non-archive and archive locations). Only if it cannot find the file in this specified site, it
continues looking for it in other locations.

Search for Interaction in Recorder Site

(ACRA only) The Locator first searches in the non-archive storage (local buffer) of the Recorder. If it
cannot find the interaction in the non-archive storage, it searches in the archive storage.
 The non-archive and archive searches can occur in different sites (depending on where the
interaction is located).
For visual presentation, the diagram shows both types of searches (non-archive and archive)
occurring in the same site

1 Locator Recorder The Locator sends a request to the Content Server

on the Recorder to search in the non-archive
storage for the interaction.
2 Recorder Locator The Content Server on the Recorder searches the

Recorder local buffer (non-archive storage) for the
interaction, and sends one of two possible
responses to the Locator:
 The Content Server found the file and prepared
it. The Locator can now build the URL for the
user to access the file.
 The Content Server did not find the file. Proceed
to the next step.
3 Locator Archive If the Content Server did not find the file in the non-
Database archive storage on the Recorder, the Locator
queries the Archive Database. The query attempts
to find servers that have Archivers that can access
the file in archive storage.
This query uses the Index Number (INUM) of the
first recorded segment of the requested type
(audio, video, and screen) belonging to the
interaction. The INUM is a unique 15-digit number,
where the first 6 digits are the recorder serial
number.
The Archive Database sends back to the Locator
one of three possible responses:
 Finds Interaction in Online Media: A list of
servers where there is an Archiver running with
access to an archived copy of the interaction.
Proceed to step 4a.
 Finds Interaction in Offline Media: A list of
offline media (tapes, DVDs) that contain the
interaction. Proceed to step 4b.
 Does Not Find Interaction: The database
cannot find the file on any archived media.
Proceed to step 4b.
NOTE: The servers that have access to the file in
archive storage can be located in different sites. For
visual presentation, the diagram shows both types
of searches (non-archive and archive) occurring in
the same site.

Finds Interaction in Online Media:
4a Locator Central Archive The Locator sends out a request to each Content
Server on the list (one at a time) generated by the
Archive Database. It continues to send the request
until it receives a positive response.
The first server that returns a positive response to
the Locator is the Content Server that attempts to
search for the interaction. (This server is usually the
first one on the list).
The Content Server then finds the interaction on
the online media, and begins preparing it for
retrieval.
Finds Interaction in Offline Media or Does Not Find Interaction:
4b Interaction Desktop The Archive Database responds that the file is

Applications archived on offline media (tapes or DVD) or that it
could not find the file. The Locator then sends one
of the responses:
 Finds Interaction in Offline Media: The
Locator returns the list of offline media. One of
the media that contains the interaction needs to
be physically inserted into an online drive. Users
can then upload and access the interaction from
the online media.
 Does Not Find Interaction: The Locator sends
an error response, indicating that the file could
not be found.
The application then sends this response to the
user (Desktop).


1 Locator Archive If the Content Server did not find the file
Database in the non-archive storage, the Locator
queries the Archive Database (using the
M, C, ST key). The query attempts to find
servers that have Archivers that can
access the file in archive storage.
The Archive Database processes the M,
C, ST key and sends back to the Locator
three possible responses:
 Finds Interaction in Online Media:
A list of servers where there is an
Archiver running with access to an
archived copy of the interaction.
Proceed to step 2a.
 Finds Interaction in Offline Media:
A list of offline media (tapes, DVDs)
that contain the interaction. Proceed
to step 2b.
 Does Not Find Interaction: The
database cannot find the file on any
archived media. Proceed to step 2b.
Finds Interaction in Online Media:
2a Locator Central Archive The Locator sends out a request to each

Content Server on the list (one at a time)
generated by the Archive Database. It
continues to send the request until it
receives a positive response.
The first server that returns a positive
response to the Locator is the Content
Server that attempts to search for the
interaction. (The server is usually the first
one on the list).
The Content Server finds the interaction
on the online media, and begins
preparing it for retrieval.
Finds Interaction in Offline Media or Does Not Find Interaction:

2b Interaction Desktop The Archive Database sends a response

Applications that the file is archived on offline media
(tapes or DVD) or that it could not find
the file. The Locator then sends one of
the responses back to the application:
 Finds Interaction in Offline Media:
The Locator returns the list of offline
media. One of the media that contains
the interaction needs to be physically
inserted into an online drive. Users
can then upload and access the
interaction from the online media.
 Does Not Find Interaction: The
Locator sends an error response,
indicating that the file could not be
found.
The application then sends this response
to the user (Desktop).
Related topics
Playback Interaction Data Flow: Retrieve Interaction using ActiveX, page 87
Search for Interaction Using Site-Dependent Playback

(ACRA only) Site-Dependent Playback means that the registry in the user Desktop site includes a
special key.
This key indicates to the Locator to first search in all storage locations in a specific site for the
interaction (both local and archive storage). Then the Locator searches for the interaction in other
sites. The Locator only searches for the interaction in other sites if it cannot find the interaction in the
specified site.
The purpose of Site-Dependent Playback is to help minimize WAN traffic between different physical
sites. This process prioritizes a copy of the file that is local, rather than needlessly transferring data
across the WAN.

In Site-Dependent Playback, the Locator searches for the recording by searching possible locations in
the following order until the recording is found:
1 Locator Recorder (in The Recorder that originally created the recording is
specified site) in the Site or Site Group specified by the Site-
Dependent Playback tip. The Locator then searches
for the recording on that recorder buffer.

2 Locator Archiver (on a The Locator searches for an archived copy of the
server in a recording on any archive server in the Site or Site
specified site) Group specified by the Site-Dependent Playback tip.
3 Locator Recorder (in The Recorder that originally created the recording is
other site) not in the Site or Site Group specified by the Site-
Dependent Playback tip. The Locator then searches
for the recording on that Recorder buffer.
4 Locator Archiver (on a The Locator searches for an archived copy of the
server in other recording on any archive server in other sites.
sites)

Playback Interaction Data Flow: Retrieve Interaction using

ActiveX
(ACRA only) The Content Server prepares the file for retrieval. The URL required for playback of the
selected interaction was provided to the Playback Application, running in the Desktop browser, in a
previous flow.
1 Desktop Content Server When the user selects the URL, the Playback
(Playback Application running in the browser sends a request
Application in to the Content Server to retrieve the file from its
Browser) location.
The Content Server retrieves the file from the
storage location:
 Non-Archive File System: The Content Server
retrieves the file directly from the non-archive file
system (local buffer or ATSM storage).
 Archive Medium (by Archiver): The Content
Server retrieves the file from the archive medium
by the Archiver.
If encryption is enabled in the system, the Player
application on the Desktop checks the file. The
Player determines whether it is encrypted before
playing it back to the user.

Related topics
Playback Interaction with Encryption using ActiveX Data Flow, page 145

Playback Interaction Data Flow: Retrieve Interaction using

HTML5 Streaming
(ACRA only) The Content Server prepares the file for retrieval. The URL required for playback of the
selected interaction was provided to the Desktop browser in a previous flow.
1 Desktop Content Server When the user selects the URL, the Browser sends a
(Browser) request to the Content Server to retrieve the file from
its location.
The Content Server retrieves the audio, screen, and
video/share data from the storage location:
 Non-Archive File System: The Content Server
retrieves the file directly from the non-archive file
system (local buffer or ATSM storage).
 Archive Medium (by Archiver): The Content
Server retrieves the file from the archive medium
by the Archiver
For HTML5 streaming playback, Content Server
returns the audio, screen, and video/share data in
chunks, as needed by the Desktop (Browser). This
step occurs iteratively for streaming replay.
Related topics
Playback Interaction with Encryption using HTML5 Streaming Data Flow, page 146

Data Flows Real-Time Monitoring Data Flow
Real-Time Monitoring Data Flow

Real-time monitoring enables users to monitor employee calls and screen activity as the call is taking
place.
Users select the extension or employee they want to monitor. They can then hear the call and view
employee screens continuously on the user interface. The user interface displays employee status in
real time. Employee status can indicate whether the agent is logged in, in a call, not in a call, or logged
out.
Related topics
Real-Time Monitoring—Retrieving Employee Information, page 90
Real-Time Monitoring—Streaming Audio, page 93
Real-Time Monitoring—Retrieving Employee Information

A user selects an employee to monitor. The employee information is retrieved and sent back to the
Desktop. The Desktop sends a request for audio streaming.

1 Monitoring Interaction By the Portal, the user selects the employee they
Desktop Applications want to monitor in one of the following ways:
 Select Employee, View Detailed Status: View the
detailed status of all employees in a specific
group. Then select the specific employee you
want to monitor from the list (Interactions >
Real Time > Monitor Employees)
 Type Extension Number: Enter the employee
extension number (Interactions > Real Time >
Monitor Extensions)
2 Interaction Interaction The application sends the request to Data Access

Applications Applications Services (DAS) (in the Interaction Applications).
(Data Access
Services)
3 Interaction Recorder The DAS in the Interaction Applications queries the

Applications Integration Agent Event Service (MAS) for the call data. The
Service MAS then looks for the CTI links configured for the
selected employee or extension, in one of the
following ways:
 Site-Dependent Real-Time Monitoring: If a
specific site is configured in the registry, the MAS
first searches the specified site for the CTI links
configured for the selected agent.
 Non-Site-Dependent Real-Time Monitoring: If
a specific site is not configured in the registry,
the MAS searches for the CTI links configured for
the selected agent across all sites.
NOTE: Site-Dependent Real-Time Monitoring is only
applicable if the user entered the employee
extension number. If the user selects a specific
agent from a group, the system does not use a site-
specific registry key to search for the CTI links.
4a Recorder Screen The Recorder Integration Service notifies the

Integration Recorder Screen Recorder to begin recording.
Service
4b Recorder Monitored The Recorder Integration Service notifies the

Integration Desktop Monitored desktop to begin sending data to the
Service Screen Recorder.

5 Monitored Screen The Monitored desktop connects to the Screen

Desktop Recorder Recorder and then sends data to the Screen
Recorder.
6 Interaction Monitoring The Interaction Applications (MAS) sends the

Applications Desktop following information to the user by the Playback
Control component installed on the user
workstation:
 Current call CTI data (not returned if there is no
call in progress)
 Employee status (logged in, logged out, in a call,
not in a call)
 Recorder and channel on which the audio is
available (not returned if there is no call in
progress)
 IP and port of the employee computer (for
screen monitoring)
 Time shift delta (for presenting the correct start
and end time)
7 Monitoring Interaction Playback Control on the Desktop sends the

Desktop Applications following information to the Interaction
Applications:
 Request to receive updated call status
information for the selected agent
 User workstation IP address and port number to
receive the audio streaming
(MAS by the Playback Web Service and the
Monitoring Real-Time Web Service or MRWS)
8 Monitoring Screen The monitoring desktop connects to the Screen

Desktop Recorder Recorder to get the data being streamed from the
monitored desktop.
Related topics
Real-Time Monitoring—Streaming Audio, page 93

Real-Time Monitoring—Streaming Audio

Audio is streamed from the recorders to the Desktop.
1 Interaction Recorder The Interaction Applications (MAS) sends

Applications Integration a request to the Recorder Integration
Service Service to start streaming the audio to
the user IP address.
2 Recorder Recorder The Recorder Integration Service sends

Integration the request to stream the audio to the
Service relevant Recorder.

3 Recorder Desktop The Recorder streams the requested

audio to the already open ports in the
Playback Control application.

Data Flows Automated Quality Management(AQM) Data Flows
Automated Quality Management(AQM) Data Flows

Automated Quality Management (AQM) is the process of fully or partially automating evaluations and
analyzing the evaluation data in Scorecards.
The following data flows relate to the fully automated evaluation process:
 Fully automated evaluation setup data flow: To start performing fully automated evaluations,
configure AQM-enabled transcription rules, create and publish an automated evaluation form, and
configure KPIs for the form in Scorecards.
 Fully automated evaluation data flow: After an automated evaluation form is published, the
system automatically evaluates applicable interactions and submits the evaluations. The evaluation
data is displayed in the relevant KPIs in Scorecards.

Fully automated evaluation setup data flow

To set up fully automated evaluations, in the Project Rules Manager configure AQM-enabled
transcription rules, and in the Form Designer create an automated evaluation form. In the form, define
applicability rules and automated answer rules. Set the form to automatically create source measures
and KPIs for each question in the form when the form is published, or set up source measures and
KPIs manually in Scorecards.

1 Desktop (browser) Project Rules In the Project Rules Manager

Manager (PRM), the user configures
transcription rules at the
enterprise level and enables the
transcriptions to be used for
AQM.
The rules' conditions include
interaction metadata which forms
the basis of the cluster definition
used by the AQM service.
2 Project Rules QM database The Project Rules Manager saves

Manager the rules in the QM database.
3 Form Designer Form In the Form Designer, the user

Management creates an automated evaluation
Web Service form.
4 Form Management QM Database The Form Management Web

Web Service Service saves the automated
form in the QM database.
5 Form Designer Applicable From the Form Designer, the user

Interactions accesses the Applicable
Rules Interactions Rules window, and
configures applicable interactions
rules per form.
6 Applicable QM Database The applicable interactions rules

Interactions Rules are saved to the QM Database.
7 Form Designer Automated From the Form Designer, the user

Answer Rules accesses the Automated Answer
Rule window, and configures an
automated answer rule per
question in a form.
A rule can include various types
of condition, for example,
interaction metadata, terms and
phrases, CTI events, and
attributes. The rules are used by
the AQM engine to answer
questions in an evaluation form.

8 Automated Answer QM database The Automated answer rules are

Rules saved in the QM Database.
9 Form Management Performance If the user enabled automatic KPI

Web Management management in the form, when
Service/Scorecards Web Service the form is published, the Form
application Management Web Service
triggers the Performance
Management Web Service to
automatically create predefined
source measures and KPIs for
each question in the form.
If the user does not enable
automatic KPI management in
the form, the user manually
creates source measures and
KPIs for the relevant form
components in the Scorecards
application.
10 Performance Framework The Performance Management

Management Web database Web Service stores the generated
Service source measures and KPIs in the
Framework database.
11 QM database Interaction The ETL process publishes the

DWH database evaluation form to the Interaction
DWH database.
12 Interaction DWH Framework The Form Tree Import Adaptor

database database imports the form's structure to
the Framework database in order
to map the generated source
measures and KPIs to the
relevant form questions.
13 Framework database Scorecards The DWH Sync Adapter

DWH database synchronizes the mapped source
measures and KPIs from the
Framework database to the
Scorecards DWH database.
Fully automated evaluation data flow

After an automated evaluation form is published in the system, the system automatically starts to
fetch interactions that match the form's applicability rules. Applicable interactions are automatically
evaluated with the form and the evaluation data is submitted to the QM Database. The Scorecards

DWH database fetches the evaluation data and calculates the KPI scores and displays them in
Scorecards.
1 Central Contact Every 5 minutes, the CMM retrieves

Missions Database published automated evaluation forms
Manager and associated Applicable Interactions
(CMM) Rules and Automated Answer Rules
from the QM database.
Based on the transcription rules in the
Project Rules Manager and the
Applicable Interactions Rules in the
evaluation form, the CMM fetches
relevant interactions from the Contact
Database.

2 Central QM Database For each retrieved interaction, the CMM

Missions creates a task instance in the QM
Manager Database.
(CMM)
3 AQM Poller Post-Processing Every 2 seconds, the AQM Poller Service

Service Agent (PPA) requests tasks from the PPA.
4 Post-Processing Post-Processing Whenever the PPA queue becomes

Agent (PPA) Server (PPS) almost empty, the PPA requests tasks
from the PPS.
5 Post-Processing QM Database Using a stored procedure, the PPS

Server (PPS) requests tasks from the QM Database
according to the constraints registered
by the PPA.
6 QM Database Post-Processing The QM Database returns tasks to the

Server (PPS) PPS.
The system sorts the tasks by task
priority as defined in the mission rule
(High, Above Normal, Normal, Below
Normal, Low).
The system further sorts the tasks by
task creation time, in descending order
from the newest to the oldest tasks.
If all tasks have the same priority, the
newest tasks are retrieved first for AQM
processing.
7 Post-Processing Post-Processing The PPS returns tasks in bulks of up to

Server (PPS) Agent (PPA) 100 interactions to the PPA. The tasks
are stored in the PPA queue.
8 Post-Processing AQM Poller The PPA returns a bulk of tasks to the

Agent (PPA) AQM Poller.
9 AQM Poller AQM The AQM Poller launches the AQM

Service Orchestrator Orchestrator and sends it the bulk of
tasks.
10 AQM Transcription The AQM Orchestrator fetches from the

Orchestrator Repository TRS a bulk of transcriptions.
Service (TRS)

11 AQM QM Database The AQM Orchestrator fetches the

Orchestrator form's Automated Answer Rules and
interaction metadata from the QM
database.
12 AQM Using the AQM Engine, the AQM

Orchestrator Orchestrator automatically evaluates
(AQM Engine) the the interactions with all the relevant
inputs.
13 AQM Evaluation The AQM Orchestrator submits the bulk

Orchestrator package (Fillout) of evaluations to the Evaluation
package (Fillout).
14 Evaluation QM Database The Evaluation package submits the

package bulk of evaluations to the QM
(Fillout) Database.
15 QM Database Interactions The evaluation data is copied every 20

DWH database minutes to the Interactions DWH
database.
16 Interactions Scorecards Every night (per adapter configuration)

DWH database DWH database or when manually triggered, the Quality
Calculator Adapter fetches the
evaluation data from the Interactions
DWH database, and parses the
evaluation scores into the relevant
source measures in the Scorecards
DWH database.
17 Scorecards Scorecards Every night (per adapter configuration)

DWH database DWH database or when manually triggered, the Calc
Engine Adapter calculates the KPI
scores from the relevant source
measure and stores the results in the
Scorecards DWH database.
18 Scorecards Scorecards The Performance Management

DWH database application retrieves the KPI scores
from the Scorecards DWH database
and displays them to the user in
Scorecards.

Data Flows Speech Analytics Data Flows
Speech Analytics Data Flows

Speech Analytics provides insight into recorded employee-customer interactions that provide
organizations with the capabilities to address and target specific business issues.
Refer to the following Speech Analytics data flows:
 Import Ontology Data Flow, page 102: To provide powerful Semantic Intelligence (Si) data in Speech
Analytics (themes), a canned or factory ontology is uploaded to the Speech Analytics Database. The
ontology is based on the specific business environment of the customer.
 Speech Analytics Transcription Data Flow, page 104: The source data used in Speech Analytics is
based on selected interactions that have been transcribed. Their original audio recording is
converted to text data. Once the transcribed interactions are stored in the database, Speech
Analytics uses the data to create a semantic index and extract themes data for user analysis.
 Interaction Analytics Export Service data flow, page 113: Automatically export transcribed
interactions according to predefined rules in the Project Rules Manager (PRM), to a secure FTP site
or a shared network location.
 Training Data Flow, page 116: The Training process retrieves a sampling of transcribed interactions,
extracts ontology-related items from them, creates an updated ontology and saves it in the Speech
Analytics Database. The items in the ontology (including themes, relations, and terms) can help the
user make non-trivial observations about their business.
 Speech Analytics Index & Themes Data Flow, page 118: Similar to the Training process, the Speech
Application Service retrieves transcribed interactions, and builds a semantic index based on this
data. The Speech Application Service also accesses and processes themes data from the last
published ontology. Both the index and the themes data are used for user analysis.
 Speech Analytics Application Data Flow, page 126: Once the index is built and the ontology data
(themes) has been published, this data is available for user analysis by the Portal.
 Speech Analytics Agent Signature Builder Data Flow, page 128: Describes how the Speech Analytics
solution identifies the agent talk segments in Mono recorded interactions.
Based on the default configuration, the entire Speech Analytics cycle, from when a call is recorded to
when it is built into the index, takes approximately 2 hours. For a detailed breakdown of this process
timeline, see Speech Analytics Pipeline Flow, page 130.
Import Ontology Data Flow

The Application Consultant determines the factory ontology that is installed for the customer.
The system engineer then uploads the relevant factory ontology to the system by an Ontology Import
Tool. The ontology data is then loaded to the database.

1 System Admin Interaction The system administrator uploads a.zip

Analytics file containing the factory ontology to the
Services server where the Interaction Analytics
Services server role is configured.
2 System Admin Interaction The system administrator uses the

Analytics Ontology Import Tool to select the .zip file
Services that resides on the server. The system
administrator selects the .zip file from the
same server on which the Interaction
Analytics Services server role is
configured.
3 Ontology Speech The Ontology Import Tool uploads the file

Import Tool Analytics containing the ontology to the Speech
(Interaction Database Analytics Database.
Analytics Once the ontology has been successfully
Services) loaded to the system, the Analytics
Training process runs on a nightly basis
(according to a predefined schedule).

Speech Analytics Transcription Data Flow

The source data used in Speech Analytics is selected interactions that have been transcribed,
meaning that their original audio recording is converted to text data. Once the transcribed
interactions are stored in the database, Speech Analytics uses the data to create a semantic index
and extract themes data for user analysis.
Based on specific project rules defined by the user, the Speech Transcription Service transcribes
interaction audio files and outputs two different outputs:
 Transcribed text of the recorded conversation
 Speaker Separation (SPS) data from the recording
The Transcription data flow is divided into the following phases:

 Transcription Configuration Data Flow, page 104: Before the transcription servers transcribe stored
interactions, they retrieve:
 Project rules defined by the user and saved in the database
 Metadata of the relevant interactions marked for transcription
 Retrieve Tasks for Transcription Data Flow, page 107: Once the transcription configuration has been
completed, the Post-Processing Agent (PPA) retrieves tasks for transcription and creates a task
queue for the speech transcription server.
 On-premises transcription data flow, page 109 and Cloud Verint Da Vinci Speech Transcription
Service data flow, page 110: In both transcription data flows, the transcription servers retrieve and
transcribe the audio files of the interactions.
In the on-premises data flow, the audio files are transcribed on-site. In the Verint Da Vinci
Speech Transcription Service data flow, the audio files are transcribed in the cloud.
The output is two different types of data:
 Transcribed text of the recorded conversation
 Speaker Separation (SPS) data from the recording
Transcription Configuration Data Flow

Before the transcription servers transcribe stored interactions, they retrieve:
 Project rules defined by the user and saved in the database
 Metadata of the relevant interactions marked for transcription


1 Desktop Project Rules Using the Project Rules Manager (PPM), the user
Manager (PRM) configures transcription rules on the enterprise
level.
The rule includes language and specific
vocabulary, which forms the basis of the cluster
definition used by the Speech Transcription
Service. Each rule is applied to a specific project,
which is associated with a specific Speech
Application Server.
2 Project Rules QM Database The Project Rules Manager saves the rule
Manager (PRM) definitions to the QM Database.
3 Speech Post- When the speech transcription system starts, it

Transcription Processing registers in the Post-Processing Agent (PPA) and
Service Agent (PPA) provides registration information. The registration
information includes the language, vocabulary,
and the associated recorders or Import Manager
(also known as constraints).
4 Post-Processing Post- The PPA passes the registration information to the

Agent (PPA) Processing Post-Processing Service (PPS).
Service (PPS)
5 Post-Processing QM Database The PPS passes the registration information to the

Service (PPS) QM Database.
6 Central QM Database The Central Missions Manager (CMM) retrieves the

Missions missions from the QM Database.
Manager (CMM)
7 Central Contact The CMM creates a query based on the missions

Missions Database and retrieves the relevant contacts metadata.
Manager (CMM)
8 Central QM Database The CMM creates task instances according to the

Missions contacts metadata in the QM Database.
Manager (CMM) Task instances can be pending for maximum one
month. If the system has not yet transcribed the
task, its status is modified to Permanent Fail as
an expired task.
Related topics
Retrieve Tasks for Transcription Data Flow, page 107

Retrieve Tasks for Transcription Data Flow

Once the Transcription Configuration is completed, the Post-Processing Agent (PPA) retrieves tasks for
transcription and creates a task queue for the speech transcription server.

1 Speech Post-Processing The speech transcription system

Transcription Agent (PPA) requests a task from PPA. For the first
Service request, the PPA returns no task. The
PPA gets task metadata.
2 Post-Processing Post-Processing The PPA requests tasks from the PPS.

Agent (PPA) Service (PPS) Steps 2–5 occur periodically, when the
PPA queue becomes almost empty.
3 Post-Processing QM Database The PPS requests tasks, using a stored

Service (PPS) procedure, from the QM Database
according to the constraints registered
by the agent.
4 QM Database Post-Processing The QM Database returns tasks to the

Service (PPS) PPS.
The system orders the tasks by the task
priority defined in the mission rule
(High, Above Normal, Normal, Below
Normal, Low).
The system further orders the tasks by
task creation time in a descending
order from the newest to the oldest
tasks.
If all tasks have the same priority, the
newest tasks are retrieved first for
transcription.
5 Post-Processing Post-Processing The PPS returns the bulk of tasks to the

Service (PPS) Agent (PPA) PPA. The PPA stores the tasks in the
PPA queue.
6 Post-Processing Speech The speech transcription system

Agent (PPA) Transcription continuously requests a task from PPA.
Service When tasks are available in the PPA
queue, the PPA returns a task to the
speech transcription system.
Related topics
On-premises transcription data flow, page 109

On-premises transcription data flow

The transcription servers retrieve and transcribe the audio files of the interactions and output two
different types of data
 Transcribed text of the recorded conversation
 Speaker Separation (SPS) data from the recording
1 Speech Post-Processing The Speech Transcription System retrieves tasks

Transcription Agent (PPA) from the Post-Processing Agent (PPA) according
System to their priority.

2 Speech Media Provider The Speech Transcription System retrieves the

Transcription audio and VAD files from the Media Provider in
System the Recorder.
3 Speech Transcription The Transcriber outputs two different types of

Transcription and Metadata data:
System Files  Transcribed Data: Contains the text of the
recorded conversation between the employee
and the customer.
 Speaker Separation (SPS) data: Contains
speaker separation and silence information
from the recorded conversation.
4 Speech DAS Web API The Speech Transcription System requests the
Transcription language code of the transcribed call in ISO
System format from the DAS Web API.
5 DAS Web API Speech The DAS Web API retrieves the language code in
Transcription ISO format from the QM Database, and sends it
System to the Speech Transcription System.
6 Speech Speech The Speech Transcription System sends the

Transcription Products transcription data to the TRS. The TRS encrypts
System Database (by the transcription data and uploads it to the
TRS) Speech Products Database.
7 Speech Contact The Speech Transcription System sends the

Transcription Database (by speaker separation data of the interaction to the
System MDL) Contact Database (by the MDL). If full-text search
(FTS) is enabled in the system, the Speech
Transcription System sends the transcription data
to the Text Database (by the MDL).
8 Speech Post-Processing The Speech Transcription System update the PPA

Transcription Agent (PPA) with the task status (success/failure).
System
Cloud Verint Da Vinci Speech Transcription Service data flow

The Verint Da Vinci Speech Transcription Service is a cloud-based transcription service that
transcribes the audio files it receives from the Speech Transcription Service.
The Speech Transcription Service retrieves the transcription tasks and the related audio files, and
then transfers the audio files to the Verint Da Vinci Speech Transcription Service for transcription in
the cloud. The transcribed audio files are then processed and indexed by the Speech
Transcription Service.

 To use the Verint Da Vinci Speech Transcription Service in the cloud, you must configure
the relevant server role and Common Cloud Services settings in System Management.
Speech Transcription Service
1. Speech Transcription Post-Processing Agent The Speech Transcription Service

Service (PPA) retrieves transcription tasks from
the Post-Processing Agent (PPA)
according to their priority.
2. Speech Transcription Media Provider For the transcription task to be

Service processed, the Speech
Transcription Service retrieves the
decrypted and compressed
version of the audio file from the
Media Provider in the Recorder.
It then uses the Media Provider
API to get the uncompressed
version.
3. Speech Transcription Speech Transcription The Transcription Engine

Service Service performs segmentation and
separates the interaction's audio
into single-speaker segments.

4. Speech Transcription API Gateway The Speech Transcription Service

Service forwards the following to the
API Gateway:
 Decrypted and compressed
version of the WAV file
 Segmentation information
 Language and vocabulary in
which to transcribe the file
The API Gateway is the
URL configured for the External
Cloud Services server role.
Verint Da Vinci Speech Transcription Service
5. API Gateway DAL The API Gateway authenticates

and authorizes the transcription
request according to the
Common Cloud Services (CCS)
settings, and redirects the
request to the Data Access Layer
(DAL).
DAL interfaces between the
API Gateway and the Verint Da
Vinci Speech Transcription
Service.
DAL assigns the audio to the
correct transcription queue
according to the language and
vocabulary.
6. DAL Percival Percival, the batch consuming

service, polls DAL for queued
tasks relevant to the language
and vocabulary.
DAL retrieves the correct task
from the queue and forwards it
to Percival.
7. Percival Verint Da Vinci Percival sends the decrypted and

Speech Transcription compressed audio segments via
Service gRPC (Google Remote Procedure
Call) to the Da Vinci Transcription
Engine.

8. Verint Da Vinci Percival The Da Vinci Transcription Engine

Speech Transcription transcribes the audio in the
Service requested language and
vocabulary, and sends the
transcribed file to Percival.
9. Percival DAL Percival writes the transcribed

audio segments to the same
queue in DAL it was originally
assigned to.
10. DAL API Gateway DAL forwards the transcribed

segments of the audio file to the
API Gateway with the status of the
transcription request.
11. API Gateway Speech Transcription The API Gateway forwards the
System same to the Speech Transcription
System.
12. Speech Transcription Speech Transcription Performs the second pass on the
Service Service transcribed audio segments:
 Assigns the Transcription
Quality Score
 Labels speakers
13. Speech Transcription Post-Processing Agent The Speech Transcription System

Service (PPA) updates the PPA with the success
or failure status of the
transcription task.
Related information
Workflow: Configure Common Cloud Services (System Administration Guide)
Verint Da Vinci Speech Transcription Service Configuration Workflow (Enterprise Manager Config
& Admin Guide)
Interaction Analytics Export Service data flow

Automatically export transcribed interactions according to predefined rules in the Project Rules
Manager (PRM), to a secure FTP site or a shared network location. Each transcription is exported to a
JSON file, in three different formats. Exporting the same transcription in multiple formats provides

the flexibility to analyze the transcription in different external applications for enhanced insights and
more accurate predictive models.
1 IAES PPFW The Interaction Analytics Export Service

(IAES) registers with the PPFW .
2 Desktop PRM The user creates a transcription export

(Browser) rule in the Project Rules Manager (PRM).
The PRM saves the rule in the Contacts
Database.

3 PPFW IAES The PPFW does one of the following:

 If the transcriptions are ready for the
required interactions, creates export
tasks in the IAES.
 If the transcriptions do not exist for
the required interactions, the PPFW
first creates the transcription tasks,
and then creates the export tasks.
Note that the transcription tasks are
created automatically without the
need for user intervention.
4 IAES PS The IAES queries the Platform Service

(PS) and validates the destination
configured in the export rule.
5 IAES TRS The IAES requests the Transcription

Repository Service (TRS) to send the
transcriptions for every interaction in the
bulk-task set.
The TRS retrieves the transcriptions for
the interactions from the Speech
Products Database and the Speech
Analytics Database, and sends them to
the IAES.
6 IAES DUS Web API Requests the DUS Web API to send the
metadata for every interaction in the
bulk-task set.
7 IAES PS The IAES does the following:

 Processes each of the raw
transcriptions in the bulk-task set, and
creates a JSON version of each
transcription. The JSON includes the
metadata for the interaction, and has
the interaction ID as its filename.
 Exports the JSON set of transcriptions
and metadata in bulk to the PS.
Interactions that are missing
metadata, are also exported with only
the transcriptions.

8 PS SFTP/UNC The PS does the following:

 Creates a ZIP file of the transcriptions,
with the rule name and a unique GUID
as its filename. The ZIP file is
password-protected if so configured.
 Uploads the ZIP file to the folder on
the SFTP or UNC, with today's date as
its name, in dd-mm-yyyy format.
9 PS IAES The PS forwards the status to IAES, which

in turn notifies the PPFW.
Training Data Flow

Every night according to a defined schedule, the Training process runs.
During the Training process, the system retrieves a sample of transcribed interactions. It also
retrieves the last ontology from the Speech Analytics Database (either factory ontology or the
ontology created from the previous night).
 There must be a minimum of 40,000 interactions or 2,000 hours of audio, whose Start Time of
the interactions is within the last 14 days. Otherwise, the Analytics Training process cannot
retrieve the interactions.
For example, there are a total of 50,000 interactions in the system over a month period
(since the system has been up and running). However, in the past 14 days, only 10,000
interactions have been generated. In this case, the Analytics Training process does not
retrieve the interactions and does not run Training.
When the Training process runs, it extracts ontology-related items from the interactions. The Training
process creates an updated ontology and saves it in the Speech Analytics Database. It creates the
ontology by comparing the previous published ontology and the new ontology-related items found in
the interactions.
The items in the ontology (including themes, relations, and terms) can help the user make non-trivial
observations about their business.

1 Integration Analytics Every night, according to a predefined

Server Training schedule, the Integration Server
triggers the Analytics Training process.
2 Analytics Transcription The Analytics Training process sends a

Training Repository request to the TRS to receive a random
Service (TRS) sampling of transcribed interactions.
NOTE: There must be a minimum of
40,000 interactions or 2,000 hours of
audio, whose Start Time of the
interactions is within the last 14 days.
3 Transcription Speech The TRS retrieves the interactions from

Repository Products the Speech Products Database.
Service (TRS) Database
4 Transcription Analytics The TRS returns the interactions to the

Repository Training Analytics Training service.
Service (TRS)
5 Analytics Speech The Analytics Training service retrieves

Training Analytics the last published ontology from the
Database Speech Analytics Database (either the
factory ontology or the ontology
created from the previous night).

6 Analytics Analytics The Analytics Training service runs the

Training Training Training process on the retrieved
interactions.
The Analytics Training service creates
an updated ontology. It creates it by
comparing the last ontology saved in
the Speech Analytics Database and the
ontology-related data it extracted from
the new sample of interactions.
7 Analytics Speech The Analytics Training service stores

Training Analytics the updated ontology version in the
Database Speech Analytics Database.
Speech Analytics Index & Themes Data Flow

Similar to the Training process, the Speech Application Service builds a semantic index every day,
according to a predefined schedule.
The Speech Application Service retrieves transcribed interactions from the Speech Products
Database. It builds the index based on this data. (Training builds the ontology based on the
interactions.)
The index includes transcribed interactions, including the transcribed text of the recorded
conversation and some metadata about the recording.
Once the index is built, it is then exported to different databases in the system for use by other
applications.
After the index is created, the Speech Application Service sends a request to the TRS to access themes
data from the Speech Analytics Database. (The themes data is from the last published ontology built
from the Training process).
The Speech Application Service processes the themes data, computes its metrics, and saves the data
in a separate file (themes). When the user requests to view themes data by the Portal, the Speech
Application Service provides the updated data.
Related topics
Index Data Flow, page 118
Indexed Data Integration Flow, page 120
Themes Data Flow, page 124
Index Data Flow

According to a predefined schedule, the Speech Application Service builds an index of transcribed
interactions. The index includes the transcribed text of the recorded conversation and some
metadata about the recording.

1 Speech TRS According to a predefined schedule, the

Application Speech Application Service requests to
Service retrieve the transcription data from the
TRS.
2 TRS Contact The TRS checks the Contact Database for

Database updated Speaker Separation (SPS) data.
3 TRS Speech The TRS copies the SPS data to the Speech
Products Products Database.
Database

4 TRS Speech The TRS responds by sending the

Application transcription (and SPS) data from the
Service Speech Products Database to the Speech
Application Service.
5 Speech Speech The Speech Application Service processes

Application Application the files and builds the index with the
Service Service latest transcribed data.
NOTE: This process can take several
hours.
Indexed Data Integration Flow

After the system indexes transcribed data, it is then exported to different databases in the system for
use by other applications.

Data Source Destination Description
Interactions Speech Contact Database The Speech Application

(with Application Service processes the
associated Service interactions, and stores
categories) them in an index
repository.
According to a predefined
schedule, the Speech
Application Service exports
the interactions to the
Contact Database.
These scheduled updates
ensure that the database is
updated regularly with the
updated indexed
interactions and their
associated category data.

Hit/no hit Speech Contact According to a predefined

Application Database/Interaction schedule, the Speech
Service Data Warehouse Application Server sends
hit/no hit data to the
Contact Database. The
Interaction Data
Warehouse then pulls this
data.
The system defines
categories in Speech
Analytics by a combination
of the following:
 Category filter: Specific
call attributes about the
interaction (such as
duration of the call, and
the financial impact of
the business issue).
 Category terms: Specific
words, phrases, or
combinations of each
spoken during the
agent-customer
conversation.
Hit represents the number
of interactions per agent
that match the category
filters and contain the
category terms.
No Hit represents the
number of interactions per
agent that match the
category filters, but do not
contain the category terms.
The category filter excludes
non-relevant calls (such as
calls that are short).
Therefore, the No Hit value
is an indicator of how
many relevant calls the
agent made that do not
contain the terms defined
for the category. This value
gives the proper

perspective to the Hit

value.
The Hit/Not Hit data is
used by Scorecards to
calculate statistical
information. The
Scorecards application
takes the number of
interactions that matched
the term-matching logic
(Hit). It then compares it
with the number of
interactions that did not
match this logic (No Hit).
The daily aggregated hit/no
hit values are used in
Scorecards for creating
KPIs that measure agent
performance.
Analytics Interaction Framework Data According to a predefined

Data Warehouse schedule, the Import
Warehouse Adapter on the Framework
Database retrieves the
Speech Analytics data from
the Interaction Data
Warehouse. It then stores
it in the Framework Data
Warehouse to use for
integration with other
applications.

Themes Data Flow

The Speech Application Service accesses themes data from the Speech Analytics Database. It then
processes the data, including calculating metrics and theme statistics. It creates a separate file that
contains the data.

1 Speech Transcription The Speech Application Service sends a

Application Repository request to the TRS for themes data.
Service Service (TRS) Each theme contains a list of items,
including:
 Terms: Terms that are meaningful
to a specific type of business or
phrases that stand out in
interactions.
For example, a theme can contain
the following terms and phrases:
Verify, confirm, want to confirm, and
wanted to confirm.
 Relations: Two terms that were
found close to each other in one
interaction.
For example, speak <-> supervisor is
one relation. The words speak and
supervisor were found within close
proximity to one another in an
interaction.
2 TRS Speech The TRS retrieves themes data from the

Analytics Speech Analytics Database.
Database
3 TRS Speech The TRS forwards the themes data to

Application the Speech Application Service.
Service
4 Speech Speech The Speech Application Service

Application Application processes the themes data, and saves
Service Service the data in a separate file.
Processing includes:
 Comparing the indexed interactions
with the relations in the themes
data, and generating a list of
suggested terms
 Calculates the metrics of each
theme, including average silence
time, average duration, and count
for the interactions represented by
the theme

Speech Analytics Application Data Flow

Once the index is built and the ontology data (themes) has been published, this data is available for
user analysis.
1 Desktop Desktop A user with the relevant permissions is

able to go to the Speech Analytics
application.
2 Desktop Interaction The Speech Analytics application

Applications (Interaction Applications Server Role) is
opened and the user is automatically
connected to the first project (listed in
alphabetical order).
The user permission settings affect the
list of projects the user has access to.

3 Interaction Speech The Speech Analytics application

Applications Application (Interaction Applications Server Role)
Server sends the request to the Speech
Application Service.
Depending on the request, the Speech
Application Service communicates with
the relevant subcomponent.
For example, the Speech Application
Service communicates with the Complete
Semantic Index to retrieve a list of
interactions. This retrieval is for text
searches, context-based suggestions,
root-cause analysis and for applying
metadata filters.
To retrieve updated themes data, the
Speech Application Service reads the
themes data, including metrics, from the
most updated themes file. It then sends
the data to the Portal.
NOTE: If a user modifies a Published
category or deletes a category, category
results can be synchronized with system
databases. Synchronizing Speech
category data with system databases
allows other suite applications (such as
Quality Monitoring and Scorecards) to
access and use updated Speech category
results. Once the synchronization
process is initiated, it can take up to one
hour for all the databases to be updated
with the new category results.
4 Speech Interaction The Speech Application Service then

Application Applications returns the response with the data to the
Service Speech Analytics application.
5 Interaction Desktop The Speech Analytics application then

Applications presents the results to the user.
Related topics
Applications User Setup, page 64

Speech Analytics Agent Signature Builder Data Flow

Speech Analytics supports Speaker Separation by identifying an employee (agent) in a mono-
recorded interaction.
The system identifies an employee-specific voice characteristic, and builds a unique voice signature
per employee. With this voice signature, the Transcriber is able to tag accurately the employee part of
the transcription.
1 Transcriber TRS The Transcriber sends the transcription

feature metadata to the TRS.
2 TRS Speech The TRS sends the transcription feature

Products DB metadata to the Speech Products
Database.

3 Speech Agent The Agent Signature Builder (ASB)

Products DB Signature requests and takes the feature metadata
Builder from the Speech Products Database.
The ASB then builds the Agent Signature.
4 Agent Speech The ASB places the Agent Signature data

Signature Products DB in the Speech Products Database.
Builder
5 Transcriber Speech The Transcriber connects to the Speech

Products DB Products Database by the Phonetics
Boosting gateway to check if Agent
Signatures exist.
The Phonetics Boosting gateway gives the
Transcriber access to the Speech Products
Database.
6 Speech Transcriber If the ASB files exist in the Speech

Products DB Products Database, the Transcriber (by
using the Phonetics Boosting gateway),
takes the files. This retrieval process is a
request and response process.
7 Transcriber Speech The Transcriber performs Speaker

Products DB Labeling. The Speaker Separation data is
sent to the Speech Products Database
together with the transcription by TRS.
8 Transcriber Contact DB The Transcriber puts the Agent Talk

metadata in the Contact DB.

Speech Analytics Pipeline Flow

Based on the default configuration, the entire Speech Analytics cycle takes approximately two hours.
The cycle begins when a call is recorded and ends when it is built into the index.
Process Description Duration
Extraction After the call is recorded, it is Total: 15–30 minutes

Engine (Optional) extracted from the source Recorder.
Call is stored in The call is stored in the Central Total: 15–30 minutes (15-
database Contact Database. min ETL schedule + 15-min
delay)
Transcription PPFW cycle: 5 minutes

Rules (PPFW) Every time it is activated, the Post-
Processing Framework (PPFW)
searches the Contact Database for
interactions that match the currently
enabled rules.
According to these rules, PPFW
compiles a list of actions that must be
performed on each interaction and
executes them.
NOTE: The maximum number of
interactions in the queue is 3 Million
(default).
Database Delay After a configurable lag time delay, 5–30 minutes (default: 5
from Real-Time the Project Rules Manager retrieves min)
records from the Sessions View.
Transcription Based on the transcription rules, the Near Real-time

original audio recording is converted NOTE: This duration
to text data. The transcribed data is assumes that the system is
stored in the database. sized to the peak hours
rate of the Contact Center.
Indexing Once the transcribed interactions are 1 hour

stored in the database, Speech
Analytics uses the data to create a
semantic index and extract themes
data for user analysis.
Total Entire process, including all processes ~2 hours

Data Flows Text Analytics data flows
Text Analytics data flows

Text Analytics provides data on text-based interactions in your enterprise. The Text Analytics
application allows you to take advantage of this data to gain valuable insights into key business issues
in the enterprise.
 Text Analytics data ingestion flow, page 132: describes how the source data is acquired by the
recorder, transformed, and indexed to generate analytic insights.
 Text Analytics application data flow, page 134: describes how once the index is built, the data is
available for display and analysis through the Text Application.
 Text Analytics model management data flow, page 135: describes how users can manage the text
language model used by the Text Analytics Service (TAS).
 Text Analytics alarms and monitoring flow, page 136: describes how alarms are generated for TAS
services and displayed in the System Monitor's Alarm Dashboard.

Text Analytics data ingestion flow

The source data is captured by the recorder, transformed, and indexed to generate analytic insights.
Seq. # Source Destination Description
1 Data Source Interaction The Interaction Capture Service ingests

Capture documents from one or more data
sources and vendors, and transforms
each document into a uniform format.

2 Interaction Capture Coordinator The Interaction Capture service stores the

Service documents on the Recorder call buffer.
The Recorder Consolidator service
forwards the documents to the
Coordinator Service in TAS.
During the transformation, the
Coordinator Service extracts metadata
fields, calculated fields, and maps them as
per TAS requirements.
Marking Data The Interaction Capture service stores the

Layer (MDL) documents on the Recorder call buffer.
The Recorder Consolidator service
forwards the documents to the MDL.
3 Marking Data Layer Contact The MDL sends the interaction and
(MDL) Database contact information to the Contact
Database.
4 Coordinator Service Tagger Service The Coordinator Service forwards the

transformed data to the Tagger Service,
also in the TAS.
The Tagger Service enriches the data in
the document by tagging it as themes,
relations, topics, and key terms.
5 Tagger Service Search Service The Tagger Service forwards the tagged
data to the Search Service.
6 Search Service Text Indexing The Search Service stores the data in the
Service Text Indexing Service.

Text Analytics application data flow

Once the index is built, the data is available for display and analysis through the Text Analytics portal.
 The flow shows only those TAS services that are applicable to the current flow.
1 Client Text Application The client logs on to the Text Application and
performs a search for interactions to analyze.
2 Text Application Search Service The Text Application forwards the search
query to the Search Service.
3 Search Service Text Indexing The Search Service queries the Text Indexing
Service Service and returns the search results.

Text Analytics model management data flow

The Text Analytics model management data flow describes how users can manage the text model
used by the Text Analytics Service (TAS).
 The flow shows only those TAS services that are applicable to the current flow.
1 Client Model The client selects a text language model to

Management edit.
Service (UI)
2 Model Configuration The Model Management Service (UI) updates

Management Service the Configuration Service with the changes to
Service (UI) the text language model.

Text Analytics alarms and monitoring flow

The Alarm Monitoring Service monitors the health of TAS services, generates alarms, and forwards
them to the Enterprise Manager for display in the Alarms Dashboard.
1 TAS Services Alarms and The Alarms and Monitoring Agent collects health
Monitoring metrics from each of the TAS services that it
Agent monitors.
2 Alarms and Alarms and The Alarms and Monitoring Manager does the
Monitoring Monitoring following:
Agent Manager  Polls the Alarms and Monitoring Agent at
predefined intervals, and retrieves the metrics
for each TAS service that is monitored.
 Groups the incoming alerts by the TAS server
from which the alert originated, and by the
TAS service for which the alert is sent.

3 Alarms and Enterprise The Alarms and Monitoring Manager generates

Monitoring Manager alarms for the relevant TAS services and
Manager forwards them to the Enterprise Manager.
4 Enterprise Framework The Enterprise Manager stores the active alarm

Manager Database XML files received from the Alarms and
Monitoring Manager in the Framework Database.
5 Framework Enterprise When a user selects System Monitoring >

Database Manager System Monitor > Alarm Dashboard in the
user interface, the Enterprise Manager connects
to the Framework database, retrieves the active
alarms for all TAS services, and displays the
active alarm information in the Alarm
Dashboard.
TAS alarms and services mapping reference

The table maps the TAS service alarm as displayed in the Alarm Manager to the name of the TAS
service in the documentation.
TAS Alarm TAS Service
TaggerService Tagger Service
VTACoordinator Coordinator Service
ConfigService Configuration Service
EASearchService Search Service
EASolrService Text Indexing Service
Model Editor Service Model Management

Service
PurgerService Purger Service
Elk Service Central Logger Service
Fluentd Logger Service
Zookeeper Service Apache ZooKeeper

Data Flows Interaction Analytics application data flow
Interaction Analytics application data flow

Interaction Analytics provides a unified view of interaction data from the Speech and Text Analytics
applications in a single location.
Once the user selects an Interaction Analytics project, the system retrieves the relevant data from
Speech and Text for display and analysis.
1 Desktop Interaction In the Interaction Analytics application, the user

Analytics either creates a new project or opens an existing
Interaction Analytics project.
The Interaction Analytics project is mapped to a pair
of Speech and Text Analytics projects.
2 Interaction Speech The Interaction Analytics application sends a request

Analytics Application to the Speech Application Service to retrieve relevant
Service interaction data for the Speech Analytics project.
Depending on the request, the Speech Application
Service communicates with the relevant
subcomponent, and sends the data to the
Interaction Analytics application.

Data Flows Interaction Analytics application data flow
Text Analytics The Interaction Analytics application sends the

Service request to the Text Analytics Service (TAS) to retrieve
the relevant data for the Text Analytics project.
The TAS communicates with the relevant service and
sends the data to the Interaction Analytics
application.
3 Interaction Desktop The Interaction Analytics application then displays

Analytics the data for trends or themes to the user.

Data Flows Encryption Data Flows
Encryption Data Flows

Encryption is the process of transforming information in plaintext to an unreadable state to protect
the data from being read and understood. Decryption is the process of making the data readable
again.
The encryption data flows describe the encryption and decryption processes for recording, playback,
transcription, and transcript storage and retrieval in Speech Analytics.
Related topics
Recording With Encryption Data Flow, page 141
Recording Using Import Manager With Encryption Data Flow, page 142
Speech Analytics Encryption Flows, page 148

Recording With Encryption Data Flow

When encryption is enabled, the Recorder encrypts the data using a key and places the key ID in the
file header. The encrypted media (and metadata) is saved to the recorder call buffer.
1 Recorder Recorder The Recorder initiates the recording of an

interaction.
The Recorder records the data (media
and metadata), and stores it in memory
in a secure buffer.

2 Recorder Local Key Recorder checks the Local Key Cache for
Cache a valid key.
One of the following occurs:
 If the key is valid, the Recorder uses
the key and the process continues
with step 6.
 If the key is not valid, the process
continues with step 3.
3 Recorder KMS API If the Recorder does not have a valid key
in the Local Key Cache, it sends a key ID
request to the KMS API.
Note: Every 5 minutes the recorder
checks with the KMS API to verify that the
key is still valid.
4 KMS API Recorder The KMS API retrieves the key from the
KMS and then returns the key to the
Recorder.
5 Recorder Local Key The Recorder uses the Local Key Cache to
Cache cache the latest (active) key in a secure
manner.
6 Recorder Call Buffer The Recorder encrypts the data using the
current key and places the key ID in the
file header.
The encrypted media (and metadata) is
saved to the recorder call buffer.
Recording Using Import Manager With Encryption Data Flow

When encryption is enabled and the Import Manager extracts the recording data, the Import
Manager places the data in a temporary cache on the recorder. It then encrypts the data using a key.
The encrypted media (and metadata) is saved to the recorder call buffer.

1 Import Recorders Based on defined settings, the Import

Manager (by (Sources) by Manager extracts the audio and
Adapters) Adapters metadata from the relevant recorders
(sources) by the corresponding adapters
according to the configured job schedule.
2 Import Media The Import Manager places the audio

Manager (by Processing and metadata of the calls in the MPC, a
Adapters) Cache (MPC) temporary cache on the local recorder,
while it processes the data.

3 Recorder Recorder Recorder initiates consolidation (or

encryption) of the recording. It reads the
data from the temporary cache on the
local recorder into a secure buffer in
memory.
4 Recorder Local Key Recorder checks the Local Key Cache for
Cache a valid key.
One of the following occurs:
 If the key is valid, the Recorder uses
the key and the process continues
with step 8.
 If the key is not valid, the process
continues with step 5.
5 Recorder KMS API If the Recorder does not have a valid key
in the Local Key Cache, it sends a key ID
request to the KMS API.
Note: Every 5 minutes the recorder
checks with the KMS API to verify that the
key is still valid.
6 KMS API KMS The KMS API retrieves the key from the
KMS and then returns the key to the
Recorder.
7 Recorder Local Key The Recorder uses the Local Key Cache
Cache to cache the latest (active) key in a secure
manner.
8 Recorder Call Buffer The Recorder encrypts the data using the
current key and places the key ID in the
file header.
The encrypted media (and metadata) is
saved to the recorder call buffer.

Playback Interaction with Encryption using ActiveX Data Flow

The Playback Interaction with Encryption using ActiveX data flow shows interaction retrieval for
playback when using the ActiveX Player with encryption enabled.
1 Desktop Audio File The Player application checks if the audio

(Player) file is encrypted by the header (if a Key ID
is attached to the header).

2 Desktop Key Proxy Web If a Key ID is in the header, the Player

(Player) Service extracts it. It then sends an encryption
request to the Key Proxy Web Service to
retrieve the key from the KMS by HTTPS.
3 Key Proxy Web KMS The Key Proxy Service sends a key ID
Service request to the KMS API by HTTPS. The
KMS API forwards the request to the
KMS.
The KMS responds by sending the key to
the Key Proxy Web Service (through the
KMS API).
4 Key Proxy Web Desktop The Key Proxy Web Service sends the key
Service (Player) to the Player by HTTPS.
5 Desktop Desktop The Player uses the key to decrypt the file
(Player) (Player) in memory, and plays it back to the user.
By default, the browser saves
downloaded files in its temporary
internet files folder in an encrypted
format.
Related topics
Playback Interaction with Encryption using HTML5 Streaming

Data Flow
The Playback Interaction with Encryption using HTML5 Streaming data flow shows interaction
retrieval for playback when using the HTML5 streaming Player with encryption enabled.

1 Desktop Content Access The Browser on the desktop, using URLs

(Browser) provided by the Playback components,
requests content using HTTPS. The
content access request is routed to the
Content Server.
2 Content Server Desktop Content Server reads encrypted data

(Browser) (from the Call Buffer, Content Server
cache, Archive cache, or similar) and then
decrypts the data in memory.
For HTML5 streaming playback, Content
Server uses HTTPS to return the audio,
screen, and video data requested by the
Desktop (Browser). This step occurs
iteratively, as needed, for streaming
replay. While delivered using in-transit
encryption, because data remains in
memory and is not cached to disk, at-rest
encryption is not used on the Desktop.
 Data cached by the Desktop

browser or by proxies between
the Desktop and the Content
Server (if any) do not use at-rest
encryption.
Related topics

Speech Analytics Encryption Flows

During encryption and decryption processes, data is transferred between system components—for
example, from TRS to Speech Products Database and conversely.
 To ensure that sensitive data is encrypted during these transfers, you must use HTTPS
protocols and enable HTTPS on your site.
For details on HTTPS enablement, see the Security Configuration Guide.
The encryption and decryption processes include:
 The Playback component in the Speech Transcription Service decrypts the file so that it can
decompress it. Once the file is decompressed, the Speech Transcription Service can transcribe the
file into text.
 After the Speech Transcription Service transcribes the file, it sends the transcript to the TRS over
HTTPS. In turn, the TRS encrypts the transcript. It then stores it in an encrypted format in the Speech
Products Database.
 Requests to retrieve transcripts are sent to the TRS over HTTPS. The TRS reads and decrypts the
transcript from the Speech Products Database, and sends the decrypted file to the requesting
service over HTTPS.
 The following encryption diagrams assume that the system is configured to use the HTTPS
protocol for network communications.
Related topics
Speech Analytics Audio and Video File Decryption Data Flow, page 148
Speech Analytics Transcript Storage Data Flow, page 150
Speech Analytics Transcript Retrieval Data Flow, page 152
Speech Analytics Audio and Video File Decryption Data Flow

Encrypted audio and video files are decrypted before their content is transcribed into text and
speaker separation (SPS) data.
The Speech Transcription Service decrypts a file to make it ready for transcription. The TRS then
encrypts the transcript and sends it to the Speech Products Database.

Data Center
Data Processing
Framework Interaction
Archive
Contact Databases
Framework
Data Data OLTP
Database Database
Warehouse Warehouse Database Interaction Interaction
Analytics Flow
Speech Services Manager
Contact QM Speech
DPA
Analytics Products
Database Database Database
Database Database Forecasting
Framework
and
Integration
Scheduling
Biometrics Service
Service
Database
Speech
Application
Service
Web Applications
Interaction Framework DPA
Applications Applications Application
Reporting Services
Encryption Services
4 Reporting
Services
KMS
Database
HTTPS
Size Zones Content Processing

Recorder
4 KMC Local
IP Recorder
Screen
Recorder
5 Playback SDK Cache
TDM IP 2 3
Recorder Analyzer
Audio file 6
1
Integration Services
Content Access
Content Storage
Telephone Recorder
Content Integration
Playback
Server Central
Service Service
Archive
1 Content Server Encrypted The Speech Transcription Service downloads

Audio File the encrypted audio files from the Content
Server.
2 Speech Playback SDK The Speech Transcription Service notifies the

Transcription Playback SDK about the location of the
Service downloaded audio files.

3 Playback SDK Playback SDK The Playback SDK:

 Checks if a key ID is attached to the
header of each file to verify that the file is
encrypted.
 Extracts key ID from the header.
4 Playback SDK Local Key The Playback SDK either retrieves the key
Cache/KMS from the Local Key Cache or from the KMS
(through the KMS API) by HTTPS.
5 Playback SDK Playback SDK The Playback SDK uses the key to decrypt
the file in memory, and decompresses the
file to PCM format.
The Speech Analytics Transcription Engine
can now transcribe the decrypted file.
6 Speech Encrypted The Speech Transcription Service deletes the

Transcription Audio File previously downloaded encrypted audio files
Service from disk.
Related topics
Speech Analytics Transcription Data Flow, page 104
Speech Analytics Transcript Storage Data Flow

Decrypted transcript files need to be encrypted before they are stored in the Speech Products
Database.
The Speech Transcription Service sends a transcript file to the TRS by HTTPS. The TRS then encrypts
the transcript and stores it in the Speech Products Database in an encrypted format.

1 Speech TRS The Speech Transcription Servers send

Transcription the transcription output files to the TRS
Servers by HTTPS.
HTTPS ensures that the data is
encrypted while it is in transit.
2 TRS Local Key The TRS either retrieves the key from
Cache or KMS the Local Key Cache or from the KMS
(through the KMS API) by HTTPS.
3 TRS Speech The TRS encrypts the data using the

Products DB current key and places the key ID in the
encryption header.
The TRS then stores the encrypted data
in the Speech Products Database.

Speech Analytics Transcript Retrieval Data Flow

Encrypted files are decrypted before they are retrieved.
You can extract transcripts for several purposes, such as indexing, reporting, and playing back
purposes.
The following diagram shows how TRS clients request a transcript from the Speech Products
Database by HTTPS. The TRS then decrypts the transcript and sends it back to the client by HTTPS.
1 Services TRS A specific service in the system requests

requesting to retrieve a transcript from the TRS
transcripts though HTTPS.
HTTPS ensures that the data is encrypted
while it is in transit.
2 TRS Speech The TRS reads the encrypted transcript

Products and the encryption header from the
Database Speech Products Database.
3 TRS Local Key The TRS either retrieves the key from the
Cache or KMS Local Key Cache or from the KMS
(through the KMS API) through HTTPS.

4 TRS Services The TRS uses the key to decrypt the

requesting transcript in memory, and sends the
transcripts decrypted transcript to the requesting
client through HTTPS.
HTTPS ensures that the data is encrypted
while it is in transit.

Data Flows Desktop Messaging Data Flows
Desktop Messaging Data Flows

The Desktop Messaging Server (DMS) component of the Framework Application server role is used to
deliver messages directly to the desktop.
These desktop messages can be notifications sent from a fellow employee, such as a supervisor or
manager. They can also be messages triggered by an alert rule to which you are assigned in the
system.
Messaging architecture updates

The Desktop Messaging Server replaces the Pop-up Notification server in previous releases. New
client/server protocol replaces pop-up reliance on SIP and DNS routing. SignalR architecture now
does the DMS routing.
Desktop messaging data flows

There are two main flows used by the system for sending desktop messages:
 Desktop Message Sent On Demand, page 155: A user logs on to the Workforce Management portal
and sends a desktop message to another user, using the Send Message button.
 Desktop Messages Sent by Organization Alert Rules, page 156: The Workforce Management
administrator configures alert rules. These rules can be fed by Adherence data, Scorecard KPIs, and
RTSNs. When a rule is triggered, desktop message are sent automatically or a DPA trigger is fired.

Desktop Message Sent On Demand

WFM portal users can click the Send Message button to send a Desktop Message to users manually, as
needed. A supervisor can send messaged to a group of employees. They can also send a message to
the desktop of an administrator.
Send Messages to Desktop On Demand
1 WFM Portal Desktop The Portal user uses the Send

Messaging Message option by filling in the
Server Desktop Message dialog with details
of the recipients and the message to
send.
2 Desktop Desktop The DMS sends a request to the

Messaging Server Messaging desktop to activate the Desktop
Clients Messaging client. The desktop user
is notified that they have received a
new message.

Desktop Messages Sent by Organization Alert Rules

The Workforce Management administrator can configure organization rules based on data from WFM
Adherence, Scorecard KPIs, and RTSNs.
When a rule is triggered, desktop messages are sent automatically or a DPA trigger can be set to fire.
Send Rule Based Alerts or DPA Triggers Automatically
1 WFM Applications Foundation The source application supplies the

or Analytics Alerts web Foundation alerts web service with
Engines (RTSA or service the information required to invoke
Biometrics) the configured desktop messaging
rules or the DPA trigger.
2 Foundation Alerts Desktop The Foundation alerts web service

web service Messaging invokes the rules engine to activate
Server (DMS) the DMS.
3 Desktop Desktop DMS sends a request to the desktop

Messaging Server Messaging Client to activate the Desktop Messaging
or DPA Client or DPA client. The desktop user is
notified that they have received a
new message or DPA fires a trigger
on the desktop.

Data Flows Desktop and Process Analytics Data Flows
Desktop and Process Analytics Data Flows

Desktop and Process Analytics (DPA) captures and analyzes information concerning how users interact
with their business-critical software applications.
The DPA Application modules provide a detailed analysis of application activity. The modules provide
information that the enterprise can use to optimize business processes and improve the use of
enterprise resources.
Related topics
DPA client/server data flow, page 157
DPA Reporting data flow, page 158
DPA Integration with WFM Data Flows, page 160
View DPA Applications in Player Data Flow, page 162
View Interactions Data in Timeline Report Data Flow, page 163
DPA client/server data flow

The DPA client regularly sends requests to the server for the current version of triggers, processes,
guidance, and NBA scripts. When the client version differs from the server version, the client sends an
extra request for the updated configuration information.
The client is installed on a Citrix or computer and multiple end users access the client machine in
parallel.

1 DPA Client DPA Desktop The employee logs in to a DPA

Transfer Service monitored workstation.
The DPA client notifies the DPA
Desktop Transfer Service of a new
logged in user.
2 DPA Desktop DPA Applications The DPA Desktop Transfer service

Transfer Service Web Service sends a request for the
configuration versions of DPA
components for the logged in user.
The data requested includes
configuration versions for these
components:
 Triggers
 Steps and Processes
 NBA and Guidance scripts
3 DPA Desktop DPA Applications When the client version differs from
Transfer Service Web Service the server version, the DPA Desktop
Transfer service requests the
updated configuration information
for each component with a
mismatched version.
4 DPA Applications DPA Database The DPA Applications service

Web Service retrieves the DPA configuration data
from the DPA Database.
5 DPA Database DPA Applications The DPA Database forwards data to

Web Service the DPA Applications service.
6 DPA Applications DPA Desktop The DPA Applications service

Web Service Transfer Service forwards the data to the DPA Client
Transfer Service for processing by
the DPA client.
DPA Reporting data flow

The DPA Reporting user accesses DPA by navigating through the WFM Portal. The user generates a
report based on DPA data retrieved by DPA Applications from the DPA Database.

1 Desktop (WFM) Desktop (DPA A user with the relevant DPA

Reports) Reporting permissions logs in to
WFM and navigates to DPA Reports.
2 Desktop (DPA DPA Applications The DPA reports user defines report
Reports) parameters and clicks Display. A
request is sent to the DPA
Applications to generate the report.
3 DPA Applications DPA Database DPA Applications send a request to

retrieve DPA data from the
database.
4 DPA Database DPA Application DPA Database forwards the data to

DPA Applications.
5 DPA Application Desktop (DPA The DPA reports module presents

Reports) the report results to the user.
Related topics

DPA Integration with WFM Data Flows

The DPA Database sends data contained in *.csv files to the WFM Adherence and VCT applications,
using a dedicated DPA integration adapter. A further adapter imports user and organizational
hierarchy information from the user management module to the DPA Database.
1 DPA Database Framework WFM Adherence

Database An IS adapter delivers an Adherence
compatible file containing activity usage
data to either the primary or secondary
line of the WFM Adherence module.
Adapters:
 DPA - Adherence adapter
 Generic WFM File Import Time
Collection (FTCI) interface

2 DPA Database Framework WFM VCT

Database A VCT compatible file is sent to the WFM
Volume Capture Tool (VCT) for use as
work volume events. The file contains a
count of triggers, steps, and processes
activated on the DPA monitored
workstations
Adapters:
 DPA - VCT Feed sends a data file to VCT
 Operations - Event File Import and
Transform adapter automates the bulk
import.
3 DPA Database Framework Scorecards

Database DPA Application usage data is sent
directly to Scorecards by an Integration
Service, using a database stored
procedure.
DPA desktop activity data including
application usage, events/triggers, steps,
and processes is used by Scorecards as
KPI source measures.
Adapters:
 Scorecards - DPA Source Metadata and
Measures Import SQL Adapter
 Scorecards - Calc Engine adapter
4 Framework DPA Database User Management

Database DPA imports users and organizations into
Role the DPA Database and adopts the
hierarchy for visibility and applicability of
DPA triggers, steps, processes, modules,
and applications.
Adapters:
 DPA employee synch adapter
 DPA employee export adapter

View DPA Applications in Player Data Flow

The player displays employee application activity during recorded interactions by retrieving data from
the DPA applications web service.
1 Interaction DPA Playback sends a web service request

Applications Web Application to DPA to retrieve application usage
Service Web Service data.
2 DPA Application Interaction DPA applications web service forwards

Web Service Applications the application activity data to the
Web Service Interactions applications web service.
3 Interaction Desktop The player displays employee

Applications Web (Playback) application activity as a bar below the
Service wave form. The applications are color
coded and the user can navigate to a
section of the interaction where a
specific application is in use.

View Interactions Data in Timeline Report Data Flow

A DPA Reporting user can configure the Application Duration Timeline By User reports to display
interaction data. The user can drill down and access the interaction itself that took place while
running defined applications, triggers, steps of processes.
1 Desktop (WFM) Desktop (DPA A user with the relevant DPA

Reports) Reporting permissions logs in to WFM
and navigates to DPA Reports.
2 Desktop (DPA DPA The DPA reports user defines

Reports) Applications parameters for an Application Duration
Timeline By User report and clicks
Display.
A request is sent to the DPA
Applications to generate the report.
3 DPA Interaction DPA Applications make a request for

Application Applications customer interaction data to be sent
Web Service to the DPA desktop.
4 Interaction Desktop DPA Timeline Reports display

Applications interactions data and the user can drill
Web Service down into the Interaction itself.

Related topics

Data Flows Archive Topologies
Archive Topologies
(ACRA only) After a recorder has completed recording a contact, it stores it on its local disk. The
recorder call storage drive, no matter how large, has some limit to its capacity. Therefore, at some
point, the older contacts need to be moved to long-term storage.
Archive refers to the infrastructure dedicated to preserving call information in long-term storage
(usually for one year and longer, depending on customer requirements). The archive service transfers
recorded content from recorders to specific storage media for preservation.
The following are the two different archive topologies that can be configured:
 Local Archive Topology, page 165: Recorders push contacts directly from their local call buffer to the
target media.
 Central Archive Topology, page 167: Central archive server is configured to pull contact data from
Recorders and write this data to the target media.
Each type of archive (local or central) can be deployed in different configurations. To determine which
type of archive is used depends on the topology best suited for a customer specific requirements (see
Local vs. Central Archive, page 168).
For detailed information on archive functionality, general data flow, setup, and configuration, see the
Archive Administration Guide.
Local Archive Topology

(ACRA only) Recorders push contacts directly from the local call buffer to the target media.

Configuration Option Description
Local Archive with Removable One Recorder is attached to some type of

Media removable media (tape drive or DVD).
(Site 1) In this configuration, this specific Recorder is
configured with Local Archive to write to the
specific removable media.
The only data transferred between the Site and
the Data Center is lightweight, archive activity
(such as status updates, updates to the database,
progress tracking).
Local Archive with Fixed Media Fixed media (SAN or Centera) is located in a Site,
Onsite and can be shared among multiple Recorders.
(Site 2) The only data transferred between the Site and
the Data Center is lightweight, archive activity. The
data includes status updates, updates to the
database, and progress tracking.

Local Archive with Fixed Media Fixed media (SAN or Centera) is located outside a
Offsite particular Site (either in Data Center or in another
(Sites 3 & 4) site in the enterprise).
The Recorders in a specific site configured with
Local Archive push contact data across WAN
bandwidth to the fixed media located in a
different location.
Central Archive Topology

(ACRA only) The Central Archive server is configured to pull contact data from Recorders and write
this data to the target media.

Central Archive Onsite One or multiple Central Archive servers are located in a
(Site 1) specific site.
In this configuration, the Central Archives pull contact data
from the Recorders configured in the same site. They write the
data to specific removable or fixed media.
All archive data stays within the same site, and is not pushed
across a WAN. Therefore, the only data transferred between
the Site and the Data Center in this configuration is lightweight
archive activity. This includes status updates, updates to the
database, and progress tracking.
Central Archive Offsite One or multiple Central Archive servers are located in the Data
(Sites 2 & 3) Center.
In this configuration, the Central Archives pull contact data
across a WAN from the Recorders located in a specific Site.
They then write the data to specific removable or fixed media
located in the Data Center.
This configuration allows pulling contact data from multiple
sites to a single archive server. Alternatively, you can subdivide
Central Archive servers by site, based on data load
considerations.
Local vs. Central Archive

(ACRA only) The supported functionality and features of both the local and central archives are the
same. The local archive can archive selective contacts based on a campaign, which is an
enhancement from previous versions. You can run the same campaign rules using both local and
central archives.
The topology differences between local and central archives determine the type of archive suitable
for specific customer requirements:
Topology Issue Local Central
Archive Server No need to maintain Central Need to have dedicated

Maintenance Archive servers servers for archive purposes
(Central Archive servers)

Data Streaming If target archive media is co- Need to stream data from
located on site with the the Recorder to the Central
recorders, or is physically Archive servers.
attached to each recorder, If the Central Archive server
you can avoid streaming data is located in the Data Center,
across a WAN. it involves streaming data
across a WAN.
Connectivity to Target Every Recorder needs Only the Central Archive

Media connectivity to the specified server itself needs
target media: connectivity to the target
 Removable media: media, which is ideal under
Connectivity issue is minor the following circumstances:
because the media is  Removable media: When
connected directly to the it is required to
Recorder consolidate data from
 Fixed media: The multiple recorders, and
Recorder writes the write it to a single
archive data to the media. removable media
If a centralized fixed media  Fixed media: A SAN or
cluster is configured in the Centera cluster is
Data Center, every configured in the Data
Recorder needs Center with restrictive
connectivity and access to access. In this
that cluster. configuration, only a few
specific servers can write
to that media.
The Central Archive pulls
data from multiple
Recorders, consolidates it
and writes it to the target
media.

Archive Task Need to configure, manage, Need to configure, manage,

Maintenance and maintain archive and maintain archive
processes on every Recorder processes on a reduced
in the enterprise. number of Central Archive
Archive processes are servers (as compared to
configured and maintained Recorders in the local archive
according to best practices topology).
on all Recorders. Therefore, the number of
places to configure archives,
check for alarms and perform
general archive maintenance
tasks is considerably
decreased when using the
Central Archive topology.

Data Flows Database Processes
Database Processes
The following describes the main database processes in the system:
 Database ETL Flows, page 171: Describes the main database ETL (Extract, Transform, Load) flows in
the system, including marking, transferring and synchronizing data between databases.
 Database Retention and Purging, page 173: Describes the retention and purging setup and process
logic of various databases in the system.
Database ETL Flows

There are various ETL (Extract, Transform, Load) flows in the system.
Data Center
Data Warehouse
QM Application ETL Interaction Data Databases
Database Warehouse
Framework Speech
Data Analytics
Warehouse Database
Data Warehouse
Contact ETL Speech
DPA
Products
Database
Database
Contact OLTP Contact
Database Contact Database Biometrics Archive Framework
Database Database Database
Database ETL
Marking
Data Processing
Web Services
Interaction
Framework DPA Interaction Interaction
Applications Applications Application Analytics Flow
Services Manager
Forecasting
Framework
and
Integration
Scheduling
Web Applications Service
Service
Interaction Framework DPA
Applications Applications Application
Speech
Application
Sends Service
Recording
Data
Site
Recorder
Integration Services Content
Processing
IP TDM IP Recorder
Speech
Integration
Recorder Recorder Analyzer Service Transcription
Service
IP
Screen Import Content Access
Recorder Content Storage
Recorder Manager Telephone
Video Content
Playback Central
Server Archive
Service
Customer
Feedback
Survey

Database Source Destination Description

Process
Marking Interactions Contact OLTP When a contact/interaction

Application Database begins, the recorder sends this
information to the Interactions
Application, which then inserts or
marks this in the session table in
the Contact OLTP Database.
When the interaction ends, the
closing interaction details are
sent in the same way to the
Contact OLTP Database.
If the interaction is the last one in
a contact, the contact row with
the relevant contact details is
inserted in the corresponding
contact table.
Contact Contact OLTP Contact Database This ETL (Extract, Transform,

Database ETL Database Load) process transfers closed
contacts from the Contact OLTP
Database to the Contact
Database every 15 minutes.
NOTE: Closed contacts are
contacts whose end_time field
has been updated by the marking
process with the UTC time that
the calls ended.
Data Contact Database Interaction Data This ETL (Extract, Transform,

Warehouse Warehouse Load) process transfers both new
Contact ETL and updated data from the
Contact Database to the
Interaction Data Warehouse
every 15 minutes.
Data QM Database Interaction Data This ETL (Extract, Transform,

Warehouse Warehouse Load) process transfers both new
Application ETL and updated data from the QM
Database to the Interaction Data
Warehouse every 15 minutes.

Database Source Destination Description

Process
Application QM QM This ETL (Extract, Transform,

Database ETL Database/Contact Database/Contact Load) process synchronizes
Database Database contact metadata between the
Contact Database and the QM
Database.
The evaluation process saves
contact metadata in the Contact
Database and copies it to the QM
Database.
The ETL3 process synchronizes
this data between these two
databases in the following ways:
 Contact Database to QM
Database: The ETL3 process
transfers contact metadata
from the Contact Database to
the QM Database every 15
minutes. This ensures
synchronization between the
databases in the event the
metadata was updated.
 QM Database to Contact
Database: The ETL3 process
counts the number of
evaluations per session in the
QM Database, and then
updates the same number of
evaluations in the Contact
Database accordingly.
Database Retention and Purging

The purging process runs once a week, at off-peak hours as part of the maintenance window. The
Database Purger runs daily during off-peak hours, and purges the relevant data from the QM,
Contact and Interaction Data Warehouse Databases.
By default, the database purging mechanism is disabled for these databases. Before the Site
Acceptance Test (SAT) is performed, you must set values for the database retention thresholds for
each of these databases in the EM:
 Interaction Retention Period (days): Defines the database retention threshold according to the
number of days of the interaction. Once this defined number of days has passed from the creation of
the interaction, the purging mechanism will be activated.

 Interaction Retention Quantity (Millions): Defines the database retention threshold according to
the total number of interactions the database retains (watermark). Once this total number of
interactions in this database has been exceeded, the purging mechanism will be activated.
Defining different values for the EM parameters according to the database allows setting different
purging thresholds for different databases in the system.
This enables, for example, retaining a longer history of interactions in the Interaction Data Warehouse,
but having a limited number of interactions in the Contact Database, where interactions are retained
primarily for searching purposes.
The Database Purger logic differs between subsystems—for example:
 Contact OLTP Database: Interactions are purged based on the minimum value defined between
the retention period and retention quantity parameters. An interaction will only be purged if it exists
in the Contact Database. For this reason, the retention period for the Contact OLTP Database must
be shorter than the retention period for the Contact Database.
 QM Database: Evaluations are purged based on the minimum value defined between the retention
period and retention quantity parameters. Unevaluated and/or non-flagged interactions are purged
based on the value set for Unevaluated Contacts Retention Period (days).
Interactions that are evaluated and/or flagged are not purged until the associated evaluation's
retention period has passed and the assigned flag's retention period has passed.
 Contact Database: Interactions are purged based on the minimum value defined between the
retention period and retention quantity parameters.
An interaction is not purged if one of the following conditions exist:
 The call is archived and the archive expiration date has not passed
 The interaction exists in the QM DB (the interaction is flagged and/or evaluated)
 Interaction Data Warehouse: Data is purged according to the following logic:
 Interactions that originated from the QM Database are deleted according to the Unevaluated
Contacts Retention Period (days).
 Evaluations are deleted according to the evaluations retention period and retention quantity
parameters.
 Data that originated from the Contact Database is purged based on the defined retention.
 Speech Analytics Index: The Speech Analytics Application server purges interactions out of the
index on a daily basis, when either the number of interactions or total audio hours reaches the
maximum limit. The purger removes old interactions first in whole day increments, so that the
oldest day(s) in the index are purged first.
For all databases, after an interaction is deleted, all of the information related to this interaction is
purged as well (for example: call custom data, call remarks).
For more information on the EM parameters related to database retention, see the Enterprise
Manager Configuration Guide.

Data Flows Reporting data flow
Reporting data flow

The Reporting data flow describes what happens within the system when a user selects to run a
report.
The Web browser sends the request to the Data Center. Reporting Services receives the request, and
communicates with the system databases to run stored procedures and functions to gather data.
Reporting Services then takes the report output and sends it back to the Web browser for viewing.
1 Desktop Framework From the Desktop, the Web browser sends the
Applications request to run a report to Framework Applications.
2 Framework Reporting Framework Applications sends the request to the

Applications Services (SSRS Reporting Services (SSRS services).
services) The SSRS services manage the SSRS content
(metadata, model and report definitions and report
properties).
3 Reporting Databases The SSRS services communicates with the

Services (SSRS Databases via SQL.
services) The databases run stored procedures and
functions to gather data.
4 Reporting Framework The SSRS services take the properties of the report
Services (SSRS Applications output and send them to the Framework
services) Applications.

Data Flows Reporting data flow
5 Framework Desktop The Framework Applications send the report data

Applications back to the Desktop.
A Report Viewer window is opened on the Desktop
and displays the report’s data.
Related information
WFO Report Development Kit (RDK)
WFO Reports Guide
WFO Ad Hoc Reports Guide

C h a p t e r 5
System Redundancy
The system supports redundancy mechanisms that ensure high-quality system service is
met under normal conditions, and provide solutions that continue to provide service in the
event of failure.
Topics
Introduction to System Redundancy 178

Data Center Zone High Availability Solutions 179
Site Zone High Availability Solution 187
Product High Availability Support 188
System Redundancy Introduction to System Redundancy
Introduction to System Redundancy

High availability includes providing a specific number of units beyond the required amount, to ensure
a high-quality system service is met during both peak and low-traffic periods.
In addition, secondary or standby entities are configured to provide service in the event that the
primary entities fail and need to be repaired. When the primary entities are up and running again, the
secondary entities return to standby mode, ready and available to provide service if another failure
occurs (see Data Center Zone High Availability Solutions, page 179).
The application features in the system support varying levels of high availability. Product High
Availability Support, page 188 provides a list of features, and indicates the level of high availability
supported by each feature.
 For details on redundancy configurations for recorders, see High Availability, page 256 in
Recording, page 236.

System Redundancy Data Center Zone High Availability Solutions
Data Center Zone High Availability Solutions

The high availability solutions available in the Data Center zone include:
 Data Center Redundancy, page 179: Utilizes an Active/Standby Data Center redundancy
configuration.
 Database High Availability solutions, page 179: Utilizes the Windows and SQL clustering
technologies in an active/passive configuration.
 Application Server High Availability Solution, page 184: Deploys multiple application servers, and has
a Load Balancer (LB) that is responsible for routing requests only to active servers in an active/active
configuration.
 End-to-End Encryption, page 185: Achieves high availability by deploying two Key Management
Servers (KMS) in a redundant configuration.
 Additional High Availability Solutions, page 185: Supports other common, standard high availability
techniques, including Virtual Machines, Boot from SAN, and network solutions.
Data Center Redundancy

Data Center operations can be halted by natural disasters or unexpected catastrophic events, such as
an earthquake or a fire.
Data Center redundancy refers to the deployment scheme and software procedures an enterprise
employs to ensure the continued availability of a Data Center, should this type of disaster occur.
To support Data Center redundancy, the enterprise must maintain two Data Centers:
 Active Production Data Center
 Secondary (or Standby) Data Center
Both Data Centers must be identical in their hardware and software configurations. If a disaster
occurs that renders the Active Production Data Center inoperable, administrators need to perform a
Data Center switch-over procedure to switch Data Center operations from the inoperable Data
Center to the Secondary (or Standby) Data Center. The Standby Data Center then becomes the new
Active Production Data Center.
For more information about this solution, see the Data Center Redundancy Guide.
Database High Availability solutions

The Database High Availability is achieved by Windows and SQL Cluster solution or SQL Server AlwaysOn
solution.
Related topics
Windows and SQL Cluster solution, page 180
SQL Server AlwaysOn solution, page 181

Windows and SQL Cluster solution

Windows and SQL Cluster is an active/passive pairing of Microsoft Windows and SQL clustering
technologies. Such a solution requires storing databases on a shared disk.
The system supports the deployment of its SQL databases on external servers. In this deployment,
the SQL Server resides outside of the servers, and the database platform is configured to work
remotely with SQL Server instances.
Customers can optionally use the Windows Clustering solution to support SQL database high
availability. The clustering solution includes at least two servers (clustering nodes)—one active server
with a running SQL Server instance, and one passive server (known as a standby server) with no
running SQL Server instance.
Both servers have the same virtual address. If the active server is not available, the system
automatically activates the standby server. This process is known as failover.
Since databases are stored on a shared disk visible to the two clustering nodes, the standby server
only needs to run the SQL Services. Applications can continue using the same network address after
failover to connect to the databases.

The Database High Availability failover scenario is implemented in the following way:
1. The system creates a session to the active SQL Server through a Cluster Name device.
2. The active SQL Server fails.
3. The system prompts the Application Server to initiate a new connection with the Cluster Name
device.
4. When the Application Server reconnects, the Cluster Name device directs the session to the
formerly passive SQL Server, which has now become the active SQL Server.
SQL Server AlwaysOn solution

The AlwaysOn Availability Groups feature is a high-availability and disaster-recovery solution (DR) that
provides an enterprise-level alternative to database mirroring.
This solution is only supported on SQL Servers Enterprise edition as WFO includes few databases
and requires read access on secondary replica. Basic AlwaysOn is not supported as it supports only a
single database, and does not have read access to the secondary replica.

Introduced in SQL Server 2012, AlwaysOn Availability Groups feature maximizes the availability of a
set of user databases for an enterprise. An availability group supports a failover environment for a
discrete set of user databases, known as availability databases, that fail over together (see
https://msdn.microsoft.com/en-us/library/hh510230(v=sql.110).aspx).
WFO requires that all its databases within an instance are in the same availability group.
The AlwaysOn feature can be used in the following implementations:
 Databases high availability (also known as standby databases)
 Disaster Recovery (DR) solution for WFO databases
 Off-load reporting
In databases high availability or DR implementations, the AlwaysOn feature synchronizes the

secondary SQL instance with the primary SQL instance. In addition, to monitor the readiness of the
primary and secondary SQL instances, an AlwaysOn health monitor is provided.
In off-load reporting implementation, the AlwaysOn feature synchronizes the secondary SQL instance
with the primary SQL instance. The third-party reporting tool is connected to the secondary SQL
instance only. Therefore, the primary SQL instance is not affected by the reporting tool.
WFO AlwaysOn Health Monitor

WFO communicates with the listener that manages the connection to the primary and secondary SQL
instances, and provides the failover functions.
WFO can use the following AlwaysOn features:
 Asynchronous-commit mode and synchronous-commit mode.
 Automatic failover and manual failover.
The monitor is installed on the server hosting the Framework Database server role.
The monitor consists on a time stamp written to each database on the primary SQL instances. The
time stamp is replicated as part of the database replication to the secondary SQL instance.
To validate that the databases are synchronized, the AlwaysOn monitor runs in five minutes intervals,
and compares the time stamps between the primary and secondary instances. If there is an issue
related to database failover readiness, the monitor provides a relevant alarm message on the WFO
system monitor.


Application Server High Availability Solution

The Application High Availability solution is achieved by multiple server redundancy. If the system
contains more than one application server, a Load Balancing (LB) unit routes requests to all active
application servers.
Communication with the application servers is implemented only through the LB virtual address. The
system is available as long as one application server is active.
Application server redundancy is also used for system scalability in cases where a single application
server is not sufficient to handle the application workload. High Availability solution design must
ensure that enough application servers are available at any given time.
For example, in a typical N+1 deployment, the system includes an extra application server in addition
to the number of application servers required to process the workload. When not more than one
server fails, the system continues to be available and meets the performance requirements. In
contrast to the database clustering solution, all application servers are active at all times and are
available to serve user requests.

The Application High Availability failover scenario is implemented in the following way:
1. Application Server A fails during an active session.
2. The system prompts the user to log on again.
3. When the user logs on again, the system creates a new session and the Load Balancer directs the
session to Application Server B.
End-to-End Encryption
The end-to-end encryption solution achieves high availability by deploying two Key Management
Servers (KMS) in a redundant configuration.
On the Thales KMS, high availability is configured in an active-active mode within the Thales KMS.
For more information on end-to-end encryption, see the Thales Key Manager Server Installation and
Configuration Guide.
Additional High Availability Solutions

High availability of the system can also be achieved by using the following common, standard
methods:

 Virtual Machines: Virtual machine products (such as VMWare), can provide high availability
solutions that are transparent to the system, providing high availability of all system components.
The Virtual Machines solution is similar to the Windows and SQL clustering solution (see Database
High Availability solutions, page 179), where the system has redundant servers in an active/passive
configuration. The virtual machine files are stored on a shared storage server, which is available to
both the active and passive servers.
When the active server fails, the system automatically performs the failover process, activating the
passive (or standby) server, which means the virtual machines are being executed on the standby
server instead of the primary server. This solution can be combined with other solutions as well.
For example, it can include multiple application servers accessed through a load balancer, and if
one of them fails, an additional server is activated automatically by the virtual environment.
 Boot from SAN: Booting servers from a Storage Area Network (SAN) eliminates the need for each
server to have its own internal disk. Server storage, including operating system files, can be
relocated to a shared network disks location, and the risk of local disk failure is removed. In this
scenario, the standby server is shut down and only booted up when the primary server fails.
 The Virtual Machines and Boot from SAN solutions can be applied to all Data Center
zone platforms. However, each specific deployment and implementation requires
approval and certification.
 Network Solutions: Customers can choose any network high availability solution, as long as
networking requirements, such as bandwidth and latency, are met. Network high availability is the
responsibility of the customer.

System Redundancy Site Zone High Availability Solution
Site Zone High Availability Solution

The high availability solutions available in the Site zone include:
 Speech Transcription Servers High Availability Solution, page 187: Supports the N+1 redundancy
configuration
The redundancy procedures for the recorders are described in Recording.
Archive Server High Availability Solution

(ACRA only) The Archive Server High Availability solution is achieved by an Active / Standby
redundancy configuration. When a failure occurs and the Active server is down, the Standby server is
activated so that system can continue to function normally to ensure business continuity.
Speech Transcription Servers High Availability Solution

The Speech Transcription Servers support an N+1 redundancy configuration. In this configuration, the
system includes an extra Speech Transcription Server, in addition to the number of transcription
servers required to process the workload. When one server fails, the system continues to be available
and meets the performance requirements.

System Redundancy Product High Availability Support
Product High Availability Support

Most products in the system support high availability, fully or partially. Partial support refers to the
fact that the application supports high availability, but the synchronization method, or the reporting
features, are not highly available.
The table outlines the products that have HA support and the caveats for products with partial HA
support or that are not supported. The table assumes a scenario whereby the customer has deployed
SQL Server clustering for the system databases, and for the application servers has deployed over
provisioning with a load balancer, while other HA solutions (such as virtualization) are not deployed.
Specifically, the Framework Integration Servers, Database Management Server, Customer Feedback
Survey Server, and the Speech Applications servers have caveats preventing high availability that are
detailed in the following table:
Product Area Highly Notes and Exceptions

Available?
Coaching Yes
Customer Feedback Yes

Applications
Customer Feedback No Although you can deploy multiple Survey

Survey Server Servers, in cases of failure, a manual
configuration of the switch routing is
required.
In addition, as each survey is completed on
one server only, in cases of failure, the survey
in progress is lost.
Desktop and Process Yes

Analytics (DPA)
eLearning Features Yes
Reports No Configuring multiple report servers to run in

a scale-out deployment, where all the servers
share a single report server database, is not
supported.
Use the high availability features of the SQL
Server Database Engine to maximize the
uptime of the report server databases.
Quality Monitoring Yes Inbox lottery is not supported


Available?
Scorecards Features Yes The Scorecards application supports HA, but

the synchronization process between
Scorecards and the Framework Integration
Server does not support HA.
To view updated KPI scores, you can either
manually run adapters, or wait for the next
automatic scheduling.
The ability to view the previous scores is
supported by high availability.
Speech Applications No Speech services (like indexing) run at the

project level. To support HA, duplicate
projects are required.
Uploading Speech categories to QM uses an
FIS adapter that does not support HA.
You can run the FIS adapter manually.
Speech Transcription No Although the transcription process is

configured with an N+1 redundancy
configuration, the Post-Processing
Framework (PPFW) component is not highly
available.
The PPFW’s Central Mission Manager (CMM)
is a service that runs on the Database
Management Server. The CMM creates
missions for transcriptions, and it is not
highly available. In cases of CMM failure, no
new missions are created and no speech
transcription occurs.
System Management Yes
User Management Partially The User Management application is highly

available. However, user management
updates will not be synced with the
Interactions and Analytics applications, since
it needs an FIS adapter for this
synchronization.


Available?
Forecast and Yes HA (N+1 or over provisioning)

Scheduling Server If you have multiple Forecast and Scheduling
servers, they automatically implement high
availability using a round robin algorithm.
To implement high availability, the system
includes an extra Forecast and Scheduling
server, in addition to the number of
Forecast and Scheduling servers required to
process the workload (N+1).
Workforce Yes WFM with CTI Integration uses an FIS adapter

Management that does not support HA.
You can run the FIS adapter manually.
Centralized Analytics No Identity Authentication and Fraud Detection

Servers (voice biometrics) can use centralized
analytics servers. Specific instances of
centralized analytics servers are identified
as a centralized enrollment server and a
centralized biometrics server.
 A centralized enrollment server enrolls
people against the Recorders to which it is
associated. If failure occurs, no other
server runs enrollment against the
associated Recorders. Rectify the cause of
the failure or manually reconfigure the
system to use a different analytics server
for enrollment processing.
 A centralized biometrics server runs
campaigns against the Recorders to which
it is associated. If failure occurs, no other
server runs campaigns against the
associated Recorders. Rectify the cause of
the failure or manually reconfigure the
system to use a different analytics server
for campaign processing.

C h a p t e r 6
System Management
The system supports a unified, centralized system management architecture for all
products.
Topics
System Management Overview 192

System Management Services 193
Configuration Data Flow 197
Alarms Data Flows 202
System Management System Management Overview
System Management Overview

The system supports a unified, centralized system management architecture for all products. System
management services are part of the system platform. They are implemented for all applications in a
unified way and are application-independent.
From the Portal, users can perform license management, view system, server and component version
information; view, change and manage system configurations; view system and server status and
alarm details; and perform user management tasks (see System Management Services, page 193).
In addition, these services are completely integrated with each other and the entire system, so that
the updates made using one service directly affect the other services.
For example, if a user attempts to configure more agent seats than is allowed by the system’s current
license, the system verifies the maximum number of seats and will not allow the user to make this
configuration change.
Refer to the following system management data flows:
 Configuration Data Flow, page 197: Describes how configuration changes are processed and
distributed to system servers in a unified, centralized way
 Alarms Data Flows, page 202: Describes how alarms are generated, and how alarm summaries are
retrieved from all servers and displayed in a centralized user interface

System Management System Management Services
System Management Services

The system has a unified, centralized system management architecture.
System Description
Management
Service
License License management is enforced centrally, and integrated with the

Management other system information.
The workflow for configuring an installed system includes activating
the license using the license Web portal, uploading the license, and
customizing the license, which includes adding or removing items
from the license, as required.
The system only displays the server roles that are included in the
specific license. If the license does not contain specific server roles,
the system will mask these roles to the user.

System Description
Management
Service
Version The purpose of Version Information is to provide software version

Information information on a server in the deployment installation tree.
The version information is collected on an on-demand basis,
returning the collected information in XML format for the system to
utilize.
This information consists of:
 System Versions:<Major Version>.<Minor Version> Service Pack
<SP Number> (Example: 11.1 Service Pack 1)
 Server Versions: Similar to the system version—although server
versions may vary between servers (for example in a gradual
upgrade use case). The server version also includes Service Pack
and Hot-Fix Rollup versions.
 Component Versions: Includes the latest installed hot-fix version
Configuration System configuration provides unified, Web-based, enterprise-level

configuration capabilities, enabled through a set of modules from the
Portal.
Using this single point of access, users can configure the entire
system (with a few exceptions) across products and packages. In this
way, the system configuration scheme eliminates duplicate
configurations of shared data across products and sites.
When the user makes configuration changes, the system calculates
the changes, and automatically distributes the parameters to the
relevant servers. To optimize the distribution to servers, there is a 10-
minute delay from the last change made by the user.
For a detailed data flow that describes how the system uses the
centralized system management architecture to process
configuration changes, and to ensure the changes are successfully
distributed to the relevant servers, see Configuration Data Flow,
page 197.

System Description
Management
Service
User Administrators set up and create user profiles for every employee in
Management their organization using the unified, single user management
solution for the Enterprise Suite.
The User Management application then sends the changes to one,
single central database, where all system management data is saved
for the whole enterprise. Administrators assign specific user
privileges and permissions to each profile (called roles and privileges).
When a user logs in to the Portal, they are authenticated and
authorized by the system. The user is only authorized to view and
access the applications and functionality defined within their scope
and visibility.
Status and Alarms and status displays are used to monitor the overall health of
Alarms the system. Users can view overall system status according to the
installation hierarchy, where per each of the hierarchy nodes, an
Active Alert Count is displayed.
To view detailed status and alarm information for specific servers,
the user selects the relevant server and the system retrieves the
alarms and status messages locally on the server.
For a detailed data flow that describes how alarms are generated and
processed in the system, and then how the alarm information is
retrieved and displayed to users, see Alarms Data Flows, page 202.

System Description
Management
Service
Topology Report The Topology Report provides system information that is useful
when planning system upgrades and in troubleshooting scenarios.
The Topology Report consists of five individual reports:
 Summary: Contains information about the creation of the
Topology Report, the customer, and the items licensed in the
enterprise.
 Servers: Contains detailed information about the hardware
components and operating system software installed on each
server in the enterprise.
 Storage: Contains statistics about the disk space capacity and the
free disk space on each server in the enterprise.
 Recorders: Contains information for the Recorder and
Consolidated servers in the enterprise
 Versions: Contains information about the WFO software server
version, service pack version, and specific hot fixes installed on
each server in the enterprise
For more information, see the Enterprise Manager Configuration and
Administration Guide.

System Management Configuration Data Flow
Configuration Data Flow

The system configuration data flow displays how the system processes configuration changes, and
then uses the centralized system management architecture to ensure the changes are successfully
distributed to all system servers.

1 Desktop System The user accesses and uses the System

Management Management application to make a
application configuration change:
Generally, there are two different types
of configuration settings that you can
edit:
 Server Role Settings: If you edit a
server role setting, the system
updates the server role instance
data XML file for the server role that
you edit.
 Non-Role Based Settings: If you edit
a non-role based setting, the system
updates the XML file associated with
the particular setting. Examples of
these files include
enterprisesettings.xml,
SecuritySettings.xml, Data
Source <id>.xml,
Organization<id>.xml,
EmployeeGroups.xml and more,.

2 System Framework The System Management application

Management Database stores the updated XML files in a queue
application in the Framework database.
Once every 60 seconds, the system
checks to determine if any new
changes have been placed in the
queue.
If new changes were placed in the
queue in the past 60 seconds, the
system checks again 60 seconds later
to determine if any new changes have
been placed in the queue.
The system continues in this way until
it detects no new changes have been
placed in the queue in the last 60
seconds, or until the message has been
in the queue for three minutes
(whichever comes first).
This wait period ensures that the
system waits until the user has finished
making configuration changes before it
begins processing the changes, but
ensures that no message remains in
the queue for more than three
minutes.

3 System Framework After 60 seconds elapses with no new

Management Database changes being placed in the queue, or
application a change has existed in the queue for
three minutes, the system converts all
of the queued configuration changes
into configuration messages.
The system creates one configuration
message for each server that has
configuration changes. Each
configuration message may contain
one or more XML files.
For example, if you change two server
roles on Server A, the system creates a
configuration message containing two
server role instance data XML files.
These configuration messages are
stored in the Framework Database.
4 EMA System The Enterprise Manager Agent (EMA)

Management on each server periodically contacts the
application System Management application and
makes a GET request for any new
configuration messages. EMA also
passes in the previously completed
message sequence to the System
Management application. If there are
no configuration messages, EMA sleeps
for one minute. After a minute has
passed, EMA makes another GET
request to the System Management
application for any new configuration
messages.
Note: The EMA is a Java-based Web
application that runs on a Tomcat
Server, and is installed on every system
server.

5 System EMA (on Target The System Management application

Management Servers) ensures that the server that hosts the
application EMA that made the GET request is
authenticated and is not blocked.
The System Management application
then returns the configuration
messages it has available to EMA.
6 EMA Recorder The EMA:

Manager and
UCM
 Extracts the XML files containing the
Applications configuration changes from the
configuration message
 Notifies the Recorder Manager and
the Unified Configuration and
Monitoring (UCM) applications on
the server that it has placed XML
files with configuration changes in
the relevant directories
7 EMA System The EMA notifies the System

Management Management application that the
application configuration change made in step 4 of
this process was successful.
8 Recorder Components The Recorder Manager or the UCM

Manager and application implements the
UCM configuration changes to components
Applications on the server to complete the
configuration change process. If the
Recorder Manager or UCM application
fails to implement the change, an
alarm is raised indicating the reason
the change cannot be implemented.

System Management Alarms Data Flows
Alarms Data Flows

Alarms are generated on individual servers. Information about alarms displays to users in the
Enterprise Manager, Enterprise Manager Agent (EMA), and Recorder Manager (RM) applications.
These data flows show how alarms are generated and processed by the system, and how the alarm
data is retrieved for display to users.
 Generation of Alarms on a Server, page 202 - Shows how alarms are generated on an individual
server and displayed to users in the EMA or RM application.
 Display of Alarms in the Alarm Dashboard, page 204 - Shows how servers send alarm data to the
Enterprise Manager application, and how the application displays this alarm data to users in the
Alarm Dashboard.
Generation of Alarms on a Server

Alarms are generated on individual servers. The following data flow shows how alarms are generated
on a server.
Due to a specific event that exceeds a predefined system threshold (for example, the component has
lost a network connection), the component raises an alarm and sends the alarm to the Alarm Service.
This can occur in two different implementations:
 The component sends the alarm directly to the Alarm Service (step 1a below)
 The SMA (System Monitoring Agent) pulls status messages from components, generates the alarms
and forwards them to the Alarm Service (step 1b below)

1a Component Alarm Service The component sends the alarm directly to the
Alarm Service.
1b Component Alarm Service For many system components, the SMA

through SMA (System Monitoring Agent) pulls status
messages from components, generates the
alarms and forwards them to the Alarm
Service.
NOTE: Either 1a or 1b occurs, depending on system configurations.
2 Alarm Service Alarm Service The Alarm Service processes the alarm. The
Alarm Service uses the alarm configuration to
determine whether to send an SNMP trap to
an SNMP node or send an email to a particular
person to provide notification that the alarm is
triggered.
The alarm configuration also determines
whether a delay period occurs before further
alarm processing, the priority level assigned to
the alarm, and other aspects of the alarm
processing.
The alarm configuration is done from the
System Monitoring > System Monitor > Alarm
Settings screen.
NOTE: The Alarm Service can also trigger
alarms for Performance Monitor-based alarms,
and for File Tampered alarms.
3 Alarm Service Active Alarms The Alarm Service creates an XML file for each
Directory alarm it processes and places this file in the
<install
directory
>software\contactstore\alarms\active
directory on the managed server.

4 Alarm Service System Monitor The System Monitor (in either the Enterprise
Manager Agent (EMA) or Recorder Manager
(RM) application) on the server accesses the
alarm XML files in the directory above to
display alarm information about active alarms.
This information displays in the Active Alarms
tab in the EMA or RM application.
From the System Monitor, alarms can be
filtered, sorted and acknowledged to help
support personnel analyze the problem.
5 Alarm Service Alarm History If a user acknowledges an alarm, the Alarm

Directory Service moves that alarm’s XML file into the
<install
directory
>software\contactstore\alarms\history
directory.
Once the alarm XML file is moved to this
directory, that alarm’s information displays in
the Alarm History tab in the SNMP System
Monitor.
Display of Alarms in the Alarm Dashboard

The alarms generated on individual servers display in the Alarm Dashboard of the Enterprise
Manager application (running on the application server in the data center).
The Alarm Dashboard displays the active alarms from all servers in the enterprise.
The data flow below shows how each server transmits active alarm data to the Alarm Dashboard. The
described process assumes that alarms are already generated on individual servers (as described in
Generation of Alarms on a Server, page 202

1 EMA N/A Every 30 seconds, the Enterprise Manager Agent

application on each managed server runs an
AlarmJob process.
2 EMA Active Alarms The AlarmJob process detects any new active alarm
Directory XML files that were added to the <install
directory>software\contactstore\alarms\active
directory on the managed server since the previous
running of the AlarmJob process.
3 EMA Enterprise The Enterprise Manager Agent collects the new active
Manager alarm XML files from the directory and sends them to
the Enterprise Manager over the HTTP(S) connection.
4 Enterprise Framework Enterprise Manager stores the active alarm XML files
Manager Database received from the server in the Framework Database.
5 Enterprise Framework When a user selects the System Monitoring >

Manager Database System Monitor > Alarm Dashboard in the user
interface, the Enterprise Manager connects to the
Framework database, retrieves the active alarm data
for all servers, and displays the active alarm
information in the Alarm Dashboard.

C h a p t e r 7
Networking and Security
The system supports various security requirements and networking configurations to

provide secure communication, and to support a secure and robust architecture.
Topics
Security Overview 207

Secure Sockets Layer (SSL) Protocol 208
End-to-End Encryption (ACR only) 209
End-to-End Encryption (ACRA only) 210
Pausing and Resuming Recording 211
Networking 212
Domain Trust 214
Remote Access 215
System Rights, Settings, and Services 216
Anti-Virus Support 217
Server and Service Authentication Methods 218
Application Security 223
Mobile device management 224
User Management Permissions 226
Audit Trail 227
Networking and Security Security Overview
Security Overview
The system supports the following main security requirements:
 Secure Sockets Layer (SSL) Protocol, page 208: Provides secure HTTP-based communications
 End-to-End Encryption (ACRA only), page 210: Supports encrypting of media files such as audio and
screen during recording, and can then store them in an encrypted format throughout their entire
lifecycle
 Pausing and Resuming Recording, page 211: Enables audio recording to be muted and screen
recordings to be blanked out to protect sensitive data from being exposed
 Networking, page 212: Supports Data center SSL offload where all HTTPS traffic is terminated at the
load balancer (LB) or web application firewall (WAF) and all communication behind it (inside the data
center) is over non-HTTPS communication. Also supports Mobile Networking, which is required to
support the mobile apps, and system communication through firewalls
 Domain Trust, page 214: Domain trust is needed to allow a single MSA and DMSA account in the
Data Center.
 Remote Access, page 215: Supports system personnel’s remote access to the system for providing
management and maintenance services in an efficient and timely manner
 System Rights, Settings, and Services, page 216: Supports security templates specified in the User
Rights, Windows Services, and Settings Guide .
 Anti-Virus Support, page 217: Supports anti-virus applications that scan for viruses on a periodic,
scheduled basis
 Application Security, page 223: Supports Network Address Translation (NAT) for all servers and
desktops, application user authentication methods for Web-based communication between
desktops and servers, supports built-in, secure system authentication processes that occur
automatically for service and server communication, and specific, configurable application security
methods, including defining session timeouts.
 User Management Permissions, page 226: Supports a secure user management methodology for all
users, and additional configurable filters for Interactions and Analytics users
 Audit Trail, page 227: Provides a record of the actions performed in the Recording Framework
Applications. For Interactions and Analytics applications, the Audit Trail Integrator solution enables
integration of the Audit Trail feature with any database through an Open Database Connectivity
(ODBC) connection.

Networking and Security Secure Sockets Layer (SSL) Protocol
Secure Sockets Layer (SSL) Protocol

The system supports the HTTPS (Hypertext Transfer Protocol Secure) protocol for securing HTTP-
based communications. The sites to be secured by HTTPS need to be determined at the solution
design phase. You can enable HTTPS at the site, site group, or enterprise levels in Enterprise Manager.
If HTTPS is required at least in one of the sites, it should be enabled on the Data Center level. In most
deployments, customers' security policies are dictated by geographic locations of sites or by lines of
business. Based on the nature of the business and security requirements, customers may choose to
enable HTTPS only on some sites or for the entire enterprise.
Every server deployed in the sites or enterprise where HTTPS is enabled requires a server certificate.
Each server requires a certificate file in PKCS12 format, named svr_cert_key.p12, containing the
following information:
 A server certificate and its matching private key signed for that server
 Certificate of the Certificate Authority (CA) that signs all the server certificates (could be the issuing
CA or the root CA if there is no CA chain)
This certificate file is unique for each server and is protected by an export password. The Common
Name (CN) on each certificate must match exactly the server name used by applications to access
that server.
Customers are responsible for obtaining and providing the TLS certificates. Customers can use their
own Certificate Authority (such as Microsoft Certificate Authority on the Domain Controller), a public
Certificate Authority (such as VeriSign) or a private/virtual Certificate Authority (such as OpenSSL).
Customers are required to provide these certificates per each server during site readiness and the
readiness checklist.
Related information
Security Configuration Guide

Networking and Security End-to-End Encryption (ACR only)
End-to-End Encryption (ACR only)

All files are stored on the servers, and can be played back at any time. They are archived for long-
term storage, or purged based on the customer’s retention policy and encryption settings.
End-to-end file encryption

The system encrypts these files at the time of recording, and then stores them in an encrypted format
throughout their whole life cycle. The files are securely decrypted at the workstation for playback.
Files are encrypted with a certified industry standard string algorithm (AES 256 using CTR mode). The
system provides a robust and scalable encryption methodology.
Key Manager Software

The end-to-end encryption solution uses the Thales Key Manager software for managing the
generation, rotation, archiving, and retrieval of symmetric keys required by the AES algorithm.

Networking and Security End-to-End Encryption (ACRA only)
End-to-End Encryption (ACRA only)

The system handles various types of files, including audio, transcriptions, screen, video, IM chats,
email or other media forms. The audio content is created by the recorders, containing the voice
between the customer and employee in an interaction. The screen content is created by the screen
recorder to contain a copy of the employee’s screen during an interaction.
All files are stored on the servers, and can be played back at any time. They are archived for long-
term storage, or purged based on the customer’s retention policy and encryption settings.
End-to-end file encryption

The system encrypts these files at the time of recording, and then stores them in an encrypted format
throughout their whole life cycle. The files are securely decrypted at the workstation for playback.
Files are encrypted with a certified industry standard string algorithm (AES 256 using CTR mode). The
system provides a robust and scalable encryption methodology.
Key Manager Software

The end-to-end encryption solution uses the Thales Key Manager software for managing the
generation, rotation, archiving, and retrieval of symmetric keys required by the AES algorithm.
Microsoft CryptoAPI
DPA data-at-rest uses the Microsoft CryptoAPI encryption method to encrypt the local DPA data
before it is stored in standard MSMQ queues. DPA encryption is not KMS based.
Screen content in-transit encryption

Encrypting captured screen data-in-transit is accomplished using a standard HTTPS/TLS encryption on
the socket communication between components.
Secure RIS to remote recorder communication

When HTTPS communication is configured, communication between the remote recorder and the
Recorder Integration Service (RIS) is secured through the Recorder Control Gateway.
Related information
Desktop Applications Deployment Reference and Installation Guide

Networking and Security Pausing and Resuming Recording
Pausing and Resuming Recording

During recording, there are times when, for security reasons, it is desirable not to capture portions of
a conversation, or portions of an agent’s screen. For example, capturing a customer password or
social security number compromises the security of that information. This feature is known as
masking.
To provide masking capability, the Integration Server and recording platform have been enhanced to
enable the voice recording to be muted without breaking the call. Similarly, portions of screen
recordings can be blanked out.
To accomplish this, the Recorder replaces, at the point of capture, the audio and screen data with
alternate information so that the identified portions are not recorded and are not present for
playback.
A beeping tone is used to indicate that an audio recording has been paused. In this way, a user is not
presented with a sudden silence during playback, which could raise questions. Similarly, a blank
screen is used to indicate that a screen recording has been paused.
Files remain whole and are not split during this process. The end result is that call and screen data
contain a portion of the call that does not have the sensitive data. Instead, beep tones or blank
screens replace sensitive data.
Related information

Networking and Security Networking
Networking
Refer to the following networking security requirements:
 Data Center SSL offload, page 212
 Mobile Networking, page 212
 Firewalls, page 213
Data Center SSL offload

Data center SSL offload is a communication method where all HTTPS traffic is terminated at the load
balancer (LB) or web application firewall (WAF) and all communication behind it (inside the data center)
is over non-HTTPS communication.
When Data Center SSL offload is enabled, the system supports the use of an external and internal load
balancer addresses:
 The external address is used for HTTPS communication between desktops or site servers to the load
balancer and creates a single point of access to the data center.
 The internal address is used for HTTP communication between the data center servers and the load
balancer.
Separating the addresses is optional and the same address may be used for both internal and external
communication. However, since communication to the external address is done over HTTPS, and
communication to the internal address is done over HTTP, it is recommended to use separate
addresses in different network segments, or to carefully restrict the access to the non-HTTPS port to
data center servers only.
Mobile Networking
The Mobile Gateway provides mobile-specific back-end services such as native mobile push
notifications and content optimization for mobile devices.
The Mobile Gateway enables native push notifications by communicating with Google Firebase Cloud
Messaging (FCM) and Apple Push Notification (APN) services.
Deploying more than two Mobile Gateways provides support for high availability.
Exposing Services to the Mobile Applications on the Internet

To allow access from mobile devices that are not part of the internal LAN, the Mobile Gateway and
system services must be exposed to the Internet. Unlike internal desktop clients, which connect to
the system over the internal LAN, external mobile devices connect via a virtual IP (VIP), which binds
the connection to the internal LAN.

Networking and Security Networking
Segmented Topology
Mobile Networking Preparation

 Access to Google (FCM) and Apple (APNS) services
To enable push notifications in the Mobile Apps, the Mobile Gateway must have access to the
FCM and APNS services as a web service call.
Outbound communication on port 443 must be opened from the Mobile Gateway Server to the
FCM (fcm.googleapis.com:443) and APNS (api.push.apple.com:443).
 Mobile solution virtual IP (VIP)
The VIP used by the mobile solution must be accessible from the Internet, typically at the level of
the Load Balancer. It is highly recommended to use a friendly domain name for the VIP, as in the
base URL, instead of an IP address. For example, <mobile.company.com>.
 Firewall ports configuration
To enable Mobile Gateway communication through firewalls, open the ports specified in the
Firewall Ports Configuration Guide.
Related information
Firewall Ports Configuration Guide
Firewalls
To enable system communication through firewalls, adhere to the guidelines specified in Firewall
Ports Configuration Guide.
Ports related to specific recorder integrations are found in the relevant Recorder integration guide.

Networking and Security Domain Trust
Domain Trust
The system supports Domain and Workgroup Integration. In the domain environment the system
servers are deployed in a Data center. In a non-domain environment, the system servers at each site
are deployed in a Windows workgroup.
Domain Integration
Domain trust is required in the Data Center to allow a single MSA and DMSA account. It is also used
to allow system services to authenticate against the SQL Server using a Windows integrated
authentication.
Domain trust is not required between the Data Center and the sites or between workstations and
system servers.
Workgroup Integration
In a workgroup environment, the service user accounts, policies and settings are maintained
individually. There is no formal membership, policy enforcement or authentication process formed
by the workgroup.
Related information
Technologies, Security, & Network Deployment Reference Guide

Networking and Security Remote Access
Remote Access
Effective support in accordance with the company’s maintenance contracts requires that company
personnel have access to the system for remote support functions.
Remote Administration mode of Terminal Services is used for management and maintenance
purposes.
Remote access to the system is essential for providing service to the system. Using the remote
connection, Customer Services can manage service requests in an efficient and timely manner.
Furthermore, during the deployment phase, remote access can be used to verify site readiness and
to efficiently configure distributed systems that have components distributed between several
geographical locations.
Related information
Technologies, Security, Encryption and Network Integration Deployment Reference Guide

Networking and Security System Rights, Settings, and Services
System Rights, Settings, and Services

The system requires implementation of Windows security settings as specified in the User Rights,
Windows Services, and Settings Guide. It is the customer’s responsibility to set the settings defined in
this guide.
Related information
User Rights, Windows Services, and Settings Guide

Networking and Security Anti-Virus Support
Anti-Virus Support
The system supports antivirus applications that scan for viruses on a periodic, scheduled basis.
The system provides file extensions, and files and folders that should not be scanned by antivirus
applications. To prevent scanning these files, the customer needs to set up the specific exclusions in
the antivirus application being used. The exclusion of system processes from scans is also supported.
Related information
Anti-virus Exclusion List (Technologies, Security, Encryption and Network Integration Deployment
Reference Guide)

Networking and Security Server and Service Authentication Methods
Server and Service Authentication Methods

The system supports built-in system authentication processes that occur automatically,
includingWindows and Token authentication. Windows Authentication is used when accessing SQL
Servers within the Data Center and Token authentication relies on a signed token that is sent to the
server on a per request basis.
Token authentication methods

Token authentication methods are built-in system processes that rely on sending a signed token to
the server on each request. This means that no session memory is required. In addition, tokens can
be encrypted.
Token authentication method types

There are four types of token authentication methods that operate in the system.
 Foundation Token: A mix of token-based and cookie-based authentication process
 Service Web Token (SWT): A service to service token
 Security Passphrase Token: A token authentication process
 DPA Public-private Token: A token and header authentication process used by DPA
Foundation Token
Authentication type
When is the token used? Application user authentication (UI to Service)

Service to Service
Session 1. Credentials or Kerberos ticket (SSO) are moved in primary

request.
2. Then Token is created by the server and returned to a
client.
3. The client sends the token to the server again, and then
the server creates SessionID.
4. The SessionID is moved between client and server each
secondary request in a cookie.
Token in transfer Response

POST
Cookie
Keys used for token The server creates the token and passes it back to the client.
creation Token is a random string with a length of 10 characters.

Authentication type
Secret phrase key N/A

management
Symmetric key Not persistent

In Memory
The token is cached with Coherence cache.
Token Length 10 chars (80 bits)
Algorithm used for token Random string

creation
What is encrypted in the Token in cache contains expiration time, user name, and user
token? locale.
Secret phrase storage N/A
Additional security
Service Web Token
Authentication type
When is the token used? Service to Service
Session No
Token is generated by the client and validated by the server for
each request
Token in transfer All HTTP Methods
Keys used for token Symmetric

creation Client and server use the same secret phrase.
Secret phrase key Multiple keys are used in the Enterprise. Typically one per
management customer or tenant.
The keys are randomly generated by the system and
distributed in the Security Settings XML file in an encrypted
format. Keys generated on demand or as needed, so there is
no default key for the system. The first key will be generated
during first configuration distribution.

Authentication type
Symmetric key Persistent (always encrypted)

 In file
 In database
In Memory
Token Length 150+ Bytes in Authorization HTTP Header
Algorithm used for token It uses HMAC-SHA256 algorithm to securely sign a randomly
creation generated salt value plus data from the request. Basically it is a
Hash-based Message Authentication Code(HMAC) signature
that uses a Secure Hash Algorithm 2 with a 256-bit key (SHA-
256) as its hashing function.
What is encrypted in the The token contains a signature of data rather than encrypted
token? data. The token is put into the Authorization header and
includes:
 The name of the algorithm used to create the signature
 The Salt value used in the signature
 The time that the token was issued
 The key id of the secret key used to sign the data
 The signature of the data as described below.
The following data is signed by the HMAC algorithm to create a
signature:
 Salt value which is 32 bytes of randomly generated data
 URI of the request
 HTTP method used in the request
 Any Verint specific request headers (starts with ‘Verint-‘)
Secret phrase storage XML encrypted with a pass-phrase
Additional security
Security Passphrase token
Authentication type
Session No
Token validated in each request
Token in transfer GET HEAD

Authentication type
Keys used for token  Symmetric

creation  Client and server use the same secret phrase.
Secret phrase key  Same keys for enterprise.

management  The Passphrase can be configured in Enterprise Manager
Enterprise Security Settings..
Symmetric key  Not persistent

 In Memory
 Regenerated each request
Token Length Large and variable depending on the data it contains
Algorithm used for token Hashing passphrase with salt. Token created with AES256,
creation 32bit IV. If no passphrase is set in EM (system default), the key
is fixed, and DES is used.
What is encrypted in the  Timestamp (originating server)

token?  Session ID for CS URLs
 IP address (optional, originating server)
Secret phrase storage  Persistent

 In file.
 Encrypted
Additional security  When using a passphrase AES is used and salt is added to
GET.
 For Content Server communication, an additional hash od
session data is added to GET.
DPA Public-private Token
Authentication type
Session No
Token validated in each request
Token in transfer POST
Keys used for token Asymmetric

creation The client uses a public key; the server uses a private key.

Authentication type
Secret phrase key Same keys for enterprise.

management Keys can be replaced manually.
Symmetric key Not persistent

In Memory
Regenerated each request
Token Length Random

Large number
Algorithm used for token RSA

creation
What is encrypted in the Timestamp

token?
Secret phrase storage Persistent

In file.
Encrypted
Additional security

Networking and Security Application Security
Application Security
The system supports several methods to secure applications and grant visibility to authenticated
users.
Application User authentication methods

The system uses Web-based communication between desktops and servers. When accessing the
platform's Web-based applications, the system authenticates the application users that are defined in
the system according to the desired authentication method. Once authenticated, the application
authorizes the user according to their specific rights and permissions, as defined in the system.
Session Timeout
Administrators can configure a timeout period for sessions. When a user’s browser is open and there
is no detectable user activity, after the timeout period is reached, the session ends.
Web Application Firewall (WAF)

The Secure Gateway provides protection against malicious attacks, such as Cross-site scripting (XSS)
and Cross-site request forgery (CSRF).
The Secure Gateway:
 Examines HTTP requests to WFO web servers
 Inspects GET, POST, and other VERBS requests
 Applies rules to help filter out illegitimate traffic from legitimate website visitors
To customize the level of application security, you can apply filtering rules.
Cross-site scripting (XSS)

Cross-site scripting (XSS) is a Web application attack used to gain access to private information by
delivering malicious code to end users by means of trusted Web sites.
The Secure Gateway:
 Sanitizes and validates user input in the application
 Screens for known attack patterns
 Allows only known data strings and formats to be sent to the application
Cross-site request forgery (CSRF)

Cross-site request forgery (CSRF) is an attack method that exploits a pre-existing relationship of trust
and forces a user to run unwanted actions on a web application in which the user is authenticated.
When the CSRF Protection feature is enabled, the system inserts custom JavaScript into the response
pages of a protected web application. The Secure Gateway uses a defense mechanism known as a
double submit cookie. It sends a random value embedded in a cookie and a request parameter. The
server verifies if the cookie value matches the request value.
Related information

Networking and Security Mobile device management
Mobile device management

Mobile devices are managed using Enterprise Mobility Management (EMM). EMM refers to the
collection of systems and processes connecting mobile devices to the enterprise infrastructure and
workflows.
The core elements of EMM suites are:
 Mobile Device Management (MDM): Tools used for mobile device administration and policy
enforcement at the device level, such as rooted device/jailbreak detection, OS configuration
management, device tracking, remote wiping of devices, and network access (VPN, WiFi).
 Mobile Application Management (MAM): Administration at the individual application level, such
as application distribution to mobile devices, version management, performance monitoring,
application wrapping, etc.
 Mobile Identity Management (MIM): Tools providing Identity and Access Management functions
for mobile devices, such as user authentication, device certificates, and behavioral and contextual
access (for example, according to how the device is used and from where).
The use of EMM tools enhances overall security and facilitates administration tasks. EMM tools do not
require any specific configuration in the Mobile Gateway, and can co-exist with and complete the
Mobile Gateway.
Examples of how EMM tools can be useful:
 Route all mobile network access through an EMM gateway that is placed in front of the Load
Balancer. This solution allows for monitoring and fine-tuning access decisions before accessing the
internal network. For example, access can be restricted according to device properties, specific
apps, network location, or specific users.
 Multi-Factor Authentication (MFA) is achieved by enforcing strong authentication using MDM, MAM,
or MIM.
 Enforce device password protection to encrypt all device content when locked.
 If a private Certificate Authority is used, use MDM to distribute root CA certificates to mobile
devices.
 Remote wiping of devices using MDM, or of application data using MAM (for data saved on mobile
devices).

Networking and Security Mobile device management
EMM gateway controlling access of mobile devices to load balancer in DMZ

Networking and Security User Management Permissions
User Management Permissions

The system supports a secure user management methodology for all users.
For users defined with permissions to use the Interactions and Analytics applications, administrators
can define specific filters related to the types of calls they can view.
For details on the generic user management methodology, see Generic User Permissions, page 226.
Generic User Permissions

The system supports a secure user management methodology, which provides security for user
access when defining all users and system entities:
 User Setup: Administrators set up and create user profiles for every employee in their organization
using the User Management application from the Portal, and the profiles are saved in one, single
central database.
 System Entities: Specific entities in the system can be configured to be associated with specific
roles and organizational groups. For example, specific reports can be applied to specific areas in the
system or specific user roles.
The specified definitions and permissions of users and system entities provides a two-pronged
approach to secure user access, which allows administrators to manage users in a unified, secure
way.
For setting up users, administrators assign specific user roles and privileges to each profile, where:
 Roles are assigned to users to define their access permissions to applications (Supervisor or Agent
role, for example)
 Privileges are associated with roles to define the features of the application a user is able to view,
and the functionality within the application the user can access.
When a user logs in to the Portal, they are authenticated and authorized by the system. The user is
only authorized to view and access the applications and functionality defined within their scope and
visibility (according to their defined role and privileges).
In addition, administrators can set up different hierarchies that allow them to manage users:
the company.
administrator.
organization or their association with a specific defined group.
Related information
Roles and privileges and organization and group hierarchies (User Management Guide)

Networking and Security Audit Trail
Audit Trail
Audit Trail provides a record of the actions performed in the applications. It allows contact centers to
track who logged into the system, performed a search, played back contacts, evaluate or flag
contacts, assign and complete training materials, and delete items from the application.
 For the Framework Application, audit actions are logged in the BPMAIN database. The audit trail
viewer allows an administrator to view these audits.
 For Interactions and Analytics applications, the Audit Trail Integrator solution enables integration of
the Audit Trail feature with any database (Microsoft SQL Server, Sybase, Oracle and more) through
an Open Database Connectivity (ODBC) connection. The Audit Trail Integrator provides long-term
storage of Audit Trail history, support for data collection across sites, and the ability to generate
reports based on this data. Interaction and Analytics actions are logged in the log files in the
Application Server.
The Audit Trail Integrator solution enables each Audit Trail customer to use a predefined
destination for the Audit Trail database, which can be hosted on the server where the Reporting
Services server role is hosted, instead of on a dedicated server.
Related information
Audit Trail Integration solution (Workforce Optimization SDK Programmer’s Guide)
Configuring the audit viewer Workforce Optimization System Administration Guide

C h a p t e r 8
Time Management
The system supports the configuration and management of multiple time zone settings. This
allows viewing a specific time setting on reports and charts, and allows users to generate
queries according to a specific time.
Topics
Time Management Overview 229

System Time, User Time and Local Time 230
Daylight Savings Time (DST) Handling 234
System Monitor, Audit Trail and Recording Rules Time Settings 235
Time Management Time Management Overview
Time Management Overview

The system supports the configuration and management of multiple time zone settings. This allows
viewing a specific time setting on reports and charts, and allows users to generate queries according
to a specific time.
Refer to the following topics related to time management:
 System Time, User Time and Local Time, page 230: Describes these different concepts of time in the
system, how/if these time settings can be configured, and provides an example of the way the
different time settings are used in the system
 Daylight Savings Time (DST) Handling, page 234: Describes how Daylight Savings Time (DST) is
handled in the system
 System Monitor, Audit Trail and Recording Rules Time Settings, page 235: Provides details on how
time zone settings are displayed for System Monitor, Audit Trail and Recording Rules

Time Management System Time, User Time and Local Time
System Time, User Time and Local Time

For most system applications, the time of a specific system operation is stored in the system as
system time (usually set to UTC). It is displayed to the user when the user views the operations'
details according to the user's time zone.
However, for the Interactions application, some operations are stored according to system or user
time, and some are stored according to local time:
 System Time/User Time: For search and playback operations, users want to be able to see time
stamps automatically adjusted according to their own time zone and daylight saving time shifts,
regardless of where the operation took place. Therefore, this time axis is referred to as system time
or user time.
The time of the operation is stored in the system as system time (usually set to UTC), and displayed
to the user when the user views the operations’ details according to the user’s time zone.
For example, if a contact was recorded in Los Angeles at 7:00 AM Pacific Time (PST), a user in Los
Angeles can locate the call by indicating 7:00 AM as the start time, and a user in New York (EST) can
search for the call by indicating 10:00 AM as the start time.
 Local Time: Cross-enterprise reporting and speech analytics are based on when an operation took
place according to the local time—the time on the clock in the location where the operation
occurred.
This time is never shifted for users when displayed in business applications. It is important to know
when an operation took place relative to the people who took part in that operation. This provides
key insight to business managers, as it allows them to compare activity across the globe relative to
the local time of day, and not relative to shifted time stamps.
For example, if an agent in Los Angeles took a call at 7:00 AM, it is important that this time is noted
in the contact’s record so that an enterprise manager in New York can run reports on LA contact
center activity in the morning hours (for example, between 7:00 and 8:00 AM), without losing this
call due to time zone adjustments.
In addition, the manager can also run reports comparing the LA contact center activity between
7:00 and 8:00 AM, with that of the New York contact center between 7:00 and 8:00 AM, to compare
the calling patterns of these early hours between the two sites.

The way the system stores the time setting and how it is viewed by users depends on the type of
system operation or activity that occurred:
Time Settings—Storage and Display
User Interface
Storage
Search & Playback Time Search & Playback

Shift
System Time User Time
Reporting & Analytics Reporting & Analytics
Local Time Local Time
Type of Operation Storage User Interface
Search and Playback Operations System Time User Time
Reporting and Analytics Local Time Local Time
 You can also view Search & Playback operations by Local Time in the system.
Time Configurations
System Time is only configured in the EM upon system installation.
Local Time is configured to one of the following:
 Organization: Time zone is based on the organization of the user or agent who performed the
operation. This is useful in scenarios where agents are working in different regions, allowing you to
unify time zone tagging across multiple time zones.
 DataSource: Time zone is based on the time zone specified for the phone data source.
Related information
Configuring the Local Time (Recorder Configuration and Administration Guide)

Time Zone Settings Use Case

The example described in this topic illustrates how the different time zone settings are used in the
system:
An enterprise operates several contact centers across the United States and Europe, and has
headquarters in New York and Paris. The system was deployed with the System Time set to UTC. The
largest contact center is located in Los Angeles.
The following table shows the contact center locations and time settings:
Los Angeles (UTC-8) New York (UTC-5) London (UTC) Paris (UTC+1)
04:00 AM 07:00 AM 12:00 PM 1:00 PM (13:00)
The following employees work in the respective contact centers:

 Agent Lenny Lester works for the Billing group in the Los Angeles contact center
 User Nora Nelson is a quality specialist in the New York offices
 User Pierre Praff is a global marketing director in the Paris offices
Agent Lenny Lester starts his shift at 9:00 AM and finishes at 4:00 PM. Lenny’s first call of the day
begins at 9:05 AM and is recorded for 10 minutes.
The system stores the information in his contact details according to the system time, which is set
according to UTC: 09:05+8=17:05 (5:05 PM):
Contact Database Record
Start Time 17:05
End Time 17:15
The next day, Nora Nelson in the New York headquarters and Pierre Praff in the Paris office both
perform a search for a random sample of calls conducted by the Los Angeles billing group the
previous day. One of the calls returned in the results is Lenny’s call.
When viewing the contact details, they will see the following:
Nora Nelson, New York
Start Time 12:05
End Time 12:15
Local Start Time 9:05
Local End Time 9:15

Pierre Praff, Paris
Start Time 18:05
End Time 18:15
Local End Time 09:15
Note the following:

 System Time stored in the database has been shifted for Nora’s benefit to reflect her New York
time zone, translating 17:05 (UTC) to 12:05 (User Time) and 17:15 (UTC) to 12:15 (User Time).
 System Time stored in the database has been shifted for Pierre’s benefit to reflect his Paris time
zone, translating 17:05 (UTC) to 18:05 (User Time) and 17:15 (UTC) to 18:15 (User Time).
 Both Nora and Pierre can see that according to the Local Time (Lenny’s time, the time of the agent
who took the call), the call took place at 09:05.
 The fact that Nora can see the local time in the contact’s record may aid her in the evaluation
process, as it allows her to appreciate that this was Lenny’s first call of the day.
When Lenny searches for his own calls, he will see his contact’s details as follows:
Lenny Lester, Los Angeles
Local End Time 09:15

Time Management Daylight Savings Time (DST) Handling
Daylight Savings Time (DST) Handling

As part of the unified Time Zone management implementation, historical DSTs per time zone are
based on the Olson Database, and the replica is kept in the ADAM/Recording Framework databases.
In the event of a DST change (may happen twice a year in countries like Brazil or Israel), specific
patches need to be installed.
Related information
Maintenance Guide

Time Management System Monitor, Audit Trail and Recording Rules Time Settings
System Monitor, Audit Trail and Recording Rules

Time Settings
Note the following about time settings in System Monitor, Audit Trail and for Recording Rules:
 System Monitor: Events are reported in UTC time. Therefore, all system monitor events are viewed
according to the user’s viewing time.
 Audit Trail: Messages based on the machine’s clock, indicating in parenthesis the time shift from
UTC. For example: 02/03/06 10:52:01.393 (+03). Daylight Savings Time changes will not be reflected
in the log files.
 Recording Rules: Time zones need to be adjusted, if required.
Rules are evaluated according to the time zone of the Integration Service Server time or UTC (To
configure according to Recorder Integration Service, from the Portal, select System
Management>Recording Rules, and select the relevant Recorder Integration Service)
The rule editors for Recorders do not include any visual presentation of the time zone. During the
upgrade, the rules should be manually adjusted to fit this change.

C h a p t e r 9
Recording
The Recorder can record both voice and screen data in IP, TDM, and mixed telephony
environments. In IP environments, the Recorder can also record video from video-enabled
telephones.
Topics
Overview 237
Recording Types 243
Topologies 252
IP Recorder Filtering 260
Recording Overview
Overview
The Recorder can record both voice and screen data in your call center, in IP, TDM, and mixed
telephony environments. For IP environments, the Recorder can also record video data. The Recorder
also supports dialer integrations and recording in trading environments. The Recorder Integration
Service handles CTI events from third-party switches and other data sources, controls recording,
manages recording rules, and is integral to the real time monitor process in providing information to
the Data Center, as illustrated at a high level in the diagram below.

Recording Overview
Recording Functions
The primary functions of the Recorder are to record, archive, and replay voice, video, screen, and
dialer-based interactions. Recorder features include:
 Full-time and selective, rules-driven recording
 Close integration with third-party CTI devices
 Archiving support
 Call replay audio delivered to the PC or through a telephone
 High-availability (redundancy)
 Web-based administration
The recording solution consists of a set of logical servers that can be deployed on a single machine or
on multiple machines in a large enterprise environment. These servers can also be deployed in the
form of clusters in order to scale with the size of the customer’s systems.
The Recorder supports both TDM and IP recording, including trunk-side recording (TDM) or gateway
recording (IP), and station-side recording (TDM) or extension-side recording (IP) recording. You can
configure each of these types of recording by using the Enterprise Manager to set up extension
groups or pools (called member groups), each with a data source that defines where the recorded call
is coming from, and then setting the recording mode.
Contacts and Interactions

A contact is a customer’s full communication experience with the contact center. Events such as a
transfer between switches or through queues can turn a single customer call into multiple contacts.
Contacts are stitched together in most cases—see Playback Interaction Data Flow: Retrieve
Interaction using ActiveX, page 87.
An interaction (sometimes referred to as a session or segment) is a single communication session
between a specific customer and a single employee or system (in the case of IVR). If the customer
speaks to one employee only during the call, the contact will contain one interaction. However, if a
customer is transferred from one employee to another during the contact, the contact will contain
two interactions.
A contact may consist of any number of interactions, each comprised of any number of different
media types. In addition, an interaction may also now exist in multiple contacts. This provides better
tracking of calls in complex scenarios across different device types.
Interactions no longer need to be associated with a phone call. For example, a session may now
consist of screen-only recordings in a back-office environment. This allows for sessions that do not
contain any media, but rather contain metadata only. Some examples of this would include
compliance call marking for abandoned calls or other back-office operations such as DPA monitoring
and tracking. Interactions are also associated with employees, even if the recording is done at the
trunk level.
A recording segment is an entity that correlates to a single INUM. In call centers it is common to
transfer calls, conduct conference calls or put a customer on hold. If a customer is transferred from
one agent to another, and then transferred again to a supervisor, the contact will consist of three
recorded segments. Inside a segment the recording system may stop and restart recordings on hold,

Recording Overview
creating two recording segments which will be combined into one segment. (These are known as
stitched recording segments or recording INUM.)
There are two ways in which segments are captured:
 The first creates agent recordings. The system will record an employee or agent when they are active,
and stop when they become inactive. (For trunks, because there can be more than one agent on a
call, the system tracks a "primary agent" per trunk and creates segments based on that.)
 The second is back office recording, which creates segments based on CTI calls. If one agent is on two
calls at the same time (for example, a customer call and a consultation call), the system creates two
segments.
 Back office recording segments depend on the calls created by the specific switch with which
the Recorder is integrated. This document describes the most common scenarios, but some
switches or call flows may segment differently.
Call Data and CTI Tagging

Call data captured by the Recorder includes associated and non-associated call data. Associated call
data represents parameters of the call such as the start time, stop time and call length. In addition to
the call data values, other data fields can be appended that contain any relevant data that is
associated with the call. This data can be from switch CTI ports, and can be information such as an
agent extension or wrap-up codes or data from back office systems, such as the value of sale.
Associated call data includes the following, which 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
Non-associated call data allows the Integration Service to place records into the database when they
cannot be directly associated with a voice call (either because the call has 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.
Once you determine which fields you need to use in your system, you can add them as custom
attributes, then map these custom attributes to an adapter. You can then use these attributes for
tagging and to build recording rules, where the attributes become criteria upon which the decision to
record or not is based.

Recording Overview
Attributes
Attributes are used to record and retrieve calls based on real criteria associated with employees (such
as an Employee ID), contacts (such as number of holds), devices (including extensions) and CTI events
(such as a call ID). You can use them to establish the conditions that trigger recordings, through
recording rules, and to tag calls, by mapping them to custom data.
There are both standard attributes, which are predefined and have specific values or behaviors, and
custom attributes, which are created to serve specific business needs using data present in a particular
environment.
Values for standard attributes are pulled from different places. For example, Employee attributes are
obtained from the Employee configuration, Contact attributes are collected from information in the
contacts, and CTI attributes are received or derived from CTI.
In certain cases attributes won’t have values. This can be because configuration is incomplete, there
are third-party limitations, or the attributes are simply not applicable to a given environment. If the
standard attributes don’t contain the data you need, you can create new ones.
Custom Data
The Recorder makes use of Custom Data (CD) and Conditional Custom Data (CCD) to tag data and
make it usable for things like reporting and analytics.
Desktop Process Analytics

If you integrate Desktop and Process Analytics (DPA) with the Recorder, you may trigger recording
events on workstations monitored by DPA clients, and tag recordings with DPA-collected custom data
and attributes.
Recording Decisions
The Recorder Integration Service uses the following mechanisms to determine whether a session
should be recorded or not:
 Extension Recording Mode
 Recorder Fallback Type
 Recording Rules
AIM and External API Commands (for example from eQuality Connect or Cisco Phone Services) can
also be factors in whether or not a given session is recorded.
 Any record or block commands take precedence over all other decisions.
Extension Recording Mode

There are five extension recording modes. These modes are the basis for what the system records
and they have a large impact on how business rules, external API and AIM commands behave.

Recording Overview
 Record—Any extension configured with Record as the Recording mode will always have every
session it is in recorded, for the entirety of the session (assuming that the recording system is
configured and working correctly). The only thing that can change this behavior is a block business
rule, AIM command or external API command.
 Do Not Record—Any extensions configured with this will not be recorded regardless of any AIM,
recording rule, or external commands.
 Application Controlled—All sessions with extensions with this setting will be recorded from the
beginning until the end (assuming there are enough resources in the recording system). At the end
of the session it will be discarded if no business rules, AIM commands or external commands are
received to record or keep the session. It is important to remember that this requires the session to
be recorded since the beginning of the session, so even if it is not kept the system will record all
sessions for this extension.
 Start on Trigger—All sessions with extensions with this setting will not be recorded by default. Only
at the time of the first trigger (a business rule, AIM command or external command) will recording
of the session begin, continuing until the end of the session. No resources are used until the
recording decision is made. On the flip side, the beginning of the session will not be recorded.
 Recording Resource—Used only for soft phones, in conjunction with the Service Observe or Single
Step Conferencing Recorder Control Type.
 Block commands take precedence over all other decisions.
 There is a fifth extension recording mode ‘Recording Resource’ that is used only in Avaya
DMCC for the soft phones configured in the system. Since these are not actually recorded but
used for recording, they are ignored for this discussion.
Recorder Fallback Type

The Recorder Fallback Type defines what will happen in the event that CTI is disconnected: whether
recording will continue (and what type), and which segments will be retained. There are three sets of
behaviors that you can specify must occur in the event of CTI disconnection:
 Never (Application)—If CTI is disconnected, no audio or screen recording will occur. If CTI is up, CTI
segments will be retained.
 On CTI Disconnection (Performance)—If CTI is disconnected, audio recording continues (VOX-
detected segments will be retained), but screen recording does not. If CTI is up, only CTI segments
are retained, VOX segments (not associated to CTI calls) will be discarded. You can set a Rollback
Period in the phone data source to specify the length of time preceding a disconnection for which
recordings will be held.
 Always (Liability)—If CTI is disconnected, audio recording continues (VOX-detected segments will be
retained), but screen recording does not. If CTI is up, both CTI- and VOX- detected segments will be
retained.

Recording Overview
Recording Rules
Recording rules are a core piece of the Recorder Integration Service, used for selective recording,
recording screens, and tagging sessions. Recording rules extend the functionality of your recording
system by allowing you to implement recording and tagging on the basis of a business logic that
reflects the goals of your enterprise. Each rule consists of a set of conditions (such as "extension
starts with") and actions (record, block, and so on). The rules trigger recording when contacts that
take place between customer interaction center employees and customers meet the specified
criteria.
 You can also use Tag Only to trigger After Call Work, or add the recording rule name to the
standard attribute Fired Business Rules, without affecting the recording decision of a rule. All
of these actions have a percentage setting that applies to them. That is, the action specified
by the recording rule will only be taken for the specified percentage of calls that meet the
rule’s conditions and occur during the set schedule. This is primarily used for selective
recording.
Related information

Recording Recording Types
Recording Types
Recording falls under two broad categories: IP and TDM, which each have a number of permutations.
The following sections describe some of the types of recording available for IP and TDM Recorders:
 IP Recording, page 243
 TDM Recording, page 247
You can use Service Observe (which allows agent extension monitoring) and Single Step Conferencing
(used to connect an in-progress call to a device) in both IP and TDM Recording with certain switches.
Refer to the Integration Guide for your environment for more information.
IP Recording
Support for IP Recording includes VoIP Gateway Recording (including SIPREC Recording, SIP Trunk
Interception, and SIP Session Replication), Extension-side recording, Duplicate Media Stream (DMS),
Real-time Transport Protocol (RTP) Detection, SIP Trunk Recording, and RTP Proxy Recording. The
style of recording dictates which calls are recorded, and which segment of any call is recorded.
In addition, IP Recording supports video recording for video-enabled telephones in Cisco SCCP and
SIP recording environments. IP Recording refers to either voice or video recorded using an
IP Recorder.
Gateway Recording
Gateway Recording is accomplished by mirroring (that is, duplicating data streams) the Gateway and
the call processing system server/cluster. This type of recording is also referred to as VoIP
Interception. 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 mirrored. Care should be taken to ensure that port mirroring for the
conference bridge resource does not take the IP Recorder (audio or video) over its configured
capacity for maximum packets per second.
The following diagram is an example of a Gateway recording solution, since the voice Gateway and
the call processing system are mirrored.

Mirror Port
PSTN
(Signaling to
the Recorder )
Switch
Internet
IP Recorder
Agent
IP
Phones
Mirror Port Media Gateway /
(Audio to the
Edge Device
Recorder )
The VoIP media gateway converts voice/video to a media streaming protocol, usually Real-time
Transport Protocol (RTP). When a conference is established, the RTP traffic flows between the
Gateway and the conference bridge. This means that the IP Recorder cannot associate it with any
device. Port mirroring the Gateway enables Recorder awareness of the RTP streams between the IP
device and the Gateway, allowing it to record this traffic.
Skinny Call Control Protocol (SCCP) traffic only flows between the IP device and the switch. The
Gateway does not use the SCCP protocol, and therefore mirroring only 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 mirror ports for the switch server/cluster. Doing so enables the Recorder to see all the SCCP
packets for the entire system.
Give careful consideration to the use of Gateway recording solutions because mirroring a large server
cluster means that each IP Recorder is being forced to monitor and track every call in the cluster.
Failover configuration is an important factor since very often, after detecting the failure of a
server/cluster, the IP device will register with another switch in the network. If this other switch is not
mirrored, then recording will not be possible.
Another consideration for Gateway recording is the ability to mirror the Gateway channels. With
Gateway recording, a channel is more likely to be utilized, meaning that its use may push beyond the
number of concurrent recording channels supported on the IP Recorder. So depending on the
amount of traffic the Gateway supports on a single network port, you may not be able to mirror it
directly. (See the Performance and Sizing Guidelines for the latest recommendations.) In these
instances you will require a device to load-balance the traffic to multiple Recorders.
Related topics
ADC, page 252

Extension-side Recording
Extension-side recording is achieved by port mirroring the traffic to and from an IP phone (as in
station-side recording in TDM recording). You may do this using either port or VLAN mirroring. You
may also use a network tap device if no mirror ports are available.
Port mirroring the IP device itself means that all RTP traffic to and from that device and SCCP traffic
between the device and the call processing system server/cluster (such as Cisco UCM), will be
received by the Recorder. In this configuration, there is no need to explicitly port mirror the call
processing system node or any of the conference bridge resources.
The following diagram illustrates an example of extension-side recording in that the access switches
to which the IP phones connect are port-mirrored directly.
NIC 1
NIC 2
NIC 3
VoIP Delivery
VoIP Delivery recording (also referred to as DMS recording), refers to deployments wherein the
switch/phone duplicates the audio it is sending and receiving, then directs it to the Recorders.
RTP Detection
In IP Recording you can use RTP detection to record calls in Recorder Controlled or CTI Controlled
environments (either all of the time or in fallback mode).
RTP detection is always enabled in Performance mode (which prevents loss of audio due to CTI
disconnection) and Liability modes (in which audio is recorded either by CTI or VOX and as VOX in
between CTI calls).

 In load-balanced Recorders, the RTP streams are only visible to one of the Recorders, and,
therefore, only recorded on that Recorder.
SIP Trunk Recording

A Session Initiation Protocol (SIP) trunk is a logical connection between an IP PBX and a service
provider’s application server that allows Voice over Internet Protocol (VoIP) traffic to be exchanged
between the two.
To deploy SIP trunks you need the following components:
 PBX with a SIP-enabled trunk side
 a SIP-compatible enterprise edge device (this can either be a firewall with complete support for SIP,
or an edge device connected to the firewall handling the traversal of the SIP traffic, such as a
Session Border Controller [SBC])
 and Internet Telephony Service Provider (ITSP) or SIP trunking service provider
When a call is placed from an internal phone to an external number, the PBX sends the necessary
information to the SIP trunk provider, who establishes the call to the dialed number and acts as an
intermediary for the call. All signaling and voice/video traffic between the PBX and the provider is
exchanged using SIP and RTP protocol packets over the IP network.
If the called number is a traditional PSTN telephone, the trunk provider routes the IP packets to the
PSTN gateway that is closest to the number being called, to minimize possible long distance charges.
The provider can also terminate PSTN numbers, and route incoming calls for those numbers back to
the IP PBX over the SIP Trunk. This allows businesses to offer local phone numbers in several
geographical areas, but service them all from a single location.
If the called number can be reached over a SIP Trunk, the call does not need to be routed over the
PSTN, but can instead be carried on the IP network end-to-end, creating a very cost-effective solution.
SIP trunking can also serve as the starting point for the entire breadth of real time communications
possible with the protocol, including instant messaging (IM), presence applications, whiteboarding
and application sharing.
The SIP trunk can be provided by a SIP trunking service provider or by an independent ITSP. In fact,
there may be several parties involved, each one providing a different part of the service required to
deliver end-to-end communication.
Because a SIP trunk is not a physical connection, there is no explicit limit on the number of calls that
can be carried over a single trunk. Each call consumes a certain amount of network bandwidth, so the
number of calls is limited by the amount of bandwidth and call processing resources that can flow
between the IP PBX and the provider’s equipment.
Implementation
The Recorder records traffic at the SIP Trunk. This includes SIPREC environments and environments
in which SIP trunk sessions are replicated by an edge device such as an Acme PacketTM SBC to the
Recorder. The way in which traffic is provided to the Recorder depends on the port
mirroring/replication mode. In SIP Trunk Recording, the edge device provides the Recorder with both
signaling and audio/video; in this case, the signaling does not carry the agent’s extension. SIP Trunk
Recording is therefore established at the member group level (not at the extension level).

RTP Proxy Recording

In Delivery deployments, RTP can be redirected to the Verint RTP Proxy Service, which then forwards
(to the Recorder) information upon which the decision to start recording is based. For example, the
following diagram illustrates a currently supported implementation with Lync, in which RTP is
received by the proxy and passed along to the Recorder and Recorder Integration Service.
TDM Recording
The Recorder supports trunk-side and station-side TDM recording.
TDM Trunk-Side Recording

There are two types of TDM Trunk-Side recording: Trunk Interception and Trunk Delivery.
Trunk Interception recording requires a physical connection directly between the demarcation point
and the switch system. In TDM environments, trunk-side interception taps directly into a T1 or E1 line
to record all incoming calls at the demarcation point before going to a switch.

Integration
Recorder CTI Server
Service Server
Server
Agent
LAN
Workstations
Junction
Box
T 1 Line
PBX
PSTN
Enterprise
Manager Server
Trunk Side Interception
Punchdown
Block
 One junction box is required for each T1/E1 line.
Trunk Delivery (line-side recording through E1 trunks, illustrated below) is a type of trunk termination
that can be implemented in Avaya switches and is supported on ISDN trunks (DT6409 and DT3209
cards only). E1 line-side (E1 LS) is a recording method in which the Recorder uses service observe in to
control extensions (supported in Avaya switches and IPC Media Recorder environments). The
Recorder maps each of its recording channels to one of the E1 trunk time slots, and to a specific
extension. When the Recorder starts up, it establishes services observes to each configured
extension, and from that moment on, the trunk delivers the extension's audio to the Recorder.

PBX
E 1 Line Tx
LAN E 1 Lines
Rx
PSTN
CSU /DSU / Recorder
NT /ISDN Server
Trunk Side Delivery
Agent
Workstations
TDM Station-Side Recording

In TDM environments, station-side recording is initiated between the switch/ACD 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.
Integration
CTI Server Service Server
LAN
Enterprise
Agent
Manager Server
Workstations
T 1/E 1 Line
PBX
PSTN
Recording
Station Side Recording Recorder

Server
Punchdown
Block

Attributes Provided by Card Model Families

The following table describes attributes available based on the family of voice card chosen for
recording. Different models in the same brand support the same attributes.
Voice Card Type
Attribute DP Trunk-Side NGX Digital LD Analog PCM Digital

Extension side Extension side Trunk Side
Digits N Y N N
Caller No Y N N N
Called No Y N N N
Direction Y N N N
DTMF Digits Y Y Y Y
CLI Y Y Y N
First Message N Y N N
Last Message N Y N N
Attributes Provided by E1/T1 Voice Cards

The following table describes the 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. Consult the switch administrator to confirm that the switch
is providing these attributes.
Protocol/ Recording Caller Called Direction DTMF CLI

Mode No No Digits
None/VOX N N N * *
ISDN/VOX N N N * *
ISDN/D-Channel # # Y * *
NFAS/VOX N N N * *

Protocol/ Recording Caller Called Direction DTMF CLI

Mode No No Digits
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 * *
* Only available when present on trunk bearer channel.

# Only available when trunk span is configured to deliver this information.
** In addition to the above stipulations, this is only on the T1 carrying the D channel, and all of the
trunks for a specific NFAS group must be on the same Recorder.

Recording Topologies
Topologies
This section describes several topologies you may use when deploying IP Recorder systems to record
both audio and video, many of which utilize an Application Delivery Controller (ADC) or other load
balancing device.
 ADC, page 252
 Single Recorder Cluster, page 255
 High Availability, page 256
ADC
You may use an ADC or other load balancing device with multiple IP Recorders (audio or video),
allowing deployment against higher density gateways or mirror ports on core switches. Supported
devices are described in detail in associated versions of the VoIP Interception Deployment Reference
Guide.
The device will be situated between the device used for port mirroring and the Recorders, and will
distribute the RTP to the Recorders. The following diagram illustrates this configuration.
Recorders
IDS Device
Incoming mirror port traffic ,

containing RTP and SCCP

RTP detection is enabled in Performance and Liability fallback modes to prevent audio/video loss. The
ADC ensures that there is only one recording for a given call, because the RTP is balanced to exactly
one active Recorder. Since the RTP is not given to any other Recorders there will only be one
recording for a given call.
Using an ADC allows you to configure IP recording environments that also derive several secondary
features, as described in the following sections.
High Density Gateways

A High Density Gateway is defined as a Gateway containing more concurrent channel capability than
a single IP Recorder can support. A High Density Gateway also provides only a single IP address to the
network infrastructure, meaning that no voice/video traffic segmentation can take place at the
network level.
By utilizing the ADC, IP Recorders can be configured into clusters. When this monitor group is
configured with the a load-balancing algorithm designed to distribute traffic, the RTP streams
representing the two-way voice conversation are load-balanced evenly around the Recorders in the
cluster.
Using clusters ensures that no single Recorder is forced to process and record all of the traffic for a
Gateway—this results in the capability to record high density Gateways.
The device also typically has the capability to flood specific traffic that it receives. Therefore, it can
provide all of the call control protocol (signalling), such as SIP or H.323, to the Recorders within the
monitor group, while at the same time load-balancing the RTP streams around the group.
In Gateway-based recording solutions, where many Recorders need the same extension
configuration, it is recommended that you use the Enterprise Manager to maintain synchronization.
For more information about Recorder configuration, see the Recorder Configuration and Administration
Guide.
 In order for the IP Recorder server or IP Recorder Video server 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 ADC.
Resource Scalability
Utilizing an ADC enables the IP Recorder to expand as the utilization of the VoIP system expands.
Once the network traffic has been provided to the ADC, IP Recorders can be added to the
configuration without the need for significant network engineering or additional port mirroring
resources.
 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 require an IP address and network port for data network
connectivity.
Even Resource Utilization

In both IP and TDM environments, when recording in a Gateway or trunk-side configuration, a
common issue is the varying rate at which the Recorder’s hard disks fill, due to the different utilization
of the trunks. This can have an impact on online availability, and can result in the Recorder hard disk
being sized for the worst-case scenario.
Configuring the IP Recorders into a group or cluster and enabling weighted round robin-or least
connections-type algorithm can address this issue. The algorithm ensures that calls are evenly
distributed among the Recorders, resulting in balanced hard disk usage. This means that the size of
hard disks in the Recorders no longer must be based on the worst-case scenario for recording, but
purely the talk time of the voice source being recorded.
 Utilization will not be even if individual Recorders experience down time that results in them
being out of the weighted round robin for substantial periods of time.
Less Network Traffic

The Recorder server can support up to 260,000 packets per second, depending on the hardware
model. The ADC 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 port mirroring
a Gateway), the IP Recorder will also see the Media Gateway Control Protocol (MGCP) between the
Gateway and the call processing system (such as UCM). System- and network interface-level filtering
(through Recorder Manager) can be applied to reduce the load on the IP Recorder. This filtering takes
place at low level within the network driver and is very efficient. Consider the use of filtering a last
resort; the ADC and the network infrastructure should be used to remove unwanted traffic.
Fewer Resources Required

The ADC can typically flood defined incoming traffic to any combination of its monitored ports. This
means that a single mirror port feed into the ADC can be used to flood the call control protocol to all
IP Recorders within a monitor group. This flooding capability greatly reduces the restrictions placed
on the IP Recorder by the lack of port mirroring resources in the network infrastructure layer.
 Flooding must be avoided on anything other than the required call control protocol.
Simplification of Network Topology

Use of an ADC means that as long as a mirror port for the required RTP and call control protocol can
be provided, the 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.
Single Recorder Cluster

The single Recorder cluster contains up to ten Recorders configured in the Enterprise Manager.
Traffic is distributed across all Recorders.
Data Network
Recorder Cluster
Integration Service
Server for the
Recorder Cluster
IDS Device
Incoming mirror port traffic ,

containing RTP and SCCP Data Center
Applications
Single Recorder Cluster Components

Components in a single Recorder cluster include:
 Up to 10 IP Recorder or IP Recorder Video servers per cluster. The Radware Alteon can support up
to 24 Recorders in a cluster.
 Recorder Integration Service—A single Integration Service can manage more than one cluster, up to
a maximum of 26,000 endpoints.
 ADC or load balancing device—One or more depending on the size of the cluster.
 Data Center Zone application components

Usage for Single Recorder Cluster

Typically, you would use the Recorder cluster when:
 recording at the Gateway.
 using a high density Gateway.
 recording inter-site links with large numbers of concurrent calls present.
 N+1 is required on an extension-side solution. (In the extension-side solution, the traffic is
distributed across the Recorder cluster.)
Licensing for Single Recorder Cluster

IP Recorder servers and IP Recorder Video servers configured in a cluster require a license equal to
the total number of extensions that must be recorded. Each Recorder in the cluster must have all of
the extensions that the cluster will record entered into their configuration.
Application-level Recorder Health Check

In environments with the Radware Alteon, an application-level Recorder health check can assess the
health of the IP Recorder server or the IP Recorder Video server.
The health check can be performed in either non-high availability deployments over the VoIP
Interception LAN (between the Alteon and the Recorder), or in a high availability configuration using a
pair of Alteons, wherein a dedicated port on each Alteon is used to connect to the LAN NIC on the
Recorder (management LAN) to perform the health check. The latter configuration requires that each
Recorder be dual-homed (that is, it must be configured with a NIC for VoIP interception and a separate
NIC for the management LAN) and is only supported on a separate port from those used for VoIP
Interception.
High Availability
Recording provides high availability through redundancy of the Recorders, Integration Service, or
both.
The following sections describe the types of redundancy available, and subsequent sections provide
configuration instructions for the basic scenarios for each. You will find additional information in the
Recorder Configuration Guide, and direction for specific integrations in your Integration Guide (where
applicable).
Recorder Redundancy
There are three types of Recorder Redundancy:
 N+N, in which all calls are recorded by pairs of Recorders. (N+N requires Integration Service
Redundancy as well.)
 N-Dedicated M-Shared, in which calls are recorded by a main N Recorder, with a backup M Recorder

available to take over should N experience any errors.

 N+M All Shared, in which all calls are load-balanced across a pool of Recorders.
Integration Service Redundancy

All varieties of N+M may be combined with either a single Integration Service (no redundancy) or a
pair (referred to as 1+1 Integration Service redundancy).
N+N requires 1+1 — that is, each pair of Recorders will have a corresponding pair of Integration
Services.
High Availability Design Examples

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

The diagram below illustrates a fully fault-tolerant Recorder cluster containing redundant devices (the
load balancing device, 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 in this example has a
recording capacity of 4000 channels (4 Recorders x 1000 channels). The fifth Recorder is considered
spare capacity (of an additional 1000 concurrent channels), meaning that the system is tolerant of
one Recorder node failure at any moment in time.
Data Network
Recorder Cluster
Integration Service
Load
Server for the Balancers /IDS
Recorder Cluster Devices
Redundant Link
Protectors
Incoming mirror port traffic , Incoming mirror port traffic ,

Data Center
containing RTP and SCCP containing RTP and SCCP
Applications

The cluster is designed to be fault tolerant of key elements being offline for periods of time, and
includes the following components:
 Data Center Zone application components: The servers for these components have no effect on
the ability of the system to record. If the database is unavailable, the Recorders queue up the
recorded calls. Once the database comes back online, the Recorders will upload the calls.
 Archive: This component 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
back online, calls to be archived were no longer on the Recorders. The hard disks on the Recorders
should be sized such that they can be tolerant of the Archive system running behind.
 Cluster Integration Service: In this configuration, the Integration Service is utilized for CTI
Integrations and tagging. If the Integration Service server fails, then this tagging will be lost. If an
extension must be recorded even during an Integration Service failure, it should not be configured
in this mode.
 IP Recorder Nodes: As described above, the configuration in the diagram contains five Recorders,
but is specified as providing 4000 channels of concurrent recording, as the fifth Recorder represents
the spare capacity required for redundancy.
 ADC or Load Balancing Device: If either load balancer fails, the other passive device will be
presented with the links through the Link Protectors. A network port failure would result in that
individual link being activated to the redundant the load balancer.
 Link Protectors: If the Link Protector fails, then the network connection will be maintained to the
primary the load balancing device through the protector's fail-through capability. The system is
likely not to be fault tolerant of a Link Protector and load balancer failure at the same time.
High Availability Analyzer

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 its call control commands. The receiving IP Recorder will ignore
duplicate call control commands that it receives from multiple Analyzers.
Redundant Network Feeds

Redundant network feeds into the IP Recorder are fully supported. The use of redundant network
feeds enables the IP Recorder to take feeds from multiple sources to protect against network failures.
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.
 Duplicate packets are supported, provided that the maximum packet count per second does
not exceed the maximum capacity of the Recorder. However, it is strongly recommended that
duplicate packets are removed, as they are a known contributor to network issues. (Duplicate
packets will also reduce the total number of "noise" calls detectable by the Recorder.)
See the Performance and Sizing Guidelines for more information.

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 that 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 50%.
 In these configurations you should disable the duplicate packet alarm in Enterprise Manager.
The IP Recorder supports a maximum of five network interfaces for recording when 2 GB of physical
memory is used in the server. If less than 2 GB of memory is available, then only four network
interface ports are supported.
NIC Failover
If the cable connected to a Delivery NIC is unplugged, or if the Delivery NIC is disabled through the
Windows Network Management system, the error priority of all extensions configured for Delivery
recording will be raised, so that the Integration Service can fall back to other Recorders to record
calls. This is only relevant for situations in which the Integration Service is on a different server from
IP Capture, and a NIC other than that used for Delivery recording is used as the management NIC (for
the Recorder Integration Service connection to the IP Capture Engine). If a separate NIC is not used
for the Integration Service, the Integration Service uses the link failure as a condition that triggers
redundancy.
 The Recorder only supports one NIC (or a team/bonded NIC pair) for delivery of audio.
 This feature is enabled by default, but you can disable it using the Delivery NIC Status Check
setting in the IPCaptureConfig.xml (in the%IMPACT360SOFTWAREDIR%\ContactStore folder).

Recording IP Recorder Filtering
IP Recorder Filtering
IP recording contains two levels of filtering. This filtering takes place in the WinPcap network driver,
which is very efficient. However, wherever possible you should seek to reduce the number of packets
arriving at the NICs for an IP Recorder server or IP Recorder Video server by ensuring only required
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, at the NIC level. When NIC-level filters are used, they are appended
with the system-level filter if 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 UCM
cluster has been port mirrored into a specific NIC, and the SCCP is the only information required from
port mirroring.
 When configuring system- and interface-level filters, ensure that they do not conflict with
each other.
The filters are configured using Recorder Manager, and do not require a restart of the IPCapture
service. When reconfiguring the filters, packet loss may occur during the filter application period. Use
of IP Recorder filtering allows you to decrease network traffic .
Related topics
Less Network Traffic, page 254
Related information
Configuring IP recording filters (Recorder Configuration and Administration Guide)

C h a p t e r 1 0
Text Analytics Architecture
Part of the Customer Engagement Optimization platform, Text Analytics adopts a tiered
approach to unstructured text data processing, analysis, and trending.
Topics
Text Analytics architecture overview 262

Text Analytics Service deployment levels 269
TAS service mapping 271
Text Analytics Architecture Text Analytics architecture overview
Text Analytics architecture overview

Part of the Customer Engagement Optimization platform, Text Analytics adopts a tiered approach to
processing and analyzing unstructured text data. The Interaction Capture Service acquires the
unstructured text data from different sources. The Text Analytics Service (TAS) ingests and processes
the data, and presents it for trending and content analysis through the Text Application.
Related topics
Interaction Capture, page 263
Text Analytics Service (TAS), page 264
Text Application, page 264

Interaction Capture
(ACRA only) The Interaction Capture Service integrates with customer environments to receive the
source data from different data sources, and in different formats. It transforms this data into a
uniform format for ingestion by the Text Analytics Service (TAS).
Related topics
Text Analytics architecture overview, page 262

Text Application
The Text Application is a web-based application that displays analytics data based on user requests.
The application provides dedicated workspaces for trend discovery, and content, and interaction
analysis with faceted and free-text search capabilities.
Related topics
Text Analytics Service (TAS)

The brain of the Text Analytics product, the Text Analytics Service (TAS) receives the data from the
Interaction Capture Service, parses the data, tags it with semantically meaningful information, creates
indexed search, and generates analytics. Accordingly to functionality, the TAS can be divided into
three types of logical servers: TAS Application, TAS Datastore, and TAS Installation. Based on the type
of deployment, they can be consolidated on the same or on different physical servers. Each server is
associated with a set of services.

TAS servers
All the TAS servers are deployed in the Data Center. In a consolidated deployment, the
TAS Application, Datastore, and Management servers are installed on the same physical server. In
distributed environments, each server is installed on one or more physical servers.
TAS Application server

The TAS Application server hosts the application services that provide analytic insights on the
data. The TAS Application server is also responsible for ingesting, processing and generating the data.
TAS Datastore server

The TAS Datastore server hosts the repository services for Text Analytics, including the Text Indexing
Service, and configuration settings.
TAS Management server

The TAS Management server hosts the Docker repository, logger and purge services. The Docker
repository is used to deploy the Docker images on the TAS Application and TAS Datastore servers.
TAS services
Each TAS server includes several services to enable analytics. Some services are present on more than
one server, while others are unique to the server type.
Coordinator Service
The Coordinator Service interfaces between the recorder and the TAS. The Coordinator Service
receives the normalized raw data from the recorder, and parses it into a format ready for ingestion by
the TAS. While parsing the data, the Coordinator Service also extracts metadata and calculated
metrics.
Tagger Service
The Tagger Service analyzes the unstructured data according to NLP (Natural Language Processing)
algorithms. The services run a pipeline of annotators to annotate the source documents into themes,
relations, topics, and key terms.
Search Service
The Search Service is the data access layer to the interactions data store (Text Indexing Service),
providing the functionality to manage interactions, and the business logic for the application. The
Search Service provides aggregated analytic insights on the set of unstructured interactions from
different perspectives, including trend, root-cause, and faceted search.
Model Management Service
The Model Management Service provides the user interface to view and manage the text language
models. The Tagger Service uses the text language model to extract and then annotate the text in the
interactions.
Model Training Service

The Model Training Service uses tenant data to enrich sentiment by machine-learning, and discover
significant key terms in the dataset.

Configuration Service
The Configuration Service stores user-defined configuration settings per customer, such as text
models to support the Tagger Service, and user-defined categories. It also stores the retention period
for each project.
Text Indexing Service (TINS)

The Text Indexing Service is a third-party service provided by Apache. The Text Indexing Service is the
main data store for the TAS, and provides distributed indexing, replication, and load-balanced
querying capabilities.
Data Export Service

The Data Export Service provides centralized processing functionality for data exports. In addition to
receiving and forwarding export requests to and from other services, the Data Export Service
provides storage, auditing, streaming, and cleanup functionality for export processes.
Purge Service
The Purge Service is installed on the Management Server. It provides a mechanism for permanently
deleting interactions in projects, according to the retention period in days, defined for each project.
Alarms and Monitoring Service (AMS)

The Alarms and Monitoring Service (AMS) provides a mechanism to monitor the health of
TAS services and generate alarms for viewing in the Alarm Dashboard.
The AMS comprises the Alarms and Monitoring Agent (client) and the Alarms and Monitoring
Manager (server):
 Alarms and Monitoring Agent
The Alarms and Monitoring Agent is installed on all the TAS servers, and collects health metrics
from each of the TAS services that are monitored.
 Alarms and Monitoring Manager
The Alarms and Monitoring Manager retrieves the health metrics from the Alarms and Monitoring
Agent, triggers and manages alarms for the TAS services.
It includes the Alarm Monitor, Alarm Manager, and the Monitoring Transformation Service:
 Alarm Monitor
The Alarm Monitor samples the health metrics of the monitored TAS services, and triggers
alarms according to the settings defined in its configuration file for each TAS service. The
settings includes the scraping interval and the alert rule for each TAS service, among others.
 Alarm Manager
The Alarm Manager receives the alarms as they are triggered from the Alarm Monitor. The
Alarm Manager groups the alerts according to the TAS server from which the alarm was
triggered, and the TAS service for which the alarm was triggered.
 Monitoring Transformation Service (MTS)
The Monitoring Transformation Service interfaces with the Alarm Dashboard in the System
Monitor to display TAS service alarms. The MTS forwards the alarms, and sends
acknowledgments for resolved alarms.

GlusterFS
GlusterFS is an open source scalable network file system used in high-availability environments. It
provides a shared folder across Docker containers and servers, and holds project-level data such as
the language model and category definitions.
Apache ZooKeeper
The Zookeeper is also a third-party service provided by Apache. The ZooKeeper is a centralized
service that maintains configuration and naming information. It also provides distributed
synchronization, and group services. Within the TAS deployment, the Zookeeper’s main responsibility
is to support high-availability of the Text Indexing Service, as a repository for the cluster configuration
and coordination.
Apache Kafka
Apache Kafka, an open-source stream processing platform from Apache, provides highly scalable
message-queuing functionality for real-time data feeds. Within the TAS deployment, Kafka queues the
export requests for interactions for retrieval by the Data Export Service.
Logger Services
There are two logger services:
 Central Logger Service: provides log indexing and visualization services for all the TAS services
through ELK (Elastic Search), an open-source third-party tool.
 Logger Service: collects logs from all the TAS services and aggregates them into a file in the file
system, through FluentD, another open-source third-party tool.
Secure Gateway
The Secure Gateway service is installed on every TAS server. The Secure Gateway supports SSL
offload for intra-server communication by offloading the encrypted communication to unencrypted
communication, when sending web service requests to the back-end server components.
In addition, the Secure Gateway verifies the Service Web Token (SWT) requests.
Related topics
Text Analytics data flows

Text Analytics provides data on text-based interactions in your enterprise. The Text Analytics
application allows you to take advantage of this data to gain valuable insights into key business issues
in the enterprise.
 Text Analytics data ingestion flow, page 132: describes how the source data is acquired by the
recorder, transformed, and indexed to generate analytic insights.
 Text Analytics application data flow, page 134: describes how once the index is built, the data is
available for display and analysis through the Text Application.

 Text Analytics model management data flow, page 135: describes how users can manage the text
language model used by the Text Analytics Service (TAS).
 Text Analytics alarms and monitoring flow, page 136: describes how alarms are generated for TAS
services and displayed in the System Monitor's Alarm Dashboard.

Text Analytics Architecture Text Analytics Service deployment levels
Text Analytics Service deployment levels

The Text Analytics Service (TAS) supports three levels of deployment, ranging from a small deployment
(level 1), to an enterprise scale deployment (level 3). To support this range, depending on the size of
the deployment, the system can be deployed on a single or on multiple servers, with or without high-
availability.
Single Box
The smallest deployment is a Single Box solution where almost all the TAS services reside on the
same physical server.
Multiple Box
In a Multiple Box solution, the deployment is distributed over multiple servers. The Single Box
solution becomes a Multiple Box solution when:
 Deployment specifications exceed those of Single Box deployment
 Customer requires high availability of databases or application
Deployment levels illustration

The following diagram illustrates the different deployment levels in standard and high-availability
environments for TAS services in the Data Center. Recorder servers deployed in the Site zone are not
included in the diagram.
Level 1 represents the Single Box deployment, and levels 2 and 3 represent the different levels of
Multiple Box deployments.

Text Analytics Architecture Text Analytics Service deployment levels
Related topics
Text Analytics Architecture, page 261

Text Analytics Architecture TAS service mapping
TAS service mapping

The table maps the names of the TAS services in the user interface and documentation with the name
in the Docker image.
TAS service Corresponding name in Corresponding name in

Docker image log files
Tagger Service tagger TaggerService
Coordinator vtacoordinator VTACoordinator

Service
Configuration configservice ConfigService

Service
Search Service easearch EASearchService
Text Indexing easolr EASolrService

Service
Model model_editor Model Editor Service

Management
Service
Model Training on_site_training

Service
Data Export dataexport DataExport

Service
Purge Service purger PurgerService
Central Logger elk Elk Service

Service
Alarms and cadvisor cAdvisor_exporter

Monitoring Agent
Alarm Manager prometheus Prometheus
Alarm Monitor alertmanager Alert Manager
Monitoring mts MTS

Transformation
Service
Logger Service fluentd Fluentd

Text Analytics Architecture TAS service mapping
TAS service Corresponding name in Corresponding name in

Docker image log files
Apache zookeeper Zookeeper Service

ZooKeeper
Secure Gateway secure_gateway SecureGatewayService

C h a p t e r 1 1
Mobile solution
The mobile solution includes the Verint Mobile Work View and Verint Mobile Team View
mobile applications and the Mobile Gateway. The mobile applications allow employees to
perform tasks directly from their mobile device, for example, access schedule information
and perform schedule changes. The Mobile Gateway provides a single external interface
between the system and the mobile application for mobile-specific back-end services.
Topics
Verint mobile solution overview 274

Mobile networking and communication security 275
Authentication and authorization 277
Data-at-rest and mobile device security 283
High availability and redundancy 284
Mobile solution Verint mobile solution overview
Verint mobile solution overview

The Verint mobile solution includes the Verint Mobile Work View and Verint Mobile Team View mobile
applications and the Mobile Gateway.
Mobile applications
Work View and Team View mobile apps allow employees, supervisors, and managers to quickly, and
easily log on to their information from an iOS or Android device.
 Verint Mobile Work View (for employees)
Work View allows employees to view and manage their schedule, view their performance
scorecards, and stay up-to-date with notifications and updates.
 Verint Team Mobile View (for supervisors and managers)
Team View allows supervisors and managers to view their employees' schedules, manage their
employees' requests, and stay up-to-date with notifications.
Work View and Team View apps require installing the Mobile Gateway server-side component
alongside the system. The Mobile Gateway enhances security features for the sign in process, and
enables employees, supervisors, and managers to receive push notifications to their mobile devices.
For example, supervisors receive push notifications when their employees' schedule changes or their
shift bidding status changes.
Mobile Gateway
The Mobile Gateway provides a single external interface between the system and the mobile
applications (iOS or Android based) for mobile-specific back-end services.
The main functions of the Mobile Gateway include:
 Secure sign-in to the mobile applications
 Mobile push notifications by communicating with Google Firebase Cloud Messaging (FCM) and
Apple Push Notification (APN) services
 Enhance the system's native APIs so that content is displayed properly on mobile devices (for
example, format changes and pagination).

Mobile solution Mobile networking and communication security
Mobile networking and communication security

The mobile solution provides several security measures to enable access from a mobile device (BYOD)
to the internal network. These security measures comply with the overall system security standards
and can co-exist with other standard security solutions, such as MDM and VPN.
Typical network topology

In a typical network topology, the Mobile Gateway is located in the Data Center (DC), similar to
Workforce Optimization (WFO) application servers, and is not exposed to the public network.
Inbound requests to the Mobile Gateway do not arrive directly from mobile devices, but rather are
exposed externally using a virtual IP (VIP) on a load balancer or application gateway (reverse proxy)
device deployed in the DMZ.
Supported HTTPS configurations

All mobile communication, and also internal components communication, supports data-in-transit
encryption using HTTPS and latest TLS protocols.

Mobile solution Mobile networking and communication security
Typically, between the mobile device and the internal data center servers there will be a load balancer
or application gateway device deployed on the DMZ. This device can terminate HTTPS communication
for inspection, and then continue the communication to the DC servers using HTTPS or HTTP.
If the communication method to the backend servers is over HTTPS, this is referred to as SSL
bridging.
If the communication method is over HTTP (not HTTPS), this is referred to as SSL offload.
It is also possible to configure the device so that it does not terminate at all HTTPS traffic. This
configuration is referred to as SSL pass-through.
Access to Google (FCM) and Apple (APNS)

To enable native push notifications to the mobile applications, the Mobile Gateway must have access
to the FCM and APNS services as a web service call (outbound HTTPS communication).
VPN tunneling
If mobile services should not be available to the public network at all, a VPN tunnel is required
between mobile devices and the corporate network, allowing devices to connect to the mobile
network as if they were located on the internal LAN.

Mobile solution Authentication and authorization
Authentication and authorization

Users access the mobile applications according to a pre-configured authentication method defined on
the server. Upon authentication, users are assigned a token for communication with WFO.
User authentication
When users access the mobile application, they are authenticated according to a pre-configured
authentication method defined on the server.
The following authentication methods are supported for the mobile applications:
 OpenID Connect (OIDC): Federated authentication method, to authenticate users against an
Identity Provider that supports OpenID Connect protocol (OIDC) and is certified as supported by
Verint. OIDC is an authentication method where the user's credentials are held with a third-party
identity provider (IdP) and not within the system. The system verifies the user's identity based on a
simple JSON-based identity token. When using an OIDC provider with multi-factor authentication
support, this capability can then also be used when authenticating in the mobile applications. The
user name for whom solution role is granted, must be included in the identity token.
 LDAP: Authentication method that uses a simple bind authentication process. The user is identified
by the Active Directory and the proof of identity comes in the form of a password.
 Database: Authentication method that authenticates the user with a user name and password that
is maintained solely and securely within the system’s own database.
The above authentication methods are the most common native mobile application authentication
methods. The SAML authentication method is not supported in the mobile solution.
Authorization
Once a user is authenticated, the application authorizes the user according to their specific rights and
permissions, as defined in the User Management application, and saved in the system database.
Within the system, each user is assigned one or more roles, where each role contains a set of
privileges. A role and its privileges allow the user to view certain pages and to perform certain
functions within the system.
Note that role is granted to a user who is identified by their user name. When authenticating using
OIDC, ensure that the relevant user name is included in the identity token provided by the IdP, as the
IdP user name may differ from the user name used in the solution. For example,
‘john.doe@acme.com’ (UPN) vs. ‘jdoe’ (sAMAccountName)
For additional security and granularity, user permissions for mobile access can be configured to differ
from the user’s permissions for desktop access. That way, for example, the user can create schedule
requests only when accessing WFO from a workstation, but not when accessing it from the mobile
device.

Session (access) token

Upon authentication, a WFO session is generated and a session token is created with an expiration
time (by default 60 minutes but configurable). An inactive session expires after the expiration time,
after which the user needs to re-authenticate. Re-authentication can either be done manually, or can
occur silently in the background using a refresh token (long-term sign in token).
Refresh token (long-term sign in token)

The refresh token is an encrypted long-term sign-in token saved on the mobile device and is used for
silent re-authentication whenever the session token is expired.
The refresh token is created by the Mobile Gateway server in case DB or LDAP user authentication
method is used, and by the OpenID Connect identity provider in case OpenID Connect user
authentication method is used. The silent re-authentication process is performed against the issuing
server.
The sign-in token has several advantages:
 The token is saved securely on the device’s key chain only, not on the server side, and there is no
need to save the user name and password on the device.
 The token is not readable on the device.
 The token has a (configurable) lifetime value, determined by the issuing server.
Authentication flows
The following diagrams illustrate user authentication and authorization using several authentication
methods.
For simplicity, network components deployed in the DMZ, such as the load balancer or application
gateway, are not included in the diagram, but it is assumed that every connection to the internal
network servers is done through these devices.

OpenID Connect initial authentication flow

OpenID Connect silent re-authentication using the refresh token

LDAP/DB authentication initial authentication flow

LDAP/DB authentication silent re-authentication using the refresh token
User termination
Users can be deleted or terminated in the User Management application by system administrators.
When a user is terminated, their credentials are immediately blocked on the WFO side. A new session
token cannot be generated and no new application data can be retrieved. Since the application data
is not saved on the mobile device and is wiped once the app is closed, this means that the user no
longer has access to application data.

Mobile solution Data-at-rest and mobile device security
Data-at-rest and mobile device security

Only the following data is saved on mobile devices:
 Employee ID
 Employee privileges
 Session token
 Sign-in token
 Device ID
 Server URL
 User's first and last name
User credentials or any WFO data are not cached on the devices.
The tokens are saved encrypted in the application’s sandbox (Android) or in the key chain (iOS) and
can only be decrypted by the server that issued them. For enhanced protection, it is also
recommended to enforce device password protection using the customer’s MDM infrastructure.
The following device permissions are needed for the mobile app:
 iOS: Push notifications
 Android: No special permissions are needed

Mobile solution High availability and redundancy
High availability and redundancy

The Mobile Gateway is designed for productivity and stability which is achieved by deploying multiple
servers, load balancers, and DoS protection devices
High availability
High availability of the Mobile Gateway is achieved by deploying multiple servers. Each server is
independent and stateless. A load balancer (provided by the customer) is responsible for distributing
incoming requests between the servers. The load balancer pings each one of the servers for a
heartbeat, so a request is always sent to a "live" Mobile Gateway.
Data is synchronized between the Mobile Gateway servers by continuously synching the cache layer
(Redis). The Redis Sentinel components (deployed on each Mobile Gateway server) keep track of the
availability of each one of the Redis services, forming a quorum that continuously decides which
Redis is considered to be the master.
The number of servers participating in a high availability scenario is 2+M where M is the number of
concurrent major failures. So in order to support one major failure, three servers are required.
Denial of Service (DoS) protection

DoS protection devices (for example, Firewalls, IPS) should be implemented at the network
infrastructure layer, preventing attacks from reaching the application layer.
If DoS attacks penetrate the network layer security, the WFO Secure Gateway deployed on each
server adds an extra protection layer providing defense in depth solution.
Disaster recovery
The system also supports Disaster Recovery architecture, where the Data Center can switch over to a
standby DC located in a different availability zone within an hour. In such a deployment, the customer
can deploy two load balancers configured as redundant.

Avaya IX WEM V15 2 Technical Overview

Uploaded by

Copyright:

Available Formats

You might also like

Avaya IX WEM V15 2 Technical Overview

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Avaya IX WEM V15 2 Technical Overview

Uploaded by

Copyright:

Available Formats

Avaya Workforce Engagement

June 14, 2023

About this guide 10

Avaya Workforce Engagement Technical Overview 4

Confidential and Proprietary Information of Verint Systems Inc.

Avaya Workforce Engagement Technical Overview 5

Confidential and Proprietary Information of Verint Systems Inc.

Avaya Workforce Engagement Technical Overview 6

Confidential and Proprietary Information of Verint Systems Inc.

Avaya Workforce Engagement Technical Overview 7

Confidential and Proprietary Information of Verint Systems Inc.

Avaya Workforce Engagement Technical Overview 8

Confidential and Proprietary Information of Verint Systems Inc.

Avaya Workforce Engagement Technical Overview 9

Confidential and Proprietary Information of Verint Systems Inc.

About this guide

The Workforce Optimization Technical Overview provides an overall description of the

Document revision history

Revision Description of changes

1.29 Access to Google (FCM) and Apple (APNS):

Revision Description of changes

1.26 Minor corrections.

1.24 Updates for V15.2 2021R1:

flow description to differentiate between on-premises and cloud-

describing the transcription flow in the cloud.

1.23 Speech Analytics Data Flows:

1.21 Updates for V15.2 2020R1:

Avaya Workforce Engagement Technical Overview 11

Confidential and Proprietary Information of Verint Systems Inc.

Revision Description of changes

1.19 Updated the platforms and server roles mapping table.

1.17  Updated Mobile Solution section with more in-depth information.

1.16 Updates for V15.2 HFR7:

1.15  Changed title of Introduction to Workforce Optimization Technical

1.14  HFR5 Updates

IdP for OpenID Connect.

Verint Mobile Work View

 Under Mobile Gateway architecture, updated the diagram

 Updated Mobile Gateway security to include the IdP sign in process

Avaya Workforce Engagement Technical Overview 12

Confidential and Proprietary Information of Verint Systems Inc.

Revision Description of changes

1.10 Updates for HFR4:

1.08 Revised Thales KMS description in the End-to-End encryption topic

Avaya Workforce Engagement Technical Overview 13

Confidential and Proprietary Information of Verint Systems Inc.

Revision Description of changes

1.06 Updates for HFR3:

 Section: System Management: Removed Information collector

service from list.

 Added steps 4 and 5 to data flow description

1.04 Updated diagram in Databases by platform section: Moved ETL Staging

Avaya Workforce Engagement Technical Overview 14

Confidential and Proprietary Information of Verint Systems Inc.

Revision Description of changes

1.02 The following changes were made for this release:

 Chapter 2 - Logical Architecture

Databases, and Text Analytics Services to Data Processing