2.5.5 Emergency Context Resolution with Internet Technologies (ecrit)

NOTE: This charter is a snapshot of the 78th IETF Meeting in Maastricht, Netherlands. It may now be out-of-date.

Last Modified: 2010-09-21

Chair(s):

Marc Linsner <marc.linsner@cisco.com>
Richard Barnes <rbarnes@bbn.com>

Real-time Applications and Infrastructure Area Director(s):

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.com>

* The Real-time Applications and Infrastructure Area Directors were seated during the IETF 65.

Real-time Applications and Infrastructure Area Advisor:

Robert Sparks <rjsparks@nostrum.com>

Secretary(ies):

Roger Marshall <rmarshall@telecomsys.com>

Mailing Lists:

General Discussion: ecrit@ietf.org
To Subscribe: https://www.ietf.org/mailman//listinfo/ecrit
Archive: http://www.ietf.org/mail-archive/web/ecrit/current/maillist.html

Description of Working Group:

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.  This 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.

Goals and Milestones:

Done  Informational RFC containing terminology definitions and the requirements
Done  An Informational document describing the threats and security considerations
Done  A Standards Track RFC describing how to identify a session set-up request is to an emergency response center
Done  A Standards Track RFC describing how to route an emergency call based on location information
Done  An Informational document describing the Mapping Protocol Architecture
Done  Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.
Done  Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC.
Done  Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document
Done  Submit
Oct 2010  Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC
Nov 2010  Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC
Mar 2011  Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC
Apr 2011  Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC
Dec 2011  Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC
Jan 2012  Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC
Mar 2012  Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC

Internet-Drafts:

  • draft-ietf-ecrit-phonebcp-15.txt
  • draft-ietf-ecrit-framework-11.txt
  • draft-ietf-ecrit-location-hiding-req-04.txt
  • draft-ietf-ecrit-lost-servicelistboundary-04.txt
  • draft-ietf-ecrit-rough-loc-03.txt
  • draft-ietf-ecrit-trustworthy-location-00.txt
  • draft-ietf-ecrit-unauthenticated-access-00.txt
  • draft-ietf-ecrit-data-only-ea-00.txt
  • draft-ietf-ecrit-additional-data-00.txt
  • draft-ietf-ecrit-psap-callback-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC5012 I Requirements for Emergency Context Resolution with Internet Technologies
    RFC5031 PS A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
    RFC5069 I Security Threats and Requirements for Emergency Call Marking and Mapping
    RFC5222 PS LoST: A Location-to-Service Translation Protocol
    RFC5223 PS Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)
    RFC5582 I Location-to-URL Mapping Architecture and Framework
    RFC5964 PS Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries

    Meeting Minutes


    Slides

    Chairs Presentation
    Framework and PhoneBCP Update - Brian Rosen
    Rough Location - Richard Barnes
    Additional Data - Brian Rosen
    PSAP Callback - Hannes Tschofenig
    Trustworthy Location - Bernard Aboba
    Civic Boundary - Martin Thomson
    SOS Parameter - Milan Patel
    802.23 Update - Geoff Thompson
    Data Only Emergency Calls - Hannes Tschofenig
    Unauthenticated emergency services - Gabor Bajko