ale application partner program inter-working report

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

Copyright © ALE 2019

ALE Application Partner Program Inter-Working Report

Partner: Newvoice Application type: Alarm Server

Application name: Mobicall 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. © 2018 ALE International. All rights reserved.



Certification overview

Date of the certification May-July 2019

ALE representative Thierry Chevert

AAPP member representative Olivier Oudom Gaspard Morel

Alcatel-Lucent Enterprise Communication Platform

OmniPCX Enterprise

Alcatel-Lucent Enterprise Communication Platform release

R 12.3 – M4.302.5h

AAPP member application release R8.3.2

Application Category Event monitoring & Alerting

Author(s): Thierry Chevert Reviewer(s): Rachid Himmi, Krassimira Atanassov Revision History Edition 1: creation of the document – March 2019

Test results

Passed

Refused Postponed

Passed with restrictions

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

IWR validity extension

None



AAPP Member Contact Information

Contact name: Olivier Oudom Title: Project Manager Address: Chemin du Joran 8B Zip Code: 1260 City: Nyon Country: Switzerland Phone: +41587501122 Fax: - Mobile Phone: - Web site: www.newvoiceinternational.com Email address: [email protected]



TABLE OF CONTENTS

1 INTRODUCTION .................................................................................................................................... 7

2 VALIDITY OF THE INTERWORKING REPORT ............................................................................. 8

3 LIMITS OF THE TECHNICAL SUPPORT ......................................................................................... 9

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

4 REMINDER ON ALE’S ALARMING SERVICES ............................................................................ 10

4.1 LOCATION SERVICE ............................................................................................................................ 10 4.1.1 DECT Location ......................................................................................................................... 10 4.1.2 BTLE Location .......................................................................................................................... 10

4.2 LIVE & NOTIFICATION SERVICE ......................................................................................................... 10 4.2.1 Live calls ................................................................................................................................... 11 4.2.2 Status calls ................................................................................................................................ 11 4.2.3 Key events call .......................................................................................................................... 11 4.2.4 Notification calls ....................................................................................................................... 11

4.3 ALARM SERVER NOTIFICATION SERVICE ........................................................................................... 11

5 APPLICATION INFORMATION ........................................................................................................ 13

6 TEST ENVIRONMENT ........................................................................................................................ 14

6.1 CONFIGURATION DIAGRAM ................................................................................................................ 14 6.2 HARDWARE CONFIGURATION ............................................................................................................ 14 6.3 SOFTWARE CONFIGURATION .............................................................................................................. 15

7 SUMMARY OF TEST RESULTS ........................................................................................................ 16

7.1 SUMMARY OF MAIN FUNCTIONS SUPPORTED ...................................................................................... 16 7.1.1 Alarming services ...................................................................................................................... 16 1.1.1 BT Beacons Location service .................................................................................................... 17 7.1.2 Generic calls ............................................................................................................................. 18 7.1.3 Conference call with Alarm server ........................................................................................... 19

7.2 SUMMARY OF PROBLEMS ................................................................................................................... 19 7.3 SUMMARY OF LIMITATIONS ............................................................................................................... 19 7.4 NOTES, REMARKS .............................................................................................................................. 19

8 TEST RESULT TEMPLATE ................................................................................................................ 20

9 TEST RESULTS USING SIP TRUNK ................................................................................................. 21

9.1 GENERIC SIP CALLS TESTS ................................................................................................................ 21 9.1.1 SIP Options ............................................................................................................................... 21 9.1.2 SIP Authentication and Registrar ............................................................................................. 21 9.1.3 SIP call set-up and call release ................................................................................................. 22 9.1.4 SIP calls to various idle phones ................................................................................................ 23 9.1.5 SIP call to various busy phones ................................................................................................ 24 9.1.6 SIP calls to IBS-DECT sets out of radio range ......................................................................... 25 9.1.7 SIP calls to forwarded phone or Dect sets ................................................................................ 26 9.1.8 SIP calls to phone that is forwarded to voice mail.................................................................... 26 9.1.9 SIP call to phone in immediate call forwarding to external destination ................................... 27 9.1.10 SIP call to Out of Service phone ............................................................................................... 28 9.1.11 Conference call with alarm server and DTMF over RTP ......................................................... 28 9.1.12 SIP call with Special Characters in CLI ................................................................................... 29

9.2 ALARMING WITH 8242 DECT AND 8262 DECT USING ENTERPRISE MODE ....................................... 30 9.2.1 Test cases linked to “Live signal” on DECT 8262 and 8242 DECT ........................................ 30 9.2.2 Test cases linked to “Status message” on 8242 DECT ............................................................. 31 9.2.3 Test cases linked to “Status message” on DECT 8262 ............................................................. 32



9.2.4 Test cases linked to “Key events” on 8242 and 8262 ............................................................... 34 9.2.5 Test cases linked to “Notification” on 8242 DECT .................................................................. 35 9.2.6 Test cases linked to “Notification” on DECT 8262 with "Panic Red button" .......................... 37 9.2.7 Test cases linked to "Man Down" or "Lost of verticality" on DECT 8262 ............................... 38 9.2.8 Test cases linked to "No Movement" on DECT 8262 ................................................................ 39 9.2.9 Test cases linked to "SHOCKS" detected on DECT 8262 ......................................................... 40 9.2.10 Test cases linked to "Pull cord" detected on DECT 8262 ......................................................... 42 9.2.11 Test cases linked to base station location using RPN ............................................................... 43

9.3 INCOMING ALARM FROM SIP ALARM SERVER TO HANDSETS ............................................................. 45 9.3.1 Incoming Alarms on DECT 8262 and 8242 DECT ................................................................... 45

10 TEST RESULTS USING THE T2 ISDN TRUNK INTERFACE .................................................. 48

10.1 GENERIC TEST CALLS OVER ISDN T2 ................................................................................................ 48 10.2 ISDN LINK CONNECTION ................................................................................................................... 48

10.2.1 ISDN call set-up and call release.............................................................................................. 49 10.2.2 ISDN calls to various idle phones ............................................................................................. 49 10.2.3 ISDN call to various busy phones ............................................................................................. 50 10.2.4 ISDN calls to DECT sets out of radio range ............................................................................. 51 10.2.5 ISDN calls to forwarded phone or DECT handset .................................................................... 51 10.2.6 ISDN calls to phone that is forwarded or Diverted to voice mail ............................................. 52 10.2.7 ISDN call to phone in immediate call forwarding to external destination ................................ 52 10.2.8 ISDN call to Out of Service phone ............................................................................................ 53 10.2.9 ISDN call with Special characters in CLI ................................................................................. 53 10.2.10 Conference call with alarm server over T2 ISDN ................................................................. 54

10.3 ISDN ALARMING WITH 8242DECT AND 8262DECT ........................................................................ 55 10.3.1 Test cases linked to “Live signal” on 8242DECT and 8262DECT .......................................... 55 10.3.2 Test cases linked to “Status message” on 8242 DECT ............................................................. 55 10.3.3 Test cases linked to “Status message” on 8262DECT .............................................................. 56 10.3.4 Test cases linked to “Key events” 8242DECT and 8262DECT ................................................ 57 10.3.5 Test cases linked to “Notification” on 8242DECT ................................................................... 59 10.3.6 Test cases linked to “Notification” on 8262DECT ................................................................... 60

10.4 HANDSET EMBEDDED ALARMS FROM 8262DECT OVER ISDN .......................................................... 62 10.4.1 Test cases linked to "Man Down" or "Lost of verticality" on 8262DECT ................................ 62 10.4.2 Test cases linked to "No Movement" on 8262DECT ................................................................. 63 10.4.3 Test cases linked to "SHOCKS" detected on 8262DECT .......................................................... 65 10.4.4 Test cases linked to "Pull Cord” on 8262DECT ....................................................................... 66 10.4.5 Test cases linked to DECT base stations Location.................................................................... 68

10.5 INCOMING ALARM FROM T0/T2 ISDN ALARM SERVER TO HANDSETS ............................................... 69 10.5.1 Incoming Alarms on 8242DECT and 8262DECT ..................................................................... 69

11 USE OF BLUETOOTH BEACONS ................................................................................................. 72

11.1 TEST CASES LINKED TO BLUETOOTH BEACONS’ LOCATION IN CASE OF SMART BEACON .................... 72 11.2 TEST CASES LINKED TO BLUETOOTH BEACONS’ LOCATION IN CASE OF ALARMING ........................... 73

12 HIGH AVAILABILITY CONFIGURATIONS ............................................................................... 74

12.1 SPATIAL REDUNDANCY COM SERVER – SINGLE MOBICALL (SIP TRUNKING) ................................... 74

13 ALARMING WITH OXE NETWORKING CONFIGURATION ................................................. 75

14 APPENDIX A : AAPP MEMBER’S APPLICATION DESCRIPTION ........................................ 76

14.1 APPLICATION DESCRIPTION ............................................................................................................... 76

15 APPENDIX B: CONFIGURATION REQUIREMENTS OF THE AAPP MEMBER’S

APPLICATION .............................................................................................................................................. 80

15.1 HARDWARE EQUIPMENT CONFIGURATION ......................................................................................... 80 15.2 SOFTWARE CONFIGURATION .............................................................................................................. 80

16 APPENDIX C: ALCATEL-LUCENT ENTERPRISE COMMUNICATION PLATFORM:

CONFIGURATION REQUIREMENTS ...................................................................................................... 92

16.1 SITE SURVEY ...................................................................................................................................... 92



16.2 EQUIPMENT CONFIGURATION ............................................................................................................. 92 16.3 PARAMETERS’ MANAGEMENT IN OMNIPCX ENTERPRISE COMSERVER ............................................. 93

16.3.1 Prefix to call alarm server ........................................................................................................ 93 16.3.2 Discriminator number according to entities for SIP ................................................................. 94 16.3.3 Discriminator link to ARS route list .......................................................................................... 94 16.3.4 Linking ARS with External SIP Gw and Trunk Group protocol .............................................. 96 16.3.5 Management of External trunk group ....................................................................................... 96 16.3.6 Internal SIP gateway. ................................................................................................................ 98 16.3.7 External SIP gateway ................................................................................................................ 99 16.3.8 DECT 8262/8242 configuration. ............................................................................................. 100 16.3.9 Licences .................................................................................................................................. 102

16.4 CAPTURE SAMPLES .......................................................................................................................... 103

17 APPENDIX D: AAPP MEMBER’S ESCALATION PROCESS .................................................. 109

17.1 CONTACT INFORMATION ................................................................................................................. 109 17.2 3

RD PARTY SUPPORT DETAIL ............................................................................................................. 109

17.2.1 Contact – Germany, Swiss, Austria, Netherlands & Eastern Europe ..................................... 109 17.2.2 Contact – France, Swiss, Belgium, Luxembourg & Western Europe ...................................... 109 17.2.3 Contact - Dubai....................................................................................................................... 110 17.2.4 Contact - USA ......................................................................................................................... 110 17.2.5 Contact - Australia .................................................................................................................. 110 17.2.6 General Information ............................................................................................................... 110 17.2.7 Severity Description and Response Times .............................................................................. 110 17.2.8 Support Level Definitions ........................................................................................................ 111

17.3 CONTACT INFORMATION ................................................................................................................. 111 17.4 CONTACT INFORMATION ................................................................................................................. 111

18 APPENDIX E: AAPP PROGRAM ................................................................................................. 112

18.1 ALCATEL-LUCENT APPLICATION PARTNER PROGRAM (AAPP)....................................................... 112 18.2 ENTERPRISE.ALCATEL-LUCENT.COM .............................................................................................. 113

19 APPENDIX F: AAPP ESCALATION PROCESS ......................................................................... 114

