Nurse Call Systems Integration with Wildix W-AIR - Admin Guide

This document describes how to configure the integration between W-AIR and any Nurse call system.

User Guide: Nurse Call Systems Integration with Wildix W-AIR - User Guide.

Created: June 2024

Updated: September 2025

Permalink: https://wildix.atlassian.net/wiki/x/UATOAQ

Introduction

The integration is used for the following in terms of nurse call systems:

Sending/ receiving SMS on W-AIR handsets
Sending alarms from W-AIR handsets to a Message server
Receiving alarms on W-AIR handsets from a Message server
Sending beacon information to a Message server

The integration is based on sending UDP packets and an acknowledge that the UDP packets are received.

Here is an example of sending beacon information from a beacon to a Message server through W-AIR handset and base station:

Here is an example of sending an alarm from a Message server to W-AIR handset:

Requirements

WMS 6.0X
W-AIR firmware version 730b200
Supported devices
- W-AIR base station: W-AIR Sync Plus, W-AIR Base Station
- W-AIR handset: W-AIR Med, W-AIR LifeSaver, W-AIR LifeSaver-EX

Message types and format

There are 5 different message types that can be used between a Message server and W-AIR base station:

XML tag	Description	Direction

XML tag	Description	Direction
Systeminfo	Messages that handle synchronization between W-AIR base station (BS) and a Message server (MS)	MS -> BS BS -> MS
Login	Messages that inform a Message server about location of W-AIR handset on a specific W-AIR base station	BS -> MS
Job	Alarms sent from a Message server to W-AIR base station and displayed on W-AIR handset under an alarm icon	MS -> BS
	SMS sent from a Message server to W-AIR base station and displayed under an SMS icon	MS -> BS
	SMS sent from W-AIR base station/ handset to another W-AIR base station/ handset via a Message server	BS -> MS
alarm	Alarms sent from W-AIR base station/ handset to a Message server	BS -> MS
beacon	Beacon information sent from W-AIR base station/ handset to a Message server	BS -> MS

Systeminfo and Login are only used when a Message server needs to send alarms/ SMS to W-AIR base station/ handset. For those Message servers that only receive beacons/ alarms from W-AIR base station/ handset, Systeminfo and Login procedures can be skipped.

Below there is a description of message formats between a Message server and W-AIR base station, followed by different message types.

XML interface: total length of XML packet is 4096 bytes. The interface follows the XML standards. Here are some basic rules:

All XML packets need to start with this XML header:
<?xml version="1.0" encoding="UTF-8"?>
No spaces in the < > elements, except for separating attributes. Examples:
<element> is valid < element > is not valid (spaces before and after “element”) <element > is not valid (space after “element”) <element attribute=”attribute1”> is valid <element attribute = “attribute1” > is not valid (spaces before and after = and after the second “) <element /> is not valid (space before /)
All elements have to be properly closed
UTF-8 is not supported, only the below extended ASCII table is supported:

XML schema description

This is XML schema description for the generic outgoing XML-based interface from a Message server. W-AIR base station should ignore unknown fields and packages received from a Message server.

<xs:element name="request" type="FrameDef" />
<xs:element name="response" type="FrameDef" />
<xs:complexType name="FrameDef">
<xs:attribute name="version" type="xs:string" /> 
<xs:attribute name="type" type="xs:string" /> 
<xs:sequence>
<xs:element name="externalid" type="xs:string" minOccurs="1"/> 
<xs:element name="status" type="xs:decimal" minOccurs="0"/> 
<xs:element name="statusinfo" type="xs:string" minOccurs="0"/> 
<xs:element name="systemdata" type="SystemDataDef" minOccurs="1"/> 
<xs:element name="jobdata" type="JobDataDef" minOccurs="0"/> 
<xs:element name="alarmdata" type="AlarmDataDef" minOccurs="0"/> 
<xs:element name="beacondata" type="BeaconDataDef" minOccurs="0"/> 
<xs:element name="rssidata" type="RssiDataDef" minOccurs="0"/> 
<xs:element name="logindata" type="LoginDataDef" minOccurs="0"/> 
<xs:element name="persondata" type="PersonDataDef" minOccurs="0"/> 
<xs:element name="senderdata" type="PersonDataDef" minOccurs="0"/>
</xs:sequence> 
</xs:complexType>

