idnits 2.17.00 (12 Aug 2021) /tmp/idnits50202/draft-ietf-ecrit-framework-12.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 (October 25, 2010) is 4225 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 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-geopriv-arch has been published as RFC 6280 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) -- 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 (~~), 11 warnings (==), 5 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: April 28, 2011 Columbia U. 6 J. Polk 7 Cisco Systems 8 A. Newton 9 TranTech/MediaSolv 10 October 25, 2010 12 Framework for Emergency Calling using Internet Multimedia 13 draft-ietf-ecrit-framework-12 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 April 28, 2011. 38 Copyright Notice 40 Copyright (c) 2010 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 in SIP . . . . . . . . . . . . . . . . 23 72 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 73 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24 74 6.10. Location validation . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 85 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31 86 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31 87 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 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 no international standards. However, the 228 Internet crosses national boundaries, and thus international 229 standards for equipment and software are required. To further 230 complicate matters, VoIP endpoints can be connected through tunneling 231 mechanisms such as virtual private networks (VPNs). Tunnels can 232 obscure the identity of the actual access network that knows the 233 location. This significantly complicates emergency calling, because 234 the location of the caller and the first element that routes 235 emergency calls can be on different continents, with different 236 conventions and processes for handling of emergency calls. 238 The IETF has historically refused to create 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. 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 must obtain his location (Section 6) 314 prior to making emergency calls. To get this location, either a form 315 of 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 [RFC3825] 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. As an aside, 759 normally, if an emergency caller insists that he is at a location 760 different from what any automatic location determination system 761 reports he is, responders will always be sent to the user's self- 762 declared location. However, this is a matter of local policy and is 763 outside the scope of this document. 765 6.2.2. Access network "wire database" location information 767 Location information can be maintained by the access network, 768 relating some form of identifier for the end subscriber or device to 769 a location database ("wire database"). In enterprise LANs, wiremap 770 databases map Ethernet switch ports to building locations. In DSL 771 installations, the local telephone carrier maintains a mapping of 772 wire-pairs to subscriber addresses. 774 Accuracy of location historically has been to a street address level. 775 However, this is not sufficient for larger structures. The PIDF 776 Location Object [RFC4119] extended by [RFC5139] and [RFC5491] permits 777 interior building/floor/room and even finer specification of location 778 within a street address. When possible, interior location should be 779 supported. 781 The threshold for when interior location is needed is approximately 782 650 square meters. This value is derived from USA fire brigade 783 recommendations of spacing of alarm pull stations. However, interior 784 space layout, construction materials and other factors should be 785 considered. 787 Even for IEEE 802.11 wireless access points, wire databases may 788 provide sufficient location resolution. The location of the access 789 point as determined by the wiremap may be supplied as the location 790 for each of the clients of the access point. However, this may not 791 be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE 792 802.22 that typically have larger cells than those of IEEE 802.11. 793 The civic location of an IEEE 802.16 base station may be of little 794 use to emergency personnel, since the endpoint could be several 795 kilometers away from the base station. 797 Wire databases are likely to be the most promising solution for 798 residential users where a service provider knows the customer's 799 service address. The service provider can then perform address 800 validation (see Section 6.10), similar to the current system in some 801 jurisdictions. 803 6.2.3. End-system measured location information 805 Global Positioning System (GPS) and similar Global Navigation 806 Satellite Systems (e.g., GLONAS and Galileo) receivers may be 807 embedded directly in the end device. GNSS produces relatively high 808 precision location fixes in open-sky conditions, but the technology 809 still faces several challenges in terms of performance (time-to-fix 810 and time-to-first-fix), as well as obtaining successful location 811 fixes within shielded structures, or underground. It also requires 812 all devices to be equipped with the appropriate GNSS capability. 814 Many mobile devices require using some kind of "assist", that may be 815 operated by the access network (A-GPS) or by a government (WAAS). A 816 device may be able to use multiple sources of assist data. 818 GNSS systems may be always enabled and thus location will always be 819 available accurately immediately (assuming the device can "see" 820 enough satellites). Mobile devices may not be able to sustain the 821 power levels required to keep the measuring system active. In such 822 circumstances, when location is needed, the device has to start up 823 the measurement mechanism. This typically takes tens of seconds, far 824 too long to wait to be able to route an emergency call. For this 825 reason, devices that have end-system measured location mechanisms but 826 need a cold start period lasting more than a couple seconds need 827 another way to get a routing location. Typically this would be a 828 location associated with a radio link (cell site/sector). 830 6.2.4. Network measured location information 832 The access network may locate end devices. Techniques include: 833 Wireless triangulation: Elements in the network infrastructure 834 triangulate end systems based on signal strength, angle of arrival 835 or time of arrival. Common mechanisms deployed include: 836 * Time Difference Of Arrival - TDOA 837 * Uplink Time Difference Of Arrival - U-TDOA 838 * Angle of Arrival - AOA 839 * RF fingerprinting 840 * Advanced Forward Link Trilateration - AFLT 841 * Enhanced Forward Link Trilateration - EFLT 842 Sometimes multiple mechanisms are combined, for example A-GPS with 843 AFLT. 844 Location beacons: A short range wireless beacon, e.g., using 845 Bluetooth or infrared, announces its location to mobile devices in 846 the vicinity. This allows devices to get location from the beacon 847 source's location. 849 6.3. Who adds location, endpoint or proxy 851 The IETF emergency call architecture prefers endpoints to learn their 852 location and supply it on the call. Where devices do not support 853 location, proxy servers may have to add location to emergency calls. 854 Some calling networks have relationships with all access networks the 855 device may be connected to, and that may allow the proxy to 856 accurately determine the location of the endpoint. However, NATs and 857 other middleboxes often make it impossible to determine a reference 858 identifier the access network could provide to a LIS to determine the 859 location of the device. Systems designers are discouraged from 860 relying on proxies to add location. The technique may be useful in 861 some limited circumstances as devices are upgraded to meet the 862 requirements of this document, or where relationships between access 863 networks and calling networks are feasible and can be relied upon to 864 get accurate location. 866 Proxy insertion of location complicates dial string recognition. As 867 noted in Section 6, local dial strings depend on the location of the 868 caller. If the device does not know its own location, it cannot use 869 the LoST service to learn the local emergency dial strings. The 870 calling network must provide another way for the device to learn the 871 local dial string, and update it when the user moves to a location 872 where the dial string(s) change, or do the dial string determination 873 itself. 875 6.4. Location and references to location 877 Location information may be expressed as the actual civic or 878 geospatial value but can be transmitted as by value (wholly contained 879 within the signaling message) or by reference (i.e., as a URI 880 pointing to the value residing on a remote node waiting to be 881 dereferenced). 883 When location is transmitted by value, the location information is 884 available to entity in the call path. On the other hand, location 885 objects can be large, and only represent a single snapshot of the 886 device's location. Location references are small and can be used to 887 represent a time-varying location, but the added complexity of the 888 dereference step introduces a risk that location will not be 889 available to parties that need it. 891 6.5. End system location configuration 893 Unless a user agent has access to provisioned or locally measured 894 location information, it must obtain it from the access network. 895 There are several location configuration protocols (LCPs) that can be 896 used for this purpose including DHCP, HELD and LLDP: 897 DHCP can deliver civic [RFC4776] or geospatial [RFC3825] 898 information. User agents need to support both formats. Note that 899 a user agent can use DHCP, via the DHCP REQUEST or INFORM 900 messages, even if it uses other means to acquire its IP address. 901 HELD [RFC5985] can deliver a civic or geo location object, by value 902 or by reference, via a layer 7 protocol. The query typically uses 903 the IP address of the requester as an identifier and returns the 904 location value or reference associated with that identifier. HELD 905 is typically carried in HTTP. 907 Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device 908 extensions [LLDP-MED] can be used to deliver location information 909 directly from the Layer 2 network infrastructure, and also 910 supports both civic and geo formats identical in format to DHCP 911 methods. 913 Each LCP has limitations in the kinds of networks that can reasonably 914 support it. For this reason, it is not possible to choose a single 915 mandatory-to-deploy LCP. For endpoints with common network 916 connections (such as an Ethernet jack or a WiFi connection) serious 917 incompatibilities would ensue unless every network supported every 918 protocol, or alternatively, every device supported every protocol. 919 For this reason, a mandatory-to-implement list of LCPs is established 920 in [I-D.ietf-ecrit-phonebcp]. Every endpoint that could be used to 921 place emergency calls must implement all of the protocols on the 922 list. Every access network must deploy at least one of them. Since 923 it is the variability of the networks that prevent a single protocol 924 from being acceptable, it must be the endpoints that implement all of 925 them, and to accommodate a wide range of devices, networks must 926 deploy at least one of them. 928 Often, network operators and device designers believe that they have 929 a simpler environment and some other network specific mechanism can 930 be used to provide location. Unfortunately, it is very rare to 931 actually be able to limit the range of devices that may be connected 932 to a network. For example, existing mobile networks are being used 933 to support routers and LANs behind a wireless data network WAN 934 connection, with Ethernet connected phones connected to that. It is 935 possible that the access network could support a protocol not on the 936 list, and require every handset in that network to use that protocol 937 for emergency calls. However, the Ethernet-connected phone won't be 938 able to acquire location, and the user of the phone is unlikely to be 939 dissuaded from placing an emergency call on that phone. The 940 widespread availability of gateways, routers and other network- 941 broadening devices means that indirectly connected endpoints are 942 possible on nearly every network. Network operators and vendors are 943 cautioned that shortcuts to meeting this requirement are seldom 944 successful. 946 Location for non-mobile devices is normally expected to be acquired 947 at network attachment time and retained by the device. It should be 948 refreshed when the cached value expires. For example, if DHCP is the 949 acquisition protocol, refresh of location may occur when the IP 950 address lease is renewed. At the time of an emergency call, the 951 location should be refreshed, with the retained location used if the 952 location acquisition does not immediately return a value. Mobile 953 devices may determine location at network attachment time and 954 periodically thereafter as a backup in case location determination at 955 the time of call does not work. Mobile device location may be 956 refreshed when a TTL expires or the device moves beyond some 957 boundaries (as provided by [RFC5222]). Normally, mobile devices will 958 acquire its location at call time for use in an emergency call 959 routing. See Section 6.8 for a further discussion on location 960 updates for dispatch location. 962 There are many examples of endpoints which are user agent 963 applications running on a more general purpose device, such as a 964 personal computer. On some systems, layer 2 protocols like DHCP and 965 LLDP may not be directly accessible to applications. It is desirable 966 for an operating system to have an API which provides the location of 967 the device for use by any application, especially those supporting 968 emergency calls. 970 6.6. When location should be configured 972 Devices should get routing location immediately after obtaining local 973 network configuration information. The presence of NAT and VPN 974 tunnels (that assign new IP addresses to communications) can obscure 975 identifiers used by LCPs to determine location, especially for HELD. 976 In some cases, such as residential NAT devices, the NAT is placed 977 between the endpoint and the access network demarcation point and 978 thus the IP address seen by the access network is the right 979 identifier for location of the residence. However, in many 980 enterprise environments, VPN tunnels can obscure the actual IP 981 address. Some VPN mechanisms can be bypassed so that a query to the 982 LCP can be designated to go through the direct IP path, using the 983 correct IP address, and not through the tunnel. In other cases, no 984 bypass is possible. Of course, LCPs that use layer 2 mechanisms 985 (DHCP Location options and LLDP-MED) are usually immune from such 986 problems because they do not use the IP address as the identifier for 987 the device seeking location. 989 It is desirable that routing location information be periodically 990 refreshed. A LIS supporting a million subscribers each refreshing 991 once per day would need to support a query rate of 1,000,000 / (24 * 992 60 * 60) = 12 queries per second. 994 It is desirable for routing location information to be requested 995 immediately before placing an emergency call. However, if there is 996 any significant delay in getting more recent location, the call 997 should be placed with the most recent location information the device 998 has. In mobile handsets, routing is often accomplished with the cell 999 site and sector of the tower serving the call, because it can take 1000 many seconds to start up the location determination mechanism and 1001 obtain an accurate location. 1003 There is a tradeoff between the time it takes to get a routing 1004 location and the accuracy (technically, confidence and uncertainty) 1005 obtained. Routing an emergency call quickly is required. However, 1006 if location can be substantially improved by waiting a short time 1007 (e.g., for some sort of "quick fix"), it's preferable to wait. Three 1008 seconds, the current nominal time for a quick fix, is a very long 1009 time add to post dial delay. 1011 NENA recommends [NENAi3TRD] that IP based systems complete calls in 1012 two seconds from last dial press to ring at PSAP. 1014 6.7. Conveying location in SIP 1016 When an emergency call is placed, the endpoint should include 1017 location in the call signaling. This is referred to as "conveyance" 1018 to distinguish it from "configuration". In SIP, the location 1019 information is conveyed following the procedures in 1020 [I-D.ietf-sip-location-conveyance]. Since the form of the location 1021 information obtained by the acquisition protocol may not be the same 1022 as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the 1023 endpoint from the LCP form to PIDF may be required. 1025 6.8. Location updates 1027 As discussed above, it may take some time for some measurement 1028 mechanisms to get a location accurate enough for dispatch, and a 1029 routing location with less accuracy may be provided to get the call 1030 established quickly. The PSAP needs the dispatch location before it 1031 sends the call to the responder. This requires an update of the 1032 location. In addition, the location of some mobile callers, e.g., in 1033 a vehicle or aircraft, can change significantly during the emergency 1034 call. 1036 A PSAP has no way to request an update of a location provided by 1037 value. If the UAC gets new location, it must signal the PSAP using a 1038 new INVITE or an UPDATE transaction with a new Geolocation header to 1039 supply the new location. 1041 With the wide variation in determination mechanisms, the PSAP does 1042 not know when accurate location may be available. The preferred 1043 mechanism is that the LIS notifies the PSAP when an accurate location 1044 is available rather than requiring a poll operation from the PSAP to 1045 the LIS. The SIP Presence subscription [RFC3856] provides a suitable 1046 mechanism. 1048 When using a HELD dereference, the PSAP must specify the value 1049 "emergencyDispatch" for the ResponseTime parameter. Since typically 1050 the LIS is local relative to the PSAP, the LIS can be aware of the 1051 update requirements of the PSAP 1053 6.9. Multiple locations 1055 Getting multiple locations all purported to describe the location of 1056 the caller is confusing to all, and should be avoided. Handling 1057 multiple locations at the point where a PIDF is created is discussed 1058 in [RFC5491]. Conflicting location information is particularly 1059 harmful if different routes (PSAPs) result from LoST queries for the 1060 multiple locations. When they occur anyway, the general guidance is 1061 that the entity earliest in the chain generally has more knowledge 1062 than later elements to make an intelligent decision, especially about 1063 which location will be used for routing. It is permissible to send 1064 multiple locations towards the PSAP, but the element that chooses the 1065 route must select exactly one location to use with LoST. 1067 Guidelines for dealing with multiple locations are also given in 1068 [RFC5222]. If a UA gets multiple locations, it must choose the one 1069 to use for routing, but it may send all of the locations it has in 1070 the signaling. If a proxy is inserting location and has multiple 1071 locations, it must choose exactly one to use for routing, marking it 1072 as such (per [I-D.ietf-sip-location-conveyance], and send it as well 1073 as any others it has. 1075 The UA or proxy should have the ability to understand how and from 1076 whom it learned its location, and should include this information in 1077 the location objects that are sent to the PSAP. That labeling 1078 provides the call-taker with information to make decisions upon, as 1079 well as guidance for what to ask the caller and what to tell the 1080 responders. 1082 Endpoints or proxies may be tempted to send multiple versions of the 1083 same location. For example a database may be used to "geocode" or 1084 "reverse geocode", that is, convert from civic to geo or vice versa. 1085 It is very problematic to use derived locations in emergency calls. 1086 The PSAP and the responders have very accurate databases which they 1087 use to convert, most commonly from a reported geo to a civic suitable 1088 for dispatching responders. If one database is used to convert from, 1089 say, civic to geo, and another converts from geo to civic, errors 1090 will often occur where the databases are slightly different. "Off by 1091 one" errors are serious when responders go to the wrong location. 1092 Derived locations should be marked with a "derived" method token 1093 [RFC4119]. If an entity gets a location which has a measured or 1094 other original method, and another with a derived method, it must use 1095 the original value for the emergency call. 1097 6.10. Location validation 1099 Validation in this context means both that there is a mapping from 1100 the address to a PSAP and that the PSAP understands how to direct 1101 responders to the location. It is recommended that location be 1102 validated prior to a device placing an actual emergency call; some 1103 jurisdictions require that this be done. 1105 Determining the addresses that are valid can be difficult. There 1106 are, for example, many cases of two names for the same street, or two 1107 streets with the same name, but different "suffixes" (Avenue, Street, 1108 Circle) in a city. In some countries, the current system provides 1109 validation. For example, in the United States of America, the Master 1110 Street Address Guide (MSAG) records all valid street addresses and is 1111 used to ensure that the service addresses in phone billing records 1112 correspond to valid emergency service street addresses. Validation 1113 is normally only a concern for civic addresses, although there could 1114 be some determination that a given geo is within at least one PSAP 1115 service boundary; that is, a "valid" geo is one where there is a 1116 mapping in the LoST server. 1118 LoST [RFC5222] includes a location validation function. Validation 1119 is normally performed when a location is entered into a Location 1120 Information Server. It should be confirmed periodically, because the 1121 mapping database undergoes slow change and locations which previously 1122 validated may eventually fail validation. Endpoints may wish to 1123 validate locations they receive from the access network, and will 1124 need to validate manually entered locations. Proxies that insert 1125 location may wish to validate locations they receive from a LIS. 1126 When the test functions (Section 15) are invoked, the location used 1127 should be validated. 1129 When validation fails, the location given must not be used for an 1130 emergency call. If validation is completed when location is first 1131 loaded into a LIS, any problems can be found and fixed before devices 1132 could get the bad location. Failure of validation arises because an 1133 error is made in determining the location, although occasionally the 1134 LoST database is not up to date or has faulty information. In either 1135 case, the problem must be identified and corrected before using the 1136 location. 1138 6.11. Default location 1140 Occasionally, the access network cannot determine the actual location 1141 of the caller. In these cases, it must supply a default location. 1142 The default location should be as accurate as the network can 1143 determine. For example, in a cable network, a default location for 1144 each Cable Modem Termination System (CMTS), with a representative 1145 location for all cable modems served by that CMTS could be provided 1146 if the network is unable to resolve the subscriber to anything more 1147 precise than the CMTS. Default locations must be marked as such so 1148 that the PSAP knows that the location is not accurate. 1150 6.12. Location format conversion 1152 The endpoint is responsible for mapping any form of location it 1153 receives from an LCP into PIDF-LO form if the LCP did not directly 1154 return a PIDF-LO. 1156 7. LIS and LoST discovery 1158 Endpoints must be able to discover a LIS if the HELD protocol is 1159 used, and a LoST server. DHCP options are defined for this purpose, 1160 namely [RFC5986] and [RFC5223]. 1162 Until such DHCP records are widely available, it may be necessary for 1163 the service provider to provision a LoST server address in the 1164 device. The endpoint can also do a DNS SRV query to find a LoST 1165 server. In any environment, more than one of these mechanisms may 1166 yield a LoST server, and they may be different. The recommended 1167 priority is DHCP first, provisioned value second, and DNS SRV query 1168 in the SIP domain third. 1170 8. Routing the call to the PSAP 1172 Emergency calls are routed based on one or more of the following 1173 criteria expressed in the call setup request (INVITE): 1174 Location: Since each PSAP serves a limited geographic region and 1175 transferring existing calls delays the emergency response, calls 1176 need to be routed to the most appropriate PSAP. In this 1177 architecture, emergency call setup requests contain location 1178 information, expressed in civic or geospatial coordinates, that 1179 allows such routing. 1180 Type of emergency service: In some jurisdictions, emergency calls 1181 for specific emergency services such as fire, police, ambulance or 1182 mountain rescue are directed to just those emergency-specific 1183 PSAPs. This mechanism is supported by marking emergency calls 1184 with the proper service identifier [RFC5031]. Even in single 1185 number jurisdictions, not all services are dispatched by PSAPs and 1186 may need alternate URNs to route calls to the appropriate call 1187 center. 1189 Media capabilities of caller: In some cases, emergency call centers 1190 for specific caller media preferences, such as typed text or 1191 video, are separate from PSAPs serving voice calls. ESRPs are 1192 expected to be able to provide routing based on media. Also, even 1193 if media capability does not affect the selection of the PSAP, 1194 there may be call takers within the PSAP that are specifically 1195 trained, e.g., in interactive text or sign language 1196 communications, where routing within the PSAP based on the media 1197 offer would be provided. 1199 Providing a URL to route emergency calls by location and by type of 1200 service is the primary function LoST [RFC5222] provides. LoST 1201 accepts a query with location (by-value) in either civic or geo form, 1202 plus a service identifier, and returns a URI (or set of URIs) to 1203 route the call to. Normal SIP [RFC3261] routing functions are used 1204 to resolve the URI to a next hop destination. 1206 The endpoint can complete the LoST mapping from its location at boot 1207 time, and periodically thereafter. It should attempt to obtain a 1208 "fresh" location, and from that a current mapping when it places an 1209 emergency call. If accessing either its location acquisition or 1210 mapping functions fail, it should use its cached value. The call 1211 would follow its normal outbound call processing. 1213 Determining when the device leaves the area provided by the LoST 1214 service can tax small mobile devices. For this reason, the LoST 1215 server should return a simple (small number of points) polygon for 1216 geospatial location. This can be a simple enclosing rectangle of the 1217 PSAP service area when the reported point is not near an edge, or a 1218 smaller polygonal edge section when the reported location is near an 1219 edge. Civic location is uncommon for mobile devices, but reporting 1220 that the same mapping is good within a community name, or even a 1221 street, may be very helpful for WiFi connected devices that roam and 1222 obtain civic location from the access point they are connected to. 1224 Networks that support devices that do not implement LoST mapping 1225 themselves may need the outbound proxy do the mapping. If the 1226 endpoint recognized the call was an emergency call, provided the 1227 correct service URN and/or included location on the call in a 1228 Geolocation header, a proxy server could easily accomplish the 1229 mapping. 1231 However, if the endpoint did not recognize the call was an emergency 1232 call, and thus did not include location, the proxy's task is more 1233 difficult. It is often difficult for the calling network to 1234 accurately determine the endpoint's location. The endpoint may have 1235 its own location, but would not normally include it on the call 1236 signaling unless it knew it was an emergency call. There is no 1237 mechanism provided in [I-D.ietf-sip-location-conveyance] for a proxy 1238 to request the endpoint supply its location, because that would open 1239 the endpoint to an attack by any proxy on the path to get it to 1240 reveal location. The proxy can attempt to redirect a call to the 1241 service URN which, if the device recognizes the significance, would 1242 include location in the redirected call from the device. All 1243 networks elements should detect emergency calls and supply default 1244 location and/or routing if it is not already present. 1246 The LoST server would normally be provided by the local emergency 1247 authorities, although the access network or calling network might run 1248 its own server using data provided by the emergency authorities. 1249 Some enterprises may have local responders and call centers, and 1250 could operate their own LoST server, providing URIs to in-house 1251 "PSAPs". Local regulations might limit the ability of enterprises to 1252 direct emergency calls to in-house services. 1254 The ESRP, which is a normal SIP proxy server in the signaling path of 1255 the call, may use a variety of PSAP state information, the location 1256 of the caller, and other criteria to onward route the call to the 1257 PSAP. In order for the ESRP to route on media choice, the initial 1258 INVITE request has to supply an SDP offer. 1260 9. Signaling of emergency calls 1262 9.1. Use of TLS 1264 Best Current Practice for SIP user agents [RFC4504] including 1265 handling of audio, video and real-time text [RFC4103] should be 1266 applied. As discussed above, location is carried in all emergency 1267 calls in the call signaling. Since emergency calls carry privacy- 1268 sensitive information, they are subject to the requirements for 1269 geospatial protocols [RFC3693]. In particular, signaling information 1270 should be carried in TLS, i.e., in 'sips' mode with a ciphersuite 1271 which includes strong encryption (e.g., AES). There are exceptions 1272 in [RFC3693] for emergency calls. For example, local policy may 1273 dictate that location is sent with an emergency call even if the 1274 user's policy would otherwise prohibit that. Nevertheless, 1275 protection from eavesdropping of location by encryption should be 1276 provided. 1278 It is unacceptable to have an emergency call fail to complete because 1279 a TLS connection was not created for any reason. Thus, the call 1280 should be attempted with TLS, but if the TLS session establishment 1281 fails, the call should be automatically retried without TLS. 1282 [RFC5630] recommends that to achieve this effect the target specifies 1283 a sip URI, but use TLS on the outbound connection. An element that 1284 receives a request over a TLS connection should attempt to create a 1285 TLS connection to the next hop. 1287 In many cases, persistent TLS connections can be maintained between 1288 elements to minimize the time needed to establish them [RFC5626]. In 1289 other circumstances, use of session resumption [RFC5077] is 1290 recommended. IPsec [RFC4301] is an acceptable alternative to TLS 1291 when used with an equivalent crypto suite. 1293 Location may be used for routing by multiple proxy servers on the 1294 path. Confidentiality mechanisms such as S/MIME encryption of SIP 1295 signaling [RFC3261] cannot be used because they obscure location. 1296 Only hop-by-hop mechanisms such as TLS should be used. Implementing 1297 location conveyance in SIP mandates inclusion of TLS support. 1299 9.2. SIP signaling requirements for User Agents 1301 SIP UAs that recognize local dial strings, insert location, and 1302 perform emergency call routing will create SIP INVITE messages with 1303 the Service URN in the Request URI, the LoST-determined URI for the 1304 PSAP in a Route header, and the location in a Geolocation header. 1305 The INVITE request must also have appropriate call back identifiers 1306 (in Contact and From headers). To enable media sensitive routing, 1307 the call should include an SDP offer. 1309 SIP caller preferences [RFC3841] can be used to signal how the PSAP 1310 should handle the call. For example, a language preference expressed 1311 in an Accept-Language header may be used as a hint to cause the PSAP 1312 to route the call to a call taker who speaks the requested language. 1313 SIP caller preferences may also be used to indicate a need to invoke 1314 a relay service for communication with people with disabilities in 1315 the call. 1317 9.3. SIP signaling requirements for proxy servers 1319 At least one SIP proxy server in the path of an emergency call must 1320 be able to assist UAs that are unable to provide any of the location 1321 based routing steps and recognition of dial strings. A Proxy can 1322 recognize the lack of location awareness by the lack of a Geolocation 1323 header. They can recognize the lack of dial string recognition by 1324 the presence of the local emergency call dial string in the From 1325 header without the service URN being present. They should obtain the 1326 location of the endpoint if possible, and use a default location if 1327 they can not, inserting it in a Geolocation header. They should 1328 query LoST with the location and put the resulting URI in a Route, 1329 with the appropriate service URN in the Request URI. In any event, 1330 they are also expected to provide information for the caller using 1331 SIP Identity or P-Asserted-Identity. It is often a regulatory matter 1332 whether calls normally marked as anonymous are passed as anonymous 1333 when they are emergency calls. Proxies must conform to the local 1334 regulation or practice. 1336 10. Call backs 1338 The call-taker must be able to reach the emergency caller if the 1339 original call is disconnected. In traditional emergency calls, 1340 wireline and wireless emergency calls include a callback identifier 1341 for this purpose. There are two kinds of call backs. When a call is 1342 dropped, or the call taker realizes that some important information 1343 is needed that it doesn't have, it must call back the device that 1344 placed the emergency call. The PSAP, or a responder, may need to 1345 call back the caller much later, and for that purpose, it wants a 1346 normal SIP Address of Record. In SIP systems, the caller must 1347 include a Contact header field in an emergency call containing a 1348 globally routable URI, possibly a GRUU [RFC5627]. This identifier 1349 would be used to initiate call-backs immediately by the call-taker 1350 if, for example, the call is prematurely dropped. A concern arises 1351 with B2BUAs that manipulate Contact headers. Such B2BUAs should 1352 always include a Contact header that routes to the same device. 1354 In addition, a call-back identifier as an Address of Record (AoR) 1355 must be included either as the URI in the From header field [RFC3261] 1356 verified by SIP Identity [RFC4474] or as a network asserted URI 1357 [RFC3325]. If the latter, the PSAP will need to establish a suitable 1358 spec(t) with the proxies that send it emergency calls. This 1359 identifier would be used to initiate a call-back at a later time and 1360 may reach the caller, not necessarily on the same device (and at the 1361 same location) as the original emergency call as per normal SIP 1362 rules. It is often a regulatory matter whether calls normally marked 1363 as anonymous are passed as anonymous when they are emergency calls. 1364 Proxies must conform to the local regulation or practice. 1366 11. Mid-call behavior 1368 Some PSAPs often include dispatchers, responders or specialists on a 1369 call. Some responder's dispatchers are not located in the primary 1370 PSAP, the call may have to be transferred to another PSAP. Most 1371 often this will be an attended transfer, or a bridged transfer. 1372 Therefore a PSAP may need to a REFER request [RFC3515] a call to a 1373 bridge for conferencing. Devices which normally involve the user in 1374 transfer operations should consider the effect of such interactions 1375 when a stressed user places an emergency call. Requiring UI 1376 manipulation during such events may not be desirable. Relay services 1377 for communication with people with disabilities may be included in 1378 the call with the bridge. The UA should be prepared to have the call 1379 transferred (usually attended, but possibly blind) per [RFC5359]. 1381 12. Call termination 1383 It is undesirable for the caller to terminate an emergency call. 1384 PSAP terminates a call using the normal SIP call termination 1385 procedures, i.e., with a BYE request. 1387 13. Disabling of features 1389 Certain features that can be invoked while a normal call is active 1390 are not permitted when the call is an emergency call. Services such 1391 as call waiting, call transfer, three way call and hold should be 1392 disabled. 1394 Certain features such as call forwarding can interfere with calls 1395 from a PSAP and should be disabled. There is no way to reliably 1396 determine a PSAP call back. A UA may be able to determine a PSAP 1397 call back by examining the domain of incoming calls after placing an 1398 emergency call and comparing that to the domain of the answering PSAP 1399 from the emergency call. Any call from the same domain and directed 1400 to the supplied Contact header or AoR after an emergency call should 1401 be accepted as a call-back from the PSAP if it occurs within a 1402 reasonable time after an emergency call was placed. 1404 14. Media 1406 PSAPs should always accept RTP media streams [RFC3550]. 1407 Traditionally, voice has been the only media stream accepted by 1408 PSAPs. In some countries, text, in the form of Baudot codes or 1409 similar tone encoded signaling within a voiceband is accepted ("TTY") 1410 for persons who have hearing disabilities. Using SIP signaling 1411 includes the capability to negotiate media. Normal SIP offer/answer 1412 [RFC3264] negotiations should be used to agree on the media streams 1413 to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs 1414 should accept G.711 A-law (and mu-law in North America) encoded voice 1415 as described in [RFC3551]. Newer text forms are rapidly appearing, 1416 with instant messaging now very common, PSAPs should accept IM with 1417 at least "pager-mode" MESSAGE request [RFC3428] as well as Message 1418 Session Relay Protocol [RFC4975]. Video may be important to support 1419 Video Relay Service (sign language interpretation) as well as modern 1420 video phones. 1422 It is desirable for media to be kept secure by the use of Secure RTP 1424 [RFC3711], using DTLS [RFC5764] for keying. 1426 15. Testing 1428 Since the emergency calling architecture consists of a number of 1429 pieces operated by independent entities, it is important to be able 1430 to test whether an emergency call is likely to succeed without 1431 actually occupying the human resources at a PSAP. Both signaling and 1432 media paths need to be tested since NATs and firewalls may allow the 1433 session setup request to reach the PSAP, while preventing the 1434 exchange of media. 1436 [I-D.ietf-ecrit-phonebcp]includes a description of an automated test 1437 procedure that validates routing, signaling and media path 1438 continuity. This test would be used within some random interval 1439 after boot time, and whenever the device location changes enough that 1440 a new PSAP mapping is returned by the LoST server. 1442 The PSAP needs to be able to control frequency and duration of the 1443 test, and since the process could be abused, it may temporarily or 1444 permanently suspend its operation. 1446 There is a concern associated with testing during a so-called 1447 "avalanche-restart" event where, for example a large power outage 1448 affects a large number of endpoints, that, when power is restored, 1449 all attempt to reboot and, possibly, test. Devices need to randomize 1450 their initiation of a boot time test to avoid the problem. 1452 16. Security Considerations 1454 Security considerations for emergency calling have been documented in 1455 [RFC5069] and [I-D.ietf-geopriv-arch]. 1457 17. IANA Considerations 1459 This document has no actions for IANA. 1461 18. Acknowledgments 1463 This draft was created from a 1464 draft-schulzrinne-sipping-emergency-arch-02 together with sections 1465 from draft-polk-newton-ecrit-arch-considerations-02. 1467 Design Team members participating in this draft creation include 1468 Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, 1469 Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments 1470 and input were provided by Richard Barnes, Barbara Stark and James 1471 Winterbottom. 1473 19. Informative References 1475 [I-D.ietf-ecrit-phonebcp] 1476 Rosen, B. and J. Polk, "Best Current Practice for 1477 Communications Services in support of Emergency Calling", 1478 draft-ietf-ecrit-phonebcp-15 (work in progress), 1479 July 2010. 1481 [I-D.ietf-geopriv-arch] 1482 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1483 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1484 Location and Location Privacy in Internet Applications", 1485 draft-ietf-geopriv-arch-03 (work in progress), 1486 October 2010. 1488 [I-D.ietf-sip-location-conveyance] 1489 Polk, J. and B. Rosen, "Location Conveyance for the 1490 Session Initiation Protocol", 1491 draft-ietf-sip-location-conveyance-13 (work in progress), 1492 March 2009. 1494 [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", 1495 Dec 2004. 1497 [LLDP-MED] 1498 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1499 Endpoint Discovery". 1501 [NENAi3TRD] 1502 NENA, "08-751 NENA i3 Technical Requirements for", 2006. 1504 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1505 A., Peterson, J., Sparks, R., Handley, M., and E. 1506 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1507 June 2002. 1509 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1510 with Session Description Protocol (SDP)", RFC 3264, 1511 June 2002. 1513 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1514 Extensions to the Session Initiation Protocol (SIP) for 1515 Asserted Identity within Trusted Networks", RFC 3325, 1516 November 2002. 1518 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1519 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1520 for Instant Messaging", RFC 3428, December 2002. 1522 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1523 Method", RFC 3515, April 2003. 1525 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1526 Jacobson, "RTP: A Transport Protocol for Real-Time 1527 Applications", STD 64, RFC 3550, July 2003. 1529 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1530 Video Conferences with Minimal Control", STD 65, RFC 3551, 1531 July 2003. 1533 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1534 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1536 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1537 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1538 RFC 3711, March 2004. 1540 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1541 Configuration Protocol Option for Coordinate-based 1542 Location Configuration Information", RFC 3825, July 2004. 1544 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1545 Preferences for the Session Initiation Protocol (SIP)", 1546 RFC 3841, August 2004. 1548 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1549 Initiation Protocol (SIP)", RFC 3856, August 2004. 1551 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1552 Resource Identifier (URI): Generic Syntax", STD 66, 1553 RFC 3986, January 2005. 1555 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1556 Conversation", RFC 4103, June 2005. 1558 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1559 Format", RFC 4119, December 2005. 1561 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 1562 Supporting Emergency Telecommunications Service (ETS) in 1563 IP Telephony", RFC 4190, November 2005. 1565 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1566 Internet Protocol", RFC 4301, December 2005. 1568 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1569 Authenticated Identity Management in the Session 1570 Initiation Protocol (SIP)", RFC 4474, August 2006. 1572 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 1573 Device Requirements and Configuration", RFC 4504, 1574 May 2006. 1576 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1577 (DHCPv4 and DHCPv6) Option for Civic Addresses 1578 Configuration Information", RFC 4776, November 2006. 1580 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1581 Initiation Protocol Uniform Resource Identifier", 1582 RFC 4967, July 2007. 1584 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1585 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1587 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1588 Emergency Context Resolution with Internet Technologies", 1589 RFC 5012, January 2008. 1591 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1592 Emergency and Other Well-Known Services", RFC 5031, 1593 January 2008. 1595 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1596 Shanmugam, "Security Threats and Requirements for 1597 Emergency Call Marking and Mapping", RFC 5069, 1598 January 2008. 1600 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1601 "Transport Layer Security (TLS) Session Resumption without 1602 Server-Side State", RFC 5077, January 2008. 1604 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1605 Format for Presence Information Data Format Location 1606 Object (PIDF-LO)", RFC 5139, February 2008. 1608 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1609 Tschofenig, "LoST: A Location-to-Service Translation 1610 Protocol", RFC 5222, August 2008. 1612 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1613 Location-to-Service Translation (LoST) Servers Using the 1614 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1615 August 2008. 1617 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1618 K. Summers, "Session Initiation Protocol Service 1619 Examples", BCP 144, RFC 5359, October 2008. 1621 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1622 Presence Information Data Format Location Object (PIDF-LO) 1623 Usage Clarification, Considerations, and Recommendations", 1624 RFC 5491, March 2009. 1626 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 1627 Initiated Connections in the Session Initiation Protocol 1628 (SIP)", RFC 5626, October 2009. 1630 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1631 Agent URIs (GRUUs) in the Session Initiation Protocol 1632 (SIP)", RFC 5627, October 2009. 1634 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1635 Initiation Protocol (SIP)", RFC 5630, October 2009. 1637 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1638 Security (DTLS) Extension to Establish Keys for the Secure 1639 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1641 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1642 RFC 5985, September 2010. 1644 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1645 Location Information Server (LIS)", RFC 5986, 1646 September 2010. 1648 [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of 1649 Defense World Geodetic System 1984, Its Definition and 1650 Relationships With Local Geodetic Systems, Third Edition", 1651 July 1997. 1653 Authors' Addresses 1655 Brian Rosen 1656 NeuStar, Inc. 1657 470 Conrad Dr 1658 Mars, PA 16046 1659 USA 1661 Email: br@brianrosen.net 1663 Henning Schulzrinne 1664 Columbia University 1665 Department of Computer Science 1666 450 Computer Science Building 1667 New York, NY 10027 1668 USA 1670 Phone: +1 212 939 7042 1671 Email: hgs@cs.columbia.edu 1672 URI: http://www.cs.columbia.edu 1674 James Polk 1675 Cisco Systems 1676 3913 Treemont Circle 1677 Colleyville, Texas 76034 1678 USA 1680 Phone: +1-817-271-3552 1681 Email: jmpolk@cisco.com 1683 Andrew Newton 1684 TranTech/MediaSolv 1685 4900 Seminary Road 1686 Alexandria, VA 22311 1687 USA 1689 Phone: +1 703 845 0656 1690 Email: andy@hxr.us