WFO 12.1 Distributor Technical Reference - Avaya...Avaya Page 2 of 114 Added information regarding SRTP for AMS based recording. Added SIPREC to “Overview and Architecture” section

Avaya Page 1 of 114

Distributor Technical Reference Bulletin

Date: Oct 16th

2015

Doc Issue: 1.5

Compas ID: 170162

Workforce Optimization 12.1

Distributor Technical Reference REVISION HISTORY

Date Revision # Summary of Changes

May 4th

2015 Issue 0.1 Initial Draft for WFO 12.1 Beta trials that includes

ASBCE/ ACR integration details section.

May 7th

2015 Issue 0.2 Include guidelines regarding AntiVirus and 3rd

party applications for ACR (Section “Known Issues

and Workarounds”)

June 17th

2015 Issue 0.3 Internal version updates

July 3rd

2015 Issue 1.0 TCP strongly recommended for SIPREC (versus

UDP)

Section 9.2: Clarified that the nailup call is always

to a secondary DN in a POM/ AACC-AML

configuration

Added new section 12 on Multi-switch support.

Clarification that Live Monitoring does not support

Telephone Replay

SIPREC: documented announcement.record

= false property setting.

SPIREC: Clarified that some DMCC ports are

usually required to handle calls that do not traverse

the SBC

SIPREC Codec selection- known limitations: ACR

provides G.711 in its SDP whereas it actually

supports both G.711 and G.729

ACCC-SIP solution no longer offered on CS1000.

POM Data Source Configuration updated.

Updated Software Distribution and Updates section

SIPREC: Updated known limitations for ASBCE

integration to include relevance of UCID

Avaya Page 2 of 114

Added information regarding SRTP for AMS based

recording.

Added SIPREC to “Overview and Architecture”

section.

July 30th

2015 Issue 1.1 Added clarification around why some legs of Elite

calls are recorded via DMCC rather than SIPREC.

Added limitation on multi-switch SIPREC

recording due to defsw132108.

Sept 3rd

2015 Issue 1.2 ACR now supports for POM multiple zones.

Minor improvements to readability of POM

Configuration section.

Sept 25th 2015 Issue 1.3 Clarify that WFO POM datasource details must

match POM datasource on ACR and not in

properties file as in previous releases.

Oct 15th 2015 Issue 1.4 Section 12: Urgent advisory Impacting ALL 12.0 &

12.1 sites

Added 6.4 Configuration Tips

Oct 16th 2015 Issue 1.5 Added new section “13.1 ACR Power On

Sequence”

PROPRIETARY INFORMATION: The information contained in this document is the property of Avaya. Except as specifically authorized in writing by Avaya, the holder of this document shall keep all information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination

to all third parties.

Avaya Page 3 of 114

1 Table of contents

2 Introduction ......................................................................................................... 8

2.1 Objective ............................................................................................................................. 8

2.2 Target Audience for this document ..................................................................................... 8

3 Software Distribution and Updates ................................................................... 9

3.1 WFO 12.1 Portfolio Patches and ISO images .................................................................... 9

3.1.1 ACR 12.1 ................................................................................................................ 9

3.1.2 WFO 12.1 ............................................................................................................... 9

4 Recording Modes in CM and CS1K: Overview and Architecture ................. 10

4.1 Introduction and Background ............................................................................................ 10

4.2 Recording in a CM Environment ....................................................................................... 10

4.2.1 Single Step Conferencing Recording only .......................................................... 11

4.2.2 CM SIP Hybrid Mode Overview ........................................................................... 12

4.2.3 SIP Recording via AACC Web Services only on CM........................................... 13

4.2.4 SIPREC in a CM Environment ............................................................................. 14

4.3 Recording in a CS1k Environment .................................................................................... 15

4.3.1 MLS Recording only ............................................................................................. 15

4.3.2 CS1K SIP Hybrid Mode Overview ....................................................................... 16

4.3.3 “AACC only” SIP Recording Mode ....................................................................... 17

5 SIP CC Hybrid (CM and CS1K): Technical Tips and Details ......................... 18

5.1 Introduction ....................................................................................................................... 18

5.2 Encryption support for AMS-SIP based recording ............................................................ 18

5.3 AACC-Specific Configuration for SIP Call Recording ....................................................... 18

5.3.1 AACC Installation ................................................................................................. 18

5.3.2 AACC Configuration and Maintenance items. ..................................................... 19

5.4 AACC Firewall Security Policy version 1.0 or later ........................................................... 23

5.5 ACR.properties file settings .............................................................................................. 23

5.6 Activity Codes not supported ............................................................................................ 25

5.7 ACR Firewall Configuration ............................................................................................... 25

5.8 ACR Codec support in SIP Hybrid mode .......................................................................... 25

6 CM SIP Hybrid Mode Technical Details .......................................................... 26

6.1 Introduction ....................................................................................................................... 26

6.2 AES 4.2.1/ 5.2.2 SuperPatch 3 ......................................................................................... 26

6.3 AACC Contact ID for inbound calls - UCID or GUID ....................................................... 26

Avaya Page 4 of 114

6.3.1 UCID Configuration .............................................................................................. 26

6.3.2 UCID Hex Encoded Value ................................................................................... 30

6.4 Configuration Tips ............................................................................................................. 31

7 NES legacy CS1k Configuration: Technical Details ...................................... 32

7.1 NES Legacy CS1k Configuration Overview ...................................................................... 32

7.2 cc.v6 mode ........................................................................................................................ 33

7.3 Multiple Appearance (MADN) Support.............................................................................. 33

7.4 Call Server Release 4.5 Implementation .......................................................................... 35

7.5 Agent Observe .................................................................................................................. 35

7.6 IP Softphone Release 3 .................................................................................................... 35

7.7 Group Call Key Not Supported ......................................................................................... 35

7.8 TDM Recorder Requirements and Supported Trunk Types ............................................. 36

7.9 Viewer Stitching ................................................................................................................ 36

7.10 Phantom DN’S .................................................................................................................. 36

7.11 Call Recording Desktop .................................................................................................... 36

7.12 MultiDN Recording ............................................................................................................ 37

7.13 Record on Demand ........................................................................................................... 39

7.13.1 Record On Demand: CS1k Configuration ............................................................ 41

7.14 Save Conversation ............................................................................................................ 41

7.14.1 Save Conversation: CS1k Configuration ............................................................. 44

7.15 Secure Call Recording ...................................................................................................... 44

7.15.1 Secure Call Recording impacts on ACR Server Performance ............................ 44

7.15.2 Provisioning Server Setup ................................................................................... 44

7.15.3 IP Phone Setup .................................................................................................... 45

7.15.4 Signalling Server Setup: ...................................................................................... 46

7.15.5 NES Call Recorder Setup .................................................................................... 50

7.15.6 How To Check if Secure Call Recording is Enabled............................................ 51

7.15.7 Unistim 5.3 ........................................................................................................... 52

8 Proactive Outreach Manager Integration ....................................................... 53

8.1 Introduction ....................................................................................................................... 53

8.2 POM and ACR Architecture Overview ............................................................................. 53

8.2.1 Consult Call Scenarios ......................................................................................... 56

8.3 POM Configuration............................................................................................................ 58

8.4 ACR Settings for POM Integration .................................................................................... 62

8.4.1 Licensing .............................................................................................................. 62

8.4.2 ACR Configuration for POM ................................................................................. 62

Avaya Page 5 of 114

8.5 WFO Configuration for POM Integration ........................................................................... 65

8.5.1 POM and CC-Elite on CM .................................................................................... 65

8.5.2 POM and AACC on CM ....................................................................................... 66

8.5.3 POM and AACC on CS1000 ................................................................................ 67

8.6 Limitations ......................................................................................................................... 68

8.6.1 Complex Call Scenarios ....................................................................................... 68

8.6.2 CS1000 Release and Relevant Patches ............................................................. 68

8.7 POM Multiple Zones.......................................................................................................... 68

9 ASBCE Integration Details ............................................................................... 69

9.1 Introduction ....................................................................................................................... 69

9.2 ASBCE ACR integration via SIPREC Overview ............................................................... 70

9.2.1 AACC-CM Architecture ....................................................................................... 71

9.2.2 CC-Elite Architecture .......................................................................................... 72

9.2.3 Hybrid Recording ................................................................................................. 73

9.2.4 Alternate Routing / Scalability .............................................................................. 73

9.3 ASBCE Configuration........................................................................................................ 74

9.3.1 Licencing .............................................................................................................. 74

9.3.2 Server Configuration ............................................................................................ 74

9.3.3 Routing Profile...................................................................................................... 75

9.3.4 UCID for Recording Server .................................................................................. 76

9.3.5 Session Policies ................................................................................................... 77

9.3.6 Session Flows ...................................................................................................... 78

9.3.7 Server Flows ........................................................................................................ 78

9.3.8 Secure Recording ................................................................................................ 80

9.3.9 Selective Recording ............................................................................................. 81

9.4 CM Configuration .............................................................................................................. 83

9.4.1 UCID Configuration .............................................................................................. 83

9.5 ACR Configuration ............................................................................................................ 85

9.6 Known Limitations ............................................................................................................. 86

9.6.1 Selective Recording Not Supported ..................................................................... 86

9.6.2 General Recording Strategy and Prioritization of Recording Mechanisms ........ 86

9.6.3 Recording Indication ............................................................................................ 87

9.6.4 AACC Scenarios .................................................................................................. 88

9.6.5 Elite Scenarios ..................................................................................................... 90

9.6.6 Far End Hold ........................................................................................................ 91

9.6.7 Progressive POM Campaigns .............................................................................. 91

Avaya Page 6 of 114

9.6.8 AAEP Transfers ................................................................................................... 92

9.6.9 Multi Switch .......................................................................................................... 92

10 WFM Configuration: Technical Details ........................................................... 93

10.1 WFM support for Multimedia/Multiplicity ........................................................................... 93

11 Multi-switch Support (aka Multiple Data Source Support) ............................ 94

11.1 Introduction ....................................................................................................................... 94

11.2 Guidelines and Limitations ................................................................................................ 95

12 Limitations, Known Issues and Workarounds ............................................... 97

12.1 wi00995346: Transferred/Conferenced party information is not displayed incase of ACR-PC (Hard Dialer) integration ........................................................................................................... 97

12.2 wi00995350: ACR does not display any information about the party called by using manual call feature ......................................................................................................................... 97

12.3 wi00999905: ACR needs both Links in a CM Hybrid Configuration ................................. 97

12.4 wi00954981: ACR counts twice for calls observed via CTI .............................................. 98

12.5 wi00955895: Total call segments recorded are counted incorrectly for CDN call with screen 98

12.6 SIL issue 15: ACR CTI information from Elite and AACC when there a CLAN busy out-release/CTI busy out-release during an active CDN or VDN call. ................................................. 99

12.7 Passive IP does not support SIP Phones, only H.323 ...................................................... 99

12.8 Attendant Console not supported on CM .......................................................................... 99

12.9 wi01030448 ACR Interoperation with AACC Mission Critical Operation ......................... 99

12.10 SIP Recording Traffic Performance and Optimisations .................................................. 100

12.10.1 TCP_NODELAY on ACR ................................................................................... 100

12.10.2 tcpackfrequency on AACC ................................................................................. 101

12.11 wi00859051: AACC6.1 CCT: Agent LOGOUT events are sent to ACR in wrong order . 101

12.12 ACR 12.1 does not support Avaya Interaction Center .................................................... 102

12.13 wi01052168: AAAD loses call while physical phone retains it after Audix-rec button pressed twice. .............................................................................................................................. 102

12.14 SAP 1-3988673732: WFM does not handle agent logout over multiple packets .......... 102

12.15 Verint# 4168480: Avaya - ASCM for CMS Reports interface does not function properly.103

12.16 Issue with Forecasting and Scheduling web based client. ............................................. 103

12.16.1 Verint# 4159230: Attempting to generate schedule in WFM remains at 0%. .... 103

12.16.2 Verint# 4171662: When adding a floating/class event, receive hourglass for a long period of time........................................................................................................... 103

12.16.3 Verint# 4178212: Exception error when working in a Campaign. ...................... 103

12.16.4 Verint# 4172440: Error when trying to unlock a shift that is coming into the new schedule already locked ................................................................................................. 104

12.17 Verint# 4168478: QM Call time is off by 1 hour .............................................................. 104

Avaya Page 7 of 114

12.18 Misleading information in Avaya Archive Administration Guide Release 12.0 ............... 104

12.19 CaptureLayeredWindows setting for Windows XP ......................................................... 104

12.20 POM Agents should not put their nailup call on hold ...................................................... 104

12.21 wi01156994 - POM does not inform ACR that an external consult call is initiated ........ 105

12.22 POM – ACR: Duplicate Agent Details in Search & Replay ............................................. 105

12.23 wi01179953: Extra recording in conf/trans from POM to non POM agent via CDN ....... 105

12.24 wi01179339: ACR updates wrong value for Hold Count, Transfer Count and Conference Count column in external transfer or transfer via agent mode POM contact ............................... 106

12.25 ACR does not support AACC/POM Agent ID’s that overlap with the Phone secondary DN (AACC-AML configuration) .......................................................................................................... 106

12.26 wi01180510: External transfer from POM agent to a VDN not supported ...................... 106

12.27 SIP PHONE (SIP type) is not recognized by TSAPI ....................................................... 107

12.28 Antivirus and other 3rd Party Applications on ACR ........................................................ 108

12.28.1 Common Problems ............................................................................................ 108

12.29 Live Monitoring does not support Telephone Replay ..................................................... 109

12.30 ACR interworking with AMS on Aura 7.0 not supported ................................................. 109

12.31 Codec selection type used with SIPREC ........................................................................ 109

12.32 Urgent advisory Impacting ALL 12.0 & 12.1 sites ........................................................... 110

13 Additional Technical Guidelines ................................................................... 111

13.1 ACR Power On Sequence ............................................................................................. 111

14 References ...................................................................................................... 112

15 Appendices ..................................................................................................... 113

A. QM Call Time Workaround ............................................................................................. 113

Avaya Page 8 of 114

2 Introduction

2.1 Objective

This document can be used as a supplement to the existing Customer documentation for WFO

12.1, and it contains extra technical notes and details that may not be contained in the Customer

Documentation. It can be viewed as a “solution level” release notes that can be used by installers

and administrators as an additional source of technical information. In particular, it will contain

information about any known issues and workarounds that are likely to be found during

installation or in production.

Note that this document should only be used in conjunction with the WFO 12.1 release -

corresponding DTR’s were previously issued for WFO 10.1, WFO 11.0 and WFO 12.0 which

contain similar type information.

2.2 Target Audience for this document

This document is targeted for technical personnel who are responsible for the installation and

maintenance of a WFO solution component primarily contact recording, quality monitoring and

WFM.

Avaya Page 9 of 114

3 Software Distribution and Updates

3.1 WFO 12.1 Portfolio Patches and ISO images

The latest GA patch lineup and ISO images are available are available at:

http://support.avaya.com and navigate to the Product “Avaya Aura Workforce Optimization”,

Downloads section.

WFO 12.1 is essentially a new version of the ACR recorder and there are 2 new ISO images

associated with this:

ACR12.1 Linux

ACR 12.1 windows

3.1.1 ACR 12.1

The ISO images and patches for ACR 12.1 are located on the support.avaya.com web pages:

Avaya Aura Workforce Optimization 12.1 - ISO Images, 12.1.x

Avaya Aura Workforce Optimization 12.1 - Latest GA Patches and Hotfix Rollups,

12.1.x

3.1.2 WFO 12.1

For all of the other WFO Framework components, the existing WFO 12.0 ISO images and latest

Hot Fix rollups are still applicable, so essentially WFO 12.1 comprises a new ACR 12.1 in

conjunction with the existing WFO 12.0 Framework

Therefore the ISO images and Hotfix rollups for the standard WFO 12.0 install are located on the

existing support.avaya.com web page for WFO 12.0, as follows:

