Introduction
ECRIT is abbreviation for Emergency Context Resolution with Internet Technologies.
ECRIT idea arose when IP-based telephony services become more popular. Users of these services (IP-based voice, text communication for hearing disabled users) expect to be able to place emergency calls.
Unfortunately, the existing mechanisms to support emergency calls that are known from public circuit-switched telephone network (PSTN) are not appropriate to handle IP-based voice, text and real-time multimedia communications.
Therfore, IETF has developed ECRIT - the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. Basic requirements are specified in draft-ietf-ecrit-requirements-13.
This page contains prototype implementation of ECRIT.
Schema 1. Main goals of implementation
ECRIT Framework
Supporting emergency calling requires cooperation by a number of elements. See draft-ietf-ecrit-framework-04 for more information.
Schema 2. Emergency Call Component Topology
- SOS Caller
- LIS
- SIP Proxy
- LoST Server
- ESRP
- PSAP
- Call taker
The term SOS caller or emergency caller refer to the person placing an emergency call or sending an emergency instant message (IM).
Location Information Server is an element that stores location information for retrieval by an authorized entity. For example HELD Server. See draft-ietf-geopriv-http-location-delivery-02 for more information.
SIP Proxy server with extension to convey geographic location information from one SIP entity to another SIP entity. Proxy servers make routing decisions based on the location of the SIP user agents.
The mapping server holds information about the location-to-PSAP URI mapping.
Emergency services routing proxy ia a proxy server that provides routing services for a group of PSAPs
Public Safety Answering Point is physical location where emergency calls are received under the responsibility of a public authority.
The person who answers an emergency call at the PSAP.
Scenarios and our solution
- Scenario 1 - UA recognition, UA resolution
- identify emergency call
- determine location information and adds Location Information to SIP Message
- determine correct PSAP
This is the most generic and most challenging scenario where the end host performs location based routing.
SIP UA:
- Scenario 2 - UA recognition, Proxy resolution
- identify emergency call
- adds Location Information to SIP Message
- determine correct PSAP
Scenario 2 is simpler than scenario 1. This scenario
already requires location information to be available to the end host.
SIP UA:
SIP Proxy:
- Scenario 3 - Proxy recognition, Proxy resolution
- recognize emergency call by dial-string number
- determine location information
- add Location-by-Reference to the SIP Message
- determine correct PSAP
This Scenario is the simplest one since the SIP Proxy Server only needs to understand location information. This scenario, however, places some assumptions about the placement of the SIP Proxy in the access network (it must be the nearest proxy).
SIP Proxy Server must deal with old user agents that do not have access to their own location data.
The Proxy must recognize a call as an emergency call that is not marked as emergency service URN.
SIP Proxy:
Schema 5. Scenario 3
Download latest versions
- LoST Server (source code available soon)
- LoST Client (source code available soon)
Daily snapshots
- LoST Server
- LoST Client
References
-
ECRIT Requirements
- Requirements for Emergency Context Resolution with Internet Technologies
- Security Threats and Requirements for Emergency Call Marking and Mapping
- Framework for Emergency Calling using Internet Multimedia
-
Emergency Service Identification
- A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
- URN Syntax
-
Location Conveyance
- Location Conveyance for the Session Initiation Protocol
- SIP: Session Initiation Protocol
- Geopriv Requirements
- A Presence-based GEOPRIV Location Object Format
-
Location Determination
- HTTP Enabled Location Delivery (HELD)
-
Mapping Protocol
- LoST: A Location-to-Service Translation Protocol
- Location-to-URL Mapping Architecture and Framework
Licensing
- LoST Server
- LoST Client
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA