Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2010-10-19 Current Status: Active Working Group Chair(s): Marc Linsner Richard Barnes Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Secretary(ies): Roger Marshall 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 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC 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: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Jul 2010 Best Current Practice for Communications Services in support of Emergency Calling Oct 2006 Jul 2010 Framework for Emergency Calling using Internet Multimedia Jun 2008 Feb 2010 Location Hiding: Problem Statement and Requirements Oct 2009 Aug 2010 LoST Service List Boundary Extension Oct 2009 Aug 2010 Using Imprecise Location for Emergency Context Resolution Sep 2010 Oct 2010 Trustworthy Location Information Sep 2010 Sep 2010 Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices Sep 2010 Sep 2010 Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP) Sep 2010 Sep 2010 Additional Data related to an Emergency Call Sep 2010 Sep 2010 Public Safety Answering Point (PSAP) Callbacks Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC5012 I Jan 2008 Requirements for Emergency Context Resolution with Internet Technologies RFC5031 PS Jan 2008 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services RFC5069 I Jan 2008 Security Threats and Requirements for Emergency Call Marking and Mapping RFC5222 PS Aug 2008 LoST: A Location-to-Service Translation Protocol RFC5223 PS Aug 2008 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) RFC5582 I Sep 2009 Location-to-URL Mapping Architecture and Framework RFC5964 PS Aug 2010 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries