ALE Application Partner Program Inter-Working Report

Transcription

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

2 Certification overview Date of the certification September 2016 ALE International representative AAPP member representative Alcatel-Lucent Enterprise Communication Platform Alcatel-Lucent Enterprise Communication Platform release AAPP member application release Application Category Thierry Chevert Mahmut Sarac OmniPCX Enterprise R L b Alarm Server Respus Event monitoring & Alerting Author(s): Karthik Padmarajan Reviewer(s): Thierry Chevert, Krassimira Atanassov, Rachid Himmi Revision History Edition 1: creation of the document September 2016 Test results Passed Refused Postponed Passed with restrictions Refer to the section 6 for a summary of the test results. IWR validity extension None

3 AAPP Member Contact Information Contact name: Title: Address: Mr. Mahmut SARAC Product Manager Unterrietstrasse 2a Zip Code: 8152 City: Glattrbugg Country: Switzerland Phone: Fax: Mobile Phone: Web site: address:

4 TABLE OF CONTEN1 Introduction 6 2 VALIDITY OF THE INTERWORKING REPORT LIMITS OF THE TECHNICAL SUPPORT CASE OF ADDITIONAL THIRD PARTY APPLICATIONS APPLICATION INFORMATION TEST ENVIRONMENT PAGING & ALARMING SETUP HARDWARE CONFIGURATION SOFTWARE CONFIGURATION SUMMARY OF TEST RESULTS SUMMARY OF MAIN FUNCTIONS SUPPORTED Paging interface Alarming Interface Generic calls High availability configuration SUMMARY OF PROBLEMS SUMMARY OF LIMITATIONS NOTES, REMARKS TEST RESULT TEMPLATE PAGING - TEST RESULTS PAGING PROTOCOL OVERVIEW From the application to the OXE From the OXE to the application CONNECTIVITY AND SET-UP DEFENCE / RECOVERY DUPLICATION OF OMNIPCX ENTERPRISE LICENCE TEST (MANDATORY) PAGING ALARM SENDING TO DECT 8262/DECT 8242 /DECT PAGING ALARM SENDING ON OTHER TYPES OF SETS PAGING ALARM DELETION ALARM WHEN OUT OF RADIO COVERAGE / OUT OF SERVICE / OTHER ERRORS ALARMING, NOTIFICATION AND LOCATION SERVICES USING THE SIP TRUNK INTERFACE GENERIC SIP CALLS TESTS SIP Options SIP Authentication and Registrar SIP call set-up and call release SIP calls to various idle phones SIP call to various busy phones SIP calls to IBS-DECT sets out of radio range SIP calls to forwarded phone or Dect sets SIP calls to phone that is forwarded to voice mail SIP call to phone in immediate call forwarding to external destination SIP call to Out of Service phone Conference call with alarm server over SIP VOIP Link SIP call with Special Characters in CLI SIP ALARMING WITH 500 DECT, 8242DECT AND 8262DECT Test cases linked to Status message on 500DECT Test cases linked to Status message on 8242DECT Test cases linked to Status message on 8262DECT Test cases linked to Key events on 500DECT, 8242DECT and 8262DECT Test cases linked to Notification on 500 DECT with "Panic Red button" Test cases linked to Notification on 8242DECT... 41

5 9.2.7 Test cases linked to Notification on 8262 DECT EMBEDDED ALARMS TO 500DECT AND 8262DECT OVER SIP Test cases linked to "Man Down" or "Lost of verticality" on 500 DECT Test cases linked to "No Movement" on 500 DECT Test cases linked to "SHOCKS" detected on 500 DECT Test cases linked to "Man Down" or "Lost of verticality" on 8262DECT Test cases linked to "No Movement" on 8262DECT Test cases linked to "SHOCKS" detected on 8262DECT Test cases linked to "Pull Cord on 8262DECT TEST CASES LINKED TO IBS-DECT AND IP-DECT BASE STATION LOCALIZATION INCOMING ALARMS ON 500DECT, 8242DECT AND 8262DECT HIGH AVAILABILITY CONFIGURATIONS Spatial Redundancy Com Server OXE high availability Alarm server high availability OXE Passive Com Server Configuration TEST CASE OF COMBINED PAGING AND ALARMING APPENDIX A: AAPP MEMBER S APPLICATION DESCRIPTION AMX ALARM MANAGEMENT SERVER PLATFORMS ALARM CONTROL UNIT SWITZERLAND BASIC AMX FEATURES OPTIONAL AMX MODULES APPENDIX B: CONFIGURATION REQUIREMENTS OF THE AAPP MEMBER S APPLICATION APPENDIX C: ALCATEL-LUCENT ENTERPRISE COMMUNICATION PLATFORM: CONFIGURATION REQUIREMENTS PAGING CONFIGURATION ALARMING DESCRIPTION AND CONFIGURATION Site survey before deployment Equipment configuration PARAMETERS MANAGEMENT IN OMNIPCX ENTERPRISE COMSERVER Management of Automatic Call Routing to Main server Management of External SIP Gateway to Alarm server Management of Prefix to call alarm server Management of discriminator Linking ARS with External SIP Gw and protocol Management of External trunk group Internal SIP gateway DECT Creation /8262DECT Creation IBS-DECT MANAGEMENT OF IP-DECT CONFIGURATION OF ALARMING IN 500DECT CONFIGURATION OF ALARMING IN 8242DECT APPENDIX D: AAPP MEMBER S ESCALATION PROCESS APPENDIX E: AAPP PROGRAM ALCATEL-LUCENT APPLICATION PARTNER PROGRAM (AAPP) ENTERPRISE.ALCATEL-LUCENT.COM APPENDIX F: AAPP ESCALATION PROCESS INTRODUCTION ESCALATION IN CASE OF A VALID INTER-WORKING REPORT ESCALATION IN ALL OTHER CASES TECHNICAL SUPPORT ACCESS... 90

