idnits 2.17.1 draft-ietf-ecrit-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 889. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 30, 2005) is 6684 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 833, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 839, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-taylor-ecrit-security-threats-01 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-09) exists of draft-ietf-sipping-toip-03 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: July 3, 2006 R. Marshall, Ed. 5 TCS 6 December 30, 2005 8 Requirements for Emergency Context Resolution with Internet Technologies 9 draft-ietf-ecrit-requirements-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 3, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document enumerates requirements for emergency calls placed by 43 the public using voice-over-IP (VoIP) and general Internet multimedia 44 systems, where Internet protocols are used end-to-end. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 11 52 5. Identifying the Caller Location . . . . . . . . . . . . . . . 13 53 6. Emergency Identifier . . . . . . . . . . . . . . . . . . . . . 15 54 7. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . . 17 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 56 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 57 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 58 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 59 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 60 11.2. Informative References . . . . . . . . . . . . . . . . . 25 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 62 Intellectual Property and Copyright Statements . . . . . . . . . . 27 64 1. Introduction 66 Users of both voice-centric (telephone-like) and non voice type 67 services (e.g. text messaging for hearing disabled users, (RFC 3351 68 [5]) have an expectation to be able to initiate a request for help in 69 case of an emergency. 71 Unfortunately, the existing mechanisms to support emergency calls 72 that have evolved within the public circuit-switched telephone 73 network (PSTN), are not appropriate to handle evolving IP-based 74 voice, text and real-time multimedia communications. This document 75 outlines the key requirements that IP-based end systems and network 76 elements, such as SIP proxies, need to satisfy in order to provide 77 emergency call services, which at a minimum, offer the same 78 functionality as existing PSTN services, with the additional overall 79 goal of making emergency calling more robust, less-costly to 80 implement, and multimedia-capable. 82 This document only focuses on end-to-end IP-based calls, i.e., where 83 the emergency call originates from an IP end system, (Internet 84 device), and terminates to an IP-capable PSAP, done entirely over an 85 IP network. 87 This document outlines the various functional issues which relate to 88 making an IP-based emergency call, including a description of 89 baseline requirements, (Section 4), identification of the emergency 90 caller's location, (Section 5), use of an emergency identifier to 91 declare a call to be an emergency call, (Section 6), and finally, the 92 mapping function required to route the call to the appropriate PSAP, 93 (Section 7). 95 Identification of the caller, while not incompatible with the 96 requirements for messaging outlined within this document, is not 97 currently considered within the scope of the ECRIT charter, and is 98 therefore, left for a future draft to describe. 100 Note: Location is required for two separate purposes, first, to route 101 the call to the appropriate PSAP and second, to display the caller's 102 location to the call taker for help in dispatching emergency 103 assistance to the correct location. 105 Ideally, the mapping protocol would yield a URI from a preferred set 106 of URIs (e.g. sips:uri; sip:uri), which would allow an emergency call 107 to be completed using IP end-to-end (possibly via the Internet). 108 Despite this goal, some PSAPs may not immediately have IP based 109 connectivity, and therefore it is imperative that the URI scheme not 110 be fixed, in order to ensure support for a less preferred set of 111 URIs, such as a TEL URI which may be used to Complete a call over the 112 PSTN. 114 2. Terminology 116 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 117 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 118 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 119 indicate requirement levels for compliant implementations. 121 Since a requirements document does not directly specify a protocol to 122 implement, these compliance labels should be read as indicating 123 requirements for the protocol or architecture, rather than an 124 implementation. 126 For lack of a better term, we will use the term "caller" or 127 "emergency caller" to refer to the person placing an emergency call 128 or sending an emergency IM. 130 Application Service Provider (ASP): The organization or entity that 131 provides application-layer services, which may include voice (see 132 "Voice Service Provider"). This entity can be a private 133 individual, an enterprise, a government, or a service provider. 134 An ASP is defined as something more general than a Voice Service 135 Provider, since emergency calls are sometimes likely to use other 136 media, including text and video. Note: For a particular user, the 137 ASP may or may not be the same organization as the IAP and/or ISP. 139 Basic Emergency Service: Basic Emergency Service allows a user to 140 reach a PSAP serving its current location, but the PSAP may not be 141 able to determine the identity or geographic location of the 142 caller (except by having the call taker ask the caller). 144 call taker: A call taker is an agent at the PSAP that accepts calls 145 and may dispatch emergency help. (Sometimes the functions of call 146 taking and dispatching are handled by different groups of people, 147 but these divisions of labor are not generally visible to the 148 outside and thus do not concern us here.) 150 civic location: A described location based on some defined grid, such 151 as a jurisdictional, postal, metropolitan, or rural reference 152 system (e.g. street address). 154 mapping service: A network service which uses a distributed mapping 155 protocol to provide information about the PSAP, or intermediary 156 which knows about the PSAP, and is used to assist in routing an 157 emergency call. 159 emergency address: The uri scheme (e.g. sip:uri, sips:uri, xmpp:uri, 160 im:uri, etc.) which represents the address of the PSAP useful for 161 the completion of an emergency call. 163 emergency caller: The user or user device entity which sends his/her 164 location to another entity in the network. 166 emergency identifier: The numerical and/or text identifier which is 167 supplied by a user or a user device, which identifies the call as 168 an emergency call and is translated into an emergency address for 169 call routing and completion. 171 enhanced emergency service: Enhanced emergency services add the 172 ability to identify the caller identity and/or caller location to 173 basic emergency services. (Sometimes, only the caller location 174 may be known, e.g. from a public access point that is not owned by 175 an individual.) 177 ESRP (Emergency Services Routing Proxy): An ESRP is a call routing 178 entity that invokes the location-to-URL mapping, which in turn may 179 return either the URL for another ESRP or the PSAP. (In a SIP 180 system, the ESRP would typically be a SIP proxy, but could also be 181 a Back-to-back user agent (B2BUA). 183 geographic location: A reference to a locatable point described by a 184 set of defined coordinates within a geographic coordinate system, 185 (e.g. lat/lon within the WGS-84 datum) 187 Internet Attachment Provider (IAP): An organization that provides 188 physical network connectivity to its customers or users, e.g. 189 through digital subscriber lines, cable TV plants, Ethernet, 190 leased lines or radio frequencies. Examples of such organizations 191 include telecommunication carriers, municipal utilities, larger 192 enterprises with their own network infrastructure, and government 193 organizations such as the military. 195 Internet Service Provider (ISP): An organization that provides IP 196 network-layer services to its customers or users. This entity may 197 or may not provide the physical-layer and layer-2 connectivity, 198 such as fiber or Ethernet. 200 Local Emerency Identifier: An emergency identifier which is 201 recognized from within a geographic or jurisdictional area from 202 which an emergency request is initiated. 204 location: A geographic identification assigned to a region or feature 205 based on a specific coordinate system, or by other precise 206 information such as a street number and name. In the geocoding 207 process, the location is defined with an x,y coordinate value 208 according to the distance north or south of the equator and east 209 or west of the prime meridian. 211 location validation: A caller location is considered valid if the 212 civic or geographic location is recognizable within an acceptable 213 location reference systems (e.g. USPS, WGS-84, etc.), and can be 214 mapped to one or more PSAPs. Location validation ensures that a 215 location is able to be referenced for mapping, but makes no 216 assumption about the association between the caller and the 217 caller's location. 219 Mapping: Process of resolving an location to a URI (or multiple 220 URIs). 222 Mapping Client: A Mapping Client interacts with the Mapping Server to 223 learn one or multiple URIs for a given location. 225 Mapping Protocol: A protocol used to convey the mapping request and 226 response. 228 Mapping Server: The Mapping Server holds information about the 229 location to URI mappings. 231 PSAP (Public Safety Answering Point): Physical location where 232 emergency calls are received under the responsibility of a public 233 authority. (This terminology is used by both ETSI, in ETSI SR 002 234 180, and NENA.) In the United Kingdom, PSAPs are called Operator 235 Assistance Centres, in New Zealand, Communications Centres. 236 Within this document, it is assumed, unless stated otherwise, that 237 PSAP is that which supports the receipt of emergency calls over 238 IP. It is also assumed that the PSAP is reachable by IP-based 239 protocols, such as SIP for call signaling and RTP for media. 241 Universal Identifier: An emergency identifier which is recognized by 242 any compatible endpoint, from any geographic location as useful 243 for initiating an emergency request. A general approach to using 244 universal identifiers is outlined in the service URN draft 245 (I-D.schulzrinne-sipping-service [4]). 247 Voice Service Provider (VSP): A specific type of Application Service 248 Provider which provides voice related services based on IP, such 249 as call routing, a SIP URI, or PSTN termination. 251 3. Basic Actors 253 In order to support emergency services covering a large physical area 254 various infrastructure elements are necessary: Internet Attachment 255 Providers, Application/Voice Service Providers, PSAPs as endpoints 256 for emergency calls, mapping services or other infrastructure 257 elements that assist in during the call routing and potentially many 258 other entities. 260 This section outlines which entities will be considered in the 261 routing scenarios discussed. 263 Location 264 Information +-----------------+ 265 |(1) |Internet | +-----------+ 266 v |Attachment | | | 267 +-----------+ |Provider | | Mapping | 268 | | | (3) | | Service | 269 | Emergency |<---+-----------------+-->| | 270 | Caller | | (2) | +-----------+ 271 | |<---+-------+ | ^ 272 +-----------+ | +----|---------+------+ | 273 ^ | | Location | | | 274 | | | Information<-+ | | 275 | +--+--------------+ |(8) | | (5) 276 | | +-----------v+ | | 277 | (4) | |Emergency | | | 278 +--------------+--->|Call Routing|<--+---+ 279 | | |Support | | 280 | | +------------+ | 281 | | ^ | 282 | | (6) | +----+--+ 283 | (7) | +------->| | 284 +--------------+--------------->| PSAP | 285 | | | 286 |Application/ +----+--+ 287 |Voice | 288 |Service | 289 |Provider | 290 +---------------------+ 292 Figure 1: Framework 294 Figure 1 shows the interaction between the entities involved in the 295 call. There are a number of different deployment choices, as it can 296 be easily seen from the figure. The following deployment choices 297 need to be highlighted: 299 o How is location information provided to the end host? It might 300 either be known to the end host itself (due to manual configuration 301 or provided via GPS) or available via a third party. Even if 302 location information is known to the network it might be made 303 available to the end host. Alternatively, location information is 304 used as part of call routing and inserted by intermediaries. 306 o Is the Internet Attachment Provider also the Application/Voice 307 Service Provider? In the Internet today these roles are typically 308 provided by different entities. As a consequence, the Application/ 309 Voice Service Provider is typically not able to learn the physical 310 location of the emergency caller. 312 Please note that the overlapping squares aim to indicate that certain 313 functionality can be collapsed into a single entity. As an example, 314 the Application/Voice Service Provider might be the same entity as 315 the Internet Attachment Provider and they might also operate the 316 PSAP. There is, however, no requirement that this must be the case. 317 Additionally it is worth pointing out that end systems might be its 318 own VSP, e.g., for enterprises or residential users. 320 Below, we describe various interactions between the entities shown in 321 Figure 1 are described: 323 o (1) Location information might be available to the end host itself. 325 o (2) Location information might, however, also be obtained from the 326 Internet Attachment Provider (e.g., using DHCP or application layer 327 signaling protocols). 329 o (3) The Emergency Caller might need to consult a mapping service to 330 determine the PSAP that is appropriate for the physical location of 331 the emergency caller (and considering other attributes such as a 332 certain language support by the Emergency Call Takers). 334 o (4) The Emergency Caller might get assistance for emergency call 335 routing by infrastructure elements (referred as Emergency Call 336 Routing Support entities). In case of SIP these entities are 337 proxies. 339 o (5) Individual Emergency Call Routing Support entities might need 340 to consult a mapping service to determine where to route the 341 emergency call. 343 o (6) The Emergency Call Routing Support entities need to finally 344 forward the call, if infrastructure based emergency call routing is 345 used. 347 o (7) The emergency caller might interact directly with the PSAP 348 without any Emergency Call Routing Support entities. 350 o (8) Location Information is used by emergency call routing entities 351 to determine appropriate PSAP mapping. 353 4. High-Level Requirements 355 Below, we summarize high-level architectural requirements that guide 356 some of the component requirements detailed later in the document. 358 Re1. Application Service Provider: The existence of an Application 359 Service Provider (ASP) MUST NOT be assumed. 361 Motivation: The caller may not have a application/voice service 362 provider. For example, a residence may have its own DNS domain 363 and run its own SIP proxy server for that domain. On a larger 364 scale, a university might provide voice services to its students 365 and staff, but not be a telecommunication provider. 367 Re2. International: The protocols and protocol extensions developed 368 MUST support regional, political and organizational differences. 370 Motivation: It must be possible for a device or software developed 371 or purchased in one country to place emergency calls in another 372 country. System components should not be biased towards a 373 particular set of emergency numbers or languages. Also, different 374 countries have evolved different ways of organizing emergency 375 services, e.g. either centralizing them or having smaller regional 376 subdivisions such as United States counties or municipalities 377 handle emergency calls. 379 Re3. Distributed Administration: Deployment of emergency services 380 MUST NOT depend on a sole central administration authority. 382 Motivation: Once common standards are established, it must be 383 possible to deploy and administer emergency calling features on a 384 regional or national basis without requiring coordination with 385 other regions or nations. The system cannot assume, for example, 386 that there is a single global entity issuing certificates for 387 PSAPs, ASPs, IAPs or other participants. 389 Re4. Multiple Modes: Multiple communication modes, such as audio, 390 video and text messaging MUST be supported. 392 Motivation: In PSTN, voice and text telephony (often called TTY or 393 textphone in North America ) are the only commonly supported 394 media. Emergency calling must support a variety of media. Such 395 media should include voice, conversational text (RFC 4103 [7]), 396 instant messaging and video. 398 Re5. Alternate Mapping Sources: The mapping protocol SHOULD allow 399 for alternative redundant sources of mapping information, possibly 400 of different degrees of currency. 402 Motivation: This provides the possibility of having available 403 alternative sources of mapping information when the normal source 404 is unavailable or unreachable, without specifying the means by 405 which the alternative source is created or updated. 407 Re6. Incremental Deployment: The ECRIT mapping protocol MUST return 408 URIs that are usable by a standard signaling protocol (i.e., 409 without special emergency extensions) unless an error is returned. 411 Motivation: The format of the output returned by the mapping 412 protocol is in a standard format for communication protocol. For 413 example, it should return something SIP specific (e.g. URI), that 414 any SIP capable phone would be able to use if used in a SIP 415 context. Special purpose URIs would not be understood by "legacy" 416 SIP devices since they do not have knowledge about the mapping 417 protocol, and therefore are not to be used. 419 Re7. Ubiquiteous Triggering: It MUST be possible to invoke the 420 mapping protocol at any time, from any location, by any client 421 which supports the mapping protocol. 423 Motivation: While end devices are the typical initiators of 424 mapping service requests, it is also expected that other mapping 425 clients, such as relays, 3rd party devices, PSAPs, etc. may also 426 trigger a mapping request. 428 Re8. PSAP Identification: The mapping information MUST be available 429 without having to enroll with a service provider. 431 Motivation: The mapping server may well be operated by a service 432 provider, but access to the server offering the mapping must not 433 require use of a specific ISP or VSP. 435 5. Identifying the Caller Location 437 Location can either be provided directly, or by reference, and 438 represents either a civic location, or as a geographic location. How 439 does the location (or location reference) become associated with the 440 call? In general, we can distinguish three modes of operation of how 441 a location is associated with an emergency call: 443 UA-inserted: The caller's user agent inserts the location 444 information, derived from sources such as GPS, DHCP or link-layer 445 announcements (LLDP). 447 UA-referenced: The caller's user agent provides a reference, via a 448 permanent or temporary identifier, to the location which is stored 449 by a location service somewhere else and then retrieved by the 450 PSAP. 452 Proxy-inserted: A proxy along the call path inserts the location or 453 location reference. 455 Lo1. Validation of Civic Location: It MUST be possible to validate a 456 civic location prior to its use in an actual emergency call. 458 Motivation: Location validation provides an opportunity to help 459 assure ahead of time, whether successful mapping to the 460 appropriate PSAP will likely occur when it is required. 461 Validation may also help to avoid delays during emergency call 462 setup due to invalid locations. 464 Lo2. Limits to Validation: Validation of a civic location MUST NOT 465 be required to enable any feature that is part of the emergency 466 call process. 468 Motivation: In some cases, (based on a variety of factors), a 469 civic location may not be considered valid. This fact should not 470 result in the call being dropped or rejected by any entity along 471 the signaling path to the PSAP. 473 Lo3. Reference Datum: The mapping server MUST understand WGS-84 474 coordinate reference system and may understand other reference 475 systems. 477 Lo4. Location Provided: An Emergency Services Routing Proxy (ESRP) 478 MUST NOT remove location information after performing location 479 based routing. 481 Motivation: The ESRP and the PSAP use the same location 482 information object but for a different purpose. Therefore, the 483 PSAP still requires the receipt of information which represents 484 the end device's location. 486 Lo5. 3D Sensitive Mapping: The mapping protocol MUST accept either a 487 2D or 3D mapping request, and return an appropriate result, based 488 on which type of input is used. 490 Motivation: It is expected that provisioning systems will accept 491 both 2D and 3D data. When a 3D request is presented to an area 492 only defined by 2D data, the mapping result would be the same as 493 if the height/altitude dimension was omitted on the request." 495 6. Emergency Identifier 497 Id1. Universal Identifier Setup: One or more universal emergency 498 identifiers MUST be recognized by any device or network element 499 for call setup purposes 501 Motivation: There must be some way for any device or element to 502 recognize an emergency call throughout the call setup. This is 503 regardless of the device location, the application (voice) service 504 provider used (if any at all), or of any other factor. Examples 505 of these might include: 911, 112, and sos.*. 507 Id2. Universal Identifier Resolution: Where multiple emergency 508 service types exist, it MUST be possible to treat each emergency 509 identifier separately, based on the specific type of emergency 510 help requested. 512 Motivation: Some jurisdictions may have multiple types of 513 emergency services available at the same level, (e.g. fire, 514 police, ambulance), in which case it is important that any one 515 could be selected directly. 517 Id3. Emergency Marking: Any device in the signaling path that 518 recognizes by some means that the signaling is associated with an 519 emergency call MUST add the emergency indication called for in Id1 520 to the signaling before forwarding it. This marking mechanism 521 must be different than QoS marking. 523 Motivation: Marking ensures proper handling as an emergency call 524 by downstream elements that may not recognize, for example, a 525 local variant of a logical emergency address. 527 Id4. Emergency Identifier-based Marking: User agents, proxies, and 528 other network elements that process signaling associated with 529 emergency calls SHOULD be configured to recognize a reasonable 530 selection of logical emergency identifiers as a means to initiate 531 emergency marking. 533 Motivation: Since user devices roam, emergency identifiers may 534 vary from region to region. It is therefore important that a 535 network entity be able to perform mapping and/or call routing 536 within the context of its own point of origin rather than relying 537 on non-local logical emergency identifiers as the only basis for 538 emergency marking of calls. 540 Id5. Prevention of Fraud: A call identified as an emergency call or 541 marked as such in accordance with the above requirements for 542 marking MUST be routed to a PSAP. 544 Motivation: this prevents use of the emergency call indication to 545 gain access to call features or authentication override for non- 546 emergency purposes. 548 Id6. Minimal configuration: Any local emergency identifiers SHOULD 549 be configured automatically, without user intervention. 551 Motivation: A new UA "unofficially imported" into an organization 552 from elsewhere should have the same emergency capabilities as one 553 officially installed. 555 Id7. Emergency Identifier Replacement: For each signaling protocol 556 that can be used in an emergency call, reserved identifiers SHOULD 557 be allowed to replace the original emergency identifier, based on 558 local conventions, regulations, or preference (e.g. as in the case 559 of an enterprise). 561 Motivation: Any signalling protocol requires the use of some 562 identifier to indicate the called party, and the user terminal may 563 lack the capability to determine the actual emergency address 564 (PSAP uri). The use of local conventions may be required as a 565 transition mechanism. Note: Such use complicates international 566 movement of the user terminal, and evolution to a standardized 567 universal emergency identifier or set of identifiers is preferred. 569 Id8. Universal Identifier Recognition: Universal identifier(s), MUST 570 be universally recognizable by any network element which supports 571 the ECRIT protocol." 573 Id9. Universal Identifier not Recognized: A call MUST be recognized 574 as emergency call even if the specific emergency service requested 575 is not recognized." 577 "Motivation: In order to have a robust system that supports 578 incremental Service deployment while still maintaining a fallback 579 capability." 581 7. Mapping Protocol 583 Given the requirement from the previous section, that of a single (or 584 small number of) emergency identifier(s) which are independent of the 585 caller's location, and since PSAPs only serve a limited geographic 586 region, and for reasons of jurisdictional and local knowledge, having 587 the call reach the appropriate PSAP based on a mapping protocol, is 588 crucial. 590 There are two basic architectures described for translating an 591 emergency identifier into the appropriate PSAP emergency address. We 592 refer to these as caller-based and mediated. 594 For caller-based resolution, the caller's user agent consults a 595 mapping service to determine the appropriate PSAP based on the 596 location provided. The resolution may take place well before the 597 actual emergency call is placed, or at the time of the call. 599 For mediated resolution, a call signaling server, such as a SIP 600 (outbound) proxy or redirect server performs this function (a request 601 for mapping) by invoking the mapping protocol. 603 Note that this case relies on an architecture where the call is 604 effectively routed to a copy of the database, rather than having some 605 non-SIP protocol query the database. 607 Since servers may be used as outbound proxy servers by clients that 608 are not in the same geographic area as the proxy server, any proxy 609 server has to be able to translate any caller location to the 610 appropriate PSAP. (A traveler may, for example, accidentally or 611 intentionally configure its home proxy server as its outbound proxy 612 server, even while far away from home.) 614 The problem at hand is more difficult to resolve than that for 615 traditional web or email services. In this case, the emergency 616 caller only dialed an emergency identifier, and depending on the 617 location, any one of several thousand PSAPs around the world could be 618 appropriate PSAP. In addition, there may be a finer resolution of 619 routing (which the caller isn't aware of), which results in a 620 particular "accredited" PSAP (i.e. one run by local authorities) 621 answering to call. (Many PSAPs are run by private entities. For 622 example, universities and corporations with large campuses often have 623 their own emergency response centers.) 624 Ma1. Appropriate PSAP: Calls MUST be routed to the PSAP responsible 625 for this particular geographic area. In particular, the location 626 determination should not be fooled by the location of IP telephony 627 gateways or dial-in lines into a corporate LAN (and dispatch 628 emergency help to the gateway or campus, rather than the caller), 629 multi-site LANs and similar arrangements. 631 Motivation: Routing to the wrong PSAP will result in delays in 632 handling emergencies as calls are redirected, and result in 633 inefficient use of PSAP resources at the initial point of contact. 635 Ma2. Mapping redirection: The mapping protocol MUST support 636 redirection functionality, since in some cases, an initial mapping 637 may provide a single URL for a large geographic area. Redirection 638 is needed to then re-invokes the mapping protocol on a different 639 database to obtain another URL for an more resolute ESRP or PSAP, 640 which covers a smaller area. 642 Motivation: The more local the mapping output is, the more 643 favourable (in most cases) the likely outcome will be for the 644 emergency caller. 646 Ma3. Minimal additional delay: The execution of the mapping protocol 647 SHOULD minimize the amount of additional delay to the overall 648 call-setup time. 650 Motivation: Since outbound proxies will likely be asked to resolve 651 the same geographic coordinates repeatedly, a suitable time- 652 limited caching mechanism should be supported. 654 Ma4. Referral: The mapping client MUST be able to contact any server 655 and be referred to another server that is more qualified to answer 656 the query. 658 Motivation: This requirement alleviates the potential for 659 incorrect configurations to cause calls to fail, particularly for 660 caller-based queries. 662 Ma5. Multiple Response URIs: The mapping protocol response MUST 663 allow the return of multiple URIs. 665 Motivation: In response to a mapping request, a server will 666 normally provide a URI or set of URIs for contacting the 667 appropriate PSAP. 669 Ma6. URI - Alternate Contact: The mapping protocol MUST be able to 670 return a URI or contact method explicitly marked as an alternate 671 contact. 673 Motivation: In response to a mapping request, if an expected URI 674 is unable to be returned, then mapping server may return an 675 alternate URI. When and how this would be used will be described 676 in an operational document. 678 Ma7. Multiple PSAP URI's: The mapping protocol MUST be able to 679 return multiple URIs for different PSAPs that cover the same area. 681 Ma8. URL properties: The mapping protocol must provide additional 682 information that allows the querying entity to determine relevant 683 properties of the URL. 685 Motivation: In some cases, the same geographic area is served by 686 several PSAPs, for example, a corporate campus might be served by 687 both a corporate security department and the municipal PSAP. The 688 mapping protocol should then return URLs for both, with 689 information allowing the querying entity to choose one or the 690 other. This determination could be made by either an ESRP, based 691 on local policy, or by direct user choice, in the case of caller- 692 based trigger methods. 694 Ma9. Traceable resolution: The entity requesting mapping SHOULD be 695 able to determine the entity or entities who provided the 696 emergency address resolution information. 698 Motivation: To provide operational traceability in case of errors. 700 Ma10. Resilience against server failure: A client MUST be able to 701 fail over to another replica of the mapping server, so that a 702 failure of a server does not endanger the ability to perform the 703 mapping. 705 Ma11. Incrementally deployable: The mapping function MUST be capable 706 of being deployed incrementally. 708 Motivation: It must not be necessary, for example, to have a 709 global street level database before deploying the system. It is 710 acceptable to have some misrouting of calls when the database does 711 not (yet) contain accurate boundary information. 713 Ma12. Verify mapping support: The mapping protocol SHOULD support 714 the ability for a requesting entity to verify that mapping 715 services are available for a referenced location. 717 Motivation: It should be possible to make sure ahead of time, that 718 requests for emergency services will work when needed. 720 Ma13. Mapping requested from anywhere: The mapping protocol MUST be 721 able to provide the mapping regardless of where the mapping client 722 is located, either geographically or by network location. 724 Motivation: The mapping client, (such as the ESRP), may not 725 necessarily be anywhere close to the caller or the appropriate 726 PSAP, but must still be able to obtain a mapping. 728 Ma14. Location Updates: It SHOULD be possible to have updates of 729 location. 731 Motivation: Updated location information may have an impact on 732 PSAP routing. In some cases it may be possible to redirect that 733 call to a more appropriate PSAP (some device measurement 734 techniques provide quick (i.e. early), but imprecise "first fix" 735 location). 737 Ma15. Extensible Protocol: The mapping protocol MUST be extensible 738 to allow for the inclusion of new location fields. 740 Motivation: This is needed, for example, to accommodate future 741 extensions to location information that might be included in the 742 PIDF-LO (RFC 4119 [2]). 744 Ma16. Split responsibility: The mapping protocol MUST allow that 745 within a single level of the civic location hierarchy, multiple 746 mapping servers handle subsets of the data elements. 748 Motivation: For example, two directories for the same city or 749 county may handle different streets within that city or county. 751 Ma17. Pervasive Mapping: The mapping function MUST be able to be 752 invoked at any time, including while an emergency call is in 753 process. 755 Ma18. Baseline query protocol: A mandatory-to-implement protocol 756 MUST be specified. 758 Motivation: An over-abundance of similarly-capable choices appears 759 undesirable for interoperability. 761 Ma19. Single URI Scheme: The mapping protocol MAY return multiple 762 URIs, though it SHOULD return only one URI per scheme, so that 763 clients are not required to select among different targets for the 764 same contact protocol. 766 Motivation: There may be two or more URIs returned when multiple 767 contact protocols are available (e.g. SIP and SMS). The client 768 may select among multiple contact protocols based on its 769 capabilities, preference settings, or availability. 771 8. Security Considerations 773 Note: Security Considerations are referenced in the ECRIT security 774 document [3]. 776 9. Contributors 778 The information contained in this document is a result of a joint 779 effort based on individual contributions by those involved in the 780 ECRIT WG. The contributors include Nadine Abbott, Hideki Arai, 781 Martin Dawson, Motoharu Kawanishi, Brian Rosen, Richard Stastny, 782 Martin Thomson, James Winterbottom. 784 The contributors can be reached at: 786 Nadine Abbott nabbott@telcordia.com 788 Hideki Arai arai859@oki.com 790 Martin Dawson Martin.Dawson@andrew.com 792 Motoharu Kawanishi kawanishi381@oki.com 794 Brian Rosen br@brianrosen.net 796 Richard Stastny Richard.Stastny@oefeg.at 798 Martin Thomson Martin.Thomson@andrew.com 800 James Winterbottom James.Winterbottom@andrew.com 802 10. Acknowledgments 804 We would like to thank Michael Hammer, Ted Hardie, Marc Linsner, 805 Andrew Newton, James Polk, Tom Taylor, and Hannes Tschofenig for 806 their input. 808 11. References 810 11.1. Normative References 812 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 813 Levels", BCP 14, RFC 2119, March 1997. 815 [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 816 RFC 4119, December 2005. 818 [3] Schulzrinne, H., "Security Threats and Requirements for 819 Emergency Calling", draft-taylor-ecrit-security-threats-01 (work 820 in progress), December 2005. 822 [4] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 823 draft-schulzrinne-sipping-service-01 (work in progress), 824 October 2005. 826 11.2. Informative References 828 [5] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van 829 Wijk, "User Requirements for the Session Initiation Protocol 830 (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired 831 Individuals", RFC 3351, August 2002. 833 [6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 834 Polk, "Geopriv Requirements", RFC 3693, February 2004. 836 [7] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", 837 RFC 4103, June 2005. 839 [8] Wijk, A., "Framework of requirements for real-time text 840 conversation using SIP", draft-ietf-sipping-toip-03 (work in 841 progress), September 2005. 843 Authors' Addresses 845 Henning Schulzrinne 846 Columbia University 847 Department of Computer Science 848 450 Computer Science Building 849 New York, NY 10027 850 US 852 Phone: +1 212 939 7004 853 Email: hgs+ecrit@cs.columbia.edu 854 URI: http://www.cs.columbia.edu 856 Roger Marshall (editor) 857 TeleCommunication Systems 858 2401 Elliott Avenue 859 2nd Floor 860 Seattle, WA 98121 861 US 863 Phone: +1 206 792 2424 864 Email: rmarshall@telecomsys.com 865 URI: http://www.telecomsys.com 867 Intellectual Property Statement 869 The IETF takes no position regarding the validity or scope of any 870 Intellectual Property Rights or other rights that might be claimed to 871 pertain to the implementation or use of the technology described in 872 this document or the extent to which any license under such rights 873 might or might not be available; nor does it represent that it has 874 made any independent effort to identify any such rights. Information 875 on the procedures with respect to rights in RFC documents can be 876 found in BCP 78 and BCP 79. 878 Copies of IPR disclosures made to the IETF Secretariat and any 879 assurances of licenses to be made available, or the result of an 880 attempt made to obtain a general license or permission for the use of 881 such proprietary rights by implementers or users of this 882 specification can be obtained from the IETF on-line IPR repository at 883 http://www.ietf.org/ipr. 885 The IETF invites any interested party to bring to its attention any 886 copyrights, patents or patent applications, or other proprietary 887 rights that may cover technology that may be required to implement 888 this standard. Please address the information to the IETF at 889 ietf-ipr@ietf.org. 891 Disclaimer of Validity 893 This document and the information contained herein are provided on an 894 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 895 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 896 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 897 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 898 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 901 Copyright Statement 903 Copyright (C) The Internet Society (2005). This document is subject 904 to the rights, licenses and restrictions contained in BCP 78, and 905 except as set forth therein, the authors retain all their rights. 907 Acknowledgment 909 Funding for the RFC Editor function is currently provided by the 910 Internet Society.