Avaya Aura Workforce Optimization 12 - ISO Images, 12.0.x

Avaya Aura Workforce Optimization 12 - Latest GA Patches and Hotfix Rollups,

12.0.x

However there are a couple of additional patches that should only be applied on WFO 12.0 when

interfacing with ACR 12.1, as follows:

• APP KB115846

• MAS KB116461

• Playback (Desktop) KB116292

The above patches are required specifically when Live Monitoring via Quality Monitoring

functionality is required.

These additional patches will be located on the WFO 12.1 Latest patches and Hotfix Rollups

web page in order to distinguish them from the standard WFO 12.0 framework install:

Avaya Aura Workforce Optimization 12.1 - Latest GA Patches and Hotfix Rollups,

12.1.x

http://support.avaya.com/

Avaya Page 10 of 114

4 Recording Modes in CM and CS1K: Overview and Architecture

4.1 Introduction and Background

ACR has historically implemented a number of different mechanisms to record calls, based on

the available interfaces from the CS1k and SM Switch environments.

ACR can record calls controlled by an Avaya Aura Contact Center running on either a

Communication Manager (CM) or a CS1000 (CS1k) platform. Depending on the switch type,

there are different types of installation for the Contact Center, and this is relevant to how the Call

Recorder interfaces with the Contact Center and hence impacts the Recorder mode of operation.

4.2 Recording in a CM Environment

In this environment there are essentially 2 different recording technologies that can be used - SIP

and Single Step Conferencing (SSC) and as a result of that, 3 possible configurations that are

supported:

SSC only - sometimes referred to as “CM legacy Recording”

SIP + SSC - sometimes referred to as “CM SIP Hybrid Recording”

SIP only

These 3 configurations are described in more detail in the following sections.

Note that the traffic capacity that is supported specifically for SIP recording is 3000 calls per

hour.


4.2.1 Single Step Conferencing Recording only

This is sometimes referred to as “Legacy CM Recording”. In this mode of operation, all calls are

recorded using SSC via DMCC/TSAPI interfaces. This is the standard mechanism used for

recording of knowledge workers on CM or Agents on CC Elite.

Note that this solution can be implemented with or without encryption (SRTP)

Single Step Conferencing

In this configuration, the ACR can run on Linux or Windows.


4.2.2 CM SIP Hybrid Mode Overview

In this environment, the AACC it is installed and configured as an “AACC–SIP” Contact Center.

This basically means that the Contact Center interfaces to the CM Switch infrastructure using

SIP trunking for voice sessions (via the SES or Session Manager), and using SIP TR87 (via

AES) for CTI events from the switch. From a call recorder perspective, the connectivity to

AACC is via CCT Web Services, and this is the mechanism by which the recorder receives CTI

information for all agent related call events and agent events (such as Login, Logout, Ready, Not

Ready). Additionally the recorder can invoke SIP recording start/stop requests via Web Services.

Note that in this environment, the recorder must also maintain a direct link into the CM via the

AES component using the DMCC/TSAPI protocols. This is required as the recorder needs to

retain the ability to record Agent calls that are not associated with the Contact Centre i.e. calls

which are physically not anchored on the AMS from a media perspective.

This type of configuration is referred to as a “CM SIP Hybrid” mode, as the recorder uses a

combination of both existing legacy CTI mechanisms (DMCC/TSAPI) and the newer Web

Services offered by AACC for SIP Recording.

CM SIP Hybrid Configuration

In the hybrid configuration, the ACR 12.x requires that both the Web Services and

DMCC/TSAPI links are operational. If either of these links is not functional, then the recorder

will not operate correctly. For example if the Web Services link is out of action, DN calls that

should be recorded via DMCC may not be recorded, even though the DMCC/TSAPI link is OK.


ACR 12.1 introduces the capability to support encryption for the AMS based RTP stream.


4.2.3 SIP Recording via AACC Web Services only on CM

In this mode, only the Web Services link to AACC enabled. Note that with this configuration,

only inbound contact center calls will be recorded i.e. calls that are physically anchored on the

AMS. This mode is configured by setting the switch type on the ACR to ‘AACC (only)’ on the

ACR via menu General Setup/Contact Centre Interface/Switch Type.

Optionally with ACR 12.x it is possible to configure only a link to CCT Web Services i.e. no

DMCC/TSAPI link in a CM environment. With this configuration, only calls that are anchored

on the AMS media server component can be recorded using SIP – any other calls that are not

anchored on AMS cannot be recorded (e.g. outbound, personal or DN consult calls). This mode

can be selected by setting the switch type to “AACC only” under General Setup/Contact Centre

Interface.

This configuration is only suitable in situations where it is only necessary to record calls that

arrived to an Agent via a CDN i.e. all customer inbound calls.

NOTE: When adding agents to the recorder in this “AACC only” mode, you must use the agent

ID rather than the agent station number in the Operations/Bulk Recording Page. If you enter the

station number, the calls will not be recorded.

SIP Recording via AACC Web Services only


ACR 12.1 introduces the capability to support encryption for the AMS based RTP stream.

RTP

Gateway


4.2.4 SIPREC in a CM Environment

ACR 12.1 introduces a new recording capability based on the IETF SIPREC standards. This

capability is implemented in conjunction with the Avaya Session Border Controller which also

supports the SIPREC standard.

In this topology, ACR has the ability to receive a forked audio stream directly from the SBC for

all calls that traverse the SBC.

In practice, this type of recording is always deployed in conjunction with additional call

recording methods (e.g. DMCC/TSAPI) as SIPREC can only record calls that pass through the

SBC. Additionally, a TSAPI link is always required when using SIPREC recording as the ACR

requires this event stream to make its recording decisions, even if SIPREC is used to record.

Note that this solution can be implemented with or without encryption (SRTP)

Refer to later section “ASBCE Integration Details” which describes the SIPREC solution in

more detail.

SIRREC Recording via Session Border Controller


4.3 Recording in a CS1k Environment

When in a CS1k environment, the ACR is only supported on Windows.

In a CS1k environment, the AACC itself can have 2 modes of operation:

“AACC–SIP” Contact Center: This is analogous to the CM configuration, in that all of

the interfaces for the AACC are using SIP – SIP trunking to the CS1K NRS component

and SIP TR87 to the CS1k Signalling Server.

“AACC- AML” Contact Center: In this configuration, the CTI link to the Switch is via a

proprietary AML link.

Therefore in a CS1k environment, there are essentially 3 basic configurations for call recording,

as follows:

MLS only Recording

SIP + MLS - referred to as “CS1k SIP Hybrid Recording”

SIP only Recording

These 3 configurations are described in more detail in the following sections.

4.3.1 MLS Recording only

This is sometimes referred to as “Legacy CS1k Recording”. In this mode of operation, all calls

are recorded via the MLS interface. This is used in an AACC-AML configuration, but can also

be used in a knowledge worker environment. Recording is possible using either Duplicate Media

Stream or TDM recording. Note that this solution can be implemented with or without

encryption (SRTP)

MLS Only Recording Configuration


4.3.2 CS1K SIP Hybrid Mode Overview

NOTE that the CS1K SIP Hybrid configuration is no longer been offered, however the

details below are maintained as information only with respect to existing installations.

This mode of operation refers to a configuration of ACR in a CS1K environment that also

includes AACC (Avaya Aura Contact Centre). In this configuration mode, the ACR is

simultaneously connected to AACC Web Services and also directly to the MLS component via a

standalone MLS server.

Note that the term “Hybrid” in this context means that we are using a combination of SIP

recording via the AMS and the existing MLS recording via a standalone MLS server, together as

a solution.

An MLS is basically a second AACC configured as an AACC-AML, with no agents so its

purpose is just to expose the MLS interface,

CS1K SIP Hybrid Configuration


In the hybrid configuration, the ACR 12.x requires that both the Web Services and MLS links are

operational. If either of these links are not functional, then the recorder will not operate correctly.

For example if the Web Services link is out of action, DN calls that should be recorded via MLS

may not be recorded, even though the MLS link is OK.

Note that with ACR 12.x it still possible to set up a recording solution using MLS only as per

CRQM 7 – this is relevant to Knowledge Worker environments and also to AACC-AML contact

center configurations.

4.3.3 “AACC only” SIP Recording Mode

For the CS1k Hybrid modes, there are essentially 2 simultaneous links configured – Web

Services and MLS

Optionally however with ACR 12.x it is possible to configure only a link to AACC Web

Services i.e. no DMCC/TSAPI link in a CM environment or no MLS link in a CS1k

environment. With this configuration, only calls that are anchored on the AMS media server

component can be recorded using SIP – any other calls that are not anchored on AMS cannot be

recorded (e.g. outbound, personal or DN consult calls). This mode can be selected via the switch

type setting under General Setup/Contact Centre Interface.

This configuration is only suitable in situations where it is only necessary to record calls that

arrived to an Agent via a CDN i.e. all customer inbound calls.

NOTE: When adding agents to the Recorder in this “AACC only” mode, you must use the agent

ID rather than the agent station number in the Operations/Bulk Recording Page. If you enter the

station number, the calls will not be recorded

AACC Only Configuration


5 SIP CC Hybrid (CM and CS1K): Technical Tips and Details

5.1 Introduction

All of the material in this chapter is relevant to both CM and CS1k SIP Hybrid configurations. In

later chapters, there is some additional material which is specific to only a CM environment or

CS1k SIP Recording.

NOTE THAT THE AACC-SIP SOLUTION IS NO LONGER OFFERED ON CS1000

5.2 Encryption support for AMS-SIP based recording

ACR 12.1 introduces the optional support for encryption of the audio stream from the AMS

component of the AACC contact center.

Under normal conditions, the ACR application works with the AES platform by using default

certificates which enables TLS operation. TLS operation is implicit as part of the named

licensing implementation for ACR on the AES.

If encryption is required for any calls recorded using the AMS – based SIP recording

mechanism, then TLS must be configured for SIP messaging between ACR and AACC.

No explicit configuration is required on ACR for the actual SRTP stream – however there are

settings on the AMS that are required which are detailed in the next section of this document.

In this topology, the ACR acts as a server and the AACC is the client so therefore a signed

certificate must be populated on all of the ACR servers (Master, Standby and Slaves) used in the

solution. A certificate request should be generated on the ACR using the steps describe in section

“Generating a Certificate Signing Request” in the ACR PIA guide. This certificate should be

signed by whatever Certificate Authority (CA) the customer has chosen to use, and it should then

be imported back into the ACR keystore.

5.3 AACC-Specific Configuration for SIP Call Recording To enable SIP Call Recording there are a small number of configuration items that should be

checked on the AACC Configuration

5.3.1 AACC Installation

Refer to the “Installation data” page under the “Licensing tab”.

For SIP Call Recording (both MBT/CM and CS1k environments), ensure that the “Open

Queue” optional package is selected during the installation process for AACC. Open Queue

is required as it provides an underlying link between the CCT and CCMS components within

AACC.


5.3.2 AACC Configuration and Maintenance items.

Ensure that the following items are configured for correct SIP Call Recording Operation

5.3.2.1 AACC Server Configuration:

Licensing Page:

Make sure that “Open Queue” is selected.

WS Open Interfaces Page:

If SOA Enabled is selected AND if CCMS is co-resident with CCT, then you need to ensure

that the ports used by SOA and CCT Web Services are not using the same port range.

Ensure OpenQ and OpenNetworking Web Services and the CCT Web Services do not

use the same port on the server. For example, change the OpenQ and OpenNetworking

services port value from 9080 to 9070 in the Web services section of server

configuration.

If AACC has been upgraded from a previous version, ensure that the port settings have

not been reset to default values which might cause a conflict with the CCT console port

settings.


5.3.2.2 CCT Console Configuration:

Note that changes to CCT Console require a restart of AACC to take effect.

Ensure that CCT Web Services are enabled:

Go to Avaya/Contact Centre/Communication Control Toolkit/CCT Console

From the right hand pane of the CCT console, select Communications/Control Toolkit/Server

Configuration

Ensure the Tab “Enable CCT Web Services” is enabled

Ensure that TLS is disabled as this is currently not supported by Call Recorder.

The Session Timeout value on the CCT console should be set to a small value, greater than 1

minute. The default value is 120 minutes = 2 hours which is an acceptable setting.

Note that for AACC 6.1 or later, there are additional entries in the CCT Web Services page for

the Call Recording UserID/Domain/password that must also be configured. Historically on ACR

10.1 this User ID is was hardcoded to the value “CallRecordUser” so this is the value that must

be used, however with ACR 12.x this User ID can be explicitly configured.

Note also that the entry “Domain Authentication Server” is the actual server name of the

Server that is running the Domain Controller Software.

For Domain Authentication Method, use “Simple”. If the alternative “Digest-MD5” is used,

this then requires that the “reversible encryption” option is enabled on the Domain Controller

for the CallRecordUser account)

If AACC has been upgraded from a previous version, please ensure that the CCT console

settings have not been reset to default values as a result of this upgrade.


Additionally, ensure that the “CallRecordUser” is explicitly added as a User Account within

CCT administration - see below: This can optionally be done by using the User Import

capability in the CCT Console.


5.3.2.3 License Manager Configuration Check: In the Real Time Usage Page, ensure the SIP Call Recording license Nodal Open Interface

Contact Recording is available. This listing corresponds to the license string

LM_CONTACTRECN in the physical license file.

Also ensure that the CCT Web Services are available– as “Nodal Open Interface Open

Networking” in this page. The best way to check this is via the license file - this listing

corresponds to the license string LM_OIN in the physical license file.

Additional License File Check:

You can check the contents of the AACC license file itself, as follows:

Within the license file AACC, the license identifier for SIP Call recording is Nodal Open

Interface Contact Recording : This is an on/off License that enables the AACC for SIP Call

Recording functionality.

In addition, a license is required for CCT Web Services. The License identifier required for

this is LM_OIN.


5.3.2.4 AACC and AMS settings for Encryption On the AMS, the following configuration is required:

Configure AMS SRTP in Best Effort or Security Enforced mode

Untick “Enable SRTCP Encryption” – this is unticked by default.

Tip: If you look at agent invite 200 OK from AMS, you should see that AMS has added a crypto

line inside the SDP: a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:use9fiqUUk/r5KmtBkUSb9vaQWeFf/A1oQQJSvYw|2^31

In general if SRTP and TLS is being deployed for the AMS based recording solution, it will be

in the context of a wider solution that involves other system components like AACC, Session

Manager (SM), Communications Manager. Refer to the Avaya Aura® Contact Center

Commissioning Guide which provides all the configuration information for AACC and AMS.

5.4 AACC Firewall Security Policy version 1.0 or later

If Windows Firewall is enabled on the AACC server, it is necessary to use the latest Avaya Aura

Contact Center Windows Firewall Policy file (version 1.0 or later) as this includes support for

SIP Call recording by allowing ACR to connect to CCT Web Services via port 9080. This latest

AACC Firewall Policy opens port 9080 for inbound connections.

5.5 ACR.properties file settings

The following entries can be included in the acr.properties file:

rec.mincallduration=1000 (Optional – only set if necessary, see details below)

dms.maxchannels=nn

Explanation of these settings:

rec.mincallduration=1000 (default value is 250mS)


This is an internal timer used in ACR to deal with potential race conditions due to dual CTI

streams arriving from the AES TSAPI interface and the AACC web services interface. .In

some scenarios there may be small recording fragments (e.g. less than 1 second) that are

recorded, due to the fact that the ACR can record using 2 different mechanisms. This setting

is designed as an option to remove these small call fragments in order to avoid confusion

when using the Search & Replay application.

Note that if the initial 1 second of the call is critical for the business that is deploying Call

Recording, then it may be better to use a value less than 1000, preferably the default 250mS

value. This could result in more calls being segmented in heavy traffic conditions, but no

valuable recording information will be impacted.

Choose the value of this setting based on your business requirements. Usually this value is set

at the default 250mS.

dms.maxchannels=nn

Enabling SIP recording to take place on a Slave ACR is achieved by setting

