IWR 0334 Ed01 - Altitude AER 8.5 - OmniPCXEnterpriseR12.3

ALE Application Partner Program
Inter-Working Report
Partner: ALTITUDE
Application type: Voice Recording Systems
Application name: Altitude Enterprise Recording
(AER)
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 issues a new major
release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs.
ALE MAKES NO REPRESENTATIONS, WARRANTIES OR CONDITIONS WITH RESPECT TO THE APPLICATION

PARTNER PRODUCT. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, ALE 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 FURTHER SHALL
HAVE NO LIABILITY TO AAPP MEMBER OR ANY OTHER PARTY ARISING FROM OR RELATED IN ANY MANNER TO
THIS CERTIFICATE.
The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. To view other trademarks used by
affiliated companies of ALE Holding, visit: www.al-enterprise.com/en/legal/trademarks-copyright. All other trademarks are the
property of their respective owners. The information presented is subject to change without notice. Neither ALE Holding nor
any of its affiliates assumes any responsibility for inaccuracies contained herein. © 2019 ALE International. All rights reserved.
ALE Application Partner Program – Inter-working report - Edition 1 - page 1/116

© 2019 ALE International. All rights reserved.
Certification overview
Date of the certification 20 to 22 May 2019
ALE representative Bernard MAREC

AAPP member representative Ruis RAMOS
Alcatel-Lucent Enterprise OmniPCX Enterprise

Communication Platform
Alcatel-Lucent Enterprise OXE R12.3 (M4.302.5.h)
Communication Platform release TSAPI R7.4.2
Altitude software 8.5.1000
AAPP member application release Connector AER 8.5.1000
Recorder HigherGround 8.1804
Application Category Voice recording
Author(s): Bernard Marex

Reviewer(s): Rachid Himmi
Revision History
Edition 1: creation of the document – May 2019
Test results
Passed Refused Postponed
Passed with restrictions
Refer to the section 2 for a summary of the test results.
IWR validity extension

None

AAPP Member Contact Information
Contact name: Rui Ramos

Title: Quality Assurance Engineer - Validation
Address : Rua Frederico George 37A
City: 1600-468 Lisboa
Country: Portugal
Phone: 00351 915406773

Fax:
Mobil
Web address: https://www.altitude.com/

E-mail: mailto:rui.ramos@altitude.com

TABLE OF CONTENTS
1 INTRODUCTION ...................................................................................................................................... 9
2 VALIDITY OF THE INTERWORKING REPORT ........................................................................... 10
3 LIMITS OF THE TECHNICAL SUPPORT ....................................................................................... 11
3.1 CASE OF ADDITIONAL THIRD PARTY APPLICATIONS ........................................................................... 11
4 APPLICATION INFORMATION ........................................................................................................ 12
1 TEST ENVIRONMENT .......................................................................................................................... 14
1.1 HARDWARE CONFIGURATION ............................................................................................................ 15
1.2 SOFTWARE CONFIGURATION .............................................................................................................. 15
2 SUMMARY OF TEST RESULTS ........................................................................................................ 16
2.1 SUMMARY OF MAIN FUNCTIONS SUPPORTED ...................................................................................... 16
2.2 SUMMARY OF PROBLEMS ................................................................................................................... 17
2.3 SUMMARY OF LIMITATIONS ............................................................................................................... 18
2.4 NOTES, REMARKS .............................................................................................................................. 18
3 TEST RESULT TEMPLATE ................................................................................................................ 19
4 TESTS RESULTS FOR IP DR LINK RECORDING ......................................................................... 20
4.1 INBOUND CALLS................................................................................................................................. 20
4.1.1 Test Objectives .......................................................................................................................... 20
4.1.2 Test Results ............................................................................................................................... 20
4.2 INTERNAL CALLS ............................................................................................................................... 23
4.2.1 Test Objectives .......................................................................................................................... 23
4.2.2 Test Results ............................................................................................................................... 23
4.3 OUTBOUND CALLS ............................................................................................................................. 24
4.3.1 Test Objectives .......................................................................................................................... 24
4.3.2 Test Results ............................................................................................................................... 24
4.4 TRANSFER OF AN INBOUND CALL – BLIND TRANSFER........................................................................ 25
4.4.1 Test Objectives .......................................................................................................................... 25
4.4.2 Test Results ............................................................................................................................... 25
4.5 TRANSFER OF AN INBOUND CALL – SUPERVISED TRANSFER .............................................................. 26
4.5.1 Test Objectives .......................................................................................................................... 26
4.5.2 Test Results ............................................................................................................................... 26
4.6 TRANSFER OF AN OUTBOUND CALL – BLIND TRANSFER .................................................................... 27
4.6.1 Test Objectives .......................................................................................................................... 27
4.6.2 Test Results ............................................................................................................................... 27
4.7 TRANSFER OF AN OUTBOUND CALL – SUPERVISED TRANSFER ........................................................... 28
4.7.1 Test Objectives .......................................................................................................................... 28
4.7.2 Test Results ............................................................................................................................... 28
4.8 3 WAY INBOUND CONFERENCE CALL ................................................................................................ 29
4.8.1 Test Objectives .......................................................................................................................... 29
4.8.2 Test Results ............................................................................................................................... 29
4.9 3 WAY INBOUND CONFERENCE CALL – THE THIRD PARTY DROPS OUT FIRST .................................... 31
4.9.1 Test Objectives .......................................................................................................................... 31
4.9.2 Test Results ............................................................................................................................... 31
4.10 3 WAY INBOUND CONFERENCE CALL – THE CONFERENCER DROPS OUT FIRST & SECOND AGENT NOT
RECORDED ..................................................................................................................................................... 32
4.10.1 Test Objectives .......................................................................................................................... 32
4.10.2 Test Results ............................................................................................................................... 32
4.11 3 WAY OUTBOUND CONFERENCE CALL ............................................................................................ 33
4.11.1 Test Objectives .......................................................................................................................... 33
4.11.2 Test Results ............................................................................................................................... 33
4.12 3 WAY OUTBOUND CONFERENCE CALL – THE THIRD PARTY DROPS OUT FIRST................................. 34

4.12.1 Test Objectives .......................................................................................................................... 34
4.12.2 Test Results ............................................................................................................................... 34
4.13 3 WAY OUTBOUND CONFERENCE CALL – THE CONFERENCER DROPS OUT FIRST & SECOND AGENT
NOT RECORDED .............................................................................................................................................. 35
4.13.1 Test Objectives .......................................................................................................................... 35
4.13.2 Test Results ............................................................................................................................... 35
4.14 CONTACT CENTER : SUPERVISED CALLS : NORMAL LISTENING.......................................................... 36
4.14.1 Test Objectives .......................................................................................................................... 36
4.14.2 Test Results ............................................................................................................................... 36
4.15 CONTACT CENTER : SUPERVISED CALLS : RESTRICTED INTRUSION.................................................... 38
4.15.1 Test Objectives .......................................................................................................................... 38
4.15.2 Test Results ............................................................................................................................... 38
4.16 CONTACT CENTER : SUPERVISED CALLS : INTRUSION........................................................................ 39
4.16.1 Test Objectives .......................................................................................................................... 39
4.16.2 Test Results ............................................................................................................................... 39
4.17 CONTACT CENTER : SUPERVISED CALLS : HELP ................................................................................. 41
4.17.1 Test Objectives .......................................................................................................................... 41
4.17.2 Test Results ............................................................................................................................... 41
4.18 CONTACT CENTER : INCOMING PRIVATE CALLS ................................................................................ 42
4.18.1 Test Objectives .......................................................................................................................... 42
4.18.2 Test Results ............................................................................................................................... 42
4.19 CONTACT CENTER : OUTGOING PRIVATE CALLS ............................................................................... 43
4.19.1 Test Objectives .......................................................................................................................... 43
4.19.2 Test Results ............................................................................................................................... 43
4.20 CONTACT CENTER : AGENT WELCOME GUIDE ................................................................................... 44
4.20.1 Test Objectives .......................................................................................................................... 44
4.20.2 Test Results : ............................................................................................................................. 44
4.21 CONTACT CENTER : FREE SEATING ................................................................................................... 45
4.21.1 Test Objectives .......................................................................................................................... 45
4.21.2 Test Results : ............................................................................................................................. 45
4.22 BUSINESS SETS : MULTILINE SETS ..................................................................................................... 46
4.22.1 Test Objectives .......................................................................................................................... 46
4.22.2 Test Results : Record lines with the same number .................................................................... 46
4.22.3 Test procedure: Record lines with several numbers ................................................................. 47
4.22.4 Test procedure: Not record several lines (inbound calls ) ........................................................ 48
4.23 BUSINESS SETS : MLA FEATURE – SECONDARY MLA SET ANSWERS ................................................ 49
4.23.1 Test Objectives .......................................................................................................................... 49
4.23.2 Test Results : ............................................................................................................................. 49
4.24 BUSINESS SETS : MLA FEATURE – SWAPPING BETWEEN 2 PRIMARY MLA LINES ............................. 50
4.24.1 Test Objectives .......................................................................................................................... 50
4.24.2 Test Results : ............................................................................................................................. 50
4.25 BUSINESS SETS : MLA FEATURE – SWAPPING BETWEEN PRIMARY AND SECONDARY MLA LINES .... 51
4.25.1 Test Objectives .......................................................................................................................... 51
4.25.2 Test Results : ............................................................................................................................. 51
4.26 BUSINESS SETS : TANDEM ................................................................................................................. 52
4.26.1 Test Objectives .......................................................................................................................... 52
4.26.2 Test Results : Inbound call to Main set ..................................................................................... 52
4.26.3 Test Results : Outbound call from the Main set ........................................................................ 53
4.26.4 Test Results : Inbound call to Secondary set ............................................................................. 53
4.26.5 Test Results : Outbound call from the Secondary set ................................................................ 54
4.27 BEEP GENERATION – SINGLE BEEP .................................................................................................... 55
4.27.1 Test Objectives .......................................................................................................................... 55
4.27.2 Test Results : ............................................................................................................................. 55
4.28 BEEP GENERATION – SEVERAL BEEPS ............................................................................................... 55
4.28.1 Test Objectives .......................................................................................................................... 55
4.28.2 Test Results : ............................................................................................................................. 55
4.29 COMPRESSION TYPE TESTS ................................................................................................................. 56
4.29.1 Test objectives ........................................................................................................................... 56
4.29.2 Test results ................................................................................................................................ 56
5 NETWORK IP DR LINK RECORDING TESTS ................................................................................ 57