19.1 INTRODUCTION ................................................................................................................................ 114 19.2 ESCALATION IN CASE OF A VALID INTER-WORKING REPORT ........................................................... 115 19.3 ESCALATION IN ALL OTHER CASES ................................................................................................... 116 19.4 TECHNICAL SUPPORT ACCESS .......................................................................................................... 117



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.

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

https://www.al-enterprise.com/en/partners/aapp



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 For details on all cases (3

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

etc.), please refer to Appendix F “AAPP Escalation Process”.

3.1 Case of additional Third party applications

In case at a customer site an additional third party application NOT provided by ALE 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 Reminder on ALE’s Alarming services

4.1 Location service This service will help the security group to find the place where the Lone Worker is located and reach this place as quick as possible. This can be display in a WEB interface onto a map according to the Alarm server provider.

4.1.1 DECT Location The DECT Handset monitors the radio coverage that it perceives to be able to set up at any time a call with the infrastructure with the best audio conditions. Therefore, it has the knowledge at a given location of all the Base Stations he can receive a signal from and the associated strength of the signal (RSSI) gives a relation with the distance between the Base Station and the DECT Handset. When signaling an alarm to the Alarm server, the DECT handset will send the RSSI of the 3 (Office mode) or 4 (Enterprise mode) best Base Stations that he can see, so that the server can locate accurately the DECT Handset position. In case the DECT Handset sees less than 4 (or 3) Bases stations, the message will indicate the valid Base Stations that the server should use in the message to compute the DECT Handset location (Enterprise & Office modes only)

This service is available on 8242DECT and 8262DECT handsets.

4.1.2 BTLE Location Previously, the location of a DECT sets was done using the RPN Number (Base Station Id) and Signal strength but now we add this new possibility to use BT-Beacons to enhanced the location and to cover the dark areas. The location can be improved using BTLE beacons, this will allow for example to discriminate on which exact floor is located the DECT handset by putting a beacon in the proximity of each floor entrance.

This service is only available on 8262DECT handset.

4.2 Live & Notification service The DECT Handset can send regular information (defined as “Live”) or event triggered (defined as “Notifications”, “Key events” or “Status”) to an Alarm server. These messages are sent to the Alarm Server by setting up a call toward the Call Server. These calls are set up by dialing a trunk access code to gain access to the Alarm server, followed by digits containing the data to be processed by the Alarm server (Enterprise & Office modes only). Those digits will indicate the type of call (“Live”, “Notifications”, “Key events” or “Status”) and additional information related to the call type. This service is available on 8242 and 8262 Dect handsets.



4.2.1 Live calls Live calls are triggered at programmable intervals, when the Handset is in idle state, and provide the Alarm Server the current DECT Handset location and state. This will enable the Alarm Server to monitor that the Handset is performing correctly, and that end user monitoring is active. Location can be used by the Alarm server to activate Notifications to the proper located user if an emergency shall occur, thus allowing the best response time to manage such event (Enterprise & Office modes only)

4.2.2 Status calls Status calls are triggered by DECT Handset status change such as being put in/out of charger, being switched on/off. This will allow the Alarm server to know that monitoring should start or stop and that subsequent messages call might be irrelevant and could be discarded (Enterprise & Office modes only).

4.2.3 Key events call Key Events calls are triggered by the end user long press of any digit key, for reporting process of completed tasks. For example: in Hotel business, the cleaning personnel shall report progress on room availability to allow the registration of new customers at the front desk (Enterprise & Office modes only).

4.2.4 Notification calls Notifications calls are triggered by the end user pressing the Alarm button on the DECT Handset to signal an unexpected or emergency. This will allow the Alarm server to launch the appropriate actions to give assistance to the end user. The embedded location data will provide means to activate the best appropriate means to ensure adequate response time to the end user request (Enterprise & Office modes only).

4.3 Alarm server Notification service Additionally, to the Handset Alarming feature, the Alarm server can send alarm messages or make voice calls upon trigger of external events, to ask the user to react and make corrective actions. Messages are sent as a voice call or may use the special call functions available on the 8242 and 8262 Dect handsets. The messages, as special calls, are sent by using the first two characters of the Caller Name Identification (CNI) field. When the alarm server initiates a call to the DECT handset, it has priority on all other actions being done on the handset. The DECT handset then reads the CNI being sent and does the appropriate action. For example: displaying “Fire Alarm” on the screen and ringing at maximum level at the same time. List of available alarm features: 8242 and 8262 Dect handsets:

trigger handset ringing with normal alarm ring and volume as programmed in the Alarm settings menu



trigger handset ringing with urgent alarm ring and volume as programmed in the Alarm settings menu

trigger handset ringing with very urgent alarm ring and volume as programmed in the Alarm settings menu

trigger handset automatic answer in Handsfree mode



5 Application information

Application family : Alarm Server Application commercial name: MOBICALL Application version: NVT 8.3.2 SQL 8.3.2 WEB 8.3.2-20190222

Interface type: SIP trunking with Alarming, location and Notification services

Brief application description:

MobiCall is a major platform for real-time event processing. The services are centered around the MobiCall gateway between events and experts which is an individually configured solution for alerting, mobilization, evacuation, information distribution and monitoring in the professional environment MobiCall is a highly reliable and flexible event and alarm management appliance that manages information, alerts and notifications generated by different sources and this includes:

Notification,

voice conference,

IVR,

dashboard,

video recording,

indoor localization,

ask management for smart phone and watches

The solution enables organizations to integrate their existing communication infrastructure and offering an easy configuration and support for every device currently in use; empowered by on premise, cloud, hybrid infrastructures and IoT solutions. Main benefits are:

• Intuitive operation with modular design • Fully redundant, distributed and virtualized architecture • Supports any intervention team, where every second counts • Offers an easy configuration and support for every device currently in use • Empowered by on premise, cloud, hybrid infrastructures and IoT solutions • Provides a large number of connectors from the event input to information distribution



6 Test environment

6.1 Configuration diagram This setup depicts actual test enviroment. Below figure features OXE in our VPN Setup.

6.2 Hardware configuration List main hardware equipments used for testing. We used two setup for testing. The application

OmniPCX Entreprise:

o CS (Call Server Processing Unit) ESXI server

