1. Emergency Context Resolution with Internet Technologies BOF (ecrit) Jon Peterson, Hannes Tschofenig BOF Chairs

2. Administrative Stuff Blue Sheets! Minute Taker? Jabber Scribe?

3. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: — the IETF plenary session, — any IETF working group or portion thereof, — the IESG or any member thereof on behalf of the IESG, — the IAB or any member thereof on behalf of the IAB, — any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, — the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details.

4. Agenda Jon Peterson/Hannes Tschofenig (15 min) Problem space in North America and Current Architecture Brian Rosen (10 min) Requirements and Architecture for Emergency Calls Henning Schulzrinne (20 min) http://www.cs.columbia.edu/sip/draft/emergency-req/ draft-schulzrinne-sipping-emergency-req-01.html http://www.cs.columbia.edu/sip/draft/emergency-arch/ draft-schulzrinne-sipping-emergency-arch-02.html Design considerations for ECRIT Ted Hardie (20 min) Open Discussions All (15 min)

5. Deliverables Informational RFC containing terminology definitions and the requirements. [April 2005] An Informational document describing the threats and security considerations. [May 2005] A BCP or Standards Track RFC describing how to identify a session set-up request is to an emergency response center. [August 2005] A BCP or Standards Track RFC describing how to route an emergency call based on location information. [August 2005] A BCP describing strategies for associating session originators with physical locations. [August 2005] A BCP describing how to discover the media stream types an ERC supports. [November 2005]

6. Charter (1/3) 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.

7. Charter (2/3) 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 PSTN or 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, 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.

8. Charter (3/3) While this group anticipates a close working relationship with NENA, 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 in their documents.