5.1 NETWORK ARCHITECTURE ................................................................................................................. 57
5.2 SIMPLE CALLS .................................................................................................................................... 59
5.2.1 Test Objectives .......................................................................................................................... 59
5.2.2 Test Results ............................................................................................................................... 59
5.3 TRANSFER OF AN INBOUND CALL FROM LOCAL TO REMOTE – BLIND TRANSFER ............................... 60
5.3.1 Test Objectives .......................................................................................................................... 60
5.3.2 Test Results ............................................................................................................................... 60
5.4 TRANSFER OF AN INBOUND CALL FROM REMOTE TO LOCAL – BLIND TRANSFER ............................... 61
5.4.1 Test Objectives .......................................................................................................................... 61
5.4.2 Test Results ............................................................................................................................... 61
5.5 TRANSFER OF AN INBOUND CALL BETWEEN 2 NODES – BLIND TRANSFER .......................................... 62
5.5.1 Test Objectives .......................................................................................................................... 62
5.5.2 Test Results ............................................................................................................................... 62
5.6 TRANSFER OF AN INBOUND CALL FROM LOCAL TO REMOTE – SUPERVISED TRANSFER ..................... 63
5.6.1 Test Objectives .......................................................................................................................... 63
5.6.2 Test Results ............................................................................................................................... 63
5.7 TRANSFER OF AN INBOUND CALL FROM REMOTE TO LOCAL – SUPERVISED TRANSFER ..................... 65
5.7.1 Test Objectives .......................................................................................................................... 65
5.7.2 Test Results ............................................................................................................................... 65
5.8 TRANSFER OF AN INBOUND CALL BETWEEN 2 NODES – SUPERVISED TRANSFER ................................ 66
5.8.1 Test Objectives .......................................................................................................................... 66
5.8.2 Test Results ............................................................................................................................... 66
5.9 TRANSFER OF AN OUTBOUND CALL FROM LOCAL TO REMOTE – BLIND TRANSFER ............................ 67
5.9.1 Test Objectives .......................................................................................................................... 67
5.9.2 Test Results ............................................................................................................................... 67
5.10 TRANSFER OF AN OUTBOUND CALL FROM REMOTE TO LOCAL – BLIND TRANSFER ............................ 68
5.10.1 Test Objectives .......................................................................................................................... 68
5.10.2 Test Results ............................................................................................................................... 68
5.11 TRANSFER OF AN OUTBOUND CALL BETWEEN 2 NODES – BLIND TRANSFER ....................................... 69
5.11.1 Test Objectives .......................................................................................................................... 69
5.11.2 Test Results ............................................................................................................................... 69
5.12 TRANSFER OF AN OUTBOUND CALL FROM LOCAL TO REMOTE – SUPERVISED TRANSFER .................. 70
5.12.1 Test Objectives .......................................................................................................................... 70
5.12.2 Test Results ............................................................................................................................... 70
5.13 TRANSFER OF AN OUTBOUND CALL FROM REMOTE TO LOCAL – SUPERVISED TRANSFER .................. 71
5.13.1 Test Objectives .......................................................................................................................... 71
5.13.2 Test Results ............................................................................................................................... 71
5.14 TRANSFER OF AN OUTBOUND CALL BETWEEN 2 NODES – SUPERVISED TRANSFER ............................. 72
5.14.1 Test Objectives .......................................................................................................................... 72
5.14.2 Test Results ............................................................................................................................... 72
5.15 3 WAY INBOUND CONFERENCE CALL – STARTING FROM LOCAL TO REMOTE................................... 73
5.15.1 Test Objectives .......................................................................................................................... 73
5.15.2 Test Results ............................................................................................................................... 73
5.16 3 WAY INBOUND CONFERENCE CALL – STARTING FROM REMOTE TO LOCAL................................... 74
5.16.1 Test Objectives .......................................................................................................................... 74
5.16.2 Test Results ............................................................................................................................... 74
5.17 3 WAY OUTBOUND CONFERENCE CALL – STARTING FROM LOCAL TO REMOTE ............................... 75
5.17.1 Test Objectives .......................................................................................................................... 75
5.17.2 Test Results ............................................................................................................................... 75
5.18 3 WAY OUTBOUND CONFERENCE CALL – STARTING FROM REMOTE TO LOCAL ............................... 76
5.18.1 Test Objectives .......................................................................................................................... 76
5.18.2 Test Results ............................................................................................................................... 76
6 RELIABILITY TESTS : IP DR-LINK ................................................................................................... 77
6.1 FAILURE TESTS .................................................................................................................................. 77
6.1.1 Test Environment ...................................................................................................................... 77
6.1.2 Objectives.................................................................................................................................. 78
6.1.3 Test Results : Bad devices ......................................................................................................... 78
6.1.4 Test Results : Not authorized recording.................................................................................... 78
6.1.5 Test Results : No Recording when the parameter “DR-Link on IP supported” = FALSE ....... 79
6.1.6 Test Results : License not available .......................................................................................... 80

6.1.7 Test Results : Max Licenses reached ........................................................................................ 80
6.2 SWITCH FAILURE ............................................................................................................................... 81
6.2.2 Objectives.................................................................................................................................. 82
6.2.3 Test Results ............................................................................................................................... 82
6.3 CTI LINK FAILURE – TSAPI RECORDER LINK FAILURE..................................................................... 85
6.3.2 Objectives.................................................................................................................................. 86
6.3.3 Test Results ............................................................................................................................... 86
6.4 CTI LINK FAILURE – TSAPI ALTITUDE LINK FAILURE ...................................................................... 88
6.4.2 Objectives.................................................................................................................................. 89
6.4.3 Test Results ............................................................................................................................... 89
6.5 VRS : LINK FAILURE ......................................................................................................................... 92
6.5.2 Objectives.................................................................................................................................. 93
6.5.3 Test Results ............................................................................................................................... 93
6.6 REDUNDANCY TESTS : OXE IN SPATIAL REDUNDANCY .................................................................... 95
6.6.2 Objectives.................................................................................................................................. 96
6.6.3 Test Results : OXE in Spatial Redundancy .............................................................................. 96
6.7 REDUNDANCY TESTS: TSAPI BACKUP => FOR THE TSAPI SERVER RECORDER ............................... 98
6.8 OBJECTIVES ....................................................................................................................................... 99
6.8.1 Test Results : TSAPI Backup .................................................................................................... 99
6.9 PASSIVE CALL SERVER ( IP DR-LINK ) ............................................................................................ 100
6.9.1 Test Environment .................................................................................................................... 100
6.9.2 Objectives : ............................................................................................................................. 101
6.9.3 Test Results : ........................................................................................................................... 101
6.10 UNDERSTANDING OF THE LOGS FILES .............................................................................................. 101
6.10.1 Test Objectives ........................................................................................................................ 101
6.10.2 Test Results ............................................................................................................................. 102
6.11 NOTIFICATIONS & ALARMS .............................................................................................................. 102
6.11.1 Test Objectives ........................................................................................................................ 102
6.11.2 Test Results ............................................................................................................................. 102
7 CTI PARAMETERS ............................................................................................................................. 104
8 APPENDIX A : AAPP MEMBER’S APPLICATION DESCRIPTION .......................................... 105
9 APPENDIX B: CONFIGURATION REQUIREMENTS OF THE AAPP MEMBER’S
APPLICATION ............................................................................................................................................ 106
10 APPENDIX C: ALCATEL-LUCENT ENTERPRISE COMMUNICATION PLATFORM:
CONFIGURATION REQUIREMENTS .................................................................................................... 107
10.1 CONFIGURATION FOR IP DR-LINK ................................................................................................... 107
10.1.1 CSTA parameters .................................................................................................................... 107
10.1.2 Phone Facilities Categories parameter .................................................................................. 108
................................................................................................................................................................ 108
10.1.3 Recording IP Logger............................................................................................................... 108
10.1.4 Quality of service for IP recording parameter (IP / IP Domain) ............................................ 109
10.1.5 IP DR-Link licenses ................................................................................................................ 109
10.2 ADDITIONAL PARAMETER FOR DR-LINK & IP DR-LINK: ................................................................ 109
11 APPENDIX D: AAPP MEMBER’S ESCALATION PROCESS .................................................. 110
12 APPENDIX E: AAPP PROGRAM ................................................................................................. 111
12.1 ALCATEL-LUCENT APPLICATION PARTNER PROGRAM (AAPP)....................................................... 111
12.2 ENTERPRISE.ALCATEL-LUCENT.COM .............................................................................................. 112
13 APPENDIX F: AAPP ESCALATION PROCESS ......................................................................... 113
13.1 INTRODUCTION ................................................................................................................................ 113
13.2 ESCALATION IN CASE OF A VALID INTER-WORKING REPORT ........................................................... 114

13.3 ESCALATION IN ALL OTHER CASES ................................................................................................... 115
13.4 TECHNICAL SUPPORT ACCESS .......................................................................................................... 116

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.
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 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://www.al-enterprise.com/en/partners/aapp) with free