o GD (Gateway driver processing Unit

o PRA T2 (ISDN Access)

o MIX 2/4/4 (ISDN T0, digital & analog interfaces)

o UA digital and analog sets Prefix 85 (ARS) uses to call Mobicall via SIP Trunking External gateway. Prefix 87 uses to call the ISDN T2 toward Mobicall T2.

DECT 8262 DECT8242

OmniPCX Enterprise SIP Trunking

Subnet 10.1.0.0

CS Stand-By CS MAIN

Switch / Router Subnet 10.10.10.0

OmniPCX Enterprise Mobicall SIP

Premium Deskphone

Premium Deskphone

Mobicall TDM ISDN

T2 Trunking

Mobile 8118



6.3 Software configuration

Alcatel Communication Platform: R 12.3 - M4.302.5h

8242DECT: 63.82 Branch 0003 - 29/10/2018

8262DECT: 5681 Branch 0006 - 20/12/2018

Partner Application : 8.3.2

Mobicall SIP running in VM on VMWare ESXi 6.0

Mobicall TDM running on PC Windows 10 Pro and Audio PRA card.



7 Summary of test results

7.1 Summary of main functions supported The Alarm Server application supports SIP Trunking protocol with the Enterprise message mode (26 digits). The message mode is configured in the DECT set (8262 and 8242). In the below tables, the following abbreviations apply:

NT: Not Tested,

NA: Not Applicable,

NS: Not Supported by Application,

OK: Working

7.1.1 Alarming services

Test related to alarm messages sent by DECT sets to External application.

Features

Alarm and notification calls from Dect sets Alarm Server

IBS-Dect

8242

DE

CT

8262

DE

CT

Live call OK OK

Notification call OK OK

Status call OK OK

Keys event call OK OK

Man down call NA OK

No movement call NA OK

Shock call NA OK



Tests related to alarms sent by external application to DECT sets (Display text and special ringing)

Features

Incoming Alarms from Alarm Server Dect sets

IBS-Dect

8242

DE

CT

8262

DE

CT

Normal alarm (B~) OK OK

Urgent alarm (C~) OK OK

Very urgent alarm (D~) OK OK

Hands free mode alarm (E~) OK OK

1.1.1 BT Beacons Location service

Features

Location services

Bluetooth Location

Smart Beacons

Comments

Live signal

OK

“Smart beacon” feature configured into the handset. The mode can be entering, leaving or entering/leaving area.

Alarm location

OK

Changing to BT Location instead of DECT location into handset configuration will send BT address at the place of RPN information.

Use of Location to trigger calls NT

Use of location to send messages (SMS or Mail)

NT

Mapping on a location map (Building map or street map)

NT



7.1.2 Generic calls These calls are generated by Alarm Server consequently to an alarm to notify OmniPCX Enterprise users in charge of managing these alarms.

Features

Generic SIP calls from Alarm Server OXE sets

Global status

SIP Authentication & Registrar OK

SIP call set-up and call release OK

SIP calls to various Idle phones OK

SIP call to various busy phones OK

SIP calls to DECT sets out of radio range OK

SIP calls to forwarded phone OK

SIP calls to phone that is forwarded to voice mail OK

SIP call to phone in immediate call forwarding to external destination

OK

SIP call to Out of Service phone OK

SIP call using CLI with special characters OK



7.1.3 Conference call with Alarm server

Features

Conferencing through Alarm Server

Global status

Conference call with SIP Interface NS

7.2 Summary of problems

None

7.3 Summary of limitations

SIP Supervision or keep-alive with SIP Option is not available from Alarm server to OXE while it works from OXE to Alarm server.

Issue with accented characters or special characters over ISDN T2: bad characters conversion or missing characters.

7.4 Notes, remarks

The tests were performed only with IBS Base Stations.



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

Test Case

Id Test Case NA OK NOK Comment

1

Test case 1

Action

Expected result

2

Test case 2

Action

Expected result

The application waits for PBX timer or phone set hangs up

3

Test case 3

Action

Expected result

Relevant only if the CTI interface is a direct CSTA link

4

Test case 4

Action

Expected result

No indication, no error message

… …

Test Case Id: a feature testing may comprise multiple steps depending on its complexity. Each step must 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

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



9 Test Results using SIP Trunk A SIP trunk is established between the OmniPCX Enterprise and Alarm Server Application (alarm server). Note: TPA stands for Third Party Application.

9.1 Generic SIP calls tests

9.1.1 SIP Options

9.1.1.1 Test Objectives

The “Option” SIP message is used by the proxy or the end-point server to check the link status by “keepalive” messages. The OXE SIP External Gateway has a manageable timer (from 0= no Option, to 32000).

9.1.1.2 Test results

Test Case Id

Test Case NA OK NOK Comment

GS1

SIP Options from Alarm Server to OXE

Alarm Server sends a SIP options request Alcatel OXE responds with a proper answer 200-OK.

Not available in Mobicall.

GS2

SIP Options from OXE to Alarm Server

Alcatel OXE sends a SIP options request Alarm Server responds with a proper answer 200-OK.

9.1.2 SIP Authentication and Registrar


To check the SIP related authentication and trunk configuration

9.1.2.2 Test Results

Test Case Id


SA1

SIP Trunk with authentication:

- Setup Alarm Server in trunk mode with authentication - Setup Alcatel-Lucent OXE for Incoming accordingly

(see Annex) - Generate a test call from Alarm Server interface. - Check that the call is accepted, that the phone rings and that a voice message is played.

Minimal Authentication is set to “SIP Digest” and username/password

SA2

SIP Trunk with authentication:

- Setup Alarm Server in trunk mode with authentication - Setup Alcatel-Lucent OXE for Outgoing

accordingly(see Annex) - Generate an alarm from DECT 8262, - Check that the call is accepted and Alarm Server sends

Not supported by Mobicall



Test Case Id


the 200-OK.

SA3

SIP Trunk without authentication:

- Setup Alarm Server in trunk mode without authentication - Setup Alcatel-Lucent OXE accordingly(see Annex) - Generate a test call from Alarm Server Web interface. - Check that the call is accepted, that the phone rings and that a voice message is played.

SA4

SIP Registration from TPA

- Setup Alarm Server in trunk mode with SIP registration - Setup Alcatel-Lucent OXE accordingly(see Annex) -- Check that the Register is correctly sent by TPA to OXE.

Tested with Authentication using Username: mobicall and Password 1234.

9.1.3 SIP call set-up and call release


To check normal SIP calls to various extensions.


Test Case Id


SI1

SIP call to phone and release from PBX

- Generate a call from TPA to phone - Answer the call - Release the call after a few seconds from the phone - Check that a BYE and 200-OK are sent on the SIP signalization.

SI2

SIP call to phone and release from TPA

- Generate a call from TPA to a phone - Answer the call - Wait until call is released by TPA - Check that a BYE and 200-OK are sent on the SIP signalization.

SI3

SIP call to phone that does no answer

- Generate a call from TPA to a phone - Do not answer the call - Wait until call is released by TPA, - Check that a CANCEL and 200-OK are sent on the SIP signalization.



9.1.4 SIP calls to various idle phones


To check normal SIP calls to various IDLE extensions in OXE Test Case:

Hand set is in idle mode

To send a call, generate a test call from the TPA

Accept the call Expected result:

call is accepted by PBX phone,

The text message of the Alarm Server application is used as caller identifier and displayed (16 characters),

On answer a voice message is played by TPA then release of the call.


Test Case Id


SV1

Call to 8128 MIPT in Idle state

Test on Alcatel-Lucent 8128 Test Case defined above Expected result defined above

SV2

Call to 8242 DECT in idle state

Test on Alcatel-Lucent 8242 DECT Test Case defined above Expected result defined above

SV3


Test on Alcatel-Lucent DECT 8262 Test Case defined above Expected result defined above

SV4

Call to Premium Deskphone serie 8 in idle state

Test on Alcatel-Lucent IP Touch 8038 Test Case defined above Expected result defined above

SV5

Call to Analog Phone in idle state

Test on Alcatel-Lucent Analog phone Test Case defined above Expected result defined above

SV6

Call to MyIC Phone 8088 (SIP phone)

Test on Alcatel-Lucent MyIC Phone Test Case defined above Expected result defined above

SV7

Call to Generic SIP Phone

Test on Generic SIP phone Test Case defined above Expected result defined above



9.1.5 SIP call to various busy phones


To check normal SIP calls to various BUSY extensions in OXE Test Case:

Phone is in communication.


Expected result:

According to the phone configuration in OXE, behaviors are different:

o call is rejected if the phone is busy

o the phone is set with "Camp On" protected in "Features" options

TPA logs call is rejected


Test Case Id


SB1

Call to busy 8128 Mobile IPTouch

Test on Alcatel-Lucent 8028

Test Case defined above

Expected result defined above

SB2

Call to busy 8242

Test on Alcatel-Lucent 8242 DECT



SB3

Call to busy DECT 8262

Test on Alcatel-Lucent Mobile 8262



While user fully busy (no camp-on or overflow) then SIP Busy here is sent to TPA that can then execute an action and keep stats on calls.

SB4

Call to busy DECT 8232




SB5

Call to busy IPTouch 8038

Test on Alcatel-Lucent IPT4038



SB6

Call to busy Analog Phone

Test on Alcatel-Lucent Analog phone



If call need to be processed on the called party then Alarm server can use another SIP Trunk with “Urgent Broadcast” activated then it will release the current call and send the alarm call to the user.



9.1.6 SIP calls to IBS-DECT sets out of radio range


To check normal SIP calls to various out of range extensions in OXE Test Case:

Hand Set is in idle mode, out of range

To send a call, generate a test call from the TPA Expected result:

call is rejected SIP 486 - Busy Here

TPA logs the call rejection reason Test was done by powering-off the Dect handsets.


Test Case Id


OR1

Call to 8242 DECT-IBS out of radio range


OR2

Call to 8242 DECT-XBS out of radio range


OR3

Call to DECT8262 out of radio range

Test on Alcatel-Lucent DECT 8262 Test Case defined above Expected result defined above

Call goes to Entity overflow number 12000 but caller is not informed (no moved temporarily)



9.1.7 SIP calls to forwarded phone or Dect sets


To check the sip calls to various forwarded phone sets in OXE registered extensions Test Case:

Phone is in idle state, call forwarding is configured,

To send a call, generate a test call from the TPA,

Accept the call on the forwarding destination

Expected result:

call is forwarded to the target phone

the following behavior should be the same depending on the target phone state


Test Case Id


FO1

Call to IPTouch serie 8

Test on Alcatel-Lucent IPTouch Serie 8 Test Case defined above Expected result defined above

FO2

Call to IBS-8262 DECT

Test on ALE 8262 Test Case defined above Expected result defined above

FO3

Call to 8242 DECT-IP

Test on Alcatel-Lucent 8242 Test Case defined above Expected result defined above

Prefixes are: 51 for immediate forward to destination / 41 for forward cancellation.

9.1.8 SIP calls to phone that is forwarded to voice mail


To check the sip calls to various voicemail forwarded phone sets in OXE Test Case:

Phone is in idle mode, immediate call forwarding to voice mail is configured


accept the call on the forwarding destination; which is another terminal

Expected result:

call forwarded to the target voice mail

the following behavior should the same depending on the target phone state




Test Case


VO1

Call to IPTouch 8038 forwarded to Voice Mail

Test on IPTouch 8038 Test Case defined above Expected result defined above

Mobicall see it as normal answer then send its alert message and take it as answered call.

9.1.9 SIP call to phone in immediate call forwarding to external destination


To check the sip calls to various external forwarded phone sets in OXE Test Case:

Phone is in idle mode, call forwarding is configured


accept the call on the forwarding destination; which is an external destination

Expected result:




Test Case


IM1

Call to DECT 8262 forwarded to public external correspondant

Test on Alcatel-Lucent DECT 8262 fwd to external. Test Case defined above Expected result defined above

IM2

Call to 4068 IPT forwarded to public external correspondant

Test on Alcatel-Lucent IP Touch 4068 fwd to external. Test Case defined above Expected result defined above



9.1.10 SIP call to Out of Service phone


To check the sip calls to various external forwarded phone sets in OXE Test Case:

Phone is out of service


call is rejected with 480 – Temporarily not available

TPA logs call as rejected


Test Case


OS1

Call to Phone 8028S that is Out of Service

Test on ALE 80x8 phone disconnected from system. Test Case defined above Expected result defined above

OXE send SIP 480 Temporarily not available to Mobicall.

9.1.11 Conference call with alarm server and DTMF over RTP


This test will show that alarm server can connect multiple phones into a conference on its own. The resources for calling or be called and for connecting all users are into the Alarm server.


Test Case


CO1

Alarm server call multiple correspondant to make conferencing

8262 DECT generate an Emergency alarm red button toward alarm server.

Then Alarm server calls programmed users that can be directly connected to conference or have to press key DTMF to be connected.

.Uses of DTMF digits for conference password . Alarm server called users that enter password 123 then get connected to conference.

CO2

Alarm server maintain the conference

Release one Phone

Check conference is maintained



9.1.12 SIP call with Special Characters in CLI


To check the SIP call behavior with special characters in the message. Test Case:

Phone is in idle mode.

To send a call, generate a test call from the TPA with text in CLI containing special accented characters.

During test, we sent “&#$£µàéèêçüöäß” as display message.

Check the displayed information on terminal.

Expected result:

The characters are displayed as they were configured in the alarm server.

the following behavior should the same depending on the target phone state.

Warning: The OXE country code is FR and this has been noticed that special characters from German are well displayed if country code is DE.


Test Case Id


CL1

Call to IPTouch 8068 (Digital NOE Extension)

Alarm server sends Alarm toward the terminal.

Check display of terminal.

Characters are well displayed on phone.

CL2

Call to MIPT 8128 (WLAN Extension)



CL3

Call to Dect 8242



CL4

Call to Dect 8242





9.2 Alarming with 8242 DECT and 8262 DECT using Enterprise mode

The Office message mode is 17 digits long. Here is the description of the message format. 8242 DECT & 8262 Handset 26 digits numbering with the following fields:

Each digit has a value from zero to nine. Unused fields (reserved) should be set to zero. The following paragraph will detail each field coding The following tests verify that the Alarm server receives and decodes well those messages. The information that you’ll see in the test cases like “code…” stands for digits 13 to digit 17 of message sent by DECT handsets to Alarm Server.

9.2.1 Test cases linked to “Live signal” on DECT 8262 and 8242 DECT


Live signal is executed if the appropriate function has been activated in the MMI configuration and the handset is in idle state. Alarm server 1 prefix is 85 Live signal is sent after 60s to first server then after 60 to second server.


Test Case Id


LIV1

Live Signal on DECT 8242

- Put the live delay value at 60 sec. - Check that two prefixes are defined (the messages are sent alternately to the first and second alternative with the defined delay between the messages). - 8242 is in idle mode

LIV2

Live Signal on DECT 8262

- Put the live delay value at 60 sec. - Check that two prefixes are defined (the messages are sent alternately to the first and second alternative with the defined delay between the messages).



Test Case Id


- 8262DECT is in idle mode

9.2.2 Test cases linked to “Status message” on 8242 DECT


The status call is aimed to provide information about the handset when the function is active. The functions are activated in the MMI configuration menu. This feture also work with alternate server 2.


Test Case Id


1

Status message on DECT8242 in charger

Step 1: - Initiate the Status function in the MMI configuration menu - A status call is made when the handset is in the charger. - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Possible state values: 1, 3, 5, 7, 9 - Check that the notification server receives and decodes the message.

030940

2

Status message on DECT8242 Out of charger

Step 1: - Initiate the Status function in the MMI configuration menu - A status call is made when the handset is out of the charger - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Possible state values: 0, 2, 4, 6, 8 - Check that the notification server receives and decodes the message.

020940

3

Status message on DECT8242 switched off

Step 1: Handset is out of charger - Initiate the Status function in the MMI configuration menu - Switch off the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Possible state value: 8 - Check that the notification server receives and decodes the message Step 2: Handset is in charger - Initiate the Status function in the MMI configuration menu - Switch off the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of

080940



Test Case Id


20 bytes when sent to the OXO). Possible state value: 9 - Check that the notification server receives and decodes the message.

4

Status message on DECT8242 switched on

Step 1: Handset is out of charger - Initiate the Status function in the MMI configuration Menu. - Switch on the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). - Check that the notification server receives and decodes the message Step 2: Handset is in charger - Initiate the Status function in the MMI configuration menu - Switch on the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). - Check that the notification server receives and decodes the message

020940

9.2.3 Test cases linked to “Status message” on DECT 8262


The status call is aimed to provide information about the handset when the function is active. The functions are activated in the MMI configuration menu.


Test Case Id


1.

Status message on DECT 8262 In charger

Step 1: - Initiate the Status function in the MMI configuration menu - A status call is made when the handset is in the charger. - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Call type 4. Possible state values: 1, 3, 5, 7, 9 - Check that the notification server receives and decodes the message.

2.

Status message on DECT 8262 Out of charger

Step 1: - Initiate the Status function in the MMI configuration menu - A status call is made when the handset is out of the charger - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Call type 4. Possible state values: 0, 2, 4, 6, 8



Test Case Id


- Check that the notification server receives and decodes the message.

3.

Status message on DECT 8262 switched off

