alcatel-lucent application partner program inter-working report · application category voice...

Alcatel-Lucent Application Partner Program – Inter-working report - Edition 1- page 1/132

Copyright © ALE International 2015

Alcatel-Lucent Application Partner Program Inter-Working Report

Partner: NICE Application type: Voice Recording Systems

(IP DR-Link) Application name: Nice Engage Platform

Alcatel-Lucent Enterprise Platform: OmniPCX Enterprise™

The product and release listed have been tested with the Alcatel-Lucent Enterprise Communication Platform and the release specified hereinafter. The tests concern only the inter-working between the AAPP member’s product and the Alcatel-Lucent Enterprise Communication Platform. The inter-working report is valid until the AAPP member’s product issues a new major release of such product (incorporating new features or functionality), or until ALE International issues a new major release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs. ALE INTERNATIONAL MAKES NO REPRESENTATIONS, WARRANTIES OR CONDITIONS WITH RESPECT TO THE APPLICATION PARTNER PRODUCT. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, ALE INTERNATIONAL HEREBY EXPRESSLY DISCLAIMS ANY AND ALL REPRESENTATIONS, WARRANTIES OR CONDITIONS OF ANY NATURE WHATSOEVER AS TO THE AAPP MEMBER’S PRODUCT INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY, NON INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE AND ALE INTERNATIONAL FURTHER SHALL HAVE NO LIABILITY TO AAPP MEMBER OR ANY OTHER PARTY ARISING FROM OR RELATED IN ANY MANNER TO THIS CERTIFICATE.



Certification overview

Date of the certification 05 to 09 October 2015

ALE International representative Bernard MAREC

AAPP member representative Yaroslav HONCHARUK

Alcatel-Lucent Enterprise Communication Platform

OmniPCX Enterprise

Alcatel-Lucent Enterprise Communication Platform release

R11.1 (L1.301.28.b) TSAPI Server 7.0.9

AAPP member application release NEP 6.3.51

Application Category Voice recording

Author(s): B. Marec Reviewer(s): R. Himmi Revision History Edition 1: creation of the document – October 2015

Test results

Passed

Refused Postponed

Passed with restrictions

Refer to the section 6 for a summary of the test results.

IWR validity extension

None



AAPP Member Contact Information

Contact name: Uri Frieder

Title: Product Manager

Address: 13 Zarhin st.

City: Ra’anana

Country: Israel

Phone: +972 (9) 775-3024

Mobile Phone: +972 (50) 642-8286

Web site: www.nice.com

Email address: [email protected]



TABLE OF CONTENTS

1 INTRODUCTION ..................................................................................................................................................... 10

2 VALIDITY OF THE INTERWORKING REPORT ............................................................................................ 11

3 LIMITS OF THE TECHNICAL SUPPORT ........................................................................................................ 12

3.1 CASE OF ADDITIONAL THIRD PARTY APPLICATIONS ............................................................................................ 12

4 APPLICATION INFORMATION ......................................................................................................................... 13

5 TEST ENVIRONMENT ........................................................................................................................................... 14

5.1 HARDWARE CONFIGURATION ............................................................................................................................. 16 5.2 SOFTWARE CONFIGURATION ............................................................................................................................... 16

6 SUMMARY OF TEST RESULTS ......................................................................................................................... 17

6.1 SUMMARY OF MAIN FUNCTIONS SUPPORTED ....................................................................................................... 17 6.2 SUMMARY OF PROBLEMS .................................................................................................................................... 18 6.3 SUMMARY OF LIMITATIONS ................................................................................................................................ 18 6.4 NOTES, REMARKS ............................................................................................................................................... 18

7 TEST RESULT TEMPLATE ................................................................................................................................. 19

8 TESTS RESULTS FOR IP DR LINK RECORDING .......................................................................................... 20

8.1 INBOUND CALLS.................................................................................................................................................. 20 8.1.1 Test Objectives ........................................................................................................................................... 20 8.1.2 Test Results ................................................................................................................................................ 20

8.2 INTERNAL CALLS ................................................................................................................................................ 21 8.2.1 Test Objectives ........................................................................................................................................... 21 8.2.2 Test Results ................................................................................................................................................ 21

8.3 OUTBOUND CALLS .............................................................................................................................................. 22 8.3.1 Test Objectives ........................................................................................................................................... 22 8.3.2 Test Results ................................................................................................................................................ 22

8.4 TRANSFER OF AN INBOUND CALL – BLIND TRANSFER......................................................................................... 23 8.4.1 Test Objectives ........................................................................................................................................... 23 8.4.2 Test Results ................................................................................................................................................ 23

8.5 TRANSFER OF AN INBOUND CALL – SUPERVISED TRANSFER ............................................................................... 24 8.5.1 Test Objectives ........................................................................................................................................... 24 8.5.2 Test Results ................................................................................................................................................ 24

8.6 TRANSFER OF AN OUTBOUND CALL – BLIND TRANSFER ..................................................................................... 25 8.6.1 Test Objectives ........................................................................................................................................... 25 8.6.2 Test Results ................................................................................................................................................ 25

8.7 TRANSFER OF AN OUTBOUND CALL – SUPERVISED TRANSFER ............................................................................ 26 8.7.1 Test Objectives ........................................................................................................................................... 26 8.7.2 Test Results ................................................................................................................................................ 26

8.8 3 WAY INBOUND CONFERENCE CALL ................................................................................................................. 27 8.8.1 Test Objectives ........................................................................................................................................... 27 8.8.2 Test Results ................................................................................................................................................ 27

8.9 3 WAY INBOUND CONFERENCE CALL – THE THIRD PARTY DROPS OUT FIRST ..................................................... 28 8.9.1 Test Objectives ........................................................................................................................................... 28 8.9.2 Test Results ................................................................................................................................................ 28

8.10 3 WAY INBOUND CONFERENCE CALL – THE CONFERENCER DROPS OUT FIRST & SECOND AGENT NOT RECORDED

29 8.10.1 Test Objectives ........................................................................................................................................... 29 8.10.2 Test Results ................................................................................................................................................ 29

8.11 3 WAY OUTBOUND CONFERENCE CALL ............................................................................................................. 30 8.11.1 Test Objectives ........................................................................................................................................... 30



8.11.2 Test Results ................................................................................................................................................ 30 8.12 3 WAY OUTBOUND CONFERENCE CALL – THE THIRD PARTY DROPS OUT FIRST.................................................. 31

8.12.1 Test Objectives ........................................................................................................................................... 31 8.12.2 Test Results ................................................................................................................................................ 31

8.13 3 WAY OUTBOUND CONFERENCE CALL – THE CONFERENCER DROPS OUT FIRST & SECOND AGENT NOT

RECORDED ...................................................................................................................................................................... 32 8.13.1 Test Objectives ........................................................................................................................................... 32 8.13.2 Test Results ................................................................................................................................................ 32

8.14 CONTACT CENTER : SUPERVISED CALLS : NORMAL LISTENING........................................................................... 33 8.14.1 Test Objectives ........................................................................................................................................... 33 8.14.2 Test Results ................................................................................................................................................ 33

8.15 CONTACT CENTER : SUPERVISED CALLS : RESTRICTED INTRUSION..................................................................... 35 8.15.1 Test Objectives ........................................................................................................................................... 35 8.15.2 Test Results ................................................................................................................................................ 35

8.16 CONTACT CENTER : SUPERVISED CALLS : INTRUSION......................................................................................... 36 8.16.1 Test Objectives ........................................................................................................................................... 36 8.16.2 Test Results ................................................................................................................................................ 36

8.17 CONTACT CENTER : SUPERVISED CALLS : HELP .................................................................................................. 37 8.17.1 Test Objectives ........................................................................................................................................... 37 8.17.2 Test Results ................................................................................................................................................ 37

8.18 CONTACT CENTER : INCOMING PRIVATE CALLS ................................................................................................. 38 8.18.1 Test Objectives ........................................................................................................................................... 38 8.18.2 Test Results ................................................................................................................................................ 38

8.19 CONTACT CENTER : OUTGOING PRIVATE CALLS ................................................................................................ 39 8.19.1 Test Objectives ........................................................................................................................................... 39 8.19.2 Test Results ................................................................................................................................................ 39

8.20 CONTACT CENTER : AGENT WELCOME GUIDE .................................................................................................... 40 8.20.1 Test Objectives ........................................................................................................................................... 40 8.20.2 Test Results : .............................................................................................................................................. 40

8.21 CONTACT CENTER : FREE SEATING .................................................................................................................... 42 8.21.1 Test Objectives ........................................................................................................................................... 42 8.21.2 Test Results : .............................................................................................................................................. 42

8.22 BUSINESS SETS : MULTILINE SETS ...................................................................................................................... 43 8.22.1 Test Objectives ........................................................................................................................................... 43 8.22.2 Test Results : Record lines with the same number ..................................................................................... 43 8.22.3 Test procedure: Record lines with several numbers .................................................................................. 44 8.22.4 Test procedure: Not record several lines ( inbound calls ) ........................................................................ 45

8.23 BUSINESS SETS : MLA FEATURE – SECONDARY MLA SET ANSWERS ................................................................. 46 8.23.1 Test Objectives ........................................................................................................................................... 46 8.23.2 Test Results : .............................................................................................................................................. 46

8.24 BUSINESS SETS : MLA FEATURE – SWAPPING BETWEEN 2 PRIMARY MLA LINES .............................................. 47 8.24.1 Test Objectives ........................................................................................................................................... 47 8.24.2 Test Results : .............................................................................................................................................. 47

8.25 BUSINESS SETS : MLA FEATURE – SWAPPING BETWEEN PRIMARY AND SECONDARY MLA LINES ..................... 48 8.25.1 Test Objectives ........................................................................................................................................... 48 8.25.2 Test Results : .............................................................................................................................................. 48

8.26 BUSINESS SETS : TANDEM .................................................................................................................................. 49 8.26.1 Test Objectives ........................................................................................................................................... 49 8.26.2 Test Results : Inbound call to Main set ...................................................................................................... 49 8.26.3 Test Results : Outbound call from the Main set ......................................................................................... 49 8.26.4 Test Results : Inbound call to Secondary set .............................................................................................. 50 8.26.5 Test Results : Outbound call from the Secondary set ................................................................................. 50

8.27 BEEP GENERATION – SINGLE BEEP ..................................................................................................................... 51 8.27.1 Test Objectives ........................................................................................................................................... 51 8.27.2 Test Results : .............................................................................................................................................. 51

8.28 BEEP GENERATION – SEVERAL BEEPS ................................................................................................................ 51 8.28.1 Test Objectives ........................................................................................................................................... 51 8.28.2 Test Results : .............................................................................................................................................. 51

8.29 COMPRESSION TYPE TESTS .................................................................................................................................. 52 8.29.1 Test objectives ............................................................................................................................................ 52



8.29.2 Test results ................................................................................................................................................. 52

9 NETWORK IP DR LINK RECORDING TESTS ................................................................................................. 53

9.1 SIMPLE CALLS ..................................................................................................................................................... 53 9.1.1 Test Objectives ........................................................................................................................................... 53 9.1.2 Test Results ................................................................................................................................................ 53

9.2 TRANSFER OF AN INBOUND CALL FROM LOCAL TO REMOTE – BLIND TRANSFER ................................................ 55 9.2.1 Test Objectives ........................................................................................................................................... 55 9.2.2 Test Results ................................................................................................................................................ 55

9.3 TRANSFER OF AN INBOUND CALL FROM REMOTE TO LOCAL – BLIND TRANSFER ................................................ 56 9.3.1 Test Objectives ........................................................................................................................................... 56 9.3.2 Test Results ................................................................................................................................................ 56

9.4 TRANSFER OF AN INBOUND CALL BETWEEN 2 NODES – BLIND TRANSFER ........................................................... 57 9.4.1 Test Objectives ........................................................................................................................................... 57 9.4.2 Test Results ................................................................................................................................................ 57

9.5 TRANSFER OF AN INBOUND CALL FROM LOCAL TO REMOTE – SUPERVISED TRANSFER ...................................... 58 9.5.1 Test Objectives ........................................................................................................................................... 58 9.5.2 Test Results ................................................................................................................................................ 58

9.6 TRANSFER OF AN INBOUND CALL FROM REMOTE TO LOCAL – SUPERVISED TRANSFER ...................................... 60 9.6.1 Test Objectives ........................................................................................................................................... 60 9.6.2 Test Results ................................................................................................................................................ 60

9.7 TRANSFER OF AN INBOUND CALL BETWEEN 2 NODES – SUPERVISED TRANSFER ................................................. 61 9.7.1 Test Objectives ........................................................................................................................................... 61 9.7.2 Test Results ................................................................................................................................................ 61

9.8 TRANSFER OF AN OUTBOUND CALL FROM LOCAL TO REMOTE – BLIND TRANSFER ............................................. 62 9.8.1 Test Objectives ........................................................................................................................................... 62 9.8.2 Test Results ................................................................................................................................................ 62

9.9 TRANSFER OF AN OUTBOUND CALL FROM REMOTE TO LOCAL – BLIND TRANSFER ............................................. 63 9.9.1 Test Objectives ........................................................................................................................................... 63 9.9.2 Test Results ................................................................................................................................................ 63

9.10 TRANSFER OF AN OUTBOUND CALL BETWEEN 2 NODES – BLIND TRANSFER ........................................................ 64 9.10.1 Test Objectives ........................................................................................................................................... 64 9.10.2 Test Results ................................................................................................................................................ 64

9.11 TRANSFER OF AN OUTBOUND CALL FROM LOCAL TO REMOTE – SUPERVISED TRANSFER ................................... 65 9.11.1 Test Objectives ........................................................................................................................................... 65 9.11.2 Test Results ................................................................................................................................................ 65

9.12 TRANSFER OF AN OUTBOUND CALL FROM REMOTE TO LOCAL – SUPERVISED TRANSFER ................................... 66 9.12.1 Test Objectives ........................................................................................................................................... 66 9.12.2 Test Results ................................................................................................................................................ 66

9.13 TRANSFER OF AN OUTBOUND CALL BETWEEN 2 NODES – SUPERVISED TRANSFER .............................................. 67 9.13.1 Test Objectives ........................................................................................................................................... 67 9.13.2 Test Results ................................................................................................................................................ 67

9.14 3 WAY INBOUND CONFERENCE CALL – STARTING FROM LOCAL TO REMOTE.................................................... 68 9.14.1 Test Objectives ........................................................................................................................................... 68 9.14.2 Test Results ................................................................................................................................................ 68

9.15 3 WAY INBOUND CONFERENCE CALL – STARTING FROM REMOTE TO LOCAL .................................................... 68 9.15.1 Test Objectives ........................................................................................................................................... 69 9.15.2 Test Results ................................................................................................................................................ 69

9.16 3 WAY OUTBOUND CONFERENCE CALL – STARTING FROM LOCAL TO REMOTE ................................................ 70 9.16.1 Test Objectives ........................................................................................................................................... 70 9.16.2 Test Results ................................................................................................................................................ 70

