2.8.4 Emergency Context Resolution with Internet Technologies (ecrit)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-28


Jon Peterson <jon.peterson@neustar.biz>
Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion:
To Subscribe:

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

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

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.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Emergency Context Resolution with Internet Technologies BOF (ecrit)
Meeting Minutes - IETF#61

(61st IETF - Washington, DC, USA, November 7-12, 2004)

Jon Peterson <jon.peterson@neustar.biz>
Hannes Tschofenig <hannes.tschofenig@siemens.com>

Minute Taker:
Melinda Shore
Joerg Ottensmeyer
Steffen Fries

Jabber Scribe:
Andrew Newton

Jon (Jon Peterson)
Hannes (Hannes Tschofenig)
Henning (Henning Schulzrinne)
Ted (Ted Hardie)
Brian (Brian Rosen)

Friday, November 12 at 0900-1130

Agenda - 15 min (Jon Peterson/Hannes Tschofenig)
Slides are available at: http://www.tschofenig.com/ecrit/IETF61/ecrit.ppt

Proposed charter is available at: http://www.tschofenig.com/ecrit/IETF61/ecrit.txt

Jon introduced the proposed charter. He mentioned the great deal of discussion of emergency services in other Transport Area working groups (voice and others). He noted that the charter has a very narrow scope: discovery of PSAPs and related related call routing. This WG will not solve the entire problem space of emergency service. Several drafts already speak to this, goal of BOF is to find out if we understand the design space (requirements, framework) and to find out if there's support for work.

Hannes went through the six proposed deliverables to highlight the charter content:
- An 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]

James Polk: Why not only requirements? He suggests to first work on the requirements and then re-charter Focus on solutions first after re-charter...

John: He said that it's becoming common in BOFs to identify everything that would be done if the first step is successful.

Rohan Mahy: H doesn't think that a two-stage charter is necessary (also raised issue of PSTN interface).

Brian Rosen: He doesn't, either, and thinks PSTN question doesn't change work in any way.

Henning: not concerned about charter, is already narrowly focused. And there is a customer on the market. Henning is concerned about time that would be expended on two-stage chartering process.

Hannes: Solutions will not be done before requirements are clear!

James Polk still has concerns that people have solutions they're working on before requirements are done.

Steve Hollenbeck: Put some wording in the charter, that milestones will be reviewed after requirements are done.

Steve Norris: Charter is very dangerous, even different wording are used between NENA and ETSI

James Polk: James still has concerns that people have solutions they're working on before requirements are done.

Jon Peterson: is Hollenbeck's proposal ok?

James: yes

Jean-Franois Mule raised issue of recognition of media types being overly specific for this point in the process.

Mike Hammer: What about management? which a double edge sword, how will be solved such that work that falls within other IETF areas?

Jon: will be clarified when that occurs.

Kwok Ho Chang: He said that the group needs to interface with other groups outside the IETF.

Problem space in North America and Current Architecture - 10 min (Brian Rosen)
Slides are available at: http://www.tschofenig.com/ecrit/IETF61/North_American_Emergency_Services.ppt

Description of current system. North America more complicated than other regions. Single universal number (911), 6134 answer points, function of local government not significantly controlled by states/feds. All emergency calls are identified by only number i.e. 911 There are ~6000 PSAPs, than calls are dispatched to 1000th of response agencies The problem is that boundaries are not regular, and do not match political boundaries He described how do wireline calls are routed today: The PSTN switch has DB which knows mapping of phone number to PSAP's phone number, then "normal call routing"
- MSAG has validation database for location validation

Aron Falk: has number portability (NP) changed this?

Brian Rosen: NP has made it more more complex, i.e. the admin procedure to register DB entries

Henning: we have local NP only, nationwide will make this impossible

- Circuit switched wireless calls: use some additional info (cell-IDs) from mobile operator
- NENA's i2 solution: based on an edge gateway, and dos not change the PSAP infrastructure, location info are "feed in" as for other PSTN/wireless calls.

Rohan Mahy: What about enterprise 911 solutions?

Brian: There are put special entries into ALI databases...

Rohan Mahy: That is the wireless phase 2 case, and only 30% of the installations have it!

Hannes reminded people not to get lost in problems in existing systems.

- what is the problem?

Aron Falk: why not one location database?

Henning: systems are very heterogeneous in the US, even different local/regional solutions possible.

Steve Norris: The situation is much easier in the UK...

Scott Bradner: Solution to worked out must be working internationally!

Requirements and Architecture for Emergency Calls - 20 min (Henning Schulzrinne)


Slides are available at: http://www.tschofenig.com/ecrit/IETF61/Requirements_and_Architecture_for_Emergency_Calling.ppt

Big picture: focus on citizen emergency call, not interested in emergency coordination, not limited to voice, not green field, architectures include trunk replacement (last hop only), VoIP to traditional PSAP, and end-to-end IP. Goal here is to get immediately to Phase II wireless (call delivery based on geo location, display at PSAP).

The basic problem is to get emergency calls to the right PSAP.
The scope of the WG will not include emergency coordination communication = e.g. ieprep
Work should not just be applicable to VoIP, but also video, text, data...
Solutions need to be incrementally deployable, not a green-field approach, parallel deployment is a must

