Requirements for Emergency Context Resolution with Internet Technologies
RFC 5012
|
| Document |
Type |
|
RFC - Informational
(January 2008; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5012 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jon Peterson
|
|
Send notices to |
|
(None)
|
Network Working Group H. Schulzrinne
Request for Comments: 5012 Columbia U.
Category: Informational R. Marshall, Ed.
TCS
January 2008
Requirements for Emergency Context Resolution with
Internet Technologies
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document defines terminology and enumerates requirements for 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Emergency Services . . . . . . . . . . . . . . . . . . . . 3
3.2. Service Providers . . . . . . . . . . . . . . . . . . . . 3
3.3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Call Routing Entities . . . . . . . . . . . . . . . . . . 5
3.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Identifiers, Numbers, and Dial Strings . . . . . . . . . . 6
3.7. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10
6. Identifying the Caller's Location . . . . . . . . . . . . . . 12
7. Emergency Service Identifier . . . . . . . . . . . . . . . . . 14
8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Schulzrinne & Marshall Informational [Page 1]
RFC 5012 ECRIT Requirements January 2008
1. Introduction
Users of both voice-centric (telephone-like) and non-voice services,
such as text communication for hearing-disabled users (see [RFC3351]
and [toip]), expect to be able to initiate a request for help in case
of an emergency.
Unfortunately, the existing mechanisms to support emergency calls
that have evolved within the public circuit-switched telephone
network (PSTN) are not appropriate to handle evolving IP-based voice,
text, and real-time multimedia communications. This document
outlines the key requirements that IP-based end systems and network
elements, such as Session Initiation Protocol (SIP) [RFC3261]
proxies, need to satisfy in order to provide emergency call services,
which at a minimum, offer the same functionality as existing PSTN
services, with the additional overall goal of making emergency
calling more robust, less costly to implement, and multimedia-
capable.
This document only focuses on end-to-end IP-based calls, i.e., where
the emergency call originates from an IP end system and terminates in
an IP-capable public safety answering point (PSAP), conveyed entirely
over an IP network.
We first define terminology in Section 3. The document then outlines
various functional issues that relate to placing an IP-based
emergency call, including a description of baseline requirements
(Section 5), identification of the emergency caller's location
(Section 6), use of a service identifier to declare a call to be an
emergency call (Section 7), and finally, the mapping function
required to route the call to the appropriate PSAP (Section 8).
The primary purpose of the mapping protocol is to produce a PSAP URI
drawn from a preferred set of URI schemes such as SIP or SIPS URIs,
based on both location information [RFC4119] and a service identifier
in order to facilitate the IP end-to-end completion of an emergency
call.
Aside from obtaining a PSAP URI, the mapping protocol is useful for
obtaining other information as well. There may be a case, for
example, where an appropriate emergency number is not known, only the
location. The mapping protocol can then return a geographically
Show full document text