Last Modified: 2004-10-28
|
Emergency Context Resolution with Internet Technologies BOF (ecrit)
Meeting Minutes - IETF#61 (61st IETF - Washington, DC, USA, November 7-12, 2004) Chair(s): Jon Peterson <jon.peterson@neustar.biz> Hannes Tschofenig <hannes.tschofenig@siemens.com> Minute Taker: Melinda Shore Joerg Ottensmeyer Steffen Fries Jabber Scribe: Andrew Newton Abbreviations: 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) 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 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. |