Step 1: Handset is out of charger - Initiate the Status function in the MMI configuration menu - Switch off the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Call type 4. Possible state value: 8 - Check that the notification server receives and decodes the message Step 2: Handset is in charger - Initiate the Status function in the MMI configuration menu - Switch off the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Possible state value: 9 - Check that the notification server receives and decodes the message.

4.

Status message on DECT 8262 switched on

Step 1: Handset is out of charger - Initiate the Status function in the MMI configuration menu - Switch on the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). Call type 4. - Check that the notification server receives and decodes the message Step 2: Handset is in charger - Initiate the Status function in the MMI configuration menu - Switch on the handset - Check the status in the message to the PBX (Message length of 30 bytes when sent to the OXE and of 20 bytes when sent to the OXO). - Check that the notification server receives and decodes the message.



9.2.4 Test cases linked to “Key events” on 8242 and 8262


Key events are used to signal the notification sever of the progress of tasks that are reported.

For example: in a hotel to confirm that a room has been cleaned.

The call type must be 2 (Key Event call). The key pressed:

8242 DECT: 8262DECT:

Key 0: 0 Key 0: 0

Key 1: 1 Key 1: 1

Key 2: 2 Key 2: 2

Key 3: 3 Key 3: 3

Key 4: 4 Key 4: 4

Key 5: 5 Key 5: 5

Key 6: 6 Key 6: 6

Key 7: 7 Key 7: 7

Key 8: 8 Key 8: 8

Key 9: 9 Key 9: 9


Test Case Id


KEY1

Key events on 8242 DECT in Idle state:

Initiate the Event function in the MMI configuration menu.

8242 DECT is in idle mode

Make a long press of one of the keys from 0 to 9 to trigger the function.

Check that a call is performed, is blinking.

Check that the notification server receives and decodes the message correctly.

OKBut: Issue with Key 0 , Mobicall sent 502-Bad gateway. Ok with other keys.

KEY2

Key events on DECT 8262 in Idle state:


DECT 8262 is in idle mode


Check that a call is performed, display shows the dialing mode.

Check that the notification server receives and decodes the message correctly

OKBut: Issue with Key 0 , Mobicall sent 502-Bad gateway. Ok with other keys.



9.2.5 Test cases linked to “Notification” on 8242 DECT


The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage.

This handset performs Notification call with a dedicated “Alarm Key” (Red button).

The “OK” key is not used as the “Key Events” are not validated in the alarm settings.


Test Case Id


NOT1

Notification on 8242 DECT in Idle state

Activate the Notify function in the MMI configuration menu

Define the first and second access prefix in the Alarm configuration.

HS is in idle mode.

To send a notification call make a long press on "OK" key (then next try with Side key!):

Check that the notification server responds in a proper way to the handset. By sending the display message: ID… followed by “F ~xxxx” to the handset (The handset does not display F~ but only xxx).

There should be no more call to second server.

Check that the notification server decodes well the message.

The 200-OK contain: To: “F~MobiAck” P-Asserted Identity: “F~MobiAck” <sip:[email protected];user=phone>

NOT2

Notification on 8242 DECT in communication state



HS is engaged into a communication.





Existing call is disconnected

NOT3

Notification on 8242 DECT in dialling state



HS is dialing a number.


Check that the notification server responds in a proper way to the handset. By sending



Test Case Id


the display message: ID… followed by “F ~xxxx” to the handset (The handset does not display F~ but only xxx).



NOT4

Notification on 8242 DECT in configuration state



HS is in configuration menu.







9.2.6 Test cases linked to “Notification” on DECT 8262 with "Panic Red button"





Configure the easy acknowledge to get display of Alarm Ack on screen.


Test Case Id


PA1

Notification on DECT 8262 in Idle state



HS is in idle mode





PA2

Notification on DECT 8262 in Communication state








Existing call is disconnected

PA3

Notification on DECT 8262 in dialling state




To send a notification call make a long press on "OK" key (then next try with Side key!)

Current call is released.

Check that the notification server responds in a proper way to the handset. By sending the display message: ID… followed by “F



Test Case Id


~xxxx” to the handset (The handset does not display F~ but only xxx).



PA4

Notification on DECT 8262 in configuration state








Note:

On DECT 8262 with latest firmware, a timer of 10 seconds has been introduced between the time we press the red button and the time alarm is really send to the server.

9.2.7 Test cases linked to "Man Down" or "Lost of verticality" on DECT 8262


The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call with a loss of verticality (Man Down) according DECT 8262 MMI configuration and timers.


Test Case Id


MD1

ManDown on DECT 8262 while in Idle state

Configure "Man Down" function via MMI to 60° degree.

Check that the Lock/Unlock is inactive.

HS is in idle mode.

Move the handset to horizontal position.

Alarm is activated after “pre-alarm” timer.

Check that the notification server responds in a proper way to the handset. By sending the display message: ID… followed by “F ~xxx” to the handset (The handset does not display F~ but only xxx).


Handset rings with pre-alarm signal then trigger the alarm call.



Test Case Id


Handset rings and need to acknowledge the alarm.

While acknowledged, check that message is sent to server.

MD3

ManDown on DECT 8262 while in dialling state



HS is dialing a phone number.







After inter-digit timer, handset trigger alarm.

Exceptions: Man Down and no movement should be inactive when the handset is charging in or out of charger (USB cord charger for example), or when user is browsing in Handset screens (not in idle state) or when the user is engaged in a call.

9.2.8 Test cases linked to "No Movement" on DECT 8262



This handset performs Notification call with a "No Movement detection". The function and a timer is programmable in the set DECT 8262; when no movement has been detected, the rings with specific rings (timer set to 10 seconds), then alarm is send to the server.


Test Case Id


NM1

No Movement on DECT 8262 in Idle state

Configure "No Movement" function via MMI.


HS is in idle state.

Do not move the handset for a time.







Test Case Id



NM3

No Movement on DECT 8262 in dialling state










Exceptions: Man Down and no movement should be inactive when the handset is charging in or out of charger (UBS cord charger for example), or when user is browsing in Handset screens (not in idle state) or when the user is engaged in a call.

9.2.9 Test cases linked to "SHOCKS" detected on DECT 8262



This handset performs Notification call when shocks are detected on handset. Generate a Shock then wait 5 seconds without movement, then the alarm is sent.

The Detection sensitivity can be set to Maximum, Medium or Minimum. With Maximum to detect softer shock and Minimum to detect strong shock.


Test Case Id


SH1

SHOCK on DECT 8262 in Idle state

Configure "Shock" function via MMI.



Let the HS fall on table.







Test Case Id



SH2

SHOCK on DECT 8262 in communication state



HS is engaged into a conversation.



Current conversation is hanged-up.





Existing call is disconnected and alarm is triggered,

SH3

SHOCK on DECT 8262 in dialling state










Set exit from dialing and generate alarm.

SH4

SHOCK on DECT 8262 in configuration_state



HS is into the configuration menu...









9.2.10 Test cases linked to "Pull cord" detected on DECT 8262



This handset performs Notification call when cord connected to the handset is removed by pulling.

The application triggers an alarm and send to the server.


Test Case Id


PC1

Pull Cord on DECT 8262 in Idle state

Configure "Pull cord" function via MMI.



Pull the cord attached to the handset.






After cord has been pull then Pre alarm signal (you can put back cord to stop) or alarm sent to server.

PC2

Pull Cord on DECT 8262 in communication state




Pull cord attached to the handset.







Existing call is disconnected and alarm is triggered,

PC3

Pull Cord on DECT 8262 in dialling state


Check that the Lock/Unlock is inactive





Check that the notification server decodes



Test Case Id


well the message.



PC4

Pull Cord on DECT 8262 in configuration_state


Check that the Lock/Unlock is inactive

HS is into the configuration menu.







9.2.11 Test cases linked to base station location using RPN


In the message send to the Alarm server, the id of DECT base station is send in order to localize the alarm sender, this id is called RPN for Radio Part Number. Test will be performed with 8242 DECT and DECT 8262 generating alarm with “Notification” key (Side button! for 8242 and Red button for 8262).

IBS-DECT PARI value into alarming message is “13600”.

The Radio Part Numbers (RPN) are 001, 002 for central area and number 100 for remote area.


Test Case Id


RP1

Location of the 8242 DECT in central area of IBS-DECT:

Generate an alarm

Check that the alarm server decodes well the message with the RPN values and levels.

Move the handset and check that values changes.

RP2

Location of the DECT 8242 in remote area of IBS-DECT:

Generate an alarm





Test Case Id


RP3

Location of the 8242 DECT in IP XBS areas:

Generate an alarm



IP xBS not tested.

RP4

Location of the DECT 8262 in IP XBS areas:

Generate an alarm





9.3 Incoming alarm from SIP Alarm server to handsets Alarm could be send manually or could be programmed according to an event from other 8242 DECT/8262.

9.3.1 Incoming Alarms on DECT 8262 and 8242 DECT


Warning: the 8262 and 8242 DECT settings should have “forced ringing” enabled in order to get different ringing melodies according to alarms. There are four types of Incoming Alarms on DECT 8262 and 8242 DECT Handsets:

Normal Alarm: CNI1 identifier (B~)

Urgent Alarm: CNI2 identifiers (C~)

Very Urgent Alarm: CNI3 identifier (D~)

Hands-free mode Alarm (Loudspeaker & Microphone active): CNI4 identifier (E~) TPA stands for Third Party Application. HS stands for Hand-Set.


Test Case Id


AL1

Manual Incoming alarm Normal on DECT 8262 in normal mode

- Set the handset in silent mode. - Send a CNI signal having a format of “B~xxx” with the CS (Alarm server)

- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings menu.

AL2

Manual Incoming alarm Normal on 8242 DECT in normal mode



It works with current “ring pattern” do not add B~ in From or message display into Mobicall settings.

AL3

Manual Incoming alarm Urgent on DECT 8262 in normal mode

- Set the handset in normal mode. - Send a CNI signal having a format of “C~xxx” with the CS (Alarm server) - Check that the handset will ring at maximum level with melody 5

AL4

Manual Incoming alarm Urgent on DECT 8262 in vibrator mode

- Set the handset in vibrator mode. Send a CNI signal having a format of “C~xxx” with the CS (Alarm server) - Check that the handset will ring at maximum level with melody 5

Working with Urgent alarm set in mobicall.



Test Case Id


AL5


- Set the handset in normal mode. - Send a CNI signal having a format of “C~xxx” with the CS (Alarm server) - Check that the handset will ring at maximum level with Alarm 2

AL6

Manual Incoming alarm Very Urgent on DECT 8262 in silent mode

- Set the handset in silent mode. Send a CNI signal having a format of “D~xxx” with the CS (Alarm server)

- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings

AL7

Manual Incoming alarm Very Urgent on DECT 8262 in normal mode

- Set the handset in normal mode. Send a CNI signal having a format of “D~xxx” with the CS (Alarm server)


AL8

Manual Incoming alarm Very Urgent on 8242 DECT in silent mode



AL8

Manual Incoming alarm Very Urgent on 8242 DECT in normal mode



AL9

Manual Incoming alarm Loudspeaker on DECT 8262 in normal mode

- Set the handset in normal mode. Send a CNI signal having a format of “E~xxx” with the CS (Alarm server)


AL10

Manual Incoming alarm Loudspeaker on DECT 8262 in vibrator mode

- Set the handset in vibrator mode. Send a CNI signal having a format of “E~xxx” with the CS (Alarm server)


AL11

Manual Incoming alarm Loudspeaker on 8242 DECT in normal mode



AL12

Manual Incoming alarm Loudspeaker on 8242 DECT in vibrator mode




Test Case Id



AL13

Manual Incoming Normal alarm on DECT 8262 with accented characters