<xs:complexType name="SystemDataDef"> 
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="1"/> 
<xs:element name="datetime" type="xs:dateTime" minOccurs="1"/> 
<xs:element name="timestamp" type="xs:string" minOccurs="1"/> 
<xs:element name="status" type="xs:decimal" minOccurs="0"/> 
<xs:element name="statusinfo" type="xs:string" minOccurs="0"/>
</xs:sequence> 
</xs:complexType>

Explanation

This sequence MUST be present in all frames.

XML child "name" (SystemDataDef)
- System name, e.g., base name or messages server system name
XML child "datetime" (SystemDataDef)
- "2014-03-04T10:16:20" is local date and time for log-reason and can be individual formatted between the systems. Note: this timestamp is not used when presenting the alarm on W-AIR handset
XML child "timestamp" (SystemDataDef)
- UTC time in HEX format
XML child "status", "statusinfo" (SystemDataDef)
- "status" is the decimal value the following values
- "statusinfo" is the string values the following values
  - 0: System not running
  - 1: System running

<xs:complexType name="JobDataDef"> 
<xs:sequence>
<xs:element name="alarmnumber" type="xs:decimal" minOccurs="0"/> 
<xs:element name="referencenumber" type="xs:string" minOccurs="0"/> 
<xs:element name="priority" type="xs:decimal" minOccurs="0"/> 
<xs:element name="flash" type="xs:decimal" minOccurs="0"/> 
<xs:element name="rings" type="xs:decimal" minOccurs="0"/> 
<xs:element name="confirmationtype" type="xs:decimal" minOccurs="0"/> 
<xs:element name="messages" type="MessagesDef" minOccurs="0"/> 
<xs:element name="status" type="xs:decimal" minOccurs="0"/> 
<xs:element name="statusinfo" type="xs: string" minOccurs="0"/>
</xs:sequence> 
</xs:complexType>

Explanation

XML child "referencenumber" (JobDataDef)
- When the string "referencenumber" is present in the message from a Message server, the message is interpreted as an alarm on W-AIR handset
- If the "referencenumber" string is not present, the message is interpreted as an SMS. Further description is available in the chapters below
XML child "priority" (JobDataDef)
- It is possible to set an alarm with different priority. Further description is available in the chapters below
XML child "flash" (JobDataDef)
- Values 0 or 1, popup (like flash-SMS). Only valid for SMS functionality
XML child "rings" (JobDataDef)
- Values 0..9, number of ringtone alerts, where 0 means endless ringing. Only valid for Alarms
XML child "confirmationtype" (JobDataDef)
- Further description is available in the chapters below
XML child "messages" (JobDataDef)
- Only used in request and MUST always be present in frame type "job"
- See "Error! Reference source not found"
XML child "status", "statusinfo" (JobDataDef)
- "status" is the decimal value the following values
- "statusinfo" is the string values the following values
  - 0: No answer. Comment: User has not answered
  - 1: Answer. Comment: User has answered -> Delivered to W-AIR handset
  - 2: Busy. Comment: User was busy
  - 3: Error. Comment: User had an error
  - 4: Confirmed. Comment: User has confirmed the alarm positive
  - 5: Rejected. Comment: User has rejected the alarm
  - 6: Dialing. Comment: The remote system is dialing the number -> W-AIR base station is paging W-AIR handset
  - 10: Canceled. Comment: The remote system cancelled the job
  - 11: Not reached. Comment: User was not reachable
  - 21: Read. Comment: User read the job

<xs:complexType name="MessagesDef"> <xs:sequence>
<xs:element name="message1" type=" xs:string" minOccurs="0"/>
<xs:element name="message2" type=" xs:string" minOccurs="0"/> 
<xs:element name="messageuui" type=" xs:string" minOccurs="0"/>
</xs:sequence> 
</xs:complexType>

Explanation

XML child "messageuui" (MessageDef)
- "messageuui" is always the body text of the message

<xs:complexType name="AlarmDataDef"> 
<xs:sequence>
<xs:element name="type" type="xs:decimal" minOccurs="0"/> 
</xs:sequence>
</xs:complexType>

Explanation

XML child "type" (AlarmDataDef)
- Values 0..9
- 0: Man Down
- 1: No Movement
- 2: Running
- 3: Pull Cord
- 4: Red Key
- 5-9 Reserved

<xs:complexType name="BeaconDataDef"> 
<xs:sequence>
<xs:element name="type" type="xs:decimal" minOccurs="0"/>
<xs:element name="uuid" type="xs:string" minOccurs="0"/> 
</xs:sequence>
</xs:complexType>