6 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 International cannot guarantee accuracy of printed material after the date of certification nor can it accept responsibility for errors or omissions. Updates to this document can be viewed on: the Technical Support page of the Enterprise Business Portal ( in the Application Partner Interworking Reports corner (restricted to Business Partners) the Application Partner portal ( with free access.

7 2 Validity of the InterWorking Report This InterWorking report specifies the products and releases which have been certified. This inter-working report is valid unless specified until the AAPP member issues a new major release of such product (incorporating new features or functionalities), or until ALE International issues a new major release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs. A new release is identified as following: a Major Release is any x. enumerated release. Example Product 1.0 is a major product release. a Minor Release is any x.y enumerated release. Example Product 1.1 is a minor product release The validity of the InterWorking report can be extended to upper major releases, if for example the interface didn t evolve, or to other products of the same family range. Please refer to the IWR validity extension chapter at the beginning of the report. Note: The InterWorking report becomes automatically obsolete when the mentioned product releases are end of life.

8 3 Limits of the Technical support For certified AAPP applications, Technical support will be provided within the scope of the features which have been certified in the InterWorking report. The scope is defined by the InterWorking report via the tests cases which have been performed, the conditions and the perimeter of the testing and identified limitations. All those details are documented in the IWR. The Business Partner must verify an InterWorking Report (see above Validity of the InterWorking Report) is valid and that the deployment follows all recommendations and prerequisites described in the InterWorking Report. The certification does not verify the functional achievement of the AAPP member s application as well as it does not cover load capacity checks, race conditions and generally speaking any real customer's site conditions. Any possible issue will require first to be addressed and analyzed by the AAPP member before being escalated to ALE International. Access to technical support by the Business Partner requires a valid ALE maintenance contract For details on all cases (3rd party application certified or not, request outside the scope of this IWR, etc.), please refer to Appendix F AAPP Escalation Process. 3.1 of additional Third party applications In case at a customer site an additional third party application NOT provided by ALE International is included in the solution between the certified Alcatel-Lucent Enterprise and AAPP member products such as a Session Border Controller or a firewall for example, ALE International will consider that situation as to that where no IWR exists. ALE International will handle this situation accordingly (for more details, please refer to Appendix F AAPP Escalation Process ).

9 4 Application information Application commercial name: AMX Alarm Management Server Application version: Alarm Server Respus Interface type: Paging Notification SIP Alarming, Notification and Location Services Brief application description: The Alarm Management Server (AMX) centralizes the processing of all events seized by external sources (building/process control, fire alarm, network management, nurse call, etc.) and notifies the alarm organization based on the respective scenario through different communication media like SMS, telephone call (VOIP), , SNMP traps, Paging or text messages on cordless handsets (DECT/WLAN) and smart phones by using data push notification services. More information is available in the appendix A.

10 5 Test environment 5.1 Paging & Alarming setup

11 5.2 Hardware configuration List main hardware equipments used for testing OmniPCX Entreprise: o CS (Call Server Processing Unit) 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 5.3 Software configuration List main softwares used for testing Alcatel-Lucent Enterprise Communication Platform: OmniPCXEnterprise R11.2 -L b Partner Application : Alarm Server Respus

12 6 Summary of test results 6.1 Summary of main functions supported Paging interface Feature Status Comment Connect the application to OmniPCX Enterprise Defence and recovery Duplication of OmniPCX Enterprise OmniPCX Enterprise licensing (Mandatory) Sending a normal alarm without acknowledgement by the user Sending a normal alarm with acknowledgement by the user Sending an urgent alarm without acknowledgement by the user Sending an urgent alarm with acknowledgement by the user Sending a normal discrete alarm Sending an urgent discrete alarm Deletion of an alarm (stop an alarm) Management Out of Coverage, Out of Service OK OK OK OK OK OK OK OK OK OK OK OK

13 6.1.2 Alarming Interface. Test related to alarm messages sent by DECT sets to External application over the SIP Trunk link. Features IBS-Dect IP-Dect Alarm and notification calls from Dect sets Alarm Server 500DECT 8242DECT 8262DECT 500DECT 8242DECT 8262DECT Live call OK OK OK OK OK OK Status call OK OK OK OK OK OK Notification call OK OK OK OK OK OK (Emergency button) Keys event call OK OK OK OK OK OK Man down call OK NA OK OK NA OK No movement call OK NA OK OK NA OK Shock call OK NA OK OK NA OK Pull Cord call NA NA OK NA NA OK (1): The shock is too sensitive with this version of handset software and hardware PP3, it will be improved in future release and/or hardware. Tests related to alarms sent by external application to DECT sets (Display text and special ringing) IBS-Dect IP-Dect Features Incoming Alarms from Alarm Server Dect sets 500DECT 8242DECT 8262DECT 500DECT 8242DECT 8262DECT Normal alarm (B~) OK OK OK OK OK OK Urgent alarm (C~) OK OK OK OK OK OK Very urgent alarm (D~) OK OK OK OK OK OK Hands free mode alarm (E~) OK OK OK OK OK OK For all the alarms no voice could be heard. This issue was because the testing was done on VPN setup.

14 6.1.3 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 Option Keep-Alive SIP Authentication & Registrar SIP call set-up and call release SIP calls to various le phones SIP call to various busy phones SIP calls to DECT sets out of radio range SIP calls to forwarded phone SIP calls to phone that is forwarded to voice mail SIP call to phone forwarded to external destination SIP call to Out of Service phone Multi-party Conference initiated by alarm server OK OK OK OK OK OK OK OK OK OK OK High availability configuration Features High availability Global status Spatial redundancy Com Server OXE Alarm Server High Availability Configuration Passive Com Server OXE OK NA OK

15 6.2 Summary of problems None 6.3 Summary of limitations During switch over in spatial setup there is delay of 5 to 10 seconds to connect to the standby server. But the alarming and paging functionality is working fine after the connection is established. There is no separate screen to show the type of incoming alarm that is triggered but the responses programmed are working. To differentiate the alarms we programmed different paging alarms in response to the type of incoming alarm triggered. 6.4 Notes, remarks The paging and alarming functionality has been combined by the application. The application has to programmed for the responses or alarms received from OXE. The application has a GUI interface to monitor the extensions and there is log for each extension that is added.

16 7 Test Result Template The results are presented as indicated in the example below: Test Test case 1 Action Expected result Test case 2 Action Expected result Test case 3 Action Expected result Test case 4 Action Expected result The application waits for PBX timer or phone set hangs up Relevant only if the CTI interface is a direct CSTA link No indication, no error message Test : a feature testing may comprise multiple steps depending on its complexity. Each step has to be completed successfully in order to conform to the test. Test : describes the test case with the detail of the main steps to be executed the and the expected result N/A: when checked, means the test case is not applicable in the scope of the application OK: when checked, means the test case performs as expected NOK: when checked, means the test case has failed. In that case, describe in the field Comment the reason for the failure and the reference number of the issue either on ALE International side or on AAPP member side Comment: to be filled in with any relevant comment. Mandatory in case a test has failed especially the reference number of the issue.

17 8 Paging - Test Results 8.1 Paging protocol overview From the application to the OXE The following fields and values are sent by the application to the OXE when sending an alarm: PagingRequestType ActiveAlarmCall value 0 - to send an alarm (text message) StopAlarmCall value 1 - to delete a previous alarms AskSotwarePack value 2 - to get current licenses ActiveSndCall value 3 - to send a discrete alarm (Same behavior as type 0) Paging Priority (A character in front of alarm name on display shows the type of alarm) NormalNoAck value 0 NormalAck value 1 UrgentNoAck value 2 UrgentAck value 3 NormalSndCall value 4 UrgentSndCall value From the OXE to the application In response to an alarm, the OXE sends back to the application one of below values: Paging State protocol values : Alert value 0 - the message is stored (ringing state) Process value 1 - the message is read or acknowledged OutOfCoverage value 2 - the destination is out of radio coverage OutOfservice value 4 - the destination is out of service Undefined value 5 - destination not declared as a NS device No Alert value 6 - the alarm cannot be deposit SPNoser value 7 - used for licenses validation Note: The AlertValue 0 is not sent back by OmniPCX Enterprise while receiving a discrete alarm (SndCall) normal or urgent to a compatible DECT set.

18 8.2 Connectivity and set-up These tests shall verify that the different components are properly connected and can communicate together (the external application and the Alcatel-Lucent Communication Platform are connected and the interface link is operational). Test CNX101 CNX102 Application connection Connect the application using IP link checks if there are incident messages using «incvisu» command Check using the http interface of the cstamono (port 2555) that the application is connected Check that only one CSTA link is used. Notification test Application send Normal alarm without ack to check the connection. Note: To monitor the socket connection, we use the web page (rerouted to or http The Web server must be activated in the CS of OmniPCX Enterprise (as root: netadmin -m / security / Web server). We see the Paging/CSTA V1 socket with the remote IP address of the remote application server (or VPN IP address) :

19 8.3 Defence / Recovery Check the behaviour of the application in case of link failure, etc. Test DEF101 DEF102 DEF103 DEF104 IP disconnection Disconnect the IP interface between the OXE and the application server. Verify that CSTA link is broken. Application send alarm Use the application to send an alarm Expected result should be error message and try to reconnect. Connect back the IP link Reconnect the IP interface, and check if the application is connected again. Check if the application reconnect the CSTA link. Check if the previously message is sent to the OXE. IP disconnection during an alarm Place an alarm but don t acknowledge the alarm Disconnect the IP interface and wait for the application detect the reconnection Read the alarm and acknowledge it Reconnect the IP interface and verify what happens on the application side Resend an alarm to the set and verify that the global chain (set + application) behaves as expected.

20 8.4 Duplication of OmniPCX Enterprise Check how the application reacts in case of OXE switchover etc. The test system is configured with spatial redundancy (duplicate call servers on two different IP subnetworks). Spatial redundancy can be configured in two ways: Alternate Proxy method : Specify both CS MAIN addresses as primary and alternative proxy respectively. Requires that on non availability of primary proxy, secondary proxy is used. Requires ability to accept incoming calls from secondary proxy. DNS method : Do not specify a proxy address, only SIP domain. Specify the CS MAIN adresses as first and second DNS server, respectively. Requires that (at least on non availability of current proxy) a new DNS request is issued for every message. Only MAIN CS will respond. Requires ability to accept incoming calls from secondary CS when it becomes new MAIN. For each configuration, check: Can new outgoing calls be made immediately after switchover? Are existing calls maintained after switchover? Are incoming calls (from new MAIN CS) accepted immediately after switchover? Can existing call be modified (transfer, hang-up, etc.) after switchover? Check if a session that has been started before switchover is maintained after switchover, i.e. does the new MAIN CS send session updates and is this accepted by the client? Test DUP101 DUP102 DUP103 Application connects to Main CS using IP@ Spatial redundancy, using Alternate Proxy method Switchover to standby call server. Verify that the application reconnect the CSTA link Verify that SIP calls are working. Application connects to Main CS via DNS query Spatial redundancy, using DNS method Switchover to standby call server. Verify that the application reconnect the CSTA link Verify that SIP calls are working. Application connects to PCS Switchover to Passive Call Server (IP link to main/stdby call servers down) Verify that the application reconnect the CSTA link Verify that the SIP calls are still working.

21 8.5 Licence test (Mandatory) This test shall verify that the application is working using the following rules: If the Notification Server lock on the OmniPCX Enterprise is strictly less than 50, the link is broken, and the application should stop working with PBX. If the Notification Server lock on the OmniPCX Enterprise is more or equal than 50, the application runs normally. Test LIC101 Try to connect application with wrong license in OmniPCX Enterprise Set a Notification Server lock of 10 or 0 in OmniPCX Enterprise Try connect the application Verify that application receive PagingState 7 (SPNoser value) Try to send an alarm from application. Verify that the alarm is not sent to OXE.

22 8.6 Paging Alarm sending to Dect 8262/Dect 8242 /DECT 8232 These tests shall verify that the application is able to send the different types of alarms. The DECT 8232/DECT 8242 / 4068 set is used for these tests. The DECT infrastructure used for these tests is TDM IBS and IP-Dect. The Dect sets behaviors are the same for both infrastructures. Test FTS101 Normal Alarm Without Ack sent to Dect Device Send a normal alarm without ack: Priority 0 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm read corresponds to the alarm sent FTS102 FTS103 FTS104 FTS105 FTS106 Normal Alarm Without Ack sent to Dect Device Send a normal alarm with ack: Priority 1 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm Without Ack sent to Dect Device Send a normal alarm without ack: Priority 2 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm With Ack sent to Dect Device Send an urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Normal SndCall alarm to Dect Device Send a normal discrete alarm: priority 4 Verify that application receives the PagingState 0 (AlertValue) Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent SndCall Alarm to Dect Device Send an urgent discrete alarm: priority 5 Verify that application receives the PagingState 0 (AlertValue) Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm The Alert Value (Paging State 0) is not sent back by OmniPCX Enterprise while receiving a Discrete alarm (SndCall) normal or urgent. The AlertValue (Paging State 0) is not sent back by OmniPCX Enterprise while receiving a Discrete alarm (SndCall) normal or urgent.

23 sent. FTS107 Urgent Alarm With Ack sent to Busy Dect Device Place a call to the Dect8242 set Send an urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone (behavior to be verified) Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. 8.7 Paging Alarm sending on other types of sets These tests shall verify the interoperability with other type of sets. Test FTA101 FTA101A FTA102 Urgent Alarm with Ack to Wlan8118/8128 Send a urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm With Ack sent to Busy Wlan8118/8128 Place a call to the WLAN 8118/8128 set Send an urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone (behavior to be verified) Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent SndCall Alarm to Wlan8118/8128 Send an urgent discrete alarm: priority 5 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent.

24 FTA103 FTA103A FTA104 FTA105 FTA106 FTA107 Urgent Alarm with Ack to IP Touch 4068 set Send a urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm With Ack sent to Busy IP Touch 4068 set Place a call to the IP Touch 4068 set Send an urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone (behavior to be verified) Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent SndCall Alarm to IP Touch 4068 set Send an urgent discrete alarm: priority 5 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm with Ack to OT Connection for 8082 set Send a urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent SndCall Alarm to OT Connection for 8082 set Send an urgent discrete alarm: priority 5 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm with Ack to DECT500 set (GAP+ mode) Configured in NOE mode. Specific version of the DECT 500

25 FTA108A FTA108 Send a urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent Alarm With Ack sent to Busy DECT500 set (GAP+ mode) Place a call to the DECT 500 set Send an urgent alarm with ack; Priority 3 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone (behavior to be verified) Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. Urgent SndCall Alarm to DECT500 set (GAP+ mode) Send an urgent discrete alarm: priority 5 Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is received on phone Read the alarm and acknowledge it. Verify that application receives the PagingState 1 (ProcessValue) Verify that the alarm read corresponds to the alarm sent. binary version for testing..

26 8.8 Paging Alarm deletion These tests shall verify that the application is able to delete alarms sent. Test DEL101 DEL102 Delete an Alarm from Application Use an existing alarm or send a new alarm with ack Delete this alarm by sending a PagingRequestType 1 (StopAlarmCall) Check it has been removed on the set. Delete an Alarm in case of multiple alarms Place several alarms with ack or without Delete one of these alarms alarm by sending a PagingRequestType 1 (StopAlarmCall) Check that this specific alarm has been removed on the set. 8.9 Alarm when Out of Radio Coverage / Out of Service / Other errors These tests shall verify the correct behaviour in specific situations like Out of Radio Coverage, Out of Service, wrong configuration, etc. Test OTH101 OTH102 OTH103 OTH104 Normal Alarm to IPTouch 4068 Out of Service Send a normal alarm to a IPT 4068 out of service Verify that application receives the PagingState 4 (OutOfServiceValue) Verify that the application displays that the phone is Out of Service Normal Alarm to DECT8242 Out of Service Send a normal alarm to Dect8242 out of service Verify that application receives the PagingState 4 (OutOfServiceValue) Verify that the application displays that the phone is Out of Service Normal Alarm to DECT8242 Out Of Coverage Send a normal alarm to Dect8242 out of coverage Verify that application receives the PagingState 2 (OutOfCoverageValue) Verify that the application displays that the phone is out of coverage Normal Alarm to DECT 500 Out of Service Send a normal alarm to Dect 500 out of service

27 Verify that application receives the PagingState 4 (OutOfServiceValue) Verify that the application displays that the phone is Out of Service OTH105 OTH106 OTH107 OTH108 OTH109 Normal Alarm to DECT 500 Out Of Coverage Send a normal alarm to Dect 500 out of coverage Verify that application receives the PagingState 2 (OutOfCoverageValue) Verify that the application displays that the phone is out of coverage Normal Alarm to WLAN 8118/8128 Out of Service Send a normal alarm to 8118/8128 out of service Verify that application receives the PagingState 4 (OutOfServiceValue) Verify that the application displays that the phone is Out of Service Normal Alarm to WLAN 8118/8128 Out Of Coverage Send a normal alarm to 8118/8128 out of coverage Verify that application receives the PagingState 2 (OutOfCoverageValue) Verify that the application displays that the phone is out of coverage Normal Alarm to phone number without NS / Paging right Send a normal alarm to a phone without Paging feature Verify that application receives the PagingState 5 (Undefined value) Verify that the application displays the error Normal alarm to phone with 8 messages already stored Send a normal alarm to a phone which alarm list is full Verify that application receives the PagingState 0 (AlertValue) Verify that the alarm is still received on phone (the oldest existing alarm is overwritten)

28 9 Alarming, Notification and Location services using the SIP trunk interface A SIP trunk is established between the OmniPCX Enterprise and Alarm Server Application (alarm server). OmniPCX Enterprise is a SIP client and Registrar in the Alarm Server application. Nota: TPA stands for Third party Application. 9.1 Generic SIP calls tests SIP Options 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). Test 1 2 SIP Options from Alarm Server to OXE Alarm Server sends a SIP options request Alcatel OmniPCX Enterprise responds with a proper answer 200-OK. SIP Options from OXE to Alarm Server Alcatel OmniPCX Enterprise sends a SIP options request Alarm Server responds with a proper answer 200-OK SIP Authentication and Registrar Test 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. 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 500 DECT, - Check that the call is accepted and Alarm Server sends the 200-OK. SIP Trunk without authentication: - Setup Alarm Server in trunk mode without authentication - Setup Alcatel-Lucent OXE accordingly(see Annex) - Generate a test call from Alarm Server Web interface. - Check that the call is accepted, that the phone rings and that a voice message is played.

29 Test 4 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 SIP call set-up and call release Test 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. 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. 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 SIP calls to various idle phones Test : Hand set is in idle mode To send a call, generate a test call from the TPA Accept the call Expected result: call is accepted by PBX phone, The text message of the Alarm Server application is used as caller identifier and displayed (16 characters), On answer a voice message is played by TPA then relase of the call. Test Call to 8128 MIPT in le state Test on Alcatel-Lucent Test defined above Expected result defined above Call to 8242 DECT in idle state Test on Alcatel-Lucent 8242 DECT 2 Test defined above Expected result defined above Call to 500 DECT in idle state Test on Alcatel-Lucent 500 DECT 3 Test defined above Expected result defined above

30 Test Call to 8262 DECT in idle state Test on Alcatel-Lucent Mobile 8232 DECT 4 Test defined above Expected result defined above Call to IPTouch serie 8 in idle state Test on Alcatel-Lucent IP Touch Test defined above Expected result defined above Call to T4034 UA set in idle state Test on Alcatel-Lucent IP Touch Test defined above Expected result defined above Call to Analog Phone in idle state Test on Alcatel-Lucent Analog phone 7 Test defined above Expected result defined above Call to MyIC Phone 8082 (SIP phone) Test on Alcatel-Lucent MyIC Phone 8 Test defined above Expected result defined above Call to Generic SIP Phone Test on Generic SIP phone 9 Test defined above Expected result defined above SIP call to various busy phones Test : 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: call is rejected if the phone is busy: The phone is set with "Camp On" protected in "Features" options TPA logs call is rejected Test Call to busy 8128 Mobile IPTouch Test on Alcatel-Lucent 8028 Test defined above Expected result defined above Call to busy 8242 IP-DECT (AGAP over SIP) Test on Alcatel-Lucent 8242 DECT Test defined above Expected result defined above Call to busy 500 IBS-DECT (GAP) Test on Alcatel-Lucent Mobile 500 Test defined above Expected result defined above Call to busy 8232 IP-DECT Test on Alcatel-Lucent Mobile 8232 Test defined above Expected result defined above Call to busy IPTouch serie 8 - T4068 Test on Alcatel-Lucent IP Touch 4068 Test defined above

31 Test Expected result defined above Call to busy 8242 IBS-DECT Test on Alcatel-Lucent 8242 DECT Test defined above Expected result defined above Call to busy 500 IP-DECT (SIP Extension) Test on Alcatel-Lucent Mobile 500 Test defined above Expected result defined above Call to busy IPTouch 4038 Test on Alcatel-Lucent IPT4038 Test defined above Expected result defined above Call to busy Analog Phone Test on Alcatel-Lucent Analog phone Test defined above Expected result defined above Call to busy MyIC Phone 8082 Test on 8232 My Ic Phone Test defined above Expected result defined above Call to busy SIP SoftPhone Test on Generic SIP phone Test defined above Expected result defined above SIP calls to IBS-DECT sets out of radio range Test : Hand Set is in idle mode, out of range To send a call, generate a test call from the TPA Expected result: call is rejected SIP Busy Here TPA logs the call rejection reason Test was done by powering-off the Dect handsets. Test Call to 8242 DECT-IBS out of radio range Test on Alcatel-Lucent 8242 DECT Test defined above Expected result defined above Call to 8242 DECT-IP out of radio range Test on Alcatel-Lucent 8232 DECT Test defined above Expected result defined above Call to DECT8242 out of radio range Test on Alcatel-Lucent DECT 8232 Test defined above Expected result defined above Call to 500 DECT-IBS out of radio range Test on Alcatel-Lucent Mobile 500DECT Test defined above Expected result defined above

32 9.1.7 SIP calls to forwarded phone or Dect sets Test : Phone is in idle state, call forwarding is configured, To send a call, generate a test call from the TPA, Accept the call on the forwarding destination Expected result: call is forwarded to the target phone the following behavior should be the same depending on the target phone state Test Call to IPTouch serie 8 Test on Alcatel-Lucent IPTouch Serie 8 Test defined above Expected result defined above Call to IBS-500 DECT in GAP Mode Test on Alcatel-Lucent IPTouch Serie 8 Test defined above Expected result defined above Call to 8242 DECT-IP Test on Alcatel-Lucent 8242 Test defined above Expected result defined above Prefixes are: 51 for immediate forward to destination / 41 for forward cancellation SIP calls to phone that is forwarded to voice mail Test : Phone is in idle mode, immediate call forwarding to voice mail is configured To send a call, generate a test call from the TPA accept the call on the forwarding destination; which is another terminal Expected result: call forwarded to the target voice mail the following behavior should the same depending on the target phone state Test 1 Call to IPTouch 4038 forwarded to Voice Mail Test on IPTouch 4038 Test defined above Expected result defined above

33 9.1.9 SIP call to phone in immediate call forwarding to external destination Test : 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 1 2 Call to 500 DECT forwarded to public external correspondant Test on Alcatel-Lucent 500 DECT fwd to external. Test defined above Expected result defined above Call to 4068 IPT forwarded to public external correspondant Test on Alcatel-Lucent IP Touch 4068 fwd to external. Test defined above Expected result defined above SIP call to Out of Service phone Test : 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 1 Call to IPTouch serie 8 Out of Service Test on Alcatel-Lucent IPTouch 4038 disconnected from system. Test defined above Expected result defined above

34 Conference call with alarm server over SIP VOIP Link 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. In our configuration based on Virtual Machine, the maximum number of DSP (RTP connections) is 16 that is to say 8 conferences. Test 1 2 Alarm server call multiple correspondant to make conferencing. TPA call users that can be directly connected to conference or have to press key 3 DTMF to be connected. Alarm server maintain the conference Release of one Phone SIP call with Special Characters in CLI Test : 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 Call to IPTouch 4068 (Digital NOE Extension) Alarm server sends Alarm toward the terminal. Check display of terminal. Call to MIPT 8128 (WLAN Extension) Alarm server sends Alarm toward the terminal. Check display of terminal. Call to MyIC Phone 8082 (SIP Extension) Alarm server sends Alarm toward the terminal. Check display of terminal. Call to 8242DECT Alarm server sends Alarm toward the terminal. Check display of terminal. Call to 8262DECT Alarm server sends Alarm toward the terminal. Check display of terminal.

35 9.2 SIP Alarming with 500 DECT, 8242DECT and 8262DECT Test cases linked to Live signal on 500DECT, 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 85 for SIP trunking ARS / 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. The alarm message is ended by 00 (digits 25 & 26) for live call state Test 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) is in idle mode The! icon will blink each time an alarm is sent. 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) is in idle mode The! icon will blink each time an alarm is sent. Live Signal on 500DECT Put the live delay value at 90 sec. Check that one prefix is defined in the configuration of HS. The alarm messages are sent to server with the defined delay 500 is in idle mode Display shows an outgoing call and dialled digits can be seen.