dms.maxchannels=0 in the ACR properties file of the Master and Standby ACR's, and then

setting dms.maxchannels=nn on the acr.properties file of the Slave ACR where nn is the

number of channels available on the Slave ACR to make recordings.

Sometimes when diagnosing issues, for debugging purposes it may be necessary to set the ACR

logging into debug mode. This increases the amount of information that is contained in the

acr.log file, and can fill up the hard disk much more quickly. Debug mode can enabled by adding

the entry:

log.level=DEBUG

Refer to the PIA guide for more details on this [1].


5.6 Activity Codes not supported

AACC Web services currently does not support providing Activity Codes information to the

ACR.

5.7 ACR Firewall Configuration

Refer to the ACR PIA [1] to understand which ports are used by ACR and ensure that any

Firewalls are configured to allow traffic through these ports.

5.8 ACR Codec support in SIP Hybrid mode

Currently only G.729 is support by the ACR. Note that even though Customer/Agent Conference

legs are G.711, AMS (Avaya Media Server) can support a 3rd

recording leg in G.729.

This limitation would only become an issue if AMS were explicitly configured to NOT allow

G.729 codec support.


6 CM SIP Hybrid Mode Technical Details

6.1 Introduction

The material in this section is specific to the CM SIP hybrid configuration only.

6.2 AES 4.2.1/ 5.2.2 SuperPatch 3

For AES 5.2.1/5.2.2 it is mandatory to use Super Patch 3 on the AES (even if using multiple

AES’s) as it resolves a P1 issue with Call Recording.

6.3 AACC Contact ID for inbound calls - UCID or GUID

AACC creates a contact ID for every incoming CDN call and format of this contact ID can vary,

depending on the configuration of Communication Manager and other system components.

The operation on AACC is as follows:

- If AACC is supplied a UCID (Universal Call ID) by the Session Manager, then

AACC will use this as the contact ID with which it identifies the call. This same

contact ID will then be supplied to the ACR via Web Services. The UCID is a 20

digit numeric number.

- If AACC is not supplied a UCID from Session Manager, then it will generate its

own internal contact ID. This is an internally generated GUID (Globally Unique

Identifier) which is a 32 digit alphanumeric number.

Thus depending on the wider system configuration, there may or may not be a UCID supplied to

AACC, and consequently the contact ID supplied to ACR may or may not be a UCID.

6.3.1 UCID Configuration

It is possible to ensure that a UCID is passed onto AACC by making some configuration changes

on the CM, as follows:

1. Verify that Universal Call Identifier is enabled and that the Network Node is a unique

node identity. Use the display system-parameters features command, at

the time of writing page 5 of 19.


2. Verify that the Universal Call Identifier is forwarded to the Adjunct Switch Applications

Interface (ASAI). Use the display system-parameters features

command, at the time of writing page 13 of 19.


3. To support Universal Call Identifier (UCID), set UUI Treatment to shared, and then

enable Send UCID. Use the display trunk-group <t1> command where t1 is

the appropriate trunk group.

With these changes, the ACR will then display the UCID.


Example with UCID steps above NOT configured

Example with UCID steps above configured


6.3.2 UCID Hex Encoded Value

The 20 digit UCID is converted to a hex-encoded value for internal use and this can be seen in

some logs including the AACC SIP log in the User-To-User field as seen in the following

example:

02/11/2012-09:14:03.197 [0x00004744] - <-- Message Received (Sender Address IP: 47.166.91.209:35808):$$begin_record

Direction: incoming

Start-Line: INVITE sip:[email protected] SIP/2.0

Record-Route: <sip:[email protected];transport=tcp;lr>

Record-Route: <sip:47.166.91.208:15060;lr;sap=-1303868404*1*016asm-callprocessing.sar-799365585~1351848928405~-590405616~1;transport=tcp>

From: "Non AACC Agent" <sip:[email protected]>;tag=802e87e7983be21a084feecec200

To: <sip:[email protected]>

Call-ID: 802e87e7983be21a184feecec200

CSeq: 1 INVITE

Via: SIP/2.0/TCP 47.166.91.209;branch=z9hG4bK2FA65BD01B6999C202141164-AP;ft=698791

Via: SIP/2.0/TCP 47.166.91.208:15070;branch=z9hG4bK2FA65BD01B6999C202141164



Via: SIP/2.0/TLS 47.166.91.209;branch=z9hG4bK802e87e7983be21a284feecec200-AP;ft=318494

Via: SIP/2.0/TLS 47.166.91.204;branch=z9hG4bK802e87e7983be21a284feecec200

Supported: 100rel,histinfo,join,replaces,sdp-anat,timer

Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,INFO,PRACK,PUBLISH

User-Agent: Avaya CM/R016x.00.1.510.1 AVAYA-SM-6.1.1.0.611023

Contact: "Non AACC Agent" <sip:[email protected]:5061;transport=tls>

Alert-Info: <cid:[email protected]>;avaya-cm-alert-type=internal

History-Info: <sip:[email protected]>;index=1

History-Info: "2041580" <sip:[email protected]>;index=1.1

Min-SE: 1200

P-Asserted-Identity: "Non AACC Agent" <sip:[email protected]>

Record-Route: <sip:[email protected];transport=tls;lr>

Record-Route: <sip:47.166.91.204:5061;transport=tls;lr>

Session-Expires: 1200;refresher=uac

User-To-User: 00FA080001183F5093914D;encoding=hex

The following explains the conversion between UCID and the hex representation on if:

Using this hex representation as an example: 00FA080001183F5093914D

The leading digits are not part of the actual UCID.

00FA means that this number that’s about to follow is a UCID ( User to USER can be

used for other types of data)

08 is the number of bytes that are about to follow (8 in this case)

sip:[email protected]

sip:[email protected];transport=tcp;lr

sip:47.166.91.208:15060;lr;sap=-1303868404*1*016asm-callprocessing.sar-799365585~1351848928405~-590405616~1;transport=tcp

sip:47.166.91.208:15060;lr;sap=-1303868404*1*016asm-callprocessing.sar-799365585~1351848928405~-590405616~1;transport=tcp



sip:[email protected]:5061;transport=tls

cid:[email protected]




sip:[email protected];transport=tls;lr

sip:47.166.91.204:5061;transport=tls;lr


0001183F5093914D is the actual UCID in Hex, broken down into 3 chunks.

0001 = 00001

183F = 06207

5093914D = 1351848269

UCID: 00001062071351848269

UCID: NNNNNCCCCCTTTTTTTTTT

NNNNN: Network Node ID (00001 to 32767) – This is a static number for either an SA

or HA configuration that will be GUI Driven.

CCCCC: Call Sequence # (00000 to 07000) – Simple call counter which will reset at

7000

TTTTTTTTTT: Timestamp: # of seconds since 12 am 1/1/1970 (Calculation based off of

the time stamp in the SIP Invite)

6.4 Configuration Tips

Note that as part of the core CM configuration, it is necessary to set up a CTI link which enables

the communication between AES and CM using add cti-link in the CM administration. As part of

this configuration, an extension number must be used.

TIP: Ensure that this extension number is configured use elsewhere on the CM system ( e.g. as

an actual station, agent etc.) and also is not configured on the ACR for bulk recording – a

misconfiguration of this nature may cause serious issues with the TSAPI operation, and hence

impact basic call recording operation.


7 NES legacy CS1k Configuration: Technical Details

7.1 NES Legacy CS1k Configuration Overview

This mode of operation refers to the legacy configuration of ACR (previously called NCR) in a

CS1k environment. In this configuration mode, the ACR CTI signaling link is via MLS. ACR

supports all the functionality of the previous NCR 7.0 product, with the exception of the CRC

(Call Recording Card), which has been discontinued.

The legacy mechanisms of recording support are:

Duplicate Media Stream – requires terminals that support the duplicate media streaming

protocol

TDM Trunk and Line Recording. Note that the previous TDM recorder application has

now been included in ACR (PCI cards are still required for this solution)

NES Legacy CS1K Configuration


7.2 cc.v6 mode

With ACR 12.x, there are a number of NES legacy features that require both AACC/CCMS 7.0

and also CS1k release 6 or later

IMPORTANT NOTE

The default operation of ACR 12.x assumes that both AACC or CCMS 7 and CS1k 6.0 (or later)

are present. If either of these two conditions is not met, then you should manually place an entry

into the ACR properties file that ensures the ACR is operating in “CC6 mode”.

The required entry is:

cc.v6=true

Note that if there are no multiDN licenses configured on the AACC, the ACR default operation

will repeatedly attempt to request licenses and this can have adverse affects on the AACC if left

in this state for a period of time. Please ensure that you have the appropriate MultiDN licenses

configured on AACC before connecting ACR in default mode of operation.

Example:

ACR properties setting Contact Center Release CS1k Release

No entry AACC, CCMS 7.0 6

cc.v6=true AACC, CCMS 7.0 5.5 or less

cc.v6=true CCMS 6 or less 6 or less

Note that when in cc.v6 = true mode, certain functionality is not available as follows:

- MultiDN recording (therefore AST licenses are required on the CS1k)

- Save/ Delete Key

- Record by Skillset.

With cc.v6 = true set, it is still possible to enable the Skillset information to be sent from AACC

to ACR (for use by Quality Monitoring) by adding the additional property setting:

cc.v6skills=true

(This capability was introduced with ACR 11 and later)

7.3 Multiple Appearance (MADN) Support

Recording of multiple appearance DN’S only works when all of the sets that are MADN’d

together actually support the duplicate media stream feature. For example you are NOT allowed

to configure TDM and IP duplicate media stream with the same multiple-appearance DN.

Multiple Appearance DN’s (MADN) can only be recorded when in Bulk Recording mode in a

knowledge worker environment. These are not supported by the Quality Monitoring application,

or the Contact Center environment.


Recording of calls made from one instance of a number to another line key on the same number

are NOT supported. The CSTA computer telephony model which underpins the call state

tracking cannot handle the same address being involved in two separate connections on the same

call.


7.4 Call Server Release 4.5 Implementation

In CS1000 R4.5, the same IP address and port number must be used for both DN’s on a physical

TN, which created some limitations with the call recording solution. However these limitations

have been resolved as a product improvement in CS1000 R5.0 and later releases. As a result of

this improvement, from CS1000 R5.0 and later, the IP address/port number can be different.

7.5 Agent Observe

This feature can be invoked from a supervisor ACD set. It is not possible to record a call that the

supervisor hears on the supervisor set using the agent observe feature. (It is of course possible

that this call is recorded on the actual agent set).

Note that is limitation also applies to the Remote Agent Observe feature, which is built upon the

Agent Observe feature.

7.6 IP Softphone Release 3

A problem Q01796067 was found on release 3 of the 2050 soft client, where call recording does

not work. This problem has been resolved in version 3.1 or later of the 2050 softphone.

7.7 Group Call Key Not Supported

Currently in CS1k there is no DN associated with a Group Call key, therefore it is not possible to

monitor this type of key via the MLS interface and hence no events are presented to the Call

recorder application to trigger call recording.


7.8 TDM Recorder Requirements and Supported Trunk Types

Note that the TDM recorder uses specific MLS content that is available with the latest software

and patch lineup for both Symposium and Communication Server 1000, therefore the minimum

software versions as described in Section 2 of this document are also applicable to the TDM

recorder.

Note also that TDM recording is limited to the following Hardware:

E1 Trunks

T1 Trunks

DPNSS Trunks

Octal Density Line cards (digital or analog)

o Only IPE Shelves for Line cards (EPE not supported)

DTI Trunks (DTI2, DTI 1.5 with either D2 or D3 frame formats) are not supported

EPE shelves are not supported

GEC Shelves are not supported.

7.9 Viewer Stitching

Note that stitching of calls in Viewer is not supported specifically for TDM recorded calls

(stitching of IP calls is supported)

7.10 Phantom DN’S

MLS does not support monitoring of Phantom DN’S, therefore Phantom DN’S should not be

configured on the Call Recorder.

7.11 Call Recording Desktop

Note that CRD can only be used with single appearance DN’S i.e. cannot be used with DN’s that

have been configured as a Multiple Appearance (MADN).


7.12 MultiDN Recording

Multi-DN recording is a feature introduced on CRQM 7.0 that requires both CS1K 6.0 or later

and CC 7.0 and all AACC versions. It eliminates the 2-key restriction on call recording that is

currently imposed by the MLS interface. With this feature, there are no longer any restrictions

on the number of keys that can be recorded on an IP terminal that supports the duplicate media

stream feature.

Multi-DN recording uses an AACC licensing mechanism whereby there is no longer a

requirement to have AST licenses on the CS1k, but instead there is a simple numerical count of

the total number of DN’s or POSIDs via the AACC License Manager.

Note that MultiDN recording is the default mode of operation for CRQM 7, ACR 10.x/ 11 / 12.

If AST licensing is required, then an optional cc.v6=true property file setting can be configured

on the ACR. Refer to section 7.2 for more information about this.

The License Key used on AACC is LM_MLSM_DN_REG

Screenshot of AACC Licence Manger

This number counts the total number of POSID’s and DN’S (including Multiple Appearance

DNS) on the CS1k that can be recorded. Hence with the introduction of this feature, the licensing

has effectively moved from an AST-based mechanism on the CS1k to an AACC License

Manager implementation (for IP call recording).

Under the Multi-DN scheme, all of the following will consume a license:

- DN

- Multiple Appearance DN


- POSID (= Position ID)

- All of the above on a Standby Call Recorder.

This feature is available only for IP Call Recording (i.e. Call Recording using the IP Phone

duplicate media stream feature). For TDM recording, AST licenses are still required as per older

NES legacy CRQM 6.5 operation.

Note: Customers can continue to use the AST licensing mechanism even for IP terminals if they

wish – this would usually be in a scenario where the customer does not have a need to record

more than 2 keys per phone. Keep in mind that these features are mutually exclusive and

therefore you should use either AST or MultiDN licensing.

The default installation on ACR 12.x will assume a MultiDN licensing model.

It is important to note that when MultiDN recording is used, it is a mandatory requirement to

have sufficient licenses on the AACC server to handle all of the IP DN’s/POSID’s being

recorded. For example if you have 50 IP terminals each with 4 DNS to be recorded, then a total

of 200 MultiDN licenses are required. For IP terminals, it is not possible to mix AST and

MultiDN licensing. Thus if a customer already has AST licenses for their IP Phones but wish to

move to a MultiDN licensing configuration (usually because they want to record more than 2

keys per phone) then they must procure enough MultiDN licenses on AACC to handle all of the

IP DN’s being recorded. One exception to this case is when the installation has both TDM and IP

terminals. For the TDM terminals only AST licensing is currently supported, therefore the

