This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ALE Application Partner Program – Inter-working report - Edition 1 - page 1/118
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
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
16.1 SITE SURVEY ...................................................................................................................................... 92
ALE Application Partner Program – Inter-working report - Edition 1 - page 6/118
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
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
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
1 Introduction This document is the result of the certification tests performed between the AAPP member’s application and Alcatel-Lucent Enterprise’s platform. It certifies proper inter-working with the AAPP member’s application. Information contained in this document is believed to be accurate and reliable at the time of printing. However, due to ongoing product improvements and revisions, ALE cannot guarantee accuracy of printed material after the date of certification nor can it accept responsibility for errors or omissions. Updates to this document can be viewed on:
- the Technical Support page of the Enterprise Business Portal (https://businessportal.alcatel-lucent.com) in the Application Partner Interworking Reports corner (restricted to Business Partners)
- the Application Partner portal (https://www.al-enterprise.com/en/partners/aapp) with free access.
2 Validity of the InterWorking Report This InterWorking report specifies the products and releases which have been certified. This inter-working report is valid unless specified until the AAPP member issues a new major release of such product (incorporating new features or functionalities), or until ALE issues a new major release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs. A new release is identified as following:
a “Major Release” is any x. enumerated release. Example Product 1.0 is a major product release.
a “Minor Release” is any x.y enumerated release. Example Product 1.1 is a minor product release
The validity of the InterWorking report can be extended to upper major releases, if for example the interface didn’t evolve, or to other products of the same family range. Please refer to the “IWR validity extension” chapter at the beginning of the report.
Note 1: The InterWorking report becomes automatically obsolete when the mentioned product releases are end of life.
Note 2: The renewal of the interoperability test (certification) is under the responsibility of the partner except if the certification fee is included in the program fee (e.g. “Application Partner” membership level) in this case ALE will schedule a new certification every two year
ALE Application Partner Program – Inter-working report - Edition 1 - page 9/118
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
- 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
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:[email protected];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
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
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
~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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
New Voice Systems DMCC Swiss ILC Services DMCCSwiss Tower, Office 3601JLT, Cluster YP. O. Box 309057Dubai, UAE [email protected]
17.2.4 Contact - USA
New Voice Americas LTD 40 Exchange Place, Suite 1602 New York, NY 10005 [email protected]
17.2.5 Contact - Australia
New Voice Australia Ltd. Level 1 / 7 Clunies Ross Court, Eight Mile Plains 4113, Queensland +61 7 5667 2990 [email protected]
17.2.6 General Information
The first level support is delegated to our resellers and installers. NewVoice, as a software editor only provides second level support. The 2nd level support is mainly for configuration and installation problems. These are easy problems than can be solved pretty quickly. There are two different support resolution methods: - phone assistance : adapted for simple and recurrent questions - on-line assistance with remote connexion : used as the highest level of support provided for incident resolution. Expert connect to the system to get more precise information (after a pre qualification) and to solve it
17.2.7 Severity Description and Response Times
Priority / Severity Description Response time
Low Trouble with installation, configuration
10min
Blocking Trouble with communication with other systems
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
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
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
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
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.
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