idnits 2.17.1 draft-ietf-ecrit-framework-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (September 8, 2011) is 4585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'M1' is mentioned on line 439, but not defined == Missing Reference: 'M4' is mentioned on line 453, but not defined == Missing Reference: 'M2' is mentioned on line 441, but not defined == Missing Reference: 'M3' is mentioned on line 443, but not defined == Missing Reference: 'M5' is mentioned on line 454, but not defined == Missing Reference: 'M6' is mentioned on line 458, but not defined == Missing Reference: 'M7' is mentioned on line 463, but not defined == Missing Reference: 'M8' is mentioned on line 466, but not defined -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: Informational H. Schulzrinne 5 Expires: March 11, 2012 Columbia U. 6 J. Polk 7 Cisco Systems 8 A. Newton 9 TranTech/MediaSolv 10 September 8, 2011 12 Framework for Emergency Calling using Internet Multimedia 13 draft-ietf-ecrit-framework-13 15 Abstract 17 The IETF has standardized various aspects of placing emergency calls. 18 This document describes how all of those component parts are used to 19 support emergency calls from citizens and visitors to authorities. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 11, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview of how emergency calls are placed . . . . . . . . . . 7 58 4. Which devices and services should support emergency calls . . 11 59 5. Identifying an emergency call . . . . . . . . . . . . . . . . 12 60 6. Location and its role in an emergency call . . . . . . . . . . 13 61 6.1. Types of location information . . . . . . . . . . . . . . 15 62 6.2. Location determination . . . . . . . . . . . . . . . . . . 16 63 6.2.1. User-entered location information . . . . . . . . . . 17 64 6.2.2. Access network "wire database" location information . 18 65 6.2.3. End-system measured location information . . . . . . . 18 66 6.2.4. Network measured location information . . . . . . . . 19 67 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19 68 6.4. Location and references to location . . . . . . . . . . . 20 69 6.5. End system location configuration . . . . . . . . . . . . 20 70 6.6. When location should be configured . . . . . . . . . . . . 22 71 6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 23 72 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 73 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23 74 6.10. Location validation . . . . . . . . . . . . . . . . . . . 24 75 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25 76 6.12. Location format conversion . . . . . . . . . . . . . . . . 26 77 7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26 78 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26 79 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28 80 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28 81 9.2. SIP signaling requirements for User Agents . . . . . . . . 29 82 9.3. SIP signaling requirements for proxy servers . . . . . . . 29 83 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 85 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30 86 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31 87 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 90 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 91 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 92 19. Informative References . . . . . . . . . . . . . . . . . . . . 33 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 95 1. Terminology 97 This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In 98 addition the following terms are used: 99 Access network: The access network supplies IP packet service to an 100 endpoint. Examples of access networks include digital subscriber 101 lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local 102 area networks and cellular data networks. 103 Confidence: Confidence is an estimate indicating how sure the 104 measuring system is that the actual location of the endpoint is 105 within the bounds defined by the uncertainty value, expressed as a 106 percentage. For example, a value of 90% indicates that the actual 107 location is within the uncertainty nine times out of ten. 108 Dispatch Location: The dispatch location is the location used for 109 dispatching responders to the person in need of assistance. The 110 dispatch location must be sufficiently precise to easily locate 111 the caller; it typically needs to be more accurate than the 112 routing location. 113 Location configuration: During location configuration, an endpoint 114 learns its physical location. 115 Location Configuration Protocol (LCP): A protocol used by an 116 endpoint to learn its location. 117 Location conveyance: Location conveyance delivers location 118 information to another element. 119 Location determination: Location determination finds where an 120 endpoint is physically located. For example, the endpoint may 121 contain a Global Navigation Satellite System (GNSS) receiver used 122 to measure its own location or the location may be determined by a 123 network administrator using a wiremap database. 124 Location Information Server (LIS): A Location Information Server 125 stores location information for retrieval by an authorized entity. 126 Mobile device: A mobile device is a user agent that may change its 127 physical location and possibly its network attachment point during 128 an emergency call. 129 NENA (National Emergency Number Association): The National Emergency 130 Number Association is an organization of professionals to "foster 131 the technological advancement, availability and implementation of 132 a universal emergency telephone number system in North America." 133 It develops emergency calling specifications and procedures. 134 Nomadic device (user): A nomadic user agent is connected to the 135 network temporarily, for relatively short durations, but does not 136 move significantly during the during the emergency call. Examples 137 include a laptop using an IEEE 802.11 hotspot or a desk IP phone 138 that is moved occasionally from one cubicle to another. 140 Physical location: A physical location describes where a person or 141 device is located in physical space, described by a coordinate 142 system. It is distinguished from the network location, described 143 by a network address. 144 PSAP: Public Safety Answering Point, the call center that answers 145 emergency calls. 146 Routing Location: The routing location of a device is used for 147 routing an emergency call and may not be as precise as the 148 Dispatch Location. 149 Stationary device: An stationary device is not mobile and is 150 connected to the network at a fixed, long-term-stable physical 151 location. Examples include home PCs or pay phones. 152 Uncertainty: Uncertainty is an estimate, expressed in a unit of 153 length, indicating the diameter of a circle that contains the 154 endpoint with the probability indicated by the confidence value. 156 2. Introduction 158 Requesting help in an emergency using a communications device such as 159 a telephone or mobile phone is an accepted practice in many parts of 160 the world. As communications devices increasingly utilize the 161 Internet to interconnect and communicate, users will expect to use 162 such devices to request help. This document describes establishment 163 of a communications session by a user to a "Public Safety Answering 164 Point" (PSAP), that is, a call center established by response 165 agencies to accept emergency calls. Such citizen/ 166 visitor-to-authority calls can be distinguished from those that are 167 created by responders (authority-to-authority) using public 168 communications infrastructure often involving some kind of priority 169 access as defined in Emergency Telecommunications Service (ETS) in IP 170 Telephony [RFC4190]. They also can be distinguished from emergency 171 warning systems that are authority-to-citizen. 173 Supporting emergency calling requires cooperation by a number of 174 elements, their vendors and service providers. This document 175 discusses how end device and applications create emergency calls, how 176 access networks supply location for some of these devices, how 177 service providers assist the establishment and routing, and how PSAPs 178 receive calls from the Internet. 180 The emergency response community will have to upgrade their 181 facilities to support a wider range of communications services, but 182 cannot be expected to handle wide variations in device and service 183 capability. New devices and services are being made available that 184 could be used to make a request for help that are not traditional 185 telephones, and users are increasingly expecting to use them to place 186 emergency calls. However, many of the technical advantages of 187 Internet multimedia require re-thinking of the traditional emergency 188 calling architecture. This challenge also offers an opportunity to 189 improve the operation of emergency calling technology, while 190 potentially lowering its cost and complexity. 192 It is beyond the scope of this document to enumerate and discuss all 193 the differences between traditional (Public Switched Telephone 194 Network) and IP-based telephony, but calling on the Internet is 195 characterized by: 196 o the interleaving over the same infrastructure of a wider variety 197 of services; 198 o the separation of the access provider from the application 199 provider; 200 o media other than voice (for example, video and text in several 201 forms); 202 o the potential mobility of all end systems, including endpoints 203 nominally thought of as fixed systems and not just those using 204 radio access technology. For example, consider a wired phone 205 connected to a router using a mobile data network such as EV-DO as 206 an uplink. 208 This document focuses on how devices using the Internet can place 209 emergency calls and how PSAPs can handle Internet multimedia 210 emergency calls natively, rather than describing how circuit-switched 211 PSAPs can handle VoIP calls. In many cases, PSAPs making the 212 transition from circuit-switched interfaces to packet-switched 213 interfaces may be able to use some of the mechanisms described here, 214 in combination with gateways that translate packet-switched calls 215 into legacy interfaces, e.g., to continue to be able to use existing 216 call taker equipment. There are many legacy telephone networks that 217 will persist long after most systems have been upgraded to IP 218 origination and termination of emergency calls. Many of these legacy 219 systems route calls based on telephone numbers. Gateways and 220 conversions between existing systems and newer systems defined by 221 this document will be required. Since existing systems are governed 222 primarily by local government regulations and national standards, the 223 gateway and conversion details will be governed by national standards 224 and thus are out of scope for this document. 226 Existing emergency call systems are organized locally or nationally; 227 there are currently few international standards. However, the 228 Internet crosses national boundaries, and thus Internet standards are 229 required. To further complicate matters, VoIP endpoints can be 230 connected through tunneling mechanisms such as virtual private 231 networks (VPNs). Tunnels can obscure the identity of the actual 232 access network that knows the location. This significantly 233 complicates emergency calling, because the location of the caller and 234 the first element that routes emergency calls can be on different 235 continents, with different conventions and processes for handling of 236 emergency calls. 238 The IETF has historically not created national variants of its 239 standards. Thus, this document attempts to take into account best 240 practices that have evolved for circuit switched PSAPs, but makes no 241 assumptions on particular operating practices currently in use, 242 numbering schemes or organizational structures. 244 This document discusses the use of the Session Initiation Protocol 245 (SIP) [RFC3261] by PSAPs and calling parties. While other inter- 246 domain call signaling protocols may be used for emergency calling, 247 SIP is ubiquitous and possesses the proper support of this use case. 248 Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable 249 for inter-domain communications, ruling out Media Gateway Controller 250 protocols such as MGCP or H.248/Megaco. The latter protocols can be 251 used by the enterprise or carrier placing the call, but any such call 252 would reach the PSAP through a media gateway controller, similar to 253 how inter-domain VoIP calls would be placed. Other signaling 254 protocols may also use protocol translation to communicate with a 255 SIP-enabled PSAP. p2psip is not considered in this document. 257 Existing emergency services rely exclusively on voice and 258 conventional text telephony ("TTY") media streams. However, more 259 choices of media offer additional ways to communicate and evaluate 260 the situation as well as to assist callers and call takers in 261 handling emergency calls. For example, instant messaging and video 262 could improve the ability to communicate and evaluate the situation 263 and to provide appropriate instruction prior to arrival of emergency 264 crews. Thus, the architecture described here supports the creation 265 of sessions of any media type, negotiated between the caller and PSAP 266 using existing SIP protocol mechanisms [RFC3264]. 268 This document focuses on the case in which all three steps in the 269 emergency calling process -- location configuration, call routing, 270 and call placement - can be and are performed by the calling 271 endpoint, with the endpoint's Access Service Provider supporting the 272 process by providing location information. Calls in this case may be 273 routed via an application-layer Communications Service Provider 274 (e.g., a Voice Service Provider), but need not be. The underlying 275 protocols can also be used to support other models in which parts of 276 the process are delegated to the Communications Service Provider. 277 This document does not address in detail either these models or 278 interoperability issues between them and the model described here. 280 Since this document is a framework document, it does not include 281 normative behavior. A companion document, [I-D.ietf-ecrit-phonebcp], 282 describes Best Current Practice for this subject and contains 283 normative language for devices, access and calling network elements. 285 Supporting emergency calling does not require any specialized SIP 286 header fields, request methods, status codes, message bodies, or 287 event packages, but does require that existing mechanisms be used in 288 certain specific ways, as described below. User Agents (UAs) unaware 289 of the recommendations in this draft may be able to place emergency 290 calls, but functionality may be impaired. For example, if the UA 291 does not implement the location mechanisms described, an emergency 292 call may not be routed to the correct PSAP, and if the caller is 293 unable to supply his exact location, dispatch of emergency responders 294 may be delayed. Suggested behavior for both endpoints and servers is 295 provided. 297 From the point of view of the PSAP, three essential elements 298 characterize an emergency call: 299 o The call is routed to the most appropriate PSAP, based primarily 300 on the location of the caller. 301 o The PSAP must be able to automatically obtain the location of the 302 caller with sufficient accuracy to dispatch a responder to help 303 the caller. 304 o The PSAP must be able to re-establish a session to the caller if 305 for any reason the original session is disrupted. 307 3. Overview of how emergency calls are placed 309 An emergency call can be distinguished (Section 5) from any other 310 call by a unique Service URN [RFC5031] that is placed in the call 311 set-up signaling when a home or visited emergency dial string is 312 detected. Because emergency services are local to specific 313 geographic regions, a caller obtains his location (Section 6) prior 314 to making emergency calls. To get this location, either a form of 315 measuring, for example, GNSS (Section 6.2.3) is deployed, or the 316 endpoint is configured (Section 6.5) with its location from the 317 access network's Location Information Server (LIS) using a Location 318 Configuration Protocol (LCP). The location is conveyed (Section 6.7) 319 in the SIP signaling with the call. The call is routed (Section 8) 320 based on location using the LoST protocol [RFC5222], which maps a 321 location to a set of PSAP URIs. Each URI resolves to a PSAP or an 322 Emergency Services Routing Proxy (ESRP) that serves as an incoming 323 proxy for a group of PSAPs. The call arrives at the PSAP with the 324 location included in the INVITE request. 326 The following is a quick overview for a typical Ethernet connected 327 telephone using SIP signaling. It illustrates one set of choices for 328 various options presented later in this document. 330 o The phone "boots" and connects to its access network. 331 o The phone gets location via a Location Configuration Protocol 332 (LCP), for example from the DHCP server in civic [RFC4776] and/or 333 geo [RFC6225] forms, a HELD server [RFC5985] or the first level 334 switch's LLDP server [LLDP]. 335 o The phone obtains the local emergency dial string(s) from the LoST 336 [RFC5222] server for its current location. It also receives and 337 caches the PSAP URI obtained from the LoST server. 338 o Some time later, the user places an emergency call. The phone 339 recognizes an emergency call from the dial strings and uses the 340 "urn:service:sos" [RFC5031] URN to mark an emergency call. 341 o It refreshes its location via DHCP and updates the PSAP's URI by 342 querying the LoST mapping server with its location. 343 o It puts its location in the SIP INVITE request in a Geolocation 344 header [I-D.ietf-sip-location-conveyance] and forwards the call 345 using its normal outbound call processing, which commonly involves 346 an outbound proxy. 347 o The proxy recognizes the call as an emergency call and routes the 348 call using normal SIP routing mechanisms to the URI specified. 349 o The call routing commonly traverses an incoming proxy server 350 (ESRP) in the emergency services network. That proxy would route 351 the call to the PSAP. 352 o The call is established with the PSAP and mutually agreed upon 353 media streams are created. 354 o The location of the caller is displayed to the call taker. 356 Configuration Servers 357 . . . . . . . . . . . . . . . . . 358 . . 359 . +--------+ +----------+ . 360 . +--------+ | +----------+ | . 361 . | LIS | | | SIP | | . 362 . | |-+ | Registrar|-+ . 363 . +--------+ +----------+ . 364 . ^ ^ . 365 . . | . . . . . . . | . . . . . . 366 | | 367 |[M1][M4] |[M2] 368 | | +--------+ 369 |+--------------+ +--------+ | 370 || | LoST | | 371 ||+-------------------->| Servers|-+ 372 ||| [M3][M5] +--------+ +-------+ 373 ||| | PSAP2 | 374 ||| +-------+ 375 ||| 376 ||| [M6] +-------+ [M7]+------+ [M8]+-------+ 377 Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 378 +-------+ +------+ +-------+ 380 +-------+ 381 | PSAP3 | 382 +-------+ 384 Figure 1: Emergency Call Component Topology 386 The typical message flow for this example using Alice as the caller: 387 [M1] Alice -> LIS: LCP Request(s) (ask for location) 388 LIS -> Alice: LCP Reply(s) (replies with location) 389 [M2] Alice -> Registrar: SIP REGISTER 390 Registrar -> Alice: SIP 200 OK (REGISTER) 391 [M3] Alice -> LoST Server: Initial LoST Query (contains location) 392 Lost Server -> Alice: Initial LoST Response (contains 393 PSAP-URI and dial string) 395 Some time later, Alice dials or otherwise initiates an emergency call: 397 [M4] Alice -> LIS: LCP Request (update location) 398 LIS -> Alice: LCP Reply (replies with location) 399 [M5] Alice -> LoST Server: Update LoST Query (contains location) 400 Lost Server -> Alice: LoST Response (contains PSAP-URI) 401 [M6] Alice -> Outgoing Proxy: SIP INVITE (service URN, 402 Location and PSAP URI) 403 [M7] Outgoing Proxy -> ESRP: SIP INVITE (service URN, 404 Location and PSAP URI) 405 [M8] ESRP -> PSAP: SIP INVITE (service URN, Location and PSAP URI) 407 The 200 OK response is propagated back from the PSAP to Alice and the 408 ACK response is propagated from Alice to the PSAP. 410 Figure 2: Message Flow 412 Figure 1 shows emergency call component topology and the text above 413 shows call establishment. These include the following components: 414 o Alice - who places the emergency call. 415 o Configuration Servers - Servers providing Alice's UA its IP 416 address and other configuration information, perhaps including 417 location by-value or by-reference. Configuration servers also may 418 include a SIP registrar for Alice's UA. Most SIP UAs will 419 register, so it will be a common scenario for UAs that make 420 emergency calls to be registered with such a server in the 421 originating calling network. Registration would be required for 422 the PSAP to be able to call back after an emergency call is 423 completed. All the configuration messages are labeled M1 through 424 M3, but could easily require more than 3 messages to complete. 425 o LoST server - Processes the LoST request for location plus a 426 Service URN to a PSAP-URI, either for an initial request from a 427 UA, or an in-call routing by the proxy server in the originating 428 network, or possibly by an ESRP. 429 o ESRP - Emergency Services Routing Proxy, a SIP proxy server that 430 is the incoming call proxy in the emergency services domain. The 431 ESRP makes further routing decisions (e.g., based on PSAP state 432 and the location of the caller) to choose the actual PSAP that 433 handles the call. In some jurisdictions, this may involve another 434 LoST query. 435 o PSAP - Emergency calls are answered at a Public Safety Answering 436 Point, a call center. 438 Generally, Alice's UA either has location configured manually, has an 439 integral location measurement mechanism, or it runs a LCP [M1] to 440 obtain location from the access (broadband) network. Alice's UA then 441 will most likely register [M2] with a SIP registrar. This allows her 442 to be contacted by other SIP entities. Next, her UA will perform an 443 initial LoST query [M3] to learn a URI for use if the LoST query 444 fails during an emergency call, or to use to test the emergency call 445 mechanism. The LoST response contains the dial string for emergency 446 calls appropriate for the location provided. 448 At some time after her device has booted, Alice initiates an 449 emergency call. She may do this by dialing an emergency dial string 450 valid for her current ("local") location, or for her "home" location. 452 The UA recognizes the dial string. The UA attempts to refresh its 453 location [M4], and with that location, to refresh the LoST mapping 454 [M5], in order to get the most accurate information to use for 455 routing the call. If the location request or the LoST request fails, 456 or takes too long, the UA uses values it has cached. 458 The UA creates a SIP INVITE [M6] request that includes the location. 459 [I-D.ietf-sip-location-conveyance] defines a SIP Geolocation header 460 that contains either a location-by-reference URI or a [RFC3986] "cid" 461 URL indicating where in the message body the location-by-value is. 463 The INVITE message is routed to the ESRP [M7], which is the first 464 inbound proxy for the emergency services domain. This message is 465 then routed by the ESRP towards the most appropriate PSAP for Alice's 466 location [M8], as determined by the location and other information. 468 A proxy in the PSAP chooses an available call taker and extends the 469 call to its UA. 471 The 200 OK response to the INVITE request traverses the path in 472 reverse, from call taker UA to PSAP proxy to ESRP to originating 473 network proxy to Alice's UA. The ACK request completes the call 474 set-up and the emergency call is established, allowing the PSAP call- 475 taker to talk to Alice about Alice's emergency. 477 4. Which devices and services should support emergency calls 479 Current PSAPs support voice calls and real-time text calls placed 480 through PSTN facilities or systems connected to the PSTN. Future 481 PSAPs will however support Internet connectivity and a wider range of 482 media types and provide higher functionality. In general, if a user 483 could reasonably expect to be able to place a call for help with the 484 device, then the device or service should support emergency calling. 485 Certainly, any device or service that looks like and works like a 486 telephone (wired or mobile) should support emergency calling, but 487 increasingly, users have expectations that other devices and services 488 should work. 490 Devices that create media sessions and exchange audio, video and/or 491 text, and have the capability to establish sessions to a wide variety 492 of addresses, and communicate over private IP networks or the 493 Internet, should support emergency calls. 495 Traditionally, enterprise support of emergency calling is provided by 496 the telephony service provider to the enterprise. In some more 497 recent systems, the enterprise PBX assists emergency calling by 498 providing more fine grained location in larger enterprises. In the 499 future, the enterprise may provide the connection to emergency 500 services itself, not relying on the telephony service provider. 502 5. Identifying an emergency call 504 Using the PSTN, emergency help can often be summoned by dialing a 505 nationally designated, widely known number, regardless of where the 506 telephone was purchased. The appropriate number is determined by the 507 infrastructure the telephone is connected to. However, this number 508 differs between localities, even though it is often the same for a 509 country or region, as it is in many countries in the European Union. 510 In some countries, there is only one uniform digit sequence that is 511 used for all types of emergencies. In others, there are several 512 sequences that are specific to the type of responder needed, e.g., 513 one for police, another for fire. For end systems, on the other 514 hand, it is desirable to have a universal identifier, independent of 515 location, to allow the automated inclusion of location information 516 and to allow the device and other entities in the call path to 517 perform appropriate processing within the signaling protocol in an 518 emergency call set-up. 520 Since there is no such universal identifier, as part of the overall 521 emergency calling architecture, common emergency call URNs are 522 defined in [RFC5031]. For a single number environment the urn is 523 "urn:service:sos". Users are not expected to "dial" an emergency 524 URN. Rather, appropriate emergency dial strings are translated to 525 corresponding service URNs, carried in the Request-URI of the INVITE 526 request. Such translation is best done by the endpoint, because, 527 among other reasons, emergency calls convey location in the 528 signaling, but non-emergency calls do not normally do that. If the 529 device recognizes the emergency call, it can include location. A 530 signaling intermediary (proxy server) can also recognize emergency 531 dial strings if the endpoint fails to do so. 533 For devices that are mobile or nomadic, an issue arises of whether 534 the home or visited dial strings should be used. Many users would 535 prefer that their home dialing sequences work no matter where they 536 are. However, local laws and regulations may require that the 537 visited dialing sequence(s) work. Therefore, the visited dial string 538 must work. Devices may have a way to be configured or learn home 539 dial strings. 541 LoST [RFC5222] provides the mechanism for obtaining the dialing 542 sequences for a given location. LoST servers must return dial 543 strings for emergency services. If the endpoint does not support the 544 translation of dial strings to service URNs, the dialing sequence 545 from the endpoint to its proxy is represented as a dial string 546 [RFC4967] and the outgoing proxy must recognize the dial string and 547 translate it to the equivalent service URN. To determine the local 548 emergency dial string, the proxy needs the location of the endpoint. 549 This may be difficult in situations where the user can roam or be 550 nomadic. Endpoint recognition of emergency dial strings is therefore 551 preferred. If a service provider is unable to guarantee that it can 552 correctly determine local emergency dialstrings, wherever its 553 subscribers may be, then it is required that the endpoint do the 554 recognition. 556 Note: The emergency call practitioners consider it undesirable to 557 have a single button emergency call user interface element. These 558 mechanisms tend to result in a very high rate of false or accidental 559 emergency calls. In order to minimize this issue, practitioners 560 recommend that device should only initiate emergency calls based on 561 entry of specific emergency call dial strings. Speed dial mechanisms 562 may effectively create single button emergency call invocation and 563 practitioners recommend they not be permitted. 565 6. Location and its role in an emergency call 567 Location is central to the operation of emergency services. Location 568 is used for two purposes in emergency call handling: routing of the 569 call and dispatch of responders. It is frequently the case that the 570 caller reporting an emergency is unable to provide a unique, valid 571 location themselves. For this reason, location provided by the 572 endpoint or the access network is needed. For practical reasons, 573 each PSAP generally handles only calls for a certain geographic area, 574 with overload arrangements between PSAPs to handle each others' 575 calls. Other calls that reach it by accident must be manually re- 576 routed (transferred) to the most appropriate PSAP, increasing call 577 handling delay and the chance for errors. The area covered by each 578 PSAP differs by jurisdiction, where some countries have only a small 579 number of PSAPs, while others decentralize PSAP responsibilities to 580 the level of counties or municipalities. 582 In most cases, PSAPs cover at least a city or town, but there are 583 some areas where PSAP coverage areas follow old telephone rate center 584 boundaries and may straddle more than one city. Irregular boundaries 585 are common, often for historical reasons. Routing must be done based 586 on actual PSAP service boundaries -- the closest PSAP, or the PSAP 587 that serves the nominal city name provided in the location, may not 588 be the correct PSAP. 590 Accuracy of routing location is a complex subject. Calls must be 591 routed quickly, but accurately, and location determination is often a 592 time/accuracy tradeoff, especially with mobile devices or self 593 measuring mechanisms. if more accurate routing location is not 594 available it is considered acceptable to base a routing decision on 595 an accuracy equal to the area of one sector of a mobile cell site. 597 Routing to the most appropriate PSAP is always based on the location 598 of the caller, despite the fact that some emergency calls are placed 599 on behalf of someone else, and the location of the incident is 600 sometimes not the location of the caller. In some cases, there are 601 other factors that enter into the choice of the PSAP that gets the 602 call, such as time of day, caller media requests and language 603 preference and call load. However, location of the caller is the 604 primary input to the routing decision. 606 Many mechanisms used to locate a caller have a relatively long "cold 607 start" time. To get a location accurate enough for dispatch may take 608 as much as 30 seconds. This is too long to wait for emergencies. 609 Accordingly, it is common, especially in mobile systems, to use a 610 coarse location, for example, the cell site and sector serving the 611 call, for call routing purposes, and then to update the location when 612 a more precise value is known prior to dispatch. In this document we 613 use "routing location" and "dispatch location" when the distinction 614 matters. 616 Accuracy of dispatch location is sometimes determined by local 617 regulation, and is constrained by available technology. The actual 618 requirement is more stringent than available technology can deliver: 619 It is required that a device making an emergency call close to the 620 "demising" or separation wall between two apartments in a high rise 621 apartment building report location with sufficient accuracy to 622 determine on what side of the wall it is on. This implies perhaps a 623 3 cm accuracy requirement. As of the date of this memo, assisted 624 GNSS uncertainty in mobile phones with 95% confidence cannot be 625 relied upon to be less than hundreds of meters. As technology 626 advances, the accuracy requirements for location will need to be 627 tightened. Wired systems using wire tracing mechanisms can provide 628 location to a wall jack in specific room on a floor in a building, 629 and may even specify a cubicle or even smaller resolution. As this 630 discussion illustrates, emergency call systems demand the most 631 stringent location accuracy available. 633 In Internet emergency calling, where the endpoint is located is 634 determined using a variety of measurement or wire-tracing methods. 635 Endpoints may be configured with their own location by the access 636 network. In some circumstances, a proxy server may insert location 637 into the signaling on behalf of the endpoint. The location is mapped 638 to the URI to send the call to, and the location is conveyed to the 639 PSAP (and other elements) in the signaling. The terms 640 'determination', 'configuration', 'mapping', and 'conveyance' are 641 used for specific aspects of location handling in IETF protocols. 642 Likewise, we employ Location Configuration Protocols, Location 643 Mapping Protocols, and Location Conveyance Protocols for these 644 functions. 646 This document provides guidance for generic network configurations 647 with respect to location. It is recognized that unique issues may 648 exist in some network deployments. The IETF will continue to 649 investigate these unique situations and provide further guidance, if 650 warranted, in future documents. 652 6.1. Types of location information 654 Location can be specified in several ways: 655 Civic: Civic location information describes the location of a person 656 or object by a street address that corresponds to a building or 657 other structure. Civic location may include more fine grained 658 location information such as floor, room and cubicle. Civic 659 information comes in two forms: 660 'Jurisdictional': refers to a civic location using actual 661 political subdivisions, especially for the community name. 662 'Postal': refers to a civic location for mail delivery. The 663 name of the post office sometimes does not correspond to the 664 community name and a postal address may contain post office 665 boxes or street addresses that do not correspond to an actual 666 building. Postal addresses are generally unsuitable for 667 emergency call dispatch because the post office conventions 668 (for community name, for example) do not match those known by 669 the responders. The fact that they are unique can sometimes be 670 exploited to provide a mapping between a postal address and a 671 civic address suitable to dispatch a responder to. In IETF 672 location protocols, there is an element (Postal Community Name) 673 that can be included in a location to provide the post office 674 name as well as the actual jurisdictional community name. 675 There is also an element for a postal code. There is no other 676 accommodation for postal addresses in these protocols. 677 Geospatial (geo): Geospatial addresses contain longitude, latitude 678 and altitude information based on an understood datum and earth 679 shape model (datum). While there have been many datums developed 680 over time, most modern systems are using or moving towards the 681 WGS84 [WGS84] datum. 682 Cell tower/sector: Cell tower/sector is often used for identifying 683 the location of a mobile handset, especially for routing of 684 emergency calls. Cell tower and sectors identify the cell tower 685 and the antenna sector that a mobile device is currently using. 686 Traditionally, the tower location is represented as a point chosen 687 to be within a certain PSAP service boundary who agrees to take 688 calls originating from that tower/sector, and routing decisions 689 are made on that point. Cell/sector information could also be 690 represented as an irregularly shaped polygon of geospatial 691 coordinates reflecting the likely geospatial location of the 692 mobile device. Whatever representation is used must route 693 correctly in the LoST database, where "correct" is determined by 694 local PSAP management. 696 In IETF protocols, both civic and geospatial forms are supported. 697 The civic forms include both postal and jurisdictional fields. A 698 cell tower/sector can be represented as a geo point or polygon or 699 civic location. Other forms of location representation must be 700 mapped into either a geo or civic for use in emergency calls. 702 For emergency call purposes, conversion of location information from 703 civic to geo or vice versa prior to conveyance is not desirable. The 704 location should be sent in the form it was determined. Conversion 705 between geo and civic requires a database. Where PSAPs need to 706 convert from whatever form they receive to another for responder 707 purposes, they have a suitable database. However, if a conversion is 708 done before the PSAP's, and the database used is not exactly the same 709 one the PSAP uses, the double conversion has a high probability of 710 introducing an error. 712 6.2. Location determination 714 As noted above, location information can be entered by the user or 715 installer of a device ("manual configuration"), measured by the end 716 system, can be delivered to the end system by some protocol or 717 measured by a third party and inserted into the call signaling. 719 In some cases, an entity may have multiple sources of location 720 information, possibly partially contradictory. This is particularly 721 likely if the location information is determined both by the end 722 system and a third party. Although self measured location (e.g., 723 GNSS) is attractive, location information provided by the access 724 network could be much more accurate, and more reliable in some 725 environments such as high rise buildings in dense urban areas. 727 The closer an entity is to the source of location, the more likely it 728 is able to determine which location is most appropriate for a 729 particular purpose when there are more than one location 730 determinations for a given endpoint. In emergency calling, the PSAP 731 is the least likely to be able to appropriately choose which location 732 to use when multiple conflicting locations are presented to it. 733 While all available locations can be sent towards the PSAP, the order 734 of the locations should be the sender's best attempt to guide the 735 recipient of which one(s) to use. 737 6.2.1. User-entered location information 739 Location information can be maintained by the end user or the 740 installer of an endpoint in the endpoint itself, or in a database. 742 Location information routinely provided by end users is almost always 743 less reliable than measured or wire database information, as users 744 may mistype location information or may enter civic address 745 information that does not correspond to a recognized (i.e., valid, 746 see Section Section 6.10) address. Users can forget to change the 747 data when the location of a device changes. 749 However, there are always a small number of cases where the automated 750 mechanisms used by the access network to determine location fail to 751 accurately reflect the actual location of the endpoint. For example, 752 the user may deploy his own WAN behind an access network, effectively 753 removing an endpoint some distance from the access network's notion 754 of its location. To handle these exceptional cases, there must be 755 some mechanism provided to manually provision a location for an 756 endpoint by the user or by the access network on behalf of a user. 757 The use of the mechanism introduces the possibility of users falsely 758 declaring themselves to be somewhere they are not. However, this is 759 generally not a problem in practice. Commonly, if an emergency 760 caller insists that he is at a location different from what any 761 automatic location determination system reports he is, responders 762 will always be sent to the user's self-declared location. 764 6.2.2. Access network "wire database" location information 766 Location information can be maintained by the access network, 767 relating some form of identifier for the end subscriber or device to 768 a location database ("wire database"). In enterprise LANs, wiremap 769 databases map Ethernet switch ports to building locations. In DSL 770 installations, the local telephone carrier maintains a mapping of 771 wire-pairs to subscriber addresses. 773 Accuracy of location historically has been to a street address level. 774 However, this is not sufficient for larger structures. The PIDF 775 Location Object [RFC4119] extended by [RFC5139] and [RFC5491] permits 776 interior building/floor/room and even finer specification of location 777 within a street address. When possible, interior location should be 778 supported. 780 The threshold for when interior location is needed is approximately 781 650 square meters. This value is derived from USA fire brigade 782 recommendations of spacing of alarm pull stations. However, interior 783 space layout, construction materials and other factors should be 784 considered. 786 Even for IEEE 802.11 wireless access points, wire databases may 787 provide sufficient location resolution. The location of the access 788 point as determined by the wiremap may be supplied as the location 789 for each of the clients of the access point. However, this may not 790 be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE 791 802.22 that typically have larger cells than those of IEEE 802.11. 792 The civic location of an IEEE 802.16 base station may be of little 793 use to emergency personnel, since the endpoint could be several 794 kilometers away from the base station. 796 Wire databases are likely to be the most promising solution for 797 residential users where a service provider knows the customer's 798 service address. The service provider can then perform address 799 validation (see Section 6.10), similar to the current system in some 800 jurisdictions. 802 6.2.3. End-system measured location information 804 Global Positioning System (GPS) and similar Global Navigation 805 Satellite Systems (e.g., GLONAS and Galileo) receivers may be 806 embedded directly in the end device. GNSS produces relatively high 807 precision location fixes in open-sky conditions, but the technology 808 still faces several challenges in terms of performance (time-to-fix 809 and time-to-first-fix), as well as obtaining successful location 810 fixes within shielded structures, or underground. It also requires 811 all devices to be equipped with the appropriate GNSS capability. 813 Many mobile devices require using some kind of "assist", that may be 814 operated by the access network (A-GPS) or by a government (WAAS). A 815 device may be able to use multiple sources of assist data. 817 GNSS systems may be always enabled and thus location will always be 818 available accurately immediately (assuming the device can "see" 819 enough satellites). Mobile devices may not be able to sustain the 820 power levels required to keep the measuring system active. In such 821 circumstances, when location is needed, the device has to start up 822 the measurement mechanism. This typically takes tens of seconds, far 823 too long to wait to be able to route an emergency call. For this 824 reason, devices that have end-system measured location mechanisms but 825 need a cold start period lasting more than a couple seconds need 826 another way to get a routing location. Typically this would be a 827 location associated with a radio link (cell site/sector). 829 6.2.4. Network measured location information 831 The access network may locate end devices. Techniques various forms 832 of triangulation. Elements in the network infrastructure triangulate 833 end systems based on signal strength, angle of arrival or time of 834 arrival. Common mechanisms deployed include: 835 o Time Difference Of Arrival - TDOA 836 o Uplink Time Difference Of Arrival - U-TDOA 837 o Angle of Arrival - AOA 838 o RF fingerprinting 839 o Advanced Forward Link Trilateration - AFLT 840 o Enhanced Forward Link Trilateration - EFLT 841 Sometimes multiple mechanisms are combined, for example A-GPS with 842 AFLT. 844 6.3. Who adds location, endpoint or proxy 846 The IETF emergency call architecture prefers endpoints to learn their 847 location and supply it on the call. Where devices do not support 848 location, proxy servers may have to add location to emergency calls. 849 Some calling networks have relationships with all access networks the 850 device may be connected to, and that may allow the proxy to 851 accurately determine the location of the endpoint. However, NATs and 852 other middleboxes often make it impossible to determine a reference 853 identifier the access network could provide to a LIS to determine the 854 location of the device. Systems designers are discouraged from 855 relying on proxies to add location. The technique may be useful in 856 some limited circumstances as devices are upgraded to meet the 857 requirements of this document, or where relationships between access 858 networks and calling networks are feasible and can be relied upon to 859 get accurate location. 861 Proxy insertion of location complicates dial string recognition. As 862 noted in Section 6, local dial strings depend on the location of the 863 caller. If the device does not know its own location, it cannot use 864 the LoST service to learn the local emergency dial strings. The 865 calling network must provide another way for the device to learn the 866 local dial string, and update it when the user moves to a location 867 where the dial string(s) change, or do the dial string determination 868 itself. 870 6.4. Location and references to location 872 Location information may be expressed as the actual civic or 873 geospatial value but can be transmitted as by value (wholly contained 874 within the signaling message) or by reference (i.e., as a URI 875 pointing to the value residing on a remote node waiting to be 876 dereferenced). 878 When location is transmitted by value, the location information is 879 available to entity in the call path. On the other hand, location 880 objects can be large, and only represent a single snapshot of the 881 device's location. Location references are small and can be used to 882 represent a time-varying location, but the added complexity of the 883 dereference step introduces a risk that location will not be 884 available to parties that need it. 886 6.5. End system location configuration 888 Unless a user agent has access to provisioned or locally measured 889 location information, it must obtain it from the access network. 890 There are several location configuration protocols (LCPs) that can be 891 used for this purpose including DHCP, HELD and LLDP: 892 DHCP can deliver civic [RFC4776] or geospatial [RFC6225] 893 information. User agents need to support both formats. Note that 894 a user agent can use DHCP, via the DHCP REQUEST or INFORM 895 messages, even if it uses other means to acquire its IP address. 896 HELD [RFC5985] can deliver a civic or geo location object, by value 897 or by reference, via a layer 7 protocol. The query typically uses 898 the IP address of the requester as an identifier and returns the 899 location value or reference associated with that identifier. HELD 900 is typically carried in HTTP. 901 Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device 902 extensions [LLDP-MED] can be used to deliver location information 903 directly from the Layer 2 network infrastructure, and also 904 supports both civic and geo formats identical in format to DHCP 905 methods. 907 Each LCP has limitations in the kinds of networks that can reasonably 908 support it. For this reason, it is not possible to choose a single 909 mandatory-to-deploy LCP. For endpoints with common network 910 connections (such as an Ethernet jack or a WiFi connection) serious 911 incompatibilities would ensue unless every network supported every 912 protocol, or alternatively, every device supported every protocol. 913 For this reason, a mandatory-to-implement list of LCPs is established 914 in [I-D.ietf-ecrit-phonebcp]. Every endpoint that could be used to 915 place emergency calls must implement all of the protocols on the 916 list. Every access network must deploy at least one of them. Since 917 it is the variability of the networks that prevent a single protocol 918 from being acceptable, it must be the endpoints that implement all of 919 them, and to accommodate a wide range of devices, networks must 920 deploy at least one of them. 922 Often, network operators and device designers believe that they have 923 a simpler environment and some other network specific mechanism can 924 be used to provide location. Unfortunately, it is very rare to 925 actually be able to limit the range of devices that may be connected 926 to a network. For example, existing mobile networks are being used 927 to support routers and LANs behind a wireless data network WAN 928 connection, with Ethernet connected phones connected to that. It is 929 possible that the access network could support a protocol not on the 930 list, and require every handset in that network to use that protocol 931 for emergency calls. However, the Ethernet-connected phone won't be 932 able to acquire location, and the user of the phone is unlikely to be 933 dissuaded from placing an emergency call on that phone. The 934 widespread availability of gateways, routers and other network- 935 broadening devices means that indirectly connected endpoints are 936 possible on nearly every network. Network operators and vendors are 937 cautioned that shortcuts to meeting this requirement are seldom 938 successful. 940 Location for non-mobile devices is normally expected to be acquired 941 at network attachment time and retained by the device. It should be 942 refreshed when the cached value expires. For example, if DHCP is the 943 acquisition protocol, refresh of location may occur when the IP 944 address lease is renewed. At the time of an emergency call, the 945 location should be refreshed, with the retained location used if the 946 location acquisition does not immediately return a value. Mobile 947 devices may determine location at network attachment time and 948 periodically thereafter as a backup in case location determination at 949 the time of call does not work. Mobile device location may be 950 refreshed when a TTL expires or the device moves beyond some 951 boundaries (as provided by [RFC5222]). Normally, mobile devices will 952 acquire its location at call time for use in an emergency call 953 routing. See Section 6.8 for a further discussion on location 954 updates for dispatch location. 956 There are many examples of endpoints which are user agent 957 applications running on a more general purpose device, such as a 958 personal computer. On some systems, layer 2 protocols like DHCP and 959 LLDP may not be directly accessible to applications. It is desirable 960 for an operating system to have an API which provides the location of 961 the device for use by any application, especially those supporting 962 emergency calls. 964 6.6. When location should be configured 966 Devices should get routing location immediately after obtaining local 967 network configuration information. The presence of NAT and VPN 968 tunnels (that assign new IP addresses to communications) can obscure 969 identifiers used by LCPs to determine location, especially for HELD. 970 In some cases, such as residential NAT devices, the NAT is placed 971 between the endpoint and the access network demarcation point and 972 thus the IP address seen by the access network is the right 973 identifier for location of the residence. However, in many 974 enterprise environments, VPN tunnels can obscure the actual IP 975 address. Some VPN mechanisms can be bypassed so that a query to the 976 LCP can be designated to go through the direct IP path, using the 977 correct IP address, and not through the tunnel. In other cases, no 978 bypass is possible, but location can be configured before the VPN is 979 established. Of course, LCPs that use layer 2 mechanisms (DHCP 980 Location options and LLDP-MED) are usually immune from such problems 981 because they do not use the IP address as the identifier for the 982 device seeking location. 984 It is desirable that routing location information be periodically 985 refreshed. A LIS supporting a million subscribers each refreshing 986 once per day would need to support a query rate of 1,000,000 / (24 * 987 60 * 60) = 12 queries per second. For networks with mobile devices, 988 much higher refresh rates could be expected. 990 It is desirable for routing location information to be requested 991 immediately before placing an emergency call. However, if there is 992 any significant delay in getting more recent location, the call 993 should be placed with the most recent location information the device 994 has. In mobile handsets, routing is often accomplished with the cell 995 site and sector of the tower serving the call, because it can take 996 many seconds to start up the location determination mechanism and 997 obtain an accurate location. 999 There is a tradeoff between the time it takes to get a routing 1000 location and the accuracy (technically, confidence and uncertainty) 1001 obtained. Routing an emergency call quickly is required. However, 1002 if location can be substantially improved by waiting a short time 1003 (e.g., for some sort of "quick fix"), it's preferable to wait. Three 1004 seconds, the current nominal time for a quick fix, is a very long 1005 time add to post dial delay. 1007 NENA recommends [NENAi3TRD] that IP based systems complete calls in 1008 two seconds from last dial press to ring at PSAP. 1010 6.7. Conveying location 1012 When an emergency call is placed, the endpoint should include 1013 location in the call signaling. This is referred to as "conveyance" 1014 to distinguish it from "configuration". In SIP, the location 1015 information is conveyed following the procedures in 1016 [I-D.ietf-sip-location-conveyance]. Since the form of the location 1017 information obtained by the acquisition protocol may not be the same 1018 as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the 1019 endpoint from the LCP form to PIDF may be required. 1021 6.8. Location updates 1023 As discussed above, it may take some time for some measurement 1024 mechanisms to get a location accurate enough for dispatch, and a 1025 routing location with less accuracy may be provided to get the call 1026 established quickly. The PSAP needs the dispatch location before it 1027 sends the call to the responder. This requires an update of the 1028 location. In addition, the location of some mobile callers, e.g., in 1029 a vehicle or aircraft, can change significantly during the emergency 1030 call. 1032 A PSAP has no way to request an update of a location provided by 1033 value. If the UAC gets new location, it must signal the PSAP using a 1034 new INVITE or an UPDATE transaction with a new Geolocation header to 1035 supply the new location. 1037 With the wide variation in determination mechanisms, the PSAP does 1038 not know when accurate location may be available. The preferred 1039 mechanism is that the LIS notifies the PSAP when an accurate location 1040 is available rather than requiring a poll operation from the PSAP to 1041 the LIS. The SIP Presence subscription [RFC3856] provides a suitable 1042 mechanism. 1044 When using a HELD dereference, the PSAP must specify the value 1045 "emergencyDispatch" for the ResponseTime parameter. Since typically 1046 the LIS is local relative to the PSAP, the LIS can be aware of the 1047 update requirements of the PSAP 1049 6.9. Multiple locations 1051 Getting multiple locations all purported to describe the location of 1052 the caller is confusing to all, and should be avoided. Handling 1053 multiple locations at the point where a PIDF is created is discussed 1054 in [RFC5491]. Conflicting location information is particularly 1055 harmful if different routes (PSAPs) result from LoST queries for the 1056 multiple locations. When they occur anyway, the general guidance is 1057 that the entity earliest in the chain generally has more knowledge 1058 than later elements to make an intelligent decision, especially about 1059 which location will be used for routing. It is permissible to send 1060 multiple locations towards the PSAP, but the element that chooses the 1061 route must select exactly one location to use with LoST. 1063 Guidelines for dealing with multiple locations are also given in 1064 [RFC5222]. If a UA gets multiple locations, it must choose the one 1065 to use for routing, but it may send all of the locations it has in 1066 the signaling. If a proxy is inserting location and has multiple 1067 locations, it must choose exactly one to use for routing, marking it 1068 as such (per [I-D.ietf-sip-location-conveyance], and send it as well 1069 as any others it has. 1071 The UA or proxy should have the ability to understand how and from 1072 whom it learned its location, and should include this information in 1073 the location objects that are sent to the PSAP. That labeling 1074 provides the call-taker with information to make decisions upon, as 1075 well as guidance for what to ask the caller and what to tell the 1076 responders. 1078 Endpoints or proxies may be tempted to send multiple versions of the 1079 same location. For example a database may be used to "geocode" or 1080 "reverse geocode", that is, convert from civic to geo or vice versa. 1081 It is very problematic to use derived locations in emergency calls. 1082 The PSAP and the responders have very accurate databases which they 1083 use to convert, most commonly from a reported geo to a civic suitable 1084 for dispatching responders. If one database is used to convert from, 1085 say, civic to geo, and another converts from geo to civic, errors 1086 will often occur where the databases are slightly different. "Off by 1087 one" errors are serious when responders go to the wrong location. 1088 Derived locations should be marked with a "derived" method token 1089 [RFC4119]. If an entity gets a location which has a measured or 1090 other original method, and another with a derived method, it must use 1091 the original value for the emergency call. 1093 6.10. Location validation 1095 Validation in this context means both that there is a mapping from 1096 the address to a PSAP and that the PSAP understands how to direct 1097 responders to the location. It is recommended that location be 1098 validated prior to a device placing an actual emergency call; some 1099 jurisdictions require that this be done. 1101 Determining the addresses that are valid can be difficult. There 1102 are, for example, many cases of two names for the same street, or two 1103 streets with the same name, but different "suffixes" (Avenue, Street, 1104 Circle) in a city. In some countries, the current system provides 1105 validation. For example, in the United States of America, the Master 1106 Street Address Guide (MSAG) records all valid street addresses and is 1107 used to ensure that the service addresses in phone billing records 1108 correspond to valid emergency service street addresses. Validation 1109 is normally only a concern for civic addresses, although there could 1110 be some determination that a given geo is within at least one PSAP 1111 service boundary; that is, a "valid" geo is one where there is a 1112 mapping in the LoST server. 1114 LoST [RFC5222] includes a location validation function. Validation 1115 is normally performed when a location is entered into a Location 1116 Information Server. It should be confirmed periodically, because the 1117 mapping database undergoes slow change and locations which previously 1118 validated may eventually fail validation. Endpoints may wish to 1119 validate locations they receive from the access network, and will 1120 need to validate manually entered locations. Proxies that insert 1121 location may wish to validate locations they receive from a LIS. 1122 When the test functions (Section 15) are invoked, the location used 1123 should be validated. 1125 When validation fails, the location given should not be used for an 1126 emergency call, unless no other valid location is available. Bad 1127 location is better than no location. If validation is completed when 1128 location is first loaded into a LIS, any problems can be found and 1129 fixed before devices could get the bad location. Failure of 1130 validation arises because an error is made in determining the 1131 location, although occasionally the LoST database is not up to date 1132 or has faulty information. In either case, the problem must be 1133 identified and should be corrected before using the location. 1135 6.11. Default location 1137 Occasionally, the access network cannot determine the actual location 1138 of the caller. In these cases, it must supply a default location. 1139 The default location should be as accurate as the network can 1140 determine. For example, in a cable network, a default location for 1141 each Cable Modem Termination System (CMTS), with a representative 1142 location for all cable modems served by that CMTS could be provided 1143 if the network is unable to resolve the subscriber to anything more 1144 precise than the CMTS. Default locations must be marked as such so 1145 that the PSAP knows that the location is not accurate. 1147 6.12. Location format conversion 1149 The endpoint is responsible for mapping any form of location it 1150 receives from an LCP into PIDF-LO form if the LCP did not directly 1151 return a PIDF-LO. 1153 7. LIS and LoST discovery 1155 Endpoints must be able to discover a LIS if the HELD protocol is 1156 used, and a LoST server. DHCP options are defined for this purpose, 1157 namely [RFC5986] and [RFC5223]. 1159 Until such DHCP records are widely available, it may be necessary for 1160 the service provider to provision a LoST server address in the 1161 device. The endpoint can also do a DNS SRV query to find a LoST 1162 server. In any environment, more than one of these mechanisms may 1163 yield a LoST server, and they may be different. The recommended 1164 priority is DHCP first, provisioned value second, and DNS SRV query 1165 in the SIP domain third. 1167 8. Routing the call to the PSAP 1169 Emergency calls are routed based on one or more of the following 1170 criteria expressed in the call setup request (INVITE): 1171 Location: Since each PSAP serves a limited geographic region and 1172 transferring existing calls delays the emergency response, calls 1173 need to be routed to the most appropriate PSAP. In this 1174 architecture, emergency call setup requests contain location 1175 information, expressed in civic or geospatial coordinates, that 1176 allows such routing. 1177 Type of emergency service: In some jurisdictions, emergency calls 1178 for specific emergency services such as fire, police, ambulance or 1179 mountain rescue are directed to just those emergency-specific 1180 PSAPs. This mechanism is supported by marking emergency calls 1181 with the proper service identifier [RFC5031]. Even in single 1182 number jurisdictions, not all services are dispatched by PSAPs and 1183 may need alternate URNs to route calls to the appropriate call 1184 center. 1185 Media capabilities of caller: In some cases, emergency call centers 1186 for specific caller media preferences, such as typed text or 1187 video, are separate from PSAPs serving voice calls. ESRPs are 1188 expected to be able to provide routing based on media. Also, even 1189 if media capability does not affect the selection of the PSAP, 1190 there may be call takers within the PSAP that are specifically 1191 trained, e.g., in interactive text or sign language 1192 communications, where routing within the PSAP based on the media 1193 offer would be provided. 1195 Providing a URL to route emergency calls by location and by type of 1196 service is the primary function LoST [RFC5222] provides. LoST 1197 accepts a query with location (by-value) in either civic or geo form, 1198 plus a service identifier, and returns a URI (or set of URIs) to 1199 route the call to. Normal SIP [RFC3261] routing functions are used 1200 to resolve the URI to a next hop destination. 1202 The endpoint can complete the LoST mapping from its location at boot 1203 time, and periodically thereafter. It should attempt to obtain a 1204 "fresh" location, and from that a current mapping when it places an 1205 emergency call. If accessing either its location acquisition or 1206 mapping functions fail, it should use its cached value. The call 1207 would follow its normal outbound call processing. 1209 Determining when the device leaves the area provided by the LoST 1210 service can tax small mobile devices. For this reason, the LoST 1211 server should return a simple (small number of points) polygon for 1212 geospatial location. This can be a simple enclosing rectangle of the 1213 PSAP service area when the reported point is not near an edge, or a 1214 smaller polygonal edge section when the reported location is near an 1215 edge. Civic location is uncommon for mobile devices, but reporting 1216 that the same mapping is good within a community name, or even a 1217 street, may be very helpful for WiFi connected devices that roam and 1218 obtain civic location from the access point they are connected to. 1220 Networks that support devices that do not implement LoST mapping 1221 themselves may need the outbound proxy do the mapping. If the 1222 endpoint recognized the call was an emergency call, provided the 1223 correct service URN and/or included location on the call in a 1224 Geolocation header, a proxy server could easily accomplish the 1225 mapping. 1227 However, if the endpoint did not recognize the call was an emergency 1228 call, and thus did not include location, the proxy's task is more 1229 difficult. It is often difficult for the calling network to 1230 accurately determine the endpoint's location. The endpoint may have 1231 its own location, but would not normally include it on the call 1232 signaling unless it knew it was an emergency call. There is no 1233 mechanism provided in [I-D.ietf-sip-location-conveyance] for a proxy 1234 to request the endpoint supply its location, because that would open 1235 the endpoint to an attack by any proxy on the path to get it to 1236 reveal location. The proxy can attempt to redirect a call to the 1237 service URN which, if the device recognizes the significance, would 1238 include location in the redirected call from the device. All 1239 networks elements should detect emergency calls and supply default 1240 location and/or routing if it is not already present. 1242 The LoST server would normally be provided by the local emergency 1243 authorities, although the access network or calling network might run 1244 its own server using data provided by the emergency authorities. 1245 Some enterprises may have local responders and call centers, and 1246 could operate their own LoST server, providing URIs to in-house 1247 "PSAPs". Local regulations might limit the ability of enterprises to 1248 direct emergency calls to in-house services. 1250 The ESRP, which is a normal SIP proxy server in the signaling path of 1251 the call, may use a variety of PSAP state information, the location 1252 of the caller, and other criteria to onward route the call to the 1253 PSAP. In order for the ESRP to route on media choice, the initial 1254 INVITE request has to supply an SDP offer. 1256 9. Signaling of emergency calls 1258 9.1. Use of TLS 1260 Best Current Practice for SIP user agents [RFC4504] including 1261 handling of audio, video and real-time text [RFC4103] should be 1262 applied. As discussed above, location is carried in all emergency 1263 calls in the call signaling. Since emergency calls carry privacy- 1264 sensitive information, they are subject to the requirements for 1265 geospatial protocols [RFC3693]. In particular, signaling information 1266 should be carried in TLS, i.e., in 'sips' mode with a ciphersuite 1267 which includes strong encryption (e.g., AES). There are exceptions 1268 in [RFC3693] for emergency calls. For example, local policy may 1269 dictate that location is sent with an emergency call even if the 1270 user's policy would otherwise prohibit that. Nevertheless, 1271 protection from eavesdropping of location by encryption should be 1272 provided. 1274 It is unacceptable to have an emergency call fail to complete because 1275 a TLS connection was not created for any reason. Thus, the call 1276 should be attempted with TLS, but if the TLS session establishment 1277 fails, the call should be automatically retried without TLS. 1278 [RFC5630] recommends that to achieve this effect the target specifies 1279 a sip URI, but use TLS on the outbound connection. An element that 1280 receives a request over a TLS connection should attempt to create a 1281 TLS connection to the next hop. 1283 In many cases, persistent TLS connections can be maintained between 1284 elements to minimize the time needed to establish them [RFC5626]. In 1285 other circumstances, use of session resumption [RFC5077] is 1286 recommended. IPsec [RFC4301] is an acceptable alternative to TLS 1287 when used with an equivalent crypto suite. 1289 Location may be used for routing by multiple proxy servers on the 1290 path. Confidentiality mechanisms such as S/MIME encryption of SIP 1291 signaling [RFC3261] cannot be used because they obscure location. 1292 Only hop-by-hop mechanisms such as TLS should be used. Implementing 1293 location conveyance in SIP mandates inclusion of TLS support. 1295 9.2. SIP signaling requirements for User Agents 1297 SIP UAs that recognize local dial strings, insert location, and 1298 perform emergency call routing will create SIP INVITE messages with 1299 the Service URN in the Request URI, the LoST-determined URI for the 1300 PSAP in a Route header, and the location in a Geolocation header. 1301 The INVITE request must also have appropriate call back identifiers 1302 (in Contact and From headers). To enable media sensitive routing, 1303 the call should include an SDP offer. 1305 SIP caller preferences [RFC3841] can be used to signal how the PSAP 1306 should handle the call. For example, a language preference expressed 1307 in an Accept-Language header may be used as a hint to cause the PSAP 1308 to route the call to a call taker who speaks the requested language. 1309 SIP caller preferences may also be used to indicate a need to invoke 1310 a relay service for communication with people with disabilities in 1311 the call. 1313 9.3. SIP signaling requirements for proxy servers 1315 At least one SIP proxy server in the path of an emergency call must 1316 be able to assist UAs that are unable to provide any of the location 1317 based routing steps and recognition of dial strings. A Proxy can 1318 recognize the lack of location awareness by the lack of a Geolocation 1319 header. They can recognize the lack of dial string recognition by 1320 the presence of the local emergency call dial string in the From 1321 header without the service URN being present. They should obtain the 1322 location of the endpoint if possible, and use a default location if 1323 they can not, inserting it in a Geolocation header. They should 1324 query LoST with the location and put the resulting URI in a Route, 1325 with the appropriate service URN in the Request URI. In any event, 1326 they are also expected to provide information for the caller using 1327 SIP Identity or P-Asserted-Identity. It is often a regulatory matter 1328 whether calls normally marked as anonymous are passed as anonymous 1329 when they are emergency calls. Proxies must conform to the local 1330 regulation or practice. 1332 10. Call backs 1334 The call-taker must be able to reach the emergency caller if the 1335 original call is disconnected. In traditional emergency calls, 1336 wireline and wireless emergency calls include a callback identifier 1337 for this purpose. There are two kinds of call backs. When a call is 1338 dropped, or the call taker realizes that some important information 1339 is needed that it doesn't have, it must call back the device that 1340 placed the emergency call. The PSAP, or a responder, may need to 1341 call back the caller much later, and for that purpose, it wants a 1342 normal SIP Address of Record. In SIP systems, the caller must 1343 include a Contact header field in an emergency call containing a 1344 globally routable URI, possibly a GRUU [RFC5627]. This identifier 1345 would be used to initiate call-backs immediately by the call-taker 1346 if, for example, the call is prematurely dropped. A concern arises 1347 with B2BUAs that manipulate Contact headers. Such B2BUAs should 1348 always include a Contact header that routes to the same device. 1350 In addition, a call-back identifier as an Address of Record (AoR) 1351 must be included either as the URI in the From header field [RFC3261] 1352 verified by SIP Identity [RFC4474] or as a network asserted URI 1353 [RFC3325]. If the latter, the PSAP will need to establish a suitable 1354 spec(t) with the proxies that send it emergency calls. This 1355 identifier would be used to initiate a call-back at a later time and 1356 may reach the caller, not necessarily on the same device (and at the 1357 same location) as the original emergency call as per normal SIP 1358 rules. It is often a regulatory matter whether calls normally marked 1359 as anonymous are passed as anonymous when they are emergency calls. 1360 Proxies must conform to the local regulation or practice. 1362 11. Mid-call behavior 1364 Some PSAPs often include dispatchers, responders or specialists on a 1365 call. Some responder's dispatchers are not located in the primary 1366 PSAP, the call may have to be transferred to another PSAP. Most 1367 often this will be an attended transfer, or a bridged transfer. 1368 Therefore a PSAP may need to a REFER request [RFC3515] a call to a 1369 bridge for conferencing. Devices which normally involve the user in 1370 transfer operations should consider the effect of such interactions 1371 when a stressed user places an emergency call. Requiring UI 1372 manipulation during such events may not be desirable. Relay services 1373 for communication with people with disabilities may be included in 1374 the call with the bridge. The UA should be prepared to have the call 1375 transferred (usually attended, but possibly blind) per [RFC5359]. 1377 12. Call termination 1379 It is undesirable for the caller to terminate an emergency call. 1380 PSAP terminates a call using the normal SIP call termination 1381 procedures, i.e., with a BYE request. 1383 13. Disabling of features 1385 Certain features that can be invoked while a normal call is active 1386 are not permitted when the call is an emergency call. Services such 1387 as call waiting, call transfer, three way call and hold should be 1388 disabled. 1390 Certain features such as call forwarding can interfere with calls 1391 from a PSAP and should be disabled. There is no way to reliably 1392 determine a PSAP call back. A UA may be able to determine a PSAP 1393 call back by examining the domain of incoming calls after placing an 1394 emergency call and comparing that to the domain of the answering PSAP 1395 from the emergency call. Any call from the same domain and directed 1396 to the supplied Contact header or AoR after an emergency call should 1397 be accepted as a call-back from the PSAP if it occurs within a 1398 reasonable time after an emergency call was placed. 1400 14. Media 1402 PSAPs should always accept RTP media streams [RFC3550]. 1403 Traditionally, voice has been the only media stream accepted by 1404 PSAPs. In some countries, text, in the form of Baudot codes or 1405 similar tone encoded signaling within a voiceband is accepted ("TTY") 1406 for persons who have hearing disabilities. Using SIP signaling 1407 includes the capability to negotiate media. Normal SIP offer/answer 1408 [RFC3264] negotiations should be used to agree on the media streams 1409 to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs 1410 should accept G.711 A-law (and mu-law in North America) encoded voice 1411 as described in [RFC3551]. Newer text forms are rapidly appearing, 1412 with instant messaging now very common, PSAPs should accept IM with 1413 at least "pager-mode" MESSAGE request [RFC3428] as well as Message 1414 Session Relay Protocol [RFC4975]. Video may be important to support 1415 Video Relay Service (sign language interpretation) as well as modern 1416 video phones. 1418 It is desirable for media to be kept secure by the use of Secure RTP 1419 [RFC3711], using DTLS [RFC5764] for keying. 1421 15. Testing 1423 Since the emergency calling architecture consists of a number of 1424 pieces operated by independent entities, it is important to be able 1425 to test whether an emergency call is likely to succeed without 1426 actually occupying the human resources at a PSAP. Both signaling and 1427 media paths need to be tested since NATs and firewalls may allow the 1428 session setup request to reach the PSAP, while preventing the 1429 exchange of media. 1431 [I-D.ietf-ecrit-phonebcp]includes a description of an automated test 1432 procedure that validates routing, signaling and media path 1433 continuity. This test would be used within some random interval 1434 after boot time, and whenever the device location changes enough that 1435 a new PSAP mapping is returned by the LoST server. 1437 The PSAP needs to be able to control frequency and duration of the 1438 test, and since the process could be abused, it may temporarily or 1439 permanently suspend its operation. 1441 There is a concern associated with testing during a so-called 1442 "avalanche-restart" event where, for example a large power outage 1443 affects a large number of endpoints, that, when power is restored, 1444 all attempt to reboot and, possibly, test. Devices need to randomize 1445 their initiation of a boot time test to avoid the problem. 1447 16. Security Considerations 1449 Security considerations for emergency calling have been documented in 1450 [RFC5069] and [RFC6280]. 1452 This document suggests that security (TLS or IPsec) be used hop by 1453 hop on a SIP call to protect location information, identity, etc. It 1454 also suggests that if the attempt to create a security association 1455 fails, the call be retried without the security. It's more important 1456 to get an emergency call through than to protect the data; indeed, in 1457 many jurisdictions privacy is explicitly waived when making emergency 1458 calls. Placing a call without security may reveal user information, 1459 including location. The alternative - failing the call if security 1460 cannot be established, is considered unacceptable. 1462 17. IANA Considerations 1464 This document has no actions for IANA. 1466 18. Acknowledgments 1468 This draft was created from a 1469 draft-schulzrinne-sipping-emergency-arch-02 together with sections 1470 from draft-polk-newton-ecrit-arch-considerations-02. 1472 Design Team members participating in this draft creation include 1473 Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, 1474 Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments 1475 and input were provided by Richard Barnes, Barbara Stark and James 1476 Winterbottom. 1478 19. Informative References 1480 [I-D.ietf-ecrit-phonebcp] 1481 Rosen, B. and J. Polk, "Best Current Practice for 1482 Communications Services in support of Emergency Calling", 1483 draft-ietf-ecrit-phonebcp-20 (work in progress), 1484 September 2011. 1486 [I-D.ietf-sip-location-conveyance] 1487 Polk, J. and B. Rosen, "Location Conveyance for the 1488 Session Initiation Protocol", 1489 draft-ietf-sip-location-conveyance-13 (work in progress), 1490 March 2009. 1492 [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", 1493 Dec 2004. 1495 [LLDP-MED] 1496 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1497 Endpoint Discovery". 1499 [NENAi3TRD] 1500 NENA, "08-751 NENA i3 Technical Requirements for", 2006. 1502 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1503 A., Peterson, J., Sparks, R., Handley, M., and E. 1504 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1505 June 2002. 1507 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1508 with Session Description Protocol (SDP)", RFC 3264, 1509 June 2002. 1511 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1512 Extensions to the Session Initiation Protocol (SIP) for 1513 Asserted Identity within Trusted Networks", RFC 3325, 1514 November 2002. 1516 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1517 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1518 for Instant Messaging", RFC 3428, December 2002. 1520 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1521 Method", RFC 3515, April 2003. 1523 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1524 Jacobson, "RTP: A Transport Protocol for Real-Time 1525 Applications", STD 64, RFC 3550, July 2003. 1527 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1528 Video Conferences with Minimal Control", STD 65, RFC 3551, 1529 July 2003. 1531 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1532 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1534 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1535 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1536 RFC 3711, March 2004. 1538 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1539 Preferences for the Session Initiation Protocol (SIP)", 1540 RFC 3841, August 2004. 1542 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1543 Initiation Protocol (SIP)", RFC 3856, August 2004. 1545 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1546 Resource Identifier (URI): Generic Syntax", STD 66, 1547 RFC 3986, January 2005. 1549 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1550 Conversation", RFC 4103, June 2005. 1552 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1553 Format", RFC 4119, December 2005. 1555 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 1556 Supporting Emergency Telecommunications Service (ETS) in 1557 IP Telephony", RFC 4190, November 2005. 1559 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1560 Internet Protocol", RFC 4301, December 2005. 1562 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1563 Authenticated Identity Management in the Session 1564 Initiation Protocol (SIP)", RFC 4474, August 2006. 1566 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 1567 Device Requirements and Configuration", RFC 4504, 1568 May 2006. 1570 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1571 (DHCPv4 and DHCPv6) Option for Civic Addresses 1572 Configuration Information", RFC 4776, November 2006. 1574 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1575 Initiation Protocol Uniform Resource Identifier", 1576 RFC 4967, July 2007. 1578 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1579 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1581 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1582 Emergency Context Resolution with Internet Technologies", 1583 RFC 5012, January 2008. 1585 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1586 Emergency and Other Well-Known Services", RFC 5031, 1587 January 2008. 1589 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1590 Shanmugam, "Security Threats and Requirements for 1591 Emergency Call Marking and Mapping", RFC 5069, 1592 January 2008. 1594 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1595 "Transport Layer Security (TLS) Session Resumption without 1596 Server-Side State", RFC 5077, January 2008. 1598 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1599 Format for Presence Information Data Format Location 1600 Object (PIDF-LO)", RFC 5139, February 2008. 1602 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1603 Tschofenig, "LoST: A Location-to-Service Translation 1604 Protocol", RFC 5222, August 2008. 1606 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1607 Location-to-Service Translation (LoST) Servers Using the 1608 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1609 August 2008. 1611 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1612 K. Summers, "Session Initiation Protocol Service 1613 Examples", BCP 144, RFC 5359, October 2008. 1615 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1616 Presence Information Data Format Location Object (PIDF-LO) 1617 Usage Clarification, Considerations, and Recommendations", 1618 RFC 5491, March 2009. 1620 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 1621 Initiated Connections in the Session Initiation Protocol 1622 (SIP)", RFC 5626, October 2009. 1624 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1625 Agent URIs (GRUUs) in the Session Initiation Protocol 1626 (SIP)", RFC 5627, October 2009. 1628 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1629 Initiation Protocol (SIP)", RFC 5630, October 2009. 1631 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1632 Security (DTLS) Extension to Establish Keys for the Secure 1633 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1635 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1636 RFC 5985, September 2010. 1638 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1639 Location Information Server (LIS)", RFC 5986, 1640 September 2010. 1642 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 1643 Host Configuration Protocol Options for Coordinate-Based 1644 Location Configuration Information", RFC 6225, July 2011. 1646 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1647 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1648 Location and Location Privacy in Internet Applications", 1649 BCP 160, RFC 6280, July 2011. 1651 [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of 1652 Defense World Geodetic System 1984, Its Definition and 1653 Relationships With Local Geodetic Systems, Third Edition", 1654 July 1997. 1656 Authors' Addresses 1658 Brian Rosen 1659 NeuStar, Inc. 1660 470 Conrad Dr 1661 Mars, PA 16046 1662 USA 1664 Email: br@brianrosen.net 1666 Henning Schulzrinne 1667 Columbia University 1668 Department of Computer Science 1669 450 Computer Science Building 1670 New York, NY 10027 1671 USA 1673 Phone: +1 212 939 7042 1674 Email: hgs@cs.columbia.edu 1675 URI: http://www.cs.columbia.edu 1677 James Polk 1678 Cisco Systems 1679 3913 Treemont Circle 1680 Colleyville, Texas 76034 1681 USA 1683 Phone: +1-817-271-3552 1684 Email: jmpolk@cisco.com 1686 Andrew Newton 1687 TranTech/MediaSolv 1688 4900 Seminary Road 1689 Alexandria, VA 22311 1690 USA 1692 Phone: +1 703 845 0656 1693 Email: andy@hxr.us