AACC will allow this to co-exist with the MultiDN licensing for IP terminals (However it is not

allowed to have the same multiple appearance DN (MADN) configured on both an IP and a

TDM terminal.

Alternatively customers who have already purchased AST licenses for their IP terminals can

continue to use these licenses by configuring the ACR into “CC6” mode – essentially this makes

it behave as an older CRQM 6.5 system and it will only perform the normal AST registration.

This is configured by adding the following line into the ACR properties file

cc.v6=true

This setting effectively turns off the MultiDN capability on the ACR.

Some examples of MultiDN licensing are provided below:

Example 1:

The ACR master registers for 10 DNS, each of which has 4 appearances.

=> The total AACC license count required is 10 x 4 = 40

Example 2:

The ACR master registers for 10 DNS, each of which has 4 appearances. The ACR

Standby registers for the same set of DN’s. The license count for the Master is 10x4 = 40

and the license count for the Standby is also 40.

=> The total license count required is 80

Example 3:


The ACR master registers for 10 POSIDS and 10 DNS. Each of the DN’s has 4

appearances. The ACR Standby registers for the same set of DN’s and POSIDS. The

license count for the Master is 10 + 10x4 = 50 and the license count for the Standby is

also 50

=> The total license count required is 100

7.13 Record on Demand

The ROD key provides an IP Phone user with the ability to manually start and stop recording of

a call using a key on the Phone.

The ROD key offers a “toggle” operation – this means that after initially hitting the key to start

recording, the same key can then be used to stop recording. This process can continue during the

call, resulting in several call recording segments based on the key sequence from the user.

The ROD key has an associated LCD ICON that displays the status of recording. When the LCD

telephone ICON is lit, the call is being recorded (and therefore not under recording when unlit).

This feature requires specific configuration on the Call Recorder on a per-user basis.

This feature requires a minimum of CC 7.0 or AACC, CS1k 6.0 and CRQM 7.0, WFO

10.1,WFO 11 or WFO 12.x

Note: The ROD key is intended only for use where the far end phone is not under control of the

same Call Recorder. If both parties on a call are under control of the same Call recorder then the

feature will not function correctly as there may be conflicts between what the near end and far

end phones are trying to achieve. The Call Recorder will recognize that both parties are on the

same call and will stream from one of these terminals (this optimizes bandwidth and CPU and is

also consistent with the CS1k Call recording solution).

Note: ROD is only applicable to DN’s/POSID’s that are configured for bulk recording on the

ACR (not on QM) - this is the same as per CRD operation (Contact Recording Desktop)

Note: CRD/ROD/SAVE features are mutually exclusive for the same DN, so if CRD is already

being used, then ROD/SAVE should not be used as there may be conflicts with these two

features trying to control bulk recording. Similarly, you should only configure either ROD or

SAVE for the same DN but not both.


The recommended settings for ROD on the ACR are as follows:

There is an on/off key code (LM_MLSM_ROD_REG) on the AACC License Manager that

enables this feature. Thus only one license is used regardless of the number of users.


7.13.1 Record On Demand: CS1k Configuration

7.14 Save Conversation

The SAVE key provides the phone user the ability to retrospectively record the entire call,

provided they invoke the feature while the Call is still active. For example, if a user decides in

the middle of a call that they would like to save the entire call, this is possible using the SAVE

key.

The SAVE key, also provides a “toggle” operation, similar to the ROD Key. In this case, the

status of the entire call toggles from status “Entire call will be saved” to “Entire call will NOT be

saved”.

The SAVE key has an associated LCD that displays the status of recording. When the LCD is lit

during the call, this means that the entire call will be saved by the call Recorder. If the LCD is

dark, this means that the entire call will not be saved.

This feature requires specific configuration on the Call Recorder on a per user basis.

This feature requires a minimum of CC 7.0, CS1k 6.0 and CRQM 7.0

Note: The SAVE key is intended only for use where the far end phone is not under control of the

same Call Recorder. If both parties on a call are under control of the same Call recorder then the

feature will not function correctly as there may be conflicts between what the near end and far

end phones are trying to achieve. The Call Recorder will recognize that both parties are on the

same call and will stream from one of these terminals (this optimizes bandwidth and CPU and is

also consistent with the CS1k Call recording solution).


Note: The SAVE is only applicable to DNs/POSIDs that are configured for bulk recording on

the ACR (not on QM) - this is the same as per CRD operation (Contact Recording Desktop)

Note: CRD/ROD/SAVE features are mutually exclusive for the same DN, so if CRD is already

being used, then ROD/SAVE should not be used as there may be conflicts with these two

features trying to control bulk recording. Similarly, you should only configure either ROD or

SAVE for the same DN but not both.

.


The recommended settings for SAVE on the ACR are as follows:

AS in the case of ROD, the SAVE Functionality is also enabled by the on/off key code

(LM_MLSM_ROD_REG) on the AACC License Manager. Thus only one license is used

regardless of the number of users.


7.14.1 Save Conversation: CS1k Configuration

7.15 Secure Call Recording

Below are some useful points regarding the configuration of the secure call recording feature.

Please also refer to the NTP’S for more detail.

7.15.1 Secure Call Recording impacts on ACR Server Performance

With secure call recording enabled, the concurrent channel capacity of the ACR Server will be

reduced by approximately 10% when compared to a non secure call recording installation.

7.15.2 Provisioning Server Setup

1. Create a folder on a server – for example: TFTP.

2. Copy 2 files system.prv and Tftppd32.exe to the folder TFTP.

3. Modify the system.prv file with following lines:

st=y;

mscr=y;

callrec=N

The meaning of the above parameters in system.prv file is as follows:

mscr=y: Mirror Mode encryption Setting: This basically means that the DMS will be the

same as primary stream. If the primary stream is encrypted, the DMS will be too. If the primary

stream is not encrypted, neither will the DMS.


Callrec=N

This identified the Call Recording Vendor: N = Avaya Call Recorder

4. Run the Tftppd32.exe (remember to keep the window open or else it wont work. As the IP sets

reboot, you should see dialog windows flashing up on the TFTP server, and they will pickup the

system.prv).

7.15.3 IP Phone Setup

1. On IP phone, double-press on Services button and open Network configuration.

2. Also in Network Config, scroll down to Provisioning, and enter IP of the TFTP server. Note

that when entering “.” (dot) for IP, press double “*”.

3. Press apply.

4. On the CS1000, change the TN configuration at LD 11: CLS MSBT (Media Security Best

Try)


7.15.4 Signalling Server Setup:

1. Go to Element Manager. Under Security->Policies->Media, you must first check the “Media

Security” option and from the drop down list which appears, select MSBT.

2. Select parameters as per the screenshot above and click Submit.


3. Upload firmware to Signaling server by navigating to the page:

4. Select phone type and click Update


5. Browse to firmware file and click Upload.


6. Click Update to update the firmware

7. When completed, restart the phone set. When the phone comes up, it will download the

firmware from the signaling server.


7.15.5 NES Call Recorder Setup

Ensure that the ACR is licensed to support encryption by checking the System->License

Window – see example below:


7.15.6 How To Check if Secure Call Recording is Enabled

Configuration required to log into phone set:

1. From set->Local Diagnostics->Advanced Diag Tools. (On the 1140E set, this menu is

accessed by double clicking on the “Globe” button)

2. Check the “Enable SSH” check box

3. Enter UserID: xxxx ( on 11xx phones, the central navigation button enables edit

mode)

4. Enter password: xxxx

5. Press Apply

(Alternatively if you are using a provisioning Server, this User ID and password may already be

defined in the system.prv file.)

To view secure call recording status:

1. Use putty SSH to log into the set, using the User ID and Password defined in previous

step.

2. Make a call to the set

3. From pdt command, type scrShow (note “scrShow” is case sensitive) and you will see

something like this:

PDT> scrShow

Secure Call Recording Setting and Status

CR Vendor: Nortel call recorder

SCR license: Granted

NT shared secret: valid

Mirror Mode Setting: Same as primary stream

UNIStim Encryption Setting: Not set

SCR Info for Rx duplicate stream:

SCR session: Active

SCR state: SCR_STAT_SUCCESS

DTLS state: SCR_DTLS_STAT_SRTP_ESTABLISHED

Source Port: 12000

Remote Port: 10992

Remote IP: 10.30.4.28

SCR Info for Tx duplicate stream:

SCR session: Active

SCR state: SCR_STAT_SUCCESS

DTLS state: SCR_DTLS_STAT_SRTP_ESTABLISHED

Source Port: 12100

Remote Port: 10994

Remote IP: 10.30.4.28

PDT>


7.15.7 Unistim 5.3

With unistim version 5.3, there is a new DTLS handshake mechanism that is used as part of the

secure call recording feature which requires additional functionality in the ACR to handle the

new handshake.

If you are using Unistim 5.3 and Secure Call recording then you must:

- use at least ACR 10.1 or later (CRQM 7.0 does not support the new DTLS handshake), with

a minimum patch level of 101055 or higher

- Manually insert the following entry into the ACR properties file:

dtls.nonstandard=2

This property file setting is required as the default operation on the ACR is to use the older

(pre=Unistim 5.3) DTLS handshake mechanism


8 Proactive Outreach Manager Integration

8.1 Introduction

This section provides some background on the ACR 12.x / POM integration and also some

specific configuration information required for this solution.

ACR POM integration is supported with the following lineup:

POM 3.0.1 and patch POM301GAPatch4.zip

o Note for multi-zone support with ACR, a minimum of POM301GAPatch8.zip is

required

ACR 12.0 with Patch ACR120088 or later (any version of ACR12.1 will suffice)

CS1000 7.6 SP5 and Patch MPLR33345 or later equivalent

CM – No specific restrictions (refer to the WFO interoperability matrix for supported

versions of CM with ACR 12.0)

AACC 6.4

8.2 POM and ACR Architecture Overview

The POM dialer is a managed application installed on top of the base Avaya Aura Experience

Portal (AAEP) platform, and in particular it uses the platform level MPP media server

component to implement SIP/RTP/conferencing functionality.

POM interoperation with the CM or CS1000 switch is purely based on SIP messaging (via

Session Manager). From this perspective, POM is switch agnostic – it is not really aware what

type of switch it is interacting with, as all of the SIP messaging traverses through the Session

Manager component.

Figure 9.1: POM to Switch Interface

ACR integrates with the POM application via a new POM/ACR interface which provides real

time call event information to the ACR, in addition to Agent Acquire and Agent

deAcquire events. Simultaneously ACR also maintains its existing CTI links like TSAPI &

Web services on CM, and MLS on CS1000.

There are 3 supported system configurations with ACR, as follows:

POM and CC-Elite

POM and AACC in a CM environment

POM and AACC in a CS1000 environment (AML only, AACC-SIP is NOT supported)


Fundamentally, all of these have a similar architecture, but there are some small differences in

terms of the configuration required, which is documented in later sections.

Figure 9.2: POM and CC-Elite

Figure 9.2 shows the POM and CC-Elite solution with ACR integration also included. In this

model, ACR has a CTI link to POM, and also a TSAPI/DMCC link to AES.

Initially an Agent logs into POM via their desktop client interface. Once a POM campaign is

started, the POM application creates a nailup call (using a SIP INVITE via SM) to the POM

agent’s telephone set and at the same time ACR receives AgentAcquireEvent via the POM

Interface which signals that the call is in fact a nailup. ACR creates a single sided call model

which shows up on the ACR CTI monitors page, but it does not start recording at this point (a

‘single-sided call’ has only one established connection therefore fails the "is it recordable" test,

similar to an off-hook condition, or a call with one party established and the other on hold)

Now that the campaign has started, POM creates outbound calls to customers (again using SIP

INVITES) and as a customer answers the call, they are immediately connected to a nailed up

POM agent via the platform level media server MPP component on POM. Thus POM/MPP acts

as a sort of ‘back to back’ component that joins two separate physical calls (customer call+ agent

nailup call) together in a single conference.

Once POM connects a customer to the nailed-up agent, this is signaled to ACR via the POM

interface (MediaInfo event) and recording is started by the ACR. All physical recording is

implemented via the existing DMCC protocol and single step conferencing mechanism, unless

there is passive tap or TDM extension side tapping present in which case those mechanisms

would be used instead. The ACR does NOT attempt to create a separate stream to the POM/MPP

component.

If either the customer or the agent hangs up, this is signaled to the ACR as a MediaComplete

event, which is then used as a trigger by the ACR to stop recording.


For more complex call scenarios where a POM agent conferences in a 3rd

party onto a call, a new

MediaInfo is sent which contains a update of all of the parties on the call including their status

(e.g. Active / Hold)

Figure 9.3: POM and AACC on CM

Figure 9.3 shows a similar architecture for the POM and AACC solution with CM. The operation

of this configuration is essentially the same as previously described for CC-Elite. As before, all

recording of POM calls is implemented via DMCC recording, unless there is passive tap or TDM

extension side tapping present in which case those mechanisms would be used instead. And if a

POM call is transferred for example to a CDN, then that final call leg will be recorded via AMS

SIP recording as the POM agent nailup leg is no longer involved in the call.

Note that ACR now has an additional CTI link to AACC via CCT Web Services which is

required as part of a normal AACC/ACR integration. Additionally with this configuration,

AACC+POM support a feature called blending, whereby an agent logged into POM can be

dynamically moved back to handle inbound AACC calls if the inbound traffic level increases.

When this happens, ACR receives a deAcquire message from the POM application and the

nailup call is torn down. If the agent is subsequently blended back into an outbound campaign,

ACR then receives an associated acquire message which signals that the POM nailup call has

been re-instated.

Note that in both the CC-Elite and AACC/CM solutions, it is important that the POM

application is configured to generate a unique UCID (Universal Call ID) as this is used by the

ACR to associate the call events that it receives from POM with related call events from the

TSAPI or AACC Web Services interface. This is described later in the configuration section.


Figure 9.4: POM and AACC on CS1000

Finally, the architecture for a POM + AACC solution with CS1000 is shown in figure 9.4.

Again, the basic operation is the same as per the previous 2 configurations, but in this case the

physical recording is via the CS1000 IP recording mechanism (duplicate media stream), unless

there is also extension side TDM recording present in which case that would be used.

In the case of CS1000, it is not possible to use the UCID mechanism for correlation of calls,

however the configuration of POM is modified to account for this fact, specifically in the context

of the caller identification (ANI=Automatic Number Identification) that is used for any external

consult calls.

Specifically this solution is only supported with the latest release of CS1000 (7.6 SP5) and also a

specific patch is required (MPLR33345) which ensures that the correct caller identification is

provided to the ACR via MLS during external consult call scenarios.

Note that in the CS1000 configuration, POM makes the nailup call to the Agent’s secondary DN

(not the Position ID)

8.2.1 Consult Call Scenarios

If a POM agent wishes to involve a 3rd

party onto a customer call (or perhaps transfer a call) then

the agent must invoke this consultative call via their desktop (they should NOT place their nailup

on HOLD)

Physically, this consult call has 2 different possibilities:

Internal Consult Call: The agent may invoke an internal consultative conference or transfer. This

means that they are initially consulting with another POM agent who is also nailed up to POM.

The POM agent will initiate this via their desktop client where they can see a dropdown list of all

of the available POM agents. At a system level, no new call legs are created, because both of the

agents involved are already nailed up to POM. So the process is implemented internally to POM,


whereby the MPP conference has the customer placed on HOLD and simultaneously provides an

active audio path between the 2 agents.

External Consult Call: In this case, the POM agent wishes to conference/transfer a 3rd

party that

is not nailed up to POM, for example a supervisor, knowledge worker or an inbound agent etc.

As per the previous case, the POM agent must initiate the consultative call via their desktop

client, however in this case they initiate an external consult call. This results in the POM

application generating a new call into the CM or CS1000 Switch. This process is shown in

figure 9.4 below

Figure 9.5: POM Call Legs Including External Consult

The external consult call leg is shown as ‘Call Leg 3’ in the above diagram.

The importance of this from an ACR perspective is that the consult call leg may eventually land

on a station that the ACR is has already targeted for recording, and in this case it needs to

determine that the call from the POM Agent is indeed the same call that lands on the 3rd

party

who is being consulted. Refer to the later section on POM configuration, which provides the

necessary detail in this regard, and specifically the parameter ‘ANI for external consult calls’, as

there are differences between how this should be configured for a CM versus CS1000.


8.3 POM Configuration The following configuration is necessary on the POM application for correct integration with

ACR.

Generate UCID:

Navigate to System Configuration / Applications. Edit both POMDriverApp

and also Nailer applications so as to enable ‘Generate UCID’.

The UCID (Universal Call ID) is critical for correct operation of the ACR application when

integrated with POM, as it uses this parameter on CM systems to correlate call events on the

TSAPI and AACC web services interface with the associated call events it receives from POM.

For example when a POM agent initiates an external transfer to a knowledge worker who is also

being recorded, ACR uses the UCID parameter to determine that they are both on the same call.


P-Asserted Identity:

Navigate to System Configuration/VoIP Connections and select the relevant SIP

Connection.

This is an optional parameter on the base Avaya Aura Experience Portal platform (AAEP). Note

that it is not mandatory from an ACR perspective, however if there is P-Asserted

Identity value configured, then please ensure that the Nailup Call CLID value is set

to the same value as the P-Asserted Identity. Additionally please check that the P-Asserted

Identity value is unique from a CM number space perspective, similar to requirement

outlined previously for the Nailup Call CLID.


Enable WFO and WFO Port:

To enable ACR connectivity to POM, navigate to POM/POM Home/Configurations

/Global Configurations

Enable WFO checkbox should be checked

WFO Port value must be configured. (The default value on ACR is 7999, but this can be

changed if required)

Nailup Call CLID:

Navigate to POM/POM Home/Configurations/Global Configurations and then

scroll down to the Agent Settings area of this page to configure this value.

This is a mandatory value, and is used by ACR to identify the POM application as the originator

of call, for example a nailup call to an agent, or an external consult call to any party the ACR

may be interested in recording.

Ensure that the Nailup Call CLID is set to a unique value that does not overlap with any

other numbers on the Switch (CM or CS1000) numbering plan, so that ACR will not confuse the

POM application with other stations/Agents/VDN’s/CDN’s/etc.


Override PAI for External Consult Calls:

Navigate to POM/POM Home/Configurations/Global Configurations

and then scroll down to the Agent Settings area of this page to configure this

value.

For the ACR/POM/CM configurations (either with AACC or CC-Elite) leave this box

UNTICKED.

For the ACR/POM/CS1000 configuration, ensure this box is TICKED

ANI for external consult calls:

Navigate to POM/POM Home/Configurations/Global Configurations

and then scroll down to the Agent Settings area of this page to configure this

value.

For the ACR/POM/CM configurations (either with AACC or CC-Elite) select radio button

‘Nailup call CLID’

For the ACR/POM/CS1000 configuration, select ‘Agent Extension’


8.4 ACR Settings for POM Integration

8.4.1 Licensing

Note that for POM operation, ACR must has a ‘Third Party dialer integrations’ license.

8.4.2 ACR Configuration for POM

8.4.2.1 Property Settings

Unless otherwise stated, all of the items below are applicable to all configurations (CM or

CS1000)

A specific new property entry sessions.ignored is required on ACR and it should be set to

the same value as the Nailup Call CLID value that is configured on the POM Application for all

POM configurations (CM or CS1000)

Example:

sessions.ignored=98765

Where 98765 is the value use for the Nailup Call CLID.

Specifically in the case of the CS1000 AACC-AML configuration, the following property setting

is also required:

mls.unknownmaybeinternal=true


Specifically in the case of the POM CM configurations (AACC or CC-Elite), the following

property setting is also required:

tsapi.ePUmaybeinternal=false

Do NOT use the properties entry POM1.blockagentids (This is now obsolete and is no

longer used)

For detail logging of the ACR to POM interface, the follow optional Properties can be used:

POM1.tracing=true

(Note we are using the specific dialer prefix, in this case POM1)


8.4.2.2 ACR Data Source Configuration

With the addition of the Data Source concept, a number of the POM configuration items that

previously needed property file entries are now available on the ACR GUI

Refer to the ACR 12.1 PIA guide which provides all the necessary details for configuring a POM

Data Source.

Note that for multi-zone operation, the value for the Zone should be ‘all’ (this is not case

sensitive). When this zone value is used, the POM server to which ACR is connected will send

call events to the ACR for all of the zones that it (the POM server) is processing.

Alternatively a specific zone value could be entered, but in this case the POM server will only

send events to ACR for that particular zone. Usually the call recording requirement will not be

zone-specific, and so in most cases is recommended to use the ‘all’ zone parameter. For thi

IMPORTANT: A minimum of POM patch POM301GAPatch8.zip is required for this ‘all’

parameter to operate correctly.


8.5 WFO Configuration for POM Integration

If additional applications (like Quality Monitoring) are being used as part of the POM/ACR

solution, then some specific configuration is required. This section documents the aspects of

WFO configuration that are relevant to POM for all of the 3 system configurations: (a) POM and

CC-Elite (b) POM and AACC on CM (c) POM and AACC on CS1000. Additionally some

information is also provided regarding screen recording configuration, although this is not

specific to the POM integration.

Refer to the ACR ‘Integration to Workforce Optimization Guide’ for general information about

setting up WFO with ACR.

8.5.1 POM and CC-Elite on CM

CM Datasource:

Under System Management/Datasources, configure a CM datasource as per normal

procedure when setting up QM for a CM environment, as follows:

Create a datasource of type ‘Phone’. Switch/Sub Type=Avaya Communication

Manager/Definity. The name of this datasource must match the value for ‘Avaya

Communication Manager Name” configured on the ‘Contact Centre Interface’ page on

ACR.

This datasource can be ‘Fixed’, ‘Free’ or ‘Hybrid’

Add all the station numbers that Agents are using under the ‘Phones’ tab

Add the CC-Elite agent IDs under the ‘Agents’ tab.

- Note that the POM agent ID should always be the same as the CC-Elite agent ID

POM Datasource:

Create a datasource of type ‘Dialer’. Switch/Sub Type = Avaya PDSManager/Definity.

- Note: The name of this datasource must match the POM dialer datasource name used in

ACR.

This datasource can only be ‘Free’ seating

Add the agent IDs under the ‘Agents’ tab for any agents that may potentially be logged into

the POM application

Do NOT add any station numbers into the ‘Phones’ tab

LAN Datasource (if required)

Create a datasource of type ‘LAN (Screen)’

In the ‘Workstations’ tab:

- Add the Computer host name

- Use the previous CM Datasource in the ‘Phone Data Source’ dropdown box

- If fixed seating arrangement, add the station number in the ‘Extension’ field

- If free seating arrangement, do NOT add the station number in the ‘Extension’ field (Click

OK when WFO flags this in a popup window)

If using Free Seating, in the ‘Employees’ tab map the agents Windows user domain name in

the from domain\user e.g. uklab\user1 to the employee on this datasource

Screen recording should not be configured on the ACR if added to WFO per the above

configuration details


8.5.2 POM and AACC on CM

CM Datasource:

Under System Management/Datasources, configure a CM datasource as per normal

procedure when setting up QM for a CM environment, as follows:


Manager/Definity.

- Note: The name of this datasource must match the value for ‘Avaya Communication

Manager Name’ configured on the ‘Contact Centre Interface’ page on ACR.

This datasource can be ‘Fixed’, ‘Free’ or ‘Hybrid’

Add all the station numbers that Agents are using under the ‘Phones’ tab

- Do NOT add the agent IDs under the ‘Agents’ tab. These will be added into the

AACC datasource

Create an AACC Datasource:


Manager/Definity.

- Note: The name of this datasource must match the value for ‘CCT Server’ configured

on the ‘Avaya Aura Contact Centre Interface’ page on ACR.


Add the agent IDs under the ‘Agents’ tab for all AACC agents

- Note that the POM agent ID should always be the same as the AACC Agent ID


Create a POM Datasource:


- Note: The name of this datasource must match the POM dialer datasource name used

in ACR.



the POM application












Screen recording should not be configured on the ACR if add to WFO per the above



8.5.3 POM and AACC on CS1000

Only the AACC-AML configuration is supported on CS1000

CS1000 Datasource:

Under System Management/Datasources, configure a CS1000 datasource as per normal

procedure when setting up QM for a CS1000 environment.

Create a datasource of type ‘Phone’. Switch/Sub Type=Nortel

CS1000/Meridian1/Succession.

- Note: The name of this datasource must match the value that is entered under Contact Center Interface/Avaya Contact Center Manager Server

Address(es) field on the ACR. (This is because the logical link to the CS1000 is

always via the AACC physical MLS link for an AACC-AML configuration)

This datasource can be ‘Fixed’, ‘Free’ or ‘Hybrid

Add all the position ID’s that are being used under ‘Phones’ tab as the Primary

Extension and add the secondary DN for that same phone into the associated

Secondary Extension field.

Add the AACC agent IDs under the ‘Agents’ tab.

- Note that the POM agent ID should always be the same as the AACC Agent ID

Create a POM Datasource:


- Note: The name of this datasource must match the POM dialer datasource name used

in ACR.



the POM application












Screen recording should not be configured on the ACR if add to WFO per the above



8.6 Limitations

8.6.1 Complex Call Scenarios

In a typical POM environment, agents are generally in conversation with a customer in a 2 way

call. However they may be scenarios where an agent wishes to consult with a 3rd

party (for

example an expert or a supervisor) and they may also choose to conference this 3rd

party into the

customer call. It is critical that a POM agent uses their desktop client to implement these types of

conference or transfer call scenarios and hence they should NOT place their physical telephone

on HOLD, as it is involved in a static nailup call that persists for the duration of the POM

campaign.

If the nailup is placed on HOLD, the POM application is not aware of this, and this can have

negative implications for the ACR application that is monitoring POM events. Therefore ACR

does not support any call scenarios where an Agent puts their nailup call on HOLD, including

scenario like making or receiving a call on a 3rd

line while the nailup call is on HOLD. This type

of call activity can result in indeterminate information being sent to the ACR application and can

therefore impact the accuracy of the resultant recordings.

Additionally having a nailup call on HOLD without POM’s knowledge can also have negative

impacts on the POM application itself, as it thinks that it has an active audio path to the agent for

potential outbound customers.

Also refer to wi01186215 in section 11 which is a temporary limitation in regard to external

transfer scenarios.

8.6.2 CS1000 Release and Relevant Patches

ACR POM integration in a CS1000 environment is only supported with:

Latest release of CS1000 (currently 7.6 SP5)

Patch MPLR33345 is also required which ensures that the correct caller identification is

provided to the ACR via MLS during external consult call scenarios.

The Route Data Block (RDB) NCRD (Network Call Redirection display update) setting

on the CS1000 systems must be set to YES to allow correct operation of Patch

MPLR22203 which ensures that MLS will communicate the correct far end party

information to ACR in external transfer scenarios. Additionally if there are networked

CS1000s, then NCRD must be set to YES on all of these systems.

8.7 POM Multiple Zones

A minimum of POM patch POM301GAPatch8.zip is required for multi-zone operation to

function correctly. Also, ACR must use the ‘all’ zone parameter in its POM datasource

configuration


9 ASBCE Integration Details

9.1 Introduction

This section provides some background on the ACR 12.1 / Avaya Session Border Controller for

Enterprise (ASBCE) integration via SIPREC and also some specific configuration information

required for this solution.

ACR ASBCE integration is supported with the following lineup:

• ASBCE 7.00.00

• ACR 12.1

• CM – No specific restrictions (refer to the WFO interoperability matrix for supported

versions of CM with ACR 12.1)


9.2 ASBCE ACR integration via SIPREC Overview

The Session Recording Protocol (SIPREC) relies on SIP, SDP and RTP to record a call. All

recording session occurs between a Session Recording Client (SRC) and a Session Recording

Server (SRS) specific to a of a communication session (CS) that passes through an SBC and

between multiple user agents.

In the solution described here the SRC is the Avaya SBCE and the SRS is the WFO 12.1 ACR.

Figure 10.1: SIPREC Overview

The ACR-ASBCE recording solution is available in the following Avaya contact centre

configurations:

CC Elite / CM

AACC 6.4 SIP / CM

See diagrams below for high level overview of the architecture of both of these configurations.

Currently support for CS1K configurations is not be available with the ACR-ASBCE SIPREC

integration.


9.2.1 AACC-CM Architecture

DMCC & TSAPIACR

AES CM

G450

Phone

Agents

SIPREC

Desktop

ASAI

RTP

RTP

RTP

Audio over RTP

- DMCC initiated RTP

- SIPREC initiated RTP ACR – Avaya Contact Recorder

SM – Session Manager

CM – Communications Manager

AES – Application Enablement Server

SBC – Session Border Controller

AMS – Avaya Media Server

AACC – Avaya Aura Contact Center

SBC

RTP

SMSIP

TR87

AACC

SIP

AMSRTP

- AACC initiated RTP

CCT

RTP

RTP

RTP

Figure 10.2: ACR SIPREC recording via SBC on AACC/CM


9.2.2 CC-Elite Architecture

DMCC & TSAPIACR

AES CM

Elite

G450

Phone

Agents

SIPREC

Desktop

ASAI

RTP

RTP

RTP

Audio over RTP

- DMCC initiated RTP

- SIPREC initiated RTP ACR – Avaya Contact Recorder

SM – Session Manager

CM – Communications Manager

AES – Application Enablement Server

SBC – Session Border Controller

SBC

RTP

RTP

SMSIP

SIP

Figure 10.3: ACR SIPREC recording via SBC on CC-Elite/CM

Note that although the SIPREC messages can be transported via UDP and accepted by the ACR,

TCP is strongly recommended as it is a reliable transport mechanism.


9.2.3 Hybrid Recording

ACR 12.1 includes SIPREC recording in its hybrid recording model. This means that it takes

feeds from a number of Data Sources and decides to record or not based on an amalgamation of

data from these Data Sources.

If a TDM tap is present and configured on the extension taking the call, it will take priority over

SIPREC recording. (This is currently fixed as highest priority on the grounds that such a tap is of

no use to any other call at that time so should be used in preference to shared resources such as

used by DMCC, SIP etc.).

Internal calls do not pass through the SBC and so cannot be recorded via the SBC. The ACR

will use SIPREC in preference to other IP recording modes when invited to do so by the SBC.

However the ACR will automatically fall back to other means of recording calls that it has not

been invited to record via SIPREC. In an Elite contact center this will be via DMCC recording.

In an AACC SIP/CM environment this will be by the standard AACC hybrid approach. i.e.

Firstly via AMS conference if possible and then via DMCC.

The hierarchy of recording methods employed in the ACR hybrid model is as follows:

i. TDM Station Side Tap

ii. TDM Trunk Side Tap / SIPREC

iii. Passive IP

iv. AMS Conference

v. DMCC

IMPORTANT POINT: SIPREC recording is only possible when the call path traverses the SBC,

therefore the ACR cannot use SIPREC in many scenarios e.g. internal calls or calls that access

the PSTN through a different non SBC route. For this reason it is very important to provision

sufficient DMCC ports on the ACR to handle the non SBC call traffic. The quantity of these

DMC ports required is therefore dependent on the traffic patterns for each site involving non-

SBC calls.

On a CM switch outbound dialer calls that are to be recorded are recorded via SIPREC unlike

outbound dialer calls in a non-SBC environment which are recorded via CM/DMCC.

IMPORTANCE OF UCID: One the fundamental mechanisms

9.2.4 Alternate Routing / Scalability

ASBCE supports alternate routing and scalability by configuring multiple ACRs in the ASBCE

and by setting the Routing policy to ‘Round Robin’.

“Round Robin” is the only routing policy that ASBCE supports for multiple ACRs.

The ASBCE does not have the concept of Master, Standby, and Slave recorders. As far as the

ASBCE is concerned all ACRs are the same. On the ACR side they will be treated as normal as

Master, Standby or Slaves.

In a scenario where all ACRs are operating normally the ASBCE will route each call to the next

ACR.


Where there is a requirement for multiple ACR’s it is normal to configure a

Master/Slave/Standby cluster. While it is technically possible to configure multiple standalone

ACR’s this is not envisaged to be used in a production setting unless there is a very specific use

case where it might be required.

9.3 ASBCE Configuration

The following configuration is necessary on the ASBCE application for correct SIPREC

integration with ACR.

9.3.1 Licencing

ASBCE licensing must be in place for additional ports that are required for SIPREC. Refer to the

ASBCE documentation for details.

9.3.2 Server Configuration 1. Global Profiles -> Server Configuration

2. Enter a Profile Name and click Next

3. Set Server Type as ‘Recording Server’.

4. Provide IP Address, Port number and appropriate transport for Recording Server

5. Enable heartbeat with OPTIONS

Set timer for frequency of sending OPTIONS. Set From and To URI for SBCE and

Recording Server


6. In Advanced tab, enable grooming. Set interworking profile as “avaya-ru”

7. Repeat for each ACR to be configured.

9.3.3 Routing Profile 1. Global Profiles -> Routing Profiles -> Add

2. Enter name for Routing Profile -> Click Next

3. Load Balancing

• Single ACR – Priority

• Multiple ACRs – Round-Robin

4. Server configuration -> Select Recording Server which was added section 9.3.2. Repeat

for each ACR configured.

Click Finish


9.3.4 UCID for Recording Server 1. Navigate to Domain Policies Signaling Rules

2. Select Signaling Rule that SBCE must use for Recording Server

3.

4. Navigate to “UCID” and edit to enable check box, Node ID as 1 and Protocol

Discriminator as 0x00


9.3.5 Session Policies 1. Domain Policies -> Session Policies -> Add

2. Enter Policy Name Click Next

3. Preferred codec #1 , #2 to be selected for PCMU (0) , G729(18) based on preference

4. Go to Media tab

5. Enable Media anchoring and Recording Server

6. Recording Type = Full Time

7. Check ‘Play Recording Tone’ to ASBCE to generate an indication to customer

8. Set Routing Profile as Routing profile created above for ACR

9. Click Finish


9.3.6 Session Flows 1. Device Specific Settings -> Session Flows -> Add

2. Enter Flow Name and select Session Policy which was created above

9.3.7 Server Flows 1. Device Specific Settings -> End Point Flows -> Server Flow -> Add

2. Add a Server flow for each ACR configured.

3. Enter Flow name and select ACR Server configured earlier.

4. Received Interface is External i.e. the one used towards Service Provider for SIP Trunk

5. Signaling Interface & Media Interface is Internal i.e. the one used towards Session

Manager

6. Routing Profile is default i.e. the one with no IP Address in the profile


7. Ensure the following settings of the Application Rule of the End Point Policy Group of

the Server Flow of the ACR are configured to support an adequate number of

sessions/endpoints:

Maximum Concurrent Sessions

Maximum Sessions Per Endpoint


9.3.8 Secure Recording

ACR will automatically use encrypted media streams if the ASBCE is configured to do so. As

the keys for these streams are exchanged via the SIP signalling path, the recorder will alarm

periodically if this has not also been secured using TLS.

9.3.8.1 SRTP Setup

AES_CM_128_HMAC_SHA1_80 encryption and authentication algorithm is supported.

No configuration is required on the ACR side to enable SRTP.

On the ASBCE side ensure that the Media Rule of the End Point Policy Group of the Server

Flow of the ACR is configured to the correct encryption and authentication algorithm. An

example of an End Point Policy Group with a Media Rule using

AES_CM_128_HMAC_SHA1_80 is given here.

9.3.8.2 TLS Setup ACR acts as the server in the TLS exchange between the ACR and the ASBCE. The following

steps are required to generate and exchange certs between ACR and ASBCE.

1. Generate CSR on ACR

2. Sign ACR CSR on CA

3. Import signed ACR CSR into ACR keystore

4. Import CA root cert into ACR keystore


5. Import CA root cert into ASBCE keystore

See PIA guide for instructions on steps 1, 3 and 4 above.

Follow the instructions below for importing certs into ASBCE, step 5 above.

9.3.8.2.1 Importing Certs into ASBCE

1. TLS Management -> Certificates -> Install

2. Select CA Certificate

3. Browse to CA Root certificate location and select cert

4. Press upload

9.3.9 Selective Recording

While SIPREC Selective recording is not supported in the ACR 12.1-ASBCE 7.00.00 integration

a possible workaround to ACR having to process RTP for all calls that traverse the SBC is to

make use of the ASBCE Session-Flow configuration.

Session Flows can be configured to only send flows to the ACR where a To or From header of

the A-B call match a pre-defined rule.

These rules are defined as follows:

1. Global Profiles -> URI Groups

2. When creating a new URI group, refer to the following table:

Name Description

URI Type Plain – Common SIP URI

Dial Plan – Valid SIP Dial Plan

Regular Expression

URIs Plain Format:

Examples:

*@192.168.15.12

mailto:*@192.168.15.12


*@avaya.com

Dial Plan:

Please note that domain portion of the URI is a regular expression and

should be escaped accordingly. Examples:

9555XXXX@.*

9555NXXX@avaya\.com

\*69@domain\.com

011*@.*

Regular Expression:

Note: This regular expression is case-insensitive. Examples:

[0-9]{3,5}\.user@domain\.com

(simple|advanced)\-user[A-Z]{3}@.*

To assign these rules to the required ACR Session Flow:

1. Device Specific Settings -> Session Flows

2. Click Edit on the required ACR Session Flow

3. Assign the appropriate URI Group configured above to

a. URI Group #1 – Identify the source of an originating call (From: Header)

b. URI Group #2 – Identify the destination of a call (To: Header)

4. Click Finish to save

mailto:011*@.*


9.4 CM Configuration

ACR uses UCID to maintain association across call legs and between different CTI feeds. When

matching UCIDs are available the ACR maintains this association and will continue to record

call legs via SIPREC. The CM in the solution must be configured properly to ensure UCIDs

match across solution elements. This configuration is outlined in this section. In a number of

scenarios the UCID is not maintained by the part of the solution generating CTI. These

scenarios are discussed in a later section.

9.4.1 UCID Configuration

1. Verify that Universal Call Identifier is enabled and that the Network Node is a unique

node identity. Use the display system-parameters features command, at the time of

writing page 5 of 20. display system-parameters features Page 5 of 20

FEATURE-RELATED SYSTEM PARAMETERS

SYSTEM PRINTER PARAMETERS

Endpoint: Lines Per Page: 60

SYSTEM-WIDE PARAMETERS

Switch Name:

Emergency Extension Forwarding (min): 10

Enable Inter-Gateway Alternate Routing? n

Enable Dial Plan Transparency in Survivable Mode? n

COR to Use for DPT: station

EC500 Routing in Survivable Mode: dpt-then-ec500

MALICIOUS CALL TRACE PARAMETERS

Apply MCT Warning Tone? n MCT Voice Recorder Trunk Group:

Delay Sending RELease (seconds): 0

SEND ALL CALLS OPTIONS

Send All Calls Applies to: station Auto Inspect on Send All Calls? n

Preserve previous AUX Work button states after deactivation? n

UNIVERSAL CALL ID

Create Universal Call ID (UCID)? y UCID Network Node ID: 1

2. Verify that the Universal Call Identifier is forwarded to the Adjunct Switch Applications

Interface (ASAI). Use the display system-parameters features command, at the time of

writing page 13 of 20. display system-parameters features Page 13 of 20

FEATURE-RELATED SYSTEM PARAMETERS

CALL CENTER MISCELLANEOUS

Callr-info Display Timer (sec): 10

Clear Callr-info: next-call

Allow Ringer-off with Auto-Answer? n

Reporting for PC Non-Predictive Calls? n

Agent/Caller Disconnect Tones? n

Interruptible Aux Notification Timer (sec): 3

Zip Tone Burst for Callmaster Endpoints: double

ASAI

Copy ASAI UUI During Conference/Transfer? n

Call Classification After Answer Supervision? n

Send UCID to ASAI? y

For ASAI Send DTMF Tone to Call Originator? y

Send Connect Event to ASAI For Announcement Answer? n


3. To support Universal Call Identifier (UCID), set UUI Treatment to shared, and then

enable Send UCID. Use the display trunk-group <t1> command where t1 is the

appropriate trunk group. display trunk-group 10 Page 3 of 22

TRUNK FEATURES

ACA Assignment? n Measured: none

Maintenance Tests? y

Numbering Format: public

UUI Treatment: shared

Maximum Size of UUI Contents: 128

Replace Restricted Numbers? n

Replace Unavailable Numbers? n

Modify Tandem Calling Number: no

Send UCID? y

Show ANSWERED BY on Display? y

DSN Term? n SIP ANAT Supported? n


9.5 ACR Configuration A property setting siprec.mode exists on ACR that corresponds to the type of SBC.

Note that the default value of this property is 2, and this corresponds to the Avaya ASBCE so

there is no need to explicitly set it.

siprec.mode=2

In certain scenarios, the ACR may try to record announcements/music when using SIPREC

which is possible because the call is already passing through the ASBCE. There is an optional

property setting that can be used to ensure that the announcements or music are not recorded

when using SIPREC, as follows:

announcement.record=false


9.6 Known Limitations

9.6.1 Selective Recording Not Supported

Full-Time recording means that the ASBCE will stream all RTP towards the ACR regardless if

the ACR intends to record those calls or not.

In Selective Recording mode of SIPREC recording, the ASBCE will not stream media packets to

the ACR until the ACR indicates by means of a re-INVITE to the ASBCE that media should be

sent.

IMPORTANT

Only Full-Time recording is implemented in the ACR 12.1 – ASBCE 7.00.00

implementation.

Hence any system configurations must take into account the necessary bandwidth and CPU

requirements for both ASBCE and ACR servers based on the entire set of call media streams

that will flow from the ASBCE to the ACR(s) - not just the calls that the ACR decides to

record.

A potential workaround is to configure a Session Flow with selected URIs in the ASBCE to only

send media for a selected VDN/CDN/Range of agents.

9.6.2 General Recording Strategy and Prioritization of Recording Mechanisms

As described in section 10.2.3, ACR implements a hybrid configuration whereby it usually has a

number of different mechanisms available for recording purposes (e.g. SIPREC, DMCC, Passive

IP etc).

SIPREC operates in conjunction with these other recording mechanisms and in particular with

the CTI signaling for real time call information that these other mechanisms provide to the ACR.

Given this architecture, there will always be a number of complex call scenarios whereby the

ACR may not be able to definitively ascertain whether a call that it receives from the ASBCE is

definitely the same call that it has been informed about by another CTI stream (e.g. via TSAPI).

The reasons for this ambiguity is beyond the control of the ACR as it relies on the various CTI

streams provided to it by the CM infrastructure. In these types of complex call scenarios, ACR

may choose to NOT record via SIPREC but instead uses an alternate method such as DMCC,

Passive IP etc. The end result will be the same – the call is successfully recorded by ACR. Some

examples of these scenarios are described later in this section.

Specifically, the ACR relies on a common call ID (UCID) which enables it to correlate SIPREC

messages for a particular call with the associated TSAPI information it receives for an endpoint

that it wishes to record. If the UCID information does not match, ACR has no choice but to

record the call by an alternative mechanism (usually DMCC) as it cannot be 100% sure that the

SIPREC messages are indeed the same call as provided by TSAPI. This emphasizes the point

that the SBC must be capable and enabled to create a UCID for any inbound calls so that this

information is provided to the ACR in the SIPREC messages. Note that this is also the reason

why CS100 is currently not supported as it does not have the capability to received and

propagate a UCID from the SBC through to the ACR via the AML/MLS interface.


9.6.3 Recording Indication

The ASBCE recording indication has some limitations and may not be suitable as a method to

fulfill recording indication requirements.

It can be enabled on an ASBCE basis as outlined above in the Session Policies Configuration.

ASBCE supports the playing of a single recording indication towards the customer trunk to

indicate a recording session is in progress.

The ASBCE will play the indication towards the customer trunk regardless of whether the ACR

decides to actually record the call.

The indication will be played once

The indication is played as soon as 200OK comes from the called party. This is the event from

where the ASBCE starts streaming media towards the Recorder. In some cases the agent

answers after the 200OK from the switch so the tone may be played before agent answers. Some

example of this:

DN call – Indication played to customer after agent/knowledge worker answers

CDN call – Indication played to customer before agent answers

VDN call – Indication played to customer before agent answers

The tone will not be recorded as it is never streamed towards the ACR.

9.6.3.1 Configuring Recording Indication The actual indication is configurable. Use the following steps to replace the default indication:

Stop the SBC

Replace CALL_CONNECTING file in following locations on each SBC with the

new recording indication. The codec used should match the location naming

convention:

o /usr/local/ipcs/prompt/pcmu

o /usr/local/ipcs/prompt/g729

Start the SBC


9.6.4 AACC Scenarios

There are a number of limitations when recording AACC related calls. These are due to

insufficient information being passed in CCT events. A number of these scenarios are listed and

described below.

9.6.4.1 AACC Transfer/Conference

The scenario here is an initial DN call via the SBC that is subsequently transferred or

conferenced on via AACC/CDN. The final leg will be recorded via AMS rather than SIPREC.

The SIPREC invite relates to the original (customer to CM) leg of the call.

The only way that ACR can know that this leg is still appropriate for the call after a transfer into

AACC and out to CM - over a different CM call - is if the contactid provided by CCT is that of

the original CM call.

First off, in this case, CCT is providing a GUID rather than a UCID - so there is no link back to

any CM call via that.

However, even if you DO configure this AACC to use the CM's UCID, it will pick up the UCID

of the consult call - which is how AACC first hears about the call.

That will NOT be the UCID of the original leg and hence won't match the SIPREC invite.

When the transfer completes and agent A drops off the consult call, that CM call will acquire the

UCID of the original leg (which is how we track this in a pure CM environment) but AACC will

not note the change to that call's UCID as it has already assigned a contactid. Unless CCT

advises ACR of that revised UCID ACR has no way of tracking back from the Agent B leg to the

original leg.

This scenario is not likely to represent a significant proportion of traffic. The bulk of customer

interactions will be via the AACC and not originating via the CM. The consult calls are SIP

recorded anyway so it's only the tail end that are SIP instead of SIPREC.

ACR has never attempted to track the legs of calls that end up routing customer to AACC (or

dialer) once the recording target (agent/station) has left them. As above, ACR loses sight of

events on those calls and without explicit advice of the state of those calls as to whether they are

still part of the leg ACR sees coming out of AACC it isn’t possible to tie them together.

UCID is only populated as the CMF contact id for an inbound CC call originating from a non-

agent (an out of provider user from the perspective of the contact center). If an Agent dials the

CDN then UCID will not be populated as the CMF contact id.

The CTI adapter of AACC is responsible for creating the contact in CMF if an Agent dials the

CDN. Currently AACC does not populate UCID from the CTI adapter. The SIP/BBUA adapter

of AACC matches up to this CMF contact on receipt of the incoming Invite. It is not possible for

the SIP adapter to update the CMF contact id at this point (the id cannot be modified after

contact creation).


9.6.4.2 AACC Call Leg Recordings Merged

This is an unusual call scenario - and has always worked this way regardless of SIPREC. This

will be treated as a limitation/standard operation.

This is very similar to the existing documented limitation where on an AACC party when a

customer drops off a 3-way call in AACC but ACR doesn't get the CTI event for that - so

continue with the existing segment.

Scenario:

1. CDN call via SBC from Cus 1 to Agent. Agent answers the call.

2. DN call via SBC from Cus 2 to Agent. Agent answers the call.

3. Agent joins the 2 calls.

4. Cus 2 releases the call.

5. Cus 1 releases the call.

Actual Result:

1 recording for screen of agent

There are 3 audio recordings generated as follows.

- SIPREC recording between Cus 1 and Agent

- SIPREC recording between Cus 2 and Agent

- SIPREC recording

- Recording between Cus 1, Cus 2 and Agent

Plus

- Recording between Cus 1 and Agent (after Cus 2 releases the call)

Agent joins and AACC call and a DN call together at his phone.

The problem is that ACR is getting CTI from two sources and the info is conflicting.

The CCT events show the agent putting the CDN call on hold and then retrieving it - but do NOT

show a conference completing.

The CCT information therefore does not include information about the party on the DN call - but

is indicating that the agent is on a CDN call so we treat its information as "dominant" over that

from TSAPI for the same station - and hence don't act on the clearedevent for 2005 from TSAPI

as the "dominant" call doesn't appear to have changed parties.

The gap in CCT's view is partially plugged with the tagging of the segment with the additional

party because of the TSAPI connection that ACR knows is present though it wasn't taken into

account in the recording decision and hence does not cause a break due to parties changing when

it later drops off.


9.6.5 Elite Scenarios

There are a number of limitations when recording Elite calls. These are due to insufficient

information being passed in TSAPI events. These scenarios are listed and described below.

9.6.5.1 VDN Transfer/Conference The scenario here is an initial DN call via the SBC; an agent answers the call and then transfers

or sets up a conference via VDN to another agent.

In the transfer scenario, the 3rd leg is recorded via DMCC.

In the conference scenario, the 3rd and 4th legs are recorded via DMCC.

In both the above cases there may be an expectation that the legs mentioned are recorded via

SIPREC rather than DMCC. However in both cases TSAPI returns the UCID of the consult leg

rather than the initial leg as the UCID of the transferred/conferenced call. Due to this the ACR

cannot determine that the call has matching SIPREC CTI and therefore must record by a

mechanism other than SIPREC, in this case DMCC.


9.6.6 Far End Hold

All far-end hold types are handled differently and are not considered a critical part of

management of call recordings. In the case of SIPREC far-end holds the behavior is documented

below. If this is to be changed then it will be addressed as an enhancement to re-look at all far-

end hold scenarios. This is not envisaged to be a requirement soon.

Scenario:

1. Agent answers DN call via SBC.

2. Customer holds the call.

3. Customer resumes the call.

4. Agent releases the call.

Actual Result:

There are 3 audio recordings generated as follows:

Before Customer holds. Recording as expected.

During Customer hold. This recording can be replayed but no sound on it.

After Customer resumes. Recording as expected.

9.6.7 Progressive POM Campaigns

Progressive POM campaign calls are recorded via DMCC rather than the expected SIPREC

method. The reason for this is the POM solution does not maintain a consistent UCID for

Progressive POM campaign calls.

This issue is tracked in MR wi01214841.


9.6.8 AAEP Transfers

ACR supports recording calls that arrive via front end IVR (AAEP) via SIPREC.

ACR does not support recording of back-end IVR.

While the ACR supports recording of calls arriving from AAEP the ACR will not record the

treatment played by the AAEP but will only start recording once the call has been answered by

an agent that is being monitored for recording.

3 AAEP transfer methods are supported. Calls transferred by all 3 methods should be SIPREC

recorded.

Blind

Consult

Bridged

Currently, however, when calls are passed onto agents via Bridged transfer a new UCID is

generated. Owing to this ACR cannot tie the bridged transfer to the original call via the SBC and

therefore does not SIPREC record but falls back to an alternative method of recording. Where

CM uses INVITE/REPLACES (see SIP Connections under VoIP Configuration) for supervised

transfer and AAEP didn’t forward the UCID from the call leg being transfer to the destination

leg.

The problem is fixed in a hotfix on AAEP 7.0.1, Avaya Aura® Experience Portal 7.0 Feature

Pack 1 MPP Hotfix 7.0.1.0.1604 (wi01202584 + wi01199451)

In the case of the Consult transfer calls also fall back to an alternative method of recording due to

a shortcoming in the way AAEP handles UCIDs. In addition to the issue described above for

Bridged transfers the AAEP has to pass that same UCID in REFER so that the ASBCE can use it

in the INVITE replace. This is tracked via wi01214850.

9.6.9 Multi Switch

In case of multiple CMs and agents transferring to another agent on a different CM there is an

issue with the SBC UCID not matching to the CTI UCID.

This issue will exist until CM fixes the bug tracked via MR defsw132108.


10 WFM Configuration: Technical Details

10.1 WFM support for Multimedia/Multiplicity

Multiplicity is a feature in Avaya Aura® Contact Centre (AACC) whereby a single agent can

handle a mixture of voice and multimedia contacts at the same time.

On WFM 12.0 ( HFR3 or later ) AACC multimedia and multiplicity is supported with real time

information that is used for adherence purposes – however it does not address any historical data

collection that may be associated with WFM functions such as forecasting and scheduling.

See reference [3] for more details regarding the support for AACC Multimedia and Multiplicity.


11 Multi-switch Support (aka Multiple Data Source Support)

11.1 Introduction

ACR 12.1 introduces the concept of multiple Data Sources, whereby a separate connection can

be explicitly configured for each telecommunications component that ACR interfaces with. For

example, a Data Source could be a Communications Manager or a CS1000 Switch, but also it

could be another component like an AACC contact center or a dialer like POM or Proactive

contact.

The ACR administration terminology is therefore now similar to the WFO framework

terminology in that it refers to ‘Data Sources’ instead of ‘Switches’.


Any new Data Sources are created from the General Setup > Recorder page using the “Add Data

Source” button. The capability to add multiple Data Sources supports any combination of Avaya

Communication Manager, CS1000, Avaya Aura Contact Centre, POM etc.

11.2 Guidelines and Limitations

In the specific case where there may be more than one PBX, it is now possible to connect a

single ACR to two or more of these PBX’s - for example a single ACR may be connected to a

CS1000 and a CM at the same time. With this type of multiple Switch arrangement there are

certain guidelines and limitations that must be considered:

Conflicting Number Plans: If the same number (say, "1234") can occur on more than one switch,

instruct the recorder to let you set a switch-specific string that will be added to internal numbers

by adding the property file setting:

cti.switchidentifiers=true

Data Source Identifier: The Administration page for each Data Source will then let you set a

specific identifier. Choose a (very) short identifier - just long enough to uniquely identify the

data source from any others. You only need to set this field on the Data Sources that have

overlapping number plans. You can use a few digits (e.g. the local public prefix or the prefix you

plan to give these switches when they are fully integrated into your numbering plan. Typically a

1 to 3 digit number or two or three character abbreviation are used. Use underbar ("_") rather

than dash ("-") if you want to visibly separate the prefix from the number. For example, "NY_"


or "SF_". You must restart the recorder after setting the identifier on a switch. It is not

recommended to change identifiers after the system has gone live.

Call scenarios involving both PBX’s: The ACR will not attempt to intelligently analyze a call

that traverses both PBX’s and therefore may not determine that an active call on PBX 1 is in fact

the same call presented on PBX 2. In these types of scenarios, it is highly likely that the ACR

will record the call twice, based on the rules associated with the corresponding Data Source for

each PBX.

Important Note Regarding Migration limitations: Note that it is not part of the standard

functionality to migrate two existing standalone master ACR’s that were previously interfacing

with different PBX’s into a single multi-switch configuration. The typical scenarios for multi

switch functionality that are supported are as follows:

(a) A customer has a single ACR master (or master + standby + slave system) connected to a

CS1000 PBX and wishes to migrate to a Communications Manager environment. This

migration could be a gradual process, therefore a period exists whereby the ACR could be

simultaneously connected to both the CS1000 and the CM.

(b) A customer has multiple PBX’s (can be any mix of CM and CS1000) and wishes to

deploy a new single master ACR system that interfaces with these PBX’s.


12 Limitations, Known Issues and Workarounds

12.1 wi00995346: Transferred/Conferenced party information is not displayed incase of ACR-PC (Hard Dialer) integration

When a Proactive Contact agent conferences a customer call to another CM station, there is no

information displayed about this CM station in ACR under Record status->CTI Monitor->Active

column

Also after completing this call, when the Agent releases the line and record, only one recording

gets created for all the conversation of conference scenario, which also does not contain any

information about the conferenced station on ACR replay page.

Applicable to Single Step Conferencing recording in a CM environment with Proactive Contact

12.2 wi00995350: ACR does not display any information about the party called by using manual call feature

A Proactive Contact agent is in conversation with a customer who is using phone 1 and the

customer asks the agent to call him back on a different phone 2. The agent hangs up the customer

call, and then initiates a manual call to the customer phone 2. After completing this call, the

agent releases the line.

ACR captures two recordings are created for this scenario, however the second recording

displays the called party information as customer phone 1, when this should actually be

customer phone 2.

Applicable to Single Step Conferencing recording in a CM environment with Proactive Contact

Hard Dialer.

12.3 wi00999905: ACR needs both Links in a CM Hybrid Configuration

With the CM hybrid configuration, ACR maintains a signaling link to the AES application

(TSAPI and DMCC) and also to the AACC application (Web Services). The current architecture

requires that both links are operational for ACR to work correctly.

If either of these links go down, then ACR will consider itself to be non viable (even if there is

no ACR standby present in the solution) and it will not use the other operational link to record.

This MR will be put in the backlog as a S3 Enhancement for WFO 12.1.

Applicable to SIP and SSC recording in a CM hybrid configuration.

Also applicable to ACR when configured in a CS1k SIP hybrid environments using SIP and

duplicate media stream/TDM recording


12.4 wi00954981: ACR counts twice for calls observed via CTI

In Recorder Status, Server tab, Total calls observed via CTI since startup and the Total calls

observed via CTI today.

In a CM or CS1k Hybrid configuration, the recorder is told about a call by the CTI from the

underlying switch (CM or CS1k) and also via AACC Web Services

Therefore in many of these scenarios, the ACR may count the number of calls twice.

Note that the purpose of these entries in the Server status page is to provide a general indication

that call activity is happening - these counters are not intended to be a precise count of the

number of calls that have been recorded. For this reason, the current operation is working as

designed.

Applicable to all configurations.

12.5 wi00955895: Total call segments recorded are counted incorrectly for CDN call with screen

This is not really an issue but rather a clarification of how the counting of call segments is

implemented in the ACR. (Also refer to the PIA Guide). Specifically this relates to the “Total

media files recorded to date” and “Total media files recorded today” counters in the

Status/Server Tab on the ACR.

If you record a basic call using CS1K Duplicate Media Streaming, this will result in an increase

of 2 audio segments because the stream is split into 2 separate files for Transmit and Receive.

Alternatively if you record using SIP, this will only result in an increment of 1, as the transmit

and receive steams are combined. Additionally, if a screen recording is also made, this generates

one extra segment count.

In summary:

Basic call recording using Duplicate media stream with screen recording: Counter

increments by 3

Basic call recording using SIP or TSAPI with screen recording: Counter increments by 2

Applicable to all configurations.


12.6 SIL issue 15: ACR CTI information from Elite and AACC when there a CLAN busy out-release/CTI busy out-release during an active CDN or VDN call.

In an abnormal case where there is an interruption in the Link between CM and AES during an

active call that is being recorded, this can sometimes result in the Recorder assigning different

Call IDs to the same call. In this case the recorder will continue to record once the link is

restored, but it may decide to use a different recording mechanism. For example if the call is

initially being recorded via SIP, after the Link interruption the Recorder may decide to resume

recording via DMCC. This will result in the 2 segments of the call having 2 different call IDs.

12.7 Passive IP does not support SIP Phones, only H.323

RPP Control messages (RTCP) are slightly different in for SIP Phones when compared to H.323

IP Phones. The ACR passive IP solution is only designed to interpret the RTCP packets for

H.323 phones.

12.8 Attendant Console not supported on CM

Attendant Console with either the Avaya Legacy or Avaya Hybrid configurations is not

supported for call recording, since ASAI does not support Attendant Consoles. This includes the

hardphone and softphone Attendant Consoles.

12.9 wi01030448 ACR Interoperation with AACC Mission Critical Operation

When ACR is deployed in conjunction with the AACC Mission Critical Solution, there is a small

possibility that ACR may not detect the switchover of the AACC and in this case a manual

restart of the ACR service is required. If the switchover is detected then an alarm will be

generated on the ACR alarms page and no action should be required. If however, the switchover

is NOT detected, no alarm will appear on ACR, and even though the ACR is polling the new

AACC and showing the link as UP, no events will be sent to the ACR from the AACC via web

services.

Another way to detect this issue is to observe the actual calls that are being recorded after the

AACC Switchover. If the Call IDs appear different after the switchover and the skillset

information is missing, this is an indication that the ACR is no longer receiving events from

AACC via Web Service, and so ACR is instead using DMCC for all subsequent recordings.


Applicable to ACR (Windows or Linux) in a SIP Hybrid Configuration or SIP only

Configuration

12.10 SIP Recording Traffic Performance and Optimisations

SIP Recording is currently only supported to a maximum of 3000 calls per hour.

At this level of traffic it is possible that the web services events being sent from AACC to ACR

may start to experience some congestion.

If this is experienced, this issue can be improved by setting one of the following settings.

12.10.1 TCP_NODELAY on ACR

This method is not applicable to ACR versions before 12.0. The reason for this is that the

TCP_NODELAY option was only introduced in JDK 1.6.30. ACR versions prior to 12.0 use

earlier versions of the java.

To make the change

update the file appropriate to the operating system the ACR is on

add the highlighted line below

Windows:

…..\tomcat7\wrapper\cscmw.conf

Linux

opt/witness/wrapper/cscml.conf

wrapper.java.additional.6=-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true

wrapper.java.additional.7=-XX:+UseConcMarkSweepGC

wrapper.java.additional.8=-XX:+ExplicitGCInvokesConcurrent

wrapper.java.additional.9=-Dsun.net.httpserver.nodelay=true


12.10.2 tcpackfrequency on AACC

If TCP_NODELAY is not an option then this issue can be improved by setting a registry

parameter TcpAckFrequency to "1" on AACC.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\

Interfaces\<Interface GUID>

where <Interface GUID> refers to the GUID of the network interface being used

The TCPAckFrequency may need to be added and its value can be in the range 0 to 255 and its

default is 2. TcpAckFrequency the number of ACKs outstanding before the delayed ACK timer

is ignored. Setting the value to 1 causes ACK’s to be generated for every segment received.

Note that the AACC server will require a reboot in order for this registry setting to take effect.

IMPORTANT NOTE: This is a windows level change on the AACC server, and therefore if you

are considering implementing this change on a customer site, it should be explicitly approved by

the AACC Design Support team as the Registry change is not specific to the Web Services

interface for Call Recording.

Applicable to SIP Recording.

12.11 wi00859051: AACC6.1 CCT: Agent LOGOUT events are sent to ACR in wrong order

When an Agent logs out, sometimes there is a small possibility that the AACC Web Services

will send these 2 events in the reverse order, as they happen almost simultaneously. If this

occurs, then the events will arrive at the ACR in the reverse order LOGOUT followed by NOT

READY. This is architecturally a very difficult issue to resolve on AACC.

ACR is aware of this issue and deals with it, so there are no adverse effects from an ACR

perspective. Other recorders should however be aware of this issue so that they too can deal with

it effectively.

Applicable to SIP Recording


12.12 ACR 12.1 does not support Avaya Interaction Center

Note that support for AIC (Avaya Interaction Center) is not available with ACR 12.1

(ACR 10.0 was the last version to provide AIC support)

12.13 wi01052168: AAAD loses call while physical phone retains it after Audix-rec button pressed twice.

This is basically an AACC issue that is caused by the On Demand feature when used by an

AACC agent who is active on an outbound call. When On Demand recording is stopped by the

agent, this can cause the call state on agent’s AAAD to go idle, even though the Agent is still

active on the outbound call. Additionally, if another 2nd

agent tries to call the 1st agent who is on

the outbound call, then the state of this 2nd

agent is also impacted and they may not be available

to take a new call until the 1st agent hangs up the outbound call.

This is not a recording issue, but rather an issue with CM/AES that is revealed by the presence of

the on Demand feature.

Applicable to DMCC Recording in a CM environment.

This issue can be avoided by setting up on-demand recording through one of the following

methods instead of configuring the Audix-rec button.

Conference in a recording port

Set up a hunt group with recording ports and conference that in

See the Avaya Contact Recorder Release 12.0 Planning, Installation and Administration Guide,

Chapter 4, On Demand Recording (Communication Manager only) section for more details on

this setup.

12.14 SAP 1-3988673732: WFM does not handle agent logout over multiple packets

In WFM an issue exists where agents are being shown as logged-out but they are shown in CCM

as being idle or in another state. This occurs when AACC breaks the RSM feed into multiple

packets as an individual packet exceeds 64k. WFM does not currently handle the case where

agent information moves between packets, it assumes the agent has logged out in this scenario.

Applicable to WFM /AACC integration


12.15 Verint# 4168480: Avaya - ASCM for CMS Reports interface does not function properly.

The vendor specific ACSM adapter (Avaya - ASCM for CMS Reports) does not function

properly. It processes data but that data does not appear in the Scorecards.

A workaround is to configure the Generic - ASCM - Agent Scorecard Metrics instead.

Applicable to WFM /CC Elite integration.

12.16 Issue with Forecasting and Scheduling web based client.

A number of product issues exist with the WFO 12 F&S Web based client that are due to be

resolved as part of a hotfix on top of HFR3. These issues are not present in the standard F&S

thick client. Until these patch updates are available, Avaya recommends that customers should

continue to use the existing F&S thick client while also making F&S on the Web available to

their users for familiarization.

12.16.1 Verint# 4159230: Attempting to generate schedule in WFM remains at 0%.

When attempting to run the schedule engine from the Calendar of the Forecasting and

Scheduling module of the web client of WFM the schedule engine sticks on 0% progress.

A workaround involving changing the user that runs the Integration Server from the IMSA

account to the ‘Local System Account’ was proposed but this caused other issues. The

recommended workaround now is to use the standard F&S client.

This issue does not occur in the standard F&S client.

12.16.2 Verint# 4171662: When adding a floating/class event, receive hourglass for a long period of time

When adding a floating or class event the cursor just spins. User must exit browser window and

log back in to stop it. When logged back in the event appears in schedule.


12.16.3 Verint# 4178212: Exception error when working in a Campaign.

When working in any campaign and after removing a repeating event an exception is thrown

"Exception occurred when attempting to read statistics data. Unable to find object(s)”.This can

be resolved by restarting the WFO_Production_Server service.



12.16.4 Verint# 4172440: Error when trying to unlock a shift that is coming into the new schedule already locked

When trying to unlock a shift that is coming into a new schedule already locked the following

error message is returned. "You cannot unlock a custom shift. It is a custom shift since the

number of an activity does not match that was defined for the shift event in shift".


12.17 Verint# 4168478: QM Call time is off by 1 hour

When reviewing calls in QM, actual call time is an hour off. As an example system said call

came in at 1:23 and the system time on agent’s system was 2:23.

This is an issue that will be resolved by HFR3.

As a workaround the script in Appendix A, QM Call Time Workaround, can be run to resolve

the issue.

12.18 Misleading information in Avaya Archive Administration Guide Release 12.0

The Avaya Archive Administration Guide Release 12.0, Chapter 1 – Archive Overview contains

a short note that indicates the WFO integrated archiving solution is supported by ACR.

“The integration implementation in the Avaya 12.0 release supports the WFO archiving

functionality. However, the preferred archiving solution is via the Avaya Contact Recorder, as

explained in the Avaya Contact Recorder Planning, Installation, and Administration Guide.”

WFO 12.1 does not support the integration implementation – instead, the integrated ACR 12.1

archive functionality should be used.

12.19 CaptureLayeredWindows setting for Windows XP

The Avaya ACR Screen Capture Technical Note [1] describes how the registry setting

CaptureLayeredWindows should be configured in a number of scenarios. However it omits to

describe that when operating on a Windows XP machine the CaptureLayeredWindows registry

setting should always be set to 1.

12.20 POM Agents should not put their nailup call on hold

When a POM agent is on a POM nailup call, they should not place the nailup call on HOLD or

accept/place a new call on another line appearance on their telephone as the POM application is

not aware that this has happened. This is a known restriction from a POM application

perspective. This type of call activity can result in indeterminate information being sent to the

ACR application and can therefore impact the accuracy of the resultant recordings.

A specific instance of this is where a nailed up POM agent initiates an external consultative call

to another nailed up POM agent when then answers the call on a different line and places their


nailup on HOLD. This scenario is therefore not supported, and consequently ACR does not

support this scenario either – it can lead to incorrect Recording decisions as the logic in the

recorder is not expecting this scenario to occur. In such cases, the POM agent who is initiating

the consult call to another POM agent should always the internal POM mechanism.

12.21 wi01156994 - POM does not inform ACR that an external consult call is initiated

During an external consult call (for example a POM agent wishes to conference in a supervisor

into a customer call), recording will continue from the point where the POM agent initiates the

external consult call and places the customer on HOLD. This may manifest itself either as a new

call segment or an elongation of the initial customer call segment. ACR requires an additional

event from the POM application to inform it of the consult call initiation – this is planned for a

future release of the POM application.

12.22 POM – ACR: Duplicate Agent Details in Search & Replay

Duplicate Agent details can occur in the ACR Search & Replay display – this is because the

agent has effectively logged on twice - once to CM and once to POM, though both normally

have same identifier and same name at present. ACR is required to track all logged on agents - as

consult calls could be on either logical system (i.e. the CM or POM) and ACR does not want

miss any recordings if a search is conducted on one or the other.

12.23 wi01179953: Extra recording in conf/trans from POM to non POM agent via CDN

An extra recording showing the POM agent initiating the consultative conference CDN call is

captured in these scenarios. This is design intent.

It occurs because POM sends a MediInfoEvent to ACR indicating the consult call has been

established even though it's only working its way through AACC before being answered.

To not have the extra recording POM would need to delay this message. However POM does

not have visibility into AACC so cannot do this.

An additional issue that may be seen is in some cases there is a difference between first and

second transfer/consult after ACR startup (and all subsequent times) is that during the first call,

ACR learns (from CCT) what is an AACC CDN and hence marks that as a "service" on all


subsequent segments that use this number - but the second segment ends just as that fact is

learned so did not have it tagged as a service.

This is a very minor limitation as it only happens at most once after startup - and if any other call

uses that AACC CDN before this type of scenario does then it won’t occur at all.

12.24 wi01179339: ACR updates wrong value for Hold Count, Transfer Count and Conference Count column in external transfer or transfer via agent mode POM contact

This is known minor issue in ACR 12.0 and will be investigated for resolution in ACR 12.1 or

later.

12.25 ACR does not support AACC/POM Agent ID’s that overlap with the Phone secondary DN (AACC-AML configuration)

In an AACC-AML / CS1000 contact center, the AACC Agent ID value is usually a completely

different numbering scheme to the Position ID /secondary DN configured on Agent’s telephone

set. In some cases for convenience, the agent ID value may be set to the same value as the

Telephone Position ID and ACR supports this configuration.

However ACR 12.0/ ACR 12.1 currently does not support a configuration whereby the Agent ID

is set to the same value as the Telephone Secondary DN. This will be investigated for resolution

in a future release.

12.26 wi01180510: External transfer from POM agent to a VDN not supported

There is a known issue with this scenario which impact the Recorder operation (a call may not be

reflected in QM for up to 4 hours, and a subsequent POM call may not record correctly)

The root cause for this issue lies in the CM/AES infrastructure, whereby incorrect information is

provided to the ACR via TSAPI. This issue is under investigation for resolution in a future Patch

or Service pack on these products.

Until such time as this issue is resolved, it is recommended that POM agents should not

implement this type of external transfer mechanism as part of their workflow.

(Internal transfers to other POM Agent who are nailed up does not have this issue)


12.27 SIP PHONE (SIP type) is not recognized by TSAPI

Symptom: After adding a station (SIP type) to ACR on the CM platform, an error message says

that: “AES TSAPI Service Observation of xxxxx reports error:CSTAUniversalFailureConfEvent

error=genericSubscribedResourceAvailability” or “Address xxxxx not recognised by TSAPI” .

The station is not monitored by CTI Monitors.

Possible cause: Configuration of SIP Endpoint for AES Control may be missing.

Suggested Solution: Each SIP endpoint to be monitored by ACR must be configured

accordingly. Enter the command change station xxxx where xxxx is the SIP endpoint. Go to

Page 6 and in the Type of 3PCC Enabled enter Avaya as shown below.


12.28 Antivirus and other 3rd Party Applications on ACR

The overarching requirement for an Avaya Contact Recorder - which is a high performance, real-

time systems that makes heavy demands on CPU, disk and network I/O - is that it is not

materially impacted by other applications running on the same server. Sizing of servers and

hence the correct operation of the systems assume that substantially all (i.e. 90% or more) of

specified resources are available to the Avaya Contact Recorder at all times.

This applies to all other applications running on the same virtual and physical machine

i.e. includes but is not limited to:

- Anti-virus software.

The recorder's files must be excluded from real time and scheduled scans

The recorder and underlying postgreSQL database processes must be completely excluded from

real time and scheduled scans. Note that some tools still access directories even when these have

been excluded and others do not have real-time exclusion features at all.

Backup tools (including Virtual machine snapshotting and recovery mechanisms) - see

Backup/Restore section in the ACR PIA guide for details.

System management tools

Virtualization frameworks

12.28.1 Common Problems

Common causes of material impact that MUST be avoided include:

1. Anti-virus software interacting at all with the recorder's database or recording folders (as is

known to happen with e.g. Trend Micro even when these folders are excluded and real-time

scanning is turned off. McAfee does not even provide such an exclusion facility). At present,

only AVG version 3485 Business Edition has been confirmed to avoid all contact with the

recorder's database files (when these are correctly excluded from its scope for both real-time and

scheduled scans).