Send a CNI signal having a format of

“B~&#$£µàéèêçüöäß” to

the Handset.

Check that the handset will ring with alarm ring and volume as programmed in the Alarm settings.

Check display of accented characters.

AL14

Manual Incoming Hands-free alarm on DECT 8262 with accented characters


“E~&#$£µàéèêçüöäß” to

the Handset.

Check that the handset will be in communication with Microphone not muted.


AL15

Manual Incoming Normal alarm on 8242 DECT with accented characters



the Handset.



AL16

Manual Incoming Hands-free alarm on 8242 DECT with accented characters



the Handset.





10 Test Results using the T2 ISDN trunk interface

A T2 ISPN trunk is established between the OmniPCXEnterprise and Alarm Server Application (alarm server). Alarm Server is equipped with Dialogic Diva T2 board. Nota: TPA stands for Third party Application

10.1 Generic test calls over ISDN T2

10.2 ISDN Link connection PRA-T2 Board into Media-Gateway 4. There are 2 trunk groups 27 (20 channels) for normal calls and 28 (10 channels) for Urgent calls (to Release busy called party in case of emergency).

Test Case

Id Test Case N/A OK NOK Comment

1

Connect the OXE PRA Board with Alarm Server TDM board:

Check that no alarms (Layer 1 Physical and Layer 2 Data Link) are presents on the PRA Board.

Check that the Link is active in Alarm Server using NVT Monitor.

2

Check status of trunk groups in OXE and Alarm Server

Trkstat 27 and 28, all channels are free.

NV Tool monitor in Alarm Server.

3

Disconnect the cable between PRA board and Alarm Server server.

Trunks are set to “HS” Out of service into OXE.

Channels become Red in Monitor tool.

Led NOS (No Signal) is on red on PRA board. Incidents 2101 – Access still in state of alarm coming on console. Trkstat shows trunks HS (Out of Service). Alarm also on Mobicall.



10.2.1 ISDN call set-up and call release

Test Case


1

ISDN call to phone and release from PBX

Generate a call from TPA to phone

Answer the call

Release the call after a few seconds from the phone

Check that call is correctly released on both ends.

2

ISDN call to phone and release from TPA

Generate a call from TPA to a phone

Answer the call

Wait until call is released by TPA

Check that call is correctly released on both ends.

3

ISDN call to phone that does no answer

Generate a call from TPA to a phone

Do not answer the call

Wait until call is released by TPA,

Check that call is correctly released in TPA.

10.2.2 ISDN calls to various idle phones

Test Case:

Hand set is in idle mode


Accept the call Expected result:

call is accepted by PBX phone,

The text message of the Alarm Server application is used as caller identifier and displayed (16 characters),

On answer a voice message is played by TPA then release of the call.

Test Case Id

Test Case N/A OK NOK Comment

1

Call to 8128 MIPT in Idle state

Test on ALE 8128 Wifi Handset Test Case defined above Expected result defined above

Hanset 8128 Wifi Number 12410

2


Test on ALE 8242 DECT Test Case defined above Expected result defined above

Handset 8242 DECT Number 12192

3




4


Test on ALE Mobile 8232 DECT Test Case defined above Expected result defined above


5

Call to IPTouch serie 8 in idle state

Test on ALE IP Touch 4038 Test Case defined above Expected result defined above

Premium DeskPhone 8028S Number 12006



Test Case Id

Test Case N/A OK NOK Comment

6

Call to Analog Phone in idle state

Test on ALE Analog phone Test Case defined above Expected result defined above

Analog Phone number 12401

7

Call to Generic SIP Phone

Test on Generic SIP phone Test Case defined above Expected result defined above

SIP Phone Advantec Number 12411

10.2.3 ISDN call to various busy phones

Test Case:

Phone is in communication.

To send a call, generate a test call “alarm” from the TPA Expected result:

According to the phone configuration in Oxe, behaviors are different:

call is rejected if the phone is busy: the phone is set with "Camp On" protected in "Features" options

TPA logs call is rejected. If Normal call from Mobicall to Multiline set then call is waiting on called party.If phoneset is Not Multiline then Call is rejected (user busy) or diverted (case with 12411 SIP Phone and 12410 8128 Phone).

Test Case


1

Call to busy 8128 Mobile IPTouch

Test on ALE Wifi mobile 8128



Call sent by Mobicall on Urgent Broadcast Trunk Group 28. Call released on Phone then ringing call from Mobicall.

2

Call to busy 8242 IBS

Test on Alcatel-Lucent 8242 DECT



Diversion to Voice mail, see 10.2.6.

4

Call to busy 8232 IBS-DECT




Call waiting on Multiline set.

4

Call to busy Premium Deskphone 8028S

Test on ALE 8028S



5

Call to busy 8262 IBS-DECT

Test on ALE 8262 DECT



Diversion to Entity Overflow number 12001. Display of “Night Forwarding”

8

Call to busy Analog Phone

Test on ALE Analog phone



10

Call to busy SIP Phone

Test on Generic SIP phone



Nota: To test this change the Public Access class of service (Default class 2) “Incoming DDI hold on Busy Set” set to 0 for day/night/Mode1/Mode2.



10.2.4 ISDN calls to DECT sets out of radio range

Test Case:

Hand Set is in idle mode, out of range


call is rejected

TPA logs the call rejection reason

Test was done by powering-off the Dect handsets.

Test Case


1

Call to 8262 IBS-DECT out of radio range




Tested by powering-off the handset.

2

Call to 8242 IP-DECT out of radio range




10.2.5 ISDN calls to forwarded phone or DECT handset Test Case :

Phone is in idle state, call forwarding is configured (Dial 51xxxxx with xxxxx corresponding to forwarding destination number),

To send a call, generate a test call from the TPA,

Accept the call on the forwarding destination Expected result:

call is forwarded to the target phone

the following behavior should be the same depending on the target phone state

Destination phones are ringing and if answer got voice message.

Test Case


1

Call to Premium Deskphone

Test on ALE 8028S Test Case defined above Expected result defined above

2

Call to 8242 DECT


Prefixes are: 51 for immediate forward to destination / 41 for forward cancellation or uses the dedicated screen key on Digital ALE phones.



10.2.6 ISDN calls to phone that is forwarded or Diverted to voice mail

Test Case:

Phone is in idle mode, immediat call forwarding to voice mail is configured: Dial 51 and 12999 (with 51 prefix to immediate forward and 12999 is Number of 4645 Voice Mail).


accept the call on the forwarding destination; which is another terminal Expected result:



Test Case


1

Call to 8242 DECT forwarded to Voice Mail

Test on 8242 DECT Test Case defined above Expected result defined above

8242 DECT has voice mail if busy then call diverted to VM. ISDN messages indicates that call goes to 12999 (Voice Mail).Alarm message is transmitted to Voice Mail during announcement.

10.2.7 ISDN call to phone in immediate call forwarding to external destination

Test Case:

Phone is in idle mode, call forwarding is configured


accept the call on the forwarding destination; which is an external destination Expected result:



Test Case


1

Call to Premium Deskphone forwarded to public external correspondant

Test on ALE 8028S forwarded to external number. Test Case defined above Expected result defined above

Alarm call follow the forwarding and wait answer of called party to play the alarm voice guide.



10.2.8 ISDN call to Out of Service phone Test Case:

Phone is out of service


call is rejected

TPA logs call as rejected

Test Case


1

Call to Premium Deskphone 8028S Out of Service

Test on ALE 8028S disconnected from system. Test Case defined above Expected result defined above

Nota: OXE sends a “Disconnect” with cause “out of order”.

10.2.9 ISDN call with Special characters in CLI Test Case:

Phone is in idle mode.

To send a call, generate a test call from the TPA with text in CLI containing special accented characters.

During test we sent “&#$£µàéèêçüöäß” as first display message then “àéèêçüöäß~&#$£µ” while call is answered.

Check the displayed information on terminal. Expected result:

The characters are displayed as they were configured in the alarm server.

the following behavior should the same depending on the target phone state. Warning: The OXE country code is FR and this has been noticed that special characters from German are well displayed if country code is DE.

Test Case


1

Call to Premium Deskphone 8028S



2

Call to MIPT 8128 (WLAN Extension)



3

Call to 8242DECT





10.2.10 Conference call with alarm server over T2 ISDN This test will show that alarm server can connect multiple phones into a conference on its own. The resources for calling or be called and for connecting all users are into the Alarm server.

Test Case


1

8262 DECT alarm followed by conference between alarm set and notified set.

Test Case :

8262DECT phone is in idle mode

Generate a manual alarm on 8262DECT

Alarm Server manages the alarm and generates an alarm to a destination

One of the destination accepts the call and dials a DTMF digit (example 8242 DECT)

Alarm Server then call the 500DECT

The Expected result:

Alarm is accepted by Alarm Server

Call is generated to alarm phone destination

After the confirmation prompt, the message can be confirmed through DTMF

Once confirmed, a voice message confirms the conference setup (if accepted)

TPA calls the second phone

On answer of the second phone, both are set in conference.

Test was done with configuration of Alarm conference that move all called parties directly into the conference and no need to accept call with DTMF.



10.3 ISDN Alarming with 8242DECT and 8262DECT

10.3.1 Test cases linked to “Live signal” on 8242DECT and 8262DECT

Live signal is executed if the appropriate function has been activated in the MMI configuration and the handset is in idle state.

Alarm server 1 prefix is 87 / Live signal “Live delay” is set to 90sec.

If a server 2 is configured the live signal will work alternatively with server 1 and then server2. This alternate mode was designed in the initial specifications.

Test Case


1

Live Signal on 8242DECT

Put the live delay value at 90 sec.

Check that two prefixes are defined (the messages

are sent alternately to the first and second alternative with the defined delay between the messages).

8242 is in idle mode

The ! icon will blink each time an

alarm is sent.

2

Live Signal on 8262DECT

Put the live delay value at 90 sec.

Check that two prefixes are defined (the messages

are sent alternately to the first and second alternative with the defined delay between the messages).

8262 is in idle mode

The ! icon will blink each time an

alarm is sent.

Live signal sent every 60 seconds.

10.3.2 Test cases linked to “Status message” on 8242 DECT The status call is aimed to provide information about the handset when the function is active. The functions are activated in the MMI configuration menu.

Test Case


1

Status message on 8242 DECT In charger

Initiate the Status function in the MMI configuration menu.

A status call is made when the handset is in the charger.

Check the status in the message sent by PBX


2 Status message on 8242 DECT Out of charger

Initiate the Status function in the MMI



Test Case


configuration menu.

A status call is made when the handset is out of charger.



3

Status message on 8242 DECT switched off

Step 1: Handset is out of charger


A status call is made when the handset is out of charger and switched-off.

Check the status in the message sent by PBX Check that the notification server receives and decodes the message correctly. Step 2: Handset is in charger


A status call is made when the handset is in the charger and switched-off.



….. 80940

4

Status message on 8242 DECT switched on



A status call is made when the handset is out of charger and switched.



Step 2: Handset is in charger





…..40940

10.3.3 Test cases linked to “Status message” on 8262DECT The status call is aimed to provide information about the handset when the function is active. The functions are activated in the MMI configuration menu.

Test Case


1

Status message on 8262 DECT In charger




Check that the notification server receives and

…. 50940



Test Case


decodes the message correctly.

2

Status message on 8262DECT Out of charger


A status call is made when the handset is out of charger.



…… 40940

3

Status message on 8262DECT switched off



A status call is made when the handset is out of charger and switched-off.

Check the status in the message sent by PBX Check that the notification server receives and decodes the message correctly. Step 2: Handset is in charger


A status call is made when the handset is in the charger and switched-off.



4

Status message on 8262 DECT switched on



A status call is made when the handset is out of charger and switched.



