idnits 2.17.1 draft-ietf-ecrit-framework-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1350. ** 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 issues found here. 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 == Line 139 has weird spacing: '... Server see [...' == 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 (October 15, 2006) is 6400 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) -- Looks like a reference, but probably isn't: '3' on line 294 -- Looks like a reference, but probably isn't: '6' on line 296 -- Looks like a reference, but probably isn't: '7' on line 296 -- Looks like a reference, but probably isn't: '4' on line 298 -- Looks like a reference, but probably isn't: '5' on line 298 -- Looks like a reference, but probably isn't: '8' on line 298 -- Looks like a reference, but probably isn't: '9' on line 298 == Missing Reference: 'M7' is mentioned on line 394, but not defined == Missing Reference: 'M8' is mentioned on line 397, but not defined == Missing Reference: 'M9' is mentioned on line 399, but not defined == Missing Reference: 'M10' is mentioned on line 402, but not defined == Missing Reference: 'M11' is mentioned on line 404, but not defined == Missing Reference: 'M1' is mentioned on line 379, but not defined == Missing Reference: 'M2' is mentioned on line 381, but not defined == Missing Reference: 'M3' is mentioned on line 383, but not defined == Missing Reference: 'M4' is mentioned on line 385, but not defined == Missing Reference: 'M5' is mentioned on line 387, but not defined == Missing Reference: 'M6' is mentioned on line 389, but not defined == Missing Reference: 'M12' is mentioned on line 406, but not defined == Unused Reference: 'I-D.ietf-sipping-config-framework' is defined on line 1163, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-02 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-12 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-requirements (ref. 'I-D.ietf-ecrit-requirements') == Outdated reference: A later version (-07) exists of draft-ietf-ecrit-service-urn-05 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-10 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-09 == Outdated reference: A later version (-05) exists of draft-rosen-iptel-dialstring-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-11 Summary: 12 errors (**), 0 flaws (~~), 24 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track H. Schulzrinne 5 Expires: April 18, 2007 Columbia U. 6 J. Polk 7 Cisco Systems 8 A. Newton 9 SunRocket 10 October 15, 2006 12 Framework for Emergency Calling in Internet Multimedia 13 draft-ietf-ecrit-framework-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 18, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Summoning emergency help by the public is a core feature of telephone 47 networks. This document describes a framework of how various IETF 48 protocols and mechanisms are combined to place emergency calls. This 49 includes how these calls are routed to the correct Public Safety 50 Answering Point (PSAP) based on the physical location of the caller, 51 while providing the call taker the necessary information to dispatch 52 a first responder to that location. This document explains how 53 location mapping, call identification and end system behavior are 54 combined to allow multimedia emergency calls. It describes at a high 55 level how the pieces (recognizing a call as an emergency call, 56 marking it as such, determining the location of the caller, routing 57 the call based on location) go together, and references the Internet 58 standards that define the details of these mechanisms. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Overview of How Emergency Calls are Placed . . . . . . . . . . 7 65 4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 11 66 5. Location and Its Role in an Emergency Call . . . . . . . . . . 12 67 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.2. Types of Location Information . . . . . . . . . . . . . . 12 69 5.3. Location Determination . . . . . . . . . . . . . . . . . . 13 70 5.3.1. User-Entered Location Information . . . . . . . . . . 14 71 5.3.2. Access Network "Wire Database" Location Information . 14 72 5.3.3. End-System Measured Location Information . . . . . . . 15 73 5.3.4. Third-party Measured Location Information . . . . . . 15 74 5.4. Location and References to Location . . . . . . . . . . . 16 75 5.5. End System Location Configuration . . . . . . . . . . . . 16 76 5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 17 77 5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 18 78 5.8. Location Validation . . . . . . . . . . . . . . . . . . . 19 79 5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 19 80 6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 19 81 7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 21 82 8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 21 83 9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 21 84 10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 22 85 11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 22 86 12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 23 89 15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 23 90 15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 16. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 24 93 16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 24 94 16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 24 95 16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 25 96 16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 25 97 16.6. Media Integrity and Confidentiality . . . . . . . . . . . 25 98 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 99 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 18.1. Normative References . . . . . . . . . . . . . . . . . . . 26 101 18.2. Informative References . . . . . . . . . . . . . . . . . . 29 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 103 Intellectual Property and Copyright Statements . . . . . . . . . . 31 105 1. Terminology 107 As a framework document, we do not define any new protocols or 108 articulate new behaviors. Thus we do not use RFC2119 [RFC2119] 109 notation. In this document, we reuse terms, and their definition, 110 from [I-D.ietf-ecrit-requirements]. In addition, the following terms 111 are used: 112 (Emergency) call taker: see [I-D.ietf-ecrit-requirements] 113 ESRP (emergency service routing proxy): see 114 [I-D.ietf-ecrit-requirements] 115 Access Network: The wide area network that supplies IP packet 116 service to an endpoint. In a residential or small business 117 environment, this might be a DSL or cable modem or WiMax service. 118 In a large enterprise environment, this would be the enterprise 119 network. In a mobile environment, this might be a mobile 120 (cellular) data network or a WiFi network. 121 Location Configuration: The process by which an endpoint learns its 122 physical location. 123 Location Conveyance: The process of sending location to another 124 element. 125 Location Determination: The mechanism used to resolve where an 126 endpoint is physically. For example, the endpoint may have a GPS 127 receiver. 128 Location Information Server An element that stores location 129 information for retrieval by an authorized entity 130 Location Validation: see [I-D.ietf-ecrit-requirements] 131 Mapping: see [I-D.ietf-ecrit-requirements] 132 NENA (National Emergency Number Association: A North American 133 organization of public safety focused individuals defining 134 emergency calling specifications and procedures. 135 PSAP (public safety answering point): see 136 [I-D.ietf-ecrit-requirements] 137 SIP B2BUA see [RFC3261] 138 SIP proxy: see [RFC3261]. 139 SIP Server see [RFC3261] 140 SIP UA (user agent): see [RFC3261]. 141 Stationary device (user): An immobile user agent that is connected 142 to the network at a fixed, long-term-stable geographic location. 143 Examples include a home PC or a payphone. 144 Nomadic device (user): User agent that is connected to the network 145 temporarily, for relatively short durations, but does not move 146 significantly during the lifetime of a network connection or 147 during the emergency call. Examples include a laptop using an 148 802.11 hotspot or a desk IP phone that is moved from one cubicle 149 to another. 151 Mobile device (user): User agent that changes geographic location 152 and possibly its network attachment point during an emergency 153 call. 155 2. Introduction 157 Summoning police, the fire department or an ambulance in emergencies 158 is one of the fundamental and most-valued functions of the telephone. 159 As telephone functionality moves from circuit-switched telephony to 160 Internet telephony, its users rightfully expect that this core 161 functionality will continue to work at least as well as it has for 162 the older technology. New devices and services are being made 163 available which could be used to make a request for help which are 164 not traditional telephones, and users are increasingly expecting them 165 to be used to place emergency calls. However, many of the technical 166 advantages of Internet multimedia require re-thinking of the 167 traditional emergency calling architecture. This challenge also 168 offers an opportunity to improve the operation of emergency calling 169 technology, while potentially lowering its cost and complexity. 171 It is beyond the scope of this document to enumerate and discuss all 172 the differences between traditional (PSTN) and Internet telephony, 173 but the core differences can be summarized as: 174 o the separation/interleaving of signaling and media data packets; 175 o the interleaving over the same infrastructure of what is an 176 emergency call with non-emergency traffic, whether that other 177 traffic is another type of call or other Internet-based traffic 178 such as email or web browsing 179 o the emergence of application-independent carriers; 180 o the plethora of different media that can be accommodated; 181 o potential mobility of all end systems, including endpoints 182 nominally thought of as fixed systems and not just those using 183 radio access technology. For example, a wired phone connected to 184 a router using a mobile data network such as EV-DO as an uplink; 186 This document focuses on how devices using the Internet can place 187 emergency calls and how PSAPs can natively handle Internet multimedia 188 emergency calls, rather than describing how circuit-switched PSAPs 189 can handle VoIP calls. In many cases, PSAPs making the transition 190 from circuit-switched interfaces to packet-switched interfaces may be 191 able to use some of the mechanisms described here, in combination 192 with gateways that translate packet-switched calls into legacy 193 interfaces, e.g., to continue to be able to use existing call taker 194 equipment. 196 We distinguish an individual request for help, usually accomplished 197 by dialing a short digit sequence like 9-1-1 or 1-1-2 from a call 198 placed by specially designated persons who have authority to claim 199 priority on available Internet communications facilities. This 200 document only discusses the former - a request for help by an 201 ordinary user answered at an emergency call center (i.e. a PSAP). 203 Existing emergency call systems are organized locally/nationally; 204 there are currently no international standards. However, the 205 Internet does not respect national boundaries, and thus international 206 standards for equipment and software required. To further complicate 207 matters, VoIP endpoints can be connected through tunneling mechanisms 208 such as virtual private networks (VPNs). This significantly 209 complicates emergency calling, because the location of the caller and 210 the first element that routes emergency calls can be on different 211 continents, with different conventions and processes for handling of 212 emergency calls. 214 The IETF has historically refused to create national variants of its 215 standards. Thus, this document attempts to take into account best 216 practices that have evolved for circuit switched PSAPs, but makes no 217 assumptions on particular operating practices currently in use, 218 numbering schemes or organizational structures. 220 This document discusses the use of the Session Initiation Protocol 221 (SIP) by PSAPs and calling parties. While other inter-domain call 222 signaling protocols may be used for emergency calling, SIP is 223 ubiquitous and possesses, through its related specifications, more of 224 the needed features for the proper support of this use case. Only 225 protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable for 226 inter-domain communications, ruling out master-slave protocols such 227 as MGCP or H.248/Megaco. The latter protocols can naturally be used 228 by the enterprise or carrier placing the call, but any such call 229 would reach the PSAP through a media gateway controller, similar to 230 how interdomain VoIP calls would be placed. Other signaling 231 protocols may also use protocol translation to communicate with a 232 SIP-enabled PSAP. 234 Existing emergency services rely exclusively on voice and 235 conventional text telephony (known as TTY in the United States) media 236 streams. However, more choices of media offer additional ways to 237 communicate and evaluate the situation as well as to assist callers 238 and call takers to handle emergency calls. For example, instant 239 messaging and video could improve the ability to communicate and 240 evaluate the situation and to provide appropriate instruction prior 241 to arrival of emergency crews. Thus, the architecture described here 242 supports the creation of sessions of any media type, negotiated 243 between the caller and PSAP using existing SIP protocol mechanisms 244 [RFC3264]. To ensure that at least one common means of 245 communications, this document recommends certain minimal capabilities 246 in [phonebcp] that call taker user agents and PSAP-operated proxies 247 should possess. 249 This document does not prescribe the detailed network architecture 250 for a PSAP or collection of PSAPs. For example, it does not describe 251 where PSAPs may place firewalls or how many SIP proxies they should 252 use. 254 This document does not introduce any new SIP header fields, request 255 methods, status codes, message bodies, or event packages. User 256 agents unaware of the recommendations in this draft can place 257 emergency calls, but may not be able to provide the same elevated 258 user interface functionality. The document suggests behavior for 259 proxy servers, in particular outbound proxy servers. 261 3. Overview of How Emergency Calls are Placed 263 We distinguish (Section 4) an emergency call from any other call by a 264 unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in 265 the initial call set-up signaling when a home or visited dialstring 266 is detected. We route emergency calls based on the location ( 267 (Section 5)) of the caller. To get this location we either include a 268 form of measuring (e.g. GPS) ( (Section 5.3.3)) device location in 269 the endpoint, or the endpoint is configured ( (Section 5.5)) with its 270 location from the access network's Location Information Server (LIS) 271 The location is conveyed ( (Section 5.6)) in the SIP signaling with 272 the call. We route( (Section 6)) the call based on location using 273 the LoST protocol ( [I-D.ietf-ecrit-lost]) which maps a location to a 274 set of PSAP URIs. Each URI resolves to a PSAP or an Emergency 275 Services Routing Proxy which serves a group of PSAPs. The call 276 arrives at the PSAP with the location included in the INVITE request. 278 Configuration Servers 279 . . . . . . . . . . . . . . . . . 280 . . 281 . +--------+ +----------+ . 282 . +--------+ | +----------+ | . 283 . | LIS | | | SIP | | . 284 . | |-+ | Registrar|-+ . 285 . +--------+ +----------+ . 286 . ^ ^ . 287 . . | . . . . . . . | . . . . . . 288 | | 289 |[1] |[2] 290 | | +--------+ 291 |+--------------+ +--------+ | 292 || | LoST | | 293 ||+-------------------->| Servers|-+ 294 ||| [3] +--------+ +-------+ 295 ||| ^ | | PSAP2 | 296 ||| [6] | | [7] +-------+ 297 ||| | v 298 ||| [4] +-------+ [5] +------+ [8] +-------+ [9] 299 Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 300 +-------+ +------+ +-------+ 302 +-------+ 303 | PSAP3 | 304 +-------+ 306 Figure 1: Generic ECRIT Component Topology 308 Figure 2 shows a generic emergency call establishment. This includes 309 the following: 310 o Alice - who will make the emergency call. 311 o Configuration Servers - Servers providing Alice's UA its IP 312 address and other configuration information, perhaps including 313 Location by-value or by-reference. In this flow, we use DHCP as 314 an example location acquisition protocol. To make this flow 315 easier to read, these configuration servers include a SIP 316 Registrar server, for Alice's UA to register with the local 317 domain, which will most likely be the case for an emergency call. 318 All these configuration messages are labeled M1 through M4, but 319 could easily require more messages than 4 to complete. 320 o ESRP - The Emergency Services Routing Proxy Server that recognizes 321 any INVITE as an emergency session initiation, and does special 322 things (knows to look for Location in the INVITE, dereferences a 323 location-by-reference, initiated a LoST Query to learn the PSAP 324 SIP(S)-URI for a UA at this location, etc). ESRPs are optional 325 elements and in some jurisdictions an emergency call may not pass 326 through one 327 o Mapping Server - Processes the LoST request for Location to PSAP- 328 URI Mapping function, either for an initial request from a UA, or 329 an in-call establishment request by an ESRP. 330 o PSAP - Call center where emergency calls are destined for in times 331 of emergencies. 333 Generally, Alice's UA either has location configured within her UA 334 when her UA boots, or she configures it with location once it boots 335 up, or her UA receives measured location from the network. Her UA 336 may have asked for location during boot-time, for example in a 337 DHCPREQUEST message or another location acquisition mechanism. 338 Alice's UA then will most likely register with a SIP domain. This 339 allows her to be contacted by other SIP entities. Next, her UA will 340 perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn an 341 early URI, for use if the Lost Query fails during an emergency call. 342 This learned early PSAP-URI will be placed in a Route header within 343 an emergency INVITE message, message [M7] in Figure 1. 345 Some time has hopefully passed since Alice's UA booted. In this 346 example, she dials or initiated an emergency call. This may have 347 been through her keypad with her locally known emergency dialstring. 348 It is important that this dialstring be recognized by her UA wherever 349 Alice is because she may be in enough distress she forgets what the 350 traveled-to emergency dialstring is; as there are more than 60 around 351 the world. 353 This emergency INVITE arrives at a SIP Proxy that understands the 354 concept of emergency calling, meaning it is an ESRP. In recognizing 355 the INVITE as an emergency call set-up, the ESRP looks for Location 356 within the message. [I-D.ietf-sip-location-conveyance] defines a SIP 357 Location header that either contain the location-by-reference URI, or 358 a [RFC2396] "cid:" indicating where in the message body the location- 359 by-value is. The ESRP can dereference the UA provided Location URI, 360 and insert the location information from the PIDF-LO into the LoST 361 query. This will prevent any problems of the LoST Mapping server 362 experiencing dereferencing problems with this request. This is 363 message [M7] and [M8] in Figure 1. The LoST response provides the 364 ESRP with the freshest PSAP-URI for that location (of Alice's UA) for 365 the most up to date routing choice. This is message [M9]. 367 The INVITE message receives a new Request-URI in the ESRP, which was 368 returned in the LoST response. This message, [M10] is transmitted 369 towards the most current PSAP for Alice's location. Message [M11], 370 the 200 OK to the INVITE may traverse one or more proxies if they 371 insert a Via header, or if one or more are B2BUAs. Figure 1 does not 372 show this. The ACK completes the call set-up and the emergency call 373 is established, allowing the PSAP call-taker to talk to Alice about 374 her emergency. 376 Configuration LoST 377 Alice Servers ESRP Server PSAP 379 [M1] DHCP Request(s) (may ask for Location) 380 ----------> 381 [M2] DHCP Reply(s) (replies with location if asked) 382 <--------- 383 [M3] SIP REGISTER (perhaps with PIDF-LO) 384 ----------> 385 [M4] SIP 200 OK (REGISTER) 386 <--------- 387 [M5] Initial LoST Protocol Query (contains Location) 388 ----------------------------------------> 389 [M6] Initial LoST Protocol Response (contains PSAP-URI) 390 <---------------------------------------- 392 ***Some time later, Alice dials/initiates emergency call*** 394 [M7] INVITE (sos, Location & early Mapping URI) 395 ---------------------> 397 [M8] LoST Protocol Query (with Location) 398 -----------------> 399 [M9] LoST Protocol Response (with PSAP-URI) 400 <----------------- 402 [M10] INVITE (sos, Location & PSAP-URI) 403 --------------------------------------> 404 [M11] 200 OK 405 <-------------------------------------------------------------- 406 [M12] ACK 407 --------------------------------------------------------------> 408 Emergency Session Established 409 <=============================================================> 411 Figure 2: General Flow of an Emergency Call Establishment 413 This is a very rough example of the operation of an emergency call 414 establishment. There are no layer 3 routers in the message flow, and 415 whatever security messages exist in the call are not shown either. 416 Each of those aspects will be addressed individually, to keep each 417 discussion in context of that subject, for clarity. 419 4. Identifying an Emergency Call 421 Using the PSTN, emergency help can often be summoned by dialing a 422 nationally designated, widely known number, regardless of where the 423 telephone was purchased. The appropriate number is determined by 424 which infrastructure the telephone is connected to. However, this 425 number differs between localities, even though it is often the same 426 for a country or region, such as many countries in the European 427 Union. In some countries, there is a single digit sequence that is 428 used for all types of emergencies. In others, there are several 429 sequences that are specific to the responder, e.g., one for police, 430 another for fire. It is deemed impractical to change the dialed 431 digits to summon help. For end systems, it is desirable to have a 432 universal identifier, independent of location, to allow the automated 433 inclusion of location information and to allow the device and other 434 entities in the call path to perform appropriate processing within 435 the signaling protocol in an emergency call set-up. 437 As part of the overall emergency calling architecture, we define 438 common emergency call URIs which are defined in 439 [I-D.ietf-ecrit-service-urn]. Users are not expected to "dial" an 440 emergency URN. Rather, the current dial sequence should be 441 translated to the appropriate service URN. Such translation could 442 ideally be performed in the endpoint, but could be performed in a 443 signaling intermediary (proxy server). For devices that are mobile 444 or nomadic, an issue arises of whether the home or visited dialing 445 strings should be used. Many users would prefer that their home 446 dialing sequences work no matter where they are. Local laws and 447 preferences of the emergency response professionals are that the 448 visited dialing sequences be used. The best answer seems to be for 449 both to work. 451 The mechanism for obtaining the dialing sequences for a given 452 location is provided by LoST [I-D.ietf-ecrit-lost] and the procedures 453 for the translation are detailed in [phonebcp]. Where the endpoint 454 does not support the translation of dialstrings to telephone numbers, 455 the dialing sequence would be represented as a dialstring 456 [I-D.rosen-iptel-dialstring] and the outgoing proxy would recognize 457 the dialstring and translate to the service URN. It should be noted 458 that the endpoint would not normally supply location unless it 459 understood the call to be an emergency call. To determine the local 460 dialstring, the proxy needs the location of the endpoint. This may 461 be difficult in situations where the user can roam or be nomadic. 462 Endpoint recognition of emergency dialstrings is therefore preferred. 464 5. Location and Its Role in an Emergency Call 466 5.1. Introduction 468 Caller location plays a central role in routing emergency calls. For 469 practical reasons, each PSAP generally handles only calls for a 470 certain geographic area (overload arrangements between PSAPs to 471 handle each others calls notwithstanding). Other calls that reach it 472 by accident must be manually re-routed (transferred) to the 473 appropriate PSAP, increasing call handling delay and the chance for 474 errors. The area covered by each PSAP differs by jurisdiction, where 475 some countries have only a small number of PSAPs, while others 476 decentralize PSAP responsibilities to the level of counties or 477 municipalities. 479 In most cases, PSAPs cover at least a city or town, but there are 480 some areas where PSAP coverage areas follow old telephone rate center 481 boundaries and may straddle more than one city. Irregular boundaries 482 are common, often for historical reasons. Routing must be done on 483 PSAP service boundaries, not "closest" or "best fit" algorithms. 485 5.2. Types of Location Information 487 There are four primary types of location information: civic, postal, 488 geospatial, and cellular cell tower and sector. 490 Civic: Civic location information describes the location of a person 491 or object by a street address that corresponds to a building or 492 other structure. (This is sometimes also called "civil" location 493 information.) Civic location may include more finer grained 494 location information such as floor, room, cubicle. Civic 495 information comes in two forms: 496 Jurisdictional - This refers to a civic location using actual 497 political subdivisions, especially for the community name. 498 Postal - This refers to a civic location used to mail a letter 499 to. The name of the post office sometimes does not correspond 500 to the actual community name and a postal addrress may contain 501 post office boxes or street addresses that do not correspond to 502 an actual building. Postal addresses are generally unsuitable 503 for emergency call routing, but may be the only address 504 available. 505 Geospatial: Geospatial addresses contain longitude, latitude and 506 altitude information based on an understood datum (starting point) 507 and earth shape model. While there have been many datums 508 developed over time, most modern systems are using or moving 509 towards WGS84. 511 Cell tower/sector: Cell tower and sectors identify the cell tower 512 and the antenna sector that the mobile device is currently using. 513 Traditionally, the tower location is expressed as a point, and 514 routing decisions are made on that point. Cell/sector information 515 could also be transmitted as an irregularly shaped polygon of 516 geospatial coordinates reflecting the likely geospatial location 517 of the mobile device. 519 In IETF protocols, civic and geo forms are both supported. The civic 520 forms include both the postal and jurisdictional fields. The cell 521 tower/sector can be represented as a point. 523 5.3. Location Determination 525 Location information can be entered by the user or installer of a 526 device ("manual configuration"), can be measured by the end system, 527 can be delivered to the end system by some protocol or can be 528 measured by a third party and inserted into the call signaling. We 529 discuss these in detail below. 531 In some cases, an entity may have multiple sources of location 532 information, possibly partially contradictory. This is particularly 533 likely if the location information is determined both by the end 534 system and a third party. Handling multiple locations is discussed 535 in XRef??. Conflicting location information is particularly harmful 536 if it points to multiple distinct PSAPs. Guidelines for dealing with 537 multiple locations is given in [phonebcp]. 539 All location objects MUST be delivered to the PSAP. To facilitate 540 such policy decisions, location information should contain 541 information about the source of data, such as GPS, manually entered 542 or based on access network topology. In addition, the generator of 543 the location information should be included. The ability of the UA 544 to understand how it learned its location, and include this 545 information element in the location object that is sent to the PSAP, 546 provides the call-taker with many pieces of information to make 547 decisions upon, and ask the caller with. 549 The call should indicate which location information has been used for 550 routing, so that the same location information is used for all call 551 routing decisions. Otherwise, two proxies might pick different 552 location information from the call request, resulting in different 553 routing decisions for different transactions. 555 End systems and network elements can derive location information from 556 a variety of sources. It is not the goal of this document to 557 exhaustively enumerate them, but we provide a few common examples in 558 the sections below. 560 5.3.1. User-Entered Location Information 562 Location information can be maintained by the end user or the 563 installer of an endpoint in the endpoint itself, or in a database. 565 Location information added by end users is almost always inferior to 566 measured or wire database information, as users may mistype civic 567 location information, may not know the meaning of geospatial 568 coordinates or may use address information that does not correspond 569 to a recognized civic address. A user-entered location can fail to 570 be changed when the location of a device changes during or after 571 movement. For example, a user could move their residence to another 572 dwelling, not update their device/equipment with this new location, 573 and place an emergency call with old location information. 575 All that said, there are always a small number of cases where the 576 mechanisms used by the access network to determine location fail to 577 accurately reflect the actual location of the endpoint. For example, 578 the user may deploy his own WAN behind an access network, effectively 579 remoting an endpoint some distance from the access network's notion 580 of its location. There must be some mechanism provided to provision 581 a location for an endpoint by the user or by the access network on 582 behalf of a user. The use of the mechanism introduces the 583 possibility of users falsely declaring themselves to be somewhere 584 they are not. As an aside, normally, if an emergency caller insists 585 he is at a location different from what any automatic location 586 determination system reports he is, responders will always be sent to 587 the user's self-declared location. However this is a matter of local 588 policy and is outside the scope of this document. 590 5.3.2. Access Network "Wire Database" Location Information 592 Location information can be maintained by the access network, 593 relating some form of identifier for the end subscriber or device to 594 a location database ("wire database"). In enterprise LANs, wiremap 595 databases map Ethernet switch ports to building layouts at known 596 locations. In DSL installations, the local telephone carrier 597 maintains a mapping of wire-pairs to subscriber addresses. 599 Even for IEEE 802.11 wireless access points, wire databases may 600 provide sufficient location resolution; the location of the access 601 point may be sufficient location information for each of the clients 602 served by that access point. This may be the connectivity type for 603 both residential users of DSL and Cable Modem installations, as well 604 as the only infrastructure at a WiFi hotspot, such as a coffee shop. 605 Each of these cases will have a known civic address of the dwelling/ 606 business, likely providing sufficient location resolution. 608 Wire databases to the home are likely to be the most promising 609 solution for residential users where a service provider knows the 610 customer's service address. The service provider can then perform 611 address verification, similar to the current system in some 612 jurisdictions. 614 5.3.3. End-System Measured Location Information 616 Global Positioning System (GPS) sensors may be embedded directly in 617 the end device. GPS produces relatively high precision location 618 fixes in open-sky conditions, but the technology still faces several 619 challenges in terms of performance (time-to-fix and time-to-first- 620 fix), as well as obtaining successful location fixes within shielded 621 structures, or underneath the ground (tunnels, basements, etc.). It 622 also requires all devices to be equipped with the appropriate GPS 623 capability. GPS technology is improving, and is increasingly 624 successful in more difficult conditions such as dense urban canyons 625 and inside commercial structures. It is currently accurate to tens 626 of meters using some kind of "assist", which may be operated by the 627 access network (A-GPS) or by a government (WAAS). Newer multi- 628 frequency systems will improve accuracy without assist. 630 GPS equipped devices vary depending on which element initiates 631 requests, which element actually determines final location, assist 632 mechanisms, etc. Some common implementations include: 633 1. GPS S/A (standalone), device initiated 634 2. GPS S/A, network initiated 635 3. AGPS-device initiated, network determined 636 4. AGPS-device initiated, network augmented 637 5. AGPS-network initiated, network determined 638 6. AGPS-network initiated, network augmented 640 5.3.4. Third-party Measured Location Information 642 Wireless triangulation: Elements in the network infrastructure 643 triangulate end systems based on signal strength, angle of arrival 644 or time of arrival. Common mechanisms deployed include. 645 1. Time Difference Of Arrival - TDOA 646 2. Uplink Time Difference Of Arrival - U-TDOA 647 3. Angle of Arrival - AOA 648 4. RF-Fingerprinting 649 5. Advanced Forward Link Trilateration - AFLT 650 6. Enhanced Forward Link Trilateration - EFLT 651 Sometimes triangulation and measured mechanisms are combined, for 652 example A-GPS with AFLT 654 Location beacons: A short range wireless beacon, e.g., using 655 Bluetooth or infrared, announces its location to mobile devices in 656 the vicinity. 658 5.4. Location and References to Location 660 Location information may be expressed as the actual civic or geo 661 value but can transmitted as by-value (wholly contained within the 662 signaling message) or by-reference (a URI pointing to the value 663 residing on a remote node waiting to be dereferenced). There are 664 pros and cons to each form: 665 location-by-value: 666 pro- Value available to each device along the path immediately 667 for further processing. 668 con- Size, especially if constrained to a UDP transport. Value 669 fixed at the time the value is acquired from the access 670 network. Value can be changed by endpoint, which may be 671 considered untrustworthy for this critical usage. 672 location-by-reference 673 pro- 'Small size. Value can fixed at time of dereference. Value 674 cannot be changed by endpoint 675 con- URI resolution requires location source be available and 676 accessible by dereferencer. Dereferencing takes time. 677 Dereferencing may fail. 679 5.5. End System Location Configuration 681 Unless a user agent has access to provisioned or locally measured 682 location information, it must obtain it from the access network. 683 There are several Location Configuration Protocols that can be used 684 for this purpose. 686 DHCP can deliver civic [I-D.ietf-geopriv-dhcp-civil] or geospatial 687 [RFC3825] information. User agents would need to support both 688 formats. Note that a user agent can use DHCP, via the DHCP 689 REQUEST or INFORM messages, even if it uses other means to acquire 690 its IP address. 691 Insert reference to L7 acquisition protocol document> is another 692 choice. 693 Link-Layer Discovery Protocol [LLDP]), with proposed extensions 694 [LLDP-MED], may also be used to deliver location information. 695 SUPL OASIS is yet another choice. 697 Other LCPs may be devised by other standards bodies. Each LCP has 698 limitations in the kinds of networks that can reasonably support it. 699 For this reason, it is not possible to choose a single mandatory to 700 deploy LCP. For endpoints with common network connections (such as 701 an Ethernet jack or a WiFi connection), unless every network 702 supported every protocol, or alternatively, every device supported 703 every protocol, serious incompatibilities would ensue. [phonebcp] 704 contains a (short) list of protocols such devices must support. 706 Where an access network can control the specification of EVERY 707 endpoint that could make an emergency call that is directly connected 708 to the network, or indirectly connected (for example, a device on a 709 LAN behind a network attachment unit), it may specify any protocol it 710 wishes for each endpoint. This is a very unusual case; nearly every 711 access network can be used to support an Ethernet based LAN behind 712 it. For example, existing mobile networks are being used to support 713 routers and LANs behind a wireless data network WAN connection. It 714 is possible that the access network supports a protocol not on the 715 phonebcp list, but another element which the access network provider 716 controls the specification of can acquire location using that 717 protocol and then that element can support one of the phonebcp's list 718 of protocols. For example, if the access network provider supplies a 719 router which includes a DHCP server, it can acquire location using an 720 access network specific protocol, and use the location information to 721 supply it to its clients via DHCP. 723 For most networks, it will not be practical to control the 724 specification of every device, or arrange interworking with network 725 specific LCPs. For this reason, most devices will need to support 726 ALL of the LCPs in [phonebcp], and access networks will have to 727 support at least one of these LCPs. 729 Location for non-mobile devices is normally expected to be acquired 730 at network attachment time and retained by the device. It should be 731 refreshed when the cached value becomes invalid (for example, if DHCP 732 is the acquisition protocol, refresh of location may occur when the 733 IP address lease is renewed). At the time of an emergency call, the 734 location should be refreshed, with the retained location used if the 735 location acquisition does not immediately return a value. Mobile 736 devices may determine location at network attachment time and 737 periodically thereafter as a backup in case location determination at 738 the time of call does not work. Mobile device location may be 739 refreshed when a TTL expires, the device moves beyond some 740 boundaries, etc. Normally, mobile devices will acquire its location 741 at call time for use in an emergency call, but see Section 5.7 743 5.6. Conveyance of Location 745 When an emergency call is placed, the endpoint (normally) puts 746 location information in the signaling with the call. We refer to 747 that as "conveyance" to distinguish it from "acquisition". 748 Acquisition gets location from access network to endpoint, conveyance 749 sends location from endpoint to elements that route the call based on 750 that location object and the PSAP. Using SIP, the location 751 information is conveyed following the procedures in 752 [I-D.ietf-sip-location-conveyance]. The form of the location 753 information obtained by the acquisition protocol may not be the same 754 as the conveyance protocol uses (PIDF-LO [RFC4119]). Conversion by 755 the endpoint may be required. Calling networks which support devices 756 which do not support location may have to add location to emergency 757 calls. Some calling networks have relationships with the access 758 network that may allow it to accurately determine location of the 759 endpoint, although NATs and other middleboxes often make it 760 impossible to determine a reference identifier the access network 761 could use to determine the location. 763 For emergency call purposes, conversion of location information from 764 civic to geo or vice versa is not desirable. The location should be 765 sent in the form it was determined. The PSAP may convert, if it 766 needs to, and if conversion resulted from an earlier conversion, 767 unacceptable errors may be introduced. 769 5.7. Location Updates 771 Location information may not be available at call setup time for 772 mobile devices. For example, if a GPS-enabled cell phone is turned 773 on and then immediately places an emergency call, it can take 774 significant additional time before the cell phone acquires a GPS fix 775 and its location. Thus, while it is desirous to base emergency 776 routing on precise caller location information, it is not possible in 777 all circumstances to do so. In some cases, the initial call setup 778 will proceed based on, for example, cell and sector information and 779 then add location information during the call, rather than delaying 780 the initial call setup by an unacceptable amount of time. 782 In addition, the location of a mobile caller, e.g., in a vehicle or 783 aircraft, can change significantly during the emergency call. The 784 PSAP must be able to get updated location information while it is 785 processing the call. 787 Location updates where the location is conveyed by value may be 788 conveyed either in a re-INVITE or UPDATE [RFC3311] request message 789 (where UPDATE is preferred) or the PSAP may subscribe to the location 790 information of the caller, using SIP presence mechanisms (RFC 3265 791 [RFC3265] RFC 3856 [RFC3856]). Authorization for subscriptions is 792 for future study. When location is conveyed by reference, additional 793 dereference operations yield updated location. 795 5.8. Location Validation 797 Location must be validated prior to a device placing an actual 798 emergency call. Validation in this context means both that there is 799 a mapping from the address to a PSAP and that the PSAP understands 800 how to direct responders to the location. This is not as easy as it 801 sounds. There are, for example, many cases of two names for the same 802 street, or two streets with the same name in a city. In some 803 countries, the current system provides validation. For example, in 804 the United States, the Master Street Address Guide (MSAG) records all 805 valid street addresses and is used to ensure that phone billing 806 records correspond to valid emergency service street addresses. 807 Validation is normally a concern for civic addresses, although there 808 could be a concern that a given geo is within at least one PSAP 809 service boundary; that is, a "valid" geo is one for which there is a 810 mapping. 812 The LoST resolver[I-D.ietf-ecrit-lost] includes a validation 813 function. Validation should ideally be performed when a location is 814 entered into a Location Information Server (which is normally a 815 provisioning mechanism in the access carrier's operation and support 816 system). It should be confirmed periodically, because the mapping 817 database undergoes slow change; new streets are added or removed, 818 community names change, postal codes change, etc. Endpoints may wish 819 to validate locations they receive from the access network, and will 820 need to validate manually entered locations. Test functions 821 (Section 13) should also re-validate. 823 5.9. Default Location 825 Occasionally, a failure may occur where the access network cannot 826 determine the actual location of the caller. In these cases, it must 827 supply a default location. The default location should be as 828 accurate as the network can determine. For example, in a cable 829 network, a default location for each CMTS, with a representative 830 location for all cable modems served by that CMTS could be provided 831 if the network is unable to resolve the subscriber to any unit less 832 than the CMTS. Default locations must be marked as such (how?) so 833 that the PSAP knows that the location is not accurate. 835 6. Routing the Call to the PSAP 837 Emergency calls are routed based on one or more of the following 838 criteria expressed in the call setup request (INVITE): 840 Location: Since each PSAP serves a limited geographic region and 841 transferring existing calls delays the emergency response, calls 842 need to be routed to the most appropriate PSAP. In this 843 architecture, emergency call setup requests contain location 844 information, expressed in civic or geospatial coordinates, that 845 allows such routing. If there is no or imprecise (e.g., cell 846 tower and sector) information at call setup time, an on-going 847 emergency call may also be transferred to another PSAP based on 848 location information that becomes available in mid-call. 849 Type of emergency service: In some jurisdictions, emergency calls 850 for fire, police, ambulance or mountain rescue are directed to 851 just those emergency-specific PSAPs. We support this mechanism by 852 optionally labeling calls with a service identifier 853 [I-D.ietf-ecrit-service-urn]. 854 Media capabilities of caller: In some cases, emergency call centers 855 for specific caller media preferences, such as typed text or 856 video, are separate from voice systems. Also, even if media 857 capability does not affect the selection of the PSAP, there may be 858 call takers within the PSAP that are specifically trained, e.g., 859 in interactive text or sign language communications. Again, we 860 use the callee capabilities [RFC3840] mechanism to label and route 861 such calls. 863 Routing for calls by location and by service is the primary function 864 LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with 865 location (by-value) in either civic or geo form, plus a service 866 identifier, and returns an xml data structure containing a URI (or 867 set of URIs) to route the call to. Normal SIP [RFC3261] routing 868 functions are used to resolve the URI to a next hop destination. 870 The endpoint can complete the LoST mapping from its location at boot 871 time, and periodically thereafter. It should attempt to obtain a 872 "fresh" location, and from that a current mapping when it places an 873 emergency call, and if accessing either its location acquisition 874 function or mapping function fails, it should use this cached value. 875 The call would follow its normal outbound call processing. Networks 876 that support devices that do not implement LoST mapping would have 877 the outbound proxy do the mapping. The proxy must have the location 878 of the endpoint, which is often difficult for the calling network to 879 accurately determine. The endpoint may have its location, but would 880 not normally include it on the call signaling. There is no mechanism 881 provided in [I-D.ietf-sip-location-conveyance] to allow a proxy to 882 require the endpoint supply location, because that would open the 883 endpoint to an attack by any proxy on the path to get it to reveal 884 location. The Proxy CAN redirect a call to the service URN which, if 885 the device recognized the significance, would include location in the 886 redirected call. All networks should detect emergency calls and 887 supply default location and/or routing if it is not already 888 performed. 890 With the URI obtained from mapping, whether by the endpoint or the 891 proxy, the proxy routes the call. Normal SIP[RFC3261] mechanisms are 892 used to route calls to the URI obtained from the LoST dip. 894 7. Signaling of Emergency Calls 896 Since emergency calls carry privacy-sensitive information, they are 897 subject to the requirements for geospatial protocols [RFC3693]. In 898 particular, signaling information should be carried in TLS, i.e., in 899 'sips' mode. While requiring TLS is actually the way the standards 900 are written, it is unacceptable to have an emergency call fail to 901 complete because a TLS connection was not created, for any reason. 902 In many cases, persistent TLS connections can be maintained between 903 elements to minimize the time needed to establish them. 905 Details can be found in [I-D.ietf-sip-location-conveyance]. 907 8. Caller Preferences 909 SIP Caller Preferences [RFC3841] may be used to signal how the PSAP 910 should handle the call. For example, a language preference expressed 911 in an Accept-Language header may used as a hint to cause the PSAP to 912 route the call to a call taker who speaks the requested language. 914 9. Including a Valid Call-Back Identifier 916 The call-taker must be able to reach the emergency caller if the 917 original call is disconnected. In traditional emergency calls, 918 wireline and wireless emergency calls include a callback identifier 919 for this purpose. In SIP systems, the caller should include a 920 Contact header field indicating its device URI, if available, or 921 possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a 922 proxy. This identifier would be used to initiate call-backs 923 immediately by the call-taker if, for example, the call is 924 prematurely dropped. 926 In addition, a call-back identifier should be included either as the 927 URI in the From header field [RFC3261] preferably verified by SIP 928 Identity[RFC4474]. This identifier would be used to initiate a call- 929 back at a later time and may reach the caller, not necessarily on the 930 same device (and at the same location) as the original emergency 931 call. 933 Finally, there may be two other call identifiers included in an 934 emergency call. An identifier may be included which can be used to 935 identify the caller, as opposed to the device or the subscriber of a 936 specific calling service. This identifier may be used to retrieve 937 information about the caller that is independent of calling service. 938 For example, Alice may have home, office and mobile telephony 939 services, but she is the same Alice in all of them. Information 940 about Alice may be kept by an entity independent of any telephony 941 service provider. The caller identity is a URI and is placed in a 942 SIP Call-Info header [RFC3261] using the token "?" following the 943 recommendations in ???. 945 The communications service provider may also include an identifier 946 that may be used to retrieve information specific to the call held by 947 the service provider. This identifier, also a URI may be placed in 948 the Call-Info header using the token "?". 950 10. Mid-Call Services and Behavior 952 A PSAP may need to REFER[RFC3515] a call to a bridge for 953 conferencing. The caller should also be prepared to have the call 954 transferred (usually attended, but possibly blind) as 955 per[I-D.ietf-sipping-service-examples]. 957 11. Call Termination 959 It is undesirable for the caller to terminate an emergency call. 960 Strategies for devices to handle caller attempts to terminate may be 961 found in [phonebcp]. PSAP call termination is accomplished with 962 normal SIP call termination procedures. 964 12. Media 966 PSAPs should accept media streams on RTP [RFC3550]. Traditionally, 967 voice has been the only media stream accepted by PSAPs. In some 968 countries, text, in the form of BAUDOT codes or similar tone encoded 969 signaling within a voiceband is accepted ("TTY") for persons who have 970 hearing disabilities. With the Internet comes a wider array of 971 potential media which a PSAP should accept. Using SIP signaling 972 includes the capability to negotiate media. Normal SIP offer/answer 973 [RFC3264] negotiations should be used to agree on the media streams 974 to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs 975 should accept G.711 A law (and mu Law in North America) encoded voice 976 as described in [RFC3551]. Newer text forms are rapidly appearing, 977 with Instant Messaging now very common, PSAPs should accept IM with 978 at least [RFC3428] as well as [RFC3920]. 980 13. Testing 982 Since the emergency calling architecture consists of a number of 983 pieces operated by independent entities, it is important to be able 984 to test whether an emergency call is likely to succeed without 985 actually occupying the human resources at a PSAP. Both signaling and 986 media paths need to be tested since NATs and firewalls may allow the 987 session setup request to reach the PSAP, while preventing the 988 exchange of media. 990 [phonebcp] includes a description of an automated test procedure that 991 validates routing, signaling and media path continuity. This test 992 would be used at boot time, and whenever the device location changes 993 enough that a new PSAP mapping is returned from LoST. A manual 994 operation for the test should also be possible. 996 14. Example Call Flows 998 TBD 1000 15. Alternatives Considered 1002 This is a non-normative appendix. During discussions of emergency 1003 calling, a number of suggestions are commonly made. Below, we 1004 discuss some of the reasons why these alternatives do not satisfy the 1005 requirements of emergency calling. 1007 15.1. tel URIs 1009 Instead of providing URIs to call routing proxies or end systems, it 1010 has been suggested that end systems be configured with a "tel" URI 1011 [RFC3966]. Such a "tel" URI would have to be routed to a 1012 geographically appropriate telephony gateway, as it is unlikely that 1013 every building, enterprise or residence will have its own gateway. 1014 VoIP devices can be used in networks that are completely unaware of 1015 VoIP services, with VoIP service providers that are physically far 1016 removed from the caller's network location. Thus, the use of a tel 1017 URI simply moves the problem to the outbound proxy, which has to use 1018 the caller's location to determine the appropriate telephony gateway. 1020 In addition, emergency telephone numbers are far from universal, with 1021 some such numbers used for non-emergency purposes elsewhere. Thus, 1022 an outbound proxy would have to ascertain the location of the caller 1023 to guess whether the "tel" URI identifies an emergency call or some 1024 other number. 1026 Thus, "tel" URIs are not likely to be appropriate or sufficient for 1027 identifying emergency calls and do not, by themselves, solve the call 1028 routing problem. 1030 16. Security Considerations 1032 16.1. Caller Authentication 1034 Fraudulent calls to PSAPs is a significant concern. Current systems 1035 rely on inherent security mechanisms in the PSTN to make sure the 1036 identity of the caller is known. As Internet technologies are 1037 increasingly used to place calls, it is becoming easier to hide the 1038 indentity of a caller. Use of the SIP Identity mechanism [RFC4474] i 1039 is recommended. If SIP Identity cannot be provided, carriers should 1040 make use of P-Asserted-Identity, [RFC3325] 1042 In keeping with established customs in circuit-switched emergency 1043 calling, authentication cannot be made a prerequisite for routing or 1044 accepting an emergency call. However, a call taker may be more 1045 suspicious of a caller and request additional information if the call 1046 authenticity cannot be verified. 1048 16.2. Location Privacy 1050 Location is sensitive information, it must be protected against 1051 disclosure to unauthorized persons. In most jurisdictions placing an 1052 emergency call implies disclosure of location to all the entities 1053 needing location to properly route and respond to the call. 1054 Nevertheless, even in an emergency, callers have an expectation that 1055 their location will not be divulged outside of that implied release. 1057 During acquisition of the location information, an eavesdropper or 1058 impersonator may obtain location. When DHCP is used, authentication 1059 [RFC3118] should be used to protect the location option. Use of TLS 1060 in other LCPs should be used. Similarly, TLS should be used with SIP 1061 signaling when location is conveyed. However, failure to establish a 1062 security association should never be used to drop an emergency call. 1063 Rather, the operation should be attempted without the security 1064 mechanism. 1066 16.3. PSAP Impersonation 1068 See Section 16.4. 1070 With LoST-based call routing (Section 6), an attacker could modify 1071 the mapping entries for one or more locations, re-routing calls 1072 destined for them. The security mechanisms for provisioning the data 1073 in the LoST database must be robust. 1075 LoST is a distributed database, with many replicas of authoritative 1076 data. An attacker may impersonate a valid LoST server and supply 1077 fraudulent data. An attacker may also perpetrate a denial of service 1078 attack on LoST servers. These issues are addressed in 1079 [I-D.ietf-ecrit-lost]. 1081 Finally, the URI LoST returns would normally contain a domain name. 1082 The domain can be hijacked by several known attacks. TLS should be 1083 used to place calls, with the domain name verified. Using DNSSEC 1084 [RFC4033] on the DNS entries is recommended. As above, failure of 1085 the security mechanism must not impede the processing of an emergency 1086 call; the operation should proceed without security rather than 1087 abandoning the call. 1089 16.4. Preventing Call Misdirection 1091 We need to prevent an emergency call reaching a destination other 1092 than a PSAP. For example, a rogue UA able to intercept SIP requests 1093 might be able to impersonate a PSAP. 1095 In the absence of a globally recognized certificate that ensures that 1096 the owner is a legitimate PSAP, we rely on a chain of trust enforced 1097 by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop 1098 to route the call only to destinations supporting TLS transport. 1099 Each ESRP verifies that the next-hop destination chosen as described 1100 in Section 6 corresponds to the server certificate offered by that 1101 destination. 1103 16.5. Call Signaling Integrity 1105 Preventing a malicious outsider from manipulating call information in 1106 SIP requests can be assured by using "sips" (that is, TLS, hop-by-hop 1107 from caller to emergency call taker. 1109 16.6. Media Integrity and Confidentiality 1111 Media integrity and confidentiality can be assured by the use of 1112 SRTP[RFC3711]. 1114 17. Acknowledgements 1116 This draft was created from a 1117 draft-schulzrinne-sipping-emergency-arch-02 together with sections 1118 from draft-polk-newton-ecrit-arch-considerations-02. 1120 Design Team members participating in this draft creation include 1121 Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger 1122 Marshall, Stu Goldman, Shida Schubert and Tom Taylor. 1124 18. References 1126 18.1. Normative References 1128 [I-D.ietf-ecrit-lost] 1129 Hardie, T., "LoST: A Location-to-Service Translation 1130 Protocol", draft-ietf-ecrit-lost-02 (work in progress), 1131 October 2006. 1133 [I-D.ietf-ecrit-requirements] 1134 Schulzrinne, H. and R. Marshall, "Requirements for 1135 Emergency Context Resolution with Internet Technologies", 1136 draft-ietf-ecrit-requirements-12 (work in progress), 1137 August 2006. 1139 [I-D.ietf-ecrit-service-urn] 1140 Schulzrinne, H., "A Uniform Resource Name (URN) for 1141 Services", draft-ietf-ecrit-service-urn-05 (work in 1142 progress), August 2006. 1144 [I-D.ietf-geopriv-dhcp-civil] 1145 Schulzrinne, H., "Dynamic Host Configuration Protocol 1146 (DHCPv4 and DHCPv6) Option for Civic Addresses 1147 Configuration Information", 1148 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 1149 January 2006. 1151 [I-D.ietf-sip-gruu] 1152 Rosenberg, J., "Obtaining and Using Globally Routable User 1153 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1154 (SIP)", draft-ietf-sip-gruu-10 (work in progress), 1155 August 2006. 1157 [I-D.ietf-sip-location-conveyance] 1158 Polk, J. and B. Rosen, "Session Initiation Protocol 1159 Location Conveyance", 1160 draft-ietf-sip-location-conveyance-04 (work in progress), 1161 August 2006. 1163 [I-D.ietf-sipping-config-framework] 1164 Petrie, D., "A Framework for Session Initiation Protocol 1165 User Agent Profile Delivery", 1166 draft-ietf-sipping-config-framework-09 (work in progress), 1167 October 2006. 1169 [I-D.rosen-iptel-dialstring] 1170 Rosen, B., "Dialstring parameter for the Session 1171 Initiation Protocol Uniform Resource Identifier", 1172 draft-rosen-iptel-dialstring-04 (work in progress), 1173 June 2006. 1175 [LLDP] "IEEE802.1ab Station and Media Access Control", Dec 2004. 1177 [LLDP-MED] 1178 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1179 Endpoint Discovery". 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, March 1997. 1184 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1185 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1186 August 1998. 1188 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1189 Messages", RFC 3118, June 2001. 1191 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1192 A., Peterson, J., Sparks, R., Handley, M., and E. 1193 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1194 June 2002. 1196 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1197 with Session Description Protocol (SDP)", RFC 3264, 1198 June 2002. 1200 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1201 Event Notification", RFC 3265, June 2002. 1203 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1204 UPDATE Method", RFC 3311, October 2002. 1206 [RFC3325] "", 2005. 1208 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1209 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1210 for Instant Messaging", RFC 3428, December 2002. 1212 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1213 Method", RFC 3515, April 2003. 1215 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1216 Jacobson, "RTP: A Transport Protocol for Real-Time 1217 Applications", STD 64, RFC 3550, July 2003. 1219 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1220 Video Conferences with Minimal Control", STD 65, RFC 3551, 1221 July 2003. 1223 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1224 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1226 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1227 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1228 RFC 3711, March 2004. 1230 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1231 Configuration Protocol Option for Coordinate-based 1232 Location Configuration Information", RFC 3825, July 2004. 1234 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1235 "Indicating User Agent Capabilities in the Session 1236 Initiation Protocol (SIP)", RFC 3840, August 2004. 1238 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1239 Preferences for the Session Initiation Protocol (SIP)", 1240 RFC 3841, August 2004. 1242 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1243 Initiation Protocol (SIP)", RFC 3856, August 2004. 1245 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1246 Protocol (XMPP): Core", RFC 3920, October 2004. 1248 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1249 Rose, "DNS Security Introduction and Requirements", 1250 RFC 4033, March 2005. 1252 [RFC4103] "", 2005. 1254 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1255 Format", RFC 4119, December 2005. 1257 [RFC4474] "", 2005. 1259 [phonebcp] 1260 Rosen, B. and J. Polk, "Best Current Practice for 1261 Communications Services in support of Emergency 1262 CallingOcti", October 2006. 1264 18.2. Informative References 1266 [I-D.ietf-sipping-service-examples] 1267 Johnston, A., "Session Initiation Protocol Service 1268 Examples", draft-ietf-sipping-service-examples-11 (work in 1269 progress), October 2006. 1271 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1272 RFC 3966, December 2004. 1274 Authors' Addresses 1276 Brian Rosen 1277 NeuStar, Inc. 1278 470 Conrad Dr 1279 Mars, PA 16046 1280 US 1282 Email: br@brianrosen.net 1284 Henning Schulzrinne 1285 Columbia University 1286 Department of Computer Science 1287 450 Computer Science Building 1288 New York, NY 10027 1289 US 1291 Phone: +1 212 939 7042 1292 Email: hgs@cs.columbia.edu 1293 URI: http://www.cs.columbia.edu 1295 James Polk 1296 Cisco Systems 1297 3913 Treemont Circle 1298 Colleyville, Texas 76034 1299 US 1301 Phone: +1-817-271-3552 1302 Email: jmpolk@cisco.com 1303 Andrew Newton 1304 SunRocket 1305 8045 Leesburg Pike, Suite 300 1306 Vienna, VA 22182 1307 US 1309 Phone: +1 703 636 8052 1310 Email: andy@hxr.us 1312 Full Copyright Statement 1314 Copyright (C) The Internet Society (2006). 1316 This document is subject to the rights, licenses and restrictions 1317 contained in BCP 78, and except as set forth therein, the authors 1318 retain all their rights. 1320 This document and the information contained herein are provided on an 1321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1328 Intellectual Property 1330 The IETF takes no position regarding the validity or scope of any 1331 Intellectual Property Rights or other rights that might be claimed to 1332 pertain to the implementation or use of the technology described in 1333 this document or the extent to which any license under such rights 1334 might or might not be available; nor does it represent that it has 1335 made any independent effort to identify any such rights. Information 1336 on the procedures with respect to rights in RFC documents can be 1337 found in BCP 78 and BCP 79. 1339 Copies of IPR disclosures made to the IETF Secretariat and any 1340 assurances of licenses to be made available, or the result of an 1341 attempt made to obtain a general license or permission for the use of 1342 such proprietary rights by implementers or users of this 1343 specification can be obtained from the IETF on-line IPR repository at 1344 http://www.ietf.org/ipr. 1346 The IETF invites any interested party to bring to its attention any 1347 copyrights, patents or patent applications, or other proprietary 1348 rights that may cover technology that may be required to implement 1349 this standard. Please address the information to the IETF at 1350 ietf-ipr@ietf.org. 1352 Acknowledgment 1354 Funding for the RFC Editor function is provided by the IETF 1355 Administrative Support Activity (IASA).