Emergency Context Resolution with Internet Technologies BOF ecrit

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

• 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-re
  q/draft-schulzrinne-sipping-emergency-req-01.html
  
• http//www.cs.columbia.edu/sip/draft/emergency-ar
  ch/
• 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.