Step 2: Handset is in charger





10.3.4 Test cases linked to “Key events” 8242DECT and 8262DECT

The Key Events is used to signal to the notification server of the progress of some tasks that are reported. These alarms are sent only when in idle state. (For example: in an hotel to confirm that a room has been cleaned.) The call type must be 2 (Key Event call). The key pressed are:



8242DECT & 8262DECT:

Key 0: 0

Key 1: 1

Key 2: 2

Key 3: 3

Key 4: 4

Key 5: 5

Key 6: 6

Key 7: 7

Key 8: 8

Key 9: 9

Test Case


1



8242 DECT is in idle mode


Check that a call is performed, ! is blinking.


Key 0: …..40920 Key 1: …..41920 Key 5: …..45920

2



8262DECT is in idle mode


Check that a call is performed, display shows the dialing mode.

Check that the notification server receives and decodes the message correctly

Key 0: ….40920 Key 2: …..42920 Key 9: …..49920



10.3.5 Test cases linked to “Notification” on 8242DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage.



Test Case


1

Notification on 8242 DECT in Idle state



HS is in idle mode.

To send a notification call make a long press on "OK" key (then next try with Side key !):




DECT send Notification …. 44910 then stay in conversation. Then Ack is send ….45901

2

Notification on 8242 DECT in communication state








3

Notification on 8242 DECT in dialling state



HS is dialling a number.







Test Case


4

Notification on 8242 DECT in configuration state








10.3.6 Test cases linked to “Notification” on 8262DECT Use of Red Button on top of the handset. The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage.



Test Case


1

Notification on 8262DECT in Idle state



HS is in idle mode.





Notification: …..44910 Ack: …..45901

2

Notification on 8262DECT in communication state





Check that the notification server responds in a proper way to the handset. By sending the



Test Case


display message: ID… followed by “F ~xxxx” to the handset (The handset does not display F~ but only xxx).



3

Notification on 8262DECT in dialling state








4

Notification on 8262DECT in configuration state










10.4 Handset embedded alarms from 8262DECT over ISDN

10.4.1 Test cases linked to "Man Down" or "Lost of verticality" on 8262DECT

The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset 8262 performs Notification call with a lost of verticality (Man Down) according to configuration into the handset menu.

Test Case


1

ManDown on 8262DECT while in Idle state



HS is in idle mode.







….. 41901

2

ManDown on 8262DECT while in Communication state



HS is in a communication with other correspondant.







See Exceptions.

3

ManDown on 8262DECT while in dialling state



HS is dialling a phone number.



At end of timer



Test Case






4

ManDown on 8262DECT while in configuration state



HS is in configuration mode.







At end of timer

Exceptions: Man Down and no movement should be inactive when the handset is charging in or out of charger (UBS cord charger for example), or when user is browsing in Handset screens (not in idle state) or when the user is engaged in a call.

10.4.2 Test cases linked to "No Movement" on 8262DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call with a "No Movement detection". The function and a timer is programmable in the 8262DECT; when no movement has been detected, the rings with specific rings (timer set to 10 seconds), then alarm is send to the server.

Test Case


1

No Movement on 8262DECT in Idle state







Check that the notification server decodes well

….43801 then Ack ….45801



Test Case


the message.



2

No Movement on 8262DECT in communication state










See Exceptions.

3

No Movement on 8262DECT in dialling state










At end of timer

4

No Movement on 8262DECT in configuration state










At end of timer

Exceptions: Man Down and no movement should be inactive when the handset is charging in or out of charger (UBS cord charger for example), or when user is browsing in



Handset screens (not in idle state) or when the user is engaged in a call.

10.4.3 Test cases linked to "SHOCKS" detected on 8262DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call when shocks are detected on handset. Generate a Shock then wait 5 seconds without movement, then the alarm is send

Test Case


1

SHOCK on 8262DECT in Idle state










….44901 Then Ack ….45901

2

SHOCK on 8262DECT in communication state











3

SHOCK on 8262DECT in dialling state







Check that the notification server decodes well



Test Case


the message.



4

SHOCK on 8262DECT in configuration_state



HS is into the configuration menu..







10.4.4 Test cases linked to "Pull Cord” on 8262DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call when the cord is pulled-out for instance in case of attack by a violent person.

Test Case


1

Pull cord on 8262DECT in Idle state

Configure "Pull Cord" function via MMI.



Pull-out the cord






Alarm ….42801

2

Pull cord on 8262DECT in communication state




Pull-out the cord





Test Case






3

Pull cord on 8262DECT in dialling state




Pull-out the cord






4

Pull cord on 8262DECT in configuration menu




Pull-out the cord








10.4.5 Test cases linked to DECT base stations Location In the message send to the Alarm server, the id of DECT base station is send in order to localize the alarm sender, this id is called RPN for Radio Part Number. Test will be performed with 8242 DECT and 500 DECT generating alarm with “Notification” key (Side button ! for 8242 and Red button for 500).

IBS-DECT PARI value into alarming message is “13600”.

The Radio Part Numbers (RPN) are 001, 002 for central area and number 100 for remote area.

Test Case


1

Location of the 8242DECT in central area of IBS-DECT:

Generate an alarm



2

Location of the 8262DECT in central area of IBS-DECT:

Generate an alarm



Tested by disconnection of IBS to get the desired one active.

4

Location of the 8242DECT in remote of IBS-DECT areas:

Generate an alarm



5

Location of the 8262DECT in remote of IBS-DECT areas:

Generate an alarm





10.5 Incoming alarm from T0/T2 ISDN Alarm server to handsets

Warning: the 500DECT, the 8242 DECT and the 8262DECT settings should have “forced ringing” enabled in order to get different ringing melodies according to alarms. There are four types of Incoming Alarms on 500DECT , 8242DECT and 8262DECT Handsets:

Normal Alarm: CNI1 identifier (B~)

Urgent Alarm: CNI2 identifiers (C~)

Very Urgent Alarm: CNI3 identifier (D~)

Hands-free mode Alarm (Loudspeaker & Microphone active): CNI4 identifier (E~) TPA stands for Third Party Application. HS stands for Hand-Set.

10.5.1 Incoming Alarms on 8242DECT and 8262DECT

Test Case Id


AL1

Manual Incoming alarm Normal on DECT 8262 in normal mode



AL2

Manual Incoming alarm Normal on 8242 DECT in normal mode



It works with current “ring pattern” do not add B~ in From or message display into Mobicall settings.

AL3


- Set the handset in normal mode. - Send a CNI signal having a format of “C~xxx” with the CS (Alarm server) - Check that the handset will ring at maximum level with melody 5

AL4

Manual Incoming alarm Urgent on DECT 8262 in vibrator mode

- Set the handset in vibrator mode. Send a CNI signal having a format of “C~xxx” with the CS (Alarm server) - Check that the handset will ring at maximum level with melody 5

AL5


- Set the handset in normal mode. - Send a CNI signal having a format of “C~xxx” with the CS (Alarm server) - Check that the handset will ring at maximum level with Alarm 2

The called party should be set ax DC! Instead of DCT ti use the correct calling scheme with B~.



Test Case Id


AL6

Manual Incoming alarm Very Urgent on DECT 8262 in silent mode



AL7

Manual Incoming alarm Very Urgent on DECT 8262 in normal mode



AL8

Manual Incoming alarm Very Urgent on 8242 DECT in silent mode



AL8

Manual Incoming alarm Very Urgent on 8242 DECT in normal mode



AL9

Manual Incoming alarm Loudspeaker on DECT 8262 in normal mode



AL10

Manual Incoming alarm Loudspeaker on DECT 8262 in vibrator mode



AL11

Manual Incoming alarm Loudspeaker on 8242 DECT in normal mode



AL12

Manual Incoming alarm Loudspeaker on 8242 DECT in vibrator mode



AL13

Manual Incoming Normal alarm on DECT 8262 with accented characters



the Handset.

Special characters are not supported by the application



Test Case Id




AL14

Manual Incoming Hands-free alarm on DECT 8262 with accented characters



the Handset.


Check display of accented characters while ringing.

Characters sent after Answer are almost same plus ~

The ß is changed to Y while ringing (normal as country code for OXE is FR). The display after answer is incoherent with these special characters.

AL15

Manual Incoming Normal alarm on 8242 DECT with accented characters



the Handset.




AL16

Manual Incoming Hands-free alarm on 8242 DECT with accented characters



the Handset.






11 Use of Bluetooth Beacons

11.1 Test cases linked to Bluetooth beacons’ location in case of Smart beacon


The handset must be configured with Smart Beacon mode and Bluetooth will be activated (Blue led blinking). The test is done with Handset configuration set to “DECT” in Location setting (Alarms are still sent with RPN DECT information).


Test Case Id


SB1

Location of the 8262 DECT entering in an area

Configure the handset to work with entering mode only in detection mode.

Check that the live signal is sent to alarm server

XX:XX:84:2A:A0:E1

SB2

Location of the 8262 DECT leaving an area

Configure the handset to work with leaving mode only.

Check that the live signals is sent to alarm server

XX:XX:84:2A:A0:E1 Phone = 4019 BDADDR = XX:XX:84:2A:A0:E1 State = 4 Key = 0 Batt = 4 CallType = 3 CallType2 = 5 TextStatus = Not charging, Ringing off, Vibrator on - Battery: 46-56 % CallType = Leaving BT area

SB3

Location of the 8262 DECT while entering in multiple areas

Configure the handset to work with entering mode only.

Check that the live signals is sent to alarm server according to areas where you moved.

.

XX:XX:84:34:26:4E Phone = 4019 BDADDR = XX:XX:84:34:26:4E State = 4 Key = 0 Batt = 4 CallType = 3 CallType2 = 3 TextStatus = Not charging, Ringing off, Vibrator on - Battery: 46-56 % CallType = Entering BT area

SB4

Location of the 8262 DECT while leaving in multiple areas

Configure the handset to work with leaving mode only.


XX:XX:84:34:26:4E XX:XX:84:2A:A0:E1



Test Case Id


.

SB5

Location of the 8262 DECT while entering and leaving in multiple areas

Configure the handset to work with entering/leaving mode.


.

SB6

Location of the 8262 DECT in conversation while entering and leaving in multiple areas

Configure the handset to work with entering/leaving mode.

Check that the live signals is sent to alarm server according to areas where you moved when you hang up the call.

.

11.2 Test cases linked to Bluetooth beacons’ location in case of Alarming


The test is done with Handset configuration set to “Bluetooth” in Location setting. (Alarms are sent with BT address information)


Test Case Id


BL1

Location of the 8262 DECT incase of Emergency Alarm

Generate an alarm

Check that the alarm server decodes well the message with the BT address.


17 digits for Beacon Id and 8 digits for alarm info: 00004713 Emergency 00005703 Ack

BL2

Location of the 8262 DECT in case of Pull Cord alarm

Generate an alarm

Check that the alarm server decodes well the message with the BT address.


00002703 Pull Cord 00005703 Ack



12 High availability configurations

12.1 Spatial Redundancy Com Server – Single Mobicall (SIP Trunking)

Initial state is Com Server 1 is active and seen as Main and Com Server 2 is In stand-by. Alarm server Mobicall has IP address 10.1.2.55 Com Server 1 is CPU-A has IP adress 10.1.6.2 and his Main IP address is 10.1.6.1 Com Server 2 is CPU-B has IP adress 10.10.10.12 and his Main IP address is 10.10.10.11 The OXE is addressed with FQDN etesting2.etesting.lab configured in DNS External server with DNS Delegation (etesting2.etesting.lab 10.1.6.1 or 10.10.10.11) Mobicall server has the configuration of its “Trunk SIP avec Authentification” with “Adresse IP PABX : “etesting2.etesting.lab”. The DNS switch-over mechanism of Mobicall was based of type SRV and has been modified in order to use the type A and no caching as OXE works with TTL=0 for DNS queries. Tests are done with IBS-DECT because the IP-DECT is not yet operational with spatial redundancy.