Explanation

XML child "type" (BeaconDataDef)
- Values 0..1
- 0: entering proximity of the beacon
- 1: leaving proximity of the beacon
XML child "uuid" (BeaconDataDef)
- String holding the uuid of the beacon

<xs:complexType name="RssiDataDef"> 
<xs:sequence>
<xs:element name="rfpi" type="xs:string" minOccurs="1"/>
<xs:element name="rssi" type="xs:decimal" minOccurs="1"/> 
</xs:sequence>
</xs:complexType>

<xs:complexType name="LoginDataDef"> 
<xs:sequence>
<xs:element name="status" type="xs:decimal" minOccurs="0"/> 
</xs:sequence>
</xs:complexType>

Explanation

XML child "status" (LoginDataDef)
- "Status" is the decimal value the following values
  - 0: Logout
  - 1: Login

<xs:complexType name="PersonDataDef"> 
<xs:sequence>
<xs:element name="address" type="xs:string" minOccurs="0"/> 
<xs:element name="name" type="xs:string" minOccurs="0"/> 
<xs:element name="location" type="xs:string" minOccurs="0"/> 
<xs:element name="status" type="xs:decimal" minOccurs="0"/> 
<xs:element name="statusinfo" type="xs: string" minOccurs="0"/>
</xs:sequence> 
</xs:complexType>

Explanation

XML child "address" (PersonDataDef)
- Called party number (W-AIR handset SIP account)
- Sometimes, an address is not a SIP account, and in that case, the address will have a type "attribute" describing the nature of the address. This can be:
  - "IPEI" - This is used when the addressed device has no SIP account
  - "ALARM", "BEACON" and "CONFIG" - These can be used to distinguish if the message is addressed to a specific server, i.e. alarm server or beacon server
  - If no type "attribute" is present, the address should be interpreted as SIP account
XML child "name" (PersonDataDef)
- Called party display name (W-AIR handset SIP account display name)
XML child "location" (PersonDataDef)
- Can be W-AIR handset's current location if available (Base name). This is the name of W-AIR base station where W-AIR handset was registered first time after startup (SIP registration), so the location cannot be used, located where W-AIR handset actually has the DECT connection, when walking around between different base stations

Setup between W-AIR base station and a Message server

To configure Text messaging feature:

Access the Base Station's web interface and navigate to Management menu
Enable Text Messaging settings and specify the following parameters:
- Text Messaging & Alarm Server: IP or domain name of a Message server W-AIR base station is connected to
- Text Messaging Port: port used by a Message server and W-AIR base station
- Text Messaging Keep Alive: minutes between W-AIR base station sends a keep alive signal to a Message server
- Text messaging Response: if W-AIR base station does not receive a response from a Message server within 30 seconds, W-AIR base station informs W-AIR handset that the messages are not delivered after sending an SMS to a Message server
Click Save and Reboot to apply the changes

When W-AIR base station is configured, sync messages are sent followed by a sync message for each W-AIR handset registered on W-AIR base station.

Examples

<?xml version="1.0" encoding="UTF-8"?>
<request version="17.6.15.1526" type="systeminfo"> <externalid>0352675351</externalid>
<systemdata>
<name>SME VoIP</name>
<datetime>1970-01-01 00:00:09</datetime> <timestamp>00000009</timestamp>
<status>1</status>
<statusinfo>System running</statusinfo> </systemdata>
</request>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="1.0" type="systeminfo"> 
<systemdata>
<name>Micromedia-Alert</name> 
<datetime>2017-06-15T16:07:10</datetime> 
<timestamp>5942948e</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata> 
<externalid>0352675351</externalid> 
<status>1</status>
<statusinfo>Accepted by external system</statusinfo> 
</response>

<?xml version="1.0" encoding="UTF-8"?> 
<request version="17.6.15.1526" type="login"> 
<externalid>3294079664</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-15 09:07:51</datetime> 
<timestamp>594294b7</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<senderdata>
<address>991</address>
<name>991</name> 
<location>SME VoIP</location> 
</senderdata>
</request>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="1.0" type="login"> 
<systemdata> 
<name>Micromedia-Alert</name> 
<datetime>2017-06-15T16:07:54</datetime> 
<timestamp>594294ba</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata> 
<externalid>3294079664</externalid> 
<status>1</status>
<statusinfo>Accepted by external system</statusinfo> 
</response>