All virus scanners impact disk performance significantly when running scans. The performance

of the recorder during such scanning is not guaranteed. If these are run out of hours, it is the

customer's responsibility to ensure that the recorder has not been affected by them and any

impact found to be caused by them will be chargeable.

Current recommendations with respect to the underlying database used (PostgreSQL) can be

found at:-

https://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows#Anti

virus_software

2. Any heavy and, especially, sustained disk activity that reduces the recorder's ability to create,

read, write or rename files - such as scheduled virus scans, backups, Windows disk indexing and

VM snapshots. Backup/Restore on page 201 explains why these are not required. The recorder's

performance is not guaranteed while these are running - and note that problems arising from

them even when carried out in idle periods may carry forward into business hours.

https://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows#Antivirus_software

https://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows#Antivirus_software


3. Other processes using up available physical memory and hence triggering page file swapping

must be avoided at all costs. This degrades apparent memory performance by at least an order of

magnitude and also impacts disk I/O dramatically.

The above not only reduce the sustainable capacity of a recorder, they also push many of the

tight real time constraints (e.g. 20ms packet intervals in most VoIP environments) out of

acceptable bounds and increase latency such that events are not processed within the sub-second

intervals needed to avoid losing significant audio content at the start of a recording.

12.29 Live Monitoring does not support Telephone Replay