Test Case


1

Manual switch-over to Main 2

Main Com Server is 10.1.6.1 (CPU-A) and Sby Com server is 10.10.10.11 (CPU-B)

PCS is inactive.

Generate alarm in central and remote area

2


Main Com Server is 10.1.6.1 (CPU-A)

Do manual switch-over with “bascul” or shutdown

Main Com Server is now 10.10.10.11 (CPU-B)

Generate an alarm from 8242 and 500 DECT.

3


Main Com Server is 10.10.10.11 (CPU-B)

Do manual switch-over with “bascul”

Main Com Server is now 10.1.6.1 (CPU-A)

Generate an alarm from 8242 DECT and 500.

4

Switch-over due to Network failure

Main Com Server is 10.1.6.1 (CPU-A)

Disconnect the LAN cable on CPU-A

Main Com Server is now 10.10.10.11 (CPU-B)

Generate an alarm from 8242 DECT and 500

When reconnecting cable, you’ll have dual Main configuration.

Com server CPU-A will reboot.

Nota: During switch-over the Racks or Gateway drivers stays operational and calls are maintains. Only the SIP trunks (External SIP gw) are restarted on the new Main com server. Test was also done with ISDN T2 and it works well without any call disturbances.



13 Alarming with OXE Networking configuration

OmniPCX enterprise is connected to another OmniPCX Enterprise and provide “networking” feature. The network link between these 2 systems uses the ABC-F Protocol (Alcatel Business Communication) Mobicall is connected to Node 2 using T2 ISDN access.

Test Case


1

8262 DECT, Node 1, sends Emergency Alarm

Configure handset to use Emergency alarm

Check that alarm is sent with correct information

Check that Acknowledge is also sent.

DECT 8262 Number 11281 in Node 1

2

8262 DECT, Node 1, sends enter area BT

Configure handset to use smart beacon and enter in area

Check that alarm is sent with correct information

2

Alarm server sends incoming alarm to 8262DECT

Check handset ring according to type of alarm

Check that display is correct

Tested with Urgent and hands-free alarms.



14 Appendix A : AAPP member’s Application description

14.1 Application description

Application family : Alarm Server Application commercial name: Mobicall Application version: 8.3.2 Interface type: T2 ISDN Trunking and SIP trunking,

both with geolocation and notification services Brief application description: Mobicall – system overview Mobicall is based on 4 elements allocated to the server. These are fully integrated:

The suppliers of information which bring the information to the Mobicall server.

The receivers of information which receive the information from the Mobicall server.

The Personnel-, Group & Alarm data which defines the way the information input is processed.

Supervision & Analysis provides the user with all the required statistics for adequate management of the system.

* Suppliers of information Mobicall basically supports all interfaces which are supported by standard computer systems. It is essential that the interfaces be reliable and, if possible, supervised by any kind of watchdogconcepts. Here are some examples:

Supervision of contacts free of potential

Integration of fire and intrusion detection systems

Links to building management systems / SPS

Nurse calls, heart alarm, emergency calls

Launching alarms by phone calls, SMS, e-mail, mouse, key-board and screen, fax, internet / Web

Connections through com-port interface, also ESPA 4.4.4

Data connection over SNMP, TCP/IP, Socket, FTP, Netsend... * Receivers of information In principle, Mobicall supports all interfaces which are backed by standard computer systems. It is essential that the calls are confirmed by the person answering the call so that Mobicall may function successfully and continue mobilization. Depending on the situation, Mobicall may start the escalation and call upon additional persons. Calls with clear messages (Voice) to internal and external phones

Text-messages to DECT – phones and other system phone sets

Text-messages sent as SMS to GSM mobile phones and pager

Alarm messages and information sent by fax and or e-mail

Broadcasting onto loudspeaker system

Alarm signal through broadcast to any PC-system in the network

Emergency calls through SNMP, FTP, contacts (relays free of potential, others…

Support of any H.323 terminal with Voice-over-IP connection



* Personnel & Group Data Every person to be contacted by Mobicall has a record containing access numbers (e.g. telephone, fax, pager, email) and function. Information receivers can be assigned to groups. In a matrix the various receivers with their particular identification (telephone number, email address, …) can be selected and allocated to the respective groups. Depending on the concept of the mobilization and the definition of the processes, a person may have several telephone numbers assigned. * Supervision & Analysis The analysis of an event includes printing by a local or remote network printer. An automatic printout at the time of the event is also feasible by fax or by e-mail. The printout shows the time, the calls were executed to the receivers, whether the called party answered, was busy or did not answer. It also shows a statistic of the calls answered, occupied or not answered, in percentage and in accordance with their escalation level.

Mobicall - top spot Mobicall supports both mobilization types: Sequential (search for first success) and Parallel (e.g. all members of a group at the same time) and a combination of both. Mobicall is able to record conversations – also in combination with configurable ACD concepts. If a number is busy, the next numbers and groups are dialed, until one answers the call. Mobicall also supports the free combination of traditional telephony and Voice over IP (MobiNETcall). Mobicall supports broadcasting. A recorded message can be sent to comfort-phones. Their loudspeakers will automatically open to play the message. Mobicall allows to call people according to their function and skills: e.g. Three avalanche rescue dogs, five policemen, two detonation-experts. The Web-Interface / Mobicall Messenger ! Mobicall systems may be configured and monitored by using a web browser. IP-Box Contact Controller The contact controller with TCP/IP or V.24 - link! Client specific watch-dog concepts Mobicall – Alcatel-Lucent-Lucent OmniPCX integration Mobicall is based on a modular and multi-lingual concept with a seamless integration into OmniPCX 4400/Enterprise and OmniPCX Office by using Q-SIG GF link. The overall solution DECT – OmniPCX 4400-Enterprise / OmniPCX Office – Mobicall has unique selling points to replace pager-based solution. These are:

Multi-line DECT, never occupied, can receive alarm calls at any time.

Showing display messages while the handset is ringing.

Showing a new display message during answer.

Combination of voice messages and display-text supporting confirmation by answer, confirm with key 3, cancel with key 4, password or id and password.

Showing a confirmation text when launching a conference call. An important number of installed systems, satisfied customers and resellers and a growing demand for DECT – Alcatel-Lucent-Lucent OmniPCX – Mobicall gives reasons to certify this solution for a better promotion all over the world. Return of investment with additional features by combining other interfaces of the Alcatel-Lucent- Lucent OmniPCX for intrusion, broadcast, sending mini-message and more !



Mobicall – the components

Alarm configurator; Every alarm contact can be individually identified and configured with individual attributes. Personnel & group editor; In a matrix alarm receivers with identification (telephone number, email address and others) can be assigned to groups. Alarm evaluation and presentation; It is possible at any time to analyze mobilizations. The alarm view program visualizes running or previous alarms. Scheduler year / week; The scheduler allows to specify the work shifts individually. Also, the responsible person for the 24 hour-hotline support can be specified. Alarm launcher; All defined alarms can be launched manually for testing and training purposes.



Every launched alarm is reported and traced. Alarm simulation; Different alarm simulations can be defined and stored for repetitive testing. Alarms and escalations are running as defined without disturbing anything. Test dial program; This feature allows to test easily all features of outbound calls. Post job-manager / configurator; Lists all queued jobs. Jobs may be stopped or cancelled by the system administrator. Timer job-program; This screen shows all jobs that are queued for later execution. Jobs may be started prematurely or cancelled. Voicemail configurator - Backup-tool - Centralised management - IP-box - Information/configuration of the system - Watchdog - Fax server and more… Mobicall – system variety Mobicall is a completely modular system that can be assembled to your needs. Mobicall may grow with your demand. It allows you to start with a basic set-up and add more functionality to your system for the future, without losing the investments already made. If an interface is not yet available, our customer support group is at your disposal to develop an interface according to your needs or specifications. Mobicall is available in six languages: German, French, Italian, English, Spanish and Chinese. Mobicall – typical applications Mobicall stands for: simple and clear solutions with a guaranteed inexpensive integration in the existing workflow and infrastructure.



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

15.1 Hardware equipment configuration

Mobicall is a PC-based alarming system, which can be installed on any table or in a rack, protected against dust, vibrations and humidity.

One 17” screen with keyboard and mouse placed in front of a chair is perfect.

Mobicall should be connected to an uninterrupted power supply with 6 plugs for PC, screen, modem for remote access, IP-boxes…

15.2 Software configuration

The application is running under MS Windows 7 and is constituted of programs (executable) that we launch to configure the system or monitor its operation. The connection to the running system can be done directely on the machine or using a “remote desktop” session (RDP) or using the “remote control” tool for New Voice.

A dongle (USB) is mandatory to make the application licensing:

The version of the alarm application was 8.3.2:



The configuration can be done thanks to a wizard (assistant):



The DECT “RPN” are set to match with a location area:



All phone numbers involved in alarming (generate alarms or receive alarms or receive notification

calls) are defined in this “group and person editor”:



This monitoring tool shows the calls in/out over the trunking:



To configure and monitor the high availability configuration, there are 2 programs.

Master / Supervisor monitor:



Synchronization program:



The new Voice tool service will manage the different services of the application:



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

16.1 Site survey The site survey is an important step to provide a reliable geolocation service. This step is needed to gather the

information about the power level received by the DECT on different places of the site where the solution is

deployed. The Alarm server should not only be able to treat the information received by the DECT handsets

but also to locate precisely where the alarm has been sent from. The main problem without site survey could

be a building having antennas on more than one floor. Without this study it is nearly impossible to locate a

DECT handset by pure theoretical calculation. For example if the emergency team is searching someone

having a heart attack on the wrong floor, the loss of time is important. The DECT handsets have the possibility

to send information by a long press of different button. One way to do a site survey would be to interpret that

information and compute it in a system containing the plan of the rooms and floors. There could be many ways

to do a site survey but it is a mandatory step to sell a reliable alarm server

16.2 Equipment configuration

16.2.1.1 General configuration

To configure the basic telephonic functions of the 500 DECT please read the following document: - For

OmniPCX Enterprise systems: “Alcatel-Lucent 500 DECT Handset Alcatel-Lucent OmniPCX Enterprise User

manual” In the Technical Knowledge Base accessible via the Business Portal at https://businessportal.alcatel-

lucent.com/ (the Technical Knowledge link is on the right of the window) - For OmniPCX Office systems:

“Alcatel-Lucent 500 DECT Handset, Alcatel-Lucent OmniPCX Office User manual”. In the Technical

Knowledge Base accessible via the Business Portal https://businessportal.alcatel-lucent.com/ (the Technical

Knowledge link is on the right of the window) - Quick guide : “Alcatel-Lucent 500 DECT Handset, User Guide”.

In the Technical Knowledge Base accessible via the Business Portal https://businessportal.alcatel-

lucent.com/ (the Technical Knowledge link is on the right of the window)

To have more information about how to use the 8242 DECT handset, please refer to the following document: -

“Alcatel-Lucent 8242 DECT Handset, Localisation and notification management, Configuration documentation”

In the Technical Knowledge Base accessible via the Business Portal https://businessportal.alcatel-lucent.com/

(the Technical Knowledge link is on the right of the window)

16.2.1.2 Geolocation and Notification configuration

Information about how to configure the geolocation specific parameters of the 500 DECT is contained

in the documents: - “Alcatel-Lucent 500 DECT Handset User guide Localisation and notification management

Configuration guide” In the Technical Knowledge Base accessible via the Business Portal

https://businessportal.alcatellucent.com/ (the Technical Knowledge link is on the right of the window) - “Alcatel-



