2.7.4 Emergency Context Resolution with Internet Technologies (ecrit)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-09


Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>
Marc Linsner <marc.linsner@cisco.com>

Transport Area Director(s):

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

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: sipping-emergency@ietf.org
To Subscribe: https://www1.ietf.org/mailman//listinfo/sipping-emergency
Archive: http://www.ietf.org/mail-archive/web/sipping-emergency/index.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

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.

This working group cares about privacy and security concerns, and will
address them within its documents.

Goals and Milestones:

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

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Emergency Context Resolution with Internet Technologies WG
 Emergency Context Resolution with Internet Technologies WG (ecrit)

Wednesday, March 9 at 0900-1130


Marc Linsner <marc.linsner@cisco.com>
Hannes Tschofenig <hannes.tschofenig@siemens.com>


Spencer Dawkins <spencer@mcsr-labs.org>



1) Agenda Bashing
(Chairs, 5 min)


  • Rohan: We have 65 minutes of material in a 150-minute slot.
  • Hannes: we have time to talk ...

2) Requirements for Session Initiation Protocol (SIP)-based Emergency Calls
(H. Schulzrinne, 15 min)


  • Idea was to collect core requirements for emergency calling, independent of technology and national considerations
  • Sipping draft has been around for a bit - cutting out trunk replacement in ECRIT
  • Number provisioning
  • Identification of emergency calls
  • Location determination
  • Call routing
  • Focus here is protocol-related requirements only, not operational requirements (which also matter)
  • Some requirements protocol-specific
  • Steve Norris - Network resiliency? Priority indication?
  • Hannes - these may be operational requirements, important but not in scope for this working group - we aren't doing system design at IETF
  • James Polk - Prioritization is specifically out of scope for this working group
  • Not sure how much we need to do here on number provisioning - idea is that users dial familiar numbers, but we don't use these as routing identifiers
  • Network boundaries may not match identifier boundaries, but this is typically national-scale, not local network scale issue
  • Roaming - need to provide both visited and home numbers
  • Support multiple emergency services (more common outside North America)
  • Call identification requirements are reasonable but contradictory - need to figure out what actually fits
  • Universal system-visible identifier, local emergency identifiers
  • All entities along a path must identify emergency calls
  • Richard - how does this work if you have identifier translation along a path? which is also a requirement
  • Requirement is actually for multiple intermediate translations along the path
  • Backwards compatibility - UACs that don't understand identifiers? Outbound proxies may not understand identiers - assume that home AOR does, that's what you actually know about and have control over
  • Rohan - software clients are still being updated regularly - don't assume this constraint - but SBCs have a business case of protocol repair
  • Jonathan - the problem is that you don't control the things you need to talk to
  • Not worrying about hotel outbound proxies, etc. at this time
  • Location requirements - multiple location providers, by reference, end party, third party. Assuming home provider is what we need to deal with now
  • Rohan - distinct providers of SIP services and IP connectivity? if we're going to support this, call it out explicitly - it's the fastest-growing form of SIP services
  • Michael - additional complexity with 802.11 mobility - need to call this out explicitly as well - as long as provider can provide location information, that's what we need to provide the service - we have to go down to layer two to solve this
  • James Polk - large-scale layer-two networks are more problematic - is this IEEE scope?
  • Civic and geographic information are done?
  • PIDF-LO is done?
  • Michael - large-scale layer-two networks need to be in scope to meet real regulartory requirements - but we don't need to say how providers know where the location actually is
  • Rohan - resounding consensus from layer two is to provide raw information and let IETF define actual protocols - we need to define this if we care about it - but this is GeoPriv material, not ECRIT material - but do we need to set requirements for GeoPriv here?
  • James - we need routing to the right PSAP to be in scope!
  • Jon Peterson - there are already drafts circulating in other working groups - requirements don't need to be done here, but we can discuss this - seems hard to do requirements without an architecture design that we don't have yet - there is a broader problem that we decided to slice into solvable parts, including this WG's charter
  • James Winterbottom- assuming that we already have a dependable source of location
  • Brian Rosen - if we don't have someone responsible for the big picture, we don't know where to go - someone has to have the big picture; if we don't, who does? - do we need to get something out quickly, or work on an architecture? Don't cycle on this for two years before we can do something
  • Jon - we are building a tool, not a solution, and it would be presumptious to do that in the IETF
  • Brian - we can't build national systems, we can only build international systems, and there's no venue to do this
  • Jon - we are not the UN, we can convince people our tools are useful, not sure we can do more
  • Richard - we are talking requirements, not solutions - let's focus on requirements before we do anything else
  • Rohan - national groups are looking to the IETF - we aren't the UN, but nations are asking for help -
  • * - if we don't decide, it will be decided nationally
  • Call routing has basic robustness requirement- UA or outbound proxy or home proxies or other proxies need to be able to routing, even if other entities don't understand non-SIP URIs
  • Non-controversial requirements for routing
  • Possibly controversial - choice of PSAP (campus vs city police), traceable resolution? for caller? or just for PSAP?
  • Steve Norris - Don't understand choice of PSAP (this is a college requirement, among other places - industrial, security firms) - we're talking about getting to the "real" PSAP, right?
  • Support for mutiple signalling protocols? Most people are worried about SIP - can others say something on the mailing list so we don't get blind-sided?
  • Media-capability-based routing? TDD, IM
  • Language-based routing? James Polk - this is a good idea - we would need  non-SIP directory services that support this - would this work within a PSAP network for additional routing after the call gets to the PSAP?  - Jon Peterson - if this is low-hanging fruit, fine, we just need to think more about this
  • Patrik - "lookup must be fast" - Sweden requirement is to minimize the number of reroutings based on guessing the language
  • Michael - if you can identify the words, there are other ways to do this - hints OK, but don't make this an operational requirement
  • Caller identification requirements - language identification? Identification of supported media? We mostly know how to do these today
  • Patrik - is call-back in these requirements? No, but it should be
  • Call Setup - Authentication override? Mid-call features (outside the scope of this working group?)?
  • SIP is external interface - allow MGCP, Skinny, H.323 within administrative domains?
  • Rohan - stimulus-oriented protocols aren't appropriate because these devices usually also speak SIP, H.323 etc.
  • Steve Norris - we're talking about voice service - that's the requirement - but we work on protocols, not on services
  • Henning - protocol choice drives idenifier discussion
  • Is PSAP OK terminology? Steve Norris - ETSI has had problems with PSAP - this is a function, not a box or a person - PSAP isn't the only problematic term we're dealing with, need to scrub this
  • Patrik - what about receive-side call blocking? What is interaction with authentication override? Need to at least discuss this - haven't had contributions on threats - but you'll get one from Sweden soon!
  • James Polk - protocol within PSAP doesn't matter. SIP and H.323 are the only choices for call routing. Focus on SIP? Jon Peterson - how much does our work here assume SIP at the requirements level? Would any URI work?
  • Jonathan Rosenberg - might be dependent on protocol, or not - can we break the problem into pieces that are mostly NOT dependent on a protocol? Use a URN instead of a SIP URI?