access.

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 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 1: The InterWorking report becomes automatically obsolete when the mentioned product
releases are end of life.
Note 2: The renewal of the interoperability test (certification) is under the responsibility of the
partner except if the certification fee is included in the program fee (e.g. “Application Partner”
membership level) in this case ALE will schedule a new certification every two year

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. Access to technical support by the Business Partner requires a valid ALE
maintenance contract
rd
For details on all cases (3 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 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 will consider that situation as to that where
no IWR exists. ALE 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: Altitude Enterprise Recording
Application version: 8.5.1000
Interface type: TSAPI Premium Server
Interface version (if relevant): Altitude (Xperience) => csta.dll 7.3.2

AER (HigherGround recorder) => csta.dll 7.4.2
Voice logger Features available Features Features tested in this

from the recorder side supported by ALE report
Extension side recording NO NO
Trunk side recording NO NO
DR-Link recording : NO NO
- Static mode in DR-Link * no no
- Dynamic mode in DR-Link * no no
IP DR-Link recording : OK OK
- Static mode in IP DR-link * OK OK
Static channel
allocation
1 device = 1 channel
- Dynamic mode in IP DR-Link * NOK NOK
Remote DR-Link recording * NO NO

IP DR-link Network recording * OK OK
Mixed recording * NO NO
IP sniffing NO NO
Free seating YES

Selective recording NO
CCD calls (OTCS application) YES
Business calls YES

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

1 Test environment
Tests Configuration : Voice Recording
Server
AER AER ALTITUDE
HigherGround « Connector » Software
Call Server 1 Recorder ALTITUDE
( Active )
POSTGRES DB SQL DB
TSAPI Server TSAPI RECORDER
Recorder Link1 – port 3595
TSAPI
RECORDER
TSAPI ALTITUDE
TSAPI Server Link1 – port 3595
Altitude
TSAPI
ALTITUDE
TSAPI
BACKUP
RECORDER
172.27.144.X
Mask : 255.255.255.0 172.27.145.X
Mask : 255.255.255.0
WAN
DOMAIN 0 DOMAIN 1
192.168.6.X 192.168.4.X
Mask : 255.255.255.0 Mask : 255.255.255.0
GA GD
GA GD
T2 T2
T2 T2
PCM-R2 PCS
PCS
TDM Set
TDM Set
IP Phone
IP Phone

1.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
 Voice Recorder System interface: Recorder (HigherGround) + Altitude connector +

Altitude software
1.2 Software configuration

List main softwares used for testing
 Alcatel Communication Platform: OmniPCX Enterprise R12.3 M4.302.5.h

 TSAPI Premium Server : 7.4.2
 Server on which TSAPI is installed : Windows Server 2008 R2 Standard SP1 (64-bit)
 Partner Application : AER HigherGround (csta.dll 7.4.2)
Altitude software (including the AER connector) => csta.dll
7.3.2
Operating System to install the recorder system: Windows Server 2012R2
Recorder System uses its own database to insert the recording => postgres database
IMPORTANT
The tests in the this report has been performed using sometime phone
set (dialing/answering/hanging up) and sometime the Uagent OTCS
interface.
The difference between Pilot or RSI, is the way how the call is distributed.
While using Pilot, the distribution is made from OXE side.
If we use RSI, the distribution of the call is done from Altitude side.
We only use distribution from Pilot, while testing in Brest, this is not relevant to the
recorder side.

2 Summary of test results
2.1 Summary of main functions supported
Networking
IP DR-Link
Recording
IP DRLink
Sampling
Total
Features Comments
Basic calls:
Inbound calls OK OK  
Outbound Calls OK OK  
Internal calls OK OK  
Transfer OK OK  
3 Way Conference Call OK OK   Correction added

new file CADcoll.exe
Contact Center :
Supervised Calls  
Private incoming calls NA 
Private outgoing calls NA
Free seating  
Business sets :
Multi lines set NA  
MLA sets NA 
OK PB: Outbound call from
Tandem the Secondary set
Beep generation NA  
Codec OK
Reliability
Basic failure OK  
OXE failure OK  
CTI link failure (TSAPI Server Recorder) OK  
CTI link failure (TSAPI Server Altitude) OK  
Redundancy Tests
Spatial redundancy of the OXE OK 
TSAPI backup OK 
Passive Call Server NA 

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 Alcatel-Lucent 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 Alcatel-Lucent 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.
2.2 Summary of problems
Conference Call
One part in the record is missing => Correction added in the code => new file CADcoll.exe)
Tandem: Outbound call from the Secondary set
There is one Rec for 3001, audio is OK, but there are 2 StartIPRecording: one for 3000 and
one for 3001, only one StopIPRecording for 3001 at end of the call.
Network IP DR Link Recording Tests
In Network environment, 2 nodes (Node 1 and Node 2) are configured and linked by ABC-F link
(Hybdrib link).
On the TSAPI Server there are 2 instances (Alcatel Open Telephony Server -> link1 (port 3595) to
NODE 1 and Alcatel Open Telephony Server1 => link2 (port 3596) to NODE 2).
The TSAPI Links are configured on the recorder to sends the request to the TSAPI Server – NODE.
We observed that the HigherGround recorder sends the Start Monitor request to TSAPI Server –
NODE whatever the NODE on which the devices belong to.
Example:
TSAPI Server receives through the link1 (Node1) Start Monitor of the devices belonging to the Node
2.
So of course, as those devices are not known on the Node 1, the Start Monitor request is refused
=> error: 12
The same happens through the link2 (Node 2) for the devices of the Node 1.
From the HigherGround, it seems that the creation of the devices (to be monitored) belongs to a
simple list and all the contain of the list is pouch on each created TSAPI link whatever the relation to
the Node.
IMPORTANT: Even if the audio capture of the recordings contains the conversation, this
behaviour is not correct and cannot be preserved in this way for support (log analysis).
Every 15 seconds, Start Monitor requests are sent for all the devices which had an error of
monitoring previously.
This makes the TSAPI Server traces unusable

2.3 Summary of limitations
HigherGround limitation => “if an agent is already logged on before Altitude connector is running,
then we do not detect it => consequence: no recording started”
Features not supported:
 Contact Center: Incoming Private Calls
 Contact Center: Outgoing Private Calls
 Business Sets: Multiline sets
 Record lines with several numbers
 Not record several lines
 Business Sets: MLA Feature
 Beep Generation – Single Beep
 Beep Generation – Several Beeps
 Passive Call Server (IP DR-Link)
2.4 Notes, remarks

When we add a device on the recorder interface, a Start monitoring request is sent to the TSAPI –
OXE => so the device is monitored by the OXE.
If we remove the device from the recorder interface (HigherGround), the device is still in the list of
the monitored device on the OXE => don’t see in the TSAPI logs a Stop monitoring.
Recorder (HigherGround) interface => display of the record

As soon as the Altitude components (connector + software) are active, we are able to get Data of
the call (direction, UCi service…) only is the call is through CCD pilot.
Station ID is displayed but not the Agent number => Pro-ACD number is shown in the record.
We see that it is not possible to mix the Data from the HigherGround recorder and the Data
provided from the Altitude through the AER connector (when Altitude is Active).
No info about the DNIS and the ANI in the showing data.
Internal calls
No information to know that the call is internal.

3 Test Result Template
The results are presented as indicated in the example below:
Test
Test Case N/A OK NOK Comment
Case Id
Test case 1
 Action
1
 Expected result
Test case 2
The application waits
 Action
2 for PBX timer or
 Expected result
phone set hangs up
Test case 3
Relevant only if the
 Action
3 CTI interface is a
 Expected result
direct CSTA link
Test case 4
 Action No indication, no error
4
 Expected result 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.

4 Tests Results for IP DR Link Recording
4.1 Inbound calls
4.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.
4.1.2 Test Results
Test
Case Id
Inbound call
 Make a PSTN inbound call to Agent 3400 1 rec
1
 Agent 3400 answers the call and speaks for at Audio OK
least 10 seconds before hanging-up.
New inbound call
 Make an inbound call to Agent V2 ( call is routed
2 through pilot distribution ). 1 rec
 Agent V2 answers the call and speaks for at least Audio OK
10 seconds before hanging-up.
Check the records in the VRS
 In the VRS application, playback the above
3 Audio OK
conversations
Note: extension displayed is not the Agent directory number but the directory number of the Pro-acd
set on which the Agent is logged on.
 Agent 3400 is logged on the Pro-ACD set 3000.
 Agent 3401 is logger on the Pro-ACD set 3001.

Uagent Altitude
Record from the HigherGround interface:

More info provided in the record database (after Altitude config) if we call through CCD Pilot to
Agent
Following extension are declared on the HigherGround recorder to be monitored:

3000
3001
3097
3098
Uagent from Altitude Xperience:

3400
3401
From the HigherGround recorder, requests Start Monitor for all those devices to the OXE.
The Uagent number are not declared on the HigherGround recorder. The HigherGroung recorder
has access to the SQL Database of Altitude, and a table (e_user) is containing all the agent ID (id,
number …)
The Recorder is getting this info to know the list of the existing agent ID and then send Monitor start
for those devices.
Note: We tried to remove one Agent ID and see from the related SQL table that the agent id has
been removed but not the monitorings device (from OXE).
 Normally it is possible to remove it from the recorder (and so Monitor Stop) by a setting in
the recorder system (G3LogFeed.cfg), but didn’t find it.
OXE
List of the monitored devices:
3000, 3001, 3097, 3098, 3400, 3401
 See screenshot at the next page:

4.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.
4.2.2 Test Results

_1
Test
Case Id
Internal call
 Make an internal call from Agent 3400 to Agent
2 records
1 3401
 Agent 3401 answers the call and speaks for at
New internal call
 Make an internal call from Agent 3400 to Agent
3401 ( call is routed through pilot distribution: 2 Rec
2
CCD Pilot 3100 ). Audio OK
3  In the VRS application, check the records
Note: no information to know that the call is internal.