W-AIR base station and a Message server has now informed each other that they exist. Now they both can send a “keep alive” signal to each other, you can decide how often to send it in Management menu -> Text Messaging. “keep Alive” messages contain information about all registered W-AIR handsets. In case a Message server gets restarted, it can always request this information from W-AIR base station.

Examples of “keep alive” signals

The response signal always use the same external Id as the request

<?xml version="1.0" encoding="UTF-8"?>
<request version="18.2.21.1359" type="systeminfo"> 
<externalid>1528744172</externalid>
<systemdata>
<name>SME VoIP</name>
<datetime>2018-02-21 07:34:45</datetime> 
<timestamp>5a8d7575</timestamp>
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<senderdata>
<address>400</address>
<name></name>
<address>401</address>
<name>Bob Andersen</name>
<address>402</address>
<name>Hansi</name>
<address>403</address>
<name>George Lucas</name>
<address>404</address>
<name>Michael Jensen</name>
<address>406</address>
<name>406</name>
<address>407</address>
<name>Fenger</name>
<address>408</address>
<name>408</name>
<address>410</address>
<name>410</name>
</senderdata> </request>

Note that the name field can be empty.

<?xml version="1.0" encoding="UTF-8"?> 
<response version="1.0" type="systeminfo"> 
<systemdata>
<name>Micromedia-Alert</name> 
<datetime>2017-06-15T16:13:10</datetime> 
<timestamp>594295f6</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata> 
<externalid>5a8d7575</externalid> 
<status>1</status>
<statusinfo>Accepted by external system</statusinfo> 
</response>

<?xml version="1.0" encoding="UTF-8"?> 
<request version="1.0" type="systeminfo"> 
<systemdata> 
<name>Micromedia-Alert</name> 
<datetime>2017-06-15T16:17:59</datetime> 
<timestamp>59429717</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata> 
<externalid>mmi59427f9a-0</externalid> 
</request>

<?xml version="1.0" encoding="UTF-8"?>
<response version="18.2.21.1359" type="systeminfo"> 
<externalid> mmi59427f9a-0</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2018-02-21 07:39:03</datetime> 
<timestamp>5a8d7677</timestamp>
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<senderdata>
<address>400</address>
<name>hej400</name>
<address>401</address>
<name>Bob Andersen</name>
<address>402</address>
<name>Hansi</name>
<address>403</address>
<name>George Lucas</name>
<address>404</address>
<name>Michael Jensen</name>
<address>406</address>
<name>406</name>
<address>407</address>
<name>Fenger</name>
<address>408</address>
<name>408</name>
<address>410</address>
<name>410</name>
</senderdata> 
</response>

<?xml version="1.0" encoding="UTF-8"?> 
<request version="17.6.15.1526" type="login"> 
<externalid>0587227135</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-16 02:07:02</datetime> 
<timestamp>59438396</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<senderdata>
<address>991</address>
<name>991</name> 
<location>SME VoIP</location> 
</senderdata>
</request>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="1.0" type="login"> 
<systemdata> 
<name>Micromedia-Alert</name> 
<datetime>2017-06-16T09:07:05</datetime> 
<timestamp>59438399</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata> 
<externalid>0587227135</externalid> 
<status>1</status>
<statusinfo>Accepted by external system</statusinfo> 
</response>

Alarms

Sending alarms to W-AIR base station/ handset from a Message server

A Message server can send a UDP packet to W-AIR base station with XML information about the alarm. W-AIR base station sends the alarm to W-AIR handset and a response is sent back to a Message server.

Priority

It is possible to set an alarm with different priority, below are the different colors that are used on W-AIR handset depending on the priority.

1: red
2: red
3: red
4: Yellow
5: Yellow
6: Yellow
7: Green
8: Green
9: Green
All other values: Green

Confirmation type

XML child "confirmationtype" (JobDataDef):

0: No User confirmation needed
- W-AIR base station sends back a confirmation to a Message server that the message is received on W-AIR base station
1: User Received Job confirmation needed
- W-AIR base station sends back a confirmation to a Message server that the message is received on W-AIR base station
- W-AIR base station sends back a confirmation to a Message server that the message is received on W-AIR handset
2: User Confirm/ Reject Job confirmation needed
- W-AIR base station sends back a confirmation to a Message server that the message is received on W-AIR base station
- W-AIR base station sends back a confirmation to a Message server that the message is received on W-AIR handset
- W-AIR base station sends back a confirmation to a Message server if the user confirms /rejects the message

