|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: Apr 26, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
|
|
|
|
|
|
| The charter of the ECRIT working group
is reported below.
|
|
|
|
In a number of areas, the public switched telephone network (PSTN) has
been configured to recognize an explicitly specified number (commonly
one that is short and easily memorized) as a call for emergency
services. These numbers (e.g. 911, 112) relate to an emergency
service context and depend on a broad, regional configuration of
service contact methods and a geographically-constrained context of
service delivery. These calls are intended to be delivered to special
call centers equipped to manage emergency response. Successful
delivery of an emergency service call within those systems requires
both an association of the physical location of the originator with an
appropriate emergency service center and call routing to deliver the
call to the center.
Calls placed using Internet technologies do not use the same systems
to achieve those goals, and the common use of overlay networks and
tunnels (either as VPNs or for mobility) makes meeting them more
challenging. There are, however, Internet technologies available to
describe location and to manage call routing.
The Emergency Context Resolution with Internet Technologies (ECRIT)
working group
will
describe when these may be appropriate and how they may be used.
Explicitly outside the scope of this group is the question of
pre-emption or prioritization of emergency services traffic. This
group is considering emergency services calls which might be made by
any user of the Internet, as opposed to government or military
services that may impose very different authentication and routing
requirements.
The group will show how the availability of location data and call
routing information at different steps in session setup would enable
communication between a user and a relevant emergency response
center. Though the term "call routing" is used in this document, it
should be understood that some of the mechanisms which will be
described might be used to enable other types of media streams. Video
and text messaging, for example, might be used to request emergency
services.
While this group anticipates a close working relationship with groups
such as NENA and ETSI EMTEL, any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority. Further, it must be possible for multiple
delegations within a jurisdiction to be handled independently, as call
routing for specific emergency types may be independent.
This working group cares about privacy and security concerns, and will
address them within its documents.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
ecrit-lost-09
IESG Evaluation::
AD Follow up
Mar 28, 2008
(78 p.)
[pdf(2)]
[html]
|
T. Hardie
A. Newton
H. Schulzrinne
H. Tschofenig |
|
LoST: A Location-to-Service Translation Protocol |
This document describes an XML-based protocol for mapping service
identifiers and geodetic or civic location information to service
contact URIs. In particular, it can be used to determine the
location-appropriate Public Safety Answering Point (PSAP) for
emergency services.
This specification requests the registration of a new MIME type:
application/lost+xml.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## ECRITwg
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
barnes-ecrit-
auth-01
ID Exists
(Recently Expired)
Oct 22, 2007
(16 p.)
[pdf(2)]
[html]
|
R. Barnes
M. Lepinski |
|
Fraud mitigation for IP-based emergency calling |
|
The use of Internet technologies for emergency calling creates
opportunities for fraud, relative to traditional circuit-switched
emergency calling. This document describes the context for IP-based
emergency calling, and the types of fraud which are possible within
the system. A mitigation strategy for fraud against voice service
providers is described; techniques for detecting or preventing other
types of fraud will be incorporated in this document as they are
available.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
barnes-ecrit-
rough-loc-00
ID Exists
Feb 18, 2008
(12 p.)
[pdf(2)]
[html]
|
R. Barnes
M. Lepinski |
|
Using Imprecise Location for Emergency Context Resolution |
|
Emergency calling works best when precise location is available for
emergency call routing. However, there are situations in which a
location provider is unable or unwilling to provide precise location,
yet still wishes to enable subscribers to make emergency calls. This
document describes the level of location accuracy that providers must
provide to enable emergency call routing. In addition, we descibe
how emergency services and non-emergency services can be invoked by
an endpoint that does not have access to its precise location.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
| | |
forte-ecrit-
lost-extensions-00
ID Exists
Mar 19, 2008
(11 p.)
[pdf(2)]
[html]
|
A. Forte
H. Schulzrinne |
|
Location-to-Service Translation Protocol (LoST) Extensions |
|
An important class of location-based services answer the question
"What instances of this service are closest to me?" Examples include
finding restaurants, gas stations, stores, automated teller machines,
wireless access points (hot spots) or parking spaces. Currently, the
Location-to-Service Translation (LoST) protocol only supports mapping
locations to a single service based on service regions. This
document describes an extension that allows queries "N nearest" and
"within distance X".
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
schulzrinne-ecrit-
location-hiding-
req-01
ID Exists
Mar 29, 2008
(10 p.)
[pdf(2)]
[html]
|
H. Schulzrinne
L. Liess
H. Tschofenig
B. Stark
A. Kuett |
|
Location Hiding: Problem Statement and Requirements |
The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by
access networks to end points in order to determine the correct dial
string and information to route the call to a Public Safety Answering
Point (PSAP). For determining the PSAP Uniform Resource Identifier
(URI) the usage of the Location-to-Service Translation (LoST)
Protocol is envisioned.
This document explores the architectural impact for the IETF
emergency services architecture for situations where the Internet
Access Provider (IAP) and/or the Internet Service Provider (ISP) are
only willing to disclose limited or no location information.
This document provides a problem statement and lists requirements.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
schulzrinne-ecrit-
unauthenticated-
access-02
ID Exists
Feb 25, 2008
(20 p.)
[pdf(2)]
[html]
|
H. Schulzrinne
S. McCann
G. Bajko
H. Tschofenig |
|
Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices |
The IETF emergency services architecture assumes that access to a
network has already happened using the traditional network access
authentication procedures or that no authentication for network
access is needed (e.g., in case of public hotspots). Subsequent
protocol interactions, such as obtaining location information,
learning the address of the Public Safety Answering Point (PSAP) and
the emergency call itself are largely decoupled from the underlying
network access procedures.
There are, however, cases where a device is not in possession of
credentials for network access, does not have a VoIP provider, or
where the credentials are available but became invalid due to various
reasons (e.g., credit exhaustion, expired accounts, etc.).
This document provides a problem statement, introduces terminology
and describes an extension for the base IETF emergency services
architecture.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