36 9.2.1 Test cases linked to Status message on 500DECT 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 Status message on 500DECT 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. Status message on 500DECT Out of charger Initiate the Status function in the MMI configuration menu. A status call is made when the handset is out of charger. Check the status in the message sent by PBX Check that the notification server receives and decodes the message correctly. Status message on 500DECT 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. Status message on 500DECT 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.

37 9.2.2 Test cases linked to Status message on 8242DECT 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 Status message on 8242DECT 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. Status message on 8242DECT Out of charger Initiate the Status function in the MMI configuration menu. A status call is made when the handset is out of charger. Check the status in the message sent by PBX Check that the notification server receives and decodes the message correctly. Status message on 8242DECT 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. Status message on 8242DECT 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.

38 9.2.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 Status message on 8262DECT 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. Status message on 8262DECT Out of charger Initiate the Status function in the MMI configuration menu. A status call is made when the handset is out of charger. Check the status in the message sent by PBX Check that the notification server receives and decodes the message correctly. 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. Status message on 8262DECT 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

39 Test charger. Check the status in the message sent by PBX Check that the notification server receives and decodes the message correctly Test cases linked to Key events on 500DECT, 8242DECT and 8262DECT Key events is used to signal the notification sever of the progress of tasks that are reported. 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 : 8242DECT & 8262DECT: 500 DECT: Key 0: 0 Key 1: 1 Key 1: 1 Key 2: 2 Key 2: 2 Key 3: 3 Key 3: 3 Key 4: 4 Key 4: 4 Key 5: 5 Key 5: 5 Key 6: 6 Key 6: 6 Key 7: 7 Key 7: 7 Key 8: 8 Test Key events on 500DECT in le state: Initiate the Event function in the MMI configuration menu. 500DECT is in idle mode Make a long press of one of the keys from 1 to 9 to trigger the function. Check that a call is performed, display shows the dialling mode. Check that the notification server receives and decodes the message correctly Key events on 8242DECT in le state: Initiate the Event function in the MMI configuration menu. 8242DECT is in idle mode Make a long press of one of the keys from 0 to 8 to trigger the function. Check that a call is performed,! Is blinking. Check that the notification server receives and decodes the message correctly. Key events on 8262DECT in le state: Initiate the Event function in the MMI configuration menu. 8262DECT is in idle mode Make a long press of one of the keys from 0 to 8 to trigger the function. Check that a call is performed, is blinking. Check that the notification server receives and decodes the message correctly. Nota: We found that sometimes there were no decoding of the Key pressed by the application when server received multiple frames from same terminal.

