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