4.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.
4.3.2 Test Results
Test
Case Id
Outbound call
 Make a PSTN outbound call from Agent 3400
1 Rec
1  The external party answers the call and speaks
for at least 10 seconds before hanging-up.

2  In the VRS application, check the records Audio OK
Note: Agent 3400 is logged on the pro-acd 3000,

Agent 3400 makes an outbound call to external 03004.

4.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.
4.4.2 Test Results
Test
Case Id
Inbound call
 Make an inbound call to Agent 3400
1 1 Rec
least 10 seconds.
Enquiry and transfer
 Agent 3400 makes an internal call to Agent 3401
2 ( the inbound call is automatically put on hold )
 Agent 3400 transfers the inbound held call to
Agent 3401
Transferred call
3  Agent 3401 answers the call and speaks for at 1 Rec
least 10 seconds before hanging-up
Note:

4.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.
4.5.2 Test Results
Test
Case Id
Inbound call
 Make an inbound call to Agent V1
1 1 Rec (Agt1)
 Agent V1 answers the call and speaks for at least
10 seconds.
Enquiry call
 Agent V1 makes an internal call to Agent V2 ( the Rec Agt1 continues
2
inbound call is automatically put on hold ) 1 Rec (Agt2)
 Agent V1 and Agent V2 are in conversation
Transfer
3  Agent V1 transfers the inbound held call to Agent Rec Agt1 stopped
V2
Transferred call
4  Agent V2 and the external party speak at least Rec Agt2 continues
during 10 seconds before hanging-up
Note: no info DNIS - ANI

Ext – Agt V1 Agt V1 – Agt V2
Agt V2 – Agt V1 Agt V2 - Ext
 If we read the 2 records, we observed that there was a shift in the records.

4.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 shou673ld be inserted to the VRS calls database. Then,
using the Query application, it should be possible to playback the audio of this call.
4.6.2 Test Results
Test
Case Id
Outbound call
 Make an outbound call from Agent V1
1 1 Rec
 The external party answers the call and speaks
for at least 10 seconds.
Enquiry and transfer
 Agent V1 makes an internal call to Agent V2 ( the
2 outbound call is automatically put on hold )
 Agent V1 transfers the outbound held call to
Agent V2
Transferred call
3  Agent V2 answers the call and speaks for at least 1 Rec
10 seconds before hanging-up
Note:
The Data circled in red, are provided when the recorder HigherGround is connected but the Altitude
Xperience + AER connector not started.
We observed that when the solution involves the recorder HigherGround + AER connector (Altitude)
+ Altitude Xperience, those Data were not abailable. Only the Data from Altitude could be provided.

4.7 Transfer of an outbound call – Supervised Transfer
This test checks that VRS is able to record supervised transferred calls for outbound calls . In
4.7.2 Test Results
Test
Case Id
Outbound call
1 1 Rec 3400
Enquiry call
 Agent V1 makes an internal call to Agent V2 ( the Rec 3400 continues
2
outbound call is automatically put on hold ) 1 Rec 3401
Transfer
Rec 3400 stopped
3  Agent V1 transfers the outbound held call to
Agent V2
Transferred call
4  Agent V2 and the external party speak at least Rec 3401 continues
during 10 seconds before hanging-up
Note: same 8.5 for the DNIS, ANI

4.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.
4.8.2 Test Results
Test
Case Id
Inbound call
1 1 Rec Agent 1
10 seconds.
Enquiry call
Rec Agent 1
2
inbound call is automatically put on hold )
continues
 Agent V1 and Agent V2 are in conversation 1 Rec Agent 2
Conference
3  Agent V1 conferences the inbound held call with
Agent V2
Rec Agent 1
Conferenced call
continues
4  Agent V1 & V2 and the external party speak at
least during 10 seconds
Rec Agent 2
continues
The conferencer drops out
 Agent V1 hangs up Rec Agent 2
5
 Agent V2 and the external party speak at least continues
during 10 seconds before hanging up
2 Recs
Check the records in the VRS Audio OK
6  In the VRS application, check the records Code changing (new
file CADcoll.exe)
Note:
DNIS, ANI, direction not provided (related to the fact that Altitude software + connector is ON, so
not able to get the Data from the recorder side).
First test => in the record of the Agent 2, one part is missing (part5 => after Agent 1 has hangs up)
Correction:
 Code changing (new file CADcoll.exe) on the HigherGround recorder part.
First time after the modification added, we get 4 recordings for the test and then the second time we
did exactly the same test, only 2 recordings were displayed
 See the records at the next page:

Same result if we did the call using the Uagent (from the Altitude interface) or if we did the call using
the phone set directly.
 Call to a CCD Pilot or call to agent directly as the same result for recording point of view.
Only provided Data is different.

4.9 3 Way Inbound Conference Call – The third party drops out first
4.9.2 Test Results
Test
Case Id
Inbound call
 Make an inbound call to CCD Pilot -> to Agent V1
1 1 Rec for Agent 1
10 seconds.
Enquiry call
 Agent V1 makes an internal call to Agent V2 ( the 1 Rec for Agent 1
2
inbound call is automatically put on hold ) 1 Rec for Agent 2
Conference
Agent V2
Conferenced call 1 Rec for Agent 1
4  Agent V1 & V2 and the external party speak at Rec Agent 2
least during 10 seconds continues
The third party drops out
 Agent V2 hangs up Rec Agent 2
5
 Agent V1 and the external party speak at least continues
4 Recs
6  In the VRS application, check the records Code changing (new
file CADcoll.exe)
Note: First test => Part 5 is missing in the audio for the 3400
After correction => First time the test was performed, we found 4 records. Then for the next test, only
2 records were displayed.
From the Uagent interface, answers to the call (Agent 1) => call to CCD Pilot
 We get 4 records => test using the Uagent interface to answer the call, consult call, conf…

4.10 3 Way Inbound Conference Call – The conferencer drops out first
& second agent not recorded
4.10.2 Test Results
Test
Case Id
Agent B not monitored
1
 Check that the agent V2 is not monitored
Inbound call
2
10 seconds.
Enquiry call
3
inbound call is automatically put on hold )
Conference
Agent V2
Conferenced call
 Agent V1 hangs up
6 Rec 3400 stopped
 Agent V2 and the external party speak at least
1 Rec OK
Audio OK

4.11 3 Way Outbound Conference Call
This test checks that VRS is able to record conference calls for outbound calls. In addition, the call-
4.11.2 Test Results
Test
Case Id
Outbound call
 Make an outbound call from Agent V1 by an
OTCS campaing (all the test using Uagent to
1
make, answer and hang up)
Rec Agent 1
Enquiry call
Rec Agent 1
2
outbound call is automatically put on hold )
continues
 Agent V1 and Agent V2 are in conversation Rec Agent 2
Conference
3  Agent V1 conferences the outbound held call with
Agent V2
Rec Agent 1
Conferenced call
continues
Rec Agent 2
continues
Rec Agent 1 stopped
5 Rec Agent 2
during 10 seconds before hanging up continues
2 Recs
Audio OK
Code changing (new
file CADcoll.exe)
Note:
First test => Audio of the part 5 is missing for the 3401
After modification => 2 Recs

4.12 3 Way Outbound Conference Call – The third party drops out first
4.12.2 Test Results
Test
Case Id
Outbound call
1
10 seconds.
Enquiry call
2
Conference
Agent V2
Conferenced call
The third party drops out
5
2 Recs
Audio OK
Code changing (new
file CADcoll.exe)
Note: Audio part 5 is missing for 3400
After modification => test using Uagent (Altitude) => give a contact to make the outbound call (from
Altitude Xperience)
 Home: 03004

4.13 3 Way Outbound Conference Call – The conferencer drops out
first & second agent not recorded
4.13.2 Test Results
Test
Case Id
Agent B not monitored
1
 Check that the agent V2 is not monitored
Outbound call
 Make an outbound call to Agent V1
2
10 seconds.
Enquiry call
3
Conference
Agent V2
Conferenced call
6
1 Rec
Audio OK

4.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
4.14.2 Test Results
Test
Case Id
Normal listening
1  A supervisor makes normal listening on Agent V1
in permanent mode.
Inbound call
through a distribution pilot ).
2
 Agent V1 answers the call
 Agent V1 and the external caller speak during at
least 10 second before hanging up
2 Recs
Check the Agent’s record in the VRS
1 Rec Agent
and 1 Rec Supervisor
Audio OK
Note:
From the record interface, we see the pro-acd extension number and not the agent and supervisor
number.
 See screenshot at the next page
Supervisor from the Altitude interface (supervisor 3410 logged on Pro-ACD 3001):

Normal Listening

4.15 Contact Center : Supervised Calls : restricted intrusion
4.15.2 Test Results
Test
Case Id
Inbound call
1
least 10 second
Restricted intrusion
2  A supervisor makes restricted intrusion on the
agent V1 during the conversation
End of Agent’s call
3
 The Agent V1 releases the call
2 Recs
Audio OK
Note: => barge-in mode => info from the Altitude interface
Stae: Barge-In for the Restrictive intrusion and for the Intrusion.

4.16 Contact Center : Supervised Calls : intrusion
4.16.2 Test Results
Test
Case Id
Inbound call
1 Rec Agent 1
1 1 Rec Supervisor
(listening mode)
least 10 second
Rec Agent 1
Intrusion
continues
2  A supervisor makes intrusion on the agent V1
during the conversation
1 Rec Supervisor
(Intrusion)
End of Agent’s call
Rec Supervisor
 The Agent V1 releases the call
3 continues after
 The supervisor continues with external party 10
seconds intrusion
3 Recs
Audio OK
Code changing (new
file CADcoll.exe)
Note: barge-in mode from the Altitude interface
First test:
Rec Agt is OK
Part 3 for the supervisor is missing
After modification:
 Supervisor activate the agent supervision fromt Uagent to supervises the Agent 1