40 9.2.5 Test cases linked to Notification on 500 DECT with "Panic Red button" 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 Notification on 500DECT in le 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 on 500DECT 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. Notification on 500DECT 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. Notification on 500DECT in configuration state Activate the Notify function in the MMI configuration menu Define the first and second access prefix in the

41 Test 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 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 Notification on 8242DECT in le 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 on 8242DECT 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. Notification on 8242DECT in dialling state Activate the Notify function in the MMI configuration menu Define the first and second access prefix in the

42 Test 4 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. Notification on 8242DECT 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.

43 9.2.7 Test cases linked to Notification on 8262 DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage.this handset performs Notification call with a dedicated Alarm Key (Red button).the OK key is not used as the Key Events are not validated in the alarm settings. Test Notification on 8262DECT in le 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 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 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 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. Notification on 8262DECT in configuration state Activate the Notify function in the MMI configuration menu Define the first and second access prefix in the

44 Test 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.

45 9.3 Embedded Alarms to 500DECT and 8262DECT over SIP Test cases linked to "Man Down" or "Lost of verticality" on 500 DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call with a lost of verticality (Man Down) according 500DECT MMI configuration and timers. Test ManDown on 500DECT while in le 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. ManDown on 500DECT 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. ManDown on 500DECT 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. 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. Not triggered while in conversation