Reference number

Substituting an alarm

The reference number is unique number per alarm. When sending an alarm, the reference number always needs to be present, otherwise the message is interpreted as an SMS.

If an alarm is sent with the same referencenumber as a previous alarm that is NOT yet confirmed/ rejected (confirmationtype 2), the first alarm is deleted and only the new one is saved and displayed on W-AIR handset
If an alarm is sent with the same referencenumber as a previous alarm that is confirmed/ rejected, then both alarms are displayed
If an alarm is sent with the same referencenumber as a previous alarm that has confirmationtype 0 or 1, then both alarms are on W-AIR handset

Deleting an alarm

It is possible to delete an alarm that is NOT yet confirmed/ rejected on W-AIR handset.

Deletion is available for an alarm with confirmationtype 1 and 2
For deleting an existing alarm, the same reference number should be used and the status should be set to 10

Response handling

For confirmationtype 1 and 2, there is always a response sent to a Message server that W-AIR base station/ handset receives the messages:

A Message server needs both responses to be sure that the messages are received on W-AIR handset.
A Message server should not send a new message to the same W-AIR handset before both responses are received
In case a Message server does not receive the response from W-AIR handset, it should wait a minimum of 10 sec before trying to send a message again to the same W-AIR handset. This is needed so W-AIR base station has enough time to timeout the first messages

When using confirmationtype 0, a Message server doesn't know if the SMS/ alarm is lost from W-AIR base station to W-AIR handset. Here a Message server should always wait 10 sec between each message to the same W-AIR handset

Alarm with Callback number

When an alarm is sent from the Message Server to the W-AIR base station, it is treated as an alarm if the reference number is set.
If a callback number is also set:
- The W-AIR base station replaces the address field with this number
- The receiving extension sees the callback as the sender and can call it directly

In Settings → Alarms, you can turn on/off the automatic confirmation for the Callback option. There are two options:

Alarm in call
Callback confirm

Callback confirm

Enabled:
- When an alarm is answered using the callback option, an alarm confirmation message will be transmitted to the BS once the call has been connected with the extension specified in the callback number field.
Disabled:
- No alarm confirmation message will be sent when using the callback option for a received alarm message.

Note: This confirmation functionality is currently not compatible with voicemail options from the PBX, as this actually connects the call and there currently is no way to distinguish this from actually reaching the remote end on the handset. This results in alarms always being accepted if voicemail or other features that enable a connection are enabled.

The setting can be changed both on the PP, and by config file on the FP. The config file overrules the local setting. The config file has three options:

global on (the setting is hidden from the user)
global off (the setting is hidden from the user)
local on (the user can see and change the setting)

The Callback confirm setting is by default enabled (local on).

Examples

Below are examples of an alarm sent from a Message server with confirmationtype 2:

<?xml version="1.0" encoding="UTF-8"?> 
<request version="1.0" type="job"> 
<systemdata> 
<name>Micromedia-Alert</name> 
<datetime>2017-06-20T09:25:24</datetime> 
<timestamp>5948cde4</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<alarmnumber>5</alarmnumber> 
<referencenumber>5</referencenumber> 
<priority>1</priority>
<flash>0</flash>
<rings>0</rings> 
<confirmationtype>2</confirmationtype> <messages>
<message1></message1> <message2></message2> 
<messageuui>Alarm1 text</messageuui> </messages>
<status>0</status>
<statusinfo/>
</jobdata>
<persondata>
<address>991</address> 
<status>0</status>
<statusinfo/>
</persondata> <externalid>mmi5948c09b-5</externalid> </request>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="17.6.15.1526" type="job"> 
<externalid>mmi5948c09b-5</externalid> 
<status>1</status>
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 02:25:22</datetime> 
<timestamp>5948cde2</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<senderdata>
<address>991</address>
<name>991</name>
<location>SME VoIP</location>
</senderdata>
</response>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="17.6.15.1526" type="job"> 
<externalid>mmi5948c09b-5</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 02:25:23</datetime> 
<timestamp>5948cde3</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<priority>1</priority>
<messages>
<message1></message1>
<message2></message2> 
<messageuui></messageuui>
</messages>
<status>1</status>
<statusinfo></statusinfo>
</jobdata>
<senderdata>
<address>991</address>
<name>991</name>
<location>SME VoIP</location>
</senderdata>
</response>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="17.6.15.1526" type="job"> 
<externalid>mmi5948c09b-5</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 02:25:38</datetime> 
<timestamp>5948cdf2</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<priority>1</priority>
<messages>
<message1></message1>
<message2></message2> 
<messageuui></messageuui>
</messages>
<status>4</status>
<statusinfo></statusinfo>
</jobdata>
<senderdata>
<address>991</address>
<name>991</name>
<location>SME VoIP</location>
</senderdata>
</response>