(Start Supervision => Permanent)
Make a call to CCD pilot (inbound call ) , Agent 1 answers from the Uagent interface
Supervisor select Intrusion (Barge-In) from the Uagent
Agent 1 hangs up (from OTCS)
Supervisor hangs up from the Uagent interface
 See screenshot of the records at the next page
Normal Listening Intrusion key pressed

on the supervisor set

4.17 Contact Center : Supervised Calls : help
4.17.2 Test Results
Test
Case Id
Inbound call
1 1 Rec Agent 1
least 10 second
Help
2
 The agent presses “help”
Rec Agent 1
Restrictive intrusion of the supervisor
continues
3  The supervisor makes now an intrusion during
the conversation of the agent V1
1 Rec Supervisor
(Intrusion)
End of Agent’s call Rec Supervisor is
 The Supervisor releases the call stopped
4
 The Agent V1 still in conversation during 10 Rec Agent 1
seconds and hangs up continues
2 Recs
Audio OK
Code changing (new
file CADcoll.exe)
Note:
Rec of the supervisor start after he pressed Intrusion.
Rec Agent: part 4 is missing after Supervisor hangs up.
After modification:
 Request Help using the Uagent interface
Uagent Agent1 (3400 logged on pro-ACD 3000) => Request supervisor Help External - Agt V1
Uagent Supervisor (3410 logged on pro-ACD 3001) => Barge-in mode
External - Agt V1
Agt V1 – Supervisor
Agt V1 resquests Help Help Supervisor hangs up

4.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
NOT SUPPORTED
4.18.2 Test Results
Test
Case Id
Inbound call
 Make an inbound call to the private Agent’s
extension V1. Not supported
1
least 10 second
2  In the VRS application, check there is no record

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

NOT SUPPORTED
This test checks that VRS is able to selectively not record outgoing private calls.
4.19.2 Test Results
Test
Case Id
Agent’s state
1 Not supported
 Check that the agent V1 is in idle state
Outbound call
 Make an outbound call from the Agent V1
2  The external party answers the call
least 10 second
3  In the VRS application, check there is no record

4.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-
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
4.20.2 Test Results :
Test
Case Id
Management of an agent presentation guide
 Login the agent V1 on the proacd P1
1  Make an inbound call to the agent V1 ( from a pilot
distribution )
 Logout the agent V1
Inbound call
 Make an inbound call to the agent V1 ( from a pilot
distribution )
2
 The agent V1 answers the inbound call
 The agent V1 & the external party speak for at least
10 seconds before hanging up.
1 Rec
Audio is
Check the record in the VRS
OK
3  In the VRS application, check the record
Welcome
guide is not
recorded.

4.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-
Test
Case Id
Agent V1 on proacd P1
distribution )
Agent V1 on proacd P2
distribution )

4.22 Business Sets : Multiline sets
NOT SUPPORTED
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
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
4.22.2 Test Results : Record lines with the same number
Test
Case Id
Several lines with the same number
Multiline not
1  Create 2 multiline keys with the same number (
the number = the phone set M )
supported
st
Inbound call : 1 call

st
Make an inbound call to the 1 multiline key
2  M answers the call
 M and the external caller speak during at least 10
seconds
nd
New Inbound call : 2 call

nd

st
M puts on Hold the 1 call

nd
3 M answers the 2 call
seconds

nd
M hangs up the 2 call
st
Retrieve the 1 call

st st
M retrieves the 1 call on the 1 multiline key
4  M and the external party speak during at least 10
seconds
 M hangs up the call

4.22.3 Test procedure: Record lines with several numbers
Test
Case Id
Several lines with several numbers
Multiline not
1  Create 2 multiline keys with 2 numbers (numbers
are different from the phone set number)
supported
st

st
seconds
nd
Outbound call : 2 call

st
M puts on Hold the 1 call

nd
Make an outbound call from the 2 multiline key
3  The external caller answers the call
seconds

nd
st
Retrieve the 1 call

st st
seconds

4.22.4 Test procedure: Not record several lines (inbound calls )
NOT SUPPORTED
Test
Case Id
Several lines with several numbers
Multiline not
1  Create 2 multiline keys with 2 numbers (numbers
are different from the phone set number)
supported
Rule to not record these lines
2  Create a rule in the VRS to not record these 2
numbers
st

st
seconds
nd

nd
 M answers the call
4
seconds

nd
st
Retrieve the 1 call

st st
seconds
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

4.23 Business Sets : MLA Feature – secondary MLA set answers
4.23.1 Test Objectives NOT SUPPORTED

This test checks that VRS is able to record calls with MLA keys. In addition, the call-details retrieved
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 Id
Primary MLA key on set M
Multiline not
1  Create a Primary MLA key ( with Number 1 ) on
the phone set M
supported
Secondary MLA key on set N
2  Create a Secondary MLA key ( with Number 1 )
on the phone set N
Inbound call
 Make an inbound call to the MLA number 1
 N answers the call on the Secondary MLA key (
3
Number 1 )
 N and the external caller speak during at least 10
seconds
On hold
4

st
N puts on Hold the 1 call
Retrieve the call on set M
 M retrieves the call on the Primary MLA key (
number 1 )
5
 M and the external party speak during at least 10
seconds
Primary MLA key Secondary MLA key

Number 1 Number 1
Set M
Set N

4.24 Business Sets : MLA Feature – swapping between 2 Primary
MLA lines
NOT SUPPORTED
Test
Case Id
Primary MLA key on set M
 Create a Primary MLA key ( with Number 1 ) on
Multiline not
1 the phone set M
 Create a Primary MLA key ( with Number 2 ) on
supported
the phone set M
Inbound call
 M answers the call on the Primary MLA key (
2
Number 1 )
seconds
New Inbound call

st
M puts on hold the 1 call

nd
M answers the 2 call on the Primary MLA key (
3
Number 2 )
seconds
 M hangs up
st
Retrieve the 1 call
 M retrieves the call on the Primary MLA key (
Number 1 )
4
 M and the external party speak during at least 10
seconds

4.25 Business Sets : MLA Feature – swapping between Primary and
Secondary MLA lines
4.25.1 Test Objectives NOT SUPPORTED
Test
Case Id
Primary MLA key on set M Multiline
1  Create a Primary MLA key ( with Number 1 ) on the not
phone set M supported
MLA key on set N
 Create a Secondary MLA key ( with Number 1 ) on
2 the phone set N
 Create a Primary MLA key ( with Number 2 ) on the
phone set N
Inbound call
 N answers the call on the Secondary MLA key (
3
Number 1 )
seconds
New Inbound call

st
N puts on hold the 1 call

nd
N answers the 2 call on the Primary MLA key (
3
Number 2 )
seconds
 N hangs up
st
Retrieve the 1 call
 N retrieves the call on the Primary MLA key (
Number 1 )
4
 N and the external party speak during at least 10
seconds
 N hangs up the call
Primary MLA key Primary MLA key

Number 2
Number 1 Set N
Secondary MLA key
Number 1
Set M

4.26 Business Sets : Tandem
This test checks that VRS is able to record calls with business sets in tandem. In addition, the call-
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 Multi-line « 3001 »
Set 3001
Set 3000 Multi-line « 3000 »
MAIN set SECONDARY set
4.26.2 Test Results : Inbound call to Main set
Test
Case Id
Management of the tandem
 Create Multiline keys on the main & the
1
secondary tandem user
 Manage the tandem
Inbound call
 Make an inbound call to the tandem number
2  The main set answers the call
 The main set and the external caller speak during
at least 10 seconds before hanging up
1 Rec
Audio OK
Note:

4.26.3 Test Results : Outbound call from the Main set
Test
Case Id
1
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
Note:
4.26.4 Test Results : Inbound call to Secondary set
Test
Case Id
1
Inbound call
 Make an inbound call to the tandem number
2  The secondary set answers the call
 The secondary set and the external caller speak
during at least 10 seconds before hanging up
1 Rec
Audio OK
Note:

4.26.5 Test Results : Outbound call from the Secondary set
Test
Case Id
1
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
There is one Rec for
3001, audio is OK, but
there are 2
Check the record in the VRS StartIPRecording: one
3  In the VRS application, check the record for 3000 and one for
3001, only one
StopIPRecording for
3001 at end of the
call.
Remark : For this test, the CSTA OXE provides the Calling Device ID in the “Originated” Event (
and not in the “Established” event ).
So to realize this test, the voice recorder system has to :

1- In the “Established” event, take the Calling Device : Device ID : X
2- In the “Originated” event :
if the ( Calling Device : Device ID : Y ) ≠ ( Calling Device : Device ID : X ) then the
voice recorder has to send the request “start IP recording ( Device_ID = Y )”

4.27 Beep Generation – Single Beep
NOT SUPPORTED
This test checks that VRS supports the generation of a single beep.
Test
Case Id
Creation of a single beep Beeps not
1
 Manage a single beep in the VRS supported
Call
2
 Make a call including a recorded device
Beep generation
3
 Send a single beep
4.28 Beep Generation – Several Beeps

NOT SUPPORTED
This test checks that VRS supports the generation of several beeps.
Test
Case Id
Creation of the generation of several beeps Beeps not
1
 Manage the generation of several beeps in the VRS supported
Call
2
 Make a call including a recorded device
Beeps generation
3
 Send several beeps

4.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.
4.29.1 Test objectives

This test checks that VRS is able to record in different codecs (G711, G729 or G723).
4.29.2 Test results
Test
Case Id
G711 1 Rec
1
 Make a call in G711 Audio OK
G723 1 Rec
2
G729 1 Rec
3

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