3) Emergency Call Requirements for IP Telephony Services In Japan
(M. Kawanishi, 10 min)


  • Requirements from a draft MIC report, focused on VoIP specifically
  • Want VoIP emergency services to be equivalent to existing PSTN environment
  • Stu Gallman - how is priority override actually performed today? This question is actually out of scope - offline?
  • James Polk - actually, may be relevant - overloaded proxy, etc. Japan worries about this, don't ignore it
  • Pointing out that PSAP is the only party that can end emergency calls - includes reversing call from PSAP
  • Pointing out requirement for redirection to altenative PSAP if original PSAP is unavailable
  • Calling-line ID must be presented unless an override code is dialed

4) NENA Requirements for Emergency Call processing
(B. Rosen, 10 min)



  • Requirements from NENA VoIP/Packet technical committee
  • 6134 PSAPs with irregular boundaries in North America - routing based on side of streets or worse
  • Lots of effort to keep civic addresses accurate
  • Current system has good accountability for every entity along the path - matters when something goes wrong, because you debug problems in life-threatening situations
  • Need to know what happened with signalling
  • Got to be able to call 911, although other numbers could work
  • Need to have calls go to H.164 numbers if you aren't served by 911
  • James Polk - is signalling trace like History-Info? Yeah, and Vias - don't drop Vias at SBCs, for instance
  • We assume soft phones get location and provide location on incoming calls - what if the PSTN comes into a gateway - what's the way to make those scenarios work?
  • Need congestion controls everywhere - don't avalanche problems downstream elements - congestion control in the SIP sense, and this is at the endpoint level, not at the intermediate node level
  • Multiple locations in a call? Gotta route based on one location - know tower location plus measured location - this does happen today, and is legitimate
  • Location provider may not be communication service provider
  • Need defaults for location when information is missing - choosing "somewhere"
  • Eric Rescola - what is scope of default route? there is a hierarchy of defaults
  • Rohan - 911 calls on cell phones in California go to Sacramento
  • Steve Norris - can't hold up emergency calls for location information
  • * - what happens if you provide coordinates instead of street addresses? Hours of discussion on this, but existing service uses both and doesn't do conversion well - what about going forward with GPS-capable devices?
  • Address hierarchies - tenants at a location, etc. URI in the database would be enough
  • Additional information about a person - URI would be enough
  • Validate before you call - location exists in the database before you use it to route. Validation databases are also multiple and often map to PSAP boundaries in North America
  • James Polk - who is "you"? - doesn't matter - UA must validate? Or location information system - place burden on the location server to validate? doesn't matter, still needs to be validated - UA can validate, but location service must validate
  • Hannes - need to be very precise about what we're trying to accomplish here - we're skating along the edge of the charter. Additionally, the term validation is used with two different meanings.
  • Henning - we have at least two mental pictures of validation - not just a terminology problem, but confusion - does an address exist, and am I actually at that location - how do I know a street address is correct? But this is clearly out of scope
  • Postal address isn't actual community name - need to know which one we've got
  • Some PSAP boundaries are incredibly irregular - river course, all of a city except for two streets
  • Lots of entities will route - routing data must be secure, reliable in the face of massive failure
  • Callback identifier must be reliable
  • "No hangup" mechanism - no BYEs!
  • Distribute route failure information and related diagnostic information
  • Want one requirements document quick - either this one or a design team draft

