idnits 2.17.00 (12 Aug 2021) /tmp/idnits53372/draft-ietf-ecrit-phonebcp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2009) is 4698 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) == Unused Reference: 'LLDP' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'LLDP-MED' is defined on line 961, but no explicit reference was found in the text == 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 == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: draft-ietf-sip-outbound has been published as RFC 5626 -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** 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) == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 6 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: January 10, 2010 Cisco Systems 6 July 9, 2009 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-12 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 10, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The IETF and other standards organization have efforts targeted at 49 standardizing various aspects of placing emergency calls on IP 50 networks. This memo describes best current practice on how devices, 51 networks and services should use such standards to make emergency 52 calls. 54 Table of Contents 56 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview of how emergency calls are placed . . . . . . . . . . 4 59 4. Which devices and services should support emergency calls . . 5 60 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 61 6. Location and its role in an emergency call . . . . . . . . . . 6 62 6.1. Types of location information . . . . . . . . . . . . . . 6 63 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 64 6.2.1. User-entered location information . . . . . . . . . . 7 65 6.2.2. Access network "wire database" location information . 7 66 6.2.3. End-system measured location information . . . . . . . 7 67 6.2.4. Network-measured location information . . . . . . . . 8 68 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 69 6.4. Location and references to location . . . . . . . . . . . 8 70 6.5. End system location configuration . . . . . . . . . . . . 9 71 6.6. When location should be configured . . . . . . . . . . . . 10 72 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11 73 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 74 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 75 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 76 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 77 6.12. Other location considerations . . . . . . . . . . . . . . 13 78 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 79 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 80 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 81 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9.2. SIP signaling requirements for User Agents . . . . . . . . 15 83 9.3. SIP signaling requirements for proxy servers . . . . . . . 17 84 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 86 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 87 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 88 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 93 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 95 19.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25 98 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25 99 A.2. Requirements of Service Providers . . . . . . . . . . . . 34 100 A.3. Requirements of Access Network . . . . . . . . . . . . . . 39 101 A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 104 1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This document uses terms from [RFC3261], [RFC5012] and 111 [I-D.ietf-ecrit-framework]. 113 2. Introduction 115 This document describes how access networks, SIP user agents, proxy 116 servers and PSAPs support emergency calling, as outlined in 117 [I-D.ietf-ecrit-framework], which is designed to complement the 118 present document in section headings, numbering and content. This 119 BCP succinctly describes the requirements of end devices and 120 applications (requirements prefaced by "ED-"), access networks 121 (including enterprise access networks) (requirements prefaced by 122 "AN-", service providers (requirements prefaced by "SP-") and PSAPs 123 to achieve globally interoperable emergency calling on the Internet. 125 This document also defines requirements for "Intermediate" devices 126 which exist between end devices or applications and the access 127 network. For example, a home router is an "Intermediate" device. 128 Reporting location on an emergency call (see Section 6) may depend on 129 the ability of such intermediate devices to meet the requirements 130 prefaced by "INT-". 132 3. Overview of how emergency calls are placed 134 An emergency call can be distinguished (Section 5) from any other 135 call by a unique Service URN [RFC5031], which is placed in the call 136 set-up signaling when a home or visited emergency dial string is 137 detected. Because emergency services are local to specific 138 geographic regions, a caller must obtain his location (Section 6) 139 prior to making emergency calls. To get this location, either a form 140 of measuring (e.g., GPS) (Section 6.2.3) device location in the 141 endpoint is deployed, or the endpoint is configured (Section 6.5) 142 with its location from the access network's Location Information 143 Server (LIS). The location is conveyed (Section 6.7) in the SIP 144 signaling with the call. The call is routed (Section 8) based on 145 location using the LoST protocol [RFC5222], which maps a location to 146 a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency 147 Services Routing Proxy (ESRP), which serves a group of PSAPs. The 148 call arrives at the PSAP with the location included in the SIP INVITE 149 request. 151 4. Which devices and services should support emergency calls 153 ED-1 A device or application SHOULD support emergency calling if a 154 user could reasonably expect to be able to place a call for help with 155 the device. Some jurisdictions have regulations governing this. 157 SP-1 If a device or application expects to be able to place a call 158 for help, the service provider that supports it MUST facilitate 159 emergency calling. Some jurisdictions have regulations governing 160 this. 162 ED-2 Devices that create media sessions and exchange audio, video 163 and/or text, and have the capability to establish sessions to a wide 164 variety of addresses, and communicate over private IP networks or the 165 Internet, SHOULD support emergency calls. Some jurisdictions have 166 regulations governing this. 168 5. Identifying an emergency call 170 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 171 the service provider always knows the location of the device, then 172 the service provider could recognize them. 174 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 175 some reason the endpoint does not recognize them. This cannot be 176 relied upon by the device if the service provider cannot always 177 determine the location of the device. 179 ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the 180 Request-URI of the INVITE. 182 ED-5/SP-4 Local dial strings MUST be recognized. 184 ED-6/SP-5 Devices MUST be able to be configured with the home country 185 from which the home dial string(s) can be determined. 187 ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST 188 [RFC5222]. Dial Strings MAY be configured directly in the device. 190 AN-1 LoST servers MUST return dial strings for emergency services 192 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 193 send dial strings as per [RFC4967]. 195 SP-7 If a proxy server recognizes dial strings on behalf of its 196 clients it MUST recognize emergency dial strings represented by 197 [RFC4967] and SHOULD recognize emergency dial strings represented by 198 a tel URI [RFC3966]. 200 ED-9 Endpoints SHOULD be able to have home dial strings provisioned. 202 SP-8 Service providers MAY provision home dial strings in devices. 204 ED-10 Devices SHOULD NOT have one button emergency calling 205 initiation. 207 ED-11/SP-9 All emergency services specified in [RFC5031] MUST be 208 recognized. 210 6. Location and its role in an emergency call 212 Handling location for emergency calling usually involves several 213 steps to process and multiple elements are involved. In Internet 214 emergency calling, where the endpoint is located is "determined" 215 using a variety of measurement or wiretracing methods. Endpoints may 216 be "configured" with their own location by the access network. In 217 some circumstances, a proxy server may insert location into the 218 signaling on behalf of the endpoint. The location is "mapped" to the 219 URI to send the call to, and the location is "conveyed" to the PSAP 220 (and other elements) in the signaling. Likewise, we employ Location 221 Configuration Protocols, the Location-to-Service Mapping Protocol, 222 and Location Conveyance Protocols for these functions. The Location- 223 to-Service Translation protocol [RFC5222] is the Location Mapping 224 Protocol defined by the IETF. 226 6.1. Types of location information 228 There are several forms of location. In IETF location configuration 229 and location conveyance protocols, civic and geospatial (geo) forms 230 are both supported. The civic forms include both postal and 231 jurisdictional fields. A cell tower/sector can be represented as a 232 point (geo or civic) or polygon. Other forms of location 233 representation must be mapped into either a geo or civic for use in 234 emergency calls. 236 ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service 237 Providers MUST be prepared to handle location represented in either 238 civic or geo form. 240 ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo 241 to civic) from the form of location the determination mechanism 242 supplied. 244 6.2. Location Determination 246 ED-14/INT-3/AN-3 Any suitable location determination mechanism MAY be 247 used. 249 6.2.1. User-entered location information 251 ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks 252 SHOULD support a manual method to "override" the location the access 253 network determines. Where a civic form of location is provided, all 254 fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be 255 specified. 257 6.2.2. Access network "wire database" location information 259 AN-5 Access networks supporting copper, fiber or other hard wired IP 260 packet service SHOULD support location configuration. If the network 261 does not support location configuration, it MUST require every device 262 that connects to the network to support end system measured location. 264 AN-6/INT-5 Access networks and intermediate devices providing wire 265 database location information SHOULD provide interior location data 266 (building, floor, room, cubicle) where possible. It is RECOMMENDED 267 that interior location be provided when spaces exceed approximately 268 650 square meters. 270 AN-7/INT-6 Access networks and intermediate devices (including 271 enterprise networks) which support intermediate range wireless 272 connections (typically 100m or less of range) and which do not 273 support a more accurate location determination mechanism such as 274 triangulation, MUST support location configuration where the location 275 of the access point is reflected as the location of the clients of 276 that access point. Where the access network provides location 277 configuration, intermediate devices MUST either be transparent to it, 278 or provide an interconnected client for the supported configuration 279 mechanism and a server for a configuration protocol supported by end 280 devices downstream of the intermediate device 282 6.2.3. End-system measured location information 284 ED-16/INT-7 Devices MAY support end-system measured location. 285 Uncertainty of less than 100 m with 95% confidence SHOULD be 286 available for dispatch. 288 ED-17/INT-8/AN-8 Devices that support endpoint measuring of location 289 MUST have at least a coarse location capability (typically <1km 290 accuracy when not location hiding) for routing of calls. The 291 location mechanism MAY be a service provided by the access network. 293 6.2.4. Network-measured location information 295 AN-9 Access networks MAY provide network-measured location 296 determination. Wireless access network which do not support network 297 measured location MUST require that all devices connected to the 298 network have end-system measured location. Uncertainty of less than 299 100 m with 95% confidence SHOULD be available for dispatch. 301 AN-10 Access networks that provide network measured location MUST 302 have at least a coarse location (typically <1km when not location 303 hiding) capability at all times for routing of calls. 305 AN-11 Access networks with range of <10 meters (e.g. personal area 306 networks such as Bluetooth MUST provide a location to mobile devices 307 connected to them. The location provided SHOULD be that of the 308 access point location unless a more accurate mechanism is provided. 310 6.3. Who adds location, endpoint or proxy 312 ED-18/INT-9 Endpoints SHOULD attempt to configure their own location 313 using the LCPs listed in ED-21. 315 SP-12 Proxies MAY provide location on behalf of devices if: 316 o The proxy has a relationship with all access networks the device 317 could connect to, and the relationship allows it to obtain 318 location. 319 o The proxy has an identifier, such as an IP address, that can be 320 used by the access network to determine the location of the 321 endpoint, even in the presence of NAT and VPN tunnels that may 322 obscure the identifier between the access network and the service 323 provider. 325 ED-19/INT-10/SP-13 Where proxies provide location on behalf of 326 endpoints, the service provider MUST ensure that either the end 327 device is provided with the local dial strings for its current 328 location (where the end device recognizes dial strings), or the 329 service provider proxy MUST detect the appropriate local dial strings 330 at the time of the call. 332 6.4. Location and references to location 334 ED-20/INT-11 Devices SHOULD be able to accept and forward location by 335 value or by reference. An end device that receives location by 336 reference (and does not also get the corresponding value) MUST be 337 able to perform a dereference operation to obtain a value. 339 6.5. End system location configuration 341 ED-21/INT-12 Devices MUST support both the DHCP location options 342 [RFC4776], [RFC3825] and HELD 343 [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a 344 specific access network interface in which that access network 345 supports location discovery such as LLDP-MED or 802.11v, the device 346 SHOULD support the additional respective access network specific 347 location discovery mechanism. 349 AN-12/INT-13 The access network MUST support either DHCP location 350 options or HELD. The access network SHOULD support other location 351 technologies that are specific to the type of access network. 353 AN-13/INT-14 Where a router is employed between a LAN and WAN in a 354 small (less than approximately 650 square meters) area, the router 355 MUST be transparent to the location provided by the WAN to the LAN. 356 This may mean the router must obtain location as a client from the 357 WAN, and supply an LCP server to the LAN with the location it 358 obtains. Where the area is larger, the LAN MUST have a location 359 configuration mechanism meeting this BCP. 361 ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in 362 any order or in parallel. The first one that succeeds in supplying 363 location can be used. 365 AN-14/INT-16 Access networks that support more than one LCP MUST 366 reply with the same location information (within the limits of the 367 data format for the specific LCP) for all LCPs it supports. 369 ED-23/INT-17/SP-14 When HELD is the LCP, the request MUST specify a 370 value of "emergencyRouting" for the "responseTime" parameter and use 371 the resulting location for routing. If a value for dispatch location 372 will be sent, another request with the "responseTime" parameter set 373 to "emergencyDispatch" must be completed, with the result sent for 374 dispatch purposes. 376 ED-24 Where the operating system supporting application programs 377 which need location for emergency calls does not allow access to 378 Layer 2 and Layer 3 functions necessary for a client application to 379 use DHCP location options and/or LLDP-MED, the operating system MUST 380 provide a published API conforming to ED-12 through ED-21 and ED-21 381 through ED-31. It is RECOMMENDED that all operating systems provide 382 such an API. 384 6.6. When location should be configured 386 ED-25/INT-18 Endpoints SHOULD obtain location immediately after 387 obtaining local network configuration information. When HELD is the 388 LCP the client MUST support a random back-off period (between 30 389 seconds and 300 seconds) for re-trying the HELD query, when no 390 response is received, and no other LCP provided location information. 392 ED-26/INT-19 If the device is configured to use DHCP for 393 bootstrapping, it MUST include both options for location acquisition 394 (civic and geodetic), the option for LIS discovery, and the option 395 for LoST discovery as defined in [RFC4776], [RFC3825], 396 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 398 ED-27/INT-20 If the device sends a DHCPINFORM message, it MUST 399 include both options for location acquisition (civic and geodetic), 400 the option for LIS discovery, and the option for LoST discovery as 401 defined in [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and 402 [RFC5223]. 404 ED-28/INT-21 To minimize the effects of VPNs that do not allow 405 packets to be sent via the native hardware interface rather than via 406 the VPN tunnel, location configuration SHOULD be attempted before 407 such tunnels are established. 409 ED-29/INT-22 Software which uses LCPs SHOULD locate and use the 410 actual hardware network interface rather than a VPN tunnel interface 411 to direct LCP requests to the LIS in the actual access network. 413 AN-15 Network administrators MUST take care in assigning IP addresses 414 such that VPN address assignments can be distinguished from local 415 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 416 to provide location to addresses that arrive via VPN connections 417 unless it can accurately determine the location for such addresses. 419 AN-16 Placement of NAT devices where an LCP uses IP address for an 420 identifier SHOULD consider the effect of the NAT on the LCP. The 421 address used to query the LIS MUST be able to correctly identify the 422 record in the LIS representing the location of the querying device 424 ED-30/INT-23 For devices which are not expected to roam, refreshing 425 location on the order of once per day is RECOMMENDED. 427 ED-31/INT-24 For devices which roam, refresh of location information 428 SHOULD be more frequent, with the frequency related to the mobility 429 of the device and the ability of the access network to support the 430 refresh operation. If the device can detect that it has moved, for 431 example when it changes access points, the device SHOULD refresh its 432 location. 434 ED-32/INT-25/AN-17 It is RECOMMENDED that location determination not 435 take longer than 250 ms to obtain routing location and systems SHOULD 436 be designed such that the typical response is under 100 ms. However, 437 as much as 3 seconds to obtain routing location MAY be tolerated if 438 location accuracy can be substantially improved over what can be 439 obtained in 250 ms. 441 6.7. Conveying location in SIP 443 ED-33/SP-15 Location sent between SIP elements MUST be conveyed using 444 [I-D.ietf-sip-location-conveyance]. 446 6.8. Location updates 448 ED-34/AN-18 Where the absolute location or the accuracy of location 449 of the endpoint may change between the time the call is received at 450 the PSAP and the time dispatch is completed, location update 451 mechanisms MUST be provided. 453 ED-35/AN-19 Mobile devices MUST be provided with a mechanism to get 454 repeated location updates to track the motion of the device during 455 the complete processing of the call. 457 ED-36/AN-20 The LIS SHOULD provide a location reference which permits 458 a subscription with appropriate filtering. 460 ED-37/AN-21 For calls sent with location-by-reference, with a SIP or 461 SIPS scheme, the server resolving the reference MUST support a 462 SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other 463 location-by-reference schemes that do not support subscription, the 464 PSAP will have to repeatedly dereference the URI to determine if the 465 device moved. 467 ED-38 If location was sent by value, and the endpoint gets updated 468 location, it MUST send the updated location to the PSAP via a SIP re- 469 INVITE or UPDATE request. Such updates SHOULD be limited to no more 470 than one update every 10 seconds. 472 6.9. Multiple locations 474 ED-39/SP-16 If the LIS has more than one location for an endpoint it 475 MUST use the procedures in [RFC5491] 477 ED-40 If a UA has more than one location available to it, it MUST 478 choose one location to route the call towards the PSAP. If multiple 479 locations are in a single PIDF, the procedures in [RFC5491] MUST be 480 followed. If the UA has multiple PIDFs, and has no reasonable basis 481 to choose from among them, a random choice is acceptable. 483 SP-17 If a proxy inserts location on behalf of an endpoint, and it 484 has multiple locations available for the endpoint it MUST choose one 485 location to use to route the call towards the PSAP. 487 SP-18 If a proxy is attempting to insert location but the UA conveyed 488 a location to it, the proxy MUST use the UA's location for routing 489 and MUST convey that location towards the PSAP. It MAY also include 490 what it believes the location to be in a separate Geolocation header. 492 SP-19 All location objects received by a proxy MUST be delivered to 493 the PSAP. 495 ED-41/SP-20 Location objects MUST contain information about the 496 method by which the location was determined, such as GPS, manually 497 entered, or based on access network topology included in a PIDF- LO 498 "method" element. In addition, the source of the location 499 information MUST be included in a PIDF-LO "provided-by" element. 501 ED-??/SP-?? A location with a method of "derived" MUST NOT be used 502 unless no other location is available. 504 ED-42/SP-21 The "used-for-routing" parameter MUST be set to the 505 location that was chosen for routing. 507 6.10. Location validation 509 AN-22 A LIS should perform location validation of civic locations via 510 LoST before entering a location in its database. 512 ED-43 Endpoints SHOULD validate civic locations when they receive 513 them from their LCP. Validation SHOULD be performed in conjunction 514 with the LoST route query to minimize load on the LoST server. 516 6.11. Default location 518 AN-23 When the access network cannot determine the actual location of 519 the caller, it MUST supply a default location. The default SHOULD be 520 chosen to be as close to the probable location of the device as the 521 network can determine. See [I-D.ietf-ecrit-framework] 523 SP-22 Proxies handling emergency calls MUST insert a default location 524 if the call does not contain a location and the proxy does not have a 525 method for obtaining a better location. 527 AN-24/SP-23 Default locations MUST be marked with method=Default and 528 the proxy MUST be identified in provided-by element of the PIDF-LO. 530 6.12. Other location considerations 532 ED-44 If the LCP does not return location in the form of a PIDF-LO 533 [RFC4119], the endpoint MUST map the location information it receives 534 from the configuration protocol to a PIDF-LO. 536 ED-45/AN-25 To prevent against spoofing of the DHCP server, elements 537 implementing DHCP for location configuration SHOULD use [RFC3118] 538 although the difficulty in providing appropriate credentials is 539 significant. 541 ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header 542 or bodies. 544 ED-47/SP-24 TLS MUST be used to protect location (but see 545 Section 9.1). IPSEC [RFC3986] is an acceptable alternative. 547 7. LIS and LoST Discovery 549 ED-48 Endpoints MUST support one or more mechanisms that allow them 550 to determine their public IP address. Examples include STUN 551 [RFC3489] and HTTP get. 553 ED-49 Endpoints MUST support LIS discovery as described in 554 [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described 555 in [RFC5223]. 557 ED-50 The device MUST have a configurable default LoST server 558 parameter. If the device is provided by or managed by a service 559 provider, it is expected that the service provider will configure 560 this option. 562 ED-51 DHCP LoST discovery MUST be used, if available, in preference 563 to configured LoST servers. If neither DHCP nor configuration leads 564 to an available LoST server, the device MUST query DNS using it's SIP 565 domain for an SRV record for a LoST service and use that server. 567 AN-26 Access networks which support DHCP MUST implement the LoST 568 discovery option 570 SP-25 Service Providers MUST provide an SRV entry in their DNS server 571 which leads to a LoST server 573 AN-27 Access Networks that use HELD and that have a DHCP server 574 SHOULD support DHCP options for providing LIS and LoST servers. 576 ED-52 When an endpoint has obtained a LoST server via an discovery 577 mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered 578 LoST server over LoST servers configured by other means. That is, 579 the endpoint MUST send queries to this LoST server first, using other 580 LoST servers only if these queries fail. 582 8. Routing the call to the PSAP 584 ED-53 Endpoints who obtain their own location SHOULD perform LoST 585 mapping to the PSAP URI. 587 ED-54 Mapping SHOULD be performed at boot time and whenever location 588 changes beyond the service boundary obtained from a prior LoST 589 mapping operation or the time-to-live value of that response has 590 expired. The value MUST be cached for possible later use. 592 ED-55 The endpoint MUST attempt to update its location at the time of 593 an emergency call. If it cannot obtain a new location quickly (see 594 Section 6), it MUST use the cached value. 596 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 597 time of an emergency call. If it cannot obtain a new mapping 598 quickly, it MUST use the cached value. If the device cannot update 599 the LoST mapping and does not have a cached value, it MUST signal an 600 emergency call without a Route header containing a PSAP URI. 602 SP-26 Networks MUST be designed so that at least one proxy in the 603 outbound path will recognize emergency calls with a Request URI of 604 the service URN in the "sos" tree. An endpoint places a service URN 605 in the Request URI to indicate that the endpoint understood the call 606 was an emergency call. A proxy that processes such a call looks for 607 the presence of a SIP Route header field with a URI of a PSAP. 608 Absence of such a Route header indicates the UAC was unable to invoke 609 LoST and the proxy MUST perform the LoST mapping and insert a Route 610 header field with the URI obtained. 612 SP-27 To deal with old user agents that predate this specification 613 and with UAs that do not have access to their own location data, a 614 proxy that recognizes a call as an emergency call that is not marked 615 as such (see Section 5) MUST also perform this mapping, with the best 616 location it has available for the endpoint. The resulting PSAP URI 617 would be placed in a Route header with the service URN in the Request 618 URI. 620 SP-28 Proxy servers performing mapping SHOULD use location obtained 621 from the access network for the mapping. If no location is 622 available, a default location (see Section 6.11) MUST be supplied. 624 SP-29 A proxy server which attempts mapping and fails to get a 625 mapping MUST provide a default mapping. A suitable default mapping 626 would be the mapping obtained previously for the default location 627 appropriate for the caller. 629 ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route 630 an emergency call towards the PSAP's URI. 632 ED-58 Initial INVITES MUST provide an Offer [RFC3264]. 634 9. Signaling of emergency calls 636 ED-59 deleted 638 9.1. Use of TLS 640 ED-60/SP-31 TLS MUST be specified when attempting to signal an 641 emergency call. IPSEC [RFC3986] is an acceptable alternative. 643 ED-61/SP-32 If TLS session establishment is not available, or fails, 644 the call MUST be retried without TLS. 646 ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain 647 persistent TLS connections between elements. 649 ED-63/AN-28 TLS MUST be specified when attempting to retrieve 650 location (configuration or dereferencing) with HELD. The use of 651 [RFC5077] is RECOMMENDED to minimize the time to establish TLS 652 sessions without keeping server-side state. 654 ED-64/AN-29 If TLS session establishment fails, the location 655 retrieval MUST be retried without TLS. 657 9.2. SIP signaling requirements for User Agents 659 ED-65 The initial SIP signaling method is an INVITE request: 660 1. The Request URI SHOULD be the service URN in the "sos" tree, If 661 the device cannot interpret local dial strings, the Request-URI 662 SHOULD be a dial string URI [RFC4967] with the dialed digits. 663 2. The To header SHOULD be a service URN in the "sos" tree. If the 664 device cannot interpret local dial strings, the To: SHOULD be a 665 dial string URI with the dialed digits. 666 3. The From header MUST be present and SHOULD be the AoR of the 667 caller. 668 4. A Via header MUST be present. 670 5. A Route header SHOULD be present with a PSAP URI obtained from 671 LoST (see Section 8) and the loose route parameter. If the 672 device does not interpret dial plans, or was unable to obtain a 673 route from a LoST server, no Route header will be present. 674 6. A Contact header MUST be present which MUST be globally 675 routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid 676 for several minutes following the termination of the call, 677 provided that the UAC remains registered with the same 678 registrar, to permit an immediate call-back to the specific 679 device which placed the emergency call. It is acceptable if the 680 UAC inserts a locally routable URI and a subsequent B2BUA maps 681 that to a globally routable URI. 682 7. Other headers MAY be included as per normal SIP behavior. 683 8. A Supported header MUST be included with the 'geolocation' 684 option tag [I-D.ietf-sip-location-conveyance], unless the device 685 does not understand the concept of SIP location. 686 9. If a device understands the SIP location conveyance 687 [I-D.ietf-sip-location-conveyance] extension and has its 688 location available, it MUST include location either by-value, 689 by-reference or both. 690 10. If a device understands the SIP Location Conveyance extension 691 and has its location unavailable or unknown to that device, it 692 MUST include a Supported header with a "geolocation" option tag, 693 and MUST NOT include a Geolocation header, and not include a 694 PIDF-LO message body. 695 11. If a device understands the SIP Location Conveyance extension 696 and supports LoST [RFC5222], the Geolocation "used-for-routing" 697 header parameter MUST be added to the corresponding URI in the 698 Geolocation header. If the device is unable to obtain a PSAP 699 URI for any reason it MUST NOT include "used-for-routing" on a 700 Geolocation URI, so that downstream entities know that LoST 701 routing has not been completed. 702 12. A SDP offer MUST be included in the INVITE. If voice is 703 supported the offer MUST include the G.711 codec, see 704 Section 14. 705 13. If the device includes location-by-value, the UA MUST support 706 multipart message bodies, since SDP will likely be also in the 707 INVITE. 708 14. A UAC SHOULD include a "inserted-by" header parameter with its 709 own hostname on all Geolocation headers. This informs 710 downstream elements which device entered the location at this 711 URI (either cid-URL or location-by-reference URI). 712 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 713 PSAP should handle the call. For example, a language preference 714 expressed in an Accept-Language header may be used as a hint to 715 cause the PSAP to route the call to a call taker who speaks the 716 requested language. SIP Caller Preferences may also be used to 717 indicate a need to invoke a relay service for communication with 718 people with disabilities in the call. 720 9.3. SIP signaling requirements for proxy servers 722 SP-34 SIP Proxy servers processing emergency calls: 723 1. If the proxy interprets dial plans on behalf of user agents, the 724 proxy MUST look for the local emergency dial string at the 725 location of the end device and MAY look for the home dial string. 726 If it finds it, the proxy MUST: 727 * Insert a Geolocation header as above. Location-by-reference 728 MUST be used because proxies must not insert bodies. 729 * Include the Geolocation "inserted-by" and "used-for-routing" 730 parameters with its own hostname (which should match the Via 731 it inserts) on the inserted-by. 732 * Map the location to a PSAP URI using LoST. 733 * Add a Route header with the PSAP URI. 734 * Replace the Request-URI (which was the dial string) with the 735 service URN appropriate for the emergency dial string. 736 * Route the call using normal SIP routing mechanisms. 737 2. If the proxy recognizes the service URN in the Request URI, and 738 does not find a a Route header, it MUST query a LoST server. If 739 multiple locations were provided, the proxy uses the location 740 that has the "used-for-routing" marker set. If a location was 741 provided (which should be the case), the proxy uses that location 742 to query LoST. The proxy may have to dereference a location by 743 reference to get a value. If a location is not present, and the 744 proxy can query a LIS which has the location of the UA it MUST do 745 so. If no location is present, and the proxy does not have 746 access to a LIS which could provide location, the proxy MUST 747 supply a default location (See Section 6.11). The location (in 748 the signaling, obtained from a LIS, or default) MUST be used in a 749 query to LoST with the service URN received with the call. The 750 resulting URI MUST be placed in a Route header added to the call. 751 3. The "inserted-by" parameter in any Geolocation: header received 752 on the call MUST NOT be modified or deleted in transit. 753 4. The proxy SHOULD NOT modify any parameters in Geolocation headers 754 received in the call. It MAY add a Geolocation header. Such an 755 additional location SHOULD NOT be used for routing; the location 756 provided by the UA should be used. 757 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 758 [RFC4474], or both, SHOULD be included to identify the sender. 759 For services which must support emergency calls from 760 unauthenticated devices, valid identity may not be available. 762 10. Call backs 764 ED-66/SP-35 Devices device SHOULD have a globally routable URI in a 765 Contact: header which remains valid for 30 minutes past the time the 766 original call containing the URI completes unless the device 767 registration expires and is not renewed. 769 SP-36 Call backs to the Contact: header URI recieved within 30 770 minutes of an emergency call must reach the device regardless of call 771 features or services that would normally cause the call to be routed 772 to some other entity. 774 SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- 775 Identity: header or From: protected by an Identity header suitable 776 for returning a call some time after the original call. Such a call 777 back would not necessarily reach the device that originally placed 778 the call. 780 11. Mid-call behavior 782 ED-67/SP-38 During the course of an emergency call, devices and 783 proxies MUST support REFER transactions with method=INVITE and the 784 Referred-by: header [RFC3515] in that transaction. 786 12. Call termination 788 ED-68 deleted 790 ED-69 There can be a case where the session signaling path is lost, 791 and the user agent does not receive the BYE. If the call is hung up, 792 and the session timer (if implemented) expires, the call MAY be 793 declared lost. If in the interval, an incoming call is received from 794 the domain of the PSAP, the device MUST drop the old call and alert 795 for the (new) incoming call. Dropping of the old call MUST only 796 occur if the user is attempting to hang up; the domain of an incoming 797 call can only be determined from the From header, which is not 798 reliable, and could be spoofed. Dropping an active call by a new 799 call with a spoofed From: would be a DoS attack. 801 13. Disabling of features 803 ED-70/SP-39 User Agents and proxies MUST disable features that will 804 interrupt an ongoing emergency call, such as: 805 o Call Waiting 806 o Call Transfer 807 o Three Way Call 808 o Hold 809 o Outbound Call Blocking 810 when an emergency call is established. Also see ED-77 in Section 14. 812 ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in 813 Call Forward numbers or speed dial lists. 815 ED-72/SP-41 The User Agent and Proxies MUST disable call features 816 which would interfere with the ability of call backs from the PSAP to 817 be completed such as: 818 o Do Not Disturb 819 o Call Forward (all kinds) 821 ED-73 Call backs SHOULD be determined by retaining the domain of the 822 PSAP which answers an outgoing emergency call and instantiating a 823 timer which starts when the call is terminated. If a call is 824 received from the same domain and within the timer period, sent to 825 the Contact: or AoR used in the emergency call, it should be assumed 826 to be a call back. The suggested timer period is 5 minutes. 827 [RFC4916] may be used by the PSAP to inform the UA of the domain of 828 the PSAP. Recognizing a call back from the domain of the PSAP will 829 not always work, and further standardization will be required to give 830 the UA the ability to recognize a call back. 832 14. Media 834 ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. 836 ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 837 agree on the media streams to be used. 839 ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law 840 if they are intended be used in North America) encoded voice as 841 described in [RFC3551]. It is desirable to include wideband codecs 842 such as AMR-WB in the offer. 844 ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT 845 be used on emergency calls. PSAP call takers sometimes get 846 information on what is happening in the background to determine how 847 to process the call. 849 ED-78 Endpoints supporting Instant Messaging (IM) MUST support both 850 [RFC3428] and [RFC4975]. 852 ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The 853 expectations for emergency service support for the real-time text 854 medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. 856 ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. 858 15. Testing 860 ED-81 INVITE requests to a service URN ending in ".test" indicates a 861 request for an automated test. For example, 862 "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response 863 indicates that the address was recognized and a 404 (Not found) that 864 it was not. A 486 (Busy Here) MUST be returned if the test service 865 is busy, and a 404 (Not found) MUST be returned if the PSAP does not 866 support the test mechanism. 868 ED-82 In its response to the test, the PSAP MAY include a text body 869 (text/plain) indicating the identity of the PSAP, the requested 870 service, and the location reported with the call. For the latter, 871 the PSAP SHOULD return location-by-value even if the original 872 location delivered with the test was by-reference. If the location- 873 by-reference was supplied, and the dereference requires credentials, 874 the PSAP SHOULD use credentials supplied by the LIS for test 875 purposes. This alerts the LIS that the dereference is not for an 876 actual emergency call and location hiding techniques, if they are 877 being used, may be employed for this dereference. Use of SIPS for 878 the request would assure the response containing the location is kept 879 private 881 ED-83 A PSAP accepting a test call SHOULD accept a media loopback 882 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 883 pkt-loopback" and "rtp-start-loopback" options. The user agent would 884 specify a loopback attribute of "loopback-source", the PSAP being the 885 mirror. User Agents should expect the PSAP to loop back no more than 886 3 packets of each media type accepted (which limits the duration of 887 the test), after which the PSAP would normally send BYE. 889 ED-84 User agents SHOULD perform a full call test, including media 890 loopback, after a disconnect and subsequent change in IP address not 891 due to a reboot. After an initial test, a full test SHOULD be 892 repeated approximately every 30 days with a random interval. 894 ED-85 User agents MUST NOT place a test call immediately after 895 booting. If the IP address changes after booting, the UA should wait 896 a random amount of time (in perhaps a 30 minute period, sufficient 897 for any avalanche restart to complete) and then test. 899 ED-86 PSAPs MAY refuse repeated requests for test from the same 900 device in a short period of time. Any refusal is signaled with a 486 901 or 488 response. 903 16. Security Considerations 905 Security considerations for emergency calling have been documented in 906 [RFC5069], and [I-D.barnes-geopriv-lo-sec]. 908 17. IANA Considerations 910 This document has no actions for IANA. 912 18. Acknowledgements 914 Work group members participating in the creation and review of this 915 document include include Hannes Tschofenig, Ted Hardie, Marc Linsner, 916 Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, 917 Barbara Stark, Richard Barnes and Peter Blatherwick. 919 19. References 921 19.1. Normative References 923 [I-D.ietf-geopriv-http-location-delivery] 924 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 925 "HTTP Enabled Location Delivery (HELD)", 926 draft-ietf-geopriv-http-location-delivery-15 (work in 927 progress), June 2009. 929 [I-D.ietf-geopriv-lis-discovery] 930 Thomson, M. and J. Winterbottom, "Discovering the Local 931 Location Information Server (LIS)", 932 draft-ietf-geopriv-lis-discovery-11 (work in progress), 933 May 2009. 935 [I-D.ietf-mmusic-media-loopback] 936 Venna, N., Jones, P., Roychowdhury, A., and K. Hedayat, 937 "An Extension to the Session Description Protocol (SDP) 938 for Media Loopback", draft-ietf-mmusic-media-loopback-10 939 (work in progress), February 2009. 941 [I-D.ietf-sip-gruu] 942 Rosenberg, J., "Obtaining and Using Globally Routable User 943 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 944 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 945 October 2007. 947 [I-D.ietf-sip-location-conveyance] 948 Polk, J. and B. Rosen, "Location Conveyance for the 949 Session Initiation Protocol", 950 draft-ietf-sip-location-conveyance-13 (work in progress), 951 March 2009. 953 [I-D.ietf-sip-outbound] 954 Jennings, C., "Managing Client Initiated Connections in 955 the Session Initiation Protocol (SIP)", 956 draft-ietf-sip-outbound-20 (work in progress), June 2009. 958 [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", 959 Dec 2004. 961 [LLDP-MED] 962 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 963 Endpoint Discovery". 965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 966 Requirement Levels", BCP 14, RFC 2119, March 1997. 968 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 969 Messages", RFC 3118, June 2001. 971 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 972 A., Peterson, J., Sparks, R., Handley, M., and E. 973 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 974 June 2002. 976 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 977 Protocol (SIP): Locating SIP Servers", RFC 3263, 978 June 2002. 980 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 981 with Session Description Protocol (SDP)", RFC 3264, 982 June 2002. 984 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 985 Event Notification", RFC 3265, June 2002. 987 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 988 and D. Gurle, "Session Initiation Protocol (SIP) Extension 989 for Instant Messaging", RFC 3428, December 2002. 991 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 992 "STUN - Simple Traversal of User Datagram Protocol (UDP) 993 Through Network Address Translators (NATs)", RFC 3489, 994 March 2003. 996 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 997 Method", RFC 3515, April 2003. 999 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1000 Jacobson, "RTP: A Transport Protocol for Real-Time 1001 Applications", STD 64, RFC 3550, July 2003. 1003 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1004 Video Conferences with Minimal Control", STD 65, RFC 3551, 1005 July 2003. 1007 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1008 Configuration Protocol Option for Coordinate-based 1009 Location Configuration Information", RFC 3825, July 2004. 1011 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1012 Preferences for the Session Initiation Protocol (SIP)", 1013 RFC 3841, August 2004. 1015 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1016 Initiation Protocol (SIP)", RFC 3856, August 2004. 1018 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1019 RFC 3966, December 2004. 1021 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 1022 M., and D. Singer, "RTP Payload Format for H.264 Video", 1023 RFC 3984, February 2005. 1025 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1026 Resource Identifier (URI): Generic Syntax", STD 66, 1027 RFC 3986, January 2005. 1029 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1030 Conversation", RFC 4103, June 2005. 1032 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1033 Format", RFC 4119, December 2005. 1035 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1036 Authenticated Identity Management in the Session 1037 Initiation Protocol (SIP)", RFC 4474, August 2006. 1039 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1040 (DHCPv4 and DHCPv6) Option for Civic Addresses 1041 Configuration Information", RFC 4776, November 2006. 1043 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1044 Protocol (SIP)", RFC 4916, June 2007. 1046 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1047 Initiation Protocol Uniform Resource Identifier", 1048 RFC 4967, July 2007. 1050 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1051 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1053 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1054 Emergency and Other Well-Known Services", RFC 5031, 1055 January 2008. 1057 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1058 Format for Presence Information Data Format Location 1059 Object (PIDF-LO)", RFC 5139, February 2008. 1061 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1062 Tschofenig, "LoST: A Location-to-Service Translation 1063 Protocol", RFC 5222, August 2008. 1065 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1066 Location-to-Service Translation (LoST) Servers Using the 1067 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1068 August 2008. 1070 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1071 Presence Information Data Format Location Object (PIDF-LO) 1072 Usage Clarification, Considerations, and Recommendations", 1073 RFC 5491, March 2009. 1075 19.2. Informative References 1077 [I-D.barnes-geopriv-lo-sec] 1078 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1079 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1080 Location and Location Privacy in Internet Applications", 1081 draft-barnes-geopriv-lo-sec-05 (work in progress), 1082 March 2009. 1084 [I-D.ietf-ecrit-framework] 1085 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1086 "Framework for Emergency Calling using Internet 1087 Multimedia", draft-ietf-ecrit-framework-09 (work in 1088 progress), March 2009. 1090 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1091 Extensions to the Session Initiation Protocol (SIP) for 1092 Asserted Identity within Trusted Networks", RFC 3325, 1093 November 2002. 1095 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1096 Emergency Context Resolution with Internet Technologies", 1097 RFC 5012, January 2008. 1099 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1100 Shanmugam, "Security Threats and Requirements for 1101 Emergency Call Marking and Mapping", RFC 5069, 1102 January 2008. 1104 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1105 "Transport Layer Security (TLS) Session Resumption without 1106 Server-Side State", RFC 5077, January 2008. 1108 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 1109 over IP Using the Session Initiation Protocol (SIP)", 1110 RFC 5194, June 2008. 1112 Appendix A. BCP Requirements Sorted by Responsible Party 1114 A.1. Requirements of End Devices 1116 ED-1 A device or application SHOULD support emergency calling if a 1117 user could reasonably expect to be able to place a call for help with 1118 the device. Some jurisdictions have regulations governing this. 1120 ED-2 Devices that create media sessions and exchange audio, video 1121 and/or text, and have the capability to establish sessions to a wide 1122 variety of addresses, and communicate over private IP networks or the 1123 Internet, SHOULD support emergency calls. Some jurisdictions have 1124 regulations governing this. 1126 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 1127 the service provider always knows the location of the device, then 1128 the service provider could recognize them. 1130 ED-4 Emergency calls MUST be marked with a Service URN in the 1131 Request-URI of the INVITE. 1133 ED-5 Local dial strings MUST be recognized. 1135 ED-6 Devices MUST be able to be configured with the home country from 1136 which the home dial string(s) can be determined. 1138 ED-7 Emergency dial strings SHOULD be determined from LoST [RFC5222]. 1140 Dial Strings MAY be configured directly in the device. 1142 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 1143 send dial strings as per [RFC4967]. 1145 ED-9 Endpoints SHOULD be able to have home dial strings provisioned 1146 by configuration. 1148 ED-10 Devices SHOULD NOT have one button emergency calling 1149 initiation. 1151 ED-11 All emergency services specified in [RFC5031] MUST be 1152 recognized. 1154 ED-12 Endpoints, Intermediate Devices and Service Providers MUST be 1155 prepared to handle location represented in either civic or geo form. 1157 ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from 1158 the form of location the determination mechanism supplied. 1160 ED-14 Any suitable location determination mechanism MAY be used. 1162 ED-15 Devices, intermediate Devices and/or access networks SHOULD 1163 support a manual method to "override" the location the access network 1164 determines. Where a civic form of location is provided, all fields 1165 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1167 ED-16 Devices MAY support end-system measured location. Uncertainty 1168 of less than 100 m with 95% confidence SHOULD be available for 1169 dispatch. 1171 ED-17 Devices that support endpoint measuring of location MUST have 1172 at least a coarse location capability (typically <1km accuracy when 1173 not location hiding) for routing of calls. The location mechanism 1174 MAY be a service provided by the access network. 1176 ED-18 Endpoints SHOULD attempt to configure their own location using 1177 the LCPs listed in ED-21. 1179 ED-19 Where proxies provide location on behalf of endpoints, the 1180 service provider MUST ensure that either the end device is provided 1181 with the local dial strings for its current location (where the end 1182 device recognizes dial strings), or the service provider proxy MUST 1183 detect the appropriate local dial strings at the time of the call. 1185 ED-20 Devices SHOULD be able to accept and forward location by value 1186 or by reference. An end device that receives location by reference 1187 (and does not also get the corresponding value) MUST be able to 1188 perform a dereference operation to obtain a value. 1190 ED-21 Devices MUST support both the DHCP location options [RFC4776], 1191 [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When 1192 devices deploy a specific access network interface in which that 1193 access network supports location discovery such as LLDP-MED or 1194 802.11v, the device SHOULD support the additional respective access 1195 network specific location discovery mechanism. 1197 ED-22 Endpoints SHOULD try all LCPs supported by the device in any 1198 order or in parallel. The first one that succeeds in supplying 1199 location can be used. 1201 ED-23 When HELD is the LCP, the request MUST specify a value of 1202 "emergencyRouting" for the "responseTime" parameter and use the 1203 resulting location for routing. If a value for dispatch location 1204 will be sent, another request with the "responseTime" parameter set 1205 to "emergencyDispatch" must be completed, with the result sent for 1206 dispatch purposes. 1208 ED-24 Where the operating system supporting application programs 1209 which need location for emergency calls does not allow access to 1210 Layer 2 and Layer 3 functions necessary for a client application to 1211 use DHCP location options and/or LLDP-MED, the operating system MUST 1212 provide a published API conforming to ED-12 through ED-21 and ED-21 1213 through ED-31. It is RECOMMENDED that all operating systems provide 1214 such an API. 1216 ED-25 Endpoints SHOULD obtain location immediately after obtaining 1217 local network configuration information. When HELD is the LCP the 1218 client MUST support a random back-off period (between 30 seconds and 1219 300 seconds) for re-trying the HELD query, when no response is 1220 received, and no other LCP provided location information. 1222 ED-26 If the device is configured to use DHCP for bootstrapping, it 1223 MUST include both options for location acquisition (civic and 1224 geodetic), the option for LIS discovery, and the option for LoST 1225 discovery as defined in [RFC4776], [RFC3825], 1226 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 1228 ED-27 If the device sends a DHCPINFORM message, it MUST include both 1229 options for location acquisition (civic and geodetic), the option for 1230 LIS discovery, and the option for LoST discovery as defined in 1231 [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 1233 ED-28 To minimize the effects of VPNs that do not allow packets to be 1234 sent via the native hardware interface rather than via the VPN 1235 tunnel, location configuration SHOULD be attempted before such 1236 tunnels are established. 1238 ED-29 Software which uses LCPs SHOULD locate and use the actual 1239 hardware network interface rather than a VPN tunnel interface to 1240 direct LCP requests to the LIS in the actual access network. 1242 ED-30 For devices which are not expected to roam, refreshing location 1243 on the order of once per day is RECOMMENDED. 1245 ED-31 For devices which roam, refresh of location information SHOULD 1246 be more frequent, with the frequency related to the mobility of the 1247 device and the ability of the access network to support the refresh 1248 operation. If the device can detect that it has moved, for example 1249 when it changes access points, the device SHOULD refresh its 1250 location. 1252 ED-32 It is RECOMMENDED that location determination not take longer 1253 than 250 ms to obtain routing location and systems SHOULD be designed 1254 such that the typical response is under 100 ms. However, as much as 1255 3 seconds to obtain routing location MAY be tolerated if location 1256 accuracy can be substantially improved over what can be obtained in 1257 250 ms. 1259 ED-33 Location sent between SIP elements MUST be conveyed using 1260 [I-D.ietf-sip-location-conveyance]. 1262 ED-34 Where the absolute location or the accuracy of location of the 1263 endpoint may change between the time the call is received at the PSAP 1264 and the time dispatch is completed, location update mechanisms MUST 1265 be provided. 1267 ED-35 Mobile devices MUST be provided with a mechanism to get 1268 repeated location updates to track the motion of the device during 1269 the complete processing of the call. 1271 ED-36 The LIS SHOULD provide a location reference which permits a 1272 subscription with appropriate filtering. 1274 ED-37 For calls sent with location-by-reference, with a SIP or SIPS 1275 scheme, the server resolving the reference MUST support a SUBSCRIBE 1276 [RFC3265] to the presence event [RFC3856]. For other location-by- 1277 reference schemes that do not support subscription, the PSAP will 1278 have to repeatedly dereference the URI to determine if the device 1279 moved. 1281 ED-38 If location was sent by value, and the endpoint gets updated 1282 location, it MUST send the updated location to the PSAP via a SIP re- 1283 INVITE or UPDATE request. Such updates SHOULD be limited to no more 1284 than one update every 10 seconds. 1286 ED-39 If the LIS has more than one location for an endpoint it MUST 1287 use the procedures in [RFC5491] 1289 ED-40 If a UA has more than one location available to it, it MUST 1290 choose one location to route the call towards the PSAP. If multiple 1291 locations are in a single PIDF, the procedures in [RFC5491] MUST be 1292 followed. If the UA has multiple PIDFs, and has no reasonable basis 1293 to choose from among them, a random choice is acceptable. 1295 ED-41 Location objects MUST contain information about the method by 1296 which the location was determined, such as GPS, manually entered, or 1297 based on access network topology included in a PIDF- LO "method" 1298 element. In addition, the source of the location information MUST be 1299 included in a PIDF-LO "provided-by" element. 1301 ED-42 The "used-for-routing" parameter MUST be set to the location 1302 that was chosen for routing. 1304 ED-43 Endpoints SHOULD validate civic locations when they receive 1305 them from their LCP. Validation SHOULD be performed in conjunction 1306 with the LoST route query to minimize load on the LoST server. 1308 ED-44 If the LCP does not return location in the form of a PIDF-LO 1309 [RFC4119], the endpoint MUST map the location information it receives 1310 from the configuration protocol to a PIDF-LO. 1312 ED-45 To prevent against spoofing of the DHCP server, elements 1313 implementing DHCP for location configuration SHOULD use [RFC3118] 1314 although the difficulty in providing appropriate credentials is 1315 significant. 1317 ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header 1318 or bodies. 1320 ED-47 TLS MUST be used to protect location (but see Section 9.1). 1321 IPSEC [RFC3986] is an acceptable alternative. 1323 ED-48 Endpoints MUST support one or more mechanisms that allow them 1324 to determine their public IP address. Examples include STUN 1325 [RFC3489] and HTTP get. 1327 ED-49 Endpoints MUST support LIS discovery as described in 1328 [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described 1329 in [RFC5223]. 1331 ED-50 The device MUST have a configurable default LoST server 1332 parameter. If the device is provided by or managed by a service 1333 provider, it is expected that the service provider will configure 1334 this option. 1336 ED-51 DHCP LoST discovery MUST be used, if available, in preference 1337 to configured LoST servers. If neither DHCP nor configuration leads 1338 to an available LoST server, the device MUST query DNS using it's SIP 1339 domain for an SRV record for a LoST service and use that server. 1341 ED-52 When an endpoint has obtained a LoST server via an discovery 1342 mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered 1343 LoST server over LoST servers configured by other means. That is, 1344 the endpoint MUST send queries to this LoST server first, using other 1345 LoST servers only if these queries fail. 1347 ED-53 Endpoints who obtain their own location SHOULD perform LoST 1348 mapping to the PSAP URI. 1350 ED-54 Mapping SHOULD be performed at boot time and whenever location 1351 changes beyond the service boundary obtained from a prior LoST 1352 mapping operation or the time-to-live value of that response has 1353 expired. The value MUST be cached for possible later use. 1355 ED-55 The endpoint MUST attempt to update its location at the time of 1356 an emergency call. If it cannot obtain a new location quickly (see 1357 Section 6), it MUST use the cached value. 1359 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 1360 time of an emergency call. If it cannot obtain a new mapping 1361 quickly, it MUST use the cached value. If the device cannot update 1362 the LoST mapping and does not have a cached value, it MUST signal an 1363 emergency call without a Route header containing a PSAP URI. 1365 ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an 1366 emergency call towards the PSAP's URI. 1368 ED-58 Initial INVITES MUST provide an Offer [RFC3264]. 1370 ED-59 deleted 1372 ED-60 TLS MUST be specified when attempting to signal an emergency 1373 call with SIP. IPSEC [RFC3986] is an acceptable alternative. 1375 ED-61 If TLS session establishment is not available, or fails, the 1376 call MUST be retried without TLS. 1378 ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent 1379 TLS connections between elements. 1381 ED-63 TLS MUST be specified when attempting to retrieve location 1382 (configuration or dereferencing) with HELD. The use of [RFC5077] is 1383 RECOMMENDED to minimize the time to establish TLS sessions without 1384 keeping server-side state. 1386 ED-64 If TLS session establishment fails, the location retrieval MUST 1387 be retried without TLS. 1389 ED-65 The initial SIP signaling method is an INVITE request: 1390 1. The Request URI SHOULD be the service URN in the "sos" tree, If 1391 the device cannot interpret local dial strings, the Request-URI 1392 SHOULD be a dial string URI [RFC4967] with the dialed digits. 1393 2. The To header SHOULD be a service URN in the "sos" tree. If the 1394 device cannot interpret local dial strings, the To: SHOULD be a 1395 dial string URI with the dialed digits. 1396 3. The From header MUST be present and SHOULD be the AoR of the 1397 caller. 1398 4. A Via header MUST be present. 1399 5. A Route header SHOULD be present with a PSAP URI obtained from 1400 LoST (see Section 8) and the loose route parameter. If the 1401 device does not interpret dial plans, or was unable to obtain a 1402 route from a LoST server, no Route header will be present. 1403 6. A Contact header MUST be present which MUST be globally 1404 routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid 1405 for several minutes following the termination of the call, 1406 provided that the UAC remains registered with the same 1407 registrar, to permit an immediate call-back to the specific 1408 device which placed the emergency call. It is acceptable if the 1409 UAC inserts a locally routable URI and a subsequent B2BUA maps 1410 that to a globally routable URI. 1411 7. Other headers MAY be included as per normal SIP behavior. 1412 8. A Supported header MUST be included with the 'geolocation' 1413 option tag [I-D.ietf-sip-location-conveyance], unless the device 1414 does not understand the concept of SIP location. 1415 9. If a device understands the SIP location conveyance 1416 [I-D.ietf-sip-location-conveyance] extension and has its 1417 location available, it MUST include location either by-value, 1418 by-reference or both. 1419 10. If a device understands the SIP Location Conveyance extension 1420 and has its location unavailable or unknown to that device, it 1421 MUST include a Supported header with a "geolocation" option tag, 1422 and MUST NOT include a Geolocation header, and not include a 1423 PIDF-LO message body. 1424 11. If a device understands the SIP Location Conveyance extension 1425 and supports LoST [RFC5222], the Geolocation "used-for-routing" 1426 header parameter MUST be added to the corresponding URI in the 1427 Geolocation header. If the device is unable to obtain a PSAP 1428 URI for any reason it MUST NOT include "used-for-routing" on a 1429 Geolocation URI, so that downstream entities know that LoST 1430 routing has not been completed. 1431 12. A SDP offer MUST be included in the INVITE. If voice is 1432 supported the offer MUST include the G.711 codec, see 1433 Section 14. 1434 13. If the device includes location-by-value, the UA MUST support 1435 multipart message bodies, since SDP will likely be also in the 1436 INVITE. 1437 14. A UAC SHOULD include a "inserted-by" header parameter with its 1438 own hostname on all Geolocation headers. This informs 1439 downstream elements which device entered the location at this 1440 URI (either cid-URL or location-by-reference URI). 1441 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 1442 PSAP should handle the call. For example, a language preference 1443 expressed in an Accept-Language header may be used as a hint to 1444 cause the PSAP to route the call to a call taker who speaks the 1445 requested language. SIP Caller Preferences may also be used to 1446 indicate a need to invoke a relay service for communication with 1447 people with disabilities in the call. 1449 ED-66 Devices device SHOULD have a globally routable URI in a 1450 Contact: header which remains valid for 30 minutes past the time the 1451 original call containing the URI completes unless the device 1452 registration expires and is not renewed. 1454 ED-67 During the course of an emergency call, devices and proxies 1455 MUST support REFER transactions with method=INVITE and the 1456 Referred-by: header [RFC3515] in that transaction. 1458 ED-68 deleted 1460 ED-69 There can be a case where the session signaling path is lost, 1461 and the user agent does not receive the BYE. If the call is hung up, 1462 and the session timer (if implemented) expires, the call MAY be 1463 declared lost. If in the interval, an incoming call is received from 1464 the domain of the PSAP, the device MUST drop the old call and alert 1465 for the (new) incoming call. Dropping of the old call MUST only 1466 occur if the user is attempting to hang up; the domain of an incoming 1467 call can only be determined from the From header, which is not 1468 reliable, and could be spoofed. Dropping an active call by a new 1469 call with a spoofed From: would be a DoS attack. 1471 ED-70 User Agents and proxies MUST disable features that will 1472 interrupt an ongoing emergency call, such as: 1473 o Call Waiting 1474 o Call Transfer 1475 o Three Way Call 1476 o Hold 1477 o Outbound Call Blocking 1478 when an emergency call is established. Also see ED-77 in Section 14. 1480 ED-71 The emergency dial strings SHOULD NOT be permitted in Call 1481 Forward numbers or speed dial lists. 1483 ED-72 The User Agent and Proxies MUST disable call features which 1484 would interfere with the ability of call backs from the PSAP to be 1485 completed such as: 1486 o Do Not Disturb 1487 o Call Forward (all kinds) 1489 ED-73 Call backs SHOULD be determined by retaining the domain of the 1490 PSAP which answers an outgoing emergency call and instantiating a 1491 timer which starts when the call is terminated. If a call is 1492 received from the same domain and within the timer period, sent to 1493 the Contact: or AoR used in the emergency call, it should be assumed 1494 to be a call back. The suggested timer period is 5 minutes. 1495 [RFC4916] may be used by the PSAP to inform the UA of the domain of 1496 the PSAP. Recognizing a call back from the domain of the PSAP will 1497 not always work, and further standardization will be required to give 1498 the UA the ability to recognize a call back. 1500 ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. 1502 ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 1503 agree on the media streams to be used. 1505 ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law 1506 if they are intended be used in North America) encoded voice as 1507 described in [RFC3551]. It is desirable to include wideband codecs 1508 such as AMR-WB in the offer. 1510 ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT 1511 be used on emergency calls. PSAP call takers sometimes get 1512 information on what is happening in the background to determine how 1513 to process the call. 1515 ED-78 Endpoints supporting Instant Messaging (IM) MUST support both 1516 [RFC3428] and [RFC4975]. 1518 ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The 1519 expectations for emergency service support for the real-time text 1520 medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. 1522 ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. 1524 ED-81 INVITE requests to a service URN ending in ".test" indicates a 1525 request for an automated test. For example, 1526 "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response 1527 indicates that the address was recognized and a 404 (Not found) that 1528 it was not. A 486 (Busy Here) MUST be returned if the test service 1529 is busy, and a 404 (Not Found) MUST be returned if the PSAP does not 1530 support the test mechanism. 1532 ED-82 In its response to the test, the PSAP MAY include a text body 1533 (text/plain) indicating the identity of the PSAP, the requested 1534 service, and the location reported with the call. For the latter, 1535 the PSAP SHOULD return location-by-value even if the original 1536 location delivered with the test was by-reference. If the location- 1537 by-reference was supplied, and the dereference requires credentials, 1538 the PSAP SHOULD use credentials supplied by the LIS for test 1539 purposes. This alerts the LIS that the dereference is not for an 1540 actual emergency call and location hiding techniques, if they are 1541 being used, may be employed for this dereference. Use of SIPS for 1542 the request would assure the response containing the location is kept 1543 private. 1545 ED-83 A PSAP accepting a test call SHOULD accept a media loopback 1546 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 1547 pkt-loopback" and "rtp-start-loopback" options. The user agent would 1548 specify a loopback attribute of "loopback-source", the PSAP being the 1549 mirror. User Agents should expect the PSAP to loop back no more than 1550 3 packets of each media type accepted (which limits the duration of 1551 the test), after which the PSAP would normally send BYE. 1553 ED-84 User agents SHOULD perform a full call test, including media 1554 loopback, after a disconnect and subsequent change in IP address not 1555 due to a reboot. After an initial test, a full test SHOULD be 1556 repeated approximately every 30 days with a random interval. 1558 ED-85 User agents MUST NOT place a test call immediately after 1559 booting. If the IP address changes after booting, the UA should wait 1560 a random amount of time (in perhaps a 30 minute period, sufficient 1561 for any avalanche restart to complete) and then test. 1563 ED-86 PSAPs MAY refuse repeated requests for test from the same 1564 device in a short period of time. Any refusal is signaled with a 486 1565 or 488 response. 1567 A.2. Requirements of Service Providers 1569 SP-1 If a device or application expects to be able to place a call 1570 for help, the service provider that supports it MUST facilitate 1571 emergency calling. Some jurisdictions have regulations governing 1572 this. 1574 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 1575 some reason the endpoint does not recognize them. This cannot be 1576 relied upon by the device if the service provider cannot always 1577 determine the location of the device. 1579 SP-3 Emergency calls MUST be marked with a Service URN in the 1580 Request-URI of the INVITE. 1582 SP-4 Local dial strings MUST be recognized. 1584 SP-5 Devices MUST be able to be configured with the home country from 1585 which the home dial string(s) can be determined. 1587 SP-6 Emergency dial strings SHOULD be determined from LoST [RFC5222]. 1588 Dial Strings MAY be configured directly in the device. 1590 SP-7 If a proxy server recognizes dial strings on behalf of its 1591 clients it MUST recognize emergency dial strings represented by 1592 [RFC4967] and SHOULD recognize emergency dial strings represented by 1593 a tel URI [RFC3966]. 1595 SP-8 Service providers MAY provide home dial strings by 1596 configuration. 1598 SP-9 All emergency services specified in [RFC5031] MUST be 1599 recognized. 1601 SP-10 Endpoints, Intermediate Devices and Service Providers MUST be 1602 prepared to handle location represented in either civic or geo form. 1604 SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from 1605 the form of location the determination mechanism supplied. 1607 SP-12 Proxies MAY provide location on behalf of devices if: 1608 o The proxy has a relationship with all access networks the device 1609 could connect to, and the relationship allows it to obtain 1610 location. 1611 o The proxy has an identifier, such as an IP address, that can be 1612 used by the access network to determine the location of the 1613 endpoint, even in the presence of NAT and VPN tunnels that may 1614 obscure the identifier between the access network and the service 1615 provider. 1617 SP-13 Where proxies provide location on behalf of endpoints, the 1618 service provider MUST ensure that either the end device is provided 1619 with the local dial strings for its current location (where the end 1620 device recognizes dial strings), or the service provider proxy MUST 1621 detect the appropriate local dial strings at the time of the call. 1623 SP-14 When HELD is the LCP, the request MUST specify a value of 1624 "emergencyRouting" for the "responseTime" parameter and use the 1625 resulting location for routing. If a value for dispatch location 1626 will be sent, another request with the "responseTime" parameter set 1627 to "emergencyDispatch" must be completed, with the result sent for 1628 dispatch purposes. 1630 SP-15 Location sent between SIP elements MUST be conveyed using 1631 [I-D.ietf-sip-location-conveyance]. 1633 SP-16 If the LIS has more than one location for an endpoint it MUST 1634 use the procedures in [RFC5491] 1636 SP-17 If a proxy inserts location on behalf of an endpoint, and it 1637 has multiple locations available for the endpoint it MUST choose one 1638 location to use to route the call towards the PSAP. 1640 SP-18 If a proxy is attempting to insert location but the UA conveyed 1641 a location to it, the proxy MUST use the UA's location for routing 1642 and MUST convey that location towards the PSAP. It MAY also include 1643 what it believes the location to be in a separate Geolocation header. 1645 SP-19 All location objects received by a proxy MUST be delivered to 1646 the PSAP. 1648 SP-20 Location objects MUST contain information about the method by 1649 which the location was determined, such as GPS, manually entered, or 1650 based on access network topology included in a PIDF- LO "method" 1651 element. In addition, the source of the location information MUST be 1652 included in a PIDF-LO "provided-by" element. 1654 SP-21 The "used-for-routing" parameter MUST be set to the location 1655 that was chosen for routing. 1657 SP-22 Proxies handling emergency calls MUST insert a default location 1658 if the call does not contain a location and the proxy does not have a 1659 method for obtaining a better location. 1661 SP-23 Default locations MUST be marked with method=Default and the 1662 proxy MUST be identified in provided-by element of the PIDF-LO. 1664 SP-24 TLS MUST be used to protect location (but see Section 9.1). 1665 IPSEC [RFC3986] is an acceptable alternative. 1667 SP-25 Service Providers MUST provide an SRV entry in their DNS server 1668 which leads to a LoST server 1670 SP-26 Networks MUST be designed so that at least one proxy in the 1671 outbound path will recognize emergency calls with a Request URI of 1672 the service URN in the "sos" tree. An endpoint places a service URN 1673 in the Request URI to indicate that the endpoint understood the call 1674 was an emergency call. A proxy that processes such a call looks for 1675 the presence of a SIP Route header field with a URI of a PSAP. 1676 Absence of such a Route header indicates the UAC was unable to invoke 1677 LoST and the proxy MUST perform the LoST mapping and insert a Route 1678 header field with the URI obtained. 1680 SP-27 To deal with old user agents that predate this specification 1681 and with UAs that do not have access to their own location data, a 1682 proxy that recognizes a call as an emergency call that is not marked 1683 as such (see Section 5) MUST also perform this mapping, with the best 1684 location it has available for the endpoint. The resulting PSAP URI 1685 would be placed in a Route header with the service URN in the Request 1686 URI. 1688 SP-28 Proxy servers performing mapping SHOULD use location obtained 1689 from the access network for the mapping. If no location is 1690 available, a default location (see Section 6.11) MUST be supplied. 1692 SP-29 A proxy server which attempts mapping and fails to get a 1693 mapping MUST provide a default mapping. A suitable default mapping 1694 would be the mapping obtained previously for the default location 1695 appropriate for the caller. 1697 SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an 1698 emergency call towards the PSAP's URI. 1700 SP-31 TLS MUST be specified when attempting to signal an emergency 1701 call with SIP. IPSEC [RFC3986] is an acceptable alternative. 1703 SP-32 If TLS session establishment is not available, or fails, the 1704 call MUST be retried without TLS. 1706 SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent 1707 TLS connections between elements. 1709 SP-34 SIP Proxy servers processing emergency calls: 1710 1. If the proxy interprets dial plans on behalf of user agents, the 1711 proxy MUST look for the local emergency dial string at the 1712 location of the end device and MAY look for the home dial string. 1713 If it finds it, the proxy MUST: 1715 * Insert a Geolocation header as above. Location-by-reference 1716 MUST be used because proxies must not insert bodies. 1717 * Include the Geolocation "inserted-by" and "used-for-routing" 1718 parameters with its own hostname (which should match the Via 1719 it inserts) on the inserted-by. 1720 * Map the location to a PSAP URI using LoST. 1721 * Add a Route header with the PSAP URI. 1722 * Replace the Request-URI (which was the dial string) with the 1723 service URN appropriate for the emergency dial string. 1724 * Route the call using normal SIP routing mechanisms. 1725 2. If the proxy recognizes the service URN in the Request URI, and 1726 does not find a a Route header, it MUST query a LoST server. If 1727 multiple locations were provided, the proxy uses the location 1728 that has the "used-for-routing" marker set. If a location was 1729 provided (which should be the case), the proxy uses that location 1730 to query LoST. The proxy may have to dereference a location by 1731 reference to get a value. If a location is not present, and the 1732 proxy can query a LIS which has the location of the UA it MUST do 1733 so. If no location is present, and the proxy does not have 1734 access to a LIS which could provide location, the proxy MUST 1735 supply a default location (See Section 6.11). The location (in 1736 the signaling, obtained from a LIS, or default) MUST be used in a 1737 query to LoST with the service URN received with the call. The 1738 resulting URI MUST be placed in a Route header added to the call. 1739 3. The "inserted-by" parameter in any Geolocation: header received 1740 on the call MUST NOT be modified or deleted in transit. 1741 4. The proxy SHOULD NOT modify any parameters in Geolocation headers 1742 received in the call. It MAY add a Geolocation header. Such an 1743 additional location SHOULD NOT be used for routing; the location 1744 provided by the UA should be used. 1745 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 1746 [RFC4474], or both, SHOULD be included to identify the sender. 1747 For services which must support emergency calls from 1748 unauthenticated devices, valid identity may not be available. 1750 SP-35 Devices device SHOULD have a globally routable URI in a 1751 Contact: header which remains valid for 30 minutes past the time the 1752 original call containing the URI completes unless the device 1753 registration expires and is not renewed. 1755 SP-36 Call backs to the Contact: header URI recieved within 30 1756 minutes of an emergency call must reach the device regardless of call 1757 features or services that would normally cause the call to be routed 1758 to some other entity. 1760 SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- 1761 Identity: header or From: protected by an Identity header suitable 1762 for returning a call some time after the original call. Such a call 1763 back would not necessarily reach the device that originally placed 1764 the call. 1766 SP-38 During the course of an emergency call, devices and proxies 1767 MUST support REFER transactions with method=INVITE and the 1768 Referred-by: header [RFC3515] in that transaction. 1770 SP-39 User Agents and proxies MUST disable features that will 1771 interrupt an ongoing emergency call, such as: 1772 o Call Waiting 1773 o Call Transfer 1774 o Three Way Call 1775 o Hold 1776 o Outbound Call Blocking 1777 when an emergency call is established. Also see ED-77 in Section 14. 1779 SP-40 The emergency dial strings SHOULD NOT be permitted in Call 1780 Forward numbers or speed dial lists. 1782 SP-41 The User Agent and Proxies MUST disable call features which 1783 would interfere with the ability of call backs from the PSAP to be 1784 completed such as: 1785 o Do Not Disturb 1786 o Call Forward (all kinds) 1788 A.3. Requirements of Access Network 1790 AN-1 LoST servers MUST return dial strings for emergency services 1792 AN-2 Elements MUST NOT convert (civic to geo or geo to civic) from 1793 the form of location the determination mechanism supplied. 1795 AN-3 Any suitable location determination mechanism MAY be used. 1797 AN-4 Devices, intermediate Devices and/or access networks SHOULD 1798 support a manual method to "override" the location the access network 1799 determines. Where a civic form of location is provided, all fields 1800 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1802 AN-5 Access networks supporting copper, fiber or other hard wired IP 1803 packet service SHOULD support location configuration. If the network 1804 does not support location configuration, it MUST require every device 1805 that connects to the network to support end system measured location. 1807 AN-6 Access networks and intermediate devices providing wire database 1808 location information SHOULD provide interior location data (building, 1809 floor, room, cubicle) where possible. It is RECOMMENDED that 1810 interior location be provided when spaces exceed approximately 650 1811 square meters. 1813 AN-7 Access networks and intermediate devices (including enterprise 1814 networks) which support intermediate range wireless connections 1815 (typically 100m or less of range) and which do not support a more 1816 accurate location determination mechanism such as triangulation, MUST 1817 support location configuration where the location of the access point 1818 is reflected as the location of the clients of that access point. 1819 Where the access network provides location configuration, 1820 intermediate devices MUST either be transparent to it, or provide an 1821 interconnected client for the supported configuration mechanism and a 1822 server for a configuration protocol supported by end devices 1823 downstream of the intermediate device 1825 AN-8 Devices that support endpoint measuring of location MUST have at 1826 least a coarse location capability (typically <1km accuracy when not 1827 location hiding) for routing of calls. The location mechanism MAY be 1828 a service provided by the access network. 1830 AN-9 Access networks MAY provide network-measured location 1831 determination. Wireless access network which do not support network 1832 measured location MUST require that all devices connected to the 1833 network have end-system measured location. Uncertainty of less than 1834 100 m with 95% confidence SHOULD be available for dispatch. 1836 AN-10 Access networks that provide network measured location MUST 1837 have at least a coarse location (typically <1km when not location 1838 hiding) capability at all times for routing of calls. 1840 AN-11 Access networks with range of <10 meters (e.g. personnal area 1841 networks such as Bluetooth MUST provide a location to mobile devices 1842 connected to them. The location provided SHOULD be that of the 1843 access point location unless a more accurate mechanism is provided. 1845 AN-12 The access network MUST support either DHCP location options or 1846 HELD. The access network SHOULD support other location technologies 1847 that are specific to the type of access network. 1849 AN-13 Where a router is employed between a LAN and WAN in a small 1850 (less than approximately 650 square meters) area, the router MUST be 1851 transparent to the location provided by the WAN to the LAN. This may 1852 mean the router must obtain location as a client from the WAN, and 1853 supply an LCP server to the LAN with the location it obtains. Where 1854 the area is larger, the LAN MUST have a location configuration 1855 mechanism meeting this BCP. 1857 AN-14 Access networks that support more than one LCP MUST reply with 1858 the same location information (within the limits of the data format 1859 for the specific LCP) for all LCPs it supports. 1861 AN-15 Network administrators MUST take care in assigning IP addresses 1862 such that VPN address assignments can be distinguished from local 1863 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 1864 to provide location to addresses that arrive via VPN connections 1865 unless it can accurately determine the location for such addresses. 1867 AN-16 Placement of NAT devices where an LCP uses IP address for an 1868 identifier SHOULD consider the effect of the NAT on the LCP. The 1869 address used to query the LIS MUST be able to correctly identify the 1870 record in the LIS representing the location of the querying device 1872 AN-17 It is RECOMMENDED that location determination not take longer 1873 than 250 ms to obtain routing location and systems SHOULD be designed 1874 such that the typical response is under 100 ms. However, as much as 1875 3 seconds to obtain routing location MAY be tolerated if location 1876 accuracy can be substantially improved over what can be obtained in 1877 250 ms. 1879 AN-18 Where the absolute location or the accuracy of location of the 1880 endpoint may change between the time the call is received at the PSAP 1881 and the time dispatch is completed, location update mechanisms MUST 1882 be provided. 1884 AN-19 Mobile devices MUST be provided with a mechanism to get 1885 repeated location updates to track the motion of the device during 1886 the complete processing of the call. 1888 AN-20 The LIS SHOULD provide a location reference which permits a 1889 subscription with appropriate filtering. 1891 AN-21 For calls sent with location-by-reference, with a SIP or SIPS 1892 scheme, the server resolving the reference MUST support a SUBSCRIBE 1893 [RFC3265] to the presence event [RFC3856]. For other location-by- 1894 reference schemes that do not support subscription, the PSAP will 1895 have to repeatedly dereference the URI to determine if the device 1896 moved. 1898 AN-22 A LIS should perform location validation of civic locations via 1899 LoST before entering a location in its database. 1901 AN-23 When the access network cannot determine the actual location of 1902 the caller, it MUST supply a default location. The default SHOULD be 1903 chosen to be as close to the probable location of the device as the 1904 network can determine. See [I-D.ietf-ecrit-framework] 1906 AN-24 Default locations MUST be marked with method=Default and the 1907 proxy MUST be identified in provided-by element of the PIDF-LO. 1909 AN-25 To prevent against spoofing of the DHCP server, elements 1910 implementing DHCP for location configuration SHOULD use [RFC3118] 1911 although the difficulty in providing appropriate credentials is 1912 significant. 1914 AN-26 Access networks which support DHCP MUST implement the LoST 1915 discovery option 1917 AN-27 Access Networks that use HELD and that have a DHCP server 1918 SHOULD support DHCP options for providing LIS and LoST servers. 1920 AN-28 TLS MUST be specified when attempting to retrieve location 1921 (configuration or dereferencing) with HELD. The use of [RFC5077] is 1922 RECOMMENDED to minimize the time to establish TLS sessions without 1923 keeping server-side state. 1925 AN-29 If TLS session establishment fails, the location retrieval MUST 1926 be retried without TLS. 1928 A.4. Requirements of Intermediate Devices 1930 INT-1 Endpoints, Intermediate Devices and Service Providers MUST be 1931 prepared to handle location represented in either civic or geo form. 1933 INT-2 Elements MUST NOT convert (civic to geo or geo to civic) from 1934 the form of location the determination mechanism supplied. 1936 INT-3 Any suitable location determination mechanism MAY be used. 1938 INT-4 Devices, intermediate Devices and/or access networks SHOULD 1939 support a manual method to "override" the location the access network 1940 determines. Where a civic form of location is provided, all fields 1941 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1943 INT-5 Access networks and intermediate devices providing wire 1944 database location information SHOULD provide interior location data 1945 (building, floor, room, cubicle) where possible. It is RECOMMENDED 1946 that interior location be provided when spaces exceed approximately 1947 650 square meters. 1949 INT-6 Access networks and intermediate devices (including enterprise 1950 networks) which support intermediate range wireless connections 1951 (typically 100m or less of range) and which do not support a more 1952 accurate location determination mechanism such as triangulation, MUST 1953 support location configuration where the location of the access point 1954 is reflected as the location of the clients of that access point. 1956 Where the access network provides location configuration, 1957 intermediate devices MUST either be transparent to it, or provide an 1958 interconnected client for the supported configuration mechanism and a 1959 server for a configuration protocol supported by end devices 1960 downstream of the intermediate device 1962 INT-7 Devices MAY support end-system measured location. Uncertainty 1963 of less than 100 m with 95% confidence SHOULD be available for 1964 dispatch. 1966 INT-8 Devices that support endpoint measuring of location MUST have 1967 at least a coarse location capability (typically <1km accuracy when 1968 not location hiding) for routing of calls. The location mechanism 1969 MAY be a service provided by the access network. 1971 INT-9 Endpoints SHOULD attempt to configure their own location using 1972 the LCPs listed in ED-21. 1974 INT-10 Where proxies provide location on behalf of endpoints, the 1975 service provider MUST ensure that either the end device is provided 1976 with the local dial strings for its current location (where the end 1977 device recognizes dial strings), or the service provider proxy MUST 1978 detect the appropriate local dial strings at the time of the call. 1980 INT-11 Devices SHOULD be able to accept and forward location by value 1981 or by reference. An end device that receives location by reference 1982 (and does not also get the corresponding value) MUST be able to 1983 perform a dereference operation to obtain a value. 1985 INT-12 Devices MUST support both the DHCP location options [RFC4776], 1986 [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When 1987 devices deploy a specific access network interface in which that 1988 access network supports location discovery such as LLDP-MED or 1989 802.11v, the device SHOULD support the additional respective access 1990 network specific location discovery mechanism. 1992 INT-13 The access network MUST support either DHCP location options 1993 or HELD. The access network SHOULD support other location 1994 technologies that are specific to the type of access network. 1996 INT-14 Where a router is employed between a LAN and WAN in a small 1997 (less than approximately 650 square meters) area, the router MUST be 1998 transparent to the location provided by the WAN to the LAN. This may 1999 mean the router must obtain location as a client from the WAN, and 2000 supply an LCP server to the LAN with the location it obtains. Where 2001 the area is larger, the LAN MUST have a location configuration 2002 mechanism meeting this BCP. 2004 INT-15 Endpoints SHOULD try all LCPs supported by the device in any 2005 order or in parallel. The first one that succeeds in supplying 2006 location can be used. 2008 INT-16 Access networks that support more than one LCP MUST reply with 2009 the same location information (within the limits of the data format 2010 for the specific LCP) for all LCPs it supports. 2012 INT-17 When HELD is the LCP, the request MUST specify a value of 2013 "emergencyRouting" for the "responseTime" parameter and use the 2014 resulting location for routing. If a value for dispatch location 2015 will be sent, another request with the "responseTime" parameter set 2016 to "emergencyDispatch" must be completed, with the result sent for 2017 dispatch purposes. 2019 INT-18 Endpoints SHOULD obtain location immediately after obtaining 2020 local network configuration information. When HELD is the LCP the 2021 client MUST support a random back-off period (between 30 seconds and 2022 300 seconds) for re-trying the HELD query, when no response is 2023 received, and no other LCP provided location information. 2025 INT-19 If the device is configured to use DHCP for bootstrapping, it 2026 MUST include both options for location acquisition (civic and 2027 geodetic), the option for LIS discovery, and the option for LoST 2028 discovery as defined in [RFC4776], [RFC3825], 2029 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 2031 INT-20 If the device sends a DHCPINFORM message, it MUST include both 2032 options for location acquisition (civic and geodetic), the option for 2033 LIS discovery, and the option for LoST discovery as defined in 2034 [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 2036 INT-21 To minimize the effects of VPNs that do not allow packets to 2037 be sent via the native hardware interface rather than via the VPN 2038 tunnel, location configuration SHOULD be attempted before such 2039 tunnels are established. 2041 INT-22 Software which uses LCPs SHOULD locate and use the actual 2042 hardware network interface rather than a VPN tunnel interface to 2043 direct LCP requests to the LIS in the actual access network. 2045 INT-23 For devices which are not expected to roam, refreshing 2046 location on the order of once per day is RECOMMENDED. 2048 INT-24 For devices which roam, refresh of location information SHOULD 2049 be more frequent, with the frequency related to the mobility of the 2050 device and the ability of the access network to support the refresh 2051 operation. If the device can detect that it has moved, for example 2052 when it changes access points, the device SHOULD refresh its 2053 location. 2055 INT-25 It is RECOMMENDED that location determination not take longer 2056 than 250 ms to obtain routing location and systems SHOULD be designed 2057 such that the typical response is under 100 ms. However, as much as 2058 3 seconds to obtain routing location MAY be tolerated if location 2059 accuracy can be substantially improved over what can be obtained in 2060 250 ms. 2062 Authors' Addresses 2064 Brian Rosen 2065 NeuStar 2066 470 Conrad Dr. 2067 Mars, PA 16046 2068 US 2070 Phone: +1 724 382 1051 2071 Email: br@brianrosen.net 2073 James Polk 2074 Cisco Systems 2075 3913 Treemont Circle 2076 Colleyville, TX 76034 2077 US 2079 Phone: +1-817-271-3552 2080 Email: jmpolk@cisco.com