Voice Recording
NODE 1 Server
AER AER ALTITUDE
HigherGround « Connector » Software
Call Server Recorder ALTITUDE
NODE 1- Link1 – port 3595
POSTGRES DB SQL DB
TSAPI Server
Recorder
NODE 2- Link2 – port 3596
TSAPI
RECORDER
NODE 1 - Link1 – port 3595

TSAPI Server
NODE 2 – Link2 – port 3596
Altitude
TSAPI
ALTITUDE
172.27.144.X
Mask : 255.255.255.0
NODE 2
WAN
Call Server
172.27.132.X
Mask : 255.255.255.0

In Network environment, 2 nodes (Node 1 and Node 2) are configured and linked by ABC-F link
(Hybdrib link).
On the TSAPI Server there are 2 instances (Alcatel Open Telephony Server -> link1 (port 3595) to
NODE 1 and Alcatel Open Telephony Server1 => link2 (port 3596) to NODE 2).
The TSAPI Links are configured on the recorder to sends the request to the TSAPI Server – NODE.
We observed that the HigherGround recorder sends the Start Monitor request to TSAPI Server –
NODE whatever the NODE on which the devices belong to.
Example:
TSAPI Server receives through the link1 (Node1) Start Monitor of the devices belonging to the Node
2.
So of course, as those devices are not known on the Node 1, the Start Monitor request is refused
=> error: 12
The same happens through the link2 (Node 2) for the devices of the Node 1.
From the HigherGround, it seems that the creation of the devices (to be monitored) belongs to a
simple list and all the contain of the list is pouch on each created TSAPI link whatever the relation to
the Node.
IMPORTANT: Even if the audio capture of the recordings contains

the conversation, this behaviour is not correct and cannot be
preserved in this way for support (log analysis).
Every 15 seconds, Start Monitor requests are sent for all the
devices which had an error of monitoring previously.
This makes the TSAPI Server traces unusable
Let’s take an example for the link1:
Recorder TSAPI Server

HigherGround link1 Users :
Start Monitor 3000
3000 Error code 12 : NODE 1 3001
3001 6000 3400
3400 6001 3401
3401 6400
6000 6401
6004
6400
WAN ABC-F link
6404
Users :
6000
NODE 2 6004
6400
6404
Correction for the conference has been applied for all the following tests.

5.2 Simple calls
This test checks that VRS is able to record simple calls through ABC-F2 link. In addition, the call-
5.2.2 Test Results
Test
Case Id
Network call : OXE1 --> OXE2
 Make a call from Agent V1 to Remote Agent RV1 2 Recs
1
 Remote Agent RV1 answers the call and speaks Audio OK
for at least 10 seconds before hanging-up.
Network call : OXE2 --> OXE1
 Make a call from Remote Agent RV1 to local
2 Recs
2 Agent V1
Audio OK
10 seconds before hanging-up.
Screenshot 9.1
No info about the
calling, called
3  In the VRS application, check the records Pro-acd number is
displayed.
ID of the agent which
is logged on but not
the directory number
Note:
1 TSAPI link (link2 – port 3596) to the TSAPI Server 172.27.139.32 => recorder system
1 TSAPI link (link2 – port 3596) to the TSAPI Server 172.27.139.210 => Altitude Solution
6000 and 6004 declared on the AER recorder (HigherGround)

6400 and 6404 declared as Uagent in OTCS solution
= > monitoring devices from the Node 2 are:

6000
6004
6400
6404

5.3 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,
5.3.2 Test Results
Test
Case Id
Inbound call to local node
1 1 Rec (3000)
10 seconds
Enquiry and transfer to remote node
 Agent V1 makes a network call to Remote Agent
RV1 ( the inbound call is automatically put on
2
hold )
 Agent RV1 transfers the inbound held call to
Remote Agent RV1
Transferred call
3  Remote Agent RV1 answers the call and speaks 1 Rec (6000)
for at least 10 seconds
Internal transfer
 Remote Agent RV1 makes an internal call to
Remote Agent RV2 ( the inbound call is
4
automatically put on hold )
 Remote Agent RV1 transfers the inbound held
call to Remote Agent RV2
Transferred call
5  Remote Agent RV2 answers the call and speaks 1 Rec (6004)
for at least 10 seconds before hanging-up
3 Recs
Audio OK
Note:

5.4 Transfer of an inbound call from Remote to Local – Blind transfer
5.4.2 Test Results
Test
Case Id
Inbound call to remote node
 Make an inbound call to Remote Agent RV1
1
 Remote Agent RV1 answers the call and speaks
Enquiry and transfer to local node
 Remote Agent RV1 makes a network call to
Agent V1 ( the inbound call is automatically put
2
on hold )
call to Agent V1
Transferred call
3  Agent V1 answers the call and speaks for at least
10 seconds
Internal transfer
4 inbound call is automatically put on hold )
 Agent V1 transfers the inbound held call to Agent
V2
Transferred call
The audio is captured
correctly but
according to the data
inserted in the record
and displayed in the
interface is very
difficult to see who
has called who and
who is the device who
has answered.

5.5 Transfer of an inbound call between 2 nodes – Blind transfer
5.5.2 Test Results
Test
Case Id
1
10 seconds
2
hold )
 Agent V1 transfers the inbound held call to
Remote Agent RV1
Transferred call
3  Remote Agent RV1 answers the call and speaks
Transfer to local node
4
on hold )
call to Agent V2
Transferred call
6  In the VRS application, check the records Data inserted in the
record not exploitable

5.6 Transfer of an inbound call from Local to Remote – Supervised
Transfer
5.6.2 Test Results
Test
Case Id
1
10 seconds
Enquiry to remote node
2
hold )
 Agent V1 and Remote Agent RV1 speak at least
10 seconds
Transfer
3
 Agent V1 transfers the enquiry call
Transferred call
4  Remote Agent RV1 and the external party speak
Internal Enquiry
Remote Agent RV2 ( the inbound call is
5
 Remote Agent RV1 and Remote Agent RV2
speak at least 10 seconds
Transfer
6
 Remote Agent RV1 transfers the enquiry call
Transferred call
3 Recs
Audio OK
Note:
Ext - Agt1
REC Agt1 Ext – Agt RV1
REC Agt RV1
Ext – Agt RV2
Consult
REC Agt RV2
call
Consult
call

5.7 Transfer of an inbound call from Remote to Local – Supervised
Transfer
5.7.2 Test Results
Test
Case Id
Inbound call to Remote node
1
Enquiry to local node
2
on hold )
10 seconds
Transfer
3
Transferred call
4  Agent V1 and the external party speak for at least
10 seconds
Internal Enquiry
5 inbound call is automatically put on hold )
 Agent V1 and Agent V2 speak at least 10
seconds
Transfer
6
Transferred call

5.8 Transfer of an inbound call between 2 nodes – Supervised
Transfer
5.8.2 Test Results
Test
Case Id
Inbound call to Local node
1
10 seconds
Enquiry to Remote node
2
hold )
10 seconds
Transfer
3
Transferred call
Enquiry to Local node
5
on hold )
 Remote Agent RV1 and Agent V2 speak at least
10 seconds
Transfer
6
Transferred call

5.9 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,
5.9.2 Test Results
Test
Case Id
Outbound call from local node
1
 External caller answers the call and speaks for at
least 10 seconds
RV1 ( the outbound call is automatically put on
2
hold )
 Agent RV1 transfers the outbound held call to
Remote Agent RV1
Transferred call
Internal transfer
Remote Agent RV2 ( the outbound call is
4
 Remote Agent RV1 transfers the outbound held
call to Remote Agent RV2
Transferred call

5.10 Transfer of an outbound call from Remote to Local – Blind
transfer
5.10.2 Test Results
Test
Case Id
Outbound call from remote node
 Make an outbound call from Remote Agent RV1
1
least 10 seconds
Enquiry and transfer to local node
Agent V1 ( the outbound call is automatically put
2
on hold )
call to Agent V1
Transferred call
10 seconds
Internal transfer
Agent V2
Transferred call

5.11 Transfer of an outbound call between 2 nodes – Blind transfer
5.11.2 Test Results
Test
Case Id
1
least 10 seconds
RV1( the outbound call is automatically put on
2
hold )
Remote Agent RV1
Transferred call
Transfer ro local node
4
on hold )
call to Agent V2
Transferred call

5.12 Transfer of an outbound call from Local to Remote – Supervised
Transfer
5.12.2 Test Results
Test
Case Id
1
least 10 seconds
2
hold )
10 seconds
Transfer
3
Transferred call
Internal Enquiry
Remote Agent RV2 ( the outbound call is
5
 Remote Agent RV1 and Remote Agent RV2
speak at least 10 seconds
Transfer
6
Transferred call

5.13 Transfer of an outbound call from Remote to Local – Supervised
Transfer
5.13.2 Test Results
Test
Case Id
Outbound call from Remote node
1
least 10 seconds
Enquiry to local node
2
on hold )
10 seconds
Transfer
3
Transferred call
10 seconds
Internal Enquiry
 Agent V1 and Agent V2 speak at least 10
seconds
Transfer
6
Transferred call

5.14 Transfer of an outbound call between 2 nodes – Supervised
Transfer
5.14.2 Test Results
Test
Case Id
Outbound call from Local node
1
least 10 seconds
Enquiry to Remote node
2
hold )
10 seconds
Transfer
3
Transferred call
5
on hold )
 Remote Agent RV1 and Agent V2 speak at least
10 seconds
Transfer
6
Transferred call

5.15 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
5.15.2 Test Results
Test
Case Id
1
10 seconds
2
hold )
10 seconds
Conference
 Agent V1 presses the “conference” button
 Agent V1, Remote Agent RV1 and the external
3 party speak for at least 10 seconds before Agent
V1 hangs up
 After Agent V1 hangs up, Agent RV1 still in
conversation during 10 seconds and hangs up

5.16 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
5.16.2 Test Results
Test
Case Id
Inbound call to Remote node
1
2
on hold )
10 seconds
Conference
 Remote Agent RV1 presses the “conference”