46 Test 4 Handset rings and need to acknowledge the alarm. While acknowledged, check that message is sent to server. ManDown on 500DECT 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. 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 Test cases linked to "No Movement" on 500 DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call with a "No Movement detection". The function and a timer is programmable in the set 500DECT; when no movement has been detected, the rings with specific rings (timer set to 10 secondes), then alarm is send to the server. Test 1 2 No Movement on 500DECT in le 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. No Movement on 500DECT 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. Not triggered while in conversation

47 Test 3 4 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. No Movement on 500DECT 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. No Movement on 500DECT 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. Not triggered while in conversation 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.

48 9.3.3 Test cases linked to "SHOCKS" detected on 500 DECT The notification function is used to signal emergency situations by end user. Emergency situations can be injury, physical or material damage. This handset performs Notification call when shocks are detected on handset. Generate a Schock then wait 5 seconds without movement, then the alarm is send Test SHOCK on 500DECT in le 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. SHOCK on 500DECT 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. SHOCK on 500DECT 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 the message. Handset rings and need to acknowledge the alarm. While acknowledged, check that message is sent to server.

49 Test 4 SHOCK on 500DECT 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 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 1 2 ManDown on 8262DECT while in le 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. 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

50 Test 3 4 message. Handset rings and need to acknowledge the alarm. While acknowledged, check that message is sent to server. 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. 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. 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. The alarm is not triggered when the user is in configuration page. Either the screen lock should happen or we should come out of the configuration menu. 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.

