Emergency Context Resolution with Internet Technologies (ecrit)

Last Modified: 2009-06-19

Additional information is available at tools.ietf.org/wg/ecrit

Chair(s):

  • Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

  • Marc Linsner <marc.linsner@cisco.com>

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

  • Robert Sparks <rjsparks@nostrum.com>
  • Cullen Jennings <fluffy@cisco.com>

    Real-time Applications and Infrastructure Area Advisor:

  • Cullen Jennings <fluffy@cisco.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
    Feb 2008  An Informational document describing the ECRIT Framework
    Feb 2008  A BCP document describing the emergency call support for devices
    Done  Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.
    Jul 2009  Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC.
    Jul 2009  Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC.
    Jul 2009  Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document

    Internet-Drafts:

    Location-to-URL Mapping Architecture and Framework (43307 bytes)
    Best Current Practice for Communications Services in support of Emergency Calling (107039 bytes)
    Framework for Emergency Calling using Internet Multimedia (96656 bytes)
    Location Hiding: Problem Statement and Requirements (18556 bytes)
    Specifying Holes in LoST Service Boundaries (24050 bytes)
    Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements (37850 bytes)
    IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications (20512 bytes)

    Request For Comments:

    Requirements for Emergency Context Resolution with Internet Technologies (RFC 5012) (54599 bytes)
    A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (RFC 5031) (32960 bytes)
    Security Threats and Requirements for Emergency Call Marking and Mapping (RFC 5069) (26230 bytes)
    LoST: A Location-to-Service Translation Protocol (RFC 5222) (123252 bytes)
    Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) (RFC 5223) (14936 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.