The core problems:
- PSTN approximate routing works (all 911 calls are local, there are only few carriers)
- more problematic for IP carries, there may be thousands in area, a few are even global
- apps have no clue about location
- transport providers have no clue what is an emergency call

- NENA roadmap: the in the IETF to be worked out solutions should work with/support NENA's i3 solution
- the proposed architecture look like this: a switch/proxy to consult databases to get mapping location->PSAP, then the call is completed based on this mapping.
Resolving this mapping is the core problem for this WG.

- requirements for emergency identifier: user interface problem and call routing problem, but not scope here
- caller location ...

- architecture: routing can take place at different places and different levels
- UAC, outbound proxy, home domain
- routing requirements...

Rohan pointed out that with IP devices identifiers needn't be limited to numbers.
Scott Brandner: is it in the scope of the wg to develop a WAN-scale replicated database?
Jon: No. There are several directory solutions to pick from: DNS, TRIP, IRIS, LDAP, ...

Design considerations for ECRIT - 20 min (Ted Hardie)
Slides are available at: http://www.tschofenig.com/ecrit/IETF61/Design_considerations_for_Emergency_Context_Resolution.pdf

Emergency response contexts enclose individuals seeking help. Can be multiple overlapping context, one critical element of context is physical location, emergency response context can change in response to load. Conflicts with internet deployment models - physical location largely unrelated to reachability & routing, internet topology is path-based, tunneling mechanisms mask topology, application routing above this layer is still dependent on it. Approaches: change routing system for emergency calls, or map between two. Modifying routing system: distinguish emergency calls, carry geographic data. Risks include emergency identification can fail, geographic location mechanism must be sufficiently widely available that it can always be invoked, must be able to handle call load, must be quick. Benefits: only occurs when needed, special handling may ensure higher service quality.

Jonathan thinks service quality should be more generic. Mapping: geographic data collection may occur at any time, when call is made target is substituted and normal call routing is used.

Richard Stastny asked about SIP dependency.

Brian said you're always doing a mapping and the question is when that mapping occurs.

Mapping risks: see slides. Hybrid approaches: very likely to be need for mapping step at some point in routing process. Like to be need for specialized routing process in the face of context change. Both may require association between presentation-layer request and application-layer request. Usual IETF work is about interoperability, this isn't - it's about optimization. Usual guidelines may not apply. Brian totally disagrees - this is exactly about interoperability.

Dave Oran disagrees that IETF work is overwhelmingly about interoperability - much is about optimization.

Ted believes best optimization strategy is to allow multiple network elements to undertake tasks. Bottom line is being able to use appropriate technology at appropriate place in network depending on context. Things needed: lookup protocol, method for carrying location data, way of identifying emergency service targets that allows distinction between types (fire, medical, police, etc.), and charter.

Open Discussions - 15 min (All)

Leif Johannson asked if we're optimizing for SIP, thinks XMPP can be helpful if not.

Henning says as long as we can do a URI it doesn't matter.

Steve Norris: raised issue of media quality, as far as QoS as is concerned should be as good as possible.

Martin Dolly said routing mechanisms need to take into account interoperability and need to route to legacy systems. Also be mindful of regulatory aspects.

Richard Kazmarek: need to think about congestion. Can recognize when congestion is encountered and reroute as needed.

Rohan brought up jurisdictional differences, wg can gather without creating formal document - for example, caller ID.

Spencer asked if there's an understanding of how bad a call can be and still be useful.

John Morris asked what relationship is between this group and charter requirement in geopriv to accommodate emergency services. Jon said hopeful people will be persuaded to use their technology. John felt that geopriv hasn't dealt well with privacy rules in this area.

Hannes + Jon: The relationship between geopriv and ecrit was briefly described. The importance of privacy in the context of location information.

Question about preemption, Jon reemphasized that we're talking about routing only.

Rohan said we need to be more crisp about when location information is available and how it's used. Location granularity, too.

Tom Taylor re-raised question of alternative architectures.

Scott Bradner reframed question as ability to reach out and acquire certain information, then asked why this is limited by service.

Steve Norris said that he thinks emergency call shouldn't be held up by lack of location information. Brian: even if you make a decision early on how to handle the call, the nature of emergencies suggests that routes may change over time.

Scott Bradner: Liaisons are important, many people here participate in other related organizations

Jon: a mailing list exists but I will turn it into an official one.

Brian Rosen: We need an architecture picture with the big picture!

James Polk: Can we get the privacy part back to the charter text?

Jon: Yes

Hannes: I will send an updated charter to list

Dan Romascanu mentioned that the enterprise space is sometime different than the public space. Something needs to be added to the charter.

Jon: charter discussion should be sent to the mailing list

Keith Drage: we have to understand the regulatory requirements... but, why delaying this work by founding a new WG and not do it in sipping?

Jonathan Rosenberg: Can't be done in sipping... is not even a SIP issue...

Kwok Chan: security and privacy is there. Reliability is also a requirement!

Jon: Is there interest in the room to work on the problem outlined in the proposed charter? hum... seem broad interest!

Nobody opposed to create a working group.


North American Emergency Services
Requirements and Architecture for Emergency Calling
Design considerations for Emergency Context Resolution