51 9.3.5 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 secondes), then alarm is send to the server. Test No Movement on 8262DECT in le 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. 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. 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.

52 Test 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. 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 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 With the current version (still Beta Test one) there is a weakness in the sensitivity the acceleration and alarm is triggered too quickly as for the real shock detection. Test 1 2 SHOCK on 8262DECT in le 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. 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.

53 Test 3 4 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. 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 the message. Handset rings and need to acknowledge the alarm. While acknowledged, check that message is sent to server. 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.

54 9.3.7 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 Pull cord on 8262DECT in le 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. 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. 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. 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. Pull cord on 8262DECT in configuration menu Configure "Pull Cord" function via MMI. OK

55 Test 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. 9.4 Test cases linked to IBS-DECT and IP-DECT base station localization 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). Test Localisation 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. Localisation of the 8262DECT in IP-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. Localisation 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. Localisation of the 500 DECT 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. Localisation of the 8242 DECT in IP-DECT areas: Generate an alarm

56 Test 6 Check that the alarm server decodes well the message with the RPN values and levels. Move the handset and check that values changes. Localisation of the 500 DECT in IP-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.

57 9.5 Incoming Alarms on 500DECT, 8242DECT and 8262DECT Warning: the 500 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 500 DECT and 8242 DECT Handsets: Normal Alarm: CNI1 identifier (B~) Urgent Alarm: CNI2 identifier (C~) Very Urgent Alarm: CNI3 identifier (D~) Hands-free mode Alarm (Loudspeaker & Microphone active): CNI4 identifier (E~) TPA stands for Third Party Application. HS stands for Hand-Set. Test Manual Incoming alarm Normal on 8262DECT 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. Manual Incoming alarm Normal on 500DECT 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. Manual Incoming alarm Normal on 8242DECT 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. Manual Incoming alarm Urgent on 500 DECT 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 Manual Incoming alarm Urgent on 8262DECT 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 Manual Incoming alarm Urgent on 500 DECT 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 Manual Incoming alarm Very Urgent on 500 DECT in silent mode - Set the handset in silent mode.

58 Test 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 Manual Incoming alarm Very Urgent on 500 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 Manual Incoming alarm Very Urgent on 8262DECT 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 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 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 Manual Incoming alarm Loudspeaker on 500 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 Manual Incoming alarm Loudspeaker on 500 DECT in vibrator mode - Set the handset in vibrator mode. Send a CNI signal having a format of E~xxx with the CS (Alarm server) - Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings 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 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)

59 Test Check that the handset will with normal alarm ring and volume as programmed in the Alarm settings Manual Incoming alarm Loudspeaker on 8262 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 Manual Incoming Normal alarm on 8262DECT with accented characters Send a CNI signal having a format of B~&#$ µàéèêçüöäß to the Handset. Check that the handset will ring with alarm ring and volume as programmed in the Alarm settings. Check display of accented characters. Manual Incoming Hands-free alarm on 8262DECT with accented characters Send a CNI signal having a format of E~&#$ µàéèêçüöäß to the Handset. Check that the handset will be in communication with Microphone not muted.. Check display of accented characters. Manual Incoming Normal alarm on 8242DECT with accented characters Send a CNI signal having a format of B~&#$ µàéèêçüöäß to the Handset. Check that the handset will ring with alarm ring and volume as programmed in the Alarm settings. Check display of accented characters. Manual Incoming Hands-free alarm on 8242DECT with accented characters Send a CNI signal having a format of E~&#$ µàéèêçüöäß to the Handset. Check that the handset will be in communication with Microphone not muted.. Check display of accented characters.