Delete an alarm

<?xml version="1.0" encoding="UTF-8"?> 
<request version="1.0" type="job"> 
<systemdata> <name>Micromedia-Alert</name> 
<datetime>2017-06-20T09:58:25</datetime> 
<timestamp>5948d5a1</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<alarmnumber>5</alarmnumber> 
<referencenumber>5</referencenumber> 
<priority>1</priority>
<flash>0</flash>
<rings>0</rings> 
<confirmationtype>2</confirmationtype> 
<messages>
<message1></message1> 
<message2></message2> 
<messageuui>Alarm1 text</messageuui> 
</messages>
<status>0</status>
<statusinfo/>
</jobdata>
<persondata>
<address>991</address> 
<status>0</status>
<statusinfo/>
</persondata> <externalid>mmi5948c0a6-5</externalid> 
</request>

<?xml version="1.0" encoding="UTF-8"?> 
<request version="1.0" type="job"> 
<systemdata> 
<name>Micromedia-Alert</name> 
<datetime>2017-06-20T09:58:25</datetime> 
<timestamp>5948d5a1</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<alarmnumber>5</alarmnumber> 
<referencenumber>5</referencenumber> 
<priority>1</priority>
<flash>0</flash>
<rings>0</rings> 
<confirmationtype>2</confirmationtype> 
<messages>
<message1></message1> 
<message2></message2> 
<messageuui>Alarm1 text</messageuui> 
</messages>
<status>10</status>
<statusinfo/>
</jobdata>
<persondata>
<address>991</address> 
<status>0</status>
<statusinfo/>
</persondata> <externalid>mmi5948c0a6-5</externalid> 
</request>

Sending alarms from W-AIR base station/ handset to a Message server

W-AIR handset can be configured so it sends an alarm to a Message server for the following cases:

0: Man Down
1: No Movement
2: Running
3: Pull Cord
4: Red Key
5-9 Reserved

Furthermore, the latest available beacon data is added to the alarm messages. If no beacon UUID is available, the field is empty.

beacontype can be:

0: Unknown
1: iBeacon
2: AltBeacon
3: Eddystone

Data payload can be:

broadcastdata: HEX encoded raw beacon BLE broadcast payload. Maximum 64 characters (32 bytes).
bdaddr; HEX encoded permanent Bluetooth address for the received beacon. Maximum 12 characters (6 bytes)

Note: When an alarm is triggered on W-AIR handset, an ongoing call is terminated . This is done for all types, even though it is not necessary for “message types”.

Examples

Below are examples of XML messages when W-AIR handset sends an alarm for “Man Down”:

<?xml version="1.0" encoding="UTF-8"?> 
<request version="17.6.15.1526" type="alarm"> 
<externalid>0623295349</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 05:55:51</datetime> 
<timestamp>5948ff37</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<alarmdata>
 <type>0</type>
 </alarmdata>
 <beacondata>
 <beacontype>X</beacontype>
 <broadcastdata>54235663af54235663af54235663af54235663af54235663af54235663af</broadcastdata>
 <bdaddr>12AFCE98BEDE</bdaddr>
 </beacondata>
 <rssidata>
 <rfpi>116e61fc00</rfpi>
 <rssi>-28</rssi>
 <rfpi>116e61fc02</rfpi>
 <rssi>-36</rssi>
 </rssidata>
<senderdata> 
<address>991</address> 
<name>991</name> 
<location>SME VoIP</location> 
</senderdata>
</request>

<?xml version="1.0" encoding="UTF-8"?>
<response version="v.3.4.7.1047" type="alarm"> 
<externalid>0623295349</externalid>
<status>1</status>
<statusinfo>Accepted by New Voice XML outgoing interface</statusinfo> 
<systemdata>
<name>Mobicall</name>
<datetime>2017-06-20T12:55:55</datetime> <timestamp>5948ff3b</timestamp>
<status>1</status>
<statusinfo>System running</statusinfo>
</systemdata>
</response>