Note that when using Live Monitoring via QM 12.0, it is not possible to listen to the call via the

telephone.

12.30 ACR interworking with AMS on Aura 7.0 not supported

Communications Manager 7.0 enables the Avaya Media Server (AMS) to be used as a media

conferencing resource for the DMCC protocol. However it does not support the existing

encryption mechanism referred to as “AES” which the Avaya Contact Recorder (ACR) currently

uses for SRTP in conjunction with DMCC recording.

Therefore some development changes are required on ACR in order to provide continued support

for encryption of audio streams when AMS is used as part of a DMCC recording solution. A

GRIP 15897 (GRIP = Global Requirements Integration Process) is currently open to define the

scope of this future development.

12.31 Codec selection type used with SIPREC

The ACR SIPREC implementation supports codec types G.711 (A law and u Law ) and also

G.729. With the current SIPREC implementation, the SBC sends an initial SIPREC INVITE to

the ACR, and the ACR then responds with a SIP OK which contains SDP (Session Description

protocol) information that defines a number of parameters that relating to the call, and in

particular the codec types that the ACR supports. Currently the ACR responds with a codec type

of G711 only which does not accurately the true capability of the ACR. Practically this has no

effect on the SIPREC operation, as the SBC will ignore this information and proceed to send

whatever codec type the main call between the 2 live parties is using, for example if the main