9.17 3 WAY OUTBOUND CONFERENCE CALL – STARTING FROM REMOTE TO LOCAL ................................................ 71 9.17.1 Test Objectives ........................................................................................................................................... 71 9.17.2 Test Results ................................................................................................................................................ 71

10 RELIABILITY TESTS IN IP DR-LINK – DYNAMIC MODE .......................................................................... 72

IT EXPLAINS WHY IN CASE OF BASIC FAILURES THERE ARE RECORDS IN THE BUSINESS ANALYZER WITHOUT AUDIO.

....................................................................................................................................................................................... 72 10.1 FAILURE TESTS ................................................................................................................................................... 73

10.1.1 Test Objectives ........................................................................................................................................... 73



10.1.2 Test Results : Bad devices .......................................................................................................................... 73 10.1.3 Test Results : Not authorized recording ..................................................................................................... 75 10.1.4 Test Results : IP DR-Link : No Recording when the parameter “DR-Link on IP supported” = FALSE ... 75 10.1.5 Test Results : License not available ........................................................................................................... 76 10.1.6 Test Results : Max Licenses reached ......................................................................................................... 76

10.2 SWITCH FAILURE ................................................................................................................................................ 77 10.2.1 Test Objectives ........................................................................................................................................... 77 10.2.2 Test Results : Switch shutdown .................................................................................................................. 78

10.3 INTERACTION CENTER LINK FAILURE - IP LINK FAILURE ................................................................................... 79 10.3.1 Test Objectives ........................................................................................................................................... 79 10.3.2 Test Results : .............................................................................................................................................. 79

10.4 AIR LOGGER LINK FAILURE – IP LINK FAILURE ................................................................................................ 81 10.4.1 Test Objectives ........................................................................................................................................... 81 10.4.2 Test Results : .............................................................................................................................................. 81

10.5 REDUNDANCY TESTS ( ALCATEL-LUCENT SIDE ) ................................................................................................ 82 10.5.1 Test Objectives ........................................................................................................................................... 82 10.5.2 Test Results : OXE in Spatial Redundancy ............................................................................................... 82 10.5.3 Test Results : OXE in Spatial Redundancy – Switch shutdown ................................................................. 83 10.5.4 Test Results : TSAPI Backup ..................................................................................................................... 84

10.6 REDUNDANCY TESTS (NICE SIDE) : AIR LOGGER FAILURES - LOGGER N +1 ...................................................... 85 10.6.1 Test Objectives ........................................................................................................................................... 85 10.6.2 Test Results : Disconnection of AIR Logger N .......................................................................................... 86 10.6.3 Test Results : Reconnection of the AIR logger N ...................................................................................... 88

10.7 PASSIVE CALL SERVER ....................................................................................................................................... 89 The test environment : ................................................................................................................................................ 89 10.7.1 Test Objectives ........................................................................................................................................... 90 10.7.2 Test Results : IP DR-Link ........................................................................................................................... 90

11 RELIABILITY TESTS IN IP DR-LINK – STATIC MODE .............................................................................. 92

IT EXPLAINS WHY IN CASE OF BASIC FAILURES THERE ARE RECORDS IN THE BUSINESS ANALYZER WITHOUT AUDIO.

....................................................................................................................................................................................... 92 11.1 FAILURE TESTS ................................................................................................................................................... 93

11.1.1 Test Objectives ........................................................................................................................................... 93 11.1.2 Test Results : Bad devices .......................................................................................................................... 93 11.1.3 Test Results : Not authorized recording ..................................................................................................... 94 11.1.4 Test Results : IP DR-Link : No Recording when the parameter “DR-Link on IP supported” = FALSE ... 94 11.1.5 Test Results : License not available ........................................................................................................... 95 11.1.6 Test Results : Max Licenses reached ......................................................................................................... 95

11.2 SWITCH FAILURE ................................................................................................................................................ 96 11.2.1 Test Objectives ........................................................................................................................................... 96 11.2.2 Test Results : Switch shutdown .................................................................................................................. 97

11.3 INTERACTION CENTER LINK FAILURE - IP LINK FAILURE ................................................................................... 98 11.3.1 Test Objectives ........................................................................................................................................... 98 11.3.2 Test Results : .............................................................................................................................................. 98

11.4 AIR LOGGER LINK FAILURE – IP LINK FAILURE .............................................................................................. 100 11.4.1 Test Objectives ......................................................................................................................................... 100 11.4.2 Test Results : ............................................................................................................................................ 100

11.5 REDUNDANCY TESTS ( ALCATEL-LUCENT SIDE ) .............................................................................................. 102 11.5.1 Test Objectives ......................................................................................................................................... 102 11.5.2 Test Results : OXE in Spatial Redundancy ............................................................................................. 102 11.5.3 Test Results : OXE in Spatial Redundancy – Switch shutdown ............................................................... 103 11.5.4 Test Results : TSAPI Backup ................................................................................................................... 104

11.6 REDUNDANCY TESTS (NICE SIDE) : AIR LOGGER FAILURES – AIR LOGGER N +1 ............................................ 105 11.6.1 Test Objectives ......................................................................................................................................... 105 11.6.2 Test Results : Disconnection of AIR Logger N ........................................................................................ 106 11.6.3 Test Results : Reconnection of the AIR logger N .................................................................................... 107

11.7 PASSIVE CALL SERVER ..................................................................................................................................... 108 The test environment : .............................................................................................................................................. 108 11.7.1 Test Objectives ......................................................................................................................................... 109 11.7.2 Test Results : IP DR-Link ......................................................................................................................... 109



11.8 UNDERSTANDING OF THE LOGS FILES ............................................................................................................... 110 11.8.1 Test Objectives ......................................................................................................................................... 110 11.8.2 Test Results .............................................................................................................................................. 110

11.9 NOTIFICATIONS & ALARMS ............................................................................................................................... 110 11.9.1 Test Objectives ......................................................................................................................................... 110 11.9.2 Test Results .............................................................................................................................................. 110

12 CTI PARAMETERS .......................................................................................................................................... 111

13 APPENDIX A : AAPP MEMBER’S APPLICATION DESCRIPTION ....................................................... 112

14 APPENDIX B: CONFIGURATION REQUIREMENTS OF THE AAPP MEMBER’S APPLICATION 114

14.1 PROCEDURE 1: VERIFY SWITCH CONNECTIVITY INFORMATION ........................................................................ 114 14.2 PROCEDURE 2: DEFINE THE ALCATEL-LUCENT OMNIPCX ENTERPRISE LINKS IN THE ..................................... 114 14.3 PROCEDURE 3: UPDATE THE ALCCSTA.CFG FILE ON THE INTERACTIONS CENTER SERVER ................................ 115 14.4 PROCEDURE 4: CTI INTEGRATION CONFIGURATION IN THE NICE SYSTEM ADMINISTRATOR ........................... 116

15 APPENDIX C: ALCATEL-LUCENT ENTERPRISE COMMUNICATION PLATFORM:

CONFIGURATION REQUIREMENTS ..................................................................................................................... 117

15.1 CONFIGURATION FOR DR-LINK ........................................................................................................................ 117 15.1.1 Licenses for DR-Link: .............................................................................................................................. 117 15.1.2 PBX Configuration for DR-Link: ............................................................................................................. 117

15.2 CONFIGURATION FOR IP DR-LINK .................................................................................................................... 119 15.2.1 CSTA parameters ..................................................................................................................................... 119 15.2.2 Phone Facilities Categories parameter ................................................................................................... 120 15.2.3 Recording IP Logger ................................................................................................................................ 120 15.2.4 Quality of service for IP recording parameter (IP / IP Domain) ............................................................. 121 15.2.5 IP DR-Link licenses ................................................................................................................................. 121

15.3 ADDITIONAL PARAMETER FOR DR-LINK & IP DR-LINK: ................................................................................. 121

16 APPENDIX D: AAPP MEMBER’S ESCALATION PROCESS ................................................................... 122

17 APPENDIX E: AAPP PROGRAM .................................................................................................................. 127

17.1 ALCATEL-LUCENT APPLICATION PARTNER PROGRAM (AAPP)........................................................................ 127 17.2 ENTERPRISE.ALCATEL-LUCENT.COM ............................................................................................................... 128

18 APPENDIX F: AAPP ESCALATION PROCESS .......................................................................................... 129

18.1 INTRODUCTION ................................................................................................................................................. 129 18.2 ESCALATION IN CASE OF A VALID INTER-WORKING REPORT ............................................................................ 130 18.3 ESCALATION IN ALL OTHER CASES .................................................................................................................... 131 18.4 TECHNICAL SUPPORT ACCESS ........................................................................................................................... 132



1 Introduction This document is the result of the certification tests performed between the AAPP member’s application and Alcatel-Lucent Enterprise’s platform. It certifies proper inter-working with the AAPP member’s application. The scope of the tests is the interoperability of the application with the Alcatel-Lucent Enterprise Communication Platform. It covers a basic or complex inter-working to ensure that services requested by the application and provided by the Communication Platform (and/or conversely) are properly completed. These tests do not verify the functional achievement of the application as well as they do not cover load capacity checks, race conditions and generally speaking any real customer's site conditions.

These tests do not verify the functional achievement of the application as well as they do not cover load capacity checks, race conditions and generally speaking any real customer's site conditions.

The first installations are used to complete those tests performed in labs with real customer conditions (Beta Test process) The Application Partner is invited to inform ALE International about the results of those fist installations.

Information contained in this document is believed to be accurate and reliable at the time of printing. However, due to ongoing product improvements and revisions, ALE International cannot guarantee accuracy of printed material after the date of certification nor can it accept responsibility for errors or omissions. Updates to this document can be viewed on:

