idnits 2.17.00 (12 Aug 2021) /tmp/idnits60851/draft-ietf-ecrit-phonebcp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (January 19, 2010) is 4504 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-geopriv-lis-discovery has been published as RFC 5986 == Outdated reference: draft-ietf-mmusic-media-loopback has been published as RFC 6849 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Obsolete normative reference: RFC 3984 (Obsoleted by RFC 6184) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: draft-ietf-geopriv-arch has been published as RFC 6280 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 6 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: BCP J. Polk 5 Expires: July 23, 2010 Cisco Systems 6 January 19, 2010 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-14 12 Abstract 14 The IETF and other standards organization have efforts targeted at 15 standardizing various aspects of placing emergency calls on IP 16 networks. This memo describes best current practice on how devices, 17 networks and services should use such standards to make emergency 18 calls. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on July 23, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview of how emergency calls are placed . . . . . . . . . . 4 63 4. Which devices and services should support emergency calls . . 5 64 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 65 6. Location and its role in an emergency call . . . . . . . . . . 6 66 6.1. Types of location information . . . . . . . . . . . . . . 6 67 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 68 6.2.1. User-entered location information . . . . . . . . . . 7 69 6.2.2. Access network "wire database" location information . 7 70 6.2.3. End-system measured location information . . . . . . . 7 71 6.2.4. Network-measured location information . . . . . . . . 8 72 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 73 6.4. Location and references to location . . . . . . . . . . . 8 74 6.5. End system location configuration . . . . . . . . . . . . 9 75 6.6. When location should be configured . . . . . . . . . . . . 10 76 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11 77 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 78 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 79 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 80 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 81 6.12. Other location considerations . . . . . . . . . . . . . . 13 82 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 83 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 84 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 85 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.2. SIP signaling requirements for User Agents . . . . . . . . 15 87 9.3. SIP signaling requirements for proxy servers . . . . . . . 17 88 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 90 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 91 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 92 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 95 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 97 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 99 19.2. Informative References . . . . . . . . . . . . . . . . . . 24 100 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25 101 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25 102 A.2. Requirements of Service Providers . . . . . . . . . . . . 35 103 A.3. Requirements of Access Network . . . . . . . . . . . . . . 39 104 A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 107 1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 This document uses terms from [RFC3261], [RFC5012] and 114 [I-D.ietf-ecrit-framework]. 116 2. Introduction 118 This document describes how access networks, SIP user agents, proxy 119 servers and PSAPs support emergency calling, as outlined in 120 [I-D.ietf-ecrit-framework], which is designed to complement the 121 present document in section headings, numbering and content. This 122 BCP succinctly describes the requirements of end devices and 123 applications (requirements prefaced by "ED-"), access networks 124 (including enterprise access networks) (requirements prefaced by 125 "AN-", service providers (requirements prefaced by "SP-") and PSAPs 126 to achieve globally interoperable emergency calling on the Internet. 128 This document also defines requirements for "Intermediate" devices 129 which exist between end devices or applications and the access 130 network. For example, a home router is an "Intermediate" device. 131 Reporting location on an emergency call (see Section 6) may depend on 132 the ability of such intermediate devices to meet the requirements 133 prefaced by "INT-". 135 3. Overview of how emergency calls are placed 137 An emergency call can be distinguished (Section 5) from any other 138 call by a unique Service URN [RFC5031], which is placed in the call 139 set-up signaling when a home or visited emergency dial string is 140 detected. Because emergency services are local to specific 141 geographic regions, a caller must obtain his location (Section 6) 142 prior to making emergency calls. To get this location, either a form 143 of measuring (e.g., GPS) (Section 6.2.3) device location in the 144 endpoint is deployed, or the endpoint is configured (Section 6.5) 145 with its location from the access network's Location Information 146 Server (LIS). The location is conveyed (Section 6.7) in the SIP 147 signaling with the call. The call is routed (Section 8) based on 148 location using the LoST protocol [RFC5222], which maps a location to 149 a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency 150 Services Routing Proxy (ESRP), which serves a group of PSAPs. The 151 call arrives at the PSAP with the location included in the SIP INVITE 152 request. 154 4. Which devices and services should support emergency calls 156 ED-1 A device or application SHOULD support emergency calling if a 157 user could reasonably expect to be able to place a call for help with 158 the device. Some jurisdictions have regulations governing this. 160 SP-1 If a device or application expects to be able to place a call 161 for help, the service provider that supports it MUST facilitate 162 emergency calling. Some jurisdictions have regulations governing 163 this. 165 ED-2 Devices that create media sessions and exchange audio, video 166 and/or text, and have the capability to establish sessions to a wide 167 variety of addresses, and communicate over private IP networks or the 168 Internet, SHOULD support emergency calls. Some jurisdictions have 169 regulations governing this. 171 5. Identifying an emergency call 173 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 174 the service provider always knows the location of the device, then 175 the service provider could recognize them. 177 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 178 some reason the endpoint does not recognize them. This cannot be 179 relied upon by the device if the service provider cannot always 180 determine the location of the device. 182 ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the 183 Request-URI of the INVITE. 185 ED-5/SP-4 Local dial strings MUST be recognized. 187 ED-6/SP-5 Devices MUST be able to be configured with the home country 188 from which the home dial string(s) can be determined. 190 ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST 191 [RFC5222]. Dial Strings MAY be configured directly in the device. 193 AN-1 LoST servers MUST return dial strings for emergency services 195 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 196 send dial strings as per [RFC4967]. 198 SP-7 If a proxy server recognizes dial strings on behalf of its 199 clients it MUST recognize emergency dial strings represented by 200 [RFC4967] and SHOULD recognize emergency dial strings represented by 201 a tel URI [RFC3966]. 203 ED-9 Endpoints SHOULD be able to have home dial strings provisioned. 205 SP-8 Service providers MAY provision home dial strings in devices. 207 ED-10 Devices SHOULD NOT have one button emergency calling 208 initiation. 210 ED-11/SP-9 All emergency services specified in [RFC5031] MUST be 211 recognized. 213 6. Location and its role in an emergency call 215 Handling location for emergency calling usually involves several 216 steps to process and multiple elements are involved. In Internet 217 emergency calling, where the endpoint is located is "determined" 218 using a variety of measurement or wiretracing methods. Endpoints may 219 be "configured" with their own location by the access network. In 220 some circumstances, a proxy server may insert location into the 221 signaling on behalf of the endpoint. The location is "mapped" to the 222 URI to send the call to, and the location is "conveyed" to the PSAP 223 (and other elements) in the signaling. Likewise, we employ Location 224 Configuration Protocols, the Location-to-Service Mapping Protocol, 225 and Location Conveyance Protocols for these functions. The Location- 226 to-Service Translation protocol [RFC5222] is the Location Mapping 227 Protocol defined by the IETF. 229 6.1. Types of location information 231 There are several forms of location. In IETF location configuration 232 and location conveyance protocols, civic and geospatial (geo) forms 233 are both supported. The civic forms include both postal and 234 jurisdictional fields. A cell tower/sector can be represented as a 235 point (geo or civic) or polygon. Other forms of location 236 representation must be mapped into either a geo or civic for use in 237 emergency calls. 239 ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service 240 Providers MUST be prepared to handle location represented in either 241 civic or geo form. 243 ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo 244 to civic) from the form of location the determination mechanism 245 supplied. 247 6.2. Location Determination 249 ED-14/INT-3/AN-3 Any suitable location determination mechanism MAY be 250 used. 252 6.2.1. User-entered location information 254 ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks 255 SHOULD support a manual method to "override" the location the access 256 network determines. Where a civic form of location is provided, all 257 fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be 258 specified. 260 6.2.2. Access network "wire database" location information 262 AN-5 Access networks supporting copper, fiber or other hard wired IP 263 packet service SHOULD support location configuration. If the network 264 does not support location configuration, it MUST require every device 265 that connects to the network to support end system measured location. 267 AN-6/INT-5 Access networks and intermediate devices providing wire 268 database location information SHOULD provide interior location data 269 (building, floor, room, cubicle) where possible. It is RECOMMENDED 270 that interior location be provided when spaces exceed approximately 271 650 square meters. 273 AN-7/INT-6 Access networks and intermediate devices (including 274 enterprise networks) which support intermediate range wireless 275 connections (typically 100m or less of range) and which do not 276 support a more accurate location determination mechanism such as 277 triangulation, MUST support location configuration where the location 278 of the access point is reflected as the location of the clients of 279 that access point. Where the access network provides location 280 configuration, intermediate devices MUST either be transparent to it, 281 or provide an interconnected client for the supported configuration 282 mechanism and a server for a configuration protocol supported by end 283 devices downstream of the intermediate device 285 6.2.3. End-system measured location information 287 ED-16/INT-7 Devices MAY support end-system measured location. 288 Uncertainty of less than 100 m with 95% confidence SHOULD be 289 available for dispatch. 291 ED-17/INT-8/AN-8 Devices that support endpoint measuring of location 292 MUST have at least a coarse location capability (typically <1km 293 accuracy when not location hiding) for routing of calls. The 294 location mechanism MAY be a service provided by the access network. 296 6.2.4. Network-measured location information 298 AN-9 Access networks MAY provide network-measured location 299 determination. Wireless access network which do not support network 300 measured location MUST require that all devices connected to the 301 network have end-system measured location. Uncertainty of less than 302 100 m with 95% confidence SHOULD be available for dispatch. 304 AN-10 Access networks that provide network measured location MUST 305 have at least a coarse location (typically <1km when not location 306 hiding) capability at all times for routing of calls. 308 AN-11 Access networks with range of <10 meters (e.g. personal area 309 networks such as Bluetooth MUST provide a location to mobile devices 310 connected to them. The location provided SHOULD be that of the 311 access point location unless a more accurate mechanism is provided. 313 6.3. Who adds location, endpoint or proxy 315 ED-18/INT-9 Endpoints SHOULD attempt to configure their own location 316 using the LCPs listed in ED-21. 318 SP-12 Proxies MAY provide location on behalf of devices if: 319 o The proxy has a relationship with all access networks the device 320 could connect to, and the relationship allows it to obtain 321 location. 322 o The proxy has an identifier, such as an IP address, that can be 323 used by the access network to determine the location of the 324 endpoint, even in the presence of NAT and VPN tunnels that may 325 obscure the identifier between the access network and the service 326 provider. 328 ED-19/INT-10/SP-13 Where proxies provide location on behalf of 329 endpoints, the service provider MUST ensure that either the end 330 device is provided with the local dial strings for its current 331 location (where the end device recognizes dial strings), or the 332 service provider proxy MUST detect the appropriate local dial strings 333 at the time of the call. 335 6.4. Location and references to location 337 ED-20/INT-11 Devices SHOULD be able to accept and forward location by 338 value or by reference. An end device that receives location by 339 reference (and does not also get the corresponding value) MUST be 340 able to perform a dereference operation to obtain a value. 342 6.5. End system location configuration 344 ED-21/INT-12 Devices MUST support both the DHCP location options 345 [RFC4776], [RFC3825] and HELD 346 [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a 347 specific access network interface in which that access network 348 supports location discovery such as LLDP-MED [LLDP-MED] or 802.11v, 349 the device SHOULD support the additional respective access network 350 specific location discovery mechanism. 352 AN-12/INT-13 The access network MUST support either DHCP location 353 options or HELD. The access network SHOULD support other location 354 technologies that are specific to the type of access network. 356 AN-13/INT-14 Where a router is employed between a LAN and WAN in a 357 small (less than approximately 650 square meters) area, the router 358 MUST be transparent to the location provided by the WAN to the LAN. 359 This may mean the router must obtain location as a client from the 360 WAN, and supply an LCP server to the LAN with the location it 361 obtains. Where the area is larger, the LAN MUST have a location 362 configuration mechanism meeting this BCP. 364 ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in 365 any order or in parallel. The first one that succeeds in supplying 366 location can be used. 368 AN-14/INT-16 Access networks that support more than one LCP MUST 369 reply with the same location information (within the limits of the 370 data format for the specific LCP) for all LCPs it supports. 372 ED-23/INT-17/SP-14 When HELD is the LCP, the request MUST specify a 373 value of "emergencyRouting" for the "responseTime" parameter and use 374 the resulting location for routing. If a value for dispatch location 375 will be sent, another request with the "responseTime" parameter set 376 to "emergencyDispatch" must be completed, with the result sent for 377 dispatch purposes. 379 ED-24 Where the operating system supporting application programs 380 which need location for emergency calls does not allow access to 381 Layer 2 and Layer 3 functions necessary for a client application to 382 use DHCP location options and/or other location technologies that are 383 specific to the type of access network, the operating system MUST 384 provide a published API conforming to ED-12 through ED-21 and ED-21 385 through ED-31. It is RECOMMENDED that all operating systems provide 386 such an API. 388 6.6. When location should be configured 390 ED-25/INT-18 Endpoints SHOULD obtain location immediately after 391 obtaining local network configuration information. When HELD is the 392 LCP the client MUST support a random back-off period (between 30 393 seconds and 300 seconds) for re-trying the HELD query, when no 394 response is received, and no other LCP provided location information. 396 ED-26/INT-19 If the device is configured to use DHCP for 397 bootstrapping, it MUST include both options for location acquisition 398 (civic and geodetic), the option for LIS discovery, and the option 399 for LoST discovery as defined in [RFC4776], [RFC3825], 400 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 402 ED-27/INT-20 If the device sends a DHCPINFORM message, it MUST 403 include both options for location acquisition (civic and geodetic), 404 the option for LIS discovery, and the option for LoST discovery as 405 defined in [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and 406 [RFC5223]. 408 ED-28/INT-21 To minimize the effects of VPNs that do not allow 409 packets to be sent via the native hardware interface rather than via 410 the VPN tunnel, location configuration SHOULD be attempted before 411 such tunnels are established. 413 ED-29/INT-22 Software which uses LCPs SHOULD locate and use the 414 actual hardware network interface rather than a VPN tunnel interface 415 to direct LCP requests to the LIS in the actual access network. 417 AN-15 Network administrators MUST take care in assigning IP addresses 418 such that VPN address assignments can be distinguished from local 419 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 420 to provide location to addresses that arrive via VPN connections 421 unless it can accurately determine the location for such addresses. 423 AN-16 Placement of NAT devices where an LCP uses IP address for an 424 identifier SHOULD consider the effect of the NAT on the LCP. The 425 address used to query the LIS MUST be able to correctly identify the 426 record in the LIS representing the location of the querying device 428 ED-30/INT-23 For devices which are not expected to roam, refreshing 429 location on the order of once per day is RECOMMENDED. 431 ED-31/INT-24 For devices which roam, refresh of location information 432 SHOULD be more frequent, with the frequency related to the mobility 433 of the device and the ability of the access network to support the 434 refresh operation. If the device can detect that it has moved, for 435 example when it changes access points, the device SHOULD refresh its 436 location. 438 ED-32/INT-25/AN-17 It is RECOMMENDED that location determination not 439 take longer than 250 ms to obtain routing location and systems SHOULD 440 be designed such that the typical response is under 100 ms. However, 441 as much as 3 seconds to obtain routing location MAY be tolerated if 442 location accuracy can be substantially improved over what can be 443 obtained in 250 ms. 445 6.7. Conveying location in SIP 447 ED-33/SP-15 Location sent between SIP elements MUST be conveyed using 448 [I-D.ietf-sip-location-conveyance]. 450 6.8. Location updates 452 ED-34/AN-18 Where the absolute location or the accuracy of location 453 of the endpoint may change between the time the call is received at 454 the PSAP and the time dispatch is completed, location update 455 mechanisms MUST be provided. 457 ED-35/AN-19 Mobile devices MUST be provided with a mechanism to get 458 repeated location updates to track the motion of the device during 459 the complete processing of the call. 461 ED-36/AN-20 The LIS SHOULD provide a location reference which permits 462 a subscription with appropriate filtering. 464 ED-37/AN-21 For calls sent with location-by-reference, with a SIP or 465 SIPS scheme, the server resolving the reference MUST support a 466 SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other 467 location-by-reference schemes that do not support subscription, the 468 PSAP will have to repeatedly dereference the URI to determine if the 469 device moved. 471 ED-38 If location was sent by value, and the endpoint gets updated 472 location, it MUST send the updated location to the PSAP via a SIP re- 473 INVITE or UPDATE request. Such updates SHOULD be limited to no more 474 than one update every 10 seconds. 476 6.9. Multiple locations 478 ED-39/SP-16 If the LIS has more than one location for an endpoint it 479 MUST use the procedures in [RFC5491] 481 ED-40 If a UA has more than one location available to it, it MUST 482 choose one location to route the call towards the PSAP. If multiple 483 locations are in a single PIDF, the procedures in [RFC5491] MUST be 484 followed. If the UA has multiple PIDFs, and has no reasonable basis 485 to choose from among them, a random choice is acceptable. 487 SP-17 If a proxy inserts location on behalf of an endpoint, and it 488 has multiple locations available for the endpoint it MUST choose one 489 location to use to route the call towards the PSAP. 491 SP-18 If a proxy is attempting to insert location but the UA conveyed 492 a location to it, the proxy MUST use the UA's location for routing 493 and MUST convey that location towards the PSAP. It MAY also include 494 what it believes the location to be in a separate Geolocation header. 496 SP-19 All location objects received by a proxy MUST be delivered to 497 the PSAP. 499 ED-41/SP-20 Location objects MUST contain information about the 500 method by which the location was determined, such as GPS, manually 501 entered, or based on access network topology included in a PIDF- LO 502 "method" element. In addition, the source of the location 503 information MUST be included in a PIDF-LO "provided-by" element. 505 ED-??/SP-?? A location with a method of "derived" MUST NOT be used 506 unless no other location is available. 508 ED-42/SP-21 The "used-for-routing" parameter MUST be set to the 509 location that was chosen for routing. 511 6.10. Location validation 513 AN-22 A LIS should perform location validation of civic locations via 514 LoST before entering a location in its database. 516 ED-43 Endpoints SHOULD validate civic locations when they receive 517 them from their LCP. Validation SHOULD be performed in conjunction 518 with the LoST route query to minimize load on the LoST server. 520 6.11. Default location 522 AN-23 When the access network cannot determine the actual location of 523 the caller, it MUST supply a default location. The default SHOULD be 524 chosen to be as close to the probable location of the device as the 525 network can determine. See [I-D.ietf-ecrit-framework] 527 SP-22 Proxies handling emergency calls MUST insert a default location 528 if the call does not contain a location and the proxy does not have a 529 method for obtaining a better location. 531 AN-24/SP-23 Default locations MUST be marked with method=Default and 532 the proxy MUST be identified in provided-by element of the PIDF-LO. 534 6.12. Other location considerations 536 ED-44 If the LCP does not return location in the form of a PIDF-LO 537 [RFC4119], the endpoint MUST map the location information it receives 538 from the configuration protocol to a PIDF-LO. 540 ED-45/AN-25 To prevent against spoofing of the DHCP server, elements 541 implementing DHCP for location configuration SHOULD use [RFC3118] 542 although the difficulty in providing appropriate credentials is 543 significant. 545 ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header 546 or bodies. 548 ED-47/SP-24 TLS MUST be used to protect location (but see 549 Section 9.1). IPSEC [RFC3986] is an acceptable alternative. 551 7. LIS and LoST Discovery 553 ED-48 Endpoints MUST support one or more mechanisms that allow them 554 to determine their public IP address. Examples include STUN 555 [RFC5389] and HTTP get. 557 ED-49 Endpoints MUST support LIS discovery as described in 558 [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described 559 in [RFC5223]. 561 ED-50 The device MUST have a configurable default LoST server 562 parameter. If the device is provided by or managed by a service 563 provider, it is expected that the service provider will configure 564 this option. 566 ED-51 DHCP LoST discovery MUST be used, if available, in preference 567 to configured LoST servers. If neither DHCP nor configuration leads 568 to an available LoST server, the device MUST query DNS using it's SIP 569 domain for an SRV record for a LoST service and use that server. 571 AN-26 Access networks which support DHCP MUST implement the LoST 572 discovery option 574 SP-25 Service Providers MUST provide an SRV entry in their DNS server 575 which leads to a LoST server 577 AN-27 Access Networks that use HELD and that have a DHCP server 578 SHOULD support DHCP options for providing LIS and LoST servers. 580 ED-52 When an endpoint has obtained a LoST server via an discovery 581 mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered 582 LoST server over LoST servers configured by other means. That is, 583 the endpoint MUST send queries to this LoST server first, using other 584 LoST servers only if these queries fail. 586 8. Routing the call to the PSAP 588 ED-53 Endpoints who obtain their own location SHOULD perform LoST 589 mapping to the PSAP URI. 591 ED-54 Mapping SHOULD be performed at boot time and whenever location 592 changes beyond the service boundary obtained from a prior LoST 593 mapping operation or the time-to-live value of that response has 594 expired. The value MUST be cached for possible later use. 596 ED-55 The endpoint MUST attempt to update its location at the time of 597 an emergency call. If it cannot obtain a new location quickly (see 598 Section 6), it MUST use the cached value. 600 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 601 time of an emergency call. If it cannot obtain a new mapping 602 quickly, it MUST use the cached value. If the device cannot update 603 the LoST mapping and does not have a cached value, it MUST signal an 604 emergency call without a Route header containing a PSAP URI. 606 SP-26 Networks MUST be designed so that at least one proxy in the 607 outbound path will recognize emergency calls with a Request URI of 608 the service URN in the "sos" tree. An endpoint places a service URN 609 in the Request URI to indicate that the endpoint understood the call 610 was an emergency call. A proxy that processes such a call looks for 611 the presence of a SIP Route header field with a URI of a PSAP. 612 Absence of such a Route header indicates the UAC was unable to invoke 613 LoST and the proxy MUST perform the LoST mapping and insert a Route 614 header field with the URI obtained. 616 SP-27 To deal with old user agents that predate this specification 617 and with UAs that do not have access to their own location data, a 618 proxy that recognizes a call as an emergency call that is not marked 619 as such (see Section 5) MUST also perform this mapping, with the best 620 location it has available for the endpoint. The resulting PSAP URI 621 would be placed in a Route header with the service URN in the Request 622 URI. 624 SP-28 Proxy servers performing mapping SHOULD use location obtained 625 from the access network for the mapping. If no location is 626 available, a default location (see Section 6.11) MUST be supplied. 628 SP-29 A proxy server which attempts mapping and fails to get a 629 mapping MUST provide a default mapping. A suitable default mapping 630 would be the mapping obtained previously for the default location 631 appropriate for the caller. 633 ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route 634 an emergency call towards the PSAP's URI. 636 ED-58 Initial INVITES MAY provide an Offer [RFC3264]. 638 9. Signaling of emergency calls 640 ED-59 deleted 642 9.1. Use of TLS 644 ED-60/SP-31 TLS MUST be specified when attempting to signal an 645 emergency call. IPSEC [RFC3986] is an acceptable alternative. 647 ED-61/SP-32 If TLS session establishment is not available, or fails, 648 the call MUST be retried without TLS. 650 ED-62/SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS 651 connections between elements. 653 ED-63/AN-28 TLS MUST be specified when attempting to retrieve 654 location (configuration or dereferencing) with HELD. The use of 655 [RFC5077] is RECOMMENDED to minimize the time to establish TLS 656 sessions without keeping server-side state. 658 ED-64/AN-29 If TLS session establishment fails, the location 659 retrieval MUST be retried without TLS. 661 9.2. SIP signaling requirements for User Agents 663 ED-65 The initial SIP signaling method is an INVITE request: 664 1. The Request URI SHOULD be the service URN in the "sos" tree, If 665 the device cannot interpret local dial strings, the Request-URI 666 SHOULD be a dial string URI [RFC4967] with the dialed digits. 667 2. The To header SHOULD be a service URN in the "sos" tree. If the 668 device cannot interpret local dial strings, the To: SHOULD be a 669 dial string URI with the dialed digits. 670 3. The From header MUST be present and SHOULD be the AoR of the 671 caller. 672 4. A Via header MUST be present. 674 5. A Route header SHOULD be present with a PSAP URI obtained from 675 LoST (see Section 8) and the loose route parameter. If the 676 device does not interpret dial plans, or was unable to obtain a 677 route from a LoST server, no Route header will be present. 678 6. A Contact header MUST be present which MUST be globally 679 routable, for example a GRUU [RFC5627], and be valid for several 680 minutes following the termination of the call, provided that the 681 UAC remains registered with the same registrar, to permit an 682 immediate call-back to the specific device which placed the 683 emergency call. It is acceptable if the UAC inserts a locally 684 routable URI and a subsequent B2BUA maps that to a globally 685 routable URI. 686 7. Other headers MAY be included as per normal SIP behavior. 687 8. A Supported header MUST be included with the 'geolocation' 688 option tag [I-D.ietf-sip-location-conveyance], unless the device 689 does not understand the concept of SIP location. 690 9. If a device understands the SIP location conveyance 691 [I-D.ietf-sip-location-conveyance] extension and has its 692 location available, it MUST include location either by-value, 693 by-reference or both. 694 10. If a device understands the SIP Location Conveyance extension 695 and has its location unavailable or unknown to that device, it 696 MUST include a Supported header with a "geolocation" option tag, 697 and MUST NOT include a Geolocation header, and not include a 698 PIDF-LO message body. 699 11. If a device understands the SIP Location Conveyance extension 700 and supports LoST [RFC5222], the Geolocation "used-for-routing" 701 header parameter MUST be added to the corresponding URI in the 702 Geolocation header. If the device is unable to obtain a PSAP 703 URI for any reason it MUST NOT include "used-for-routing" on a 704 Geolocation URI, so that downstream entities know that LoST 705 routing has not been completed. 706 12. A SDP offer SHOULD be included in the INVITE. If voice is 707 supported the offer MUST include the G.711 codec, see 708 Section 14. As PSAPs may support a wide range of media types 709 and codecs, sending an offerless INVITE may result in a lengthy 710 return offer, but is permitted. Cautions in [RFC3261] on 711 offerless INVITEs should be considered before such use. 712 13. If the device includes location-by-value, the UA MUST support 713 multipart message bodies, since SDP will likely be also in the 714 INVITE. 715 14. A UAC SHOULD include a "inserted-by" header parameter with its 716 own hostname on all Geolocation headers. This informs 717 downstream elements which device entered the location at this 718 URI (either cid-URL or location-by-reference URI). 719 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 720 PSAP should handle the call. For example, a language preference 721 expressed in an Accept-Language header may be used as a hint to 722 cause the PSAP to route the call to a call taker who speaks the 723 requested language. SIP Caller Preferences may also be used to 724 indicate a need to invoke a relay service for communication with 725 people with disabilities in the call. 727 9.3. SIP signaling requirements for proxy servers 729 SP-34 SIP Proxy servers processing emergency calls: 730 1. If the proxy interprets dial plans on behalf of user agents, the 731 proxy MUST look for the local emergency dial string at the 732 location of the end device and MAY look for the home dial string. 733 If it finds it, the proxy MUST: 734 * Insert a Geolocation header as above. Location-by-reference 735 MUST be used because proxies must not insert bodies. 736 * Include the Geolocation "inserted-by" and "used-for-routing" 737 parameters with its own hostname (which should match the Via 738 it inserts) on the inserted-by. 739 * Map the location to a PSAP URI using LoST. 740 * Add a Route header with the PSAP URI. 741 * Replace the Request-URI (which was the dial string) with the 742 service URN appropriate for the emergency dial string. 743 * Route the call using normal SIP routing mechanisms. 744 2. If the proxy recognizes the service URN in the Request URI, and 745 does not find a a Route header, it MUST query a LoST server. If 746 multiple locations were provided, the proxy uses the location 747 that has the "used-for-routing" marker set. If a location was 748 provided (which should be the case), the proxy uses that location 749 to query LoST. The proxy may have to dereference a location by 750 reference to get a value. If a location is not present, and the 751 proxy can query a LIS which has the location of the UA it MUST do 752 so. If no location is present, and the proxy does not have 753 access to a LIS which could provide location, the proxy MUST 754 supply a default location (See Section 6.11). The location (in 755 the signaling, obtained from a LIS, or default) MUST be used in a 756 query to LoST with the service URN received with the call. The 757 resulting URI MUST be placed in a Route header added to the call. 758 3. The "inserted-by" parameter in any Geolocation: header received 759 on the call MUST NOT be modified or deleted in transit. 760 4. The proxy SHOULD NOT modify any parameters in Geolocation headers 761 received in the call. It MAY add a Geolocation header. Such an 762 additional location SHOULD NOT be used for routing; the location 763 provided by the UA should be used. 764 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 765 [RFC4474], or both, SHOULD be included to identify the sender. 766 For services which must support emergency calls from 767 unauthenticated devices, valid identity may not be available. 769 10. Call backs 771 ED-66/SP-35 Devices device SHOULD have a globally routable URI in a 772 Contact: header which remains valid for 30 minutes past the time the 773 original call containing the URI completes unless the device 774 registration expires and is not renewed. 776 SP-36 Call backs to the Contact: header URI recieved within 30 777 minutes of an emergency call must reach the device regardless of call 778 features or services that would normally cause the call to be routed 779 to some other entity. 781 SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- 782 Identity: header or From: protected by an Identity header suitable 783 for returning a call some time after the original call. Such a call 784 back would not necessarily reach the device that originally placed 785 the call. 787 11. Mid-call behavior 789 ED-67/SP-38 During the course of an emergency call, devices and 790 proxies MUST support REFER transactions with method=INVITE and the 791 Referred-by: header [RFC3515] in that transaction. 793 12. Call termination 795 ED-68 deleted 797 ED-69 There can be a case where the session signaling path is lost, 798 and the user agent does not receive the BYE. If the call is hung up, 799 and the session timer (if implemented) expires, the call MAY be 800 declared lost. If in the interval, an incoming call is received from 801 the domain of the PSAP, the device MUST drop the old call and alert 802 for the (new) incoming call. Dropping of the old call MUST only 803 occur if the user is attempting to hang up; the domain of an incoming 804 call can only be determined from the From header, which is not 805 reliable, and could be spoofed. Dropping an active call by a new 806 call with a spoofed From: would be a DoS attack. 808 13. Disabling of features 810 ED-70/SP-39 User Agents and proxies MUST disable features that will 811 interrupt an ongoing emergency call, such as: 813 o Call Waiting 814 o Call Transfer 815 o Three Way Call 816 o Hold 817 o Outbound Call Blocking 818 when an emergency call is established. Also see ED-77 in Section 14. 820 ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in 821 Call Forward numbers or speed dial lists. 823 ED-72/SP-41 The User Agent and Proxies MUST disable call features 824 which would interfere with the ability of call backs from the PSAP to 825 be completed such as: 826 o Do Not Disturb 827 o Call Forward (all kinds) 829 ED-73 Call backs SHOULD be determined by retaining the domain of the 830 PSAP which answers an outgoing emergency call and instantiating a 831 timer which starts when the call is terminated. If a call is 832 received from the same domain and within the timer period, sent to 833 the Contact: or AoR used in the emergency call, it should be assumed 834 to be a call back. The suggested timer period is 5 minutes. 835 [RFC4916] may be used by the PSAP to inform the UA of the domain of 836 the PSAP. Recognizing a call back from the domain of the PSAP will 837 not always work, and further standardization will be required to give 838 the UA the ability to recognize a call back. 840 14. Media 842 ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. 844 ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 845 agree on the media streams to be used. 847 ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law 848 if they are intended be used in North America) encoded voice as 849 described in [RFC3551]. It is desirable to include wideband codecs 850 such as AMR-WB in the offer. 852 ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT 853 be used on emergency calls. PSAP call takers sometimes get 854 information on what is happening in the background to determine how 855 to process the call. 857 ED-78 Endpoints supporting Instant Messaging (IM) MUST support both 858 [RFC3428] and [RFC4975]. 860 ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The 861 expectations for emergency service support for the real-time text 862 medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. 864 ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. 866 15. Testing 868 ED-81 INVITE requests to a service URN ending in ".test" indicates a 869 request for an automated test. For example, 870 "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response 871 indicates that the address was recognized and a 404 (Not found) that 872 it was not. A 486 (Busy Here) MUST be returned if the test service 873 is busy, and a 404 (Not found) MUST be returned if the PSAP does not 874 support the test mechanism. 876 ED-82 In its response to the test, the PSAP MAY include a text body 877 (text/plain) indicating the identity of the PSAP, the requested 878 service, and the location reported with the call. For the latter, 879 the PSAP SHOULD return location-by-value even if the original 880 location delivered with the test was by-reference. If the location- 881 by-reference was supplied, and the dereference requires credentials, 882 the PSAP SHOULD use credentials supplied by the LIS for test 883 purposes. This alerts the LIS that the dereference is not for an 884 actual emergency call and location hiding techniques, if they are 885 being used, may be employed for this dereference. Use of SIPS for 886 the request would assure the response containing the location is kept 887 private 889 ED-83 A PSAP accepting a test call SHOULD accept a media loopback 890 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 891 pkt-loopback" and "rtp-start-loopback" options. The user agent would 892 specify a loopback attribute of "loopback-source", the PSAP being the 893 mirror. User Agents should expect the PSAP to loop back no more than 894 3 packets of each media type accepted (which limits the duration of 895 the test), after which the PSAP would normally send BYE. 897 ED-84 User agents SHOULD perform a full call test, including media 898 loopback, after a disconnect and subsequent change in IP address not 899 due to a reboot. After an initial test, a full test SHOULD be 900 repeated approximately every 30 days with a random interval. 902 ED-85 User agents MUST NOT place a test call immediately after 903 booting. If the IP address changes after booting, the UA should wait 904 a random amount of time (in perhaps a 30 minute period, sufficient 905 for any avalanche restart to complete) and then test. 907 ED-86 PSAPs MAY refuse repeated requests for test from the same 908 device in a short period of time. Any refusal is signaled with a 486 909 or 488 response. 911 16. Security Considerations 913 Security considerations for emergency calling have been documented in 914 [RFC5069], and [I-D.ietf-geopriv-arch]. 916 17. IANA Considerations 918 This document has no actions for IANA. 920 18. Acknowledgements 922 Work group members participating in the creation and review of this 923 document include include Hannes Tschofenig, Ted Hardie, Marc Linsner, 924 Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, 925 Barbara Stark, Richard Barnes and Peter Blatherwick. 927 19. References 929 19.1. Normative References 931 [I-D.ietf-geopriv-http-location-delivery] 932 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 933 "HTTP Enabled Location Delivery (HELD)", 934 draft-ietf-geopriv-http-location-delivery-16 (work in 935 progress), August 2009. 937 [I-D.ietf-geopriv-lis-discovery] 938 Thomson, M. and J. Winterbottom, "Discovering the Local 939 Location Information Server (LIS)", 940 draft-ietf-geopriv-lis-discovery-13 (work in progress), 941 December 2009. 943 [I-D.ietf-mmusic-media-loopback] 944 Sivachelvan, C., Venna, N., Jones, P., Stratton, N., 945 Roychowdhury, A., and K. Hedayat, "An Extension to the 946 Session Description Protocol (SDP) for Media Loopback", 947 draft-ietf-mmusic-media-loopback-11 (work in progress), 948 October 2009. 950 [I-D.ietf-sip-location-conveyance] 951 Polk, J. and B. Rosen, "Location Conveyance for the 952 Session Initiation Protocol", 953 draft-ietf-sip-location-conveyance-13 (work in progress), 954 March 2009. 956 [LLDP-MED] 957 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 958 Endpoint Discovery". 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, March 1997. 963 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 964 Messages", RFC 3118, June 2001. 966 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 967 A., Peterson, J., Sparks, R., Handley, M., and E. 968 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 969 June 2002. 971 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 972 Protocol (SIP): Locating SIP Servers", RFC 3263, 973 June 2002. 975 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 976 with Session Description Protocol (SDP)", RFC 3264, 977 June 2002. 979 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 980 Event Notification", RFC 3265, June 2002. 982 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 983 and D. Gurle, "Session Initiation Protocol (SIP) Extension 984 for Instant Messaging", RFC 3428, December 2002. 986 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 987 Method", RFC 3515, April 2003. 989 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 990 Jacobson, "RTP: A Transport Protocol for Real-Time 991 Applications", STD 64, RFC 3550, July 2003. 993 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 994 Video Conferences with Minimal Control", STD 65, RFC 3551, 995 July 2003. 997 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 998 Configuration Protocol Option for Coordinate-based 999 Location Configuration Information", RFC 3825, July 2004. 1001 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1002 Preferences for the Session Initiation Protocol (SIP)", 1003 RFC 3841, August 2004. 1005 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1006 Initiation Protocol (SIP)", RFC 3856, August 2004. 1008 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1009 RFC 3966, December 2004. 1011 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 1012 M., and D. Singer, "RTP Payload Format for H.264 Video", 1013 RFC 3984, February 2005. 1015 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1016 Resource Identifier (URI): Generic Syntax", STD 66, 1017 RFC 3986, January 2005. 1019 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1020 Conversation", RFC 4103, June 2005. 1022 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1023 Format", RFC 4119, December 2005. 1025 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1026 Authenticated Identity Management in the Session 1027 Initiation Protocol (SIP)", RFC 4474, August 2006. 1029 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1030 (DHCPv4 and DHCPv6) Option for Civic Addresses 1031 Configuration Information", RFC 4776, November 2006. 1033 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1034 Protocol (SIP)", RFC 4916, June 2007. 1036 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1037 Initiation Protocol Uniform Resource Identifier", 1038 RFC 4967, July 2007. 1040 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1041 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1043 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1044 Emergency and Other Well-Known Services", RFC 5031, 1045 January 2008. 1047 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1048 Format for Presence Information Data Format Location 1049 Object (PIDF-LO)", RFC 5139, February 2008. 1051 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1052 Tschofenig, "LoST: A Location-to-Service Translation 1053 Protocol", RFC 5222, August 2008. 1055 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1056 Location-to-Service Translation (LoST) Servers Using the 1057 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1058 August 2008. 1060 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1061 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1062 October 2008. 1064 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1065 Presence Information Data Format Location Object (PIDF-LO) 1066 Usage Clarification, Considerations, and Recommendations", 1067 RFC 5491, March 2009. 1069 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 1070 Initiated Connections in the Session Initiation Protocol 1071 (SIP)", RFC 5626, October 2009. 1073 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1074 Agent URIs (GRUUs) in the Session Initiation Protocol 1075 (SIP)", RFC 5627, October 2009. 1077 19.2. Informative References 1079 [I-D.ietf-ecrit-framework] 1080 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1081 "Framework for Emergency Calling using Internet 1082 Multimedia", draft-ietf-ecrit-framework-10 (work in 1083 progress), July 2009. 1085 [I-D.ietf-geopriv-arch] 1086 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1087 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1088 Location and Location Privacy in Internet Applications", 1089 draft-ietf-geopriv-arch-01 (work in progress), 1090 October 2009. 1092 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1093 Extensions to the Session Initiation Protocol (SIP) for 1094 Asserted Identity within Trusted Networks", RFC 3325, 1095 November 2002. 1097 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1098 Emergency Context Resolution with Internet Technologies", 1099 RFC 5012, January 2008. 1101 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1102 Shanmugam, "Security Threats and Requirements for 1103 Emergency Call Marking and Mapping", RFC 5069, 1104 January 2008. 1106 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1107 "Transport Layer Security (TLS) Session Resumption without 1108 Server-Side State", RFC 5077, January 2008. 1110 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 1111 over IP Using the Session Initiation Protocol (SIP)", 1112 RFC 5194, June 2008. 1114 Appendix A. BCP Requirements Sorted by Responsible Party 1116 A.1. Requirements of End Devices 1118 ED-1 A device or application SHOULD support emergency calling if a 1119 user could reasonably expect to be able to place a call for help with 1120 the device. Some jurisdictions have regulations governing this. 1122 ED-2 Devices that create media sessions and exchange audio, video 1123 and/or text, and have the capability to establish sessions to a wide 1124 variety of addresses, and communicate over private IP networks or the 1125 Internet, SHOULD support emergency calls. Some jurisdictions have 1126 regulations governing this. 1128 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 1129 the service provider always knows the location of the device, then 1130 the service provider could recognize them. 1132 ED-4 Emergency calls MUST be marked with a Service URN in the 1133 Request-URI of the INVITE. 1135 ED-5 Local dial strings MUST be recognized. 1137 ED-6 Devices MUST be able to be configured with the home country from 1138 which the home dial string(s) can be determined. 1140 ED-7 Emergency dial strings SHOULD be determined from LoST [RFC5222]. 1141 Dial Strings MAY be configured directly in the device. 1143 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 1144 send dial strings as per [RFC4967]. 1146 ED-9 Endpoints SHOULD be able to have home dial strings provisioned 1147 by configuration. 1149 ED-10 Devices SHOULD NOT have one button emergency calling 1150 initiation. 1152 ED-11 All emergency services specified in [RFC5031] MUST be 1153 recognized. 1155 ED-12 Endpoints, Intermediate Devices and Service Providers MUST be 1156 prepared to handle location represented in either civic or geo form. 1158 ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from 1159 the form of location the determination mechanism supplied. 1161 ED-14 Any suitable location determination mechanism MAY be used. 1163 ED-15 Devices, intermediate Devices and/or access networks SHOULD 1164 support a manual method to "override" the location the access network 1165 determines. Where a civic form of location is provided, all fields 1166 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1168 ED-16 Devices MAY support end-system measured location. Uncertainty 1169 of less than 100 m with 95% confidence SHOULD be available for 1170 dispatch. 1172 ED-17 Devices that support endpoint measuring of location MUST have 1173 at least a coarse location capability (typically <1km accuracy when 1174 not location hiding) for routing of calls. The location mechanism 1175 MAY be a service provided by the access network. 1177 ED-18 Endpoints SHOULD attempt to configure their own location using 1178 the LCPs listed in ED-21. 1180 ED-19 Where proxies provide location on behalf of endpoints, the 1181 service provider MUST ensure that either the end device is provided 1182 with the local dial strings for its current location (where the end 1183 device recognizes dial strings), or the service provider proxy MUST 1184 detect the appropriate local dial strings at the time of the call. 1186 ED-20 Devices SHOULD be able to accept and forward location by value 1187 or by reference. An end device that receives location by reference 1188 (and does not also get the corresponding value) MUST be able to 1189 perform a dereference operation to obtain a value. 1191 ED-21 Devices MUST support both the DHCP location options [RFC4776], 1192 [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When 1193 devices deploy a specific access network interface in which that 1194 access network supports location discovery such as LLDP-MED or 1195 802.11v, the device SHOULD support the additional respective access 1196 network specific location discovery mechanism. 1198 ED-22 Endpoints SHOULD try all LCPs supported by the device in any 1199 order or in parallel. The first one that succeeds in supplying 1200 location can be used. 1202 ED-23 When HELD is the LCP, the request MUST specify a value of 1203 "emergencyRouting" for the "responseTime" parameter and use the 1204 resulting location for routing. If a value for dispatch location 1205 will be sent, another request with the "responseTime" parameter set 1206 to "emergencyDispatch" must be completed, with the result sent for 1207 dispatch purposes. 1209 ED-24 Where the operating system supporting application programs 1210 which need location for emergency calls does not allow access to 1211 Layer 2 and Layer 3 functions necessary for a client application to 1212 use DHCP location options and/or other location technologies that are 1213 specific to the type of access network, the operating system MUST 1214 provide a published API conforming to ED-12 through ED-21 and ED-21 1215 through ED-31. It is RECOMMENDED that all operating systems provide 1216 such an API. 1218 ED-25 Endpoints SHOULD obtain location immediately after obtaining 1219 local network configuration information. When HELD is the LCP the 1220 client MUST support a random back-off period (between 30 seconds and 1221 300 seconds) for re-trying the HELD query, when no response is 1222 received, and no other LCP provided location information. 1224 ED-26 If the device is configured to use DHCP for bootstrapping, it 1225 MUST include both options for location acquisition (civic and 1226 geodetic), the option for LIS discovery, and the option for LoST 1227 discovery as defined in [RFC4776], [RFC3825], 1228 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 1230 ED-27 If the device sends a DHCPINFORM message, it MUST include both 1231 options for location acquisition (civic and geodetic), the option for 1232 LIS discovery, and the option for LoST discovery as defined in 1233 [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 1235 ED-28 To minimize the effects of VPNs that do not allow packets to be 1236 sent via the native hardware interface rather than via the VPN 1237 tunnel, location configuration SHOULD be attempted before such 1238 tunnels are established. 1240 ED-29 Software which uses LCPs SHOULD locate and use the actual 1241 hardware network interface rather than a VPN tunnel interface to 1242 direct LCP requests to the LIS in the actual access network. 1244 ED-30 For devices which are not expected to roam, refreshing location 1245 on the order of once per day is RECOMMENDED. 1247 ED-31 For devices which roam, refresh of location information SHOULD 1248 be more frequent, with the frequency related to the mobility of the 1249 device and the ability of the access network to support the refresh 1250 operation. If the device can detect that it has moved, for example 1251 when it changes access points, the device SHOULD refresh its 1252 location. 1254 ED-32 It is RECOMMENDED that location determination not take longer 1255 than 250 ms to obtain routing location and systems SHOULD be designed 1256 such that the typical response is under 100 ms. However, as much as 1257 3 seconds to obtain routing location MAY be tolerated if location 1258 accuracy can be substantially improved over what can be obtained in 1259 250 ms. 1261 ED-33 Location sent between SIP elements MUST be conveyed using 1262 [I-D.ietf-sip-location-conveyance]. 1264 ED-34 Where the absolute location or the accuracy of location of the 1265 endpoint may change between the time the call is received at the PSAP 1266 and the time dispatch is completed, location update mechanisms MUST 1267 be provided. 1269 ED-35 Mobile devices MUST be provided with a mechanism to get 1270 repeated location updates to track the motion of the device during 1271 the complete processing of the call. 1273 ED-36 The LIS SHOULD provide a location reference which permits a 1274 subscription with appropriate filtering. 1276 ED-37 For calls sent with location-by-reference, with a SIP or SIPS 1277 scheme, the server resolving the reference MUST support a SUBSCRIBE 1278 [RFC3265] to the presence event [RFC3856]. For other location-by- 1279 reference schemes that do not support subscription, the PSAP will 1280 have to repeatedly dereference the URI to determine if the device 1281 moved. 1283 ED-38 If location was sent by value, and the endpoint gets updated 1284 location, it MUST send the updated location to the PSAP via a SIP re- 1285 INVITE or UPDATE request. Such updates SHOULD be limited to no more 1286 than one update every 10 seconds. 1288 ED-39 If the LIS has more than one location for an endpoint it MUST 1289 use the procedures in [RFC5491] 1291 ED-40 If a UA has more than one location available to it, it MUST 1292 choose one location to route the call towards the PSAP. If multiple 1293 locations are in a single PIDF, the procedures in [RFC5491] MUST be 1294 followed. If the UA has multiple PIDFs, and has no reasonable basis 1295 to choose from among them, a random choice is acceptable. 1297 ED-41 Location objects MUST contain information about the method by 1298 which the location was determined, such as GPS, manually entered, or 1299 based on access network topology included in a PIDF- LO "method" 1300 element. In addition, the source of the location information MUST be 1301 included in a PIDF-LO "provided-by" element. 1303 ED-42 The "used-for-routing" parameter MUST be set to the location 1304 that was chosen for routing. 1306 ED-43 Endpoints SHOULD validate civic locations when they receive 1307 them from their LCP. Validation SHOULD be performed in conjunction 1308 with the LoST route query to minimize load on the LoST server. 1310 ED-44 If the LCP does not return location in the form of a PIDF-LO 1311 [RFC4119], the endpoint MUST map the location information it receives 1312 from the configuration protocol to a PIDF-LO. 1314 ED-45 To prevent against spoofing of the DHCP server, elements 1315 implementing DHCP for location configuration SHOULD use [RFC3118] 1316 although the difficulty in providing appropriate credentials is 1317 significant. 1319 ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header 1320 or bodies. 1322 ED-47 TLS MUST be used to protect location (but see Section 9.1). 1323 IPSEC [RFC3986] is an acceptable alternative. 1325 ED-48 Endpoints MUST support one or more mechanisms that allow them 1326 to determine their public IP address. Examples include STUN 1327 [RFC5389] and HTTP get. 1329 ED-49 Endpoints MUST support LIS discovery as described in 1330 [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described 1331 in [RFC5223]. 1333 ED-50 The device MUST have a configurable default LoST server 1334 parameter. If the device is provided by or managed by a service 1335 provider, it is expected that the service provider will configure 1336 this option. 1338 ED-51 DHCP LoST discovery MUST be used, if available, in preference 1339 to configured LoST servers. If neither DHCP nor configuration leads 1340 to an available LoST server, the device MUST query DNS using it's SIP 1341 domain for an SRV record for a LoST service and use that server. 1343 ED-52 When an endpoint has obtained a LoST server via an discovery 1344 mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered 1345 LoST server over LoST servers configured by other means. That is, 1346 the endpoint MUST send queries to this LoST server first, using other 1347 LoST servers only if these queries fail. 1349 ED-53 Endpoints who obtain their own location SHOULD perform LoST 1350 mapping to the PSAP URI. 1352 ED-54 Mapping SHOULD be performed at boot time and whenever location 1353 changes beyond the service boundary obtained from a prior LoST 1354 mapping operation or the time-to-live value of that response has 1355 expired. The value MUST be cached for possible later use. 1357 ED-55 The endpoint MUST attempt to update its location at the time of 1358 an emergency call. If it cannot obtain a new location quickly (see 1359 Section 6), it MUST use the cached value. 1361 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 1362 time of an emergency call. If it cannot obtain a new mapping 1363 quickly, it MUST use the cached value. If the device cannot update 1364 the LoST mapping and does not have a cached value, it MUST signal an 1365 emergency call without a Route header containing a PSAP URI. 1367 ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an 1368 emergency call towards the PSAP's URI. 1370 ED-58 Initial INVITES MAY provide an Offer [RFC3264]. 1372 ED-59 deleted 1374 ED-60 TLS MUST be specified when attempting to signal an emergency 1375 call with SIP. IPSEC [RFC3986] is an acceptable alternative. 1377 ED-61 If TLS session establishment is not available, or fails, the 1378 call MUST be retried without TLS. 1380 ED-62 [RFC5626] is RECOMMENDED to maintain persistent TLS connections 1381 between elements. 1383 ED-63 TLS MUST be specified when attempting to retrieve location 1384 (configuration or dereferencing) with HELD. The use of [RFC5077] is 1385 RECOMMENDED to minimize the time to establish TLS sessions without 1386 keeping server-side state. 1388 ED-64 If TLS session establishment fails, the location retrieval MUST 1389 be retried without TLS. 1391 ED-65 The initial SIP signaling method is an INVITE request: 1392 1. The Request URI SHOULD be the service URN in the "sos" tree, If 1393 the device cannot interpret local dial strings, the Request-URI 1394 SHOULD be a dial string URI [RFC4967] with the dialed digits. 1395 2. The To header SHOULD be a service URN in the "sos" tree. If the 1396 device cannot interpret local dial strings, the To: SHOULD be a 1397 dial string URI with the dialed digits. 1398 3. The From header MUST be present and SHOULD be the AoR of the 1399 caller. 1400 4. A Via header MUST be present. 1401 5. A Route header SHOULD be present with a PSAP URI obtained from 1402 LoST (see Section 8) and the loose route parameter. If the 1403 device does not interpret dial plans, or was unable to obtain a 1404 route from a LoST server, no Route header will be present. 1405 6. A Contact header MUST be present which MUST be globally 1406 routable, for example a GRUU [RFC5627], and be valid for several 1407 minutes following the termination of the call, provided that the 1408 UAC remains registered with the same registrar, to permit an 1409 immediate call-back to the specific device which placed the 1410 emergency call. It is acceptable if the UAC inserts a locally 1411 routable URI and a subsequent B2BUA maps that to a globally 1412 routable URI. 1413 7. Other headers MAY be included as per normal SIP behavior. 1414 8. A Supported header MUST be included with the 'geolocation' 1415 option tag [I-D.ietf-sip-location-conveyance], unless the device 1416 does not understand the concept of SIP location. 1417 9. If a device understands the SIP location conveyance 1418 [I-D.ietf-sip-location-conveyance] extension and has its 1419 location available, it MUST include location either by-value, 1420 by-reference or both. 1421 10. If a device understands the SIP Location Conveyance extension 1422 and has its location unavailable or unknown to that device, it 1423 MUST include a Supported header with a "geolocation" option tag, 1424 and MUST NOT include a Geolocation header, and not include a 1425 PIDF-LO message body. 1426 11. If a device understands the SIP Location Conveyance extension 1427 and supports LoST [RFC5222], the Geolocation "used-for-routing" 1428 header parameter MUST be added to the corresponding URI in the 1429 Geolocation header. If the device is unable to obtain a PSAP 1430 URI for any reason it MUST NOT include "used-for-routing" on a 1431 Geolocation URI, so that downstream entities know that LoST 1432 routing has not been completed. 1433 12. A SDP offer SHOULD be included in the INVITE. If voice is 1434 supported the offer MUST include the G.711 codec, see 1435 Section 14. As PSAPs may support a wide range of media types 1436 and codecs, sending an offerless INVITE may result in a lengthy 1437 return offer, but is permitted. Cautions in [RFC3261] on 1438 offerless INVITEs should be considered before such use. 1439 13. If the device includes location-by-value, the UA MUST support 1440 multipart message bodies, since SDP will likely be also in the 1441 INVITE. 1442 14. A UAC SHOULD include a "inserted-by" header parameter with its 1443 own hostname on all Geolocation headers. This informs 1444 downstream elements which device entered the location at this 1445 URI (either cid-URL or location-by-reference URI). 1446 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 1447 PSAP should handle the call. For example, a language preference 1448 expressed in an Accept-Language header may be used as a hint to 1449 cause the PSAP to route the call to a call taker who speaks the 1450 requested language. SIP Caller Preferences may also be used to 1451 indicate a need to invoke a relay service for communication with 1452 people with disabilities in the call. 1454 ED-66 Devices device SHOULD have a globally routable URI in a 1455 Contact: header which remains valid for 30 minutes past the time the 1456 original call containing the URI completes unless the device 1457 registration expires and is not renewed. 1459 ED-67 During the course of an emergency call, devices and proxies 1460 MUST support REFER transactions with method=INVITE and the 1461 Referred-by: header [RFC3515] in that transaction. 1463 ED-68 deleted 1465 ED-69 There can be a case where the session signaling path is lost, 1466 and the user agent does not receive the BYE. If the call is hung up, 1467 and the session timer (if implemented) expires, the call MAY be 1468 declared lost. If in the interval, an incoming call is received from 1469 the domain of the PSAP, the device MUST drop the old call and alert 1470 for the (new) incoming call. Dropping of the old call MUST only 1471 occur if the user is attempting to hang up; the domain of an incoming 1472 call can only be determined from the From header, which is not 1473 reliable, and could be spoofed. Dropping an active call by a new 1474 call with a spoofed From: would be a DoS attack. 1476 ED-70 User Agents and proxies MUST disable features that will 1477 interrupt an ongoing emergency call, such as: 1479 o Call Waiting 1480 o Call Transfer 1481 o Three Way Call 1482 o Hold 1483 o Outbound Call Blocking 1484 when an emergency call is established. Also see ED-77 in Section 14. 1486 ED-71 The emergency dial strings SHOULD NOT be permitted in Call 1487 Forward numbers or speed dial lists. 1489 ED-72 The User Agent and Proxies MUST disable call features which 1490 would interfere with the ability of call backs from the PSAP to be 1491 completed such as: 1492 o Do Not Disturb 1493 o Call Forward (all kinds) 1495 ED-73 Call backs SHOULD be determined by retaining the domain of the 1496 PSAP which answers an outgoing emergency call and instantiating a 1497 timer which starts when the call is terminated. If a call is 1498 received from the same domain and within the timer period, sent to 1499 the Contact: or AoR used in the emergency call, it should be assumed 1500 to be a call back. The suggested timer period is 5 minutes. 1501 [RFC4916] may be used by the PSAP to inform the UA of the domain of 1502 the PSAP. Recognizing a call back from the domain of the PSAP will 1503 not always work, and further standardization will be required to give 1504 the UA the ability to recognize a call back. 1506 ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. 1508 ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 1509 agree on the media streams to be used. 1511 ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law 1512 if they are intended be used in North America) encoded voice as 1513 described in [RFC3551]. It is desirable to include wideband codecs 1514 such as AMR-WB in the offer. 1516 ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT 1517 be used on emergency calls. PSAP call takers sometimes get 1518 information on what is happening in the background to determine how 1519 to process the call. 1521 ED-78 Endpoints supporting Instant Messaging (IM) MUST support both 1522 [RFC3428] and [RFC4975]. 1524 ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The 1525 expectations for emergency service support for the real-time text 1526 medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. 1528 ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. 1530 ED-81 INVITE requests to a service URN ending in ".test" indicates a 1531 request for an automated test. For example, 1532 "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response 1533 indicates that the address was recognized and a 404 (Not found) that 1534 it was not. A 486 (Busy Here) MUST be returned if the test service 1535 is busy, and a 404 (Not Found) MUST be returned if the PSAP does not 1536 support the test mechanism. 1538 ED-82 In its response to the test, the PSAP MAY include a text body 1539 (text/plain) indicating the identity of the PSAP, the requested 1540 service, and the location reported with the call. For the latter, 1541 the PSAP SHOULD return location-by-value even if the original 1542 location delivered with the test was by-reference. If the location- 1543 by-reference was supplied, and the dereference requires credentials, 1544 the PSAP SHOULD use credentials supplied by the LIS for test 1545 purposes. This alerts the LIS that the dereference is not for an 1546 actual emergency call and location hiding techniques, if they are 1547 being used, may be employed for this dereference. Use of SIPS for 1548 the request would assure the response containing the location is kept 1549 private. 1551 ED-83 A PSAP accepting a test call SHOULD accept a media loopback 1552 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 1553 pkt-loopback" and "rtp-start-loopback" options. The user agent would 1554 specify a loopback attribute of "loopback-source", the PSAP being the 1555 mirror. User Agents should expect the PSAP to loop back no more than 1556 3 packets of each media type accepted (which limits the duration of 1557 the test), after which the PSAP would normally send BYE. 1559 ED-84 User agents SHOULD perform a full call test, including media 1560 loopback, after a disconnect and subsequent change in IP address not 1561 due to a reboot. After an initial test, a full test SHOULD be 1562 repeated approximately every 30 days with a random interval. 1564 ED-85 User agents MUST NOT place a test call immediately after 1565 booting. If the IP address changes after booting, the UA should wait 1566 a random amount of time (in perhaps a 30 minute period, sufficient 1567 for any avalanche restart to complete) and then test. 1569 ED-86 PSAPs MAY refuse repeated requests for test from the same 1570 device in a short period of time. Any refusal is signaled with a 486 1571 or 488 response. 1573 A.2. Requirements of Service Providers 1575 SP-1 If a device or application expects to be able to place a call 1576 for help, the service provider that supports it MUST facilitate 1577 emergency calling. Some jurisdictions have regulations governing 1578 this. 1580 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 1581 some reason the endpoint does not recognize them. This cannot be 1582 relied upon by the device if the service provider cannot always 1583 determine the location of the device. 1585 SP-3 Emergency calls MUST be marked with a Service URN in the 1586 Request-URI of the INVITE. 1588 SP-4 Local dial strings MUST be recognized. 1590 SP-5 Devices MUST be able to be configured with the home country from 1591 which the home dial string(s) can be determined. 1593 SP-6 Emergency dial strings SHOULD be determined from LoST [RFC5222]. 1594 Dial Strings MAY be configured directly in the device. 1596 SP-7 If a proxy server recognizes dial strings on behalf of its 1597 clients it MUST recognize emergency dial strings represented by 1598 [RFC4967] and SHOULD recognize emergency dial strings represented by 1599 a tel URI [RFC3966]. 1601 SP-8 Service providers MAY provide home dial strings by 1602 configuration. 1604 SP-9 All emergency services specified in [RFC5031] MUST be 1605 recognized. 1607 SP-10 Endpoints, Intermediate Devices and Service Providers MUST be 1608 prepared to handle location represented in either civic or geo form. 1610 SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from 1611 the form of location the determination mechanism supplied. 1613 SP-12 Proxies MAY provide location on behalf of devices if: 1614 o The proxy has a relationship with all access networks the device 1615 could connect to, and the relationship allows it to obtain 1616 location. 1617 o The proxy has an identifier, such as an IP address, that can be 1618 used by the access network to determine the location of the 1619 endpoint, even in the presence of NAT and VPN tunnels that may 1620 obscure the identifier between the access network and the service 1621 provider. 1623 SP-13 Where proxies provide location on behalf of endpoints, the 1624 service provider MUST ensure that either the end device is provided 1625 with the local dial strings for its current location (where the end 1626 device recognizes dial strings), or the service provider proxy MUST 1627 detect the appropriate local dial strings at the time of the call. 1629 SP-14 When HELD is the LCP, the request MUST specify a value of 1630 "emergencyRouting" for the "responseTime" parameter and use the 1631 resulting location for routing. If a value for dispatch location 1632 will be sent, another request with the "responseTime" parameter set 1633 to "emergencyDispatch" must be completed, with the result sent for 1634 dispatch purposes. 1636 SP-15 Location sent between SIP elements MUST be conveyed using 1637 [I-D.ietf-sip-location-conveyance]. 1639 SP-16 If the LIS has more than one location for an endpoint it MUST 1640 use the procedures in [RFC5491] 1642 SP-17 If a proxy inserts location on behalf of an endpoint, and it 1643 has multiple locations available for the endpoint it MUST choose one 1644 location to use to route the call towards the PSAP. 1646 SP-18 If a proxy is attempting to insert location but the UA conveyed 1647 a location to it, the proxy MUST use the UA's location for routing 1648 and MUST convey that location towards the PSAP. It MAY also include 1649 what it believes the location to be in a separate Geolocation header. 1651 SP-19 All location objects received by a proxy MUST be delivered to 1652 the PSAP. 1654 SP-20 Location objects MUST contain information about the method by 1655 which the location was determined, such as GPS, manually entered, or 1656 based on access network topology included in a PIDF- LO "method" 1657 element. In addition, the source of the location information MUST be 1658 included in a PIDF-LO "provided-by" element. 1660 SP-21 The "used-for-routing" parameter MUST be set to the location 1661 that was chosen for routing. 1663 SP-22 Proxies handling emergency calls MUST insert a default location 1664 if the call does not contain a location and the proxy does not have a 1665 method for obtaining a better location. 1667 SP-23 Default locations MUST be marked with method=Default and the 1668 proxy MUST be identified in provided-by element of the PIDF-LO. 1670 SP-24 TLS MUST be used to protect location (but see Section 9.1). 1671 IPSEC [RFC3986] is an acceptable alternative. 1673 SP-25 Service Providers MUST provide an SRV entry in their DNS server 1674 which leads to a LoST server 1676 SP-26 Networks MUST be designed so that at least one proxy in the 1677 outbound path will recognize emergency calls with a Request URI of 1678 the service URN in the "sos" tree. An endpoint places a service URN 1679 in the Request URI to indicate that the endpoint understood the call 1680 was an emergency call. A proxy that processes such a call looks for 1681 the presence of a SIP Route header field with a URI of a PSAP. 1682 Absence of such a Route header indicates the UAC was unable to invoke 1683 LoST and the proxy MUST perform the LoST mapping and insert a Route 1684 header field with the URI obtained. 1686 SP-27 To deal with old user agents that predate this specification 1687 and with UAs that do not have access to their own location data, a 1688 proxy that recognizes a call as an emergency call that is not marked 1689 as such (see Section 5) MUST also perform this mapping, with the best 1690 location it has available for the endpoint. The resulting PSAP URI 1691 would be placed in a Route header with the service URN in the Request 1692 URI. 1694 SP-28 Proxy servers performing mapping SHOULD use location obtained 1695 from the access network for the mapping. If no location is 1696 available, a default location (see Section 6.11) MUST be supplied. 1698 SP-29 A proxy server which attempts mapping and fails to get a 1699 mapping MUST provide a default mapping. A suitable default mapping 1700 would be the mapping obtained previously for the default location 1701 appropriate for the caller. 1703 SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an 1704 emergency call towards the PSAP's URI. 1706 SP-31 TLS MUST be specified when attempting to signal an emergency 1707 call with SIP. IPSEC [RFC3986] is an acceptable alternative. 1709 SP-32 If TLS session establishment is not available, or fails, the 1710 call MUST be retried without TLS. 1712 SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS connections 1713 between elements. 1715 SP-34 SIP Proxy servers processing emergency calls: 1717 1. If the proxy interprets dial plans on behalf of user agents, the 1718 proxy MUST look for the local emergency dial string at the 1719 location of the end device and MAY look for the home dial string. 1720 If it finds it, the proxy MUST: 1721 * Insert a Geolocation header as above. Location-by-reference 1722 MUST be used because proxies must not insert bodies. 1723 * Include the Geolocation "inserted-by" and "used-for-routing" 1724 parameters with its own hostname (which should match the Via 1725 it inserts) on the inserted-by. 1726 * Map the location to a PSAP URI using LoST. 1727 * Add a Route header with the PSAP URI. 1728 * Replace the Request-URI (which was the dial string) with the 1729 service URN appropriate for the emergency dial string. 1730 * Route the call using normal SIP routing mechanisms. 1731 2. If the proxy recognizes the service URN in the Request URI, and 1732 does not find a a Route header, it MUST query a LoST server. If 1733 multiple locations were provided, the proxy uses the location 1734 that has the "used-for-routing" marker set. If a location was 1735 provided (which should be the case), the proxy uses that location 1736 to query LoST. The proxy may have to dereference a location by 1737 reference to get a value. If a location is not present, and the 1738 proxy can query a LIS which has the location of the UA it MUST do 1739 so. If no location is present, and the proxy does not have 1740 access to a LIS which could provide location, the proxy MUST 1741 supply a default location (See Section 6.11). The location (in 1742 the signaling, obtained from a LIS, or default) MUST be used in a 1743 query to LoST with the service URN received with the call. The 1744 resulting URI MUST be placed in a Route header added to the call. 1745 3. The "inserted-by" parameter in any Geolocation: header received 1746 on the call MUST NOT be modified or deleted in transit. 1747 4. The proxy SHOULD NOT modify any parameters in Geolocation headers 1748 received in the call. It MAY add a Geolocation header. Such an 1749 additional location SHOULD NOT be used for routing; the location 1750 provided by the UA should be used. 1751 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 1752 [RFC4474], or both, SHOULD be included to identify the sender. 1753 For services which must support emergency calls from 1754 unauthenticated devices, valid identity may not be available. 1756 SP-35 Devices device SHOULD have a globally routable URI in a 1757 Contact: header which remains valid for 30 minutes past the time the 1758 original call containing the URI completes unless the device 1759 registration expires and is not renewed. 1761 SP-36 Call backs to the Contact: header URI recieved within 30 1762 minutes of an emergency call must reach the device regardless of call 1763 features or services that would normally cause the call to be routed 1764 to some other entity. 1766 SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- 1767 Identity: header or From: protected by an Identity header suitable 1768 for returning a call some time after the original call. Such a call 1769 back would not necessarily reach the device that originally placed 1770 the call. 1772 SP-38 During the course of an emergency call, devices and proxies 1773 MUST support REFER transactions with method=INVITE and the 1774 Referred-by: header [RFC3515] in that transaction. 1776 SP-39 User Agents and proxies MUST disable features that will 1777 interrupt an ongoing emergency call, such as: 1778 o Call Waiting 1779 o Call Transfer 1780 o Three Way Call 1781 o Hold 1782 o Outbound Call Blocking 1783 when an emergency call is established. Also see ED-77 in Section 14. 1785 SP-40 The emergency dial strings SHOULD NOT be permitted in Call 1786 Forward numbers or speed dial lists. 1788 SP-41 The User Agent and Proxies MUST disable call features which 1789 would interfere with the ability of call backs from the PSAP to be 1790 completed such as: 1791 o Do Not Disturb 1792 o Call Forward (all kinds) 1794 A.3. Requirements of Access Network 1796 AN-1 LoST servers MUST return dial strings for emergency services 1798 AN-2 Elements MUST NOT convert (civic to geo or geo to civic) from 1799 the form of location the determination mechanism supplied. 1801 AN-3 Any suitable location determination mechanism MAY be used. 1803 AN-4 Devices, intermediate Devices and/or access networks SHOULD 1804 support a manual method to "override" the location the access network 1805 determines. Where a civic form of location is provided, all fields 1806 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1808 AN-5 Access networks supporting copper, fiber or other hard wired IP 1809 packet service SHOULD support location configuration. If the network 1810 does not support location configuration, it MUST require every device 1811 that connects to the network to support end system measured location. 1813 AN-6 Access networks and intermediate devices providing wire database 1814 location information SHOULD provide interior location data (building, 1815 floor, room, cubicle) where possible. It is RECOMMENDED that 1816 interior location be provided when spaces exceed approximately 650 1817 square meters. 1819 AN-7 Access networks and intermediate devices (including enterprise 1820 networks) which support intermediate range wireless connections 1821 (typically 100m or less of range) and which do not support a more 1822 accurate location determination mechanism such as triangulation, MUST 1823 support location configuration where the location of the access point 1824 is reflected as the location of the clients of that access point. 1825 Where the access network provides location configuration, 1826 intermediate devices MUST either be transparent to it, or provide an 1827 interconnected client for the supported configuration mechanism and a 1828 server for a configuration protocol supported by end devices 1829 downstream of the intermediate device 1831 AN-8 Devices that support endpoint measuring of location MUST have at 1832 least a coarse location capability (typically <1km accuracy when not 1833 location hiding) for routing of calls. The location mechanism MAY be 1834 a service provided by the access network. 1836 AN-9 Access networks MAY provide network-measured location 1837 determination. Wireless access network which do not support network 1838 measured location MUST require that all devices connected to the 1839 network have end-system measured location. Uncertainty of less than 1840 100 m with 95% confidence SHOULD be available for dispatch. 1842 AN-10 Access networks that provide network measured location MUST 1843 have at least a coarse location (typically <1km when not location 1844 hiding) capability at all times for routing of calls. 1846 AN-11 Access networks with range of <10 meters (e.g. personnal area 1847 networks such as Bluetooth MUST provide a location to mobile devices 1848 connected to them. The location provided SHOULD be that of the 1849 access point location unless a more accurate mechanism is provided. 1851 AN-12 The access network MUST support either DHCP location options or 1852 HELD. The access network SHOULD support other location technologies 1853 that are specific to the type of access network. 1855 AN-13 Where a router is employed between a LAN and WAN in a small 1856 (less than approximately 650 square meters) area, the router MUST be 1857 transparent to the location provided by the WAN to the LAN. This may 1858 mean the router must obtain location as a client from the WAN, and 1859 supply an LCP server to the LAN with the location it obtains. Where 1860 the area is larger, the LAN MUST have a location configuration 1861 mechanism meeting this BCP. 1863 AN-14 Access networks that support more than one LCP MUST reply with 1864 the same location information (within the limits of the data format 1865 for the specific LCP) for all LCPs it supports. 1867 AN-15 Network administrators MUST take care in assigning IP addresses 1868 such that VPN address assignments can be distinguished from local 1869 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 1870 to provide location to addresses that arrive via VPN connections 1871 unless it can accurately determine the location for such addresses. 1873 AN-16 Placement of NAT devices where an LCP uses IP address for an 1874 identifier SHOULD consider the effect of the NAT on the LCP. The 1875 address used to query the LIS MUST be able to correctly identify the 1876 record in the LIS representing the location of the querying device 1878 AN-17 It is RECOMMENDED that location determination not take longer 1879 than 250 ms to obtain routing location and systems SHOULD be designed 1880 such that the typical response is under 100 ms. However, as much as 1881 3 seconds to obtain routing location MAY be tolerated if location 1882 accuracy can be substantially improved over what can be obtained in 1883 250 ms. 1885 AN-18 Where the absolute location or the accuracy of location of the 1886 endpoint may change between the time the call is received at the PSAP 1887 and the time dispatch is completed, location update mechanisms MUST 1888 be provided. 1890 AN-19 Mobile devices MUST be provided with a mechanism to get 1891 repeated location updates to track the motion of the device during 1892 the complete processing of the call. 1894 AN-20 The LIS SHOULD provide a location reference which permits a 1895 subscription with appropriate filtering. 1897 AN-21 For calls sent with location-by-reference, with a SIP or SIPS 1898 scheme, the server resolving the reference MUST support a SUBSCRIBE 1899 [RFC3265] to the presence event [RFC3856]. For other location-by- 1900 reference schemes that do not support subscription, the PSAP will 1901 have to repeatedly dereference the URI to determine if the device 1902 moved. 1904 AN-22 A LIS should perform location validation of civic locations via 1905 LoST before entering a location in its database. 1907 AN-23 When the access network cannot determine the actual location of 1908 the caller, it MUST supply a default location. The default SHOULD be 1909 chosen to be as close to the probable location of the device as the 1910 network can determine. See [I-D.ietf-ecrit-framework] 1911 AN-24 Default locations MUST be marked with method=Default and the 1912 proxy MUST be identified in provided-by element of the PIDF-LO. 1914 AN-25 To prevent against spoofing of the DHCP server, elements 1915 implementing DHCP for location configuration SHOULD use [RFC3118] 1916 although the difficulty in providing appropriate credentials is 1917 significant. 1919 AN-26 Access networks which support DHCP MUST implement the LoST 1920 discovery option 1922 AN-27 Access Networks that use HELD and that have a DHCP server 1923 SHOULD support DHCP options for providing LIS and LoST servers. 1925 AN-28 TLS MUST be specified when attempting to retrieve location 1926 (configuration or dereferencing) with HELD. The use of [RFC5077] is 1927 RECOMMENDED to minimize the time to establish TLS sessions without 1928 keeping server-side state. 1930 AN-29 If TLS session establishment fails, the location retrieval MUST 1931 be retried without TLS. 1933 A.4. Requirements of Intermediate Devices 1935 INT-1 Endpoints, Intermediate Devices and Service Providers MUST be 1936 prepared to handle location represented in either civic or geo form. 1938 INT-2 Elements MUST NOT convert (civic to geo or geo to civic) from 1939 the form of location the determination mechanism supplied. 1941 INT-3 Any suitable location determination mechanism MAY be used. 1943 INT-4 Devices, intermediate Devices and/or access networks SHOULD 1944 support a manual method to "override" the location the access network 1945 determines. Where a civic form of location is provided, all fields 1946 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1948 INT-5 Access networks and intermediate devices providing wire 1949 database location information SHOULD provide interior location data 1950 (building, floor, room, cubicle) where possible. It is RECOMMENDED 1951 that interior location be provided when spaces exceed approximately 1952 650 square meters. 1954 INT-6 Access networks and intermediate devices (including enterprise 1955 networks) which support intermediate range wireless connections 1956 (typically 100m or less of range) and which do not support a more 1957 accurate location determination mechanism such as triangulation, MUST 1958 support location configuration where the location of the access point 1959 is reflected as the location of the clients of that access point. 1960 Where the access network provides location configuration, 1961 intermediate devices MUST either be transparent to it, or provide an 1962 interconnected client for the supported configuration mechanism and a 1963 server for a configuration protocol supported by end devices 1964 downstream of the intermediate device 1966 INT-7 Devices MAY support end-system measured location. Uncertainty 1967 of less than 100 m with 95% confidence SHOULD be available for 1968 dispatch. 1970 INT-8 Devices that support endpoint measuring of location MUST have 1971 at least a coarse location capability (typically <1km accuracy when 1972 not location hiding) for routing of calls. The location mechanism 1973 MAY be a service provided by the access network. 1975 INT-9 Endpoints SHOULD attempt to configure their own location using 1976 the LCPs listed in ED-21. 1978 INT-10 Where proxies provide location on behalf of endpoints, the 1979 service provider MUST ensure that either the end device is provided 1980 with the local dial strings for its current location (where the end 1981 device recognizes dial strings), or the service provider proxy MUST 1982 detect the appropriate local dial strings at the time of the call. 1984 INT-11 Devices SHOULD be able to accept and forward location by value 1985 or by reference. An end device that receives location by reference 1986 (and does not also get the corresponding value) MUST be able to 1987 perform a dereference operation to obtain a value. 1989 INT-12 Devices MUST support both the DHCP location options [RFC4776], 1990 [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When 1991 devices deploy a specific access network interface in which that 1992 access network supports location discovery such as LLDP-MED or 1993 802.11v, the device SHOULD support the additional respective access 1994 network specific location discovery mechanism. 1996 INT-13 The access network MUST support either DHCP location options 1997 or HELD. The access network SHOULD support other location 1998 technologies that are specific to the type of access network. 2000 INT-14 Where a router is employed between a LAN and WAN in a small 2001 (less than approximately 650 square meters) area, the router MUST be 2002 transparent to the location provided by the WAN to the LAN. This may 2003 mean the router must obtain location as a client from the WAN, and 2004 supply an LCP server to the LAN with the location it obtains. Where 2005 the area is larger, the LAN MUST have a location configuration 2006 mechanism meeting this BCP. 2008 INT-15 Endpoints SHOULD try all LCPs supported by the device in any 2009 order or in parallel. The first one that succeeds in supplying 2010 location can be used. 2012 INT-16 Access networks that support more than one LCP MUST reply with 2013 the same location information (within the limits of the data format 2014 for the specific LCP) for all LCPs it supports. 2016 INT-17 When HELD is the LCP, the request MUST specify a value of 2017 "emergencyRouting" for the "responseTime" parameter and use the 2018 resulting location for routing. If a value for dispatch location 2019 will be sent, another request with the "responseTime" parameter set 2020 to "emergencyDispatch" must be completed, with the result sent for 2021 dispatch purposes. 2023 INT-18 Endpoints SHOULD obtain location immediately after obtaining 2024 local network configuration information. When HELD is the LCP the 2025 client MUST support a random back-off period (between 30 seconds and 2026 300 seconds) for re-trying the HELD query, when no response is 2027 received, and no other LCP provided location information. 2029 INT-19 If the device is configured to use DHCP for bootstrapping, it 2030 MUST include both options for location acquisition (civic and 2031 geodetic), the option for LIS discovery, and the option for LoST 2032 discovery as defined in [RFC4776], [RFC3825], 2033 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 2035 INT-20 If the device sends a DHCPINFORM message, it MUST include both 2036 options for location acquisition (civic and geodetic), the option for 2037 LIS discovery, and the option for LoST discovery as defined in 2038 [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 2040 INT-21 To minimize the effects of VPNs that do not allow packets to 2041 be sent via the native hardware interface rather than via the VPN 2042 tunnel, location configuration SHOULD be attempted before such 2043 tunnels are established. 2045 INT-22 Software which uses LCPs SHOULD locate and use the actual 2046 hardware network interface rather than a VPN tunnel interface to 2047 direct LCP requests to the LIS in the actual access network. 2049 INT-23 For devices which are not expected to roam, refreshing 2050 location on the order of once per day is RECOMMENDED. 2052 INT-24 For devices which roam, refresh of location information SHOULD 2053 be more frequent, with the frequency related to the mobility of the 2054 device and the ability of the access network to support the refresh 2055 operation. If the device can detect that it has moved, for example 2056 when it changes access points, the device SHOULD refresh its 2057 location. 2059 INT-25 It is RECOMMENDED that location determination not take longer 2060 than 250 ms to obtain routing location and systems SHOULD be designed 2061 such that the typical response is under 100 ms. However, as much as 2062 3 seconds to obtain routing location MAY be tolerated if location 2063 accuracy can be substantially improved over what can be obtained in 2064 250 ms. 2066 Authors' Addresses 2068 Brian Rosen 2069 NeuStar 2070 470 Conrad Dr. 2071 Mars, PA 16046 2072 US 2074 Phone: +1 724 382 1051 2075 Email: br@brianrosen.net 2077 James Polk 2078 Cisco Systems 2079 3913 Treemont Circle 2080 Colleyville, TX 76034 2081 US 2083 Phone: +1-817-271-3552 2084 Email: jmpolk@cisco.com