--- 1/draft-ietf-ecrit-requirements-11.txt 2006-08-29 01:12:06.000000000 +0200 +++ 2/draft-ietf-ecrit-requirements-12.txt 2006-08-29 01:12:06.000000000 +0200 @@ -1,18 +1,20 @@ ECRIT H. Schulzrinne Internet-Draft Columbia U. -Expires: December 3, 2006 R. Marshall, Ed. +Expires: February 27, 2007 R. Marshall, Ed. TCS + August 26, 2006 + Requirements for Emergency Context Resolution with Internet Technologies - draft-ietf-ecrit-requirements-11 + draft-ietf-ecrit-requirements-12 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 3, 2006. + This Internet-Draft will expire on February 27, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where @@ -49,33 +51,33 @@ 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Emergency Services . . . . . . . . . . . . . . . . . . . . 6 3.2 Service Providers . . . . . . . . . . . . . . . . . . . . 6 3.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Call Routing Entities . . . . . . . . . . . . . . . . . . 7 3.5 Location . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 Identifiers, Numbers and Dial Strings . . . . . . . . . . 8 3.7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5. High-Level Requirements . . . . . . . . . . . . . . . . . . 14 - 6. Identifying the Caller's Location . . . . . . . . . . . . . 16 - 7. Emergency Service Identifier . . . . . . . . . . . . . . . . 19 - 8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . 22 - 9. Security Considerations . . . . . . . . . . . . . . . . . . 27 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 13.1 Normative References . . . . . . . . . . . . . . . . . . 31 - 13.2 Informative References . . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 - Intellectual Property and Copyright Statements . . . . . . . 33 + 5. High-Level Requirements . . . . . . . . . . . . . . . . . . 13 + 6. Identifying the Caller's Location . . . . . . . . . . . . . 15 + 7. Emergency Service Identifier . . . . . . . . . . . . . . . . 18 + 8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . 21 + 9. Security Considerations . . . . . . . . . . . . . . . . . . 26 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 13.1 Normative References . . . . . . . . . . . . . . . . . . 30 + 13.2 Informative References . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 + Intellectual Property and Copyright Statements . . . . . . . 32 1. Introduction Users of both voice-centric (telephone-like) and non-voice services such as text communication for hearing disabled users (RFC 3351 [3]) expect to be able to initiate a request for help in case of an emergency. Unfortunately, the existing mechanisms to support emergency calls that have evolved within the public circuit-switched telephone @@ -95,21 +97,21 @@ We first define terminology in Section 3. The document then outlines various functional issues which relate to placing an IP-based emergency call, including a description of baseline requirements (Section 5), identification of the emergency caller's location (Section 6), use of a service identifier to declare a call to be an emergency call (Section 7), and finally, the mapping function required to route the call to the appropriate PSAP (Section 8). The primary purpose of the mapping protocol is to produce a PSAP URI drawn from a preferred set of URI schemes such as SIP or SIPS URIs, - based on both location information [9] and a service identifier in + based on both location information [8] and a service identifier in order to facilitate the IP end-to-end completion of an emergency call. Aside from obtaining a PSAP URI, the mapping protocol is useful for obtaining other information as well. There may be a case, for example, where an appropriate emergency number is not known, only location. The mapping protocol can then return a geographically appropriate emergency number based on the input. Since some PSAPs may not immediately support IP, or because some user @@ -251,21 +253,21 @@ string of digits used to reach the (emergency) service. The emergency service number is often just called the emergency number. It is the number typically dialed on devices directly connected to the PSTN and the number reserved for emergency calls by national or regional numbering authorities. It only contains the digits 0 through 9, # and *. The service number may depend on the location of the caller. For example, the general emergency service number in the United States is 911 and the poison control service number is 18002221222. In most cases, the service number and dial string are the same; they may differ in some private - phone networks. A service number may be carried in tel URLs [7], + phone networks. A service number may be carried in tel URLs [6], along with a context identifier. In the North American numbering plan, some service numbers are also three-digit N11 or service codes, but not all emergency numbers have three digits. A caller may have to dial a service dial string (below) that differs from the service number when using a PBX. (Emergency) service dial string: The service dial string identifies the string of digits that a caller must dial to reach a particular (emergency) service. In devices directly connected to the PSTN, the service dial string is the same as the service number and may @@ -276,33 +278,33 @@ emergency services in the United States might be 9911. Dial strings may contain indications of pauses or wait-for-secondary- dial-tone indications. Service dial strings are outside the scope of this document. (Emergency) service identifier: The (emergency) service identifier describes the emergency service, independent of the user interface mechanism, the signaling protocol that is used to reach the service, or the caller's geographic location. It is a protocol constant and used within the mapping and signaling protocols. An - example is the service URN [12]. + example is the service URN [11]. (Emergency) service URL: The service URL is a protocol-specific - (e.g., SIP) or protocol-agnostic (e.g., im: [6]) contains the + (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the address of the PSAP or other emergency service. It depends on the specific signaling or data transport protocol used to reach the emergency service. Service URN: A service URN is an implementation of a service identifier, which can be applied to both emergency and non- emergency contexts, e.g., urn:service:sos or urn:service:counseling. Within this document, service URNs are - referred to as 'emergency service URNs' [12]. + referred to as 'emergency service URNs' [11]. Home emergency number: A home emergency number is the emergency number valid at the caller's customary home location, e.g., his permanent residence. The home location may or may not coincide with the service area of the caller's VSP. Home emergency dial string: A home dial string is the dial string valid at the caller's customary home location, e.g., his permanent residence. @@ -375,48 +377,41 @@ |Service | |Provider | +---------------------+ Figure 1: Framework for emergency call routing Figure 1 shows the interaction between the entities involved in the call. There are a number of different deployment choices, as can be easily seen from the figure. - How is location information provided to the end host? It might - either be known to the end host itself via manual configuration, - provided via GPS, made available via DHCP ([5], [14]) or some other - mechanism. Alternatively, location information is inserted by - intermediaries. - Is the Internet Attachment Provider also the Application/Voice Service Provider? In the Internet today these roles are typically provided by different entities. As a consequence, the Application/ Voice Service Provider is typically not able to directly determine the physical location of the emergency caller. The overlapping squares in the figure indicate that some functions can be collapsed into a single entity. As an example, the Application/Voice Service Provider might be the same entity as the Internet Attachment Provider. There is, however, no requirement that this must be the case. Additionally, we consider that end systems might act as their own ASP/VSP, e.g., either for enterprises or for residential users. Various potential interactions between the entities depicted in Figure 1 are described below: 1. Location information might be available to the end host itself. 2. Location information might, however, also be obtained from the - Internet Attachment Provider (e.g., using DHCP or application - layer signaling protocols). + Internet Attachment Provider. 3. The emergency caller might need to consult a mapping service to determine the PSAP (or other relevant information) that is appropriate for the physical location of the emergency caller, possibly considering other attributes such as appropriate language support by the emergency call taker. 4. The emergency caller might get assistance for emergency call routing by infrastructure elements that are emergency call routing support entities, such as an Emergency Service Routing @@ -478,21 +473,21 @@ PSAPs, ASP/VSPs, IAPs or other participants. Re4. Multi-mode communication: IP-based emergency calls MUST support multiple communication modes, including, for example, audio, video and text. Motivation: Within the PSTN, voice and text telephony (often called TTY or text-phone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC - 4103 [8]), instant messaging and video. + 4103 [7]), instant messaging and video. Re5. Mapping result usability: The mapping protocol MUST return one or more URIs that are usable within a standard signaling protocol (i.e., without special emergency extensions). Motivation: For example, a SIP URI which is returned by the mapping protocol needs to be usable by any SIP capable phone within a SIP initiated emergency call. This is in contrast to a "special purpose" URI, which may not be recognizable by a legacy SIP device. @@ -518,32 +513,29 @@ Re8. Anonymous mapping: The mapping protocol MUST NOT require the true identity of the target for which the location information is attributed. Motivation: Ideally, no identity information is provided via the mapping protocol. Where identity information is provided, it may be in the form of an unlinked pseudonym (RFC 3693 [4]). 6. Identifying the Caller's Location - Location can either be provided directly (by value), or via a poiner + Location can either be provided directly (by value), or via a pointer (by reference), and represents either a civic location, or a geographic location. An important question is how and when to attach location information to the VoIP emergency signaling messages. In general, we can distinguish three modes of operation of how a location is associated with an emergency call: UA-inserted: The caller's user agent inserts the location information - into the call signaling message. The location information is - derived from sources such as GPS, DHCP (see [5] for geographic - location information and [14] for civic location information) or - utilizing the Link Layer Discovery Protocol (LLDP) [16]. + into the call signaling message. UA-referenced: The caller's user agent provides a pointer (i.e., a location reference), via a permanent or temporary identifier, to the location information, which is stored by a location server somewhere else and then retrieved by the PSAP, ESRP, or other authorized entity. Proxy-inserted: A proxy along the call path inserts the location or location reference. @@ -562,21 +554,21 @@ Lo2. Location delivery by-value: The mapping protocol MUST support the delivery of location information using a by-value method, though it MAY also support de-referencing a URL that references a location object. Motivation: The mapping protocol is not required to support the ability to de-reference specific location references. Lo3. Alternate community names: The mapping protocol MUST support both the jurisdictional community name and the postal community - name fields within the PIDF-LO [9] data. + name fields within the PIDF-LO [8] data. Motivation: The mapping protocol must accept queries with either a postal or jurisdictional community name field, or both, and provide appropriate responses. If a mapping query contains only one community name and the database contains both jurisdictional and postal community names, the mapping protocol response SHOULD return both community names. Lo4. Validation of civic location: The mapping protocol MUST support location validation for civic locations (street addresses). @@ -643,21 +635,21 @@ Street Address Guide (MSAG) or commercial map data providers. 7. Emergency Service Identifier Emergency service identifiers are protocol constants that allow protocol entities such as SIP proxy servers to distinguish emergency calls from non-emergency calls and to identify the specific emergency service desired. Emergency service identifiers are a subclass of service identifiers that more generally identify services reachable by callers. An example of a service identifier is the service URN - [12], but other identifiers, such as tel URIs [7], may also serve + [11], but other identifiers, such as tel URIs [6], may also serve this role during a transition period. Since this document only addresses emergency services, we use the terms "emergency service identifier" and "service identifier" interchangeably. Requirements for these identifiers include: Id1. Multiple emergency services: The mapping protocol MUST be able to distinguish between different emergency services, differentiated by different service identifiers. @@ -710,21 +702,21 @@ emergency service identifiers. Id6. Emergency service identifier marking: Signaling protocols MUST support emergency service identifiers to mark a call as an emergency call. Motivation: Marking ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address. This marking mechanism is related to, but independent of, marking calls for - prioritized call handling [10]. + prioritized call handling [9]. Id7. Handling unrecognized emergency service identifiers: There MUST be support for calls which are initiated as emergency calls even if the specific emergency service requested is not recognized by the ESRP. Such calls will then be routed to a generic emergency service. Motivation: Fallback routing allows new emergency services to be introduced incrementally, while avoiding non-routable emergency calls. For example, a call for marine rescue services would be @@ -735,36 +727,36 @@ be able to report back the actual service mapped if the mapping protocol substitutes another service for the one requested. Motivation: A mapping server may be configured to automatically look up the PSAP for another service if the user-requested service is not available for that location. For example, if there is no marine rescue service, the mapping protocol might return the PSAP URL for general emergencies and include the "urn:service.sos" identifier in the response to alert the querier to that fact. - Id9. Discovery of visited emergency dial strings: There MUST be a + Id9. Discovery of visited emergency numbers: There MUST be a mechanism to allow the end device to learn visited emergency numbers. Motivation: Travelers visiting a foreign country may observe the local emergency number, e.g., seeing it painted on the side of a fire truck, and then rightfully expect to be able to dial that emergency number. Similarly, a local "good Samaritan" may use a tourist's cell phone to summon help. 8. Mapping Protocol There are two basic approaches to invoke the mapping protocol. We refer to these as caller-based and mediated. In each case, the mapping client initiates a request to a mapping server via a mapping - protocol. A proposed mapping protocol, LoST, is outlined in [13]. + protocol. A proposed mapping protocol, LoST, is outlined in [12]. For caller-based resolution, the caller's user agent invokes the mapping protocol to determine the appropriate PSAP based on the location provided. The resolution may take place well before the actual emergency call is placed, or at the time of the call. For mediated resolution, an emergency call routing support entity, such as a SIP (outbound) proxy or redirect server invokes the mapping service. @@ -780,21 +772,21 @@ Motivation: An over-abundance of similarly-capable choices appears undesirable for interoperability. Ma2. Extensible protocol: The mapping protocol MUST be designed to support the extensibility of location data elements, both for new and existing fields. Motivation: This is needed, for example, to accommodate future extensions to location information that might be included in the - PIDF-LO ([9]). + PIDF-LO ([8]). Ma3. Incrementally deployable: The mapping protocol MUST be designed to support its incremental deployment. Motivation: It must not be necessary, for example, to have a global street level database before deploying the system. It is acceptable to have some misrouting of calls when the database does not (yet) contain accurate PSAP service area information. Ma4. Any time mapping: The mapping protocol MUST support the ability @@ -894,21 +886,21 @@ county may handle different streets within that city or county. Ma14. URL for error reporting: The mapping protocol MUST support the ability to return a URL that can be used to report a suspected or known error within the mapping database. Motivation: If an error is returned, for example, there needs to be a URL which points to a resource which can explain or potentially help resolve the error. - Ma15. Resiliance to failure: The mapping protocol MUST support a + Ma15. Resilience to failure: The mapping protocol MUST support a mechanism which enables the client to fail over to different (replica) mapping server. Motivation: The failure of a mapping server should not preclude the mapping client from receiving an answer to its query. Ma16. Traceable resolution: The mapping protocol SHOULD support the ability of the mapping client to be able to determine the entity or entities that provided the emergency address resolution information. @@ -938,36 +930,30 @@ Motivation: This is especially useful when an alternate mapping is requested, and alternative sources of mapping data may not have been created or updated with the same set of information or within the same timeframe. Differences in currency between mapping data contained within mapping sources should be minimized. 9. Security Considerations Threats and security requirements are discussed in a separate - document [11]. + document [10]. 10. IANA Considerations This document does not require actions by the IANA. 11. Contributors - The information contained in this document is a result of a several - original joint contributions of text, which was then discussed and - refined by those and many others within the working group. These - contributors to the early text include, Nadine Abbott, Hideki Arai, - Martin Dawson, Motoharu Kawanishi, Brian Rosen, Richard Stastny, - Martin Thomson, James Winterbottom. - - The contributors can be reached at: + The information in this document is partially derived from text + written by the following contributors: Nadine Abbott nabbott@telcordia.com Hideki Arai arai859@oki.com Martin Dawson Martin.Dawson@andrew.com Motoharu Kawanishi kawanishi381@oki.com Brian Rosen br@brianrosen.net @@ -981,22 +967,22 @@ 12. Acknowledgments In addition to thanking those listed above, we would like to also thank Guy Caron, Barry Dingle, Keith Drage, Tim Dunn, Patrik Faltstrom, Clive D.W. Feather, Raymond Forbes, Randall Gellens, Michael Haberler, Michael Hammer, Ted Hardie, Gunnar Hellstrom, Cullen Jennings, Marc Linsner, Rohan Mahy, Patti McCalmont, Don Mitchell, John Morris, Andrew Newton, Steve Norreys, Jon Peterson, James Polk, Benny Rodrig, John Rosenberg, Jonathan Rosenberg, John Schnizlein, Shida Schubert, James Seng, Byron Smith, Barbara Stark, - Tom Taylor, Hannes Tschofenig, and Nate Wilcox for their helpful - input. + Richard Stastny, Tom Taylor, Hannes Tschofenig, and Nate Wilcox for + their helpful input. 13. References 13.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 13.2 Informative References @@ -1005,62 +991,50 @@ Session Initiation Protocol", RFC 3261, June 2002. [3] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002. [4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. - [5] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host - Configuration Protocol Option for Coordinate-based Location - Configuration Information", RFC 3825, July 2004. - - [6] Peterson, J., "Common Profile for Instant Messaging (CPIM)", + [5] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. - [7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + [6] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. - [8] Hellstrom, G. and P. Jones, "RTP Payload for Text + [7] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. - [9] Peterson, J., "A Presence-based GEOPRIV Location Object + [8] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. - [10] Schulzrinne, H. and J. Polk, "Communications Resource Priority + [9] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. - [11] Taylor, T., "Security Threats and Requirements for Emergency + [10] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006. - [12] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", - draft-ietf-ecrit-service-urn-03 (work in progress), May 2006. + [11] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", + draft-ietf-ecrit-service-urn-04 (work in progress), + August 2006. - [13] Hardie, T., "LoST: A Location-to-Service Translation Protocol", + [12] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-hardie-ecrit-lost-00 (work in progress), March 2006. - [14] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 - and DHCPv6) Option for Civic Addresses Configuration - Information", draft-ietf-geopriv-dhcp-civil-09 (work in - progress), January 2006. - - [15] Wijk, A. and G. Gybels, "Framework for real-time text over IP + [13] Wijk, A. and G. Gybels, "Framework for real-time text over IP using the Session Initiation Protocol (SIP)", - draft-ietf-sipping-toip-05 (work in progress), June 2006. - - [16] Institute of Electrical and Electronics Engineers, "Station and - Media Access Control Connectivity Discovery", IEEE Standard - 802.1 AB, April 2005. + draft-ietf-sipping-toip-06 (work in progress), August 2006. Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US