- the Technical Support page of the Enterprise Business Portal (https://businessportal.alcatel-lucent.com) in the Application Partner Interworking Reports corner (restricted to Business Partners)

- the Application Partner portal (https://applicationpartner.alcatel-lucent.com) with free access.

Interworking Certification labels: “Sampling” calls can fit with Quality Management in Contact Center, to record some calls. Installation, error handling and traces are checked for the ALE International interface. In addition to the previous requirements, “Total” means the capability to record all types of calls, for all types of telephone devices, for Contact Center and Business environments and using all CSTA data. Each of those recording levels can run for the different types of connection. The ALE International Dedicated Recording Link can be used for a “Stand alone” site only or for “Networked” in distributed multi-site environment. 2. In addition to the “Sampling” capabilities, “Total” means the call types, for all telephone devices, within both Contact Center and Business environments, and using all CSTA data.

https://businessportal.alcatel-lucent.com/


https://applicationpartner.alcatel-lucent.com/



2 Validity of the InterWorking Report This InterWorking report specifies the products and releases which have been certified. This inter-working report is valid unless specified until the AAPP member issues a new major release of such product (incorporating new features or functionalities), or until ALE International issues a new major release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs. A new release is identified as following:

a “Major Release” is any x. enumerated release. Example Product 1.0 is a major product release.

a “Minor Release” is any x.y enumerated release. Example Product 1.1 is a minor product release The validity of the InterWorking report can be extended to upper major releases, if for example the interface didn’t evolve, or to other products of the same family range. Please refer to the “IWR validity extension” chapter at the beginning of the report.

Note: The InterWorking report becomes automatically obsolete when the mentioned product releases are end of life.



3 Limits of the Technical support

For certified AAPP applications, Technical support will be provided within the scope of the features which have been certified in the InterWorking report. The scope is defined by the InterWorking report via the tests cases which have been performed, the conditions and the perimeter of the testing and identified limitations. All those details are documented in the IWR. The Business Partner must verify an InterWorking Report (see above “Validity of the InterWorking Report) is valid and that the deployment follows all recommendations and prerequisites described in the InterWorking Report.

The certification does not verify the functional achievement of the AAPP member’s application as well as it does not cover load capacity checks, race conditions and generally speaking any real customer's site conditions.

Any possible issue will require first to be addressed and analyzed by the AAPP member before being escalated to ALE International. Access to technical support by the Business Partner requires a valid ALE maintenance contract For any request outside the scope of this IWR, ALE International offers the “On Demand Diagnostic” service where assistance will be provided against payment. For details on all cases (3

rd party application certified or not, request outside the scope of this IWR, etc.),

please refer to Appendix F “AAPP Escalation Process”.

3.1 Case of additional Third party applications

In case at a customer site an additional third party application NOT provided by ALE International is included in the solution between the certified Alcatel-Lucent Enterprise and AAPP member products such as a Session Border Controller or a firewall for example, ALE International will consider that situation as to that where no IWR exists. ALE International will handle this situation accordingly (for more details, please refer to Appendix F “AAPP Escalation Process”).



4 Application information Application family : Voice Recording System Application commercial name: Nice Engage Platform Application version: 6.3.51 (csta64.dll => version 7.0.7) Interface type: TSAPI Premium Server Interface version (if relevant): TSAPI Server 7.0.9

Voice logger Features available Features tested in this report

from the recorder side (Supported by Alcatel-Lucent

Technical Support)

Extension side recording No No

Trunk side recording No No

DR-Link recording :

- Static mode in DR-Link * No No

- Dynamic mode in DR-Link * No No

IP DR-Link recording :

- Static mode in IP DR-link * Yes Yes

- Dynamic mode in IP DR-Link * Yes Yes

Remote DR-Link recording * No No

IP DR-link Network recording * Yes Yes

Mixed recording * No No

IP sniffing Yes No

Free seating Yes Yes

Selective recording Yes Yes

CCD calls Yes Yes

Business calls Yes Yes

Static Mode : The Voice Recording System sends a unique start recording request to the OmniPCXEnterprise for each recorded user at the CSTA connection. Dynamic Mode : The Voice Recording System sends a start recording request to the OmniPCXEnterprise for each conversation of each recorded user.



5 Test environment

Tests Configuration :

TDM DR Link Recording using the Alcatel-Lucent OmniPCX Enterprise and TSAPI. The Voice TDM

logger is connected to PCM2 board on Alcatel-Lucent OmniPCX Enterprise.

Remote TDM DR Link Recording : The OmniPCX Enterprise(s) are connected with ABC-F link to central OmniPCX Enterprise. The Active TDM logger is connected to the central node.

IP DR-Link Recording using the Alcatel-Lucent OmniPCX Enterprise and TSAPI. The VoIP-logger is connected directly to Network of the handsets.

IP DR-Link Network Recording : The OmniPCX Enterprise(s) are connected with ABC-F link to central OmniPCX Enterprise. The VoIP-logger is connected directly to the central node.

Mixed Recording ( Recording between TDM & IP sets ) : selection of the used voice logger ( DR-link logger or IP DR-link logger )

CS

192.168.6.X

( 255.255.255.0 )

192.168.6.X

192.168.6.X

GD

PCM-R2

T2 T2

GA

192.168.6.X

NODE 1

NODE 2

IP DR-Link logger

192.168.6.X

Nice Interaction

TSAPI

CS

192.168.6.X/Y

Main CPU

192.168.4..X

( 255.255.255.0 )

CS

192.168.4.X

Backup CPU GD

PCS

T2

192.168.4.X

192.168.4.X

Passive Call Server192.168.4.1Router

17

2.2

7.1

32

.11

92

.16

8.6

.1

GD

T2 T2

GA

172.27.132.X

172.27.132.X

( 255.255.255.0 )

172.27.132.X 172.27.132.X

192.168.4.X 192.168.4.X

DR-Link logger

192.168.6.X

192.168.6.X

CSCS

192.168.6.X

( 255.255.255.0 )

192.168.6.X

192.168.6.X

GD

PCM-R2

T2 T2

GA

192.168.6.X

GD

PCM-R2

T2 T2

GA

192.168.6.X

NODE 1

NODE 2

IP DR-Link logger

192.168.6.X

IP DR-Link logger

192.168.6.X

Nice Interaction

TSAPI

Nice Interaction

TSAPI

CSCS

192.168.6.X/Y

Main CPU

192.168.4..X

( 255.255.255.0 )

CSCS

192.168.4.X

Backup CPU GD

PCS

T2

192.168.4.X

192.168.4.X

Passive Call Server

GD

PCS

T2

GD

PCS

T2

192.168.4.X

192.168.4.X

Passive Call Server192.168.4.1RouterRouter

17

2.2

7.1

32

.11

92

.16

8.6

.1

GD

T2 T2

GA

172.27.132.X

172.27.132.X

( 255.255.255.0 )

172.27.132.X 172.27.132.X

192.168.4.X 192.168.4.X

DR-Link logger

192.168.6.X

192.168.6.X

VRS



Trunk Recording using the Alcatel-Lucent OmniPCX Enterprise and TSAPI. This method tests Total recording in the Voice Recording Server. The Voice logger is connected on Alcatel OXE with E1, T2 or T0 trunk.

Extension Side Recording using the Alcatel-Lucent OmniPCX Enterprise and TSAPI. This method

tests Total recording. Loggers record directly from extensions and are configured to receive direct parallel inputs to the extensions.

Nice system during the tests:

ç

Operating System => NICE recommendations:

Windows Server 2012 (64 bits)

2 hots fix implemented before starting the tests => will be included in the next

version.

ROUTER

Node 1 ABC-F link

VMware

172.X.Y.57

VMware

172.X.Y.60

VMware

172.X.Y.59

172.X.Y.1

192.X.Y.1

172.X.Z.1

192.X.Y.43

Physical Server : HP Proliant DL380 G7)

-Application

-Interaction

Center

-DataBase

-CTI

AIR Logger 1

CTI

AIR Logger 2

CTI

TSAPI Server 7.0.9

Attention

Air Logger => 100 channels per logger

(the previous solution, VoIP Logger was 24 channels

per logger)

Air Logger supports the features to record Voice Over

IP, screen capture.

Also IP sniffing but not supported by Alcatel-Lucent.

Node 2

192.X.Z.43



5.1 Hardware configuration

List main hardware equipments used for testing

OmniPCX Entreprise: Appliance servers, T2 and PCM interfaces, UA and Z interfaces, IP phones, Digital & analog sets o CS (Call Server Processing Unit) o GD o GA o PCM2 ( MG IVR-Z30 ) o PRA T2 (ISDN Access) o MIX 2/4/4 (Digital & analog interfaces) o UA digital and analog sets o IP Phones

Phones sets : o Agents ( TDM sets ) in principal node : A, B, C o Agents ( IP Phones sets ) in principal node : V1, V2, V3 o Business sets in principal node : M, N o Agents ( TDM sets ) in remote node : RA, RB, RC o Agents ( IP Phones sets ) in remote node : RV1, RV2, RV3

NICE interface: o Interaction Center o AIR logger N and AIR logger N+1

5.2 Software configuration

List main softwares used for testing

Alcatel Communication Platform: OmniPCX Enterprise R11.1 L1.301

TSAPI Premium Server : 7.0.9

Server on which TSAPI is installed : Windows Server 2008 R2 Enterprise (64 bit)

Partner Application : Nice Engage Platform 6.3.51 (csta64.dll -> version 7.0.7)



6 Summary of test results

6.1 Summary of main functions supported

Features

IP D

R-L

ink

Record

ing

Netw

ork

ing

IP D

RLin

k

Sam

plin

g

Tota

l

Comments

Basic calls:

Inbound calls Ok Ok

Outbound Calls Ok Ok

Internal calls Ok Ok

Transfer Ok Ok

3 Way Conference Call Ok Ok

Contact Center :

Supervised Calls

Private incoming calls Ok

Private outgoing calls Na Not supported

Free seating Ok

Business sets :

Multi lines set Ok

MLA sets Ok

Tandem Ok

Beep generation Ok

Reliability

Basic failure Ok

OXE failure Ok

CTI link failure Ok

Redundancy Tests

Spatial redundancy of the OXE Ok

TSAPI backup Ok

High Availability (AIR logger N and AIR logger N+1

Ok

Passive Call Server Ok



6.2 Summary of problems IP DR-Link Network 9.5 Transfer of an inbound call from Local to Remote – Supervised Transfer => Segment duration is not calculated correctly.

NICE Business Analyzer does not display recording icon for interaction in following cases:

Total mode – after start of the call AIR does not receive RTP packets due to any reason (e.g. Recording restriction from OXE side)

Dynamic mode – any negative response from OXE on intrusion requests (e.g. Recording restriction from OXE side)

Dynamic mode – any kind of critical failure during recording (e.g. OXE\TSAPI server disconnection, LAN disconnection)

Dynamic mode – negative rule configured on Nice Interaction Center that prevents call to be recorded

6.3 Summary of limitations Private outgoing calls: this feature is not supported

6.4 Notes, remarks Reliability tests

Failure Tests => there is a recording but no audio => error "No recordings found."



7 Test Result Template The results are presented as indicated in the example below:

Test Case

Id Test Case N/A OK NOK Comment

1

Test case 1

Action

Expected result

2

Test case 2

Action

Expected result

The application waits for PBX timer or phone set hangs up

3

Test case 3

Action

Expected result

Relevant only if the CTI interface is a direct CSTA link

4

Test case 4

Action

Expected result

No indication, no error message

… …

Test Case Id: a feature testing may comprise multiple steps depending on its complexity. Each step has to be completed successfully in order to conform to the test. Test Case: describes the test case with the detail of the main steps to be executed the and the expected result N/A: when checked, means the test case is not applicable in the scope of the application OK: when checked, means the test case performs as expected NOK: when checked, means the test case has failed. In that case, describe in the field “Comment” the reason for the failure and the reference number of the issue either on ALE International side or on AAPP member side Comment: to be filled in with any relevant comment. Mandatory in case a test has failed especially the reference number of the issue.



8 Tests Results for IP DR Link Recording

8.1 Inbound calls

8.1.1 Test Objectives

This test checks that VRS is able to record inbound calls. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.1.2 Test Results

Test Case


1

Inbound call

Make a PSTN inbound call to Agent V1

Agent V1 answers the call and speaks for at least 10 seconds before hanging-up.

1 rec

2

New inbound call

Make an inbound call to Agent V2 ( call is routed through pilot distribution ).


1 rec

3

Check the records in the VRS

In the VRS application, playback the above conversations

Audio OK

Note: Test of the IPTouch 8068 => rec OK, audio OK



8.2 Internal calls


This test checks that VRS is able to record internal calls. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.2.2 Test Results

Test Case


1

Internal call

Make an internal call from Agent 3400 to Agent V2


1 rec

2

New internal call

Make an internal call from Agent V1 to Agent V2 ( call is routed through pilot distribution ).


1 rec

3


In the VRS application, check the records

Audio OK

Note: There are not 2 recordings because it is an internal call => only 1 recording is realized (take the recording of the caller).

In this Test Case ID 1, the Agent 3400.

Test of the IPTouch 8068: recording sis OK, audio is OK.



8.3 Outbound calls


This test checks that VRS is able to record outbound calls . In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.3.2 Test Results

Test Case


1

Outbound call

Make a PSTN outbound call from Agent V1

The external party answers the call and speaks for at least 10 seconds before hanging-up.

2



1 recording Audio OK

Note:

Test of the IPTouch 8068: recording sis OK, audio is OK.



8.4 Transfer of an inbound call – Blind Transfer


This test checks that VRS is able to record blind transferred calls for inbound calls . In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.4.2 Test Results

Test Case


1

Inbound call

Make an inbound call to Agent V1

Agent V1 answers the call and speaks for at least 10 seconds.

2

Enquiry and transfer

Agent V1 makes an internal call to Agent V2 ( the inbound call is automatically put on hold )

Agent V1 transfers the inbound held call to Agent V2

3

Transferred call

Agent V2 answers the call and speaks for at least 10 seconds before hanging-up

4



2 segments Audio OK

Note:

Preview

Segments

Active calls



8.5 Transfer of an inbound call – Supervised Transfer


This test checks that VRS is able to record supervised transferred calls for inbound calls . In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.5.2 Test Results

Test Case


1

Inbound call



2

Enquiry call


Agent V1 and Agent V2 are in conversation

3

Transfer


4

Transferred call

Agent V2 and the external party speak at least during 10 seconds before hanging-up

5



3 segments Audio OK

Note:

Ext caller – Agt

3400

Agt 3400 – Agt 3401

Inbound call Consult Call Transferred call

Agt 3401 – Ext Caller



8.6 Transfer of an outbound call – Blind Transfer


This test checks that VRS is able to record blind transferred calls for outbound calls . In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.6.2 Test Results

Test Case


1

Outbound call

Make an outbound call from Agent V1

The external party answers the call and speaks for at least 10 seconds.

2

Enquiry and transfer

Agent V1 makes an internal call to Agent V2 ( the outbound call is automatically put on hold )

Agent V1 transfers the outbound held call to Agent V2

3

Transferred call


4



2 segments Audio OK



8.7 Transfer of an outbound call – Supervised Transfer


This test checks that VRS is able to record supervised transferred calls for outbound calls . In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.7.2 Test Results

Test Case


1

Outbound call



1 segment

2

Enquiry call



1 segment

3

Transfer


4

Transferred call

Agent V2 and the external party speak at least during 10 seconds before hanging-up

1 segment

5



3 segments Audio OK

Note:



8.8 3 Way Inbound Conference Call


This test checks that VRS is able to record conference calls for inbound calls. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.8.2 Test Results

Test Case


1

Inbound call



1 segment

2

Enquiry call



1 segment

3

Conference

Agent V1 conferences the inbound held call with Agent V2

1 segment

4

Conferenced call

Agent V1 & V2 and the external party speak at least during 10 seconds

5

The conferencer drops out

Agent V1 hangs up

Agent V2 and the external party speak at least during 10 seconds before hanging up

1 segment

6



4 segments Audio OK

Note:



8.9 3 Way Inbound Conference Call – The third party drops out first



8.9.2 Test Results

Test Case


1

Inbound call



2

Enquiry call



3

Conference


4

Conferenced call


5

The third party drops out

Agent V2 hangs up


6



4 segments Audio OK



8.10 3 Way Inbound Conference Call – The conferencer drops out first & second agent not recorded



8.10.2 Test Results

Test Case


1 Agent B not monitored

Check that the agent V2 is not monitored

2

Inbound call



1 segment

3

Enquiry call



1 segment

4

Conference


1 segment

5

Conferenced call


6


Agent V1 hangs up


No segment for the Agent 2 to the Ext Caller because Agent2 is not monitored.

7



3 segments Audio OK



8.11 3 Way Outbound Conference Call


This test checks that VRS is able to record conference calls for outbound calls. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.11.2 Test Results

Test Case


1

Outbound call



2

Enquiry call



3

Conference

Agent V1 conferences the outbound held call with Agent V2

4

Conferenced call


5


Agent V1 hangs up


6



4 segments Audio OK



8.12 3 Way Outbound Conference Call – The third party drops out first



8.12.2 Test Results

Test Case


1

Outbound call

Make an outbound call to Agent V1


2

Enquiry call



3

Conference


4

Conferenced call


5

The third party drops out

Agent V2 hangs up


6



4 segments Audio OK



8.13 3 Way Outbound Conference Call – The conferencer drops out first & second agent not recorded



8.13.2 Test Results

Test Case


1 Agent B not monitored

Check that the agent V2 is not monitored

2

Outbound call

Make an outbound call to Agent V1


3

Enquiry call



4

Conference


5

Conferenced call


6


Agent V1 hangs up


7



3 segments Audio OK



8.14 Contact Center : Supervised Calls : normal listening General remark regarding the supervised calls : The supervisor can use ACD listening in permanently or dynamically ways. The following supervision scenarios are examined :

Normal listening ( the supervisor listens the conversation between the agent and the “customer” )

Restricted Intrusion ( the supervisor can speak to the agent but the “customer” doesn’t hear the supervisor )

Intrusion ( the supervisor, the agent & the “customer” are in conference )

Help of Supervisor ( the agent asks help to the supervisor )

Specific configuration on the PBX :

Create an agent with supervisor function : o User/ACD station = Supervisor o User/Prog keys --> key Number ( 1 for instance ) / function = ACD listening

Affect the agent to a processing group : o Application/CCD/Operators /Operators data management/attaching list ---> Affect the agent

to the processing group number.

Log on the supervisor agent on a Pro-ACD set . The « supervision » tests can be done.


This test checks that VRS is able to record supervised calls. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

8.14.2 Test Results

Test Case


1 Normal listening

A supervisor makes normal listening on Agent V1 in permanent mode.

2

Inbound call

Make an inbound call to Agent V1 ( call is routed through a distribution pilot ).

Agent V1 answers the call

Agent V1 and the external caller speak during at least 10 second before hanging up

3

Check the Agent’s record in the VRS


1 segment for 3410 Audio OK NO segment for Agent V1

Note:

- The record concerns the recorded call (not specific to the agent or the supervisor).

- There is no flag that the supervisor is in inactive mode (so only in listening mode)



ConferenceEvent: Segment is for 3410 because the Initiator Participants is 3410.



8.15 Contact Center : Supervised Calls : restricted intrusion



8.15.2 Test Results

Test Case


1

Inbound call



Agent V1 and the external caller speak during at least 10 second

2 Restricted intrusion

A supervisor makes restricted intrusion on the agent V1 during the conversation

3 End of Agent’s call

The Agent V1 releases the call

4



Idem 8.14.2



8.16 Contact Center : Supervised Calls : intrusion



8.16.2 Test Results

Test Case


1

Inbound call

Make an inbound call to Agent 3400 ( call is routed through a distribution pilot ).

Agent 3400 answers the call

Agent 3400 and the external caller speak during at least 10 second

2 Intrusion

A supervisor makes intrusion on the agent 3400 during the conversation


The Agent 3400 releases the call

4



3 segments Audio OK

Note:

The call is recorded but the displayed of the recording is related to the Supervisor 3410 and the duration of the

Agent 3400 is Null.

So even if the audio is recorded and we are able to listen to the call, this feature has to be rechecked.



8.17 Contact Center : Supervised Calls : help



8.17.2 Test Results

Test Case


1

Inbound call




1 segment (Agent V1)

2 Help

The agent presses “help”

3

Restrictive intrusion of the supervisor

The supervisor makes now a restrictive intrusion during the conversation of the agent V1

1 segment (Supervisor 3410)


The Agent V1 releases the call

1 segment (Supervisor 3410)

5



3 segments Audio OK

Note:



8.18 Contact Center : Incoming Private Calls


This test checks that VRS is able to selectively not record incoming private calls.

Note: To manage private incoming calls, set the parameter: Application / CCD / CCD users / agent xxxx / Private agent number (the number 3020 has been associated as a private number to the Agent 3400)

8.18.2 Test Results

Test Case


1

Inbound call

Make an inbound call to the private Agent’s extension 3020.

Agent 3400 answers the call

Agent 3400 and the external caller speak during at least 10 second

OXE command: ( )> zdpost d 3400 | grep Csta NO recording

2


In the VRS application, check there is no record

A record is displayed. Info of the call (see screenshot below), but no audio.

Note: Rule created in the NICE system to not record the Private number 3020. Decision to not record by the rule is taken at the beginning => that means no channel taken.



8.19 Contact Center : Outgoing Private Calls The aim of these test is to not record private calls from the agent. To manage private outgoing calls, set the parameters: Application / CCD / Processing Group / Outgoing ACD call = False Note : in withdraw state, the agent makes automatically outgoing private call when he makes outbound calls. Note : The “AGENT BUSY” CSTA event ( after the ESTABLISHED event ) is not present for a private outgoing call


This test checks that VRS is able to selectively not record outgoing private calls.

8.19.2 Test Results

Test Case


1 Agent’s state

Check that the agent V1 is in idle state

2

Outbound call

Make an outbound call from the Agent V1

The external party answers the call


3



FEATURE

NOT SUPPORTED



8.20 Contact Center : Agent Welcome guide


This test is intended to see the behaviour of the Voice Recording System when there is an inbound call to an agent ( from a pilot distribution ) which has an agent welcome guide. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call. The management of an Agent Welcome Guide is below:

1- Management of this voice guide : a. Under mgr--> System --> Dynamic voice guides --> Assignment : Create

Sub-message number = 4500 ( 4500 is the first sub-message number used for the agent welcome guide )

ACT-Coupler : Address of one GD board in common hardware ( GPA2 board in crystal hardware )

b. Assign this voice guide to the agent :

Mgr --> Applications --> CCD ---> Operators ---> For the agent : a. Presentation mess. Nb = 4500 b. Presentation mess. File Nb = 1

2- With the phone set of the agent :

a. Login the agent b. Press the “welcome guide” button c. Record the welcome guide d. Download this recorded welcome guide e. Activate this welcome guide

8.20.2 Test Results :

Test Case Id

Test Case N/A OK NOK Comment

1

Management of an agent presentation guide

Login the agent V1 on the proacd P1

Make an inbound call to the agent V1 ( from a pilot distribution )

Logout the agent V1

2

Inbound call


The agent V1 answers the inbound call

The agent V1 & the external party speak for at least 10 seconds before hanging up.

3

Check the record in the VRS

In the VRS application, check the record

Rec is visible and audio is OK.

Note: According to the NEW parameter (not present in the previous NIM platform) “SupportWithHoldAndRetrievedCapiEvents” the result of the test is different: “SupportWithHoldAndRetrievedCapiEvents” to Yes



“SupportWithHoldAndRetrievedCapiEvents” to No

For both the preview is:

During the Agent Welcome

guide is played, the Agent call

is put on hold.

After the Agent Welcome guide is

played, the agent is in conversation

with the External caller.

External caller dials the Agent number

Agent is ringing and then answers to the call

ESTABLISHED event

Due to the Agent Welcome guide management for the Agent, the call is

put on hold

HELD event

The Agent Welcome guide is played the External caller

When the Agent Welcome guide is finished, the External caller and the

Agent are in conversation

RETRIEVED event



8.21 Contact Center : Free Seating


This test checks that VRS is able to take into account free seating system. The agents will log on several stations and the system should be able to selectively recording calls. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.


Test Case Id


1

Agent V1 on proacd P1



Logout the agent V1

1 recording

2

Agent V1 on proacd P2



Logout the agent V1

1 recording

3



Audio OK



8.22 Business Sets : Multiline sets


This test checks that VRS is able to record several calls on the same set. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call. Note: Several scenarios are possible according to the type of multi-line configuration:

* The multi line set has several lines on the same number

* The multi line set has several lines with several numbers

8.22.2 Test Results : Record lines with the same number

Test Case


1

Several lines with the same number

Create 2 multiline keys with the same number ( the number = the phone set 3000 )

2

Inbound call : 1st

call

Make an inbound call to the 1st multiline key

3000 answers the call

3000 and the external caller speak during at least 10 seconds

1 recording (segment 3000)

3

New Inbound call : 2nd

call

Make an inbound call to the 2nd

multiline key

3000 puts on Hold the 1st call

3000 answers the 2nd

call


3000 hangs up the 2nd

call

1 recording (segment 3000)

4

Retrieve the 1st

call

3000 retrieves the 1st call on the 1

st multiline key

3000 and the external party speak during at least 10 seconds

3000 hangs up the call

Continue in the recording

5



Audio is OK

Note:

Inbound call to 300

1st multiline

Retrieves the 1st call

Inbound call to 2nd multiline



8.22.3 Test procedure: Record lines with several numbers

Test Case


1

Several lines with several numbers

Create 2 multiline keys with 2 numbers (numbers are different from the phone set number: 3080 and 3081)

2

Inbound call : 1st

call


M answers the call

M and the external caller speak during at least 10 seconds

1 segment (3080)

3

Outbound call : 2nd

call

M puts on Hold the 1st call

Make an outbound call from the 2nd

multiline key

The external caller answers the call


M hangs up the 2nd

call

1 segment (3081)

4

Retrieve the 1st

call

M retrieves the 1st call on the 1

st multiline key

M and the external party speak during at least 10 seconds

M hangs up the call

Continue to segment 3080

5



2 segments Audio OK



8.22.4 Test procedure: Not record several lines ( inbound calls )

Test Case


1

Several lines with several numbers

Create 2 multiline keys with 2 numbers (numbers are different from the phone set number: 3080 and 3081)

2

Rule to not record these lines

Create a rule in the VRS to not record these 2 numbers

Rule created in the NICE system to not record the 3080 and 3081.

3

Inbound call : 1st

call


M answers the call


4

Inbound call : 2nd

call

Make an inbound call to the 2nd

multiline key

M answers the call


M hangs up the 2nd

call

5

Retrieve the 1st

call

M retrieves the 1st call on the 1

st multiline key


M hangs up the call

6



2 recordings displayed without audio on it, just CSTA info. Same popup as private call (8.18) informing there is no audio.

Note : The test to not record several lines for outbound calls is not done due to a lack of the CSTA information in the OXE part



8.23 Business Sets : MLA Feature – secondary MLA set answers


This test checks that VRS is able to record calls with MLA keys. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call Note : A business set must have a multiline key before the creation of a MLA key


Test Case


1

Primary MLA key on set 3000

Create a Primary MLA key ( with Number 3600) on the phone set 3000

2

Secondary MLA key on set 3001

Create a Secondary MLA key ( with Number 3600 ) on the phone set 3001

3

Inbound call

Make an inbound call to the MLA number 3600

3001 answers the call on the Secondary MLA key ( Number 3600 )


1 recording for 3001

4 On hold

3001 puts on Hold the 1st call

5

Retrieve the call on set 3000

3000 retrieves the call on the Primary MLA key ( number 3600 )




6



Audio is OK

Set 3000 Set 3001

Primary MLA key

Number 3600

Secondary MLA key

Number 3600



8.24 Business Sets : MLA Feature – swapping between 2 Primary MLA lines


This test checks that VRS is able to record calls with MLA keys. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call


Test Case


1

Primary MLA key on set M

Create a Primary MLA key ( with Number 1 ) on the phone set M


2

Inbound call


M answers the call on the Primary MLA key ( Number 1 )


3

New Inbound call


M puts on hold the 1st call

M answers the 2nd

call on the Primary MLA key ( Number 2 )


M hangs up

4

Retrieve the 1st

call

M retrieves the call on the Primary MLA key ( Number 1 )


M hangs up the call

5



Recordings and Audio is oK



8.25 Business Sets : MLA Feature – swapping between Primary and Secondary MLA lines


This test checks that VRS is able to record calls with MLA keys. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call


Test Case Id


1

Primary MLA key on set 3000


2

MLA key on set 3001

Create a Secondary MLA key ( with Number 3600 ) on the phone set 3001

Create a Primary MLA key ( with Number 3602 ) on the phone set 3001

3

Inbound call


3001 answers the call on the Secondary MLA key ( Number 3600 )



3

New Inbound call


3001 puts on hold the 1st call

3001 answers the 2nd

call on the Primary MLA key ( Number 3602 )


3001 hangs up


4

Retrieve the 1st

call

3001 retrieves the call on the Primary MLA key ( Number 3600 )



Continue to the

5



Primary MLA key

Number 3602

Secondary MLA key

Number 3600

Primary MLA key

Number 3600

Set 3000

Set 3001



8.26 Business Sets : Tandem


This test checks that VRS is able to record calls with business sets in tandem. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call Management of the tandem :

1. In the Main & secondary sets, create multiline keys 2. For the Main set, mgr --> users :

a. “Tandem directory Number” = number of the secondary tandem user b. “Main set in the tandem” = YES

8.26.2 Test Results : Inbound call to Main set

Test Case


1

Management of the tandem

Create Multiline keys on the main & the secondary tandem user

Manage the tandem

2

Inbound call

Make an inbound call to the tandem number

The main set answers the call

The main set and the external caller speak during at least 10 seconds before hanging up

3




8.26.3 Test Results : Outbound call from the Main set

Test Case


1



Manage the tandem

2

Outbound call

Make an outbound call from the main set


The main set and the external caller speak during at least 10 seconds before hanging up

3




TANDEM

MAIN SECONDARY

3000 3001



8.26.4 Test Results : Inbound call to Secondary set

Test Case


1



Manage the tandem

2

Inbound call

Make an inbound call to the tandem number

The secondary set answers the call

The secondary set and the external caller speak during at least 10 seconds before hanging up

3




Note: Dialed number is 3000

8.26.5 Test Results : Outbound call from the Secondary set

Test Case


1



Manage the tandem

2

Outbound call

Make an outbound call from the secondary set


The secondary set and the external caller speak during at least 10 seconds before hanging up

3






8.27 Beep Generation – Single Beep


This test checks that VRS supports the generation of a single beep.


Test Case Id


1 Creation of a single beep

Manage a single beep in the VRS

2 Call

Make a call including a recorded device

3 Beep generation

Send a single beep

4



1 recording Audio OK (Beep is heard)

Note: management in the NICE system beepToneFrequency: 21 beepToneSilenceDuration: 0

8.28 Beep Generation – Several Beeps


This test checks that VRS supports the generation of several beeps.


Test Case Id


1 Creation of the generation of several beeps

Manage the generation of several beeps in the VRS

2 Call

Make a call including a recorded device

3 Beeps generation

Send several beeps

4



1 recording Audio ok (beeps are heard)

Note: management in the NICE system beepToneFrequency: 21 beepTonePresenceDuration: 5 beepToneSilenceDuration: 0



8.29 Compression type tests

3 codecs can be managed on the OXE: G711, G729, G723 Specific configuration on the PBX:

Check the compression type on the system parameter o System/Other System Param./Compression Parameters

Compression Type: G729 (or G723)

Modify according to the requested test the compression type linked to the IP Phone and the GD board

o IP/IP Phones Parameters Default Voice Coding Algorithm + Without Compression (or With Compression)

o INTIP B and GD Parameters Default Voice Coding Algorithm + Without Compression (or With Compression)

To verify the compression type which is used for an IP call from IP Phone, you have to mirror the IP Phone. From wireshark software, the RTP event will show you the compression type.

8.29.1 Test objectives This test checks that VRS is able to record in different codecs (G711, G729 or G723).

8.29.2 Test results

Test Case Id


1 G711

Make a call in G711

2 G723

Make a call in G723

3 G729

Make a call in G729

4



Audio is OK



9 Network IP DR Link Recording Tests The following test cases intend to record calls over the WAN ( Network OXE in full IP ).

9.1 Simple calls


This test checks that VRS is able to record simple calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.1.2 Test Results

Test Case


1 Network call : OXE1 --> OXE2

Make a call from Agent V1 to Remote Agent RV1

Remote Agent RV1 answers the call and speaks for at least 10 seconds before hanging-up.

2 recordings

2

Network call : OXE2 --> OXE1

Make a call from Remote Agent RV1 to local Agent V1


2 recordings

3



Audio OK

Note:

There are 2 recordings => it is explained by there are 2 OXEs (Node 1 and Node 2 in ABC-F network). Same “Full Name” because the best participant if the caller (3400).



Test Case ID: 2



9.2 Transfer of an inbound call from Local to Remote – Blind transfer


This test checks that VRS is able to record transfer inbound calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.2.2 Test Results

Test Case


1

Inbound call to local node


Agent V1 answers the call and speaks for at least 10 seconds

Segment 3400

2

Enquiry and transfer to remote node

Agent V1 makes a network call to Remote Agent RV1 ( the inbound call is automatically put on hold )

Agent RV1 transfers the inbound held call to Remote Agent RV1

3

Transferred call

Remote Agent RV1 answers the call and speaks for at least 10 seconds

Segment 6400

4

Internal transfer

Remote Agent RV1 makes an internal call to Remote Agent RV2 ( the inbound call is automatically put on hold )

Remote Agent RV1 transfers the inbound held call to Remote Agent RV2

5

Transferred call

Remote Agent RV2 answers the call and speaks for at least 10 seconds before hanging-up

Segment 6401

6



2 recordings Audio OK



9.3 Transfer of an inbound call from Remote to Local – Blind transfer



9.3.2 Test Results

Test Case


1

Inbound call to remote node

Make an inbound call to Remote Agent RV1


2

Enquiry and transfer to local node

Remote Agent RV1 makes a network call to Agent V1 ( the inbound call is automatically put on hold )

Remote Agent RV1 transfers the inbound held call to Agent V1

3

Transferred call


4

Internal transfer



5

Transferred call


6



Audio OK



9.4 Transfer of an inbound call between 2 nodes – Blind transfer



9.4.2 Test Results

Test Case


1




2



Agent V1 transfers the inbound held call to Remote Agent RV1

3

Transferred call


4

Transfer to local node


Remote Agent RV1 transfers the inbound held call to Agent V2

5

Transferred call


6



Audio OK



9.5 Transfer of an inbound call from Local to Remote – Supervised Transfer



9.5.2 Test Results

Test Case


1




2

Enquiry to remote node


Agent V1 and Remote Agent RV1 speak at least 10 seconds

3 Transfer

Agent V1 transfers the enquiry call

4

Transferred call

Remote Agent RV1 and the external party speak for at least 10 seconds

5

Internal Enquiry

Remote Agent RV1 makes an internal call to Remote Agent RV2 ( the inbound call is automatically put on hold )

Remote Agent RV1 and Remote Agent RV2 speak at least 10 seconds

6 Transfer

Remote Agent RV1 transfers the enquiry call

7

Transferred call

Remote Agent RV2 and the external party speak for at least 10 seconds before hanging-up

8



Note: See next page.



Test Case ID: 1 and 2

Test Case ID: 2 to 7

Segment duration is not calculated correctly. Link to the fact that after sending the SnapshotDevice request, the NICE system receives “Connection State” equal to Null for any agent. Problem of segment is analyzing by NICE.

External caller calls the

Agent 3400

2 :36 :39 2 :36 :52 2 :36 :59

Consult call from 3400 to

6400

Agent 3400 transfers the

call

Duration : 20s

indicated 20s, but

should be 13s

7s



9.6 Transfer of an inbound call from Remote to Local – Supervised Transfer



9.6.2 Test Results

Test Case


1

Inbound call to Remote node



2

Enquiry to local node



3 Transfer


4

Transferred call

Agent V1 and the external party speak for at least 10 seconds

5

Internal Enquiry


Agent V1 and Agent V2 speak at least 10 seconds

6 Transfer


7

Transferred call

Agent V2 and the external party speak for at least 10 seconds before hanging-up

8



Audio OK Pb segment duration



9.7 Transfer of an inbound call between 2 nodes – Supervised Transfer



9.7.2 Test Results

Test Case


1

Inbound call to Local node



2

Enquiry to Remote node



3 Transfer


4

Transferred call


5

Enquiry to Local node


Remote Agent RV1 and Agent V2 speak at least 10 seconds

6 Transfer


7

Transferred call


8



Audio OK Pb segment duration



9.8 Transfer of an outbound call from Local to Remote – Blind transfer


This test checks that VRS is able to record transfer outbound calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.8.2 Test Results

Test Case


1

Outbound call from local node


External caller answers the call and speaks for at least 10 seconds

2


Agent V1 makes a network call to Remote Agent RV1 ( the outbound call is automatically put on hold )

Agent RV1 transfers the outbound held call to Remote Agent RV1

3

Transferred call


4

Internal transfer

Remote Agent RV1 makes an internal call to Remote Agent RV2 ( the outbound call is automatically put on hold )

Remote Agent RV1 transfers the outbound held call to Remote Agent RV2

5

Transferred call

Remote Agent RV2 answers the call and speaks for at least 10 seconds before hanging-up

6



Audio OK



9.9 Transfer of an outbound call from Remote to Local – Blind transfer



9.9.2 Test Results

Test Case


1

Outbound call from remote node

Make an outbound call from Remote Agent RV1


2

Enquiry and transfer to local node

Remote Agent RV1 makes a network call to Agent V1 ( the outbound call is automatically put on hold )

Remote Agent RV1 transfers the outbound held call to Agent V1

3

Transferred call


4

Internal transfer



5

Transferred call


6



Audio OK



9.10 Transfer of an outbound call between 2 nodes – Blind transfer



9.10.2 Test Results

Test Case


1




2


Agent V1 makes a network call to Remote Agent RV1( the outbound call is automatically put on hold )

Agent V1 transfers the outbound held call to Remote Agent RV1

3

Transferred call


4

Transfer ro local node


Remote Agent RV1 transfers the outbound held call to Agent V2

5

Transferred call


6



Audio OK



9.11 Transfer of an outbound call from Local to Remote – Supervised Transfer



9.11.2 Test Results

Test Case


1




2




3 Transfer


4

Transferred call


5

Internal Enquiry

Remote Agent RV1 makes an internal call to Remote Agent RV2 ( the outbound call is automatically put on hold )

Remote Agent RV1 and Remote Agent RV2 speak at least 10 seconds

6 Transfer


7

Transferred call

Remote Agent RV2 and the external party speak for at least 10 seconds before hanging-up

8



Audio OK



9.12 Transfer of an outbound call from Remote to Local – Supervised Transfer



9.12.2 Test Results

Test Case


1

Outbound call from Remote node



2

Enquiry to local node



3 Transfer


4

Transferred call

Agent V1 and the external party speak for at least 10 seconds

5

Internal Enquiry


Agent V1 and Agent V2 speak at least 10 seconds

6 Transfer


7

Transferred call


8



Audio OK



9.13 Transfer of an outbound call between 2 nodes – Supervised Transfer



9.13.2 Test Results

Test Case


1

Outbound call from Local node



2

Enquiry to Remote node



3 Transfer


4

Transferred call


5



Remote Agent RV1 and Agent V2 speak at least 10 seconds

6 Transfer


7

Transferred call


8



Audio OK



9.14 3 Way Inbound Conference Call – Starting From Local to Remote


This test checks that VRS is able to record inbound conference calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.14.2 Test Results

Test Case


1




2




3

Conference

Agent V1 presses the “conference” button

Agent V1, Remote Agent RV1 and the external party speak for at least 10 seconds before Agent V1 hangs up

4



Audio OK

Note:

The call from External caller and the 3400 started at 17:09:10. The following view has been taken at the consult call between 3400 and 6400.

9.15 3 Way Inbound Conference Call – Starting From Remote to Local




This test checks that VRS is able to record inbound conference calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.15.2 Test Results

Test Case


1

Inbound call to Remote node



2




3

Conference

Remote Agent RV1 presses the “conference” button

Agent V1, Remote Agent RV1 and the external party speak for at least 10 seconds before Agent RV1 hangs up

4



Audio OK



9.16 3 Way Outbound Conference Call – Starting From Local to Remote


This test checks that VRS is able to record outbound conference calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.16.2 Test Results

Test Case


1




2




3

Conference

Agent V1 presses the “conference” button

Agent V1, Remote Agent RV1 and the external party speak for at least 10 seconds before Agent V1 hangs up

4



Audio OK



9.17 3 Way Outbound Conference Call – Starting From Remote to Local


This test checks that VRS is able to record outbound conference calls through ABC-F2 link. In addition, the call-details retrieved from the CSTA link should be inserted to the VRS calls database. Then, using the Query application, it should be possible to playback the audio of this call.

9.17.2 Test Results

Test Case


1

Outbound call from Remote node



2




3

Conference

Remote Agent RV1 presses the “conference” button

Agent V1, Remote Agent RV1 and the external party speak for at least 10 seconds before Agent RV1 hangs up

4



Audio oK



10 Reliability tests in IP DR-Link – Dynamic mode

TESTS below in DYNAMIC mode IMPORTANT NOTE : Nice Engage Platform works in a multi TSAPI clients architecture as following :

1- From CSTA point of view, the Interaction Server is useful : For the registration of the Nice in the OXE

The IC sends the CSTA request to the OXE via the TSAPI server: “Escape Service Register” For the monitoring of the recordable devices of the OXE The IC sends the CSTA request to the OXE via the TSAPI server: “Monitor device = Device_Id” 2- From CSTA point of view, the AIR Logger is useful : For the registration of the Nice in the OXE

The AIR logger sends the CSTA request to the OXE via the TSAPI server: “Escape Service Register” For the start and stop IP Recording of the devices of the OXE The AIR logger sends the CSTA request to the OXE via the TSAPI server: “Start IP Recording : Device_ID, IP@ of the logger, port X1, port X2”

In case of the following basic failures, the IP logger and the Interaction Center are aware that it is not possible to record, as they receive an error answer of the OXE regarding the “Start IP Recording” request. Nevertheless, the Interaction Center creates automatically a record in the Business Analyzer without taking into account the error message of the OXE regarding the “Start IP Recording” request.

It explains why in case of basic failures there are records in the Business Analyzer without audio.

Interaction

Center

AIR

Logger



10.1 Failure Tests


The list of tests below intends to check the behaviour of VRS in case of failure or wrong configuration. More especially if the notification messages (or alarms) are relevant for administrator to help investigate the possible issues.

10.1.2 Test Results : Bad devices

This test is intended to check the behaviour of the VRS to not record in IP DR-link a non IP device

Test Case


1 Management of the recording of a TDM set in the VRS

Declare the recording of a set which is not a serie 8 ( UA, Z, serie 9… )

2 Record in IP DR-link

Try to record in IP DR-link ( send a “Start IP Recording” event from the VRS ) the set

3



In the VRS application, check the logs…

Recording displayed but no audio associated.

Note: Error displayed



Warning when trying to open the recording:



10.1.3 Test Results : Not authorized recording

This test is intended to check the behaviour of VRS to not record a device which is not authorized

Test Case


1 Record authorization = False

In the Phone Features Category of the set, put the “Record Authorization” = False

Used extension 3000

2 Try to Record

Make a call with the set

Try to record the set

3




1 recording is displayed but no audio.

Note:

10.1.4 Test Results : IP DR-Link : No Recording when the parameter “DR-Link on IP supported” = FALSE

This test is intended to check the behaviour of the VRS to not record a VoIP when DR-Link on IP is not supported. This boolean is in mgr --> Applications --> CSTA -->“DR-link on IP supported” = False.

It means that the IP Phones must not be recorded in IP DR-Link.

Test Case


1 “DR-link on IP supported” = FALSE

Manage the parameter “DR-Link on IP supported” = False

2

Record in IP DR-link

Try to record in IP DR-link ( send a “Start IP Recording” event from the VRS ) a monitored VoIP set

3




1 recording is displayed nut no audio.

Note:



10.1.5 Test Results : License not available This test is intended to check the behaviour of VRS to not record a device when the licenses are not available

Test Case


1 License file with no recording licenses

Put a new license file with no recording ( lock 334 = 0 )

2 Try to Record



3




1 recording is displayed but no audio

Note: error “security violation” The OXE command zdpost d 3000 | grep Csta shows the result: NO recording.

10.1.6 Test Results : Max Licenses reached This test is intended to check the behaviour of VRS to not record a device when the licences are reached

Test Case


1 License file with limited recording licenses

Put a new license file with limited recording ( lock 334 with limited value )

Lock 334 = 1

2 Try to Record

Try to record the set when the limited recording license is reached

3




Recording to 3000 (IP Phone) No recording for 3001 (IP Phone)

Note: error “Outstanding request limit exceeded” Simultaneous calls : inbound call to 3000, inbound call to 3001



10.2 Switch Failure


This test is intended to check the recovering of the VRS after a Switch failure. The switch has only one CPU. Test environment :

DATA CENTER 1

172.X.144.X

Mask : 255.255.255.0

Call Server 1

( Active )

Interaction

Center

AIR Logger N

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

DOMAIN 0

Primary Link

WAN

TSAPI Server

172.X.139.X

Mask : 255.255.255.0

172.X.139.210

DATA CENTER 2

172.X.144.60

172.X.144.57

172.X.144.53



10.2.2 Test Results : Switch shutdown

Test Case


1

Inbound call

Make an inbound call to 3000

3000 and the external party speak for at least 10 seconds

05:01:00 pm

2

Outbound call

Make an outbound call from 3001

3001 and the External party speak for at least 10 seconds

05:01:15 pm

3 Internal call

Make an internal call from V3 to V4

V3 and V4 speak for at least 10 seconds

4 Switch failure

Reboot the OXE 05:02:00 pm

5




Lost of IP Phone at 05:02:18 pm

6

New calls after the reboot

Perform new calls ( internal, inbound & outbound calls )

7


In the VRS application, check the new records



Note:

ConnectionManager (Interaction Center)

After OXE restarting => [172.X.139.210] (NICE…) 6 monitorings



10.3 Interaction Center Link Failure - IP link Failure


This test is intended to check the recovering of the Nice System after an Interaction Center Link failure with an IP link Failure. In the test, one Call server is used, one IC and one VoIP logger


The test consists to unplug the IP cable of the Interaction Center.

Test Case


1 Management of “End Of Recording on end of calls”

Manage the parameter “End of Recording on end of calls” = YES

2 Internal call

Make an internal call from 3000 to 3005

V1 and V2 speak for at least 10 seconds

3000 is monitored 3005 not monitored Call at 05:44:00 pm

3 IP Link failure

Unplug the IP cable of the Interaction Center

VMware 172.27.144.57 (network deactivated) 05:47:00 pm

4 Call still continues

5 Check the status of the IP Phone on the OXE

IP recording status for the device 3000

6 IP Link reconnection

Plug the IP cable of the Interaction Center 05:49:20 pm

7 Stop the call 05:49:40

8





Note: Even after the network disconnection of the Interaction Center, the IP Phone 3000 still continues to send its audio. Another test:

Manage the parameter “End of Recording on end of calls” = YES -1- External call to the IP Phone 3000 IP recording status for the device 3000 from the OXE (zdpost command) -2- Network disconnection of the Interaction Center (05:58:00) -3- IP recording status for the device 3000 from the OXE -4- 06:02:00 pm, end of the call (1 recording , audio OK, recording stopped after the hang up of the call) -5- New call, Interaction Center is still without network connected -6- still IP recording status for the device 3000 It seems that the AIR Logger works as total because the 3000 is still IP recording mode after the hang up of the call.



Another test: No call is established, Interaction Center has the network disconnected -1- external call to the IP Phone 3000 -2- 3000 is NO recording status for OXE point of view -3- AIR Logger is not able to send StartIP Recording due to the IC has not network connected.



10.4 AIR Logger Link Failure – IP Link Failure


This test is intended to check the recovering of the VRS after an AIR Logger Link failure with an IP link failure.


In the test, one Call server is used, one Interaction Center and one AIR logger

Test Case




2 Incoming call

Make an incomingl call to V1 (3000)

V1 speak for at least 10 seconds

06:22:00 pm IP recording status from the OXE for the 3000

3 IP Link failure

Unplug the IP cable of the VoIP logger

08:24:00 (network deactivated)

4

End of calls

Stop the current calls

06:25:00 pm At end of the call, still IP recording


Plug the IP cable of the VoIP logger

06:26:00 Network reconnected

6 Check the records in the VRS




7

New calls

Perform a new call incoming call to V1 (3000)

06:28:00 pm

8





Note: Test Case Id 3 => after the IP network link is disconnected, the recording status of the device 3000 (from the OXE: zdpost command) is still IP recording. Test Case Id 5 => after the reconnection of the IP link, the recording status (OXE) is still IP recording. parameter “End of Recording on end of calls” = NO, same behaviour.

recording

06 :22 :00 pm 06 :24 :00 pm



10.5 Redundancy Tests ( Alcatel-Lucent side )


These tests are intended to check the recovering of the Voice Recording System using redundancy elements.

10.5.2 Test Results : OXE in Spatial Redundancy

In this test, both CPUs are used in spatial redundancy ( in different IP sub networks ).

WAN

DATA CENTER 1

172.27.144.X

Mask : 255.255.255.0

Call Server 1

( Active )

Interaction

Center

DATA CENTER 3

172.27.145.X

Mask : 255.255.255.0

Call Server 2

( Stand By )

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

DOMAIN 0

Primary Link

AIR Logger

TSAPI Server

172.X.139.X

Mask : 255.255.255.0

172.X.139.210

DATA CENTER 2

172.X.144.53

172.X.145.53

172.X.144.57

172.X.144.60



10.5.3 Test Results : OXE in Spatial Redundancy – Switch shutdown

Test Case


1

Management of the CPUs

Manage both CPUs in two IP sub networks

Check that the spatial redundancy is managed


CS Main : 172.X.144.53 CS St by : 172.X.145.53

2

Inbound call

Make an inbound call to V3

V3 and the External party speak for at least 10 seconds

09:17:30 am

3

Outbound call

Make an outbound call from V4

V4 and the external party speak for at least 10 seconds

09:18:00 am

4 Switchover of the OXE

Switchover the Main CPU

Check the new Main CPU ( CS2 ) is coming up

Check the new CTI link ( IC1 & CS2 ) is up

09:18:30 am

5

End of calls


09:20:40 am

6




2 recordings (end of the recordings 09:19:36 am) Audio OK

7

New calls

Perform a new inbound call to V3

Perform a new outbound call from V4

8




2 recordings Audio OK (audio icon is OK)

Note: The Call Server “Stand By” becomes MAIN. The connection of the NICE is OK: [172.X.139.210] (NICE ) 5 monitorings 09:19:36 am => time at which the NICE TSAPI client has detected the lost of the OXE MAIN. No audio icon seen from the NICE interface.



10.5.4 Test Results : TSAPI Backup

This test is intended to check the recovering of the Voice Recording System with a TSAPI server backup installed on a dedicated machine.

Test Case


1

Management of the TSAPI server Backup

Check that the TSAPI server Backup is installed ( on a dedicated machine ), configured and running

TSAPI Backup: 172.X.139.212

2

Inbound call



09:57:33 am

3

Outbound call



09:57:50 am

4 Stop the Main Alcatel Open Telephony service

Stop the main Alcatel-Lucent’s service (Alcatel Open Telephony).

Wait until TSAPI Backup is Up

09:59:00 am

5

End of calls


10:00:00 am OXE command zdpost shows “NO recording”

6




2 recordings Audio OK (Audio icon is ok shown)

7

New calls

Perform a new internal call between V1 & V2



TSAPI Backup is UP

8




2 recordings Audio OK (audio icon is OK)

Note: 09:59:48 am [172.X.139.212] (NICE ) 5 monitorings End of recording at 9:59:00 am which corresponds to the stopping of the Primary TSAPI Server service. Configuration in the NICE system: Interface connection details => change parameter

UseWarmStandbyFeature => NO to Yes After this modif, we have access to the Secondary Server ID tab, and we enter

ALCATEL#link1#CSTA#172.X.139.212 Also in the file alccsta.cfg file, we add:

link1 172.X.139.212 2555



10.6 Redundancy Tests (Nice side) : AIR Logger Failures - logger N +1


These tests are intended to check the recovering of the Voice Recording System using AIR logger failures Management : The loggers N and N+1 are configured as Normal and Slave

WAN

DATA CENTER 1

172.X.144.X

Mask : 255.255.255.0

Call Server 1

( Active )

Interaction

Center

AIR Logger N

AIR Logger N+1

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

DOMAIN 0

Primary Link

172.X.144.59

172.X.144.60

TSAPI Server

172.X.139.X

Mask : 255.255.255.0

172.X.139.210

DATA CENTER 2



10.6.2 Test Results : Disconnection of AIR Logger N

This test is intended to check the recovering of VRS when the AIR logger N is disconnected.

Test Case


1 Management


2

Inbound call



3 Disconnection of the logger N

For the IP disconnection of the AIR logger N, this is done in the software of the AIR logger N

10:26:00 am

4

End of calls


10:26:30 am

5




6

New calls


AIR Logger N still disconnected AIR Logger N+1 connected (active)

7




1 recording audio OK

Note: From the logs RCM: status of the AIR Logger before the disconnection of the AIR Logger N

AIR Logger N disconnection:

Recording from the NICE interface:

AIR Logger N

AIR Logger N+1



AIR N+1 recording

Stored on AIR Logger N but

disconnected so record not

accessible



10.6.3 Test Results : Reconnection of the AIR logger N

This test is intended to check the recovering of VRS when the AIR logger N is reconnected.

As soon as the AIR Logger N is reconnected, the AIR Logger N+1 stays in Active

mode and the AIR Logger N becomes is Spare.

Test Case


1 Current state

The AIR logger N is unplugged

2

Inbound call



3

Outbound call



4 Reconnection of the AIR logger N

For the IP reconnection of the AIR logger N, this is done in the software of the AIR logger N

5

End of calls


6




2 recordings Audio OK (on AIR Logger N+1)

Note:

After AIR Logger N is reconnected



10.7 Passive Call Server

The test environment :

TSAPI SERVER 1

172.X.139.210

DATA CENTER 1

Call Server 1

( Active )

Interaction

Center

WAN

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

PCS

DOMAIN 0

AIR Logger

172.X.144.X

Mask : 255.255.255.0 172.X.139.X

Mask : 255.255.255.0

192.168.6.212

TSAPI SERVER 2

The TSAPI Server 2 will be able to connect only the IP @ of the

Passive Call Server.

From TSAPI Manager => managed the Passive Call Server IP @

192.168.6.57

In the alccsta.cfg file of the AIR Logger, we have :

link1 172.X.139.210 3595

and we add :

link1 192.168.6.212 3595

192.168.6.57




This test is intended to check the recovering of the Voice Recording System in case of network failure when the Main& StandBy CPU become not available. In this case the Passive Call Server is started and ensure basic telephonic services.

In this case, the AIR Logger ( for IP DR-Link ) must follow several conditions :

is located with the remote media gateway embeds a TSAPI server which is connected to the Passive Call Server is configured with a second CTI link connected to embedded TSAPI

10.7.2 Test Results : IP DR-Link

Test Case


1 Management of the Passice Call Server

Manage a Passive Call Server in the OXE

2 Management of the IP Logger

Creation of a second CTI Link in the “alccsta.cfg” file of the IP logger, link attached to the PCS

The 1st link in the

“alccsta.cfg” file is attached to the CPUs Main

3

Network failure

Unplug the IP cables of the Main & the Stby CPU

Unplug the IP cables of IC server

The Passive Call Server is isolated and the remote media gateway reboots automatically

The Passive Call Server is now linked to the TSAPI of the “ remote” Logger

PCS is Active IP Phone reset to connect the PCS IP Phone: NO recording status in the OXE

4

Inbound calls


V3 & the external party speak for at least 10 seconds before hanging up

5

Outbound calls



6

Check if there are the records in the logger

Check the records in the logger


No recording, AIR Logger is not able to send the CSTA events. This is the role of the IC.

7

Network reconnection

Plug the IP cable of the Main & the Standby CPU

The remote media gateway reboots automatically

The Logger is now reconnected with the Voice Recording System

Call Server is UP IC is UP The PCS is Inactive

8

Synchronization – Retrieving data

Check that the Voice Recording Server retrieve these records

9

New calls

Perform new calls : oubound & inbound calls

IC is able to get the CSTA events, so the AIR Logger can send



the appropriate StartIP recording.




2 recordings Audio is OK

Note:

On the Passive Call Server => telnet localhost 2555

[192.168.6.212] (NICE )

5 monitorings



11 Reliability tests in IP DR-Link – Static mode

TESTS below in STATIC mode

Static mode is named Total mode in the NICE terms. The StartIP recording request is sent by the AIR Logger at the TSAPI Server connection. That means, IP Phone is in IP recording status until the TSAPI Server is running. The StartIP recording is not sent after each ESTABLISHED event as a DYNAMIC mode. IMPORTANT NOTE : Nice Engage Platform works in a multi TSAPI clients architecture as following :

1- From CSTA point of view, the Interaction Server is useful : For the registration of the Nice in the OXE

The IC sends the CSTA request to the OXE via the TSAPI server: “Escape Service Register” For the monitoring of the recordable devices of the OXE The IC sends the CSTA request to the OXE via the TSAPI server: “Monitor device = Device_Id” 2- From CSTA point of view, the AIR Logger is useful : For the registration of the Nice in the OXE

The AIR logger sends the CSTA request to the OXE via the TSAPI server: “Escape Service Register” For the start and stop IP Recording of the devices of the OXE The AIR logger sends the CSTA request to the OXE via the TSAPI server: “Start IP Recording : Device_ID, IP@ of the logger, port X1, port X2”

In case of the following basic failures, the IP logger and the Interaction Center are aware that it is not possible to record, as they receive an error answer of the OXE regarding the “Start IP Recording” request. Nevertheless, the Interaction Center creates automatically a record in the Business Analyzer without taking into account the error message of the OXE regarding the “Start IP Recording” request.

It explains why in case of basic failures there are records in the Business Analyzer without audio.

Interaction

Center

AIR

Logger



11.1 Failure Tests


The list of tests below intends to check the behaviour of VRS in case of failure or wrong configuration. More especially if the notification messages (or alarms) are relevant for administrator to help investigate the possible issues.

11.1.2 Test Results : Bad devices

This test is intended to check the behaviour of the VRS to not record in IP DR-link a non IP device

Test Case


1 Management of the recording of a TDM set in the VRS

Declare the recording of a set which is not a serie 8 ( UA, Z, serie 9… )

2 Record in IP DR-link

Try to record in IP DR-link ( send a “Start IP Recording” event from the VRS ) the set

3




No recording



11.1.3 Test Results : Not authorized recording

This test is intended to check the behaviour of VRS to not record a device which is not authorized

Test Case


1 Record authorization = False

In the Phone Features Category of the set, put the “Record Authorization” = False

2 Try to Record

Make a call with the set 3000


Static mode: zdpost d 3000 | grep Csta IP recording

3




1 recording. Popup “No recordings found” displayed when trying to open the recording.

Note: We don’t see errors in the StreamObserver of the AIR Logger.

11.1.4 Test Results : IP DR-Link : No Recording when the parameter “DR-Link on IP supported” = FALSE

This test is intended to check the behaviour of the VRS to not record a VoIP when DR-Link on IP is not supported. This boolean is in mgr --> Applications --> CSTA -->“DR-link on IP supported” = False.

It means that the IP Phones must not be recorded in IP DR-Link.

Test Case


1 “DR-link on IP supported” = FALSE

Manage the parameter “DR-Link on IP supported” = False

2

Record in IP DR-link

Try to record in IP DR-link ( send a “Start IP Recording” event from the VRS ) a monitored VoIP set

3







11.1.5 Test Results : License not available This test is intended to check the behaviour of VRS to not record a device when the licenses are not available

Test Case


1 License file with no recording licenses

Put a new license file with no recording ( lock 334 = 0 )

2 Try to Record



3





Note: In the AIR Logger StreamObserver logs, we got following info and error: Request MONITOR_DEVICE Rqt_INTRUDE_TO_CALL (ResourceID=3000) Got RESPONSE from CTI link _CM_RST_FAILURE ERROR Code:19 – SECURITY_VIOLATION

11.1.6 Test Results : Max Licenses reached This test is intended to check the behaviour of VRS to not record a device when the licences are reached

Test Case


1 License file with limited recording licenses

Put a new license file with limited recording ( lock 334 with limited value )

2 Try to Record

Try to record the set when the limited recording license is reached

3




1 recording OK and 1 recording no audio. Popup “No recordings found” displayed when trying to open the recording.



11.2 Switch Failure


This test is intended to check the recovering of the VRS after a Switch failure. The switch has only one CPU. Test environment :

WAN

DATA CENTER 1

172.27.144.X

Mask : 255.255.255.0

Call Server 1

( Active )

Interaction

Center

AIR Logger N

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

DOMAIN 0

Primary Link

TSAPI Server

172.X.139.X

Mask : 255.255.255.0

172.X.139.210

DATA CENTER 2



11.2.2 Test Results : Switch shutdown

Before starting the calls (Test Case Id 1 and 2), the recording status of the IP Phones is IP recording.

Test Case


1

Inbound call



2

Outbound call



4 Switch failure

Reboot the OXE

01:11:00 pm (switch failure) 01:11:30 pm (IP Phone restart)

5




2 recordings (end of the recording 01:11:31 pm) Audio OK

6

New calls after the reboot

Perform new calls ( internal, inbound & outbound calls )

Recording status of the IP Phone is IP recording.

7





Note: Recording is stopped when the IP Phone restart.



11.3 Interaction Center Link Failure - IP link Failure


This test is intended to check the recovering of the VRS after an Interaction Center Link failure with an IP link Failure. In the test, one Call server is used, one Interaction Center and one AIR logger


The test consists to unplug the IP cable of the Interaction Center.

Test Case




2 Inbound call

Make an inbound call to the set 3000

3000 speak for at least 10 seconds

02:54:25 pm

3 IP Link failure

Unplug the IP cable of the Interaction Center

02:55:30 pm

4 Let’s the call going on


Plug the IP cable of the Interaction Center

02:57:30 TSAPI events: Query Device.

6

End of calls


02:58:35 pm

7




1 recording Audio OK Duration of the recording is 00:01:45. (no audio icon in the NICE interface)

Note: Check on the OTS Maintenance interface (option 521 1) if TSAPI events are produced after the IP disconnection of the Interaction Center.

The IP disconnection of the IC is link as a lost of ONE TSAPI client for the TSAPI Server. But the AIR Logger is still running and has a CTI (TSAPI client) connected to the TSAPI Server also. So from the OXE (CSTA) we have still the link UP and typed NICE with the monitorings.

No TSAPI events are produced after the IP disconnection of the IC. The recording is stopped at 02:56:10 pm, so about 40sec after the IP link failure of the Interaction Center. We don’t see any requests sent to the TSAPI Server to stop the recording.



Another test: parameter “End of Recording on end of calls” = NO

-1- zdpost d 3000 | grep Csta IP recording -2- incoming call to the 3000 02:32:20 pm -3- Interaction Center IP disconnection 02:33:15 pm TSAPI events => no events produced The zdpost for the 3000 is still IP recording -4- Interaction Center reconnection 02:36:20 pm TSAPI events => QueryDevice -5- End of the call 02:38:30 pm TSAPI events=> ConnectionCleared

From the NICE interface, 1 recording is displayed (Audio OK). The duration is 1min22sec. The IP Phone is still IP recording status (so it continues to duplicate the audio stream to the IP address of the AIR Logger). But the recording is stopped after 1min22sec so at about 02:33:42 pm. The Interaction Center is stopped at 02:33:15 pm. That means the Nice system takes about 30 sec to detect the lost of the Interaction Center and to stop the recording.



11.4 AIR Logger Link Failure – IP Link Failure


This test is intended to check the recovering of the VRS after an AIR Logger Link failure with an IP link failure.


In the test, one Call server is used, one IC and one AIR logger

Test Case




2 Incoming call

Make an incoming call to 3000

3000 speak for at least 10 seconds

04:10:40 pm

3 IP Link failure

Unplug the IP cable of the VoIP logger 04:11:55 pm

4

End of calls


04:12:50 pm End of the call


Plug the IP cable of the AIR logger N

AIR logger N is reconnected 04:14:45 pm

6




1 recording (end of recording at 04:12:47 pm) Audio OK

7

New calls

Perform an incoming call to 3000

8





Note: Recording goes to the end of the call.


Duration :

2min10sec



-1- zdpost d 3000 | grep Csta IP recording -2- incoming call to the set 3000 02:07:40 pm -3- AIR logger N IP disconnection 02:08:55 pm Check the TSAPI events from the OTS Maintenance interface (option 521 1) => no events -4- End of the call 02:10:10 pm TSAPI events: ConnectionCleared -5- AIR logger N IP reconnection 02:11:45 pm TSAPI events: StartIP recording for all the devices Recording (Audio OK) Audio during 1min17sec (between 3000 answers to the call to the AIR logger disconnection) Recording total is 2min31sec (between 3000 answers to the end of the call)


-1- zdpost d 3000 | grep Csta IP recording -2- incoming call to the set 3000 02:16:20 pm -3- AIR logger N IP disconnection 02:17:20 pm Check the TSAPI events from the OTS Maintenance interface (option 521 1) => no events -4- AIR logger N IP reconnection 02:19:00 pm

TSAPI events: StartIP recording for all the devices

zdpost d 3000 | grep Csta IP recording -5- End of the call 02:20:50 pm 1 recording (Audio OK) , duration is 4min32sec We have the audio which continues after the IP reconnection of the AIR logger N.



11.5 Redundancy Tests ( Alcatel-Lucent side )


These tests are intended to check the recovering of the Voice Recording System using redundancy elements.

11.5.2 Test Results : OXE in Spatial Redundancy

In this test, both CPUs are used in spatial redundancy ( in different IP sub networks ).

WAN

DATA CENTER

1

172.X.144.X

Mask : 255.255.255.0

Call Server

1

( Active )

Interaction

Center 1

DATA CENTER 3

172.X.145.X

Mask : 255.255.255.0

Call Server

2

( Stand By )

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

DOMAIN

0

Primary Link

AIR Logger

TSAPI Server

172.X.139.X

Mask : 255.255.255.0

172.X.139.210

DATA CENTER 2



11.5.3 Test Results : OXE in Spatial Redundancy – Switch shutdown

Test Case


1

Management of the CPUs

Manage both CPUs in two IP sub networks

Check that the spatial redundancy is managed


2

Inbound call



3

Outbound call



4

Switchover of the OXE

Switchover the Main CPU

Check the new Main CPU ( CS2 ) is coming up

Check the new CTI link ( IC1 & CS2 ) is up

5

End of calls


6




2 recordings Audio is OK

7

New calls




8





Note: The Call Server Stand-By becomes MAIN: [172.X.139.210] CSTA (NICE ) 5 monitorings



11.5.4 Test Results : TSAPI Backup

This test is intended to check the recovering of the Voice Recording System with a TSAPI server backup installed on a dedicated machine.

Test Case


1 Management of the TSAPI server Backup

Check that the TSAPI server Backup is installed ( on a dedicated machine ), configured and running

TSAPI Backup 172.X.139.212

2

Inbound call



01:56:00 pm

3

Outbound call



01:56:10 pm

4

Stop the Main Alcatel Open Telephony service

Stop the main Alcatel-Lucent’s service (Alcatel Open Telephony).

Wait until TSAPI Backup is Up

01:56:50 pm (stop the service) 01:57:38 (TSAPI Backup is connected to the OXE)

5

End of calls


01:58:01 pm

6




2 recordings Audio OK End of the recording at the stop of the TSAPI Server service.

7

New calls




8





Note: On the OXE:

telnet localhost 2555 1 [172.X.139.210] CSTA (NICE ) 5 monitorings

TSAPI Backup connected Client 1 is lost (the service has been stopped) [172.X.139.212] CSTA (NICE ) 01:57:38 pm 5 monitorings



11.6 Redundancy Tests (Nice side) : AIR Logger Failures – AIR logger N +1


These tests are intended to check the recovering of the Voice Recording System using AIR logger failures Management : The AIR loggers N and N+1 are configured as Normal and Slave

WAN

DATA CENTER 1

172.X.144.X

Mask : 255.255.255.0

Call Server 1

( Active )

Interaction

Center

AIR Logger N

AIR Logger N+1

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

DOMAIN 0

TSAP

I

TSAPI Server

172.X.139.X

Mask : 255.255.255.0

172.X.139.210

DATA CENTER 2



11.6.2 Test Results : Disconnection of AIR Logger N

This test is intended to check the recovering of VRS when the AIR logger N is disconnected.

Test Case


1 Management

Manage the parameter “End of Recording on end of calls” = YES OR NO

3

Inbound call



03:41:30 pm

4

Outbound call



03:41:50 pm

5 Disconnection of the logger N

For the IP disconnection of the logger N, this is done in the software of the logger N

03:43:00 pm AIR logger N disconnected (IP) AIR logger N+1 still connected

6

End of calls


03:43:58 pm

7




2 recordings Audio OK End of the recordings at 03:43:58 pm

8

New calls



AIR logger N+1 is Active AIR logger N is still disconnected (IP)

9







11.6.3 Test Results : Reconnection of the AIR logger N

This test is intended to check the recovering of VRS when the AIR logger N is reconnected.

Test Case


1 Current state

The logger N is unplugged

3

Inbound call



4

Outbound call



5 Reconnection of the logger N

For the IP reconnection of the logger N, this is done in the software of the logger N

AIR logger N is reconnected (IP): status Spare AIR logger N+1 is Active

6

End of calls


7




2 recordings Audio OK Recording on the AIR logger N+1

8

New calls




9







11.7 Passive Call Server

The test environment :

DATA CENTER 1

Call Server 1

( Active )

Interaction

Center

TSAPI Server 1

WAN

192.168.6.X

Mask : 255.255.255.0

IP Phone

IP Phone

GD

PCM-R2

T2 T2

GA

PCS

DOMAIN 0

AIR Logger

172.X.144.X

Mask : 255.255.255.0

TSAPI Server 2

192.168.6.212

The TSAPI Server 2 will be able to connect only the IP @ of the

Passive Call Server.

From TSAPI Manager => managed the Passive Call Server IP @

192.168.6.57

In the alccsta.cfg file of the AIR Logger, we have :

link1 172.X.139.210 3595

and we add :

link1 192.168.6.212 3595

192.168.6.57

172.X.139.X

Mask : 255.255.255.0

172.X.139.210




This test is intended to check the recovering of the Voice Recording System in case of network failure when the Main& StandBy CPU become not available. In this case the Passive Call Server is started and ensure basic telephonic services. In this case, the Logger ( for IP DR-Link ) must follow several conditions :

is located with the remote media gateway embeds a TSAPI server which is connected to the Passive Call Server is configured with a second CTI link connected to embedded TSAPI

11.7.2 Test Results : IP DR-Link

Test Case


1

Management of the Passice Call Server

Manage a Passive Call Server in the OXE PCS is INACTIVE

Passive Call Server 192.168.6.57 TSAPI Server 2 192.168.6.212

2 Management of the IP Logger

Creation of a second CTI Link in the “alccsta.cfg” file of the IP logger, link attached to the PCS

The 1st link in the

“alccsta.cfg” file is attached to the CPUs Main & Stand-By

3

Network failure

Unplug the IP cables of the Main & the Stby CPU

The Passive Call Server is isolated and the remote media gateway reboots automatically

The Passive Call Server is now linked to the TSAPI of the “ remote” Logger

zdpost d 3000 IP recording

4

Inbound calls



5

Check if there are the records in the logger

Check the records in the logger


IC is not reconnected so not possible yet to check the recordings.

6

Network reconnection

Plug the IP cable of the Main & the Standby CPU

The remote media gateway reboots automatically

The Logger is now reconnected with the Voice Recording System

Interaction Center reconnected.

7

Synchronization – Retrieving data

Check that the Voice Recording Server retrieve these records

Recording retrieve about 10 minutes after the IC is reconnected.

8

New calls

Perform new calls : inbound calls

9





Note: file alccsta.cfg of the TSAPI Server 2 includes the link: link1 192.168.6.212 3595

CS MAIN / PCS Inactive

[172.X.139.210] (NICE)

5 monitorings

zdpost d 3000

IP recording

Parameter for

synchronization :

In the TRS => op_call

duration : 600 ms

(by default is set to 3 hours)



11.8 Understanding of the logs files


This test is intended to check the understanding of the log files of the VRS. We consider three levels or notes : Poor, Good, Very Good. Alcatel-Lucent has to add a comment in order to justify the note.

11.8.2 Test Results

Test Case Note Comments

Understanding of the log files of the Recording System Good

Debug mode can be activated for the different NICE components (like Driver, ConnectionManager, StreamObserver...)

11.9 Notifications & alarms


This test is intended to check the notifications & alarms of the Voice Recording System. We consider three levels or notes : Poor, Good, Very Good. Alcatel-Lucent has to add a comment in order to justify the note.

11.9.2 Test Results

Test Case Note Comments

Notifications & Alarms of the Voice Recording System Good



12 CTI parameters

Following CTI information (extracted from CSTA events) are stored in the VRS database

Type Information N/A OK NOK

Calculated

Duration

CSTA Standard Events

Start Time

Stop Time

DNIS

ANI

Direction ( In / Out )

Agent ID

Call ID (create a coumpound ID based on the Call ID)

Alcatel-Lucent private CSTA

Agent Name (NOT directly from the CSTA, but by the info entered in the NICE system)

Agent Group

Pilot Name (by business data in NICE)

Associate Data

Associate station

Global Callid



13 Appendix A : AAPP member’s Application description

Solution description

NICE Engage Platform offers reliable and resilient call recording, providing the ability to capture, store and maintain customer interactions such as telephone, chat and email conversations in the form of voice, text and screen activity.

Additional capabilities include:

Central, cost-effective management of multi-site environments with central user administration, reporting, playback and querying

Enterprise scalability for all sizes and types of environments including consolidated data center and hub-and-spoke IT architectures

Multi-channel text interaction recording of chat, email, SMS and customer feedback

Business continuity including solutions for continuous call recording, call archiving, and disaster recovery

Centralized storage management integrating with enterprise storage systems and leveraging existing resources

Powerful data security including end-to-end media encryption, strong user authentication and server hardening

Server and client virtualization to reduce the amount of resources consumed

Nice Engage 6.3 provides two recording modes:

Total Recording. Records all interactions for all connected inputs: All interactions are recorded, regardless of the availability of CTI connection. Total recording is usually used for compliance recording.

Interaction-based recording. Records selected interactions based on filter criteria: The user selects complete or parts of interactions to be recorded according to a predefined schedule or criteria (for example, interactions to and from the sales department). Interaction-based Recording can be: Rule-Based, Statistical for QM or ROD (Recording on Demand), it is usually used for Quality Monitoring.



Nice Engage 6.3 provides several methods for capturing voice:

Active VoIP Recording using IP DR Link. In active VoIP recording using IP DR Link, the NICE Advanced Interaction Recorder (AIR) is communicating with the OmniPCX Enterprise PBX to initiate recording. The IP extension is actually doing the replication of the RTP packets to the AIR. The solution is available for OmniPCX Enterprise 8.0 or higher and requires the use of TSAPI Server R6.3.1 or higher.

In a networked environment more than one OmniPCX Enterprise PBX is in control. Even though both OmniPCX Enterprise PBXs can be recorded using a single NICE Advanced Interaction Recorder (AIR), the AIR needs to communicate with a different TSAPI Server in order to initiate the recording. Each TSAPI Server will be responsible for forwarding the duplication request to its OmniPCX Enterprise PBX. A single Interactions Center can be used.

Passive VoIP recording. In passive recording, the network switch is duplicating the RTP packets to the NICE Advanced Interaction Recorder (AIR) using a dedicated mirroring port on the network switch.

.



14 Appendix B: Configuration requirements of the AAPP member’s application

14.1 Procedure 1: Verify Switch Connectivity Information The first step in setting up the Alcatel-Lucent OmniPCX Enterprise on-site, is to verify switch connectivity information. Switch connectivity parameters include the following:

Retrieve the Alcatel TSAPI Server connection string

Get the complete list of Agent IDs/stations to be monitored and recorded

Get the user name and password if the Alcatel OXE server access is protected.

14.2 Procedure 2: Define the Alcatel-Lucent OmniPCX Enterprise Links in the

Hosts File For each link (node) in your configuration, you must define the switch IP address and the link name in the NICE Interaction Center’s hosts file. Each link must have a unique name. EXAMPLE:

Name the first link nice. Name the second link nice1. Name the third link nice2.

Figure 1 – Hosts file example



When you configure links in the Alcatel TSAPI Server installation, you must enter the identical link names that you defined in the hosts file (one by one) in the Add PBX Link window. To define links in the hosts file:

In the NICE Interaction Center, locate C:\windows\system32\drivers\etc. Open the hosts or lmhost file in a text editor.

Define the Alcatel-Lucent OmniPCX Enterprise IP address and host name for each link (node).

Select File > Save, then Exit (see Figure 1)

14.3 Procedure 3: Update the Alccsta.cfg file on the Interactions Center server

Having TSAPI Server properly configured, you must verify that the Alccsta.cfg file of the NICE Integration component reflects these configuration details. To update the Alccsta.cfg file:

On the TSAPI server, go to Start > Programs > Alcatel TSAPI Client, click Alccsta.cfg. The Allccsta.cfg file opens (see Figure 2)

Scroll down to the end of the file and copy the lines with the server names.

On the Interactions Center server, go to Nice Systems\CTI and open Alccsta.cfg file.

Scroll down to the end of the file and paste the previously copied lines with the server names. Save and close.

Figure 2 - Alccsta.cfg file



14.4 Procedure 4: CTI Integration configuration in the NICE System Administrator

Please refer to Nice Engage Platform release 4.1 integration guide that is available on link –

http://www.extranice.com/EIS/ProductDocumentation/EngagePlatform/Documents/Alcatel-

Lucent%20OmniPCX%20(OXE)%20Active%20Recording%20Connectivity%20-%20Engage%20-%206.3.pdf

http://www.extranice.com/EIS/ProductDocumentation/EngagePlatform/Documents/Alcatel-Lucent%20OmniPCX%20(OXE)%20Active%20Recording%20Connectivity%20-%20Engage%20-%206.3.pdf

http://www.extranice.com/EIS/ProductDocumentation/EngagePlatform/Documents/Alcatel-Lucent%20OmniPCX%20(OXE)%20Active%20Recording%20Connectivity%20-%20Engage%20-%206.3.pdf



15 Appendix C: Alcatel-Lucent Enterprise Communication Platform: configuration requirements

15.1 Configuration for DR-Link

15.1.1 Licenses for DR-Link: Following licenses are required:

lock 130 : to specify the type of voice recording system used. "0" if no voice recording system is connected. "1" if a Nice Systems recording system is used.

"2" for other systems (eTalk…).

lock 145 : the value must be set to the simultaneous recording requests number

(maximum 600)

15.1.2 PBX Configuration for DR-Link:

Two steps are required: Step 1: Declare the PCM2 board as a “IVR-Z30” board and do not forget to set the following parameters

“Networking recording use” to “True”.

“IVR protocol” to “No IVR Protocol”



Step 2: Create new users on this Z30 board by declaring analog sets with a physical location on this board (30 phone numbers must be defined in the Phonebook). Start from Equipment Address 1 until 30.



15.2 Configuration for IP DR-Link

15.2.1 CSTA parameters

Parameter 1 : Set to TRUE the “DR-Link on IP supported” parameter.

Parameter 2 : “End of recording on end of call” :

According to the behaviour requested by the customer, modify the value of this parameter to stop ( or not ) the recording of a device before the end of call.

This parameter is only available in IP DR-Link ( not in DR-Link )

Remark :The recording stays active until the “Stop IP Recording” is requested even if the

device becomes out of service.

1

2



15.2.2 Phone Facilities Categories parameter

The configuration parameter “Record Authorization” in Categories / Phone Facilities Categories inside the menu ‘Rights’ is affected to allow the System administrator to authorize the recording of a category of users.

15.2.3 Recording IP Logger

Declare all IP loggers thanks this menu.



15.2.4 Quality of service for IP recording parameter (IP / IP Domain)

If necessary, configure the “Quality of service for IP recording” to have a different TOS/DiffServ for recording ( in order not to disturb voice communications).

15.2.5 IP DR-Link licenses

There are two software locks related to DR-Link on IP :

lock 130 : to specify the type of voice recording system used. "0" if no voice recording system is connected. "1" if a Nice Systems recording system is used.

"2" for other systems (Verint, Retia, ASC, eTalk, ...).

lock 334 : gives the maximum IP recording flows available

15.3 Additional parameter for DR-Link & IP DR-Link:

During a system configuration it is possible to precise the quantity of maximum authorized monitoring. By default this value is set to 1000 but through ACTIS it can be increase to 3000 max



16 Appendix D: AAPP member’s escalation process

Main Contact Information

Main Location Additional Location Additional Location

Address NICE Systems Ltd. 22

Zarhin Street P.O. Box 690 Ra'anana 4310602 Israel

NICE Systems Inc.

461 From Road Paramus New Jersey 07652 USA

NICE CTI Systems UK 160

Queen Victoria Street

London, EC4V 4BF

ENGLAND

Main Telephone +972 9 775 3777 +1 201 964-2600

+1 866 999-NICE

+44 (0) 207 002 3000

+44 (0) 148 977 1633

Main Fax +972 9 743 4282

+972 9 775 3222

+1 201 964-2610 +44 (0) 207 002 3030

General E-mail [email protected] [email protected] [email protected]

3rd Party Contacts

Name Role Phone Email

Shabi Levi Director, Partners ＆

Alliances

+972 (9) 775-3825 [email protected]

Uri Frieder Connectivity Product

Manager

+972 9 775 3024 [email protected]



3rd Party Support Contact Information Requests for support (SRs) arrive at NICE through a variety of channels, including phone, email, alarm or via the NICESupport web portal. Support requests can be open 24x7 at the NICE Customer Support Portal http://www.extranice.com/NICESupport

NICE International call center 22 Zarhin St. Raanana, Israel Tel: + (972) 9-775-3800/333 Fax: +972-9-775-3000

Email: [email protected]

Available 8-20:00. GMT+2 After hours (18-8): at the same telephone number for eligible customers only. Manager: Bubu Wicnudel Tel: +972 9 769 7313 Email: [email protected]

NICE Systems Inc. 7604 Technology Way 5

th floor

Denver, CO 80237 Tel: 1-800-NICE611 (800-642-3611)

GMBH office Grosse Gallusstrass 9 60311 Frankfurt Main Tel: +49(0) 69-971-77111 Fax: +49(0) 69-971-77200


Available 9-18. GMT+1 After hours (18-9): at + (972) 9-775-3800/333 for eligible customers only.

NICE APAC Customer Support Helpdesk Area – 3 Quadrant, 8th Floor Tower – 1,Umiya Business Bay, Marathahalli – Sarjapur Outer Ring Road, Bangalore – 560 103 India

Support Tel: +91 80 30 78 17 00


http://www.extranice.com/NICESupport



3rd Party Support Detail

General Information

NICE’s maintenance concept is based on a four skill level structure. Where the first and second tiers mainly represent

the regional NICE customer support for post installation maintenance issues and the Professional Services Engineer and

Installation HelpDesk for installation support. The third and fourth Tiers are the global Advanced Support Group and

the Engineering Services within NICE’s R&D organization. The table below summarizes the maintenance Skill levels,

their respective activities, and tasks.

Majority of agreements are either :

24*7: The customer is entitled to receive support seven days a week, 24 hours a day, regardless of CSC

working hours.

Monday – Friday 09:00-18:00 Local Time

Support Level Definitions

Level Description

Tier 1 In most cases, the initial handling of the SR is executed by the Tier 1 Customer Support Representative (T1 CSR). A T1 CSR is a technical engineer responsible for opening the SR, performing initial troubleshooting and, if necessary, escalating the SR and transferring ownership to a higher technical level.

Tier 2 Tier 2 Customer Support Representative (T2 CSR) is a technical engineer of a higher

technical level, who is responsible for identifying both the issue and the required

solution, as then implementing the solution and closing the SR, to the customer’s

approval and satisfaction. in most cases the T2 engineer owns the case start to finish

and handles all customer contact, even if the case is escalated higher. A T2 CSR will

usually be the customer’s POC (Point of Contact) within NICE.

Tier 3 The Advanced Support Group (ASG) engineers represent the global support tier, and have a very

wide range of technical expertise. When an issue or solution cannot be identified, the T2 CSR

engages the ASG engineers, who then take responsibility for identifying both the issue and the

solution, as well as frequently updating the internal NICE team working on the SR.

Tier 4 The R&D team are engaged by ASG for cases of high complexity, when the highest level of expertise is required to identify the issue, or when changes in code are required to enable a solution.

Severity Description and Response Times (These are not what we follow – see relevant

information in our welcome doc sent separately)

Severity Description Response Time

Critical Critical customer business impact: A failure in the operation of the NICE Solution or NICE Solution Component in a production environment, which results in a critical impact on a customer’s business. No available workaround.

Initial CS – 60 minutes

Restore – 24H

Resolve – 5D

High Significant customer business impact. Can be either of the following:

1. An intermittent failure in the operation of the NICE Solution

or NICE Solution Component in a production environment,

which results in significant impact on a customer’s business.

2. A failure in the operation of the Solution or Solution

Component in a lab or development environment, which

results in critical impact on said environment. No available

workaround.

Initial CS – 120 minutes

Resolve – 5D



Medium Minimal customer business impact: A non-essential problem which

results in diminished functionality of the Solution or Solution

Component where the NICE products are substantially operational.

Includes reported issues with NICE documentation.

CS – 9 hours (following business day)

Resolve – 10D

Low No business impact: There are issue(s) and/or question(s) related to the Solution or Solution Component, but there is no impact on customer operations.

CS – 9 hours (following business day)

Call Flow Description



Escalation Contacts Title Name Phone Number Receipt of request and entitlement

NICE International call center EMEA

Tel: + (972) 9-775-3800/333

Fax: +972-9-743-4282 [email protected]

NICE Americas

Tel: 800-642 3611

NICE APAC Customer Support

Tel: +852 8338-9818

Fax: +852 2802-1800

Tier 1 & 2 Determine severity

VP, Customer

Support, Americas

Mark Irish Tel: +1 (720) 264-4391 [email protected]

EMEA CS Director

Bubu Wicnudel Tel: +972 97697313 [email protected]

APAC CS Director

Santosh Quadras Tel: +91-9886693491 [email protected]

ASG

VP Advanced Support

Gon Nivron Tel: + (972) 9-775- 3007 [email protected]

Vice President, Global Support

Mark Rooney

Tel: +1 720.264.4122 [email protected]



17 Appendix E: AAPP program

17.1 Alcatel-Lucent Application Partner Program (AAPP)

The Application Partner Program is designed to support companies that develop communication applications for the enterprise market, based on Alcatel-Lucent Enterprise's product family. The program provides tools and support for developing, verifying and promoting compliant third-party applications that complement Alcatel-Lucent Enterprise's product family. ALE International facilitates market access for compliant applications. The Alcatel-Lucent Application Partner Program (AAPP) has two main objectives:

Provide easy interfacing for Alcatel-Lucent Enterprise communication products: Alcatel-Lucent Enterprise's communication products for the enterprise market include infrastructure elements, platforms and software suites. To ensure easy integration, the AAPP provides a full array of standards-based application programming interfaces and fully-documented proprietary interfaces. Together, these enable third-party applications to benefit fully from the potential of Alcatel-Lucent Enterprise products.

Test and verify a comprehensive range of third-party applications: to ensure proper inter-working, ALE International tests and verifies selected third-party applications that complement its portfolio. Successful candidates, which are labelled Alcatel-Lucent Enterprise Compliant Application, come from every area of voice and data communications.

The Alcatel-Lucent Application Partner Program covers a wide array of third-party applications/products designed for voice-centric and data-centric networks in the enterprise market, including terminals, communication applications, mobility, management, security, etc.



Web site The Application Partner Portal is a website dedicated to the AAPP program and where the InterWorking Reports can be consulted. Its access is free at http://applicationpartner.alcatel-lucent.com

17.2 Enterprise.Alcatel-Lucent.com

You can access the Alcatel-Lucent Enterprise website at this URL: http://www.enterprise.alcatel-lucent.com/

http://applicationpartner.alcatel-lucent.com/

http://www.enterprise.alcatel-lucent.com/



18 Appendix F: AAPP Escalation process

18.1 Introduction

The purpose of this appendix is to define the escalation process to be applied by the ALE International Business Partners when facing a problem with the solution certified in this document. The principle is that ALE International Technical Support will be subject to the existence of a valid InterWorking Report within the limits defined in the chapter “Limits of the Technical support”. In case technical support is granted, ALE International and the Application Partner, are engaged as following:

(*) The Application Partner Business Partner can be a Third-Party company or the ALE International Business Partner itself



18.2 Escalation in case of a valid Inter-Working Report

The InterWorking Report describes the test cases which have been performed, the conditions of the testing and the observed limitations. This defines the scope of what has been certified. If the issue is in the scope of the IWR, both parties, ALE International and the Application Partner, are engaged: Case 1: the responsibility can be established 100% on ALE International side.

In that case, the problem must be escalated by the ALE Business Partner to the ALE International Support Center using the standard process: open a ticket (eService Request –eSR)

Case 2: the responsibility can be established 100% on Application Partner side.

In that case, the problem must be escalated directly to the Application Partner by opening a ticket through the Partner Hotline. In general, the process to be applied for the Application Partner is described in the IWR.

Case 3: the responsibility can not be established.

In that case the following process applies:

The Application Partner shall be contacted first by the Business Partner (responsible for the application, see figure in previous page) for an analysis of the problem.

The ALE International Business Partner will escalate the problem to the ALE International

Support Center only if the Application Partner has demonstrated with traces a problem on the ALE International side or if the Application Partner (not the Business Partner) needs the involvement of ALE International

In that case, the ALE International Business Partner must provide the reference of the Case Number on the Application Partner side. The Application Partner must provide to ALE International the results of its investigations, traces, etc, related to this Case Number.

ALE International reserves the right to close the case opened on his side if the investigations made on the Application Partner side are insufficient or do not exist.

Note: Known problems or remarks mentioned in the IWR will not be taken into account. For any issue reported by a Business Partner outside the scope of the IWR, ALE International offers the “On Demand Diagnostic” service where ALE International will provide 8 hours assistance against payment . IMPORTANT NOTE 1: The possibility to configure the Alcatel-Lucent Enterprise PBX with ACTIS quotation tool in order to interwork with an external application is not the guarantee of the availability and the support of the solution. The reference remains the existence of a valid InterWorking Report. Please check the availability of the Inter-Working Report on the AAPP (URL: https://private.applicationpartner.alcatel-lucent.com) or Enterprise Business Portal (Url: Enterprise Business Portal) web sites. IMPORTANT NOTE 2: Involvement of the ALE International Business Partner is mandatory, the access to the Alcatel-Lucent Enterprise platform (remote access, login/password) being the Business Partner responsibility.

https://private.applicationpartner.alcatel-lucent.com/

https://businessportal.alcatel-lucent.com/alugesdp/faces/gesdp/products/Listing.jspx?DOCTYPE=Technical_Documentation/Interworking_Reports&RESULTSBYPAGE=25&BOXES=partner,product&OPENFOLDER=doctype.Interworking_Reports&_afPfm=2

https://businessportal.alcatel-lucent.com/alugesdp/faces/gesdp/products/Listing.jspx?DOCTYPE=Technical_Documentation/Interworking_Reports&RESULTSBYPAGE=25&BOXES=partner,product&OPENFOLDER=doctype.Interworking_Reports&_afPfm=2



18.3 Escalation in all other cases

For non-certified AAPP applications, no valid InterWorking Report is available and the integrator is expected to troubleshoot the issue. If the ALE Business Partner finds out the reported issue is maybe due to one of the Alcatel-Lucent Enterprise solutions, the ALE Business Partner opens a ticket with ALE International Support and shares all trouble shooting information and conclusions that shows a need for ALE International to analyze. Access to technical support requires a valid ALE maintenance contract and the most recent maintenance software revision deployed on site. The resolution of those non-AAPP solutions cases is based on best effort and there is no commitment to fix or enhance the licensed Alcatel-Lucent Enterprise software. For information, for non-certified AAPP applications and if the ALE Business Partner is not able to find out the issues, ALE International offers an “On Demand Diagnostic” service where assistance will be provided for a fee.



18.4 Technical support access

The ALE International Support Center is open 24 hours a day; 7 days a week:

e-Support from the Application Partner Web site (if registered Alcatel-Lucent Application Partner):

http://applicationpartner.alcatel-lucent.com

e-Support from the ALE International Business Partners Web site (if registered Alcatel-Lucent Enterprise

Business Partners): https://businessportal.alcatel-lucent.com click under “Contact us” the eService

Request link

e-mail: [email protected]

Fax number: +33(0)3 69 20 85 85

Telephone numbers:

ALE International Business Partners Support Center for countries:

Country Supported language Toll free number

France

French

+800-00200100

Belgium

Luxembourg

Germany

German Austria

Switzerland

United Kingdom

English

Italy

Australia

Denmark

Ireland

Netherlands

South Africa

Norway

Poland

Sweden

Czech Republic

Estonia

Finland

Greece

Slovakia

Portugal

Spain Spanish

For other countries: English answer: + 1 650 385 2193 French answer: + 1 650 385 2196 German answer: + 1 650 385 2197 Spanish answer: + 1 650 385 2198

END OF DOCUMENT

http://applicationpartner.alcatel-lucent.com/


mailto:[email protected]