idnits 2.17.1 draft-ietf-ecrit-framework-01.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, updated by RFC 4748 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1432. 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 IETF Trust 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 (March 01, 2007) is 6266 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: '1' on line 290 -- Looks like a reference, but probably isn't: '4' on line 290 -- Looks like a reference, but probably isn't: '2' on line 290 -- Looks like a reference, but probably isn't: '3' on line 295 -- Looks like a reference, but probably isn't: '5' on line 295 -- Looks like a reference, but probably isn't: '6' on line 299 -- Looks like a reference, but probably isn't: '7' on line 299 -- Looks like a reference, but probably isn't: '8' on line 299 -- Looks like a reference, but probably isn't: '9' on line 299 == Missing Reference: 'M1' is mentioned on line 384, but not defined == Missing Reference: 'M2' is mentioned on line 388, but not defined == Missing Reference: 'M3' is mentioned on line 392, but not defined == Missing Reference: 'M4' is mentioned on line 399, but not defined == Missing Reference: 'M5' is mentioned on line 403, but not defined == Missing Reference: 'M8' is mentioned on line 410, but not defined == Unused Reference: 'I-D.ietf-sipping-config-framework' is defined on line 1245, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-04 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-00 == 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 (-14) exists of draft-ietf-geopriv-pdif-lo-profile-05 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-11 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-07 -- 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-10 -- 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) ** Obsolete normative reference: RFC 4676 (Obsoleted by RFC 4776) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-12 Summary: 11 errors (**), 0 flaws (~~), 19 warnings (==), 19 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: September 2, 2007 Columbia U. 6 J. Polk 7 Cisco Systems 8 A. Newton 9 SunRocket 10 March 01, 2007 12 Framework for Emergency Calling in Internet Multimedia 13 draft-ietf-ecrit-framework-01 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 September 2, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . 20 81 7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 21 82 8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 22 83 9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 22 84 10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 23 85 11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 23 86 12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 24 89 15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 24 90 15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 16. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 25 93 16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 26 94 16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 26 95 16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 26 96 16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 27 97 16.6. Media Integrity and Confidentiality . . . . . . . . . . . 27 98 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 99 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 18.1. Normative References . . . . . . . . . . . . . . . . . . . 27 101 18.2. Informative References . . . . . . . . . . . . . . . . . . 30 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 103 Intellectual Property and Copyright Statements . . . . . . . . . . 32 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 are required. To further 207 complicate matters, VoIP endpoints can be connected through tunneling 208 mechanisms such as virtual private networks (VPNs). This 209 significantly complicates emergency calling, because the location of 210 the caller and the first element that routes emergency calls can be 211 on different continents, with different conventions and processes for 212 handling of 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) [RFC3261] by PSAPs and calling parties. While other inter- 222 domain call signaling protocols may be used for emergency calling, 223 SIP is ubiquitous and possesses, through its related specifications, 224 more of the needed features for the proper support of this use case. 225 Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable 226 for inter-domain communications, ruling out MG/MGC protocols such as 227 MGCP or H.248/Megaco. The latter protocols can naturally be used by 228 the enterprise or carrier placing the call, but any such call would 229 reach the PSAP through a media gateway controller, similar to how 230 interdomain VoIP calls would be placed. Other signaling protocols 231 may also use protocol translation to communicate with a SIP-enabled 232 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 [I-D.ietf-ecrit-phonebcp] that call taker user agents and PSAP- 247 operated proxies 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 emergancy 266 dialstring is detected. We route emergency calls based on the 267 location ( (Section 5)) of the caller. To get this location we 268 either include a form of measuring (e.g. GPS) ( (Section 5.3.3)) 269 device location in the endpoint, or the endpoint is configured ( 270 (Section 5.5)) with its location from the access network's Location 271 Information Server (LIS) The location is conveyed ( (Section 5.6)) in 272 the SIP signaling with the call. We route( (Section 6)) the call 273 based on location using the LoST protocol ( [I-D.ietf-ecrit-lost]) 274 which maps a location to a set of PSAP URIs. Each URI resolves to a 275 PSAP or an Emergency Services Routing Proxy which serves a group of 276 PSAPs. The call arrives at the PSAP with the location included in 277 the INVITE request. 279 Configuration Servers 280 . . . . . . . . . . . . . . . . . 281 . . 282 . +--------+ +----------+ . 283 . +--------+ | +----------+ | . 284 . | LIS | | | SIP | | . 285 . | |-+ | Registrar|-+ . 286 . +--------+ +----------+ . 287 . ^ ^ . 288 . . | . . . . . . . | . . . . . . 289 | | 290 |[1][4] |[2] 291 | | +--------+ 292 |+--------------+ +--------+ | 293 || | LoST | | 294 ||+-------------------->| Servers|-+ 295 ||| [3][5] +--------+ +-------+ 296 ||| | PSAP2 | 297 ||| +-------+ 298 ||| 299 ||| [6] +-------+ [7] +------+ [8] +-------+ [9] 300 Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 301 +-------+ +------+ +-------+ 303 +-------+ 304 | PSAP3 | 305 +-------+ 307 Figure 1: Generic ECRIT Component Topology 309 Figure 2 shows a generic emergency call establishment. This includes 310 the following: 311 o Alice - who will make the emergency call. 312 o Configuration Servers - Servers providing Alice's UA its IP 313 address and other configuration information, perhaps including 314 Location by-value or by-reference. In this flow, we use DHCP as 315 an example location acquisition protocol. Configuration servers 316 also may include a SIP Registrar server, for Alice's UA to 317 register Alice's UA to register with. Most SIP UAs will register 318 with a call server, so it will be a common scenario for UAs that 319 make emergency calls to be registered with such a server in the 320 originating calling network. All these configuration messages are 321 labeled M1 through M3, but could easily require more messages than 322 4 to complete. 323 o ESRP - The Emergency Services Routing Proxy Server that is the 324 incoming call proxy in the emergency services domain. The ESRP 325 makes further routing decisions based on PSAP state and location 326 of the caller to choose the actual PSAP which handles the call. 327 In some jurisdictions, that may involve another LoST dip 328 o LoST Server - Processes the LoST request for Location to PSAP-URI 329 Mapping function, either for an initial request from a UA, or an 330 in-call routing by the Proxy server in the originating network, or 331 possibly by an ESRP. 332 o PSAP - Call center where emergency calls are destined for in times 333 of emergencies. 335 Generally, Alice's UA either has location configured manually, has an 336 integral location measurement mechanism, or it runs a location 337 configuration protocol to obtain location from the access (broadband) 338 network. For most devices, an LCP will be used, for example a 339 DHCPREQUEST message or another location acquisition mechanism. 340 Alice's UA then will most likely register with a SIP domain. This 341 allows her to be contacted by other SIP entities. Next, her UA will 342 perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn a 343 URI, for use if the Lost Query fails during an emergency call. The 344 LoST query may contain the dialstring for emergency calls appropriate 345 for the location provided. 347 Some time has hopefully passed since Alice's UA booted. In this 348 example, she dials or initiates an emergency call. This may have 349 been through her keypad with her locally known emergency dialstring. 350 It is important that this dialstring be recognized by her UA wherever 351 Alice is because she may be in enough distress she forgets what the 352 traveled-to emergency dialstring is; as there are more than 60 around 353 the world. 355 The UA recognizes the dialstring, which means this is an emergency 356 call. The UA attempts to refresh its location, and with that 357 location, the LoST mapping, to get the most accurate information to 358 use for routing the call. If the location request or the LoST 359 request fails (or takes too long) the UA uses it's cached values. 361 The UA creates an INVITE which includes the location. 362 [I-D.ietf-sip-location-conveyance] defines a SIP Location header that 363 either contain the location-by-reference URI, or a [RFC2396] "cid:" 364 indicating where in the message body the location-by-value is. 366 The INVITE message routes to the ESRP, which is the first inbound 367 proxy for the emergency services domain. This message, is then 368 routed by the ESRP towards the most current PSAP for Alice's 369 location, which uses PSAP state, location and other state information 370 to choose this PSAP. 372 A proxy in the PSAP choses an available call taker and extends the 373 call to its UA. 375 The 200 OK to the INVITE traverses the path in reverse, from call 376 taker UA to PSAP proxy to ESRP to originating network proxy to 377 Alice's UA. The ACK completes the call set-up and the emergency call 378 is established, allowing the PSAP call-taker to talk to Alice about 379 her emergency. 381 Configuration LoST 382 Alice Servers ESRP Server PSAP 384 [M1] DHCP Request(s) (may ask for Location) 385 ----------> 386 DHCP Reply(s) (replies with location if asked) 387 <--------- 388 [M2] SIP REGISTER 389 ----------> 390 SIP 200 OK (REGISTER) 391 <--------- 392 [M3] Initial LoST Protocol Query (contains Location) 393 ----------------------------------------> 394 Initial LoST Protocol Response (contains PSAP-URI) 395 <---------------------------------------- 397 ***Some time later, Alice dials/initiates emergency call*** 399 [M4] DHCP Request(s) (update Location) 400 ----------> 401 DHCP Reply(s) (replies with location) 402 <--------- 403 [M5] Update LoST Protocol Query (contains Location) 404 ----------------------------------------> 405 LoST Protocol Response (contains PSAP-URI) 406 <---------------------------------------- 407 [M6/7] INVITE (sos URN, Location & early PSAP URI) 408 ---------------------> 410 [M8] INVITE (sos, Location & PSAP-URI) 411 --------------------------------------> 412 200 OK 413 <-------------------------------------------------------------- 414 ACK 415 --------------------------------------------------------------> 416 Emergency Session Established 417 <=============================================================> 419 Figure 2: General Flow of an Emergency Call Establishment 421 This is a very rough example of the operation of an emergency call 422 establishment. There are no layer 3 routers in the message flow, and 423 whatever security messages exist in the call are not shown either. 424 Each of those aspects will be addressed individually, to keep each 425 discussion in context of that subject, for clarity. 427 4. Identifying an Emergency Call 429 Using the PSTN, emergency help can often be summoned by dialing a 430 nationally designated, widely known number, regardless of where the 431 telephone was purchased. The appropriate number is determined by 432 which infrastructure the telephone is connected to. However, this 433 number differs between localities, even though it is often the same 434 for a country or region, such as many countries in the European 435 Union. In some countries, there is a single digit sequence that is 436 used for all types of emergencies. In others, there are several 437 sequences that are specific to the responder, e.g., one for police, 438 another for fire. It is deemed impractical to change the dialed 439 digits to summon help. For end systems, it is desirable to have a 440 universal identifier, independent of location, to allow the automated 441 inclusion of location information and to allow the device and other 442 entities in the call path to perform appropriate processing within 443 the signaling protocol in an emergency call set-up. 445 As part of the overall emergency calling architecture, we define 446 common emergency call URIs which are defined in 447 [I-D.ietf-ecrit-service-urn]. Users are not expected to "dial" an 448 emergency URN. Rather, the current dialstring should be translated 449 to the appropriate service URN. Such translation could ideally be 450 performed in the endpoint, but could be performed in a signaling 451 intermediary (proxy server). For devices that are mobile or nomadic, 452 an issue arises of whether the home or visited dialing strings should 453 be used. Many users would prefer that their home dialing sequences 454 work no matter where they are. Local laws and preferences of the 455 emergency response professionals are such that the visited dialing 456 sequences must always work. Having the home dialstring work is 457 optional. The best answer seems to be for both to work. 459 The mechanism for obtaining the dialing sequences for a given 460 location is provided by LoST [I-D.ietf-ecrit-lost]. Where the 461 endpoint does not support the translation of dialstrings to telephone 462 numbers, the dialing sequence would be represented as a dialstring 463 [I-D.rosen-iptel-dialstring] and the outgoing proxy would recognize 464 the dialstring and translate to the service URN. It should be noted 465 that the endpoint would not normally supply location unless it 466 understood the call to be an emergency call. To determine the local 467 dialstring, the proxy needs the location of the endpoint. This may 468 be difficult in situations where the user can roam or be nomadic. 470 Endpoint recognition of emergency dialstrings is therefore preferred. 472 5. Location and Its Role in an Emergency Call 474 5.1. Introduction 476 Caller location plays a central role in routing emergency calls. For 477 practical reasons, each PSAP generally handles only calls for a 478 certain geographic area (overload arrangements between PSAPs to 479 handle each others calls notwithstanding). Other calls that reach it 480 by accident must be manually re-routed (transferred) to the 481 appropriate PSAP, increasing call handling delay and the chance for 482 errors. The area covered by each PSAP differs by jurisdiction, where 483 some countries have only a small number of PSAPs, while others 484 decentralize PSAP responsibilities to the level of counties or 485 municipalities. 487 In most cases, PSAPs cover at least a city or town, but there are 488 some areas where PSAP coverage areas follow old telephone rate center 489 boundaries and may straddle more than one city. Irregular boundaries 490 are common, often for historical reasons. Routing must be done on 491 PSAP service boundaries, not "closest" or "best fit" algorithms. 493 5.2. Types of Location Information 495 There are four primary types of location information: civic, postal, 496 geospatial, and cellular cell tower and sector. 498 Civic: Civic location information describes the location of a person 499 or object by a street address that corresponds to a building or 500 other structure. (This is sometimes also called "civil" location 501 information.) Civic location may include more finer grained 502 location information such as floor, room, cubicle. Civic 503 information comes in two forms: 504 Jurisdictional - This refers to a civic location using actual 505 political subdivisions, especially for the community name. 506 Postal - This refers to a civic location used to mail a letter 507 to. The name of the post office sometimes does not correspond 508 to the actual community name and a postal addrress may contain 509 post office boxes or street addresses that do not correspond to 510 an actual building. Postal addresses are generally unsuitable 511 for emergency call routing, but may be the only address 512 available. 514 Geospatial: Geospatial addresses contain longitude, latitude and 515 altitude information based on an understood datum (starting point) 516 and earth shape model. While there have been many datums 517 developed over time, most modern systems are using or moving 518 towards WGS84. 519 Cell tower/sector: Cell tower and sectors identify the cell tower 520 and the antenna sector that the mobile device is currently using. 521 Traditionally, the tower location is expressed as a point, and 522 routing decisions are made on that point. Cell/sector information 523 could also be transmitted as an irregularly shaped polygon of 524 geospatial coordinates reflecting the likely geospatial location 525 of the mobile device. 527 In IETF protocols, civic and geo forms are both supported. The civic 528 forms include both the postal and jurisdictional fields. The cell 529 tower/sector can be represented as a point. 531 5.3. Location Determination 533 Location information can be entered by the user or installer of a 534 device ("manual configuration"), can be measured by the end system, 535 can be delivered to the end system by some protocol or can be 536 measured by a third party and inserted into the call signaling. We 537 discuss these in detail below. 539 In some cases, an entity may have multiple sources of location 540 information, possibly partially contradictory. This is particularly 541 likely if the location information is determined both by the end 542 system and a third party. Handling multiple locations is discussed 543 in [I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location 544 information is particularly harmful if it points to multiple distinct 545 PSAPs. Guidelines for dealing with multiple locations is also given 546 in [I-D.ietf-ecrit-lost]. 548 All location objects MUST be delivered to the PSAP. To facilitate 549 such policy decisions, location information should contain 550 information about the source of data, such as GPS, manually entered 551 or based on access network topology. In addition, the generator of 552 the location information should be included. The ability of the UA 553 to understand how it learned its location, and include this 554 information element in the location object that is sent to the PSAP, 555 provides the call-taker with many pieces of information to make 556 decisions upon, and guidance for what to ask the caller and what to 557 tell the responders. 559 The call should indicate which location information has been used for 560 routing, so that the same location information is used for all call 561 routing decisions. Otherwise, two proxies might pick different 562 location information from the call request, resulting in different 563 routing decisions for different transactions. The location 564 conveyance mechanism [I-D.ietf-ecrit-lost] contains a parameter which 565 can be used for this purpose 567 End systems and network elements can derive location information from 568 a variety of sources. It is not the goal of this document to 569 exhaustively enumerate them, but we provide a few common examples in 570 the sections below. 572 5.3.1. User-Entered Location Information 574 Location information can be maintained by the end user or the 575 installer of an endpoint in the endpoint itself, or in a database. 577 Location information added by end users is almost always inferior to 578 measured or wire database information, as users may mistype civic 579 location information, may not know the meaning of geospatial 580 coordinates or may use address information that does not correspond 581 to a recognized civic address. A user-entered location can fail to 582 be changed when the location of a device changes during or after 583 movement. For example, a user could move their residence to another 584 dwelling, not update their device/equipment with this new location, 585 and place an emergency call with old location information. 587 All that said, there are always a small number of cases where the 588 mechanisms used by the access network to determine location fail to 589 accurately reflect the actual location of the endpoint. For example, 590 the user may deploy his own WAN behind an access network, effectively 591 remoting an endpoint some distance from the access network's notion 592 of its location. There must be some mechanism provided to provision 593 a location for an endpoint by the user or by the access network on 594 behalf of a user. The use of the mechanism introduces the 595 possibility of users falsely declaring themselves to be somewhere 596 they are not. As an aside, normally, if an emergency caller insists 597 he is at a location different from what any automatic location 598 determination system reports he is, responders will always be sent to 599 the user's self-declared location. However this is a matter of local 600 policy and is outside the scope of this document. 602 5.3.2. Access Network "Wire Database" Location Information 604 Location information can be maintained by the access network, 605 relating some form of identifier for the end subscriber or device to 606 a location database ("wire database"). In enterprise LANs, wiremap 607 databases map Ethernet switch ports to building layouts at known 608 locations. In DSL installations, the local telephone carrier 609 maintains a mapping of wire-pairs to subscriber addresses. 611 Even for IEEE 802.11 wireless access points, wire databases may 612 provide sufficient location resolution; the location of the access 613 point may be sufficient location information for each of the clients 614 served by that access point. This may be the connectivity type for 615 both residential users of DSL and Cable Modem installations, as well 616 as the only infrastructure at a WiFi hotspot, such as a coffee shop. 617 Each of these cases will have a known civic address of the dwelling/ 618 business, likely providing sufficient location resolution. 620 Wire databases to the home are likely to be the most promising 621 solution for residential users where a service provider knows the 622 customer's service address. The service provider can then perform 623 address verification, similar to the current system in some 624 jurisdictions. 626 5.3.3. End-System Measured Location Information 628 Global Positioning System (GPS) sensors may be embedded directly in 629 the end device. GPS produces relatively high precision location 630 fixes in open-sky conditions, but the technology still faces several 631 challenges in terms of performance (time-to-fix and time-to-first- 632 fix), as well as obtaining successful location fixes within shielded 633 structures, or underneath the ground (tunnels, basements, etc.). It 634 also requires all devices to be equipped with the appropriate GPS 635 capability. GPS technology is improving, and is increasingly 636 successful in more difficult conditions such as dense urban canyons 637 and inside commercial structures. It is currently accurate to tens 638 of meters using some kind of "assist", which may be operated by the 639 access network (A-GPS) or by a government (WAAS). Newer multi- 640 frequency systems will improve accuracy without assist. 642 GPS equipped devices vary depending on which element initiates 643 requests, which element actually determines final location, assist 644 mechanisms, etc. Some common implementations include: 645 1. GPS S/A (standalone), device initiated 646 2. GPS S/A, network initiated 647 3. AGPS-device initiated, network determined 648 4. AGPS-device initiated, network augmented 649 5. AGPS-network initiated, network determined 650 6. AGPS-network initiated, network augmented 652 5.3.4. Third-party Measured Location Information 654 Wireless triangulation: Elements in the network infrastructure 655 triangulate end systems based on signal strength, angle of arrival 656 or time of arrival. Common mechanisms deployed include. 658 1. Time Difference Of Arrival - TDOA 659 2. Uplink Time Difference Of Arrival - U-TDOA 660 3. Angle of Arrival - AOA 661 4. RF-Fingerprinting 662 5. Advanced Forward Link Trilateration - AFLT 663 6. Enhanced Forward Link Trilateration - EFLT 664 Sometimes triangulation and measured mechanisms are combined, for 665 example A-GPS with AFLT 666 Location beacons: A short range wireless beacon, e.g., using 667 Bluetooth or infrared, announces its location to mobile devices in 668 the vicinity. 670 5.4. Location and References to Location 672 Location information may be expressed as the actual civic or geo 673 value but can be transmitted as by-value (wholly contained within the 674 signaling message) or by-reference (a URI pointing to the value 675 residing on a remote node waiting to be dereferenced). There are 676 pros and cons to each form: 677 location-by-value: 678 pro- Value available to each device along the path immediately 679 for further processing. 680 con- Size, especially if constrained to a UDP transport. Value 681 fixed at the time the value is acquired from the access 682 network. Value can be changed by endpoint, which may be 683 considered untrustworthy for this critical usage. 684 location-by-reference 685 pro- Small size. Value can be fixed at time of dereference. 686 Value cannot be changed by endpoint 687 con- URI resolution requires location source be available and 688 accessible by dereferencer. Dereferencing takes time. 689 Dereferencing may fail. 691 5.5. End System Location Configuration 693 Unless a user agent has access to provisioned or locally measured 694 location information, it must obtain it from the access network. 695 There are several Location Configuration Protocols that can be used 696 for this purpose. 698 DHCP can deliver civic [RFC4676] or geospatial [RFC3825] 699 information. User agents would need to support both formats. 700 Note that a user agent can use DHCP, via the DHCP REQUEST or 701 INFORM messages, even if it uses other means to acquire its IP 702 address. 704 Insert reference to L7 acquisition protocol document> is another 705 choice. 706 Link-Layer Discovery Protocol [LLDP]), with proposed extensions 707 [LLDP-MED], may also be used to deliver location information. 708 SUPL OASIS is yet another choice. 710 Other LCPs may be devised by other standards bodies. Each LCP has 711 limitations in the kinds of networks that can reasonably support it. 712 For this reason, it is not possible to choose a single mandatory to 713 deploy LCP. For endpoints with common network connections (such as 714 an Ethernet jack or a WiFi connection), unless every network 715 supported every protocol, or alternatively, every device supported 716 every protocol, serious incompatibilities would ensue. 717 [I-D.ietf-ecrit-lost] contains a (short) list of protocols such 718 devices must support. 720 Where an access network can control the specification of EVERY 721 endpoint that could make an emergency call that is directly connected 722 to the network, or indirectly connected (for example, a device on a 723 LAN behind a network attachment unit), it may specify any protocol it 724 wishes for each endpoint. This is a very unusual case; nearly every 725 access network can be used to support an Ethernet based LAN behind it 727 For example, existing mobile networks are being used to support 728 routers and LANs behind a wireless data network WAN connection, with 729 Ethernet connected phones connected to that. It is possible that the 730 access network supports a protocol not on the phonebcp list, and 731 every handset supported in that network could use that protocol for 732 emergency calls. However, unless another element which the access 733 network provider controls the specification of can acquire location 734 using that protocol and then that element can support one of the 735 phonebcp's list of protocols, the Ethernt connected phone won't be 736 able to acquire location. In this case, if the access network 737 provider supplies a router which includes a DHCP server, it can 738 acquire location using the access network specific protocol, and then 739 use the location information to supply it to its clients (e.g. the 740 Ethernet connected phone) via DHCP. 742 For most networks, it will not be practical to control the 743 specification of every device, or arrange interworking with network 744 specific LCPs. For this reason, most devices will need to support 745 ALL of the LCPs in [I-D.ietf-ecrit-lost], and access networks will 746 have to support at least one of these LCPs. 748 Location for non-mobile devices is normally expected to be acquired 749 at network attachment time and retained by the device. It should be 750 refreshed when the cached value becomes invalid (for example, if DHCP 751 is the acquisition protocol, refresh of location may occur when the 752 IP address lease is renewed). At the time of an emergency call, the 753 location should be refreshed, with the retained location used if the 754 location acquisition does not immediately return a value. Mobile 755 devices may determine location at network attachment time and 756 periodically thereafter as a backup in case location determination at 757 the time of call does not work. Mobile device location may be 758 refreshed when a TTL expires, the device moves beyond some boundaries 759 (as provided by [I-D.ietf-ecrit-lost]), etc. Normally, mobile 760 devices will acquire its location at call time for use in an 761 emergency call routing, but see Section 5.7 763 5.6. Conveyance of Location 765 When an emergency call is placed, the endpoint (normally) puts 766 location information in the signaling with the call. We refer to 767 that as "conveyance" to distinguish it from "configuration". 768 Configuration gets location from access network to endpoint, 769 conveyance sends location from endpoint to elements that route the 770 call based on that location object and the PSAP. Using SIP, the 771 location information is conveyed following the procedures in 772 [I-D.ietf-sip-location-conveyance]. The form of the location 773 information obtained by the acquisition protocol may not be the same 774 as the conveyance protocol uses (PIDF-LO [RFC4119]). Mapping by the 775 endpoint may be required. Calling networks which support devices 776 which do not support location may have to add location to emergency 777 calls. Some calling networks have relationships with the access 778 network that may allow it to accurately determine location of the 779 endpoint, although NATs and other middleboxes usually make it 780 impossible to determine a reference identifier the access network 781 could use to determine the location. 783 For emergency call purposes, conversion of location information from 784 civic to geo or vice versa prior to conveyance is not desirable. The 785 location should be sent in the form it was determined. The PSAP may 786 convert, if it needs to, and if conversion resulted from an earlier 787 conversion, unacceptable errors may be introduced. 789 5.7. Location Updates 791 Location information may not be available at call setup time for 792 mobile devices. For example, if a GPS-enabled cell phone is turned 793 on and then immediately places an emergency call, it can take 794 significant additional time before the cell phone acquires a GPS fix 795 and its location. Thus, while it is desirous to base emergency 796 routing on precise caller location information, it is not possible in 797 all circumstances to do so. In some cases, the initial call setup 798 will proceed based on, for example, cell and sector information and 799 then add location information during the call, rather than delaying 800 the initial call setup by an unacceptable amount of time. 802 In addition, the location of a mobile caller, e.g., in a vehicle or 803 aircraft, can change significantly during the emergency call. The 804 PSAP must be able to get updated location information while it is 805 processing the call. 807 Location updates where the location is conveyed by value may be 808 conveyed either in a re-INVITE or UPDATE [RFC3311] request message 809 (where UPDATE is preferred) or the PSAP may subscribe to the location 810 information of the caller, using SIP presence mechanisms (RFC 3265 811 [RFC3265] RFC 3856 [RFC3856]). Authorization for subscriptions is 812 for future study. When location is conveyed by reference, additional 813 dereference operations yield updated location. 815 5.8. Location Validation 817 Location must be validated prior to a device placing an actual 818 emergency call. Validation in this context means both that there is 819 a mapping from the address to a PSAP and that the PSAP understands 820 how to direct responders to the location. This is not as easy as it 821 sounds. There are, for example, many cases of two names for the same 822 street, or two streets with the same name in a city. In some 823 countries, the current system provides validation. For example, in 824 the United States, the Master Street Address Guide (MSAG) records all 825 valid street addresses and is used to ensure that the service 826 addresses in phone billing records correspond to valid emergency 827 service street addresses. Validation is normally a concern for civic 828 addresses, although there could be a concern that a given geo is 829 within at least one PSAP service boundary; that is, a "valid" geo is 830 one for which there is a mapping. 832 The LoST resolver[I-D.ietf-ecrit-lost] includes a validation 833 function. Validation should ideally be performed when a location is 834 entered into a Location Information Server (which is normally a 835 provisioning mechanism in the access carrier's operation and support 836 system). It should be confirmed periodically, because the mapping 837 database undergoes slow change; new streets are added or removed, 838 community names change, postal codes change, etc. Endpoints may wish 839 to validate locations they receive from the access network, and will 840 need to validate manually entered locations. Proxies which insert 841 location may wish to validate locations they recieve from a LIS. 842 Test functions (Section 13) should also re-validate. 844 5.9. Default Location 846 Occasionally, a failure may occur where the access network cannot 847 determine the actual location of the caller. In these cases, it must 848 supply a default location. The default location should be as 849 accurate as the network can determine. For example, in a cable 850 network, a default location for each Cable Modem Termination System 851 (CMTS), with a representative location for all cable modems served by 852 that CMTS could be provided if the network is unable to resolve the 853 subscriber to any unit less than the CMTS. Default locations must be 854 marked as such (how?) so that the PSAP knows that the location is not 855 accurate. 857 6. Routing the Call to the PSAP 859 Emergency calls are routed based on one or more of the following 860 criteria expressed in the call setup request (INVITE): 862 Location: Since each PSAP serves a limited geographic region and 863 transferring existing calls delays the emergency response, calls 864 need to be routed to the most appropriate PSAP. In this 865 architecture, emergency call setup requests contain location 866 information, expressed in civic or geospatial coordinates, that 867 allows such routing. If there is no or imprecise (e.g., cell 868 tower and sector) information at call setup time, an on-going 869 emergency call may also be transferred to another PSAP based on 870 location information that becomes available in mid-call. 871 Type of emergency service: In some jurisdictions, emergency calls 872 for fire, police, ambulance or mountain rescue are directed to 873 just those emergency-specific PSAPs. We support this mechanism by 874 optionally labeling calls with a service identifier 875 [I-D.ietf-ecrit-service-urn]. 876 Media capabilities of caller: In some cases, emergency call centers 877 for specific caller media preferences, such as typed text or 878 video, are separate from voice systems. Also, even if media 879 capability does not affect the selection of the PSAP, there may be 880 call takers within the PSAP that are specifically trained, e.g., 881 in interactive text or sign language communications. Again, we 882 use the callee capabilities [RFC3840] mechanism to label and route 883 such calls. 885 Routing for calls by location and by service is the primary function 886 LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with 887 location (by-value) in either civic or geo form, plus a service 888 identifier, and returns an xml data structure containing a URI (or 889 set of URIs) to route the call to. Normal SIP [RFC3261] routing 890 functions are used to resolve the URI to a next hop destination. 892 The endpoint can complete the LoST mapping from its location at boot 893 time, and periodically thereafter. It should attempt to obtain a 894 "fresh" location, and from that a current mapping when it places an 895 emergency call, and if accessing either its location acquisition 896 function or mapping function fails, it should use this cached value. 897 The call would follow its normal outbound call processing. Networks 898 that support devices that do not implement LoST mapping themseleves 899 would have the outbound proxy do the mapping. The proxy must have 900 the location of the endpoint, which is often difficult for the 901 calling network to accurately determine. The endpoint may have its 902 location, but would not normally include it on the call signaling. 903 There is no mechanism provided in [I-D.ietf-sip-location-conveyance] 904 to allow a proxy to require the endpoint supply location, because 905 that would open the endpoint to an attack by any proxy on the path to 906 get it to reveal location. The Proxy CAN redirect a call to the 907 service URN which, if the device recognized the significance, would 908 include location in the redirected call. All networks should detect 909 emergency calls and supply default location and/or routing if it is 910 not already performed. 912 With the URI obtained from mapping, whether by the endpoint or the 913 proxy, the proxy routes the call. Normal SIP[RFC3261] mechanisms are 914 used to route calls to the URI obtained from the LoST dip. 916 Often, the SIP routing of an emergency call will first route to an 917 incoming call proxy in the domain operated by the emergency service. 918 That proxy is called an "Emergency Services Routing Proxy" (ESRP). 919 The ESRP, which is a normal SIP proxy server, may use a variety of 920 PSAP state information, the location of the caller, and other 921 criteria to onward route the call to the PSAP. 923 7. Signaling of Emergency Calls 925 As discussed above, location is carried in all emergency calls in the 926 call signaling. Since emergency calls carry privacy-sensitive 927 information, they are subject to the requirements for geospatial 928 protocols [RFC3693]. In particular, signaling information should be 929 carried in TLS, i.e., in 'sips' mode. While requiring TLS is 930 actually the way the standards are written, it is unacceptable to 931 have an emergency call fail to complete because a TLS connection was 932 not created, for any reason. In many cases, persistent TLS 933 connections can be maintained between elements to minimize the time 934 needed to establish them. 936 The use of SIP Identity [RFC4474] to protect the headers of the 937 message could improve end-to-end integrity of the information. 939 Details of how location is carried in call signaling can be found in 940 [I-D.ietf-sip-location-conveyance]. 942 8. Caller Preferences 944 SIP Caller Preferences [RFC3841] may be used to signal how the PSAP 945 should handle the call. For example, a language preference expressed 946 in an Accept-Language header may used as a hint to cause the PSAP to 947 route the call to a call taker who speaks the requested language. 949 9. Including a Valid Call-Back Identifier 951 The call-taker must be able to reach the emergency caller if the 952 original call is disconnected. In traditional emergency calls, 953 wireline and wireless emergency calls include a callback identifier 954 for this purpose. In SIP systems, the caller should include a 955 Contact header field indicating its device URI, if available, or 956 possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a 957 proxy. This identifier would be used to initiate call-backs 958 immediately by the call-taker if, for example, the call is 959 prematurely dropped. 961 In addition, a call-back identifier should be included either as the 962 URI in the From header field [RFC3261] preferably verified by SIP 963 Identity[RFC4474]. This identifier would be used to initiate a call- 964 back at a later time and may reach the caller, not necessarily on the 965 same device (and at the same location) as the original emergency 966 call. Both the Contact and From specific requirements are detailed 967 in [I-D.ietf-ecrit-phonebcp] 969 Finally, there may be two other call identifiers included in an 970 emergency call. An identifier may be included which can be used to 971 identify the caller, as opposed to the device or the subscriber of a 972 specific calling service. This identifier may be used to retrieve 973 information about the caller that is independent of calling service. 974 For example, Alice may have home, office and mobile telephony 975 services, but she is the same Alice in all of them. Information 976 about Alice may be kept by an entity independent of any telephony 977 service provider. The caller identity is a URI and is placed in a 978 SIP Call-Info header [RFC3261] using the token "?" following the 979 recommendations in [I-D.ietf-ecrit-phonebcp]. 981 The communications service provider may also include an identifier 982 that may be used to retrieve information specific to the call held by 983 the service provider. This identifier, also a URI may be placed in 984 the Call-Info header using the token "?" per 985 [I-D.ietf-ecrit-phonebcp]. 987 10. Mid-Call Services and Behavior 989 A PSAP may need to REFER[RFC3515] a call to a bridge for 990 conferencing. The caller should also be prepared to have the call 991 transferred (usually attended, but possibly blind) as 992 per[I-D.ietf-sipping-service-examples]. 994 While in a call, a number of of other call features, such as call 995 waiting, must be disabled. This is also discussed in 996 [I-D.ietf-ecrit-phonebcp]. 998 11. Call Termination 1000 It is undesirable for the caller to terminate an emergency call. 1001 Strategies for devices to handle caller attempts to terminate may be 1002 found in [I-D.ietf-ecrit-phonebcp]. PSAP call termination is 1003 accomplished with normal SIP call termination procedures. 1005 12. Media 1007 PSAPs should accept media streams on RTP [RFC3550]. Traditionally, 1008 voice has been the only media stream accepted by PSAPs. In some 1009 countries, text, in the form of BAUDOT codes or similar tone encoded 1010 signaling within a voiceband is accepted ("TTY") for persons who have 1011 hearing disabilities. With the Internet comes a wider array of 1012 potential media which a PSAP should accept. Using SIP signaling 1013 includes the capability to negotiate media. Normal SIP offer/answer 1014 [RFC3264] negotiations should be used to agree on the media streams 1015 to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs 1016 should accept G.711 A law (and mu Law in North America) encoded voice 1017 as described in [RFC3551]. Newer text forms are rapidly appearing, 1018 with Instant Messaging now very common, PSAPs should accept IM with 1019 at least [RFC3428] as well as [RFC3920]. 1021 13. Testing 1023 Since the emergency calling architecture consists of a number of 1024 pieces operated by independent entities, it is important to be able 1025 to test whether an emergency call is likely to succeed without 1026 actually occupying the human resources at a PSAP. Both signaling and 1027 media paths need to be tested since NATs and firewalls may allow the 1028 session setup request to reach the PSAP, while preventing the 1029 exchange of media. 1031 [I-D.ietf-ecrit-phonebcp] includes a description of an automated test 1032 procedure that validates routing, signaling and media path 1033 continuity. This test would be used at boot time, and whenever the 1034 device location changes enough that a new PSAP mapping is returned 1035 from LoST. A manual operation for the test should also be possible. 1037 14. Example Call Flows 1039 TBD 1041 15. Alternatives Considered 1043 This is a non-normative appendix. During discussions of emergency 1044 calling, a number of suggestions are commonly made. Below, we 1045 discuss some of the reasons why these alternatives do not satisfy the 1046 requirements of emergency calling. 1048 15.1. tel URIs 1050 Instead of providing URIs to call routing proxies or end systems, it 1051 has been suggested that end systems be configured with a "tel" URI 1052 [RFC3966]. Such a "tel" URI would have to be routed to a 1053 geographically appropriate telephony gateway, as it is unlikely that 1054 every building, enterprise or residence will have its own gateway. 1055 VoIP devices can be used in networks that are completely unaware of 1056 VoIP services, with VoIP service providers that are physically far 1057 removed from the caller's network location. Thus, the use of a tel 1058 URI simply moves the problem to the outbound proxy, which has to use 1059 the caller's location to determine the appropriate telephony gateway. 1061 In addition, emergency telephone numbers are far from universal, with 1062 some such numbers used for non-emergency purposes elsewhere. Thus, 1063 an outbound proxy would have to ascertain the location of the caller 1064 to guess whether the "tel" URI identifies an emergency call or some 1065 other number. 1067 Thus, "tel" URIs are not likely to be appropriate or sufficient for 1068 identifying emergency calls and do not, by themselves, solve the call 1069 routing problem. 1071 16. Security Considerations 1073 Connecting ANY service to the Internet creates threads to the service 1074 which did not exist before. The emergency call service is especially 1075 critical compared to other services lately connected to the Internet. 1076 It must work reliably even in case of a major disaster when thousands 1077 of citizens call for help simultaneously. Not only does the service 1078 need to be protected but also the liberties of the citizens who might 1079 need to use the service must be considered. 1081 The emergency service is an obvious target for a deliberate attack, 1082 and specifially a denial of service attack. Mechanisms must be 1083 provided to help the emergency networks survive such attacks while 1084 continuing to provide service to genuine callers. 1086 Failure of any security mechanism should normally not prevent an 1087 emergency call to be established. Unlike most systems, suspicious 1088 calls (that is, those where normal security mechanisms are not 1089 attempted or they fail to produce expected valid credentials) are 1090 normally not dropped, but are processed with the call taker made 1091 aware that the information given (location, for example), may not be 1092 accurate. As the discussion in Section 5 shows, providing accurate 1093 location in the presence of a very wide variety of circumstances is 1094 challenging. Exceptions may result in some of the security 1095 mechanisms not being able to be deployed, and yet the information may 1096 be valid. 1098 When the emergency service is under deliberate attack, the policies 1099 on call acceptance may be changed. More stringent compliance to 1100 security recommendations may be enforced, or at least calls with full 1101 security mechanisms in place may be processed before calls without 1102 them. 1104 The decision whether other security mechanisms should be tried or the 1105 call be dropped depends on the policy of the citizen, the policy of 1106 the call router and the policy of the PSAP and out of the scope of 1107 this document. 1109 16.1. Caller Authentication 1111 Fraudulent calls to PSAPs is a significant concern. Current systems 1112 rely on inherent security mechanisms in the PSTN to make sure the 1113 identity of the owner of the telephone is known. As Internet 1114 technologies are increasingly used to place calls, it is becoming 1115 easier to hide the identity of a caller. Use of the SIP Identity 1116 mechanism [RFC4474] i is recommended. If SIP Identity cannot be 1117 provided, carriers should make use of P-Asserted-Identity, [RFC3325] 1119 In keeping with established customs in circuit-switched emergency 1120 calling, authentication cannot be made a prerequisite for routing or 1121 accepting an emergency call. However, a call taker may be more 1122 suspicious of a caller and request additional information if the call 1123 authenticity cannot be verified. 1125 16.2. Location Privacy 1127 Location is sensitive information, it must be protected against 1128 disclosure to unauthorized persons. In most jurisdictions placing an 1129 emergency call implies disclosure of location to all the entities 1130 needing location to properly route and respond to the call. 1131 Nevertheless, even in an emergency, callers have an expectation that 1132 their location will not be divulged outside of that implied release. 1134 During acquisition of the location information, an eavesdropper or 1135 impersonator may obtain location. When DHCP is used, authentication 1136 [RFC3118] should be used to protect the location option. Use of TLS 1137 in other LCPs should be used. Similarly, TLS should be used with SIP 1138 signaling when location is conveyed. However, failure to establish a 1139 security association should never be used to drop an emergency call. 1140 Rather, the operation should be attempted without the security 1141 mechanism. 1143 16.3. PSAP Impersonation 1145 See Section 16.4. 1147 With LoST-based call routing (Section 6), an attacker could modify 1148 the mapping entries for one or more locations, re-routing calls 1149 destined for them. The security mechanisms for provisioning the data 1150 in the LoST database must be robust. 1152 LoST is a distributed database, with many replicas of authoritative 1153 data. An attacker may impersonate a valid LoST server and supply 1154 fraudulent data. An attacker may also perpetrate a denial of service 1155 attack on LoST servers. These issues are addressed in 1156 [I-D.ietf-ecrit-lost]. 1158 Finally, the URI LoST returns would normally contain a domain name. 1159 The domain can be hijacked by several known attacks. TLS should be 1160 used to place calls, with the domain name verified. Using DNSSEC 1161 [RFC4033] on the DNS entries is recommended. As above, failure of 1162 the security mechanism must not impede the processing of an emergency 1163 call; the operation should proceed without security rather than 1164 abandoning the call. 1166 16.4. Preventing Call Misdirection 1168 We need to prevent an emergency call reaching a destination other 1169 than a PSAP. For example, a rogue UA able to intercept SIP requests 1170 might be able to impersonate a PSAP. 1172 In the absence of a globally recognized certificate that ensures that 1173 the owner is a legitimate PSAP, we rely on a chain of trust enforced 1174 by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop 1175 to route the call only to destinations supporting TLS transport. 1176 Each ESRP verifies that the next-hop destination chosen as described 1177 in Section 6 corresponds to the server certificate offered by that 1178 destination. 1180 16.5. Call Signaling Integrity 1182 Preventing a malicious outsider from manipulating call information in 1183 SIP requests can be assured by using "sips" (that is, TLS, hop-by-hop 1184 from caller to emergency call taker. 1186 16.6. Media Integrity and Confidentiality 1188 Media integrity and confidentiality can be assured by the use of 1189 SRTP[RFC3711]. 1191 17. Acknowledgements 1193 This draft was created from a 1194 draft-schulzrinne-sipping-emergency-arch-02 together with sections 1195 from draft-polk-newton-ecrit-arch-considerations-02. 1197 Design Team members participating in this draft creation include 1198 Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger 1199 Marshall, Stu Goldman, Shida Schubert and Tom Taylor. 1201 18. References 1203 18.1. Normative References 1205 [I-D.ietf-ecrit-lost] 1206 Hardie, T., "LoST: A Location-to-Service Translation 1207 Protocol", draft-ietf-ecrit-lost-04 (work in progress), 1208 February 2007. 1210 [I-D.ietf-ecrit-phonebcp] 1211 Rosen, B. and J. Polk, "Best Current Practice for 1212 Communications Services in support of Emergency Calling", 1213 draft-ietf-ecrit-phonebcp-00 (work in progress), 1214 October 2006. 1216 [I-D.ietf-ecrit-requirements] 1217 Schulzrinne, H. and R. Marshall, "Requirements for 1218 Emergency Context Resolution with Internet Technologies", 1219 draft-ietf-ecrit-requirements-12 (work in progress), 1220 August 2006. 1222 [I-D.ietf-ecrit-service-urn] 1223 Schulzrinne, H., "A Uniform Resource Name (URN) for 1224 Services", draft-ietf-ecrit-service-urn-05 (work in 1225 progress), August 2006. 1227 [I-D.ietf-geopriv-pdif-lo-profile] 1228 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 1229 Considerations and Recommendations", 1230 draft-ietf-geopriv-pdif-lo-profile-05 (work in progress), 1231 October 2006. 1233 [I-D.ietf-sip-gruu] 1234 Rosenberg, J., "Obtaining and Using Globally Routable User 1235 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1236 (SIP)", draft-ietf-sip-gruu-11 (work in progress), 1237 October 2006. 1239 [I-D.ietf-sip-location-conveyance] 1240 Polk, J. and B. Rosen, "Session Initiation Protocol 1241 Location Conveyance", 1242 draft-ietf-sip-location-conveyance-07 (work in progress), 1243 February 2007. 1245 [I-D.ietf-sipping-config-framework] 1246 Petrie, D. and S. Channabasappa, "A Framework for Session 1247 Initiation Protocol User Agent Profile Delivery", 1248 draft-ietf-sipping-config-framework-10 (work in progress), 1249 January 2007. 1251 [I-D.rosen-iptel-dialstring] 1252 Rosen, B., "Dialstring parameter for the Session 1253 Initiation Protocol Uniform Resource Identifier", 1254 draft-rosen-iptel-dialstring-05 (work in progress), 1255 March 2007. 1257 [LLDP] "IEEE802.1ab Station and Media Access Control", Dec 2004. 1259 [LLDP-MED] 1260 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1261 Endpoint Discovery". 1263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1264 Requirement Levels", BCP 14, RFC 2119, March 1997. 1266 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1267 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1268 August 1998. 1270 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1271 Messages", RFC 3118, June 2001. 1273 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1274 A., Peterson, J., Sparks, R., Handley, M., and E. 1275 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1276 June 2002. 1278 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1279 with Session Description Protocol (SDP)", RFC 3264, 1280 June 2002. 1282 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1283 Event Notification", RFC 3265, June 2002. 1285 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1286 UPDATE Method", RFC 3311, October 2002. 1288 [RFC3325] "", 2005. 1290 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1291 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1292 for Instant Messaging", RFC 3428, December 2002. 1294 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1295 Method", RFC 3515, April 2003. 1297 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1298 Jacobson, "RTP: A Transport Protocol for Real-Time 1299 Applications", STD 64, RFC 3550, July 2003. 1301 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1302 Video Conferences with Minimal Control", STD 65, RFC 3551, 1303 July 2003. 1305 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1306 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1308 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1309 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1310 RFC 3711, March 2004. 1312 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1313 Configuration Protocol Option for Coordinate-based 1314 Location Configuration Information", RFC 3825, July 2004. 1316 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1317 "Indicating User Agent Capabilities in the Session 1318 Initiation Protocol (SIP)", RFC 3840, August 2004. 1320 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1321 Preferences for the Session Initiation Protocol (SIP)", 1322 RFC 3841, August 2004. 1324 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1325 Initiation Protocol (SIP)", RFC 3856, August 2004. 1327 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1328 Protocol (XMPP): Core", RFC 3920, October 2004. 1330 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1331 Rose, "DNS Security Introduction and Requirements", 1332 RFC 4033, March 2005. 1334 [RFC4103] "", 2005. 1336 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1337 Format", RFC 4119, December 2005. 1339 [RFC4474] "", 2005. 1341 [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol 1342 (DHCPv4 and DHCPv6) Option for Civic Addresses 1343 Configuration Information", RFC 4676, October 2006. 1345 18.2. Informative References 1347 [I-D.ietf-sipping-service-examples] 1348 Johnston, A., "Session Initiation Protocol Service 1349 Examples", draft-ietf-sipping-service-examples-12 (work in 1350 progress), January 2007. 1352 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1353 RFC 3966, December 2004. 1355 Authors' Addresses 1357 Brian Rosen 1358 NeuStar, Inc. 1359 470 Conrad Dr 1360 Mars, PA 16046 1361 US 1363 Email: br@brianrosen.net 1365 Henning Schulzrinne 1366 Columbia University 1367 Department of Computer Science 1368 450 Computer Science Building 1369 New York, NY 10027 1370 US 1372 Phone: +1 212 939 7042 1373 Email: hgs@cs.columbia.edu 1374 URI: http://www.cs.columbia.edu 1376 James Polk 1377 Cisco Systems 1378 3913 Treemont Circle 1379 Colleyville, Texas 76034 1380 US 1382 Phone: +1-817-271-3552 1383 Email: jmpolk@cisco.com 1385 Andrew Newton 1386 SunRocket 1387 8045 Leesburg Pike, Suite 300 1388 Vienna, VA 22182 1389 US 1391 Phone: +1 703 636 8052 1392 Email: andy@hxr.us 1394 Full Copyright Statement 1396 Copyright (C) The IETF Trust (2007). 1398 This document is subject to the rights, licenses and restrictions 1399 contained in BCP 78, and except as set forth therein, the authors 1400 retain all their rights. 1402 This document and the information contained herein are provided on an 1403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1405 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1406 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1407 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1410 Intellectual Property 1412 The IETF takes no position regarding the validity or scope of any 1413 Intellectual Property Rights or other rights that might be claimed to 1414 pertain to the implementation or use of the technology described in 1415 this document or the extent to which any license under such rights 1416 might or might not be available; nor does it represent that it has 1417 made any independent effort to identify any such rights. Information 1418 on the procedures with respect to rights in RFC documents can be 1419 found in BCP 78 and BCP 79. 1421 Copies of IPR disclosures made to the IETF Secretariat and any 1422 assurances of licenses to be made available, or the result of an 1423 attempt made to obtain a general license or permission for the use of 1424 such proprietary rights by implementers or users of this 1425 specification can be obtained from the IETF on-line IPR repository at 1426 http://www.ietf.org/ipr. 1428 The IETF invites any interested party to bring to its attention any 1429 copyrights, patents or patent applications, or other proprietary 1430 rights that may cover technology that may be required to implement 1431 this standard. Please address the information to the IETF at 1432 ietf-ipr@ietf.org. 1434 Acknowledgment 1436 Funding for the RFC Editor function is provided by the IETF 1437 Administrative Support Activity (IASA).