60 9.6 High availability configurations Spatial Redundancy Com Server OXE high availability The OmniPCX Enterprise is duplicated and the 2 Com Servers are in different IP subnets. There will be 2 Main IP addresses but only one is active according to status of Com Servers (Main or Stand-By). Test Manual switch-over to Main 2 Main Com Server is (CPU-A) Do manual switch-over with bascul or shutdown Main Com Server is now (CPU-B) Generate an alarm from 8242 and 500 DECT. Manual switch-over to Main 1 Main Com Server is (CPU-B) Do manual switch-over with bascul Main Com Server is now (CPU-A) Generate an alarm from 8242 DECT and 500. Switch-over due to Network failure Main Com Server is (CPU-A) Disconnect the LAN cable on CPU-A Main Com Server is now (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 Alarm server high availability There are 2 SIP External Gateways for each Alarm server (Main and Slave). The prefix to access server is calling an ARS route list that contain 2 routes (One to Main and second one to Slave). When the handset send an alarm to OXE using this prefix it will go to first route for Main then if down go to second route for Slave. Test 1 2 Alarm Server main and Alarm Server slave are actives the main Alarm Server is running and slave is also running and they are synchronized. Generate an alarm from 8262DECT and 8242DECT. Alarm Server main is down the main Alarm Server (SIP) has the services stopped, it won t answer and the slave is taking over the service for local Dect sets and remote. Generate an alarm from 8262DECT and 8242DECT.

61 Test 3 Alarm Server slave is down and Main is active Main server is back. the Supervisor Alarm Server has all services stopped and it won t answer and Master is taking over the service for remote Dect sets and local. Generate an alarm from 8262DECT and 8242DECT OXE Passive Com Server Configuration The Passive Com Server has the same database as the redundant Com Servers (CPU-A and CPU-B) as this is copied every day from Main CS to PCS. In case changes were done, do a pcscopy from Main CS to update the PCS with the latest database. The command pcsview will show you the PCS configurations currently existing in your system. DNS Delegation could not be used to reach the PCS as it do not have the internal name resolver activated. Into the Alarm servers, we added the Trunk to the PCS Test Switch-over to PCS Main Com Server is (CPU-A) and Stand-By Com Server is (CPU-B) PCS is and is inactive Shutdown both Com servers (shutdown h) All gateways and terminals will stop operation 1 Gateway rack 4 (GD board in IP Domain 11 secured) will reboot to connect to PCS. IBS connected on UA Board of this rack will run properely Generate an alarm from 500 DECT in the secured GD. Switch-back to CS Main PCS is and is active PCS Main is back and active All gateways and terminals will start working Gateway rack 4 (GD board in IP Domain 11 2 secured) will reboot to connect to CS Main. PCS will reboot Generate an alarm from any 8242 DECT/500 Check that it is sent by CS Main and alarm call from server goes also to CS Main and not anymore to PCS IP.

62 9.7 Test case of combined Paging and Alarming Test Trigger an ManDown alarm from the IBS DECT 8262/ Dect 500. Once the alarm is acknowledged by the server, the Alarm server immediately generates an Paging alarm to the IP touch extension for alerting them. Trigger an ManDown alarm from the IP DECT 8262/ Dect 500. Once the alarm is acknowledged by the server, the Alarm server immediately generates an Paging alarm to the IP touch extension for alerting them. Trigger an No movement alarm from the IP DECT 8262/ Dect 500. Once the alarm is acknowledged by the server, the Alarm server immediately generates an Paging alarm to the IP touch extension for alerting them. Trigger an No movement alarm from the IBS DECT 8262/ Dect 500. Once the alarm is acknowledged by the server, the Alarm server immediately generates an Paging alarm to the IP touch extension for alerting them. Trigger an Shock alarm from the IBS DECT 8262/ Dect 500. Once the alarm is acknowledged by the server, the Alarm server immediately generates an Paging alarm to the IP touch extension for alerting them. Trigger an Shock alarm from the IP DECT 8262/ Dect 500. Once the alarm is acknowledged by the server, the Alarm server immediately generates an Paging alarm to the IP touch extension for alerting them.

63 10 Appendix A: AAPP member s Application description 10.1 AMX Alarm Management Server Technical problems, equipment failures, fire or water damage and similar incidents can have costly consequences for a business. In order to guarantee the safety of individuals, groups and infrastructure within an organization, a rapid response to incidents is essential. The AMX (Alarm Management Server) developed by ATT guarantees that the right people can intervene to protect persons and infrastructure at the earliest possible time to minimize any adverse outcomes. If an emergency call, fire alarm or technical alarm is triggered, individuals or entire groups are notified within the shortest possible time frame, according to a pre-defined response scenario. Information about the event is forwarded as a voice message via a telephone call (TDM/VoIP) or in the form of text as an SNMP trap, SMS or pager message. Protection for Persons and Infrastructure Combined text and voice messages via cordless terminals (DECT, Wi-Fi) can be deployed for in-house alarms. This allows entire buildings or parts of buildings to be evacuated quickly and efficiently. These powerful options are especially applicable to the hotel industry, where the AMX, in conjunction with check-in systems, can transmit fully automated messages to the guest s room in their native language. Proven Hard and Software Concept The AMX Alarm Management Server is already in its eighth generation and supports Windows 7 (64 Bit) and Windows Server 2008 (64 Bit). All AMX modules were developed according to international best practice standards and programming conventions using the latest WEB technologies and methods (ASP.NET, MS SQL, AJAX). A combination of rigorously tested software and industry standard hardware components guarantees that the AMX is extremely reliable. ATT s consistent use of industry standards ensures simplified support, compatibility with third party systems and a high degree of investment protection.

64 Universal Deployment Using standardized interfaces, the AMX communicates with fire alarm systems, building and process control systems, check-in and check-out systems, and monitors network management and nurse call systems. In this way, the AMX offers central recording and processing for all occurring events. Due to its flexible configuration, the AMX can be easily tailored to monitor existing infrastructure and seamlessly integrate with customer processes and procedures. The AMX is very versatile: from pure text transmissions to initiating an emergency conference call between several parties and/or groups, simple serial alarms or several nested alarm levels, and all can be carried out simultaneously. Manual ad-hoc alarms (text / voice / TTS) are just as easy as the completely centralised and automated processing of all external alarms. Large Capacity and Constant Monitoring Up to 32,000 dry contacts can be monitored over serial interfaces and/or via a company s internal LAN. One single AMX Server can support up to 270 voice connections, with each individual outgoing line dynamically assigned to an alarm depending on its priority. AMX can not only continuously monitor connected third party systems, but also proprietary modules and messages from the operating system. Return on Investment Thanks to its compatibility with all modern PBXs, the AMX is easily deployed in any organisation and the investment in the AMX is secure, even if the PBX is upgraded or replaced. AMX-Integrations Alcatel 4400 / OXO / OXE, Siemens Hicom / HiPath, Nortel Meridian / CS1000, Avaya Aura & IP Office Communication Manager, Panasonic TDA / TDE/ NCP, Cisco CUCM, Aastra MD110 / MX-ONE/ A400 / A700/A5000/ OpenCom 1000 and Microsoft Lync Platforms

65 10.3 Alarm control unit Switzerland ATT Smartphone Alarm 10.4 Basic AMX Features Ready-to-operate, preconfigured alarm server PBX connection over BRI, PRI, VoIP (SIP), XML, CSTA Event message processing via telephone call and dry contacts (RS232/IP) Alarm notifications forwarded to an unlimited number of in-house and external subscribers Alarm text messages sent to cordless DECT and Wi-Fi terminals, or desk terminals with display* Call intrusion and disconnecting existing conversations are definable for each alarm* Overriding call deviation* Confirming alarms with an announcement or password, or via XML, CSTA, DECT SMS* Alarm notification ends if x of y people have already confirmed receipt. Delay issuing an alarm (e.g. filtering brief power interruptions) Call repetition and escalation process Reporting (PDF, CSV, EXCEL, RTF, TIFF, Web Archive) Ad hoc documentation of system configuration Holiday calendar Recording and alarm time windows are definable for each day and event Self-monitoring and self-diagnostics Automated and prescheduled test alarms Import/export tool to change subscriber and interface data SQL database Backup tool Log archiving tool per module Internal watchdog process, Event Watch (OS) Alarm prioritization (e.g. fire alarm before machine alarm)

66 GUI for administration and configuration changes (persons, groups, events, etc.) System access audit trail (data logging) 10.5 Optional AMX Modules Native mobile apps iphone, Android Interface controller Monitoring and controlling interface events Real-time monitoring Monitor all ongoing events Active personnel-monitoring Man-down alarm, emergency call, active callback, customer-specific Watchdog with contact output Hardware platform monitoring Watchdog with SMS or pager or output Monitoring licensed software modules, including hardware Alarm activation mask Customer-specific images, e.g. to simplify an evacuation scenario Protocol interfaces Via IP (SNMP, , OPC, MOD Bus) and RS 232 (ESPA 4.4.4, ESPA Plus, line protocol, SPS, etc.); please ask for the complete list, over 40 different interfaces available Duty plan, including absence calendar Annual plan Revision module Deactivate alarm groups and alarm points for a service window Linking primary and secondary alarms Alarm categories Hotel check-in, check-out Fidelio, Rebag, etc. Nurse call interface Tyco, Gets, Ackermann, etc. SMS (forwarding / monitoring) Alarm notification via SMS Acknowledgement with 2-way SMS Pager (internal or external) Alarm notification via pager (forwarding / monitoring) Alarm notification as an SNMP trap (forwarding / monitoring) Alarm notification as a SNMP trap Alarm via phone call REA (with or without ad hoc announcement), elevator alarm with voice transmission, emergency medical call, etc. Conference call Activating a conference call between persons targeted by an alarm (multi-conference calls) Multi-Tenant Architecture In-house departments or external companies with exclusive database access Sound Notification via audio systems Ad hoc alarms Recording or generating a new alarm message (text, voice, TTS), with password-protected activation and free selection of subscribers and their communication devices Event printer Continuous feed printer for issuing alarm logs Browser interface Intranet or Internet access Redundant architecture RAID I, dual-power supplies, redundant systems (master/slave or hot/hot) Specialized applications Additional customer-specific solutions can be developed

67 11 Appendix B: Configuration requirements of the AAPP member s application APPLICATION PAGING: (CSTAServer.exe -gui) To configure, click «Program» and «Configuration»

68 To make a quick check with any phone number, use Program and Test Buttons. Using ScenarioBuilder you can change Ip adresses of the PBX s.

69

70

71 12 Appendix C: Alcatel-Lucent Enterprise Communication Platform: configuration requirements 12.1 Paging Configuration The notification server parameter has to be enabled supported devices 12.2 Alarming description and configuration Site survey before deployment The site survey is an important step to provide a reliable geo-location service. This step is needed to gather the information about the power level received by the DECT on different places of the site where the solution is deployed. The Alarm server should not only be able to treat the information received by the DECT handsets but also to locate precisely where the alarm has been sent from. The main problem without site survey could be a building having antennas on more than one floor. Without this study it is nearly impossible to locate a DECT handset by pure theoretical calculation. For example if the emergency team is searching someone having a heart attack on the wrong floor, the loss of time is important. The DECT handsets have the possibility to send information by a long press of different button. One way to do a site survey would be to interpret that information and compute it in a system containing the plan of the rooms and floors. There could be many ways to do a site survey but it is a mandatory step to sell a reliable alarm server

72 Equipment configuration General configuration To configure the basic telephonic functions of the 500 DECT please read the following document: - For OmniPCX Enterprise systems: Alcatel-Lucent 500 DECT Handset Alcatel-Lucent OmniPCX Enterprise User manual In the Technical Knowledge Base accessible via the Business Portal at (the Technical Knowledge link is on the right of the window) - For OmniPCX Office systems: Alcatel-Lucent 500 DECT Handset, Alcatel-Lucent OmniPCX Office User manual. In the Technical Knowledge Base accessible via the Business Portal (the Technical Knowledge link is on the right of the window) - Quick guide : Alcatel-Lucent 500 DECT Handset, User Guide. In the Technical Knowledge Base accessible via the Business Portal (the Technical Knowledge link is on the right of the window) To have more information about how to use the 8242 DECT handset, please refer to the following document: - Alcatel-Lucent 8242 DECT Handset, Localisation and notification management, Configuration documentation In the Technical Knowledge Base accessible via the Business Portal (the Technical Knowledge link is on the right of the window) Geolocation and Notification configuration Information about how to configure the geolocation specific parameters of the 500 DECT is contained in the documents: - Alcatel-Lucent 500 DECT Handset User guide Localisation and notification management Configuration guide In the Technical Knowledge Base accessible via the Business Portal (the Technical Knowledge link is on the right of the window) - Alcatel-Lucent 500 DECT Handset User guide Localisation and notification management User guide In the Technical Knowledge Base accessible via the Business Portal (the Technical Knowledge link is on the right of the window) For the 8242 DECT parameters please refer to the document: - Alcatel-Lucent 8242 DECT Handset, Localisation and notification management, User documentation In the Technical Knowledge Base accessible via the Business Portal (the Technical Knowledge link is on the right of the window) OmniPCX Enterprise Licences In order to use the Geolocation and Notification server, licenses to use DECT handsets and SIP trunk are needed on the OmniPCX Enterprise. The licensing has to be done using ACTIS tool and can be checked using spadmin command For DECT feature: 29 DECT/PWT Engine = 1 41 DECT register Max number of Dect handset that can register to CallServer. 175 Mobile users Max number of Dect handsets declared in management 345 SIP extension users Number of IP-Dect handsets like 500Dect 371 IPDect users Max number of IP-Dect handsets For SIP Trunking: 185 SIP gateway = SIP network links Max number of links to SIP networks. 467 ARS Max routing list that can be managed

73 Phones configuration No specific configuration is needed for the 500 DECT. They are declared in the OmniPCX Enterprise as normal DECT phones as every Geolocation and Notification information is handled by the Alarm server OmniPCX Enterprise Trunks configuration In order to configure the trunks needed for the link between the Alarm server and the OmniPCX Enterprise please refer to the expert technical document. This document can be found in the Technical Knowledge Base.

74 12.3 Parameters management in OmniPCX Enterprise ComServer The parameters management could be done using a terminal connection (Console, telnet or ssh) with command mgr or a Graphical User Interface with OmniVista8770 Network Management Center. The following screenshots came from this GUI management center Management of Automatic Call Routing to Main server Created a ARS Route Number command table

75 Management of External SIP Gateway to Alarm server Management of Prefix to call alarm server

76 Management of discriminator Discriminator number according to entities Discriminator link to ARS route list

77 Linking ARS with External SIP Gw and protocol Management of External trunk group

78 Internal SIP gateway.

79 DECT Creation DECT 500 should be created as SIP extension (IPTouch /8262DECT Creation DECT 8242 or 8262 should be created as Gap IBS-DECT To check management of IBS AP into OXE CS.

80 12.4 Management of IP-DECT To configure DAPs we need the DAP configurator (Dect-IP WEB interface for DAP Manager) Below screenshot describes the configuration of the DAP.

81 Registered Base stations Subscriptions

82 12.5 Configuration of Alarming in 500DECT On 500DECT, go to "Menu", select "settings" go to "Security», then "alarm settings" Enter Alarm Password (default 0000) Go to "Alarm status" Select type of alarms you want to use Go back in previous menu Select «Alarm mode» Select "Enterprise" Go to "Alarm server", "Server 1", then enter in "Number" the Trunk group prefix you ll use. Go back to main menu; the phone is ready Configuration of Alarming in 8242DECT Press the Menu key

83

84 13 Appendix D: AAPP member s escalation process Hotline: hotline@attag.ch

85 14 Appendix E: AAPP program 14.1 Alcatel-Lucent Application Partner Program (AAPP) * The Application Partner Program is designed to support companies that develop communication applications for the enterprise market, based on Alcatel-Lucent Enterprise's product family. The program provides tools and support for developing, verifying and promoting compliant third-party applications that complement Alcatel-Lucent Enterprise's product family. ALE International facilitates market access for compliant applications. The Alcatel-Lucent Application Partner Program (AAPP) has two main objectives: Provide easy interfacing for Alcatel-Lucent Enterprise communication products: Alcatel-Lucent Enterprise's communication products for the enterprise market include infrastructure elements, platforms and software suites. To ensure easy integration, the AAPP provides a full array of standards-based application programming interfaces and fullydocumented proprietary interfaces. Together, these enable third-party applications to benefit fully from the potential of Alcatel-Lucent Enterprise products. Test and verify a comprehensive range of third-party applications: to ensure proper inter-working, ALE International tests and verifies selected third-party applications that complement its portfolio. Successful candidates, which are labelled Alcatel- Lucent Enterprise Compliant Application, come from every area of voice and data communications. The Alcatel-Lucent Application Partner Program covers a wide array of third-party applications/products designed for voice-centric and data-centric networks in the enterprise market, including terminals, communication applications, mobility, management, security, etc.

86 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 Enterprise.Alcatel-Lucent.com You can access the Alcatel-Lucent Enterprise website at this URL:

87 15 Appendix F: AAPP Escalation process 15.1 Introduction The purpose of this appendix is to define the escalation process to be applied by the ALE International Business Partners when facing a problem with the solution certified in this document. The principle is that ALE International Technical Support will be subject to the existence of a valid InterWorking Report within the limits defined in the chapter Limits of the Technical support. In case technical support is granted, ALE International and the Application Partner, are engaged as following: (*) The Application Partner Business Partner can be a Third-Party company or the ALE International Business Partner itself