ECRIT Basic Reqs
(R. Stastny, 10 min)


  • Draft intention was to step back to high level
  • Updating based on list discussion
  • Don't want operators to withhold location information (even because they want to sell it)
  • Must verify path to PSAP/ECC periodically
  • Steve Norris - get location information from user at last resort? Mobile phones are doing this by voice now in Europe, thinking about better mechanisms
  • James Polk - 802.11 phones in a home won't have their own locations; $500 boxes may ask users to provide information (although this won't be reliable) - this is a policy question
  • Communication established by external events (is this out of scope? certainly a user interface issue)
  • Indication whether you are allowed to make an emergency call (no location, no authentication, etc.)
  • Have added home and visited emergency URI requirement
  • Have added recognition of emergency calls by intermediate devices
  • Steve Norris - 3GPP also has requirements for downloading roamed-to emergency numbers automatically
  • Jon Peterson - being able to designate a gateway for emergency calls is actually in scope, but going beyond this is probably out of scope
  • Some SHOULDs are MUSTs in some countries

6) ECRIT Location Scope Requirements
(J. Winterbottom, 10 min)


  • VoIP needs the same assurances for PSAPs that they have from POTS information today
  • Location tied to a device, not to a user, at the time that a call is made
  • Location needs to be a real place - postal vs jurisdictional location
  • Patrik - location needs to be what a fire truck is using, whether it is right or wrong
  • Brian - same for information that's used to route
  • Need accountability for location providers
  • Reliability may not be in scope for Ecrit, but it needs to be in scope for somebody
  • Steve Norris - if you have two pieces of location, both of them are required
  • James Polk - Access provider is probably actually providing location, not service provider
  • Jon Peterson - we were talking about scope when we did charter - how is the protocol depending on the validation of location information, if we understand that error conditions are included in the protocol?
  • Henning - if there's a one-step resolution protocol, this is probably OK - if it's not one step, if multiple steps of resolution are required and visible outside the PSAP, the protocol needs to know about validity
  • Brian Rosen - it is in scope to require location validation before you route emergency calls based on location - why is this controversial? It's a North American requirement, for sure
  • Henning - Imagine an MSAG that wouldn't route to a real PSAP - confirms that a location is valid, but you can't tell that a PSAP assignment is reasonable or not. Location is more complicated than just "does it exist", and these requirements are stronger.
  • <>Brian Rosen - Patrik was right - what people care about is what Patrik said; what people care about is whether locations work for dispatching fire trucks - location will be used for routing AND given to the PSAP for PSAP response</>

7) Next Steps and AOB
(Chairs, 5 min)

  • Hannes: We have seen a number of drafts about requirements, some more mature than others. We need to come up with requirements really soon. Henning's document is the most complete one (and available for a long time already). It needs to be updated and have terminology scrubbed. Can other document authors contribute to one document? Can we pick an editor?
  • Brian Rosen - this is actually more collaborative, but I agree
  • Roger Marshall and Brian Rosen volunteered to be editors - Roger will take the lead here
  • Rohan - who are these requirements for? All of the drafts have requirements on all sorts of entities - need to organize the requirements by who they reply to.
  • Rohan - security analysis - need to do much more work in this area.
  • Steve Norris - NGN TiSPAN group has IMS requirements that are 90-percent overlap with 3GPP. Emergency services have requirements, too (provider call release, etc.)


Requirements for Emergency Calling
Emergency Call Requirements for IP Telephony Services in Japan
NENA Requirements
ECRIT Basic Reqs
Requirements for Domain Authentication and Validated Location