Lucent 500 DECT Handset User guide Localisation and notification management User guide” In the Technical

Knowledge Base accessible via the Business Portal https://businessportal.alcatellucent.com/ (the Technical

Knowledge link is on the right of the window)

For the 8242 DECT parameters please refer to the document: - “Alcatel-Lucent 8242 DECT Handset,

Localisation and notification management, User documentation” In the Technical Knowledge Base accessible

via the Business Portal https://businessportal.alcatellucent.com/ (the Technical Knowledge link is on the right of

the window)

16.3 Parameters’ management in OmniPCX Enterprise ComServer

The parameters’ management could be done using a “terminal” connection (Console, telnet or ssh)

with command “mgr” or a “Graphical User Interface” with OmniVista8770 Network Management

Center. The following screenshots came from this GUI management center

The management can also be done with Web Management of OXE https:/IipAddressOfOxe then

login with “mtcl”.

16.3.1 Prefix to call alarm server Prefix for ISDN T2 trunk group

Prefix for ARS to SIP Trunk Group and SIP External Gateway



16.3.2 Discriminator number according to entities for SIP

16.3.3 Discriminator link to ARS route list Number of digits are 26 (OXE mode) for numbers starting with 0,1,2,9. Should add 3 to 8 if used in the first digit of PARI (DECT location) or BT address (BT location).

Trunk group 25, numbering command table 11



16.3.4 Linking ARS with External SIP Gw and Trunk Group protocol

16.3.5 Management of External trunk group

Trunk group 25 used for SIP gateway



Trunk group 27 used for ISDN T2



16.3.6 Internal SIP gateway.



16.3.7 External SIP gateway



16.3.8 DECT 8262/8242 configuration. To check management of IBS AP into OXE CS.

In the DECT handset we need to configure the server prefix in the notification server. Follow the below screenshot to configure the notification server.



Enter the prefix in the server 1 settings and incase if there is a secondary backup notification server, please enter the prefix in the server 2 settings. In our case we do not have redunancy server.

Goto location & events setting and enble the location by bluetooth beacon as show below.



Select when to trigger the alarm, while entering the beacon range or leaving beacon range or both.

16.3.9 Licences In order to use the “Geolocation and Notification” server, licenses to use DECT handsets

and SIP trunk are needed on the OmniPCX Enterprise. The licensing has to be done using ACTIS

tool and can be checked using “spadmin” command

For DECT feature:

29 DECT/PWT Engine = 1

41 DECT register Max number of Dect handset that can register to CallServer.

175 Mobile users Max number of Dect handsets declared in management

345 SIP extension users Number of IP-Dect handsets like 500Dect

371 IPDect users Max number of IP-Dect handsets

For SIP Trunking: 185 SIP gateway = 1

188 SIP network links Max number of links to SIP networks.

467 ARS Max routing list that can be managed



16.4 Capture samples

Tracing on OXE SIPmotor

8262 DECT with Location mode set to BT and smart beacons set to « Notify when leaving » :



| 20






| OP : 1b77 (7031)


| [12] Numeric string (l=5) 31 32 31 39 30

| [02] Integer (l=2) 01 02




| OP : 1b7d (7037)

| [05] ARG NULL (l=0)

| IE:[6c] CALLING_NUMBER (l=7) -> 00 81 Num : 12190

| IE:[70] CALLED_NUMBER (l=2) -> 80 Num : 2

| IE:[7d] HLC (l=2) 91 81

| [95] Locking shift. codeset : 5

| IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)

|______________________________________________________________________________

______________________________________________________________________________

| (078708:001994:03913) Concatenated-Physical-Event :


| tei: 0 >>>> message received : SETUP ACK [0d] Call ref : 80 9d

|______________________________________________________________________________

|

| IE:[18] CHANNEL (l=3) a9 83 93 -> T2 : B channel 19 exclusive

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 <<<< message sent : INFORMATION [7b] Call ref : 00 9d

| SENDING COMPLETE

|______________________________________________________________________________

|


|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : ALERT (01) Call ref : 80 9d

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : FACILITY [62] Call ref : 80 9d

|______________________________________________________________________________

|



| [aa] NFE (l=6):




| [a1] INVOKE (l=21):


| OP: ECMA RO_CONNECTED_NAME (2)

| [80] Name presentation allowed (l=9) 'F~MobiAck'

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : CONNECT (07) Call ref : 80 9d

|______________________________________________________________________________

______________________________________________________________________________





| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 00 9d

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : DISCONNECT [45] Call ref : 80 9d

|______________________________________________________________________________

|

| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 <<<< message sent : RELEASE [4d] Call ref : 00 9d

|______________________________________________________________________________

|

| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 9d

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 <<<< message sent : SETUP [05] Call ref : 00 9e

|

| CONCATENATION OF 2 SEGMENTED MESSAGES

|______________________________________________________________________________

|

| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3

| IE:[18] CHANNEL (l=3) a1 83 94 -> T2 : B channel 20 preferred



| [aa] NFE (l=6):




| [a1] INVOKE (l=69):


| OP: ECMA RO_CALLING_NAME (0)


| [80] Name presentation allowed (l=16) '12190-8262 IBS D'

| [a6] Sequence of Ecma extension (l=37)


| [06] Object id. (l=7) 2b 0c 02 88 52 b6 73



| [81] Context specific (l=19) 31 32 31 39 30 2d 38 32 36

| 32 20 49 42 53 20 44 65 63 74

| [a1] INVOKE (l=69):

| Invoke Ident. : 0001 (1)

| OP: ALCATEL RO_CLASSMARKS (1)


| [80] Feature identifier (l=5) 06 44 6e 1f 04

| [82] Cug (l=1) 00

| [83] SubNetwork number (l=1) 01

| [ab] Sequence of Project data (l=41)


| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (134624407)


| [83] Current entity (l=1) 01

| [84] Initial kind of call (l=1) 11





| OP :RO_SERVER_ACCESS_INFO (134624407)


| [80] Language (l=1) 02

| [81] type of set (l=1) 05

| [84] Feature identifier 2 (l=5) 00 c0 20 00 5e

| [86] Priority of call (l=1) 00



| [aa] NFE (l=6):


| [82] Destination Entity (l=1) Any_type_PTNX


| [a1] INVOKE (l=21):

| Invoke Ident. : 2afe (11006)

| OP: ALCATEL Unknown (11006)


| [02] Integer (l=1) 00

| [02] Integer (l=1) 00




| OP :ALCATEL CHARGING_INFO (112)


| [12] Numeric string (l=5) 31 32 31 39 30



| [82] Context specific (l=10) 20 20 20 20 20 20 20 20 20

| 20






| OP : 1b77 (7031)


| [12] Numeric string (l=5) 31 32 31 39 30

| [02] Integer (l=2) 01 02




| OP : 1b7d (7037)

| [05] ARG NULL (l=0)

| IE:[6c] CALLING_NUMBER (l=7) -> 00 81 Num : 12190


| IE:[7d] HLC (l=2) 91 81

| [95] Locking shift. codeset : 5

| IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : SETUP ACK [0d] Call ref : 80 9e

|______________________________________________________________________________

|

| IE:[18] CHANNEL (l=3) a9 83 94 -> T2 : B channel 20 exclusive

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 <<<< message sent : INFORMATION [7b] Call ref : 00 9e

| SENDING COMPLETE

|______________________________________________________________________________

|


|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : ALERT (01) Call ref : 80 9e

|______________________________________________________________________________



______________________________________________________________________________



| tei: 0 >>>> message received : FACILITY [62] Call ref : 80 9e

|______________________________________________________________________________

|



| [aa] NFE (l=6):




| [a1] INVOKE (l=21):


| OP: ECMA RO_CONNECTED_NAME (2)

| [80] Name presentation allowed (l=9) 'F~MobiAck'

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : CONNECT (07) Call ref : 80 9e

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 00 9e

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : DISCONNECT [45] Call ref : 80 9e

|______________________________________________________________________________

|

| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 <<<< message sent : RELEASE [4d] Call ref : 00 9e

|______________________________________________________________________________

|

| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING

|______________________________________________________________________________

______________________________________________________________________________



| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 9e

|______________________________________________________________________________



17 Appendix D: AAPP member’s escalation process

17.1 Contact Information

Address : ST Gallerstrasse 8 8856 Lachen Main Phone : 0041 58 750 11 11 Main Fax : 0041 58 750 11 12

Main mail : [email protected]

17.2 3rd

party support detail

17.2.1 Contact – Germany, Swiss, Austria, Netherlands & Eastern Europe

New Voice Schweiz AG Militärstrasse 90 – 8004 Zürich (Schweiz) +41 58 750 11 11 [email protected] New Voice (Austria) GmbH Paschinger Strasse 115 – 4060 Leonding (Austria) +43 732 890 120 +43 732 890 120 350 (Fax) [email protected] New Voice Systems GmbH Mörikestrasse 17 – 71636 Ludwigsburg (Deutschland) +49 7141 947 59 50 +49 7141 947 59 69 (Fax) [email protected] New Voice Systems GmbH Schlesische Straße 20 – 10997 Berlin (Deutschland) +49 7141 947 59 50 [email protected]

17.2.2 Contact – France, Swiss, Belgium, Luxembourg & Western Europe

New Voice (France) SA 19, Rue Corot – 92410 Ville D’Avray (France) +33 1 41 15 80 65 [email protected] New Voice Suisse SA Chemin du Joran 8b – 1260 Nyon (Suisse) +41 58 750 11 22 [email protected]

mailto:[email protected]








17.2.3 Contact - Dubai

New Voice Systems DMCC Swiss ILC Services DMCCSwiss Tower, Office 3601JLT, Cluster YP. O. Box 309057Dubai, UAE [email protected]

17.2.4 Contact - USA

New Voice Americas LTD 40 Exchange Place, Suite 1602 New York, NY 10005 [email protected]

17.2.5 Contact - Australia

New Voice Australia Ltd. Level 1 / 7 Clunies Ross Court, Eight Mile Plains 4113, Queensland +61 7 5667 2990 [email protected]

17.2.6 General Information

The first level support is delegated to our resellers and installers. NewVoice, as a software editor only provides second level support. The 2nd level support is mainly for configuration and installation problems. These are easy problems than can be solved pretty quickly. There are two different support resolution methods: - phone assistance : adapted for simple and recurrent questions - on-line assistance with remote connexion : used as the highest level of support provided for incident resolution. Expert connect to the system to get more precise information (after a pre qualification) and to solve it

17.2.7 Severity Description and Response Times

Priority / Severity Description Response time

Low Trouble with installation, configuration

10min

Blocking Trouble with communication with other systems

30min to 24h






17.2.8 Support Level Definitions

Level Description

1st Qualification of an incident, a problem. Includes the collection of every configuration information, a detailed description of the problem occuring and the cinematic conducting to that problem.

2nd Resolution of an incident. Problems of configuration, installation of the application, or uneffective functionnalities.

3rd Hardware issues. Since no hardware is provided, there is no such support level







18 Appendix E: AAPP program

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

18.2 Enterprise.Alcatel-Lucent.com

You can access the Alcatel-Lucent Enterprise website at this URL: https://www.al-enterprise.com



https://www.al-enterprise.com/



19 Appendix F: AAPP Escalation process

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



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



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



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



19.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: [email protected]

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

Telephone numbers:

ALE Business Partners Support Center for countries:

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

Country Supported language Toll free number

France

French

+800-00200100

Belgium

Luxembourg

Germany

German Austria

Switzerland

United Kingdom

English

Italy

Australia

Denmark

Ireland

Netherlands

South Africa

Norway

Poland

Sweden

Czech Republic

Estonia

Finland

Greece

Slovakia

Portugal

Spain Spanish


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




END OF DOCUMENT

ale application partner program inter-working report

Documents