call is using G.729, the SBC will also send that to the ACR, even though the ACR has stipulated

G.711 in the SDP. Note that ACR also examines the RTP stream and automatically detects the

codec type.

In the future, the ASBCE will also support transcoding but in this scenario the codec type used

for the SIPREC legs will be configured on the ASBCE and will not be determined by the SIP OK

received by the ACR, so the codec type as provided by the ACR will continue to be ignored even

with the new transcoding capability.

However it is acknowledged that the message sequence will look incorrect to a service engineer

who investigates the SIPREC message sequence between the SBC and the ACR, particularly in

the case where the SBC decides that it wants to use G.729 and could cause confusion/ For this


reason a work item will be created to change the ACR behavior so that it’s SDP reflects the true

nature of it’s codec capabilities.

12.32 Urgent advisory Impacting ALL 12.0 & 12.1 sites

IMPORTANT

The following property MUST be set in all ACR Master & Standby Servers/Recorders

tsapi.maxretryinterval=1

This can be performed while the recorder is running via the mtce page and should also be set in

the property file.

This change still allows the sub second check for genuine transition states on call teardown to

work but does NOT persist invalid call states received from TSAPI.

A future patch is being developed which will make this the default in 12.0 and 12.1 – this

document will be updated with that detail once the patch is available