button
3
party speak for at least 10 seconds before Agent
RV1 hangs up

5.17 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
5.17.2 Test Results
Test
Case Id
1
least 10 seconds
2
hold )
10 seconds
Conference
 Agent V1 presses the “conference” button
3  Agent V1, Remote Agent RV1 and the external
V1 hangs up

5.18 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
5.18.2 Test Results
Test
Case Id
Outbound call from Remote node
1
least 10 seconds
2
on hold )
10 seconds
Conference
 Remote Agent RV1 presses the “conference”
button
3
RV1 hangs up
No data to show the
call is outbound call,
same as previous test
case.

6 Reliability tests : IP DR-Link
6.1 Failure Tests
6.1.1 Test Environment

6.1.2 Objectives
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
6.1.3 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 Id
Management of the recording of a TDM set in the VRS
TDM
1  Declare the recording of a set which is not a serie
8 ( UA, Z, serie 9… )
configured/monitored
Record in IP DR-link
2  Try to record in IP DR-link ( send a “Start IP
Recording” event from the VRS ) the set
 In the VRS application, check there is no record No record in the
3
 In the VRS application, check the logs… recording interface
Note: => from debdrlink_LT_HP_QA… log file

 CSTA_UNIVERSAL_FAILURE_CONF err=2
6.1.4 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 Id
Record authorization = False
1  In the Phone Features Category of the set, put
the “Record Authorization” = False
Try to Record
2  Make a call with the set
 Try to record the set
 In the VRS application, check there is no record
3 No Record
 In the VRS application, check the logs…
Note: CSTA_UNIVERSAL_FAILURE_CONF err=19

6.1.5 Test Results : 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”
Test
Case Id
“DR-link on IP supported” = FALSE
1  Manage the parameter “DR-Link on IP
supported” = False
Record in IP DR-link
 Try to record in IP DR-link ( send a “Start IP
2
Recording” event from the VRS ) a monitored
VoIP set
3 No record

6.1.6 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 Id
License file with no recording licenses
1  Put a new license file with no recording ( lock 334
=0)
Try to Record
2  Make a call with the set
 Try to record the set
3 No record
6.1.7 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 Id
License file with limited recording licenses
1  Put a new license file with limited recording ( lock 334 = 1
334 with limited value )
Try to Record
2  Try to record the set when the limited recording
license is reached
Check the records in the VRS 1 record, the second
 In the VRS application, check there is no record simultaneous call is
3
 In the VRS application, check the logs… not recorded (no
record)

6.2 Switch Failure

6.2.2 Objectives
This test is intended to check the recovering of the VRS after a Switch failure.
The switch has only one CPU.
6.2.3 Test Results
Test
Case Id
Inbound call
 Make an inbound call to A
1
 A and the external party speak for at least 10
seconds
Outbound call
 Make an outbound call from B
2
 B and the External party speak for at least 10
seconds
Internal call
3  Make an internal call from C to D
 C and D speak for at least 10 seconds
Switch failure
4
 Reboot the OXE
3 Recs
Audio OK
 In the VRS application, check the records
5 (record stopped when
link to TSAPI Server is
detected as lost)
New calls after the reboot
 Perform new calls ( internal, inbound & outbound
6
calls )

 In the VRS application, check the new records Recs OK
7
 In the VRS application, check the logs… Audio OK
Note:
From the Altitude software, we have an indication about the status of the TSAPI link:

From the DR-Link connector, we see the connection Failed:
When the link is retrieved:

Record from the HigherGround recorder:

6.3 CTI Link Failure – TSAPI Recorder link Failure
6.3.1 Test Environment TSAPI Server Recorder
link failure.
TSAPI Server Altitude is
UP and Running

6.3.2 Objectives
This test is intended to check the recovering of the VRS after a CTI Link failure with an OTS service
failure.
6.3.3 Test Results
Test
Case Id
Management of “End Of Recording on end of calls”
1  Manage the parameter “End of Recording on end
of calls” = NO
Inbound call on pilot CCD
 Make an inbound call to pilot CCD => to Agent
Agent 1
2 V1
 Answers from the Uagent (Agent 1) interface
IP Recording
 Agent V1 speaks for at least 10 seconds
Disconnection of TSAPI Server
3
 Unplug the IP cable of the TSAPI Server
End of call
4
 Stop the call
Check if there are the records in the VRS
 In the VRS application, check the records 1 Rec
5
Reconnection of the TSAPI Server

6
 Plug the IP cable of the TSAPI Server
New calls
 Perform a new call (inbound from Uagent Agent
7
1)

 In the VRS application, check the new records 1 Rec
8
Note:
Recorder is checking if the TSAPI link is alive every 15 seconds.
 DRLink connector (TSAPI alive)

Record from the HigherGround recorder:

6.4 CTI Link Failure – TSAPI Altitude link Failure
TSAPI Server Altitude link
failure.
TSAPI Server Recorder is
still UP and running

6.4.2 Objectives
This test is intended to check the recovering of the VRS after a CTI Link failure with an OTS service
failure.
6.4.3 Test Results
Test
Case Id
Management of “End Of Recording on end of calls”
1  Manage the parameter “End of Recording on end
of calls” = NO
Inbound call
2 V1
 Answers from the Uagent (Agent 1) interface
 Agent V1 speaks for at least 10 seconds
Disconnection of TSAPI Server (Altitude)
3
 Unplug the IP cable of the TSAPI Server
End of call
4
 Stop the call
2 Recs
(1 Rec is the audio
Check if there are the records in the VRS before the link is
 In the VRS application, check the records detected lost by the
5
 In the VRS application, check the logs… Altitude, another Rec
from link failure
detected by Altitude to
the end of the call)
Reconnection of the TSAPI Server Reconnection is OK
6
 Plug the IP cable of the TSAPI Server Monitor is OK
New calls
Inbound call
7  Make an inbound call to pilot CCD => to Agent
V1
Answer by the Uagent
8
Note:
Altitude TSAPI Server IP link failure (disconnection):

From the HigherGround recorder interface, we see 2 records. One concerns the part of the capture
before the IP link failure and the seond concerns the part after the link is lost until the end of the call.

6.5 VRS : Link Failure During the tests, the recorder
and the Altitude components
6.5.1 Test Environment (connector + software) were
installed on the same server.
ONE BOX SOLUTION

6.5.2 Objectives
This test is intended to check the recovering of the VRS after a Link failure of the VRS.
6.5.3 Test Results
Test
Case Id
Inbound call
1
V1
Answer the call by the Uagent interface
Disconnection of Server (Recorder + Altitude)
2
 Unplug the IP cable of the VRS
Close the current call
3
 Stop the current call
Connection of the VRS
4  Plug the IP cable of the VRS
1 Rec
Audio OK
The Rec is stopped as
5 soon as the IP link is
disconnected from the
server (Recorder +
Altitude)
New calls
6  Perform new calls (inbound calls )

7
Note:
Step 2
After about 2 min the TSAPI Server is detecting the lost of the TSAPI client.
So from the OXE, the CSTA client lost is type DR-Link and the monitorings.
Step 4
Reconnection OK, CSTA client from OXE is typed DR-Link and Monitorings are OK.
Test => Short IP disconnection:

Call established
Disconnection IP link of the server
30 seconds later
Reconnection IP link of the server
30 seconds later
End of the call
 2 Recs displayed. 1 rec for the period before the IP disconnection
And another Rec for the period at the reconnection to the end of the
call.
See screeshot of the records at the next page.

6.6 Redundancy Tests : OXE in Spatial Redundancy

6.6.2 Objectives
These tests are intended to check the recovering of the Voice Recording System using redundancy
elements.
6.6.3 Test Results : OXE in Spatial Redundancy
This test is intended to check the recovering of VRS after a CPU disconnection & a switchover.
In this test, both CPUs are used in spatial redundancy ( in different IP sub networks ).
Test
Case Id
Management of the CPUs
 Manage both CPUs ( CS1 Main & CS2 Stby ) in
1 two IP sub networks
 Check that the spatial redundancy is managed
New calls
2  Perform a new inbound call to A
Disconnection of the Main CPU CS2 is Main

 Unplug the CS1 2 CSTA clients
3  Check the CS2 becomes Pseudo-Main connected to the CS2
 Check the new CTI link Monitorings devices
OK
End of calls
4  Stop the current calls

1 Rec
5 Audio OK
New calls

7
Reconnection of CS1
 Plug the CS1
8  The CS1 automatically shutdown
 Check CS2=Main and CS1= Stby
New calls
Shutdown of CS2
 Shutdown of CS2
10
 CS1 becomes Main
End of calls

 In the VRS application, check the records 1 Rec
12
New calls
13
 Perform a new inbound call to A

14

6.7 Redundancy Tests: TSAPI Backup => for the TSAPI Server
Recorder
172.27.144.32
172.27.145.25

6.8 Objectives
These tests are intended to check the recovering of the Voice Recording System using TSAPI
Backup.
6.8.1 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 Id
Management of the TSAPI server Backup

 Check that the TSAPI server Backup is installed (
1
on a dedicated machine ), configured and
running
Inbound call
 Make an inbound call to A
2
 A and the External party speak for at least 10
seconds
Stop the Main Alcatel Open Telephony service
 Stop the main Alcatel-Lucent’s service
3
(Alcatel Open Telephony).
 Wait until TSAPI Backup is Up
End of calls
1 Rec
Audio OK
5 Rec stopped as soon
as the TSAPI Service
is stopped
New calls ( with TSAPI Backup )

7
Start the Main Alcatel Open Telephony service

 Start the Main Alcatel-Lucent’s service (Alcatel
8 Open Telephony).
 Wait until TSAPI Main is Up ( Main replaces
automatically Backup )
New calls ( with TSAPI Main )

