CLC/TS 50134-9:2018
(Main)Alarm systems - Social alarm systems - Part 9: IP Communications Protocol
Alarm systems - Social alarm systems - Part 9: IP Communications Protocol
This Technical Specification specifies a protocol for point-to-point transmission of alarms, faults, control signals and communications monitoring, between a Local Unit and Controller and an Alarm Receiving Centre using the Internet protocol (IP). The protocol is intended for use over any network that supports the transmission of IP data with sufficient quality of service to support VoIP or a separate voice channel. The Alarm Protocol is defined as an XML scheme including the alarm types, codes and necessary additional information. The alarm protocol is an application layer protocol using another Internet Protocol as a transport protocol to handle addressing and transport functions. The transport protocol initially defined in this Technical Specification is SIP (Session Initiation Protocol). The system performance characteristics for alarm transmission are specified in EN 50134-5. The performance characteristics of the Local Unit and Controller are expected to comply with the requirements of its associated alarm system standard and to apply for the transmission of social alarms. The protocols described in this standard are based on the SS 91100:2014 SCAIP standard [7] and defined to enable backwards compatibility with existing products based on the SCAIP standard.
Alarmanlagen - Personen-Hilferufanlagen - Teil 9: IP-Übertragungsprotokoll
Systèmes d'alarme - Systèmes d'alarme sociale - Partie 9: Protocole de communication IP
Alarmni sistemi - Socialni alarmni sistemi - 9. del: Komunikacijski protokoli IP
Ta tehnična specifikacija opredeljuje protokol za prenos alarmov, napak, krmilnih signalov in komunikacij od točke do točke med lokalno enoto in krmilnikom ter sprejemnim centrom za alarme prek internetnega protokola (IP). Protokol je namenjen za uporabo v vseh omrežjih, ki podpirajo prenos podatkov IP z ustrezno kakovostjo storitve za podporo protokola VoIP, ali prek ločenega glasovnega kanala.
Alarmni protokol je opredeljen kot shema XML, vključno z vrstami alarmov, kodami in potrebnimi dodatnimi informacijami.
Protokol alarma je protokol aplikacijske ravni, ki uporablja drug internetni protokol kot transportni protokol za obdelavo naslovov in izvajanje transportnih funkcij. Transportni protokol, prvotno opredeljen v tej tehnični specifikaciji, je SIP (protokol za začetek seje).
Lastnosti delovanja sistema za prenos alarma so navedene v standardu EN 50134-5. Pričakuje se, da bodo lastnosti delovanja lokalne enote in krmilnika izpolnjevale zahteve standarda za povezani alarmni sistem ter se uporabljale za prenos socialnih alarmov.
Protokoli, opisani v tem standardu, temeljijo na standardu SS 91100:2014 SCAIP [7] in so opredeljeni tako, da omogočajo povratno združljivost z obstoječimi izdelki na podlagi standarda SCAIP.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-november-2018
Alarmni sistemi - Socialni alarmni sistemi - 9. del: Komunikacijski protokoli IP
Alarm systems - Social alarm systems - Part 9: IP Communications Protocol
Systèmes d'alarme - Systèmes d'alarme sociale - Partie 9: Protocole de communication
IP
Ta slovenski standard je istoveten z: CLC/TS 50134-9:2018
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
TECHNICAL SPECIFICATION CLC/TS 50134-9
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
September 2018
ICS 13.320; 35.240.99
English Version
Alarm systems - Social alarm systems - Part 9: IP
Communications Protocol
Systèmes d'alarme - Systèmes d'alarme sociale - Partie 9: Alarmanlagen - Personen-Hilferufanlagen - Teil 9: IP
Protocole de communication IP Übertragungsprotokoll
This Technical Specification was approved by CENELEC on 2018-05-28.
CENELEC members are required to announce the existence of this TS in the same way as for an EN and to make the TS available promptly
at national level in an appropriate form. It is permissible to keep conflicting national standards in force.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden,
Switzerland, Turkey and the United Kingdom.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. CLC/TS 50134-9:2018 E
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 8
4 Social Alarm transmission network architecture . 9
4.1 General . 9
4.2 Alarm and status messages . 10
4.2.1 General . 10
4.2.2 Authentication . 10
4.2.3 Encryption . 10
4.3 Voice / multimedia over IP implementation . 10
4.4 Separate voice network . 10
5 Use Case 1: Event without voice- or multimedia communication . 11
5.1 General . 11
5.2 Event not treated by alarm receiver . 11
5.3 Event information update . 12
5.4 Aborting message session . 12
5.5 Heartbeat . 12
6 Use case 2: Event with voice or multimedia communication . 12
6.1 LUC initiated voice / multimedia channel . 12
6.2 ARC initiated voice / multimedia channel . 13
6.3 Voice session initiation decision . 14
7 Message format description . 14
7.1 General . 14
7.2 Interoperability Considerations with Version Numbering . 15
7.2.1 General . 15
7.2.2 Interoperability between LUC and ARC versions with the same major version number . 15
7.2.3 Interoperability between LUC and ARC with Different Major Version Numbers . 15
7.2.4 Interoperability with SCAIP . 15
7.3 Message Request. 15
7.4 Message Response . 19
8 DTMF code . 21
9 Sessions . 22
9.1 Message . 22
9.2 Voice or multimedia . 23
Annex A (normative) Codes for device types . 24
Annex B (normative) Codes for device components . 27
Annex C (normative) Status codes . 28
Annex D (normative) Location codes . 32
Annex E (normative) Info codes . 34
Annex F (informative) XML schema . 35
Annex G (informative) Rationale and roadmap . 40
Bibliography . 41
European foreword
This document (CLC/TS 50134-9:2018) has been prepared by CLC/TC 79 “Alarm systems”.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
EN 50134 consists of the following parts, under the general title Alarm systems — Social alarm systems:
— Part 1: System requirements;
— Part 2: Trigger devices;
Part 3: Local unit and controller;
—
— Part 5: Interconnections and communications;
Part 7: Application guidelines;
—
— Part 9: IP Communications Protocol [the present Technical Specification].
Annexes which are designated “informative” are given for information only.
Introduction
As telecommunication operators continue to migrate towards Next Generation Networks they are increasingly
converging voice traffic onto their IP infrastructures which may have an adverse impact on the reliability of in-
call, tone based protocols.
The impact differs per country but is rapidly increasing across Europe. In addition, cellular technology is
increasingly used next to broadband, cable and fibre solutions.
This Technical Specification defines the IP communications protocol for social alarms, optimized for stand-
alone usage. The majority of current social alarms usage is stand-alone within the home and not related to
other alarm systems. The combination of social alarms with other types of alarm systems is pending for a
future version of this standard.
1 Scope
This Technical Specification specifies a protocol for point-to-point transmission of alarms, faults, control
signals and communications monitoring, between a Local Unit and Controller and an Alarm Receiving Centre
using the Internet protocol (IP). The protocol is intended for use over any network that supports the
transmission of IP data with sufficient quality of service to support VoIP or a separate voice channel.
The Alarm Protocol is defined as an XML scheme including the alarm types, codes and necessary additional
information.
The alarm protocol is an application layer protocol using another Internet Protocol as a transport protocol to
handle addressing and transport functions. The transport protocol initially defined in this Technical
Specification is SIP (Session Initiation Protocol).
The system performance characteristics for alarm transmission are specified in EN 50134-5. The performance
characteristics of the Local Unit and Controller are expected to comply with the requirements of its associated
alarm system standard and to apply for the transmission of social alarms.
The protocols described in this standard are based on the SS 91100:2014 SCAIP standard [7] and defined to
enable backwards compatibility with existing products based on the SCAIP standard.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
EN 50134–1, Alarm systems — Social alarm systems — Part 1: System requirements
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and
times
ITU X509, Information technology — Open Systems Interconnection — The Directory: Public-key and attribute
certificate frameworks
RFC 2119, Key words for use in RFCs to Indicate Requirement Levels
RFC 2617, HTTP Authentication: Basic and Digest Access Authentication
[HTTP-AUTH]
RFC 3261, SIP: Session Initiation Protocol
[SIP]
RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP)
[SDP]
RFC 3428, Session Initiation Protocol (SIP) Extension for Instant Messaging
[SIP-IM]
RFC 3550, RTP: A Transport Protocol for Real-Time Applications
[RTP]
RFC 3711, The Secure Real-time Transport Protocol (SRTP)
[SRTP]
RFC 4568, Session Description Protocol (SDP) - Security Descriptions for Media Streams
[SDP-SEC]
RFC 4733, RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
[RTP-DTMF]
RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address
[ICE]
Translator (NAT) Traversal for Offer/Answer Protocols
RFC 5389, Session Traversal Utilities for NAT (STUN)
[STUN]
RFC 5764, Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the
[SRTP-DTLS]
Secure Real-time Transport Protocol (SRTP)
RFC 5766, Traversal Using Relays around NAT (TURN): Relay Extensions to Session
[TURN]
Traversal Utilities for NAT (STUN)
RFC 5768, Indicating Support for Interactive Connectivity Establishment (ICE) in the Session
[SIP-ICE]
Initiation Protocol (SIP)
RFC 5870, A Uniform Resource Identifier for Geographic Locations ('geo' URI)
RFC 6314, NAT Traversal Practices for Client-Server SIP
[SIP-NAT]
G.711 (11/88), Pulse code modulation (PCM) of voice frequencies
G.729 (06/12), Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction
(CS-ACELP)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
alarm receiver
alarm receiving centre
system part which provides facilities for communication with a number of controllers, and providing the alarm
receiving and information processing system as an interface to the alarm recipient
3.2
codec
device capable of encoding and decoding a digital data stream or signal
3.3
controller
alarm sender
interface between one or more Local Units and the alarm transmission system or alarm recipient
3.4
heartbeat
periodic event generated by hardware or software to indicate normal operation or to synchronize parts of a
system
3.5
in-band signalling
sending of control information within the same band or channel used for voice
3.6
interconnections
transmission system that provides the communication between trigger devices and local unit and controller
3.7
Local Unit and Controller
interface between the user and the controller which enables two-way speech
3.8
multimedia
media and content that use a combination of different content forms as text, audio, still images, animation,
video or interactivity
3.9
polling
sampling of a device to synchronize an activity
3.10
protocol
system of digital rules for message exchange within or between computers
3.11
social alarm system
telecare system
system providing 24 h facilities for alarm triggering, identification, signal transmission, alarm reception, two-
way speech communication, reassurance and assistance, for use by persons considered to be at risk
3.2 Abbreviations
Abbreviation Definition
ARC Alarm Receiving Centre
ASCII American Standard Code for Information Interchange
GGA Global Positioning System Fix Data
GPS Global Positioning System
GSM Global System for Mobile Communications
IP Internet Protocol
ISO International Organization for Standardization
LUC Local Unit and Controller
NMEA National Marine Electronics Association
POTS Plain Old Telephone Service
RFC Request for Comments
RTP Real-time Transport Protocol
SRTP Secure Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-PP Session Initiation Protocol, Peer-to-peer.
TLS Transport Layer Security
UCS Universal Character Set
UDP User Datagram Protocol
UTF UCS Transformation Formats
XML eXtensible Markup Language
URI Uniform Resource Identifier
Abbreviation Definition
SCAIP Social Care Alarm Internet Protocol
NGN Next Generation Network, a packet-based network able to provide services
including Telecommunication Services (such as voice) and able to make use of
multiple broadband, QoS-enabled transport technologies and in which service-
related functions are independent from underlying transport-related technologies.
4 Social Alarm transmission network architecture
4.1 General
The network architecture assumed by this standard as shown in Figure 1 is the existence of an all IP network
used for both the alarm communication protocol and voice, or the existence of an IP network for the alarm
communication protocol and a separate voice path outside of the IP network. The separate voice network can
be provided by cellular, analog POTS, broadband cable or VoIP operator infrastructure or a combination of
these.
In addition, in the second case the IP network may not be available while a voice session is in progress (e.g.
when 2G/2.5G modems are used in the LUC). Note that the second case is technology agnostic with respect
to the technology between LUC and voice network and the technology between ARC and voice network other
than the requirement that LUC and ARC are addressable via E.164 addressing.
Alarm Receiver
Alarm Sender
Alarm Alarm
protocol protocol
ARC
LUC IP network ARC
Voice over IP or
Voice over IP or
multimedia over IP
multimedia over IP
Alarm Receiver
Alarm Sender
Alarm Alarm
protocol protocol
ARC
LUC IP network ARC
voice
voice
Voice network
Figure 1 — Network architecture options
The protocol allows for a LUC to communicate to multiple ARCs. The mechanisms for ensuring availability of
an ARC and ensuring the LUC communicates to the correct ARC are not part of this standard, but could
consist of, for example, global load balancing, DNS, SIP proxies as part of the IP network, or use of the status
code in the message response indicating to the LUC to contact the another ARC.
In addition, there may be constraints in the IP network on the reachability of the LUC from the ARC due to the
presence of an on premise NAT router or firewall.
4.2 Alarm and status messages
4.2.1 General
Alarm and status messages shall use SIP messaging [SIP-IM].
4.2.2 Authentication
The application layer protocol shall support authentication on a per connection basis, at least the same level
of encryption and authentication mechanisms as SIP. Authentication shall be either user specific, where each
alarm sender logs in on a separate account or group specific, where all alarm senders log in on a common
account.
The authentication mechanism shall support HTTP Digest authentication.
Alarm receivers shall only accept and process messages from authenticated, and thus authorized, alarm
senders. The LUC shall authenticate towards the ARC using HTTP digest authentication.
4.2.3 Encryption
The LUC and the ARC shall support encryption.
The LUC shall not transmit personal or sensitive information over an unsecure connection without encryption.
The LUC and ARC shall support secure SIP over unsecure connections.
Personal and Sensitive data are only allowed to be transmitted over secure SIP.
The ARC shall present a valid ITU X509 certificate.
LUC shall verify the identity of the server certificate using a local Root CA Certificate
LUC to ARC SIP session shall be encrypted with TLS V1.2 or higher.
LUC to ARC SIP session shall use cryptographic algorithms AES-128 encryption minimum.
NOTE The management of certificates and the behaviour when certificates are invalid are out of scope of this
standard.
4.3 Voice / multimedia over IP implementation
Voice / multimedia channels over the IP network shall use SIP [SIP], SDP [SDP] and RTP [RTP].
LUC to ARC voice session shall support codec G.711 (a-law) or G.729 minimum.
The LUC shall support firewall traversal for VoIP and SIP using ICE [STUN], TURN [TURN], ICE for SIP [SIP-
ICE] and NAT traversal for SIP [SIP-NAT].
The LUC and the ARC shall support secure communication through the use of TLS. The need for a secure
connection is indicated by the use of a “sips:” URI as the destination for SIP. This also indicates the LUC and
ARC shall use SRTP [SRTP] for the voice channel. The LUC and ARC shall support [SDP-SEC] to negotiate a
secure voice channel.
LUC to ARC voice session shall be encrypted with SRTP using AES-128 encryption minimum
NOTE Whether secure communications need to be used is determined by the organization deploying the social
alarm system.
4.4 Separate voice network
When the voice channel is set up out of band using a different technology such as a cellular network, a Next
Generation Network (NGN) or an analog POTS, signalling and voice channel occur outside of the IP network.
The voice channel in this case shall be able to terminate on the POTS or a NGN with voice functionality
supporting E.164 phone numbers at the ARC, so that ARC does not need special connectivity other than to
the POTS or NGN. If the LUC supports call back, it shall be possible to call to the LUC using an E.164 phone
number, which may be over cellular, NGN or analog POTS.
Some functions should be controlled by single DTMF codes from the alarm receiver to enable a basic control
facility when the use of the voice channel results in loss of IP connectivity (e.g. 2G/2.5G cellular connectivity).
NOTE The alarm receiver of the Message Request might or might not be the same as the alarm receiver of the voice
or multimedia communication. The alarm sender might be able to connect to multiple alarm receivers for different events.
5 Use Case 1: Event without voice- or multimedia communication
5.1 General
Figure 2 shows the communication model with an alarm sender communicating over the IP network, e.g.
Internet, with TS50134 as protocol and an alarm receiver as endpoint. Messages are initiated from either an
end user, e.g. human, or a device and could have the function either as an alarm or a status message.
Figure 2 — Communication setup
Figure 3 shows the Alarm Protocol message exchange between the alarm sender and the alarm receiver.
Figure 3 — Message exchange
In this use case, the alarm sender sends a Message Request to the alarm receiver. Each Message Request
shall be acknowledged by the alarm receiver using a Message Response.
An event shall be considered successfully handled when the status number (status-number, see Table 2) of
the Message Response is set to 0.
5.2 Event not treated by alarm receiver
If the alarm receiver cannot determine the event as treated it shall return a Message Response with status
message (status-number, see Table 2) set to 4. This shall cause the alarm sender to resend the same
Message Request after 5 to 20 s.
This polling sequence shall continue for at least 3 min but shall not continue for more than 30 min.
5.3 Event information update
If the alarm sender has new information related to an event that is being processed the alarm sender shall
send a Message Request with message type (message-type, see Table 1) set to Information update and all
mandatory data elements set to the same value as the initial Message Request.
5.4 Aborting message session
The alarm sender shall stop resending the Message Request and continue with an alternative action if the
alarm sender has not received a Message Response with status number (status-number, see Table 2) set to 0
within a specified time. In such case it shall abort the alarm by sending a Message Request with message
type (message-type, see Table 1) set to Reset and reference (reference, see Table 1) set to the same value
as in the initial Message Request.
5.5 Heartbeat
The alarm sender shall poll the alarm receiver periodically with a Message Request having message type
(message-type, see Table 1) set to Heartbeat. The alarm receiver shall return a Message Response with
status number (status-number, see Table 2) set to 0.
The heartbeat period should be minimum 1 min and maximum 1 440 min.
6 Use case 2: Event with voice or multimedia communication
6.1 LUC initiated voice / multimedia channel
In this use case the alarm sender will send a Message Request as well as establish a voice or multimedia
session. The initial message exchange shall be handled the same way as in use case 1, shown in Figure 2. If
the alarm sender receives a Message Response with status number (status-number, see Table 2) set to 0 and
media reply (media-reply, see Table 2) set to 1 or more, it should initiate a voice or multimedia session. Upon
reception of the Message Response, the alarm sender should initiate the voice session within 60 s. Note that
call handling reply (callhandling-reply, see Table 2) shall be set to 61 or 62, or omitted.
Figure 4 shows a message exchange combined with the establishment of a LUC initiated voice or multimedia
communication.
Figure 4 — Message exchange with LUC initiated voice or multimedia communication
The voice or multimedia communication shall be initiated by the alarm sender. Once the communication is
established it may be modified or terminated by either the alarm sender or the alarm receiver.
6.2 ARC initiated voice / multimedia channel
In this use case the alarm sender will send a Message Request. As a result of this Message Request, the
ARC establishes a voice or multimedia session. The initial message exchange shall be handled the same way
as in use case 1, shown in Figure 3. In this exchange the LUC sends a Message Request with the call
handling parameter (call-handling, see Table 1) set to 1. ARC sends a Message Response with status number
(status-number, see Table 2) set to 0 and media reply (media-reply, see Table 2) set to 1 or more together
with the call handling reply information (callhandling-reply, see Table 2). The ARC subsequently initiates a
voice or multimedia session by sending a Session Setup Request. After sending of the Message Response,
the ARC should initiate the voice session within the specified time in the call handling reply information.
NOTE The decision for callback is described in 6.3.
Figure 5 shows the message exchange combined with the establishment of a voice or multimedia
communication.
Alarm Sender
Alarm Receiver
Message Request
Message Response
Alarm Sender
Alarm Receiver
Session Setup Request
Session Setup Response
Voice / Multimedia
Session Teardown Request
Session Teardown Response
- or -
Session Teardown Request
Session Teardown Response
Figure 5 — Message exchange with ARC initiated voice or multimedia communication
6.3 Voice session initiation decision
The LUC can request the set-up of a voice channel and can indicate it will call or ask for a call back. The
decision whether the voice session shall be initiated by the LUC or the ARC is taken by the ARC.
The LUC shall support calling in to the ARC. The LUC may support call backs.
The ARC shall support calling into the ARC. If the option exists for the ARC to establish a media channel to
the LUC, then the ARC may support calling out to the LUC.
The LUC and ARC shall support a media channel for voice for alarms where a voice channel is required. The
LUC and ARC may support other media than voice for multimedia over IP.
7 Message format description
7.1 General
TS50134 uses an XML format for the messages to represent the alarms and information codes. The
messages shall conform to a specific XML schema that should be used to verify the messages. The XML
schema is defined in Annex F.
Table 1 and Table 2 provides information about the data elements. The column “Length in characters”
provides the minimum and maximum number of characters of the text in a present data element. An asterisk
(*) indicates that the data element is mandatory. If a non-mandatory data element is excluded the receiver of
the Message Request or Message Response should treat it as defined for “omitted”.
For example, 0/2-4 without an asterisk (*) means that the data element may be omitted. When it is omitted it
shall have a length of 0 characters when it is present the length shall be 2, 3 or 4 characters.
As another example, 1-16 * means that data element is mandatory and shall have a length of 1 to 16
characters.
Content values enclosed between apostrophes shall be interpreted as the text string between them and shall
be coded in US-ASCII format if not otherwise stated.
EXAMPLE “1” means the US-ASCII value of the character 1.
7.2 Interoperability Considerations with Version Numbering
7.2.1 General
The version number is divided into two parts: major version number and minor version number. Versions with
only minor version number differences shall provide full backward compatibility. Versions with major version
number differences may not provide backward compatibility.
An ARC shall be able to support multiple major versions. A LUC may be able to support multiple major
versions.
7.2.2 Interoperability between LUC and ARC versions with the same major version number
The following rules shall be followed between LUC and ARC implementing different versions having the same
major version number but different minor version number.
When a LUC or ARC receives a message containing a particular minor version number it may respond with a
message containing a different minor version number. Unless a specific behaviour has been defined, the
receiving LUC or ARC shall ignore (i.e. consider omitted) all unrecognized fields and all recognized fields with
unrecognized values.
The receiving LUC or ARC shall respond to any unknown message type with status-number 99 and
status-text 'Error-unsupported-message'.
7.2.3 Interoperability between LUC and ARC with Different Major Version Numbers
The following rules shall be followed between LUC and ARC implementing versions with different major
version numbers.
The receiving LUC or ARC shall respond to any message having a not supported major version number with a
response with status-number 99, and status-text 'Error-unsupported-version'. The LUC or ARC shall
include the highest major version it supports that is below the not supported major version in the request in the
common-version field.
7.2.4 Interoperability with SCAIP
The protocol is defined to be interoperable with LUCs communicating SCAIP. For that reason a number of
attributes are marked as ‘deprecated’ but still allowed to be used in the protocol.
A LUC complying with this standard shall not create messages with deprecated attribute values unless
explicitly configured to do so. A LUC may provide the option to use the original SCAIP protocol.
A LUC complying with this standard shall interpret deprecated attribute values as defined in this standard.
An ARC complying with this standard shall interpret deprecated attribute values as defined in this standard.
If an ARC receives a message from the LUC containing the deprecated attribute value “gsm:”, the ARC shall
respond with the attribute value “gsm:” instead of “tel:”.
7.3 Message Request
Message Requests shall be encoded as a list of child XML tags and data elements contained in the root tag
message-request according to the template below. The template defines the XML encoding of all possible
data elements. The data elements are specified in Table 1.
reference
version
system-config
call-handling
message-type
heartbeat-options
controller-id
device-type
device-id
device-component
device-text
caller-id
status-code
status-text
priority
location-code
location-value
wgs-pos
time-stamp
gga-pos
location-text
info-code
info-text
additional-message
Table 1 — XML description for Message Requests
Data element name XML tag Description of content Length in
characters
message-request
Compound element for the Message Request
reference
The reference is used to match the Message Response 1–16 *
against the Message Request. The reference number shall
differ between subsequent Message Sessions.
The valid characters are: “A” through “Z”, “a” through “z”
and “0” through “9”.
version
Protocol version written as two digits, a period and two 0/5
digits.
EXAMPLE “01.23”
When omitted, “01.00” shall be assumed. The valid
characters are “0” through “9”
system-config
System configuration and information 0/1
Omitted or “0” = Local unit and controller
“1” = Grouped equipment with supervisor off duty
“2” = Grouped equipment with supervisor on duty
“3” = Grouped equipment with supervisor on duty acting as
an alarm receiver
call-handling Omitted or “0” = Normal outgoing call from the alarm 0/1
sender
“1” = Callback requested
Data element name XML tag Description of content Length in
characters
media-request
Omitted or “0” = Not defined, controlled by ARC 0/1–2
“1” = duplex voice call
“2” = simplex voice call, microphone (LUC speaker muted)
“3” = simplex voice call, speaker (LUC microphone muted)
“4” = No audio
message-type
Omitted or “ME” = Message 0/2
“RE” = Reset
“IN” = Information update within the Message Session
“PI” = Heartbeat
heartbeat-options
Omitted or “0” = Alarm sender cannot handle heartbeat 0/1–3
time adjustments from the alarm receiver.
“001” = Alarm sender can handle heartbeat time
adjustments from the alarm receiver.
Other = Unspecified for future use.
controller-id ID or account number for the controller that is calling. 1–32 *
The valid characters for this field are “0” through “9”.
device-type
The device type contains the specification of the device. 1–4 *
Valid device types are defined in Annex A.
device-id
The device ID is used to indicate the identity of a physical 0/1–16
device causing the event. This could for example the serial
number of a wireless device communicating through the
LUC. The device-id shall at least be unique within the
context of the controller-id. The valid characters for this
field are characters with US-ASCII encoding 32 through
126.
device-component
The device component is used to further indicate the 0/1–3
source of an event within a device.
Valid device component codes are defined in Annex B
device-text Device text description. 0/1–32
The text is only aimed to give additional information. Not to
contradict the device type or component. The valid
character set for this field is Unicode and UTF-8 encoding
shall be used
Data element name XML tag Description of content Length in
characters
caller-id
Media and telephone number (according to RFC3966) or 0/1–256
SIP URI (according to) of the alarm sender.
EXAMPLE 1 “tel:+46701445566”
One XML element shall be used for each available media.
Valid media types are:
• “no-voice:”
• “gsm:” deprecated, interpret as “tel:” E.164
number.
• “tel:” voice channel using E.164 number.
• “sip:” voice or multimedia non-secured
• “sips:” voice or multimedia secured
• “sip-pp”: deprecated, interpret as “sip:”
If the telephone number or SIP URI is unknown but can be
used for outgoing call the number should be omitted.
EXAMPLE 2 “sip:”
status-code
The status code is used to indicate the device state when 0/1–4
the message type is ME or IN
Valid status codes are defined in Annex C.
When the message type is ME or IN and this field is
omitted the default value of ‘Alarm (manual) 0010’ is
assumed.
For other message types this field has no meaning and
should be omitted without any default value being
assumed.
status-text
Status text description. 0/1–32
The text shall only give additional information and shall not
contradict with the status code. The valid character set for
this field is Unicode and UTF-8 encoding shall be used
Priority A single-digit priority field, to indicate that a priority over
0/1
other messages has been assigned to this event.
“0” = lowest priority
“1”-”8“= increasing priority
“9“ = highest priority
Omitted = “0”
location-code
Location information to allow detailed locations of events to 0/1–3
also refer to a location
be indicated. The location code can
value when needed.
Valid location codes are defined in Annex D.
location-value
Further specification of the location-code. 0/1–2
It can be either a simple numbering of a fixed location, an
area or a section number.
The valid characters for this field are characters with US-
ASCII encoding 32 through 126.
location-geo When a geographical coordinate or time stamp is added
the additional sub elements wgs-pos, time-stamp and
gga-pos below shall be used.
Data element name XML tag Description of content Length in
characters
wgs-pos
2D microformat of coordinate reference system WGS-84 0/1–23
expressed as latitude and longitude in degrees, extracted
from “geo” specified in RFC 5870.
EXAMPLE “59.336111,18.072778”
time-stamp Additional time stamp according to ISO 8601 with time 0/22
zone expressed as difference to UTC in hours.
Timestamp in Central European Time (CET):
YYYY-MM-DDThh:mm:ss+01
gga-pos
GPS, NMEA sentence GGA - essential fix data which 0/81
provide 3D location and accuracy data
$GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,
a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh
location-text
Text description of the location from where the Message 0/1–32
Request is raised.
EXAMPLE “Chapel”
The text is only aimed to give additional information. Not to
contradict the location code or value. The valid character
set for this field is Unicode and UTF-8 encoding shall be
used
info-code
Additional coded information about the event. 0/1–3
Valid info codes are defined in Annex E.
info-text Additional text information about the event 0/1–128
The text is only aimed to give additional information. Not to
contradict the info code. The valid character set for this
field is Unicode and UTF-8 encoding shall be used
additional-
Additional message shall be used if total length of the 0/1–4
message
message request exceeds 1300 bytes. If the Message
Request exceeds the limit it shall be sent as several
Message Requests marked with number of additional
message after present message
For example, if a Message Request is 1 700 bytes it shall
be divided in two messages whereof additional messages
is stated to 1 in the first message and 0 in the second (last)
message.
Omitted or “0” = Last message
“n” = Number of additional messages after present
message
The valid characters for this field are “0” through “9” .
7.4 Message Response
Message Responses shall be encoded as a list of child XML tags and data elements contained in the root tag
message-response according to the template below. The template defines the XML encoding of all possible
data elements. The data elements are specified in Table 2.
reference
status-number
status-text
common-version
media-reply
callhandling-reply
transferred-number
heartbeat-interval
Table 2 — XML description for Message response
Data element name XML Description of content Length in
Tag characters
message-
Compound element for the Message Response
response
reference
The reference number extracted from . 1–16 *
status-number
Alarm processing related status-numbers: 1–3 *
“0” = Ok. The alarm has been handled successfully. No
further actions is necessary
“4” = Hold. The alarm is being processed. Resend alarm for
updated status information.
“5” = Not treated or not distributed. The alarm couldn’t be
handled. Try next alarm action
“6” = Busy. The alarm couldn’t be handled right now. Try
again later or proceed with next alarm action.
Message related status-numbers:
“1” = message to long
“2” = invalid format
“3” = wrong data content
“7” = mandatory tag is missing
“10” = reference missing
“99” = undefined error
status-text
Text information about the status number. 0–128
The text is only aimed to give additional information. Not to
contradict the status number.
The valid characters for this field are characters with US-
ASCII encoding 32 through 126.
common-version
Protocol version to use that shall be equal or lower than the 0/5
version in the corresponding Message Request.
Omitted = Initial version, “01.00”
The valid characters are “0” through “9”.
media-reply
Omitted or “0” = no voice call 0/1–2
“1” = duplex voice call
“2” = simplex voice call, microphone (LUC speaker muted)
“3” = simplex voice call, speaker (LUC microphone muted)
Data element name XML Description of content Length in
Tag characters
callhandling-
Reply to Message Request call-handling, . 0/2
reply
“01”-”60” (nn) = Callback accepted, open auto-answer
channel for nn minutes. Requires that the alarm
receiver have registered the valid alarm sender
URI/Telephone number or a number or identity
contained in the caller-id,
Omitted or “61” = set-up a voice call to a pre-defined receiver
“62” = set-up a voice call to transferred URI/Telephone
number defined in transferred-number,
transferred-
Media and telephone number or SIP URI transferred for 0/1–256
number callhandling-reply, .
EXAMPLE: “tel:+46701445566”
One XML
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...