13 Additional Technical Guidelines

13.1 ACR Power On Sequence

In the case where the solution is comprised of multiple ACR’s, the standby server(s) should not

be powered on before the master ACR. This is required in order to prevent an ACR standby

server assuming a master role, if the actual master ACR is not yet visible on the network.

In the common case where all servers are powered on at the same time, the solution should

behave correctly, as the standby server has a default wait period of 120 seconds before it will

attempt to assume control. This wait period is defined by the property setting

oemcomms.connecttimeout=xxx with a default of 120 seconds, but this value can be

changed to a higher value if there is a concern that the boot up time of the servers involved

varies significantly.

The sequence of powering up a slave or CRS recorder in relation to the master or standby ACR

is not critical.

Refer to the ACR Planning, Installation and Administration Guide which has additional

information on this topic, specifically the sections entitled “Power-On” and “Failure Detection”

in the Fault Tolerant Appendix.


14 References

[1] Avaya Contact Recorder, Planning, Release 12.1, Planning, Installation and

Administration Guide. Issue 2, Feb 2015.

[2] Avaya Contact Recorder, Planning, Release 12.1, Technical Note: Avaya Contact

Recorder Screen Capture Installation

[3] Avaya Technical Note: Multiplicity in Avaya Aura® Workforce Optimization solution.


15 Appendices

A. QM Call Time Workaround

BPMAINDB_KB115533_QC118625_TIMEZONEINFO_update.sql

USE BPMAINDB

GO

print 'Begin Script KB115533_1200_FN_QC118625_TIMEZONEforID_20088'

PRINT 'KB115508 QC118625 for July Release - Updating BPCONFIG for ID = -20088 with epoch time'

IF EXISTS (SELECT * FROM bpconfig WHERE id = -20088) BEGIN

print 'Bpconfig entry is there for -20088'

declare @value varchar(100)

SELECT @value=value from BPCONFIG where ID = -20088

IF @value LIKE '%[^0-9]%'

SET @value=0

IF (convert(bigint, @value) > 0 ) BEGIN

PRINT 'Do nothing.......'

END

ELSE

BEGIN

PRINT ' @value is non numeric or 0...'

IF ((SELECT isnull(Count(*),0) FROM timezoneam) > 0 )

BEGIN

print 'Timezoneam table has data ie more than 0 records...'

PRINT 'Updating BPCONFIG for ID = -20088 with Fixed epoch time of 3/31/2010 value'

+ ' instead of epoch time as per vinod ESR 4098798...'

UPDATE bpconfig

SET value = convert(int, datediff(ss,'01-01-1970 00:00:00','03-31-2010 00:00:00'))

WHERE id = -20088

END -- End for TIMEZONEAM check

ELSE

BEGIN

PRINT 'Updating BPCONFIG for ID = -20088 with 0 value instead of epoch time as per

vinod ESR 4098798...'

UPDATE bpconfig

SET value = 0

WHERE id = -20088

END

END -- IF (convert(int, @value) > 0

END -- End of BPCONFIG IF EXISTS (SELECT * FROM BPCONFIG WHERE ID = -20088) BEGIN

GO

print 'End Script KB115533_1200_FN_QC118625_TIMEZONEforID_20088'

GO


[Last Page]

Documents

WFO 12.1 Distributor Technical Reference - Avaya...Avaya Page 2 of 114 Added information regarding SRTP for AMS based recording. Added SIPREC to “Overview and Architecture” section