Open source strategy
One of the main objectives of EMYNOS is to produce some open-source working prototypes for next generation emergency services supporting unified communications through open standardized protocols and architectures (e.g. SIP, IMS). The EMYNOS open source strategy aims at enabling users/developers (industry, academia) to test their Next Generation emergency services solutions or to develop emergency applications on top of the EMYNOS framework.
Development on a solid basis
In developing the IP based emergency support, the EMYNOS consortium has chosen (and extended) well-known and stable software components among the ones already existing in the open source VoIP area. For instance, Linphone has been extended to initiate emergency calls, Kamailio which is a SIP proxy being used by a lot of VoIP providers, has been extended to behave as an ESRP, and Asterisk which is a well know PBX software has been extended to handle calls in the PSAP.
Interoperability and collaboration building
It is important to mention that most of the EMYNOS components being made open source were also tested successfully against industrial solutions. This was achieved through the participation of the EMYNOS consortium to the consecutive ETSI NG112 plugtests™ events in 2016 and 2017.
NG112 and NG911
Although the EMYNOS implementation has been targeting NG112 (Next Generation Emergency Services in Europe), this implementation can also be used in the context of NG911 (North America. For more details, we refer to the specifications documents EENA NG112 LTD and NENA i3 architecture.
Components
Linphone
The VoIP software Linphone is extended in the context of EMYNOS as follows:
- Initiating emergency calls with audio/ video/ real-time text
- Supporting emergency URNs
- Supporting several location configuration protocols (DHCP, HELD, LLDP-MED)
- Accepting emergency calls and visualizing location information
Related Links:
Emergency Services Routing Proxy (ESRP)
The EMYNOS ESRP is based on Kamailio SIP server. The code has been modified to handle big SIP packets in WebRTC calls that include additional information in the SDP (such as location or sensor information). Besides the main emergency call routing functionality, it also includes some additional functions that a BCF is responsible for in the ESInet (such as NAT handling or media encryption/decryption).
The RTP/SRTP media conversion is done by Sipwise NGCP rtpengine.
Related Links:
Interactive Voice Response system (IVR)
The IVR is used, for instance, in case all the call takers are busy. It is based on the Asterisk VoIP software. Here, the emergency call is forwarded to an IVR system where an audio file will be played and an Instant Message (with necessary information to be used by the caller) will be sent to the caller’s VoIP client.
Related Links:
Emergency Support for the IP Multimedia Subsystem (IMS)
The IP Multimedia Subsystem (or shortly IMS) is the key enabler in the mobile world for providing rich multimedia services to the end-users. It was standardized by the Third Generation Partnership Project (3GPP) (IMS Release 6) and uses the IETF standard (SIP) for session management. Although originally designed for mobile networks, IMS has been considered as a core component for NGN fixed networks. This vision is supported by the standardization bodies 3GPP, ETSI TISPAN and 3GPP2/LTE. The IMS architecture specifies three layers,
- Transport or Access layer: responsible for media processing and interaction with end systems
- Control (or IMS) layer: responsible for registration and SIP signaling routing
- Service or Application layer: hosting the call control applications and Value Added Services (VAS)
The objective of 3GPP was also to develop the necessary elements to enhance IMS with the support of emergency services while using as much as possible the protocols specified by IETF. The 3GPP work about emergency services was decomposed into several stages and described in corresponding documents: 3GPP TS 22.101 (for the requirements), 3GPP TS 23.167 (for the architecture), and 3GPP TS 24.229 (for the protocols and interfaces). For more details, we refer to these documents.
The architecture of the emergency services support for IMS is depicted in the figure above. Two main components were added to the IMS framework: (1) the Emergency CSCF (E-CSCF) which is the entity in charge of routing the emergency requests to the appropriate PSAPs, and the Location Retrieval Function (LRF) which is in charge of retrieving the location information of the user’s terminal that has initiated an IMS emergency session. For more details, we refer to the 3GPP document TS 23.167.
Related Links:
Reporting function
The reporting function will be used by the call taker to report about the emergency call.
To submit a report, the call taker needs to press on the “Report…” button. A window will pop up enabling the call taker to insert some information ( e.g, emergency description and emergency call type). When the call taker submits the report, a XML string will be generated based on Common Alerting Protocol (CAP) and stored in a database
Related Links:
False and hoax calls
Our false and hoax calls implementation is based on the IETF draft “draft-ietf-sipcore-callinfo-spam-00” for both caller and callee.
To be more precise, when a caller makes an emergency call, Linphone shows a pop-up window informing the caller that he is about to make an emergency call and whether he wants to proceed. If the caller press the button “YES”, the call will be stablished, if the caller press the button “NO”, the call will be dropped. If the caller does not react, the call will still be, automatically, established but after a delay of few seconds (e.g, 6 seconds). In this situation, an extra “Call-Info” header is added
To the SIP message showing that this call might be a false call:
Call-Info: <data:>;purpose=info;spam=33;reason="No confirmation"
When the callee receives a call with “spam header”, Linphone will create a report
based on the header data.
In addition to the “Call-Info”, the IMEI and the cell ID information are also sent when it is possible..
Related Links:
Sensor based emergency calls
The implementation we are describing here is based on Linphone Android with smartwatches (Tizen, Android Wear) as a caller, and the desktop Linphone as a call taker.
If you DO NOT have a smartwatch:
As long as you are not using a smartwatch, a dummy sensor data will be included in the SIP INVITE message if you make an emergency call.
If you have a smartwatch with heart rate monitor (HRM) sensor (Tizen/ Android Wear):
Please install the sample smartwatch App on your smartwatch, Android Wear version is with the Linphone-android project, and Tizen version in this git:
https://gitlab.fokus.fraunhofer.de/cki/HeartRateMonitor.git
The installation of the smartwatch App is not in the scope of this document. You should also ensure that the smartwatch is paired with the Android device, and the Android device has our extended Linphone installed.
Open the Linphone in the Android device, and the smartwatch app stated previously. If you are using the Tizen smartwatch, you will see a toast message “Accept connection”, this means that the connection between the two Apps are established.
TODO: Same thing for Android Wear Apps?
Both smartwatch Apps will send a message to the Android device to trigger an emergency call if the heartbeat rate measured is higher than the limit. For Tizen smartwatch App, please set a limit lower than normal heartbeat rate by using the slider in “Settings”. For Android Wear App, the limit is set to 50 (lower than normal rate). Please wear your watch or the App will remind you to wear/ not work.
Once the smartwatch App detects a heart rate higher than the limit, it will send a message encoded in JSON with the heart rate to Linphone in the Android device through Bluetooth or WLAN:
{"messageType": "emergency", "heartBeat": 150}
These messages will be transformed to a SensorML XML string by Linphone and included in the SIP INVITE message.
Call taker side:
When the call taker receives a SIP INVITE with SensorML payload in the body, Linphone will extract the sensor data (e.g. heart rate) from the payload and display them in a separate window sor data (e.g. heart rate) from the payload and display them in a separate window.
Mandate 493
In the EMYNOS project, we also consider the European Commission vision reflected by the mandate M493 in terms of emergency calls routing.
Our implementation includes ib and ic interfaces, which are defined in ETSI ES 203 178. These two interfaces allow VoIP providers to retrieve the URI of the Location
Server (LS) and the location of the emergency caller by contacting the LS discovery function and the LS services.
ib interface usage
“dns_resolver.py” implements the ib interface, which is based on RFC 7216. The following figure shows the flow chart:
Before running the script, please change the IP of the DNS servers by editing the r.nameservers variable of the script.
You may run the script by: ./dns_resolver.py [IP that requires reverse DNS lookup] The script will print out the URI of LS retrieved if succeed, or print the error code out.
ic interface usage
"held.py" implements the ic interface, which is based on HELD protocol (RFC 5985). You may run the script by: ./held.py [URI of LS]
The script will print the location response XML payload out if succeed.
Related Links:
Asterisk PBX
The EMYNOS project created a fork of the Digium Asterisk PBX and enhanced it with NG112 functionality. This includes: Support for service URNs (e.g. urn:service:sos), extraction and addition of body parts from/to messages from the dialplan, real-time text and pre-dial handler for the Queue application. However, all these features have been implemented for the PJSIP channel driver only.
The EMYNOS Asterisk fork is based on Asterisk 14.5.0.
Related Links:
Media Splitter (Legacy System Total Conversation Enabler)
This component enhances legacy PSAP systems with EMYNOS Next generation Emergency Communication functionalities such us Video, Real-Time-Text, Location (PIDF-LO) and Sensor Data.
This components consists of 2 basic modules.
Asterisk Media Splitter Plugin
This module is responsible for detecting the unsupported media, parsing the SDP response message from the legacy PSAP systems, and forwarding the unsupported media to the Media Server Module by rewriting the SDP response.
Media Server
This module receives and handles the unsupported media. Moreover, this module is in charge of making these media available to the legacy PSAP system using a user-friendly web interface.