SMS

Sending SMS to W-AIR base station/ handset from a Message server

When sending an SMS from a Message server, the reference number string should be removed from the XML message. After this is done, messages are interpreted as an SMS instead of an alarm.

Note that:

It is not possible to send a delete request from a Message server to W-AIR base station/ handset for an SMS
It is not possible to substitute an SMS with a new SMS

Priority

An SMS can be sent to W-AIR handset with 2 priorities:

0: Normal
1: Urgent

Confirmation type

There are 2 confirmations types for SMS:

0: No User confirmation needed
- W-AIR base station sends back a confirmation to a Message server that the message is received on its side
- W-AIR base station sends back a confirmation to MS that the message is received on W-AIR handset side
1: User Confirm/Reject Job confirmation needed
- W-AIR base station sends back a confirmation to a Message server that the message is received on its side
- W-AIR base station sends back a confirmation to a Message server that the message is received on W-AIR handset side
- W-AIR base station send s back a confirmation to a Message server if user confirms/ rejects the message

Sending SMS from W-AIR base station/ handset to another W-AIR base station/ handset via a Message server

It is possible to send an SMS from one W-AIR handset to another W-AIR handset via a Message server that supports such functionality.

Priority

An SMS can be sent from W-AIR handset with 2 priorities:

0: Normal
1: Urgent

Examples

Below are examples of messages sent between W-AIR base station and a Message server.

<?xml version="1.0" encoding="UTF-8"?> 
<request version="17.6.15.1526" type="job"> 
<externalid>0649396368</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 04:12:16</datetime> 
<timestamp>5948e6f0</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<priority>1</priority>
<messages>
<message1></message1>
<message2></message2> 
<messageuui>Tw</messageuui>
</messages>
<status>0</status> 
<statusinfo></statusinfo>
</jobdata>
<senderdata>
<address>990</address>
<name>990</name>
<location>SME VoIP</location>
</senderdata>
<persondata>
<address>991</address>
</persondata>
</request>

<?xml version="1.0" encoding="UTF-8"?> 
<request version="17.6.15.1526" type="job"> 
<externalid>0649396368</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 04:12:16</datetime> 
<timestamp>5948e6f0</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<priority>1</priority>
<messages>
<message1></message1>
<message2></message2> 
<messageuui>Tw</messageuui>
</messages>
<status>0</status> 
<statusinfo></statusinfo>
</jobdata>
<senderdata>
<address>990</address>
<name>990</name>
<location>SME VoIP</location>
</senderdata>
<persondata>
<address>991</address>
</persondata>
</request>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="17.6.15.1526" type="job"> 
<externalid>0649396368</externalid> 
<status>1</status>
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 04:12:16</datetime> 
<timestamp>5948e6f0</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<senderdata>
<address>991</address>
<name>991</name>
<location>SME VoIP</location>
</senderdata>
<persondata>
<address>990</address>
<name>990</name>
<location>SME VoIP</location>
</persondata>
</response>

<?xml version="1.0" encoding="UTF-8"?> 
<response version="17.6.15.1526" type="job"> 
<externalid>0649396368</externalid> 
<systemdata>
<name>SME VoIP</name>
<datetime>2017-06-20 04:12:17</datetime> 
<timestamp>5948e6f1</timestamp> 
<status>1</status>
<statusinfo>System running</statusinfo> 
</systemdata>
<jobdata>
<priority>1</priority>
<messages>
<message1></message1>
<message2></message2> 
<messageuui></messageuui>
</messages>
<status>1</status>
<statusinfo></statusinfo>
</jobdata>
<senderdata>
<address>991</address>
<name>991</name>
<location>SME VoIP</location>
</senderdata>
<persondata>
<address>990</address>
<name>990</name>
<location>SME VoIP</location>
</persondata>
</response>

Beacon

Provisioning of beacon settings

W-AIR handset has 2 beacon modes:

Active: W-AIR handset acts as a beacon itself and transmits beacon information to the surroundings

Passive: W-AIR handset listens for beacon and reports the received beacons to a Message server

Parameters are stored on W-AIR base station and transferred to W-AIR handset, it is not possible to change them on W-AIR handset:

Name	Setting	Comment

Name	Setting	Comment
Handset mode (2 bit)	Receive beacon, transmit beacon, 1 selectable (drop down) receive and transmit beacon.