1 Rec
Audio OK
Note:
See reconnection of the TSAPI Backup on the OXE => 172.27.145.25 => DR_LINK => 8
monitorings

6.9 Passive Call Server ( IP DR-Link )
NOT SUPPORTED

6.9.2 Objectives :
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
Test
Case Id
One Box solution
Management of the Logger
during the test.
1  Manage a Passive Call Server in the OXE
Passive Call Server
 Manage the Passive Call Server in the Logger
test not applicable.
Network failure
 Unplug the IP cables of the Main & the Standby
CPU
2  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
Internal calls
 Make an internal call between V1 & V2
3
 V1 & V2 speak for at least 10 seconds before
hanging up
Inbound calls
 Make an inbound call to V1
4
 V1 & the external party speak for at least 10
seconds before hanging up
Outbound calls
 Make an outbound call from V1
5
 V1 & the external party speak for at least 10
seconds before hanging up
Check if there are the records in the logger
 Check the records in the logger
6
Network reconnection
 Plug the IP cable of the Main & the Standby CPU
 The remote media gateway reboots automatically
7
 The Logger is now reconnected with the Voice
Recording System
Synchronization – Retrieving data

8  Check that the Voice Recording Server retrieve
these records
New calls
 Perform new calls : internal, oubound & inbound
9
calls
6.10 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.
6.10.2 Test Results
Test Case Note Comments
Logs from the Altitude Connector

Understanding of the log files of the Recording System Good Logs from the AER
HigherGround
6.11 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.
6.11.2 Test Results
Test Case Note Comments
Only up or
Notifi in the Connector
Notifications & Alarms of the Voice Recording System down (for the
(Notif in the AER HigherGround)
link)
Note: see the screenshot at the next page.
The screenhot is showing the connection from the connector => Xperirence concerns the
connection to the Altitude software and Recorder concerns the connection to the AER
HigherGround.

Uagent connected

7 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
Customized parameter
from HigherGround
DNIS
Not available if the OTCS
solution is ON
Customized parameter
from HigherGround
ANI
Not available if the OTCS
solution is ON
Provided from the
Direction ( In / Out )
Altitude OTCS solution
Station ID is displayed
Agent ID
but not the Agent ID
Own RecKey build by
Call ID
GlobalCallID
Alcatel-Lucent private
CSTA
Agent Name
Agent Group
Pilot Name
Associate Data
Associate station
Global Callid

8 Appendix A : AAPP member’s Application
description
Altitude Enterprise Recorder is a multichannel data recording, storage, and analytics
solution that offers a robust Quality Assurance and assessment tools for agent
performance. It allows to record voice and agent screens together with the associated
metadata and provides an omnichannel view of all interactions between agents and
customers. Customer satisfaction data is attached to the call and viewed in the interaction
history.
Altitude Enterprise Recorder offers a variety of reports, views, and grading criteria. You
can create multiple grading forms that are customized for your organization by applying
relevant questions to your forms.
To examine overall performance of agents and teams, analytics can be applied with
scorecard reports, historical or real-time, which can be scheduled as periodical or retrieved
on-demand. The reports can be displayed by various parameters such as question,
interaction number, interaction media, call duration, and more. Metrics and key
performance indicators can be viewed in a dashboard by table or graphically for visual
comparison

9 Appendix B: Configuration requirements of the
AAPP member’s application
Please Consult altitude-enterprise-recording-telephony-switch-integration.pdf
(section “Integration with Alcatel-Lucent OXE”)

10 Appendix C: Alcatel-Lucent Enterprise
Communication Platform: configuration
requirements
10.1 Configuration for IP DR-Link
10.1.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.

10.1.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.
10.1.3 Recording IP Logger
Declare all IP loggers thanks this menu.

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

11 Appendix D: AAPP member’s escalation
process
To contact the technical support:
 Email: customer.care@altitude.com
 Customer Care web site: https://customercare.altitude.com/
Applicable scenarios:
 ALE Partner is also Altitude Partner: In this case a contract between the partner
and Altitude should be in place; The contract will define the procedures, but those
should be the standard ones.
 ALE partner is not Altitude partner (unlikely scenario): the partner should notify the
customer to do a maintenance contract with Altitude. Customer to follow the
standard requests for support.
Altitude Partners receive a document (Operations Guide) with all the information regarding
the escalation process (it can be different depending on the region).

12 Appendix E: AAPP program
12.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 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 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
https://www.al-enterprise.com/en/partners/aapp
12.2 Enterprise.Alcatel-Lucent.com
You can access the Alcatel-Lucent Enterprise website at this URL: https://www.al-enterprise.com

13 Appendix F: AAPP Escalation process
13.1 Introduction
The purpose of this appendix is to define the escalation process to be applied by the ALE Business
Partners when facing a problem with the solution certified in this document.
The principle is that ALE 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 and the Application Partner, are engaged as following:
(*) The Application Partner Business Partner can be a Third-Party company or the ALE
Business Partner itself

13.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 and the Application Partner, are engaged:
Case 1: the responsibility can be established 100% on ALE side.

In that case, the problem must be escalated by the ALE Business Partner to the ALE
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 Business Partner will escalate the problem to the ALE Support Center only if
the Application Partner has demonstrated with traces a problem on the ALE side or if
the Application Partner (not the Business Partner) needs the involvement of ALE
In that case, the ALE Business Partner must provide the reference of the Case Number on
the Application Partner side. The Application Partner must provide to ALE the results of its
investigations, traces, etc, related to this Case Number.
ALE 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 offers the “On
Demand Diagnostic” service where ALE 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://www.al-
enterprise.com/en/partners/aapp) or Enterprise Business Portal (Url: Enterprise Business Portal)
web sites.
IMPORTANT NOTE 2: Involvement of the ALE Business Partner is mandatory, the access to the
Alcatel-Lucent Enterprise platform (remote access, login/password) being the Business Partner
responsibility.

13.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 Support and shares all trouble shooting information and conclusions that shows a
need for ALE 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 offers an “On Demand Diagnostic” service where assistance will be
provided for a fee.

13.4 Technical support access
The ALE 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): https://www.al-enterprise.com/en/partners/aapp
 e-Support from the ALE Business Partners Web site (if registered Alcatel-Lucent Enterprise
Business Partners): https://businessportal2.alcatel-lucent.com click under “Contact us” the
eService Request link
 e-mail: Ebg_Global_Supportcenter@al-enterprise.com
 Fax number: +33(0)3 69 20 85 85
 Telephone numbers:
ALE Business Partners Support Center for countries:
Country Supported language Toll free number

France
Belgium French
Luxembourg
Germany
Austria German
Switzerland
United Kingdom
Italy
Australia
Denmark
Ireland
Netherlands +800-00200100
South Africa
Norway
English
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


IWR 0334 Ed01 - Altitude AER 8.5 - OmniPCXEnterpriseR12.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IWR 0334 Ed01 - Altitude AER 8.5 - OmniPCXEnterpriseR12.3

Uploaded by

Copyright:

Available Formats

ALE Application Partner Program

ALE MAKES NO REPRESENTATIONS, WARRANTIES OR CONDITIONS WITH RESPECT TO THE APPLICATION

ALE Application Partner Program – Inter-working report - Edition 1 - page 1/116

Date of the certification 20 to 22 May 2019

ALE representative Bernard MAREC

Alcatel-Lucent Enterprise OmniPCX Enterprise

Author(s): Bernard Marex

Edition 1: creation of the document – May 2019

Passed with restrictions

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

IWR validity extension

ALE Application Partner Program – Inter-working report - Edition 1 - page 2/116

Contact name: Rui Ramos

Address : Rua Frederico George 37A

City: 1600-468 Lisboa

Phone: 00351 915406773

Web address: https://www.altitude.com/

ALE Application Partner Program – Inter-working report - Edition 1 - page 3/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 4/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 5/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 6/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 7/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 8/116

It certifies proper inter-working with the AAPP member’s application.

- the Technical Support page of the Enterprise Business Portal

- the Application Partner portal (https://www.al-enterprise.com/en/partners/aapp) with free

ALE Application Partner Program – Inter-working report - Edition 1 - page 9/116

A new release is identified as following:

ALE Application Partner Program – Inter-working report - Edition 1 - page 10/116

3.1 Case of additional Third party applications

ALE Application Partner Program – Inter-working report - Edition 1 - page 11/116

Application family : Voice Recording System

Application commercial name: Altitude Enterprise Recording

Application version: 8.5.1000

Interface type: TSAPI Premium Server

Interface version (if relevant): Altitude (Xperience) => csta.dll 7.3.2

Voice logger Features available Features Features tested in this

Trunk side recording NO NO

Remote DR-Link recording * NO NO

Free seating YES

ALE Application Partner Program – Inter-working report - Edition 1 - page 12/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 13/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 14/116

 OmniPCX Entreprise: Appliance servers, T2 and PCM interfaces, UA and Z interfaces,

 Voice Recorder System interface: Recorder (HigherGround) + Altitude connector +

1.2 Software configuration

 Alcatel Communication Platform: OmniPCX Enterprise R12.3 M4.302.5.h

ALE Application Partner Program – Inter-working report - Edition 1 - page 15/116

2.1 Summary of main functions supported

3 Way Conference Call OK OK   Correction added

Private incoming calls NA 

Private outgoing calls NA

ALE Application Partner Program – Inter-working report - Edition 1 - page 16/116

2.2 Summary of problems

ALE Application Partner Program – Inter-working report - Edition 1 - page 17/116

2.4 Notes, remarks

Recorder (HigherGround) interface => display of the record

ALE Application Partner Program – Inter-working report - Edition 1 - page 18/116

ALE Application Partner Program – Inter-working report - Edition 1 - page 19/116

4.1 Inbound calls

4.1.1 Test Objectives

4.1.2 Test Results

Record from the HigherGround interface: