ale application partner program inter-working report
Post on 03-Oct-2021
0 Views
Preview:
TRANSCRIPT
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 2/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 3/118
Copyright © ALE 2019
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: oudom@newvoice.ch
ALE Application Partner Program – Inter-working report - Edition 1 - page 4/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 5/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 6/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 7/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 8/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 9/118
Copyright © ALE 2019
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”).
ALE Application Partner Program – Inter-working report - Edition 1 - page 10/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 11/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 12/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 13/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 14/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 15/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 16/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 17/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 18/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 19/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 20/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 21/118
Copyright © ALE 2019
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
9.1.2.1 Test Objectives
To check the SIP related authentication and trunk configuration
9.1.2.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 22/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
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
9.1.3.1 Test Objectives
To check normal SIP calls to various extensions.
9.1.3.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 23/118
Copyright © ALE 2019
9.1.4 SIP calls to various idle phones
9.1.4.1 Test Objectives
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.
9.1.4.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
Call to 8262 DECT in idle state
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 24/118
Copyright © ALE 2019
9.1.5 SIP call to various busy phones
9.1.5.1 Test Objectives
To check normal SIP calls to various BUSY extensions in OXE Test Case:
Phone is in communication.
To send a call, generate a test call from the TPA
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
9.1.5.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
Test Case defined above
Expected result defined above
SB3
Call to busy DECT 8262
Test on Alcatel-Lucent Mobile 8262
Test Case defined above
Expected result defined above
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
Test on Alcatel-Lucent Mobile 8232
Test Case defined above
Expected result defined above
SB5
Call to busy IPTouch 8038
Test on Alcatel-Lucent IPT4038
Test Case defined above
Expected result defined above
SB6
Call to busy Analog Phone
Test on Alcatel-Lucent Analog phone
Test Case defined above
Expected result defined above
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 25/118
Copyright © ALE 2019
9.1.6 SIP calls to IBS-DECT sets out of radio range
9.1.6.1 Test Objectives
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.
9.1.6.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
OR1
Call to 8242 DECT-IBS out of radio range
Test on Alcatel-Lucent 8242 DECT Test Case defined above Expected result defined above
OR2
Call to 8242 DECT-XBS out of radio range
Test on Alcatel-Lucent 8232 DECT Test Case defined above Expected result defined above
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)
ALE Application Partner Program – Inter-working report - Edition 1 - page 26/118
Copyright © ALE 2019
9.1.7 SIP calls to forwarded phone or Dect sets
9.1.7.1 Test Objectives
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
9.1.7.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
9.1.8.1 Test Objectives
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
To send a call, generate a test call from the TPA
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
9.1.8.2 Test Results
ALE Application Partner Program – Inter-working report - Edition 1 - page 27/118
Copyright © ALE 2019
Test Case
Id Test Case NA OK NOK Comment
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
9.1.9.1 Test Objectives
To check the sip calls to various external forwarded phone sets in OXE Test Case:
Phone is in idle mode, call forwarding is configured
To send a call, generate a test call from the TPA
accept the call on the forwarding destination; which is an external destination
Expected result:
call forwarded to the target voice mail
the following behavior should the same depending on the target phone state
9.1.9.2 Test Results
Test Case
Id Test Case NA OK NOK Comment
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 28/118
Copyright © ALE 2019
9.1.10 SIP call to Out of Service phone
9.1.10.1 Test Objectives
To check the sip calls to various external forwarded phone sets in OXE Test Case:
Phone is out of service
To send a call, generate a test call from the TPA Expected result:
call is rejected with 480 – Temporarily not available
TPA logs call as rejected
9.1.10.2 Test Results
Test Case
Id Test Case NA OK NOK Comment
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
9.1.11.1 Test Objectives
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.
9.1.11.2 Test Results
Test Case
Id Test Case NA OK NOK Comment
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 29/118
Copyright © ALE 2019
9.1.12 SIP call with Special Characters in CLI
9.1.12.1 Test Objectives
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.
9.1.12.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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)
Alarm server sends Alarm toward the terminal.
Check display of terminal.
CL3
Call to Dect 8242
Alarm server sends Alarm toward the terminal.
Check display of terminal.
CL4
Call to Dect 8242
Alarm server sends Alarm toward the terminal.
Check display of terminal.
ALE Application Partner Program – Inter-working report - Edition 1 - page 30/118
Copyright © ALE 2019
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
9.2.1.1 Test Objectives
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.
9.2.1.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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).
ALE Application Partner Program – Inter-working report - Edition 1 - page 31/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
- 8262DECT is in idle mode
9.2.2 Test cases linked to “Status message” on 8242 DECT
9.2.2.1 Test Objectives
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.
9.2.2.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 32/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
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
9.2.3.1 Test Objectives
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.
9.2.3.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 33/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
- 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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 34/118
Copyright © ALE 2019
9.2.4 Test cases linked to “Key events” on 8242 and 8262
9.2.4.1 Test Objectives
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
9.2.4.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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:
Initiate the Event function in the MMI configuration menu.
DECT 8262 is in idle mode
Make a long press of one of the keys from 1 to 9 to trigger the function.
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 35/118
Copyright © ALE 2019
9.2.5 Test cases linked to “Notification” on 8242 DECT
9.2.5.1 Test Objectives
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.
9.2.5.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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:F@10.1.2.55;user=phone>
NOT2
Notification on 8242 DECT in communication state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is engaged into a communication.
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.
Existing call is disconnected
NOT3
Notification on 8242 DECT in dialling state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is dialing a number.
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 36/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
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.
NOT4
Notification on 8242 DECT in configuration state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is in configuration menu.
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 37/118
Copyright © ALE 2019
9.2.6 Test cases linked to “Notification” on DECT 8262 with "Panic Red button"
9.2.6.1 Test Objectives
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.
Configure the easy acknowledge to get display of Alarm Ack on screen.
9.2.6.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
PA1
Notification on DECT 8262 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.
PA2
Notification on DECT 8262 in Communication state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is engaged into a communication.
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.
Existing call is disconnected
PA3
Notification on DECT 8262 in dialling state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is dialing a number.
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 38/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
~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.
PA4
Notification on DECT 8262 in configuration state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is in configuration menu.
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.
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
9.2.7.1 Test Objectives
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.
9.2.7.2 Test Objectives
Test Case Id
Test Case NA OK NOK Comment
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).
Check that the notification server decodes well the message.
Handset rings with pre-alarm signal then trigger the alarm call.
ALE Application Partner Program – Inter-working report - Edition 1 - page 39/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
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
Configure "Man Down" function via MMI to 60° degree.
Check that the Lock/Unlock is inactive.
HS is dialing a phone number.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
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
9.2.8.1 Test Objectives
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 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.
9.2.8.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
NM1
No Movement on DECT 8262 in Idle state
Configure "No Movement" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Do not move the handset for a time.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
ALE Application Partner Program – Inter-working report - Edition 1 - page 40/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
While acknowledged, check that message is sent to server.
NM3
No Movement on DECT 8262 in dialling state
Configure "No Movement" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Do not move the handset for a time.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
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
9.2.9.1 Test Objectives
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 sent.
The Detection sensitivity can be set to Maximum, Medium or Minimum. With Maximum to detect softer shock and Minimum to detect strong shock.
9.2.9.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
SH1
SHOCK on DECT 8262 in Idle state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Let the HS fall on table.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
ALE Application Partner Program – Inter-working report - Edition 1 - page 41/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
While acknowledged, check that message is sent to server.
SH2
SHOCK on DECT 8262 in communication state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is engaged into a conversation.
Let the HS fall on table.
Alarm is activated after “pre-alarm” timer.
Current conversation is hanged-up.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
Existing call is disconnected and alarm is triggered,
SH3
SHOCK on DECT 8262 in dialling state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is dialing a number.
Let the HS fall on table.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
Set exit from dialing and generate alarm.
SH4
SHOCK on DECT 8262 in configuration_state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is into the configuration menu...
Let the HS fall on table.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
ALE Application Partner Program – Inter-working report - Edition 1 - page 42/118
Copyright © ALE 2019
9.2.10 Test cases linked to "Pull cord" detected on DECT 8262
9.2.10.1 Test Objectives
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 cord connected to the handset is removed by pulling.
The application triggers an alarm and send to the server.
9.2.10.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
PC1
Pull Cord on DECT 8262 in Idle state
Configure "Pull cord" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Pull the cord attached to the handset.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
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
Configure "Pull cord" function via MMI.
Check that the Lock/Unlock is inactive.
HS is engaged into a conversation.
Pull cord attached to the handset.
Alarm is activated after “pre-alarm” timer.
Current conversation is hanged-up.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
Existing call is disconnected and alarm is triggered,
PC3
Pull Cord on DECT 8262 in dialling state
Configure "Pull cord" function via MMI.
Check that the Lock/Unlock is inactive
HS is dialing a number.
Pull the cord attached to the handset.
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).
Check that the notification server decodes
ALE Application Partner Program – Inter-working report - Edition 1 - page 43/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
PC4
Pull Cord on DECT 8262 in configuration_state
Configure "Pull cord" function via MMI.
Check that the Lock/Unlock is inactive
HS is into the configuration menu.
Pull the cord attached to the handset.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
9.2.11 Test cases linked to base station location using RPN
9.2.11.1 Test Objectives
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.
9.2.11.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
Check that the alarm server decodes well the message with the RPN values and levels.
Move the handset and check that values changes.
ALE Application Partner Program – Inter-working report - Edition 1 - page 44/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
RP3
Location of the 8242 DECT in IP XBS areas:
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.
IP xBS not tested.
RP4
Location of the DECT 8262 in IP XBS areas:
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 45/118
Copyright © ALE 2019
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
9.3.1.1 Test Objectives
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.
9.3.1.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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
- 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.
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 46/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
AL5
Manual Incoming alarm Urgent on DECT 8242 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 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)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL8
Manual Incoming alarm Very Urgent on 8242 DECT 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
AL8
Manual Incoming alarm Very Urgent on 8242 DECT in normal mode
- Set the handset in normal 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
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)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
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)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL11
Manual Incoming alarm Loudspeaker on 8242 DECT in normal mode
- Set the handset in normal mode. Send a CNI signal having a format of “E~xxx” with the CS (Alarm server)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL12
Manual Incoming alarm Loudspeaker on 8242 DECT in vibrator mode
- Set the handset in vibrator mode. Send a CNI signal having a format of “E~xxx” with the CS (Alarm server)
ALE Application Partner Program – Inter-working report - Edition 1 - page 47/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
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
Send a CNI signal having a format of
“E~&#$£µàéèêçüöäß” to
the Handset.
Check that the handset will be in communication with Microphone not muted.
Check display of accented characters.
AL15
Manual Incoming Normal alarm on 8242 DECT 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.
AL16
Manual Incoming Hands-free alarm on 8242 DECT with accented characters
Send a CNI signal having a format of
“E~&#$£µàéèêçüöäß” to
the Handset.
Check that the handset will be in communication with Microphone not muted.
Check display of accented characters.
ALE Application Partner Program – Inter-working report - Edition 1 - page 48/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 49/118
Copyright © ALE 2019
10.2.1 ISDN call set-up and call release
Test Case
Id Test Case N/A OK NOK Comment
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
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
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
Call to 8242 DECT in idle state
Test on ALE 8242 DECT Test Case defined above Expected result defined above
Handset 8242 DECT Number 12192
3
Call to 8262 DECT in idle state
Test on ALE 8262 DECT Test Case defined above Expected result defined above
Handset 8262 DECT Number 12193
4
Call to 8232 DECT in idle state
Test on ALE Mobile 8232 DECT Test Case defined above Expected result defined above
Handset 8232 DECT Number 12191
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 50/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
1
Call to busy 8128 Mobile IPTouch
Test on ALE Wifi mobile 8128
Test Case defined above
Expected result defined above
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
Test Case defined above
Expected result defined above
Diversion to Voice mail, see 10.2.6.
4
Call to busy 8232 IBS-DECT
Test on Alcatel-Lucent Mobile 8232
Test Case defined above
Expected result defined above
Call waiting on Multiline set.
4
Call to busy Premium Deskphone 8028S
Test on ALE 8028S
Test Case defined above
Expected result defined above
5
Call to busy 8262 IBS-DECT
Test on ALE 8262 DECT
Test Case defined above
Expected result defined above
Diversion to Entity Overflow number 12001. Display of “Night Forwarding”
8
Call to busy Analog Phone
Test on ALE Analog phone
Test Case defined above
Expected result defined above
10
Call to busy SIP Phone
Test on Generic SIP phone
Test Case defined above
Expected result defined above
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 51/118
Copyright © ALE 2019
10.2.4 ISDN calls to DECT sets out of radio range
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
TPA logs the call rejection reason
Test was done by powering-off the Dect handsets.
Test Case
Id Test Case N/A OK NOK Comment
1
Call to 8262 IBS-DECT out of radio range
Test on ALE 8262 DECT
Test Case defined above
Expected result defined above
Tested by powering-off the handset.
2
Call to 8242 IP-DECT out of radio range
Test on ALE 8242 DECT
Test Case defined above
Expected result defined above
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
Id Test Case N/A OK NOK Comment
1
Call to Premium Deskphone
Test on ALE 8028S Test Case defined above Expected result defined above
2
Call to 8242 DECT
Test on ALE 8242 DECT Test Case defined above Expected result defined above
Prefixes are: 51 for immediate forward to destination / 41 for forward cancellation or uses the dedicated screen key on Digital ALE phones.
ALE Application Partner Program – Inter-working report - Edition 1 - page 52/118
Copyright © ALE 2019
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).
To send a call, generate a test call from the TPA
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
Id Test Case N/A OK NOK Comment
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
To send a call, generate a test call from the TPA
accept the call on the forwarding destination; which is an external destination Expected result:
call forwarded to the target voice mail
the following behavior should the same depending on the target phone state
Test Case
Id Test Case N/A OK NOK Comment
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 53/118
Copyright © ALE 2019
10.2.8 ISDN call to Out of Service phone Test Case:
Phone is out of service
To send a call, generate a test call from the TPA Expected result:
call is rejected
TPA logs call as rejected
Test Case
Id Test Case N/A OK NOK Comment
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
Id Test Case N/A OK NOK Comment
1
Call to Premium Deskphone 8028S
Alarm server sends Alarm toward the terminal.
Check display of terminal.
2
Call to MIPT 8128 (WLAN Extension)
Alarm server sends Alarm toward the terminal.
Check display of terminal.
3
Call to 8242DECT
Alarm server sends Alarm toward the terminal.
Check display of terminal.
ALE Application Partner Program – Inter-working report - Edition 1 - page 54/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 55/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
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
Id Test Case N/A OK NOK Comment
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
Check that the notification server receives and decodes the message correctly.
2 Status message on 8242 DECT Out of charger
Initiate the Status function in the MMI
ALE Application Partner Program – Inter-working report - Edition 1 - page 56/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
configuration menu.
A status call is made when the handset is out of charger.
Check the status in the message sent by PBX
Check that the notification server receives and decodes the message correctly.
3
Status message on 8242 DECT switched off
Step 1: Handset is out of charger
Initiate the Status function in the MMI configuration menu.
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
Initiate the Status function in the MMI configuration menu.
A status call is made when the handset is in the charger and switched-off.
Check the status in the message sent by PBX
Check that the notification server receives and decodes the message correctly.
….. 80940
4
Status message on 8242 DECT switched on
Step 1: Handset is out of charger
Initiate the Status function in the MMI configuration menu.
A status call is made when the handset is out of charger and switched.
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
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
Check that the notification server receives and decodes the message correctly.
…..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
Id Test Case N/A OK NOK Comment
1
Status message on 8262 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
Check that the notification server receives and
…. 50940
ALE Application Partner Program – Inter-working report - Edition 1 - page 57/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
decodes the message correctly.
2
Status message on 8262DECT Out of charger
Initiate the Status function in the MMI configuration menu.
A status call is made when the handset is out of charger.
Check the status in the message sent by PBX
Check that the notification server receives and decodes the message correctly.
…… 40940
3
Status message on 8262DECT switched off
Step 1: Handset is out of charger
Initiate the Status function in the MMI configuration menu.
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
Initiate the Status function in the MMI configuration menu.
A status call is made when the handset is in the charger and switched-off.
Check the status in the message sent by PBX
Check that the notification server receives and decodes the message correctly.
4
Status message on 8262 DECT switched on
Step 1: Handset is out of charger
Initiate the Status function in the MMI configuration menu.
A status call is made when the handset is out of charger and switched.
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
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
Check that the notification server receives and decodes the message correctly.
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:
ALE Application Partner Program – Inter-working report - Edition 1 - page 58/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
1
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.
Key 0: …..40920 Key 1: …..41920 Key 5: …..45920
2
Key events on 8262 DECT in Idle state:
Initiate the Event function in the MMI configuration menu.
8262DECT is in idle mode
Make a long press of one of the keys from 1 to 9 to trigger the function.
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 59/118
Copyright © ALE 2019
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.
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 Test Case N/A OK NOK Comment
1
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.
DECT send Notification …. 44910 then stay in conversation. Then Ack is send ….45901
2
Notification on 8242 DECT in communication state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is engaged into a communication.
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.
3
Notification on 8242 DECT in dialling state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is dialling a number.
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 60/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
4
Notification on 8242 DECT in configuration state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is in configuration menu.
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.
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.
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 Test Case N/A OK NOK Comment
1
Notification on 8262DECT 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.
Notification: …..44910 Ack: …..45901
2
Notification on 8262DECT in communication state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is engaged into a communication.
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 61/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
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.
3
Notification on 8262DECT in dialling state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is dialling a number.
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.
4
Notification on 8262DECT in configuration state
Activate the Notify function in the MMI configuration menu
Define the first and second access prefix in the Alarm configuration.
HS is in configuration menu.
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 62/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
1
ManDown on 8262DECT 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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
….. 41901
2
ManDown on 8262DECT while in Communication state
Configure "Man Down" function via MMI to 60° degree.
Check that the Lock/Unlock is inactive.
HS is in a communication with other correspondant.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
See Exceptions.
3
ManDown on 8262DECT while in dialling state
Configure "Man Down" function via MMI to 60° degree.
Check that the Lock/Unlock is inactive.
HS is dialling a phone number.
Move the handset to horizontal position.
Alarm is activated after “pre-alarm” timer.
At end of timer
ALE Application Partner Program – Inter-working report - Edition 1 - page 63/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
4
ManDown on 8262DECT while in configuration state
Configure "Man Down" function via MMI to 60° degree.
Check that the Lock/Unlock is inactive.
HS is in configuration 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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
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
Id Test Case N/A OK NOK Comment
1
No Movement on 8262DECT in Idle state
Configure "No Movement" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Do not move the handset for a time.
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).
Check that the notification server decodes well
….43801 then Ack ….45801
ALE Application Partner Program – Inter-working report - Edition 1 - page 64/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
2
No Movement on 8262DECT in communication state
Configure "No Movement" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Do not move the handset for a time.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
See Exceptions.
3
No Movement on 8262DECT in dialling state
Configure "No Movement" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Do not move the handset for a time.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
At end of timer
4
No Movement on 8262DECT in configuration state
Configure "No Movement" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Do not move the handset for a time.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 65/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
1
SHOCK on 8262DECT in Idle state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Let the HS fall on table.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
….44901 Then Ack ….45901
2
SHOCK on 8262DECT in communication state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is engaged into a conversation.
Let the HS fall on table.
Alarm is activated after “pre-alarm” timer.
Current conversation is hanged-up.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
3
SHOCK on 8262DECT in dialling state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is dialling a number.
Let the HS fall on table.
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).
Check that the notification server decodes well
ALE Application Partner Program – Inter-working report - Edition 1 - page 66/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
4
SHOCK on 8262DECT in configuration_state
Configure "Shock" function via MMI.
Check that the Lock/Unlock is inactive.
HS is into the configuration menu..
Let the HS fall on table.
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
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
Id Test Case N/A OK NOK Comment
1
Pull cord on 8262DECT in Idle state
Configure "Pull Cord" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Pull-out the cord
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
Alarm ….42801
2
Pull cord on 8262DECT in communication state
Configure "Pull Cord" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Pull-out the cord
Alarm is activated after “pre-alarm” timer.
Current conversation is hanged-up.
ALE Application Partner Program – Inter-working report - Edition 1 - page 67/118
Copyright © ALE 2019
Test Case
Id Test Case N/A OK NOK Comment
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
3
Pull cord on 8262DECT in dialling state
Configure "Pull Cord" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Pull-out the cord
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
4
Pull cord on 8262DECT in configuration menu
Configure "Pull Cord" function via MMI.
Check that the Lock/Unlock is inactive.
HS is in idle state.
Pull-out the cord
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).
Check that the notification server decodes well the message.
Handset rings and need to acknowledge the alarm.
While acknowledged, check that message is sent to server.
ALE Application Partner Program – Inter-working report - Edition 1 - page 68/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
1
Location of the 8242DECT 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.
2
Location of the 8262DECT 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.
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
Check that the alarm server decodes well the message with the RPN values and levels.
Move the handset and check that values changes.
5
Location of the 8262DECT in remote of IBS-DECT areas:
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 69/118
Copyright © ALE 2019
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
Test Case NA OK NOK Comment
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
- 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.
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
AL5
Manual Incoming alarm Urgent on DECT 8242 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 Alarm 2
The called party should be set ax DC! Instead of DCT ti use the correct calling scheme with B~.
ALE Application Partner Program – Inter-working report - Edition 1 - page 70/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
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)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL8
Manual Incoming alarm Very Urgent on 8242 DECT 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
AL8
Manual Incoming alarm Very Urgent on 8242 DECT in normal mode
- Set the handset in normal 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
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)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
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)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL11
Manual Incoming alarm Loudspeaker on 8242 DECT in normal mode
- Set the handset in normal mode. Send a CNI signal having a format of “E~xxx” with the CS (Alarm server)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL12
Manual Incoming alarm Loudspeaker on 8242 DECT in vibrator mode
- Set the handset in vibrator mode. Send a CNI signal having a format of “E~xxx” with the CS (Alarm server)
- Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings
AL13
Manual Incoming Normal alarm on DECT 8262 with accented characters
Send a CNI signal having a format of
“B~&#$£µàéèêçüöäß” to
the Handset.
Special characters are not supported by the application
ALE Application Partner Program – Inter-working report - Edition 1 - page 71/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
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
Send a CNI signal having a format of
“E~&#$£µàéèêçüöäß” to
the Handset.
Check that the handset will be in communication with Microphone not muted.
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
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.
Special characters are not supported by the application
AL16
Manual Incoming Hands-free alarm on 8242 DECT with accented characters
Send a CNI signal having a format of
“E~&#$£µàéèêçüöäß” to
the Handset.
Check that the handset will be in communication with Microphone not muted.
Check display of accented characters.
Special characters are not supported by the application
ALE Application Partner Program – Inter-working report - Edition 1 - page 72/118
Copyright © ALE 2019
11 Use of Bluetooth Beacons
11.1 Test cases linked to Bluetooth beacons’ location in case of Smart beacon
11.1.1.1 Test Objectives
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).
11.1.1.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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.
Check that the live signals is sent to alarm server according to areas where you moved.
XX:XX:84:34:26:4E XX:XX:84:2A:A0:E1
ALE Application Partner Program – Inter-working report - Edition 1 - page 73/118
Copyright © ALE 2019
Test Case Id
Test Case NA OK NOK Comment
.
SB5
Location of the 8262 DECT 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.
.
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
11.2.1.1 Test Objectives
The test is done with Handset configuration set to “Bluetooth” in Location setting. (Alarms are sent with BT address information)
11.2.1.2 Test Results
Test Case Id
Test Case NA OK NOK Comment
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.
Move the handset and check that values changes.
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.
Move the handset and check that values changes.
00002703 Pull Cord 00005703 Ack
ALE Application Partner Program – Inter-working report - Edition 1 - page 74/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
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
Manual switch-over to Main 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
Manual switch-over to Main 1
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 75/118
Copyright © ALE 2019
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
Id Test Case N/A OK NOK Comment
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 76/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 77/118
Copyright © ALE 2019
* 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 !
ALE Application Partner Program – Inter-working report - Edition 1 - page 78/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 79/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 80/118
Copyright © ALE 2019
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:
ALE Application Partner Program – Inter-working report - Edition 1 - page 81/118
Copyright © ALE 2019
The configuration can be done thanks to a wizard (assistant):
ALE Application Partner Program – Inter-working report - Edition 1 - page 82/118
Copyright © ALE 2019
ALE Application Partner Program – Inter-working report - Edition 1 - page 83/118
Copyright © ALE 2019
ALE Application Partner Program – Inter-working report - Edition 1 - page 84/118
Copyright © ALE 2019
ALE Application Partner Program – Inter-working report - Edition 1 - page 85/118
Copyright © ALE 2019
The DECT “RPN” are set to match with a location area:
ALE Application Partner Program – Inter-working report - Edition 1 - page 86/118
Copyright © ALE 2019
All phone numbers involved in alarming (generate alarms or receive alarms or receive notification
calls) are defined in this “group and person editor”:
ALE Application Partner Program – Inter-working report - Edition 1 - page 87/118
Copyright © ALE 2019
This monitoring tool shows the calls in/out over the trunking:
ALE Application Partner Program – Inter-working report - Edition 1 - page 88/118
Copyright © ALE 2019
To configure and monitor the high availability configuration, there are 2 programs.
Master / Supervisor monitor:
ALE Application Partner Program – Inter-working report - Edition 1 - page 89/118
Copyright © ALE 2019
ALE Application Partner Program – Inter-working report - Edition 1 - page 90/118
Copyright © ALE 2019
Synchronization program:
ALE Application Partner Program – Inter-working report - Edition 1 - page 91/118
Copyright © ALE 2019
The new Voice tool service will manage the different services of the application:
ALE Application Partner Program – Inter-working report - Edition 1 - page 92/118
Copyright © ALE 2019
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-
ALE Application Partner Program – Inter-working report - Edition 1 - page 93/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 94/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 95/118
Copyright © ALE 2019
ALE Application Partner Program – Inter-working report - Edition 1 - page 96/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 97/118
Copyright © ALE 2019
Trunk group 27 used for ISDN T2
ALE Application Partner Program – Inter-working report - Edition 1 - page 98/118
Copyright © ALE 2019
16.3.6 Internal SIP gateway.
ALE Application Partner Program – Inter-working report - Edition 1 - page 99/118
Copyright © ALE 2019
16.3.7 External SIP gateway
ALE Application Partner Program – Inter-working report - Edition 1 - page 100/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 101/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 102/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 103/118
Copyright © ALE 2019
16.4 Capture samples
Tracing on OXE SIPmotor
8262 DECT with Location mode set to BT and smart beacons set to « Notify when leaving » :
ALE Application Partner Program – Inter-working report - Edition 1 - page 104/118
Copyright © ALE 2019
Tracing on T2 ISDN using T3
______________________________________________________________________________
| (078702:001992:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 359 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 00 9d
|
| CONCATENATION OF 2 SEGMENTED MESSAGES
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a1 83 93 -> T2 : B channel 19 preferred
| IE:[1c] FACILITY (l=154)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=69):
| Invoke Ident. : 2ee0 (12000)
| OP: ECMA RO_CALLING_NAME (0)
| [30] Sequence (l=57)
| [80] Name presentation allowed (l=16) '12190-8262 IBS D'
| [a6] Sequence of Ecma extension (l=37)
| [30] Sequence (l=35)
| [06] Object id. (l=7) 2b 0c 02 88 52 b6 73
| [30] Sequence (l=24)
| [80] Context specific (l=1) 00
| [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)
| [30] Sequence (l=56)
| [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)
| [30] Sequence (l=15)
| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (134624407)
| [30] Sequence (l=9)
| [83] Current entity (l=1) 01
| [84] Initial kind of call (l=1) 11
| [85] Context specific (l=1) 01
| [30] Sequence (l=22)
| OP :RO_SERVER_ACCESS_INFO (134624407)
| [30] Sequence (l=16)
| [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
| IE:[1c] FACILITY (l=35)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) Any_type_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=21):
| Invoke Ident. : 2afe (11006)
| OP: ALCATEL Unknown (11006)
| [30] Sequence (l=6)
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| IE:[27] NOTIF_INDI (l=46)
| 83 : discriminator for notif. extention
| [30] Sequence (l=43)
| OP :ALCATEL CHARGING_INFO (112)
| [30] Sequence (l=33)
| [12] Numeric string (l=5) 31 32 31 39 30
| [80] Context specific (l=2) 05 00
| [81] Context specific (l=2) 01 02
| [82] Context specific (l=10) 20 20 20 20 20 20 20 20 20
ALE Application Partner Program – Inter-working report - Edition 1 - page 105/118
Copyright © ALE 2019
| 20
| [86] Context specific (l=1) 01
| [87] Context specific (l=1) 00
| IE:[27] NOTIF_INDI (l=25)
| 83 : discriminator for notif. extention
| [30] Sequence (l=22)
| OP : 1b77 (7031)
| [30] Sequence (l=11)
| [12] Numeric string (l=5) 31 32 31 39 30
| [02] Integer (l=2) 01 02
| IE:[27] NOTIF_INDI (l=14)
| 83 : discriminator for notif. extention
| [30] Sequence (l=11)
| 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 :
| long: 23 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP ACK [0d] Call ref : 80 9d
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 93 -> T2 : B channel 19 exclusive
|______________________________________________________________________________
______________________________________________________________________________
| (078708:001995:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 47 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : INFORMATION [7b] Call ref : 00 9d
| SENDING COMPLETE
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=26) -> 80 Num : 0022313205204405900002703
|______________________________________________________________________________
______________________________________________________________________________
| (078711:001996:03913) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 80 9d
|______________________________________________________________________________
______________________________________________________________________________
| (078713:001997:03913) Concatenated-Physical-Event :
| long: 55 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : FACILITY [62] Call ref : 80 9d
|______________________________________________________________________________
|
| IE:[1c] FACILITY (l=35)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=21):
| Invoke Ident. : 2ee2 (12002)
| OP: ECMA RO_CONNECTED_NAME (2)
| [80] Name presentation allowed (l=9) 'F~MobiAck'
|______________________________________________________________________________
______________________________________________________________________________
| (078713:001998:03913) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 80 9d
|______________________________________________________________________________
______________________________________________________________________________
| (078713:001999:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
ALE Application Partner Program – Inter-working report - Edition 1 - page 106/118
Copyright © ALE 2019
| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 00 9d
|______________________________________________________________________________
______________________________________________________________________________
| (078740:002000:03913) Concatenated-Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : DISCONNECT [45] Call ref : 80 9d
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________
______________________________________________________________________________
| (078740:002001:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : RELEASE [4d] Call ref : 00 9d
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________
______________________________________________________________________________
| (078740:002002:03913) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 9d
|______________________________________________________________________________
______________________________________________________________________________
| (079108:002008:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 359 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| 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
| IE:[1c] FACILITY (l=154)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=69):
| Invoke Ident. : 2ee0 (12000)
| OP: ECMA RO_CALLING_NAME (0)
| [30] Sequence (l=57)
| [80] Name presentation allowed (l=16) '12190-8262 IBS D'
| [a6] Sequence of Ecma extension (l=37)
| [30] Sequence (l=35)
| [06] Object id. (l=7) 2b 0c 02 88 52 b6 73
| [30] Sequence (l=24)
| [80] Context specific (l=1) 00
| [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)
| [30] Sequence (l=56)
| [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)
| [30] Sequence (l=15)
| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (134624407)
| [30] Sequence (l=9)
| [83] Current entity (l=1) 01
| [84] Initial kind of call (l=1) 11
| [85] Context specific (l=1) 01
ALE Application Partner Program – Inter-working report - Edition 1 - page 107/118
Copyright © ALE 2019
| [30] Sequence (l=22)
| OP :RO_SERVER_ACCESS_INFO (134624407)
| [30] Sequence (l=16)
| [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
| IE:[1c] FACILITY (l=35)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) Any_type_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=21):
| Invoke Ident. : 2afe (11006)
| OP: ALCATEL Unknown (11006)
| [30] Sequence (l=6)
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| IE:[27] NOTIF_INDI (l=46)
| 83 : discriminator for notif. extention
| [30] Sequence (l=43)
| OP :ALCATEL CHARGING_INFO (112)
| [30] Sequence (l=33)
| [12] Numeric string (l=5) 31 32 31 39 30
| [80] Context specific (l=2) 05 00
| [81] Context specific (l=2) 01 02
| [82] Context specific (l=10) 20 20 20 20 20 20 20 20 20
| 20
| [86] Context specific (l=1) 01
| [87] Context specific (l=1) 00
| IE:[27] NOTIF_INDI (l=25)
| 83 : discriminator for notif. extention
| [30] Sequence (l=22)
| OP : 1b77 (7031)
| [30] Sequence (l=11)
| [12] Numeric string (l=5) 31 32 31 39 30
| [02] Integer (l=2) 01 02
| IE:[27] NOTIF_INDI (l=14)
| 83 : discriminator for notif. extention
| [30] Sequence (l=11)
| 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)
|______________________________________________________________________________
______________________________________________________________________________
| (079115:002010:03913) Concatenated-Physical-Event :
| long: 23 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP ACK [0d] Call ref : 80 9e
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 94 -> T2 : B channel 20 exclusive
|______________________________________________________________________________
______________________________________________________________________________
| (079115:002011:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 47 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : INFORMATION [7b] Call ref : 00 9e
| SENDING COMPLETE
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=26) -> 80 Num : 0022313205204405900005703
|______________________________________________________________________________
______________________________________________________________________________
| (079120:002012:03913) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 80 9e
|______________________________________________________________________________
ALE Application Partner Program – Inter-working report - Edition 1 - page 108/118
Copyright © ALE 2019
______________________________________________________________________________
| (079122:002013:03913) Concatenated-Physical-Event :
| long: 55 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : FACILITY [62] Call ref : 80 9e
|______________________________________________________________________________
|
| IE:[1c] FACILITY (l=35)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=21):
| Invoke Ident. : 2ee2 (12002)
| OP: ECMA RO_CONNECTED_NAME (2)
| [80] Name presentation allowed (l=9) 'F~MobiAck'
|______________________________________________________________________________
______________________________________________________________________________
| (079122:002014:03913) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 80 9e
|______________________________________________________________________________
______________________________________________________________________________
| (079122:002015:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 00 9e
|______________________________________________________________________________
______________________________________________________________________________
| (079230:002016:03913) Concatenated-Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : DISCONNECT [45] Call ref : 80 9e
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________
______________________________________________________________________________
| (079230:002017:03841) 3841: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 4 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : RELEASE [4d] Call ref : 00 9e
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________
______________________________________________________________________________
| (079230:002018:03913) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 4 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 9e
|______________________________________________________________________________
ALE Application Partner Program – Inter-working report - Edition 1 - page 109/118
Copyright © ALE 2019
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 : info@newvoice.ch
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 mobicall@newvoice.ch New Voice (Austria) GmbH Paschinger Strasse 115 – 4060 Leonding (Austria) +43 732 890 120 +43 732 890 120 350 (Fax) mobicall@newvoice.at New Voice Systems GmbH Mörikestrasse 17 – 71636 Ludwigsburg (Deutschland) +49 7141 947 59 50 +49 7141 947 59 69 (Fax) mobicall@newvoice.de New Voice Systems GmbH Schlesische Straße 20 – 10997 Berlin (Deutschland) +49 7141 947 59 50 mobicall@newvoice.de
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 mobicall@newvoice.fr New Voice Suisse SA Chemin du Joran 8b – 1260 Nyon (Suisse) +41 58 750 11 22 mobicall@newvoice.fr
ALE Application Partner Program – Inter-working report - Edition 1 - page 110/118
Copyright © ALE 2019
17.2.3 Contact - Dubai
New Voice Systems DMCC Swiss ILC Services DMCCSwiss Tower, Office 3601JLT, Cluster YP. O. Box 309057Dubai, UAE mobicall@newvoice.ae
17.2.4 Contact - USA
New Voice Americas LTD 40 Exchange Place, Suite 1602 New York, NY 10005 mobicall@newvoiceamericas.com
17.2.5 Contact - Australia
New Voice Australia Ltd. Level 1 / 7 Clunies Ross Court, Eight Mile Plains 4113, Queensland +61 7 5667 2990 MobiCall@newvoice.com.au
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 111/118
Copyright © ALE 2019
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
17.3 Contact Information
Address : ST Gallerstrasse 8 8856 Lachen Main Phone : 0041 58 750 11 11 Main Fax : 0041 58 750 11 12
17.4 Contact Information
Address : ST Gallerstrasse 8 8856 Lachen Main Phone : 0041 58 750 11 11 Main Fax : 0041 58 750 11 12
ALE Application Partner Program – Inter-working report - Edition 1 - page 112/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 113/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 114/118
Copyright © ALE 2019
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 115/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 116/118
Copyright © ALE 2019
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.
ALE Application Partner Program – Inter-working report - Edition 1 - page 117/118
Copyright © ALE 2019
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: Ebg_Global_Supportcenter@al-enterprise.com
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
ALE Application Partner Program – Inter-working report - Edition 1 - page 118/118
Copyright © ALE 2019
END OF DOCUMENT
top related