idnits 2.17.1 draft-ietf-ecrit-phonebcp-08.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 (February 26, 2009) is 5531 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 959, but no explicit reference was found in the text == Unused Reference: 'LLDP-MED' is defined on line 962, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-13 == Outdated reference: A later version (-15) exists of draft-ietf-geopriv-lis-discovery-07 == Outdated reference: A later version (-27) exists of draft-ietf-mmusic-media-loopback-09 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-12 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-16 -- 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: A later version (-05) exists of draft-barnes-geopriv-lo-sec-04 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-07 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 10 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: August 30, 2009 Cisco Systems 6 February 26, 2009 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-08 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 August 30, 2009. 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 deleted 186 ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST 187 [RFC5222]. Dial Strings MAY be configured directly in the device. 189 AN-1 LoST servers MUST return dial strings for emergency services 191 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 192 send dial strings as per [RFC4967]. 194 SP-7 If a proxy server recognizes dial strings on behalf of its 195 clients it MUST recognize emergency dial strings represented by 196 [RFC4967] and SHOULD recognize emergency dial strings represented by 197 a tel URI [RFC3966]. 199 ED-9 Endpoints SHOULD be able to have home dial strings provisioned. 201 SP-8 Service providers MAY provision home dial strings in devices. 203 ED-10 Devices SHOULD NOT have one button emergency calling 204 initiation. 206 ED-11/SP-9 All emergency services specified in [RFC5031] MUST be 207 recognized. 209 6. Location and its role in an emergency call 211 Handling location for emergency calling usually involves several 212 steps to process and multiple elements are involved. In Internet 213 emergency calling, where the endpoint is located is "determined" 214 using a variety of measurement or wiretracing methods. Endpoints may 215 be "configured" with their own location by the access network. In 216 some circumstances, a proxy server may insert location into the 217 signaling on behalf of the endpoint. The location is "mapped" to the 218 URI to send the call to, and the location is "conveyed" to the PSAP 219 (and other elements) in the signaling. Likewise, we employ Location 220 Configuration Protocols, the Location-to-Service Mapping Protocol, 221 and Location Conveyance Protocols for these functions. The Location- 222 to-Service Translation protocol [RFC5222] is the Location Mapping 223 Protocol defined by the IETF. 225 6.1. Types of location information 227 There are several forms of location. In IETF location configuration 228 and location conveyance protocols, civic and geospatial (geo) forms 229 are both supported. The civic forms include both postal and 230 jurisdictional fields. A cell tower/sector can be represented as a 231 point (geo or civic) or polygon. Other forms of location 232 representation must be mapped into either a geo or civic for use in 233 emergency calls. 235 ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service 236 Providers MUST be prepared to handle location represented in either 237 civic or geo form. 239 ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo 240 to civic) from the form of location the determination mechanism 241 supplied. 243 6.2. Location Determination 245 ED-14/INT-3/AN-3 Any suitable location determination mechanism MAY be 246 used. 248 6.2.1. User-entered location information 250 ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks 251 SHOULD support a manual method to "override" the location the access 252 network determines. Where a civic form of location is provided, all 253 fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be 254 specified. 256 6.2.2. Access network "wire database" location information 258 AN-5 Access networks supporting copper, fiber or other hard wired IP 259 packet service SHOULD support location configuration. If the network 260 does not support location configuration, it MUST require every device 261 that connects to the network to support end system measured location. 263 AN-6/INT-5 Access networks and intermediate devices providing wire 264 database location information SHOULD provide interior location data 265 (building, floor, room, cubicle) where possible. It is RECOMMENDED 266 that interior location be provided when spaces exceed approximately 267 650 square meters. 269 AN-7/INT-6 Access networks and intermediate devices (including 270 enterprise networks) which support intermediate range wireless 271 connections (typically 100m or less of range) and which do not 272 support a more accurate location determination mechanism such as 273 triangulation, MUST support location configuration where the location 274 of the access point is reflected as the location of the clients of 275 that access point. Where the access network provides location 276 configuration, intermediate devices MUST either be transparent to it, 277 or provide an interconnected client for the supported configuration 278 mechanism and a server for a configuration protocol supported by end 279 devices downstream of the intermediate device 281 6.2.3. End-system measured location information 283 ED-16/INT-7 Devices MAY support end-system measured location. 284 Uncertainty of less than 100 m with 95% confidence SHOULD be 285 available for dispatch. 287 ED-17/INT-8/AN-8 Devices that support endpoint measuring of location 288 MUST have at least a coarse location capability (typically <1km 289 accuracy when not location hiding) for routing of calls. The 290 location mechanism MAY be a service provided by the access network. 292 6.2.4. Network-measured location information 294 AN-9 Access networks MAY provide network-measured location 295 determination. Wireless access network which do not support network 296 measured location MUST require that all devices connected to the 297 network have end-system measured location. Uncertainty of less than 298 100 m with 95% confidence SHOULD be available for dispatch. 300 AN-10 Access networks that provide network measured location MUST 301 have at least a coarse location (typically <1km when not location 302 hiding) capability at all times for routing of calls. 304 AN-11 Access networks with range of <10 meters (e.g. personal area 305 networks such as Bluetooth MUST provide a location to mobile devices 306 connected to them. The location provided SHOULD be that of the 307 access point location unless a more accurate mechanism is provided. 309 6.3. Who adds location, endpoint or proxy 311 ED-18/INT-9 Endpoints SHOULD attempt to configure their own location 312 using the LCPs listed in ED-21. 314 SP-12 Proxies MAY provide location on behalf of devices if: 315 o The proxy has a relationship with all access networks the device 316 could connect to, and the relationship allows it to obtain 317 location. 318 o The proxy has an identifier, such as an IP address, that can be 319 used by the access network to determine the location of the 320 endpoint, even in the presence of NAT and VPN tunnels that may 321 obscure the identifier between the access network and the service 322 provider. 324 ED-19/INT-10/SP-13 Where proxies provide location on behalf of 325 endpoints, the service provider MUST ensure that either the end 326 device is provided with the local dial strings for its current 327 location (where the end device recognizes dial strings), or the 328 service provider proxy MUST detect the appropriate local dial strings 329 at the time of the call. 331 6.4. Location and references to location 333 ED-20/INT-11 Devices SHOULD be able to accept and forward location by 334 value or by reference. An end device that receives location by 335 reference (and does not also get the corresponding value) MUST be 336 able to perform a dereference operation to obtain a value. 338 6.5. End system location configuration 340 ED-21/INT-12 Devices MUST support both the DHCP location options 341 [RFC4776], [RFC3825] and HELD 342 [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a 343 specific access network interface in which that access network 344 supports location discovery such as LLDP-MED or 802.11v, the device 345 SHOULD support the additional respective access network specific 346 location discovery mechanism. 348 AN-12/INT-13 The access network MUST support either DHCP location 349 options or HELD. The access network SHOULD support other location 350 technologies that are specific to the type of access network. 352 AN-13/INT-14 Where a router is employed between a LAN and WAN in a 353 small (less than approximately 650 square meters) area, the router 354 MUST be transparent to the location provided by the WAN to the LAN. 355 This may mean the router must obtain location as a client from the 356 WAN, and supply an LCP server to the LAN with the location it 357 obtains. Where the area is larger, the LAN MUST have a location 358 configuration mechanism meeting this BCP. 360 ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in 361 any order or in parallel. The first one that succeeds in supplying 362 location can be used. 364 AN-14/INT-16 Access networks that support more than one LCP MUST 365 reply with the same location information (within the limits of the 366 data format for the specific LCP) for all LCPs it supports. 368 ED-23/INT-17/SP-14 When HELD is the LCP, the request MUST specify a 369 value of "emergencyRouting" for the "responseTime" parameter and use 370 the resulting location for routing. If a value for dispatch location 371 will be sent, another request with the "responseTime" parameter set 372 to "emergencyDispatch" must be completed, with the result sent for 373 dispatch purposes. 375 ED-24 Where the operating system supporting application programs 376 which need location for emergency calls does not allow access to 377 Layer 2 and Layer 3 functions necessary for a client application to 378 use DHCP location options and/or LLDP-MED, the operating system MUST 379 provide a published API conforming to ED-12 through ED-21 and ED-21 380 through ED-31. It is RECOMMENDED that all operating systems provide 381 such an API. 383 6.6. When location should be configured 385 ED-25/INT-18 Endpoints SHOULD obtain location immediately after 386 obtaining local network configuration information. When HELD is the 387 LCP the client MUST support a random back-off period (between 30 388 seconds and 300 seconds) for re-trying the HELD query, when no 389 response is received, and no other LCP provided location information. 391 ED-26/INT-19 If the device is configured to use DHCP for 392 bootstrapping, it MUST include both options for location acquisition 393 (civic and geodetic), the option for LIS discovery, and the option 394 for LoST discovery as defined in [RFC4776], [RFC3825], 395 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 397 ED-27/INT-20 If the device sends a DHCPINFORM message, it MUST 398 include both options for location acquisition (civic and geodetic), 399 the option for LIS discovery, and the option for LoST discovery as 400 defined in [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and 401 [RFC5223]. 403 ED-28/INT-21 To minimize the effects of VPNs that do not allow 404 packets to be sent via the native hardware interface rather than via 405 the VPN tunnel, location configuration SHOULD be attempted before 406 such tunnels are established. 408 ED-29/INT-22 Software which uses LCPs SHOULD locate and use the 409 actual hardware network interface rather than a VPN tunnel interface 410 to direct LCP requests to the LIS in the actual access network. 412 AN-15 Network administrators MUST take care in assigning IP addresses 413 such that VPN address assignments can be distinguished from local 414 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 415 to provide location to addresses that arrive via VPN connections 416 unless it can accurately determine the location for such addresses. 418 AN-16 Placement of NAT devices where an LCP uses IP address for an 419 identifier SHOULD consider the effect of the NAT on the LCP. The 420 address used to query the LIS MUST be able to correctly identify the 421 record in the LIS representing the location of the querying device 423 ED-30/INT-23 For devices which are not expected to roam, refreshing 424 location on the order of once per day is RECOMMENDED. 426 ED-31/INT-24 For devices which roam, refresh of location information 427 SHOULD be more frequent, with the frequency related to the mobility 428 of the device and the ability of the access network to support the 429 refresh operation. If the device can detect that it has moved, for 430 example when it changes access points, the device SHOULD refresh its 431 location. 433 ED-32/INT-25/AN-17 It is RECOMMENDED that location determination not 434 take longer than 250 ms to obtain routing location and systems SHOULD 435 be designed such that the typical response is under 100 ms. However, 436 as much as 3 seconds to obtain routing location MAY be tolerated if 437 location accuracy can be substantially improved over what can be 438 obtained in 250 ms. 440 6.7. Conveying location in SIP 442 ED-33/SP-15 Location sent between SIP elements MUST be conveyed using 443 [I-D.ietf-sip-location-conveyance]. 445 6.8. Location updates 447 ED-34/AN-18 Where the absolute location or the accuracy of location 448 of the endpoint may change between the time the call is received at 449 the PSAP and the time dispatch is completed, location update 450 mechanisms MUST be provided. 452 ED-35/AN-19 Mobile devices MUST be provided with a mechanism to get 453 repeated location updates to track the motion of the device during 454 the complete processing of the call. 456 ED-36/AN-20 The LIS SHOULD provide a location reference which permits 457 a subscription with appropriate filtering. 459 ED-37/AN-21 For calls sent with location-by-reference, with a SIP or 460 SIPS scheme, the server resolving the reference MUST support a 461 SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other 462 location-by-reference schemes that do not support subscription, the 463 PSAP will have to repeatedly dereference the URI to determine if the 464 device moved. 466 ED-38 If location was sent by value, and the endpoint gets updated 467 location, it MUST send the updated location to the PSAP via a SIP re- 468 INVITE or UPDATE request. Such updates SHOULD be limited to no more 469 than one update every 10 seconds. 471 6.9. Multiple locations 473 ED-39/SP-16 If the LIS has more than one location for an endpoint it 474 MUST use the procedures in [I-D.ietf-geopriv-pdif-lo-profile] 476 ED-40 If a UA has more than one location available to it, it MUST 477 choose one location to route the call towards the PSAP. If multiple 478 locations are in a single PIDF, the procedures in 480 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. If the UA has 481 multiple PIDFs, and has no reasonable basis to choose from among 482 them, a random choice is acceptable. 484 SP-17 If a proxy inserts location on behalf of an endpoint, and it 485 has multiple locations available for the endpoint it MUST choose one 486 location to use to route the call towards the PSAP. 488 SP-18 If a proxy is attempting to insert location but the UA conveyed 489 a location to it, the proxy MUST use the UA's location for routing 490 and MUST convey that location towards the PSAP. It MAY also include 491 what it believes the location to be in a separate Geolocation header. 493 SP-19 All location objects received by a proxy MUST be delivered to 494 the PSAP. 496 ED-41/SP-20 Location objects MUST contain information about the 497 method by which the location was determined, such as GPS, manually 498 entered, or based on access network topology included in a PIDF- LO 499 "method" element. In addition, the source of the location 500 information MUST be included in a PIDF-LO "provided-by" element. 502 ED-??/SP-?? A location with a method of "derived" MUST NOT be used 503 unless no other location is available. 505 ED-42/SP-21 The "used-for-routing" parameter MUST be set to the 506 location that was chosen for routing. 508 6.10. Location validation 510 AN-22 A LIS should perform location validation of civic locations via 511 LoST before entering a location in its database. 513 ED-43 Endpoints SHOULD validate civic locations when they receive 514 them from their LCP. Validation SHOULD be performed in conjunction 515 with the LoST route query to minimize load on the LoST server. 517 6.11. Default location 519 AN-23 When the access network cannot determine the actual location of 520 the caller, it MUST supply a default location. The default SHOULD be 521 chosen to be as close to the probable location of the device as the 522 network can determine. See [I-D.ietf-ecrit-framework] 524 SP-22 Proxies handling emergency calls MUST insert a default location 525 if the call does not contain a location and the proxy does not have a 526 method for obtaining a better location. 528 AN-24/SP-23 Default locations MUST be marked with method=Default and 529 the proxy MUST be identified in provided-by element of the PIDF-LO. 531 6.12. Other location considerations 533 ED-44 If the LCP does not return location in the form of a PIDF-LO 534 [RFC4119], the endpoint MUST map the location information it receives 535 from the configuration protocol to a PIDF-LO. 537 ED-45/AN-25 To prevent against spoofing of the DHCP server, elements 538 implementing DHCP for location configuration SHOULD use [RFC3118] 539 although the difficulty in providing appropriate credentials is 540 significant. 542 ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header 543 or bodies. 545 ED-47/SP-24 TLS MUST be used to protect location (but see 546 Section 9.1). IPSEC [RFC3986] is an acceptable alternative. 548 7. LIS and LoST Discovery 550 ED-48 Endpoints MUST support one or more mechanisms that allow them 551 to determine their public IP address. Examples include STUN 552 [RFC3489] and HTTP get. 554 ED-49 Endpoints MUST support LIS discovery as described in 555 [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described 556 in [RFC5223]. 558 ED-50 The device MUST have a configurable default LoST server 559 parameter. If the device is provided by or managed by a service 560 provider, it is expected that the service provider will configure 561 this option. 563 ED-51 DHCP LoST discovery MUST be used, if available, in preference 564 to configured LoST servers. If neither DHCP nor configuration leads 565 to an available LoST server, the device MUST query DNS using it's SIP 566 domain for an SRV record for a LoST service and use that server. 568 AN-26 Access networks which support DHCP MUST implement the LoST 569 discovery option 571 SP-25 Service Providers MUST provide an SRV entry in their DNS server 572 which leads to a LoST server 574 AN-27 Access Networks that use HELD and that have a DHCP server 575 SHOULD support DHCP options for providing LIS and LoST servers. 577 ED-52 When an endpoint has obtained a LoST server via an discovery 578 mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered 579 LoST server over LoST servers configured by other means. That is, 580 the endpoint MUST send queries to this LoST server first, using other 581 LoST servers only if these queries fail. 583 8. Routing the call to the PSAP 585 ED-53 Endpoints who obtain their own location SHOULD perform LoST 586 mapping to the PSAP URI. 588 ED-54 Mapping SHOULD be performed at boot time and whenever location 589 changes beyond the service boundary obtained from a prior LoST 590 mapping operation or the time-to-live value of that response has 591 expired. The value MUST be cached for possible later use. 593 ED-55 The endpoint MUST attempt to update its location at the time of 594 an emergency call. If it cannot obtain a new location quickly (see 595 Section 6), it MUST use the cached value. 597 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 598 time of an emergency call. If it cannot obtain a new mapping 599 quickly, it MUST use the cached value. If the device cannot update 600 the LoST mapping and does not have a cached value, it MUST signal an 601 emergency call without a Route header containing a PSAP URI. 603 SP-26 Networks MUST be designed so that at least one proxy in the 604 outbound path will recognize emergency calls with a Request URI of 605 the service URN in the "sos" tree. An endpoint places a service URN 606 in the Request URI to indicate that the endpoint understood the call 607 was an emergency call. A proxy that processes such a call looks for 608 the presence of a SIP Route header field with a URI of a PSAP. 609 Absence of such a Route header indicates the UAC was unable to invoke 610 LoST and the proxy MUST perform the LoST mapping and insert a Route 611 header field with the URI obtained. 613 SP-27 To deal with old user agents that predate this specification 614 and with UAs that do not have access to their own location data, a 615 proxy that recognizes a call as an emergency call that is not marked 616 as such (see Section 5) MUST also perform this mapping, with the best 617 location it has available for the endpoint. The resulting PSAP URI 618 would be placed in a Route header with the service URN in the Request 619 URI. 621 SP-28 Proxy servers performing mapping SHOULD use location obtained 622 from the access network for the mapping. If no location is 623 available, a default location (see Section 6.11) MUST be supplied. 625 SP-29 A proxy server which attempts mapping and fails to get a 626 mapping MUST provide a default mapping. A suitable default mapping 627 would be the mapping obtained previously for the default location 628 appropriate for the caller. 630 ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route 631 an emergency call towards the PSAP's URI. 633 ED-58 Initial INVITES MUST provide an Offer [RFC3264]. 635 9. Signaling of emergency calls 637 ED-59 deleted 639 9.1. Use of TLS 641 ED-60/SP-31 TLS MUST be specified when attempting to signal an 642 emergency call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. 643 IPSEC [RFC3986] is an acceptable alternative. 645 ED-61/SP-32 If TLS session establishment fails, the call MUST be 646 retried without TLS. 648 ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain 649 persistent TLS connections between elements. 651 ED-63/AN-28 TLS MUST be specified when attempting to retrieve 652 location (configuration or dereferencing) with HELD. The use of 653 [RFC5077] is RECOMMENDED to minimize the time to establish TLS 654 sessions without keeping server-side state. 656 ED-64/AN-29 If TLS session establishment fails, the location 657 retrieval MUST be retried without TLS. 659 9.2. SIP signaling requirements for User Agents 661 ED-65 The initial SIP signaling method is an INVITE request: 662 1. The Request URI SHOULD be the service URN in the "sos" tree, If 663 the device cannot interpret local dial strings, the Request-URI 664 SHOULD be a dial string URI [RFC4967] with the dialed digits. 665 2. The To header SHOULD be a service URN in the "sos" tree. If the 666 device cannot interpret local dial strings, the To: SHOULD be a 667 dial string URI with the dialed digits. 669 3. The From header MUST be present and SHOULD be the AoR of the 670 caller. 671 4. A Via header MUST be present. 672 5. A Route header SHOULD be present with a PSAP URI obtained from 673 LoST (see Section 8) and the loose route parameter. If the 674 device does not interpret dial plans, or was unable to obtain a 675 route from a LoST server, no Route header will be present. 676 6. A Contact header MUST be present which MUST be globally 677 routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid 678 for several minutes following the termination of the call to 679 permit an immediate call-back to the specific device which 680 placed the emergency call. 681 7. Other headers MAY be included as per normal SIP behavior. 682 8. A Supported header MUST be included with the 'geolocation' 683 option tag [I-D.ietf-sip-location-conveyance], unless the device 684 does not understand the concept of SIP location. 685 9. If a device understands the SIP location conveyance 686 [I-D.ietf-sip-location-conveyance] extension and has its 687 location available, it MUST include location either by-value, 688 by-reference or both. 689 10. If a device understands the SIP Location Conveyance extension 690 and has its location unavailable or unknown to that device, it 691 MUST include a Supported header with a "geolocation" option tag, 692 and MUST NOT include a Geolocation header, and not include a 693 PIDF-LO message body. 694 11. If a device understands the SIP Location Conveyance extension 695 and supports LoST [RFC5222], the Geolocation "used-for-routing" 696 header parameter MUST be added to the corresponding URI in the 697 Geolocation header. If the device is unable to obtain a PSAP 698 URI for any reason it MUST NOT include "used-for-routing" on a 699 Geolocation URI, so that downstream entities know that LoST 700 routing has not been completed. 701 12. A SDP offer MUST be included in the INVITE. If voice is 702 supported the offer MUST include the G.711 codec, see 703 Section 14. 704 13. If the device includes location-by-value, the UA MUST support 705 multipart message bodies, since SDP will likely be also in the 706 INVITE. 707 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 708 on all Geolocation headers. This informs downstream elements 709 which device entered the location at this URI (either cid-URL or 710 location-by-reference URI). 711 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 712 PSAP should handle the call. For example, a language preference 713 expressed in an Accept-Language header may be used as a hint to 714 cause the PSAP to route the call to a call taker who speaks the 715 requested language. SIP Caller Preferences may also be used to 716 indicate a need to invoke a relay service for communication with 717 people with disabilities in the call. 719 9.3. SIP signaling requirements for proxy servers 721 SP-34 SIP Proxy servers processing emergency calls: 722 1. If the proxy interprets dial plans on behalf of user agents, the 723 proxy MUST look for the local emergency dial string at the 724 location of the end device and MAY look for the home dial string. 725 If it finds it, the proxy MUST: 726 * Insert a Geolocation header as above. Location-by-reference 727 MUST be used because proxies must not insert bodies. 728 * Include the Geolocation "inserted-by=server" and "used-for- 729 routing" parameters. 730 * Map the location to a PSAP URI using LoST. 731 * Add a Route header with the PSAP URI. 732 * Replace the Request-URI (which was the dial string) with the 733 service URN appropriate for the emergency dial string. 734 * Route the call using normal SIP routing mechanisms. 735 2. If the proxy recognizes the service URN in the Request URI, and 736 does not find a a Route header, it MUST query a LoST server. If 737 multiple locations were provided, the proxy uses the location 738 that has the "used-for-routing" marker set. If a location was 739 provided (which should be the case), the proxy uses that location 740 to query LoST. The proxy may have to dereference a location by 741 reference to get a value. If a location is not present, and the 742 proxy can query a LIS which has the location of the UA it MUST do 743 so. If no location is present, and the proxy does not have 744 access to a LIS which could provide location, the proxy MUST 745 supply a default location (See Section 6.11). The location (in 746 the signaling, obtained from a LIS, or default) MUST be used in a 747 query to LoST with the service URN received with the call. The 748 resulting URI MUST be placed in a Route header added to the call. 749 3. The "inserted-by=" parameter in any Geolocation: header received 750 on the call MUST NOT be modified or deleted in transit. 751 4. The proxy SHOULD NOT modify any parameters in Geolocation headers 752 received in the call. It MAY add a Geolocation header. Such an 753 additional location SHOULD NOT be used for routing; the location 754 provided by the UA should be used. 755 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 756 [RFC4474], or both, SHOULD be included to identify the sender. 757 For services which must support emergency calls from 758 unauthenticated devices, valid identity may not be available. 760 10. Call backs 762 ED-66/SP-35 Devices device SHOULD have a globally routable URI in a 763 Contact: header which remains valid for 30 minutes past the time the 764 original call containing the URI completes unless the device 765 registration expires and is not renewed. 767 SP-36 Call backs to the Contact: header URI recieved within 30 768 minutes of an emergency call must reach the device regardless of call 769 features or services that would normally cause the call to be routed 770 to some other entity. 772 SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- 773 Identity: header or From: protected by an Identity header suitable 774 for returning a call some time after the original call. Such a call 775 back would not necessarily reach the device that originally placed 776 the call. 778 11. Mid-call behavior 780 ED-67/SP-38 During the course of an emergency call, devices and 781 proxies MUST support REFER transactions and the Referred-by: header 782 [RFC3515]. 784 12. Call termination 786 ED-68 deleted 788 ED-69 There can be a case where the session signaling path is lost, 789 and the user agent does not receive the BYE. If the call is hung up, 790 and the session timer (if implemented) expires, the call MAY be 791 declared lost. If in the interval, an incoming call is received from 792 the domain of the PSAP, the device MUST drop the old call and alert 793 for the (new) incoming call. Dropping of the old call MUST only 794 occur if the user is attempting to hang up; the domain of an incoming 795 call can only be determined from the From header, which is not 796 reliable, and could be spoofed. Dropping an active call by a new 797 call with a spoofed From: would be a DoS attack. 799 13. Disabling of features 801 ED-70/SP-39 User Agents and proxies MUST disable outgoing call 802 features such as 803 o Call Waiting 804 o Call Transfer 805 o Three Way Call 806 o Hold, including Flash hold 807 o Outbound Call Blocking 808 when an emergency call is established. Also see ED-77 in Section 14. 810 ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in 811 Call Forward numbers or speed dial lists. 813 ED-72/SP-41 The User Agent and Proxies SHOULD disable the following 814 incoming call features on call backs from the PSAP: 815 o Call Waiting 816 o Do Not Disturb 817 o Call Forward (all kinds) 819 ED-73 Call backs SHOULD be determined by retaining the domain of the 820 PSAP which answers an outgoing emergency call and instantiating a 821 timer which starts when the call is terminated. If a call is 822 received from the same domain and within the timer period, sent to 823 the Contact: or AoR used in the emergency call, it should be assumed 824 to be a call back. The suggested timer period is 5 minutes. 826 14. Media 828 ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. 830 ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 831 agree on the media streams to be used. 833 ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law 834 if they are intended be used in North America) encoded voice as 835 described in [RFC3551]. It is desirable to include wideband codecs 836 such as AMR-WB in the offer. 838 ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT 839 be used on emergency calls. PSAP call takers sometimes get 840 information on what is happening in the background to determine how 841 to process the call. 843 ED-78 Endpoints supporting Instant Messaging (IM) MUST support both 844 [RFC3428] and [RFC4975]. 846 ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The 847 expectations for emergency service support for the real-time text 848 medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. 850 ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. 852 15. Testing 854 ED-81 INVITE requests to a service URN ending in ".test" indicates a 855 request for an automated test. For example, 856 "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response 857 indicates that the address was recognized and a 404 (Not found) that 858 it was not. A 486 (Busy Here) MUST be returned if the test service 859 is busy, and a 404 (Not found) MUST be returned if the PSAP does not 860 support the test mechanism. 862 ED-82 In its response to the test, the PSAP MAY include a text body 863 (text/plain) indicating the identity of the PSAP, the requested 864 service, and the location reported with the call. For the latter, 865 the PSAP SHOULD return location-by-value even if the original 866 location delivered with the test was by-reference. If the location- 867 by-reference was supplied, and the dereference requires credentials, 868 the PSAP SHOULD use credentials supplied by the LIS for test 869 purposes. This alerts the LIS that the dereference is not for an 870 actual emergency call and location hiding techniques, if they are 871 being used, may be employed for this dereference. The test response 872 SHOULD be protected with TLS. If the body cannot be protected, the 873 location SHOULD NOT be included in the response.. 875 ED-83 A PSAP accepting a test call SHOULD accept a media loopback 876 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 877 pkt-loopback" and "rtp-start-loopback" options. The user agent would 878 specify a loopback attribute of "loopback-source", the PSAP being the 879 mirror. User Agents should expect the PSAP to loop back no more than 880 3 packets of each media type accepted (which limits the duration of 881 the test), after which the PSAP would normally send BYE. 883 ED-84 User agents SHOULD perform a full call test, including media 884 loopback, after a disconnect and subsequent change in IP address not 885 due to a reboot. After an initial test, a full test SHOULD be 886 repeated approximately every 30 days with a random interval. 888 ED-85 User agents MUST NOT place a test call immediately after 889 booting. If the IP address changes after booting, the UA should wait 890 a random amount of time (in perhaps a 30 minute period, sufficient 891 for any avalanche restart to complete) and then test. 893 ED-86 PSAPs MAY refuse repeated requests for test from the same 894 device in a short period of time. Any refusal is signaled with a 486 895 or 488 response. 897 16. Security Considerations 899 Security considerations for emergency calling have been documented in 900 [RFC5069], and [I-D.barnes-geopriv-lo-sec]. 902 17. IANA Considerations 904 This document has no actions for IANA. 906 18. Acknowledgements 908 Work group members participating in the creation and review of this 909 document include include Hannes Tschofenig, Ted Hardie, Marc Linsner, 910 Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, 911 Barbara Stark, Richard Barnes and Peter Blatherwick. 913 19. References 915 19.1. Normative References 917 [I-D.ietf-geopriv-http-location-delivery] 918 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 919 "HTTP Enabled Location Delivery (HELD)", 920 draft-ietf-geopriv-http-location-delivery-13 (work in 921 progress), February 2009. 923 [I-D.ietf-geopriv-lis-discovery] 924 Thomson, M. and J. Winterbottom, "Discovering the Local 925 Location Information Server (LIS)", 926 draft-ietf-geopriv-lis-discovery-07 (work in progress), 927 February 2009. 929 [I-D.ietf-geopriv-pdif-lo-profile] 930 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 931 PIDF-LO Usage Clarification, Considerations and 932 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 933 (work in progress), November 2008. 935 [I-D.ietf-mmusic-media-loopback] 936 Hedayat, K., "An Extension to the Session Description 937 Protocol (SDP) for Media Loopback", 938 draft-ietf-mmusic-media-loopback-09 (work in progress), 939 August 2008. 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-12 (work in progress), 951 November 2008. 953 [I-D.ietf-sip-outbound] 954 Jennings, C. and R. Mahy, "Managing Client Initiated 955 Connections in the Session Initiation Protocol (SIP)", 956 draft-ietf-sip-outbound-16 (work in progress), 957 October 2008. 959 [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", 960 Dec 2004. 962 [LLDP-MED] 963 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 964 Endpoint Discovery". 966 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 967 Requirement Levels", BCP 14, RFC 2119, March 1997. 969 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 970 Messages", RFC 3118, June 2001. 972 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 973 A., Peterson, J., Sparks, R., Handley, M., and E. 974 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 975 June 2002. 977 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 978 Protocol (SIP): Locating SIP Servers", RFC 3263, 979 June 2002. 981 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 982 with Session Description Protocol (SDP)", RFC 3264, 983 June 2002. 985 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 986 Event Notification", RFC 3265, June 2002. 988 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 989 and D. Gurle, "Session Initiation Protocol (SIP) Extension 990 for Instant Messaging", RFC 3428, December 2002. 992 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 993 "STUN - Simple Traversal of User Datagram Protocol (UDP) 994 Through Network Address Translators (NATs)", RFC 3489, 995 March 2003. 997 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 998 Method", RFC 3515, April 2003. 1000 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1001 Jacobson, "RTP: A Transport Protocol for Real-Time 1002 Applications", STD 64, RFC 3550, July 2003. 1004 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1005 Video Conferences with Minimal Control", STD 65, RFC 3551, 1006 July 2003. 1008 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1009 Configuration Protocol Option for Coordinate-based 1010 Location Configuration Information", RFC 3825, July 2004. 1012 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1013 Preferences for the Session Initiation Protocol (SIP)", 1014 RFC 3841, August 2004. 1016 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1017 Initiation Protocol (SIP)", RFC 3856, August 2004. 1019 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1020 RFC 3966, December 2004. 1022 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 1023 M., and D. Singer, "RTP Payload Format for H.264 Video", 1024 RFC 3984, February 2005. 1026 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1027 Resource Identifier (URI): Generic Syntax", STD 66, 1028 RFC 3986, January 2005. 1030 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1031 Conversation", RFC 4103, June 2005. 1033 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1034 Format", RFC 4119, December 2005. 1036 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1037 Authenticated Identity Management in the Session 1038 Initiation Protocol (SIP)", RFC 4474, August 2006. 1040 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1041 (DHCPv4 and DHCPv6) Option for Civic Addresses 1042 Configuration Information", RFC 4776, November 2006. 1044 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1045 Initiation Protocol Uniform Resource Identifier", 1046 RFC 4967, July 2007. 1048 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1049 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1051 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1052 Emergency and Other Well-Known Services", RFC 5031, 1053 January 2008. 1055 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1056 Format for Presence Information Data Format Location 1057 Object (PIDF-LO)", RFC 5139, February 2008. 1059 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1060 Tschofenig, "LoST: A Location-to-Service Translation 1061 Protocol", RFC 5222, August 2008. 1063 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1064 Location-to-Service Translation (LoST) Servers Using the 1065 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1066 August 2008. 1068 19.2. Informative References 1070 [I-D.barnes-geopriv-lo-sec] 1071 Barnes, R., Lepinski, M., Tschofenig, H., and H. 1072 Schulzrinne, "Additional Location Privacy Considerations", 1073 draft-barnes-geopriv-lo-sec-04 (work in progress), 1074 January 2009. 1076 [I-D.ietf-ecrit-framework] 1077 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1078 "Framework for Emergency Calling using Internet 1079 Multimedia", draft-ietf-ecrit-framework-07 (work in 1080 progress), January 2009. 1082 [I-D.ietf-sip-sips] 1083 Audet, F., "The use of the SIPS URI Scheme in the Session 1084 Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work 1085 in progress), November 2008. 1087 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1088 Extensions to the Session Initiation Protocol (SIP) for 1089 Asserted Identity within Trusted Networks", RFC 3325, 1090 November 2002. 1092 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1093 Emergency Context Resolution with Internet Technologies", 1094 RFC 5012, January 2008. 1096 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1097 Shanmugam, "Security Threats and Requirements for 1098 Emergency Call Marking and Mapping", RFC 5069, 1099 January 2008. 1101 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1102 "Transport Layer Security (TLS) Session Resumption without 1103 Server-Side State", RFC 5077, January 2008. 1105 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 1106 over IP Using the Session Initiation Protocol (SIP)", 1107 RFC 5194, June 2008. 1109 Appendix A. BCP Requirements Sorted by Responsible Party 1111 A.1. Requirements of End Devices 1113 ED-1 A device or application SHOULD support emergency calling if a 1114 user could reasonably expect to be able to place a call for help with 1115 the device. Some jurisdictions have regulations governing this. 1117 ED-2 Devices that create media sessions and exchange audio, video 1118 and/or text, and have the capability to establish sessions to a wide 1119 variety of addresses, and communicate over private IP networks or the 1120 Internet, SHOULD support emergency calls. Some jurisdictions have 1121 regulations governing this. 1123 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 1124 the service provider always knows the location of the device, then 1125 the service provider could recognize them. 1127 ED-4 Emergency calls MUST be marked with a Service URN in the 1128 Request-URI of the INVITE. 1130 ED-5 Local dial strings MUST be recognized. 1132 ED-7 Emergency dial strings SHOULD be determined from LoST [RFC5222]. 1133 Dial Strings MAY be configured directly in the device. 1135 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 1136 send dial strings as per [RFC4967]. 1138 ED-9 Endpoints SHOULD be able to have home dial strings provisioned 1139 by configuration. 1141 ED-10 Devices SHOULD NOT have one button emergency calling 1142 initiation. 1144 ED-11 All emergency services specified in [RFC5031] MUST be 1145 recognized. 1147 ED-12 Endpoints, Intermediate Devices and Service Providers MUST be 1148 prepared to handle location represented in either civic or geo form. 1150 ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from 1151 the form of location the determination mechanism supplied. 1153 ED-14 Any suitable location determination mechanism MAY be used. 1155 ED-15 Devices, intermediate Devices and/or access networks SHOULD 1156 support a manual method to "override" the location the access network 1157 determines. Where a civic form of location is provided, all fields 1158 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1160 ED-16 Devices MAY support end-system measured location. Uncertainty 1161 of less than 100 m with 95% confidence SHOULD be available for 1162 dispatch. 1164 ED-17 Devices that support endpoint measuring of location MUST have 1165 at least a coarse location capability (typically <1km accuracy when 1166 not location hiding) for routing of calls. The location mechanism 1167 MAY be a service provided by the access network. 1169 ED-18 Endpoints SHOULD attempt to configure their own location using 1170 the LCPs listed in ED-21. 1172 ED-19 Where proxies provide location on behalf of endpoints, the 1173 service provider MUST ensure that either the end device is provided 1174 with the local dial strings for its current location (where the end 1175 device recognizes dial strings), or the service provider proxy MUST 1176 detect the appropriate local dial strings at the time of the call. 1178 ED-20 Devices SHOULD be able to accept and forward location by value 1179 or by reference. An end device that receives location by reference 1180 (and does not also get the corresponding value) MUST be able to 1181 perform a dereference operation to obtain a value. 1183 ED-21 Devices MUST support both the DHCP location options [RFC4776], 1184 [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When 1185 devices deploy a specific access network interface in which that 1186 access network supports location discovery such as LLDP-MED or 1187 802.11v, the device SHOULD support the additional respective access 1188 network specific location discovery mechanism. 1190 ED-22 Endpoints SHOULD try all LCPs supported by the device in any 1191 order or in parallel. The first one that succeeds in supplying 1192 location can be used. 1194 ED-23 When HELD is the LCP, the request MUST specify a value of 1195 "emergencyRouting" for the "responseTime" parameter and use the 1196 resulting location for routing. If a value for dispatch location 1197 will be sent, another request with the "responseTime" parameter set 1198 to "emergencyDispatch" must be completed, with the result sent for 1199 dispatch purposes. 1201 ED-24 Where the operating system supporting application programs 1202 which need location for emergency calls does not allow access to 1203 Layer 2 and Layer 3 functions necessary for a client application to 1204 use DHCP location options and/or LLDP-MED, the operating system MUST 1205 provide a published API conforming to ED-12 through ED-21 and ED-21 1206 through ED-31. It is RECOMMENDED that all operating systems provide 1207 such an API. 1209 ED-25 Endpoints SHOULD obtain location immediately after obtaining 1210 local network configuration information. When HELD is the LCP the 1211 client MUST support a random back-off period (between 30 seconds and 1212 300 seconds) for re-trying the HELD query, when no response is 1213 received, and no other LCP provided location information. 1215 ED-26 If the device is configured to use DHCP for bootstrapping, it 1216 MUST include both options for location acquisition (civic and 1217 geodetic), the option for LIS discovery, and the option for LoST 1218 discovery as defined in [RFC4776], [RFC3825], 1219 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 1221 ED-27 If the device sends a DHCPINFORM message, it MUST include both 1222 options for location acquisition (civic and geodetic), the option for 1223 LIS discovery, and the option for LoST discovery as defined in 1224 [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 1226 ED-28 To minimize the effects of VPNs that do not allow packets to be 1227 sent via the native hardware interface rather than via the VPN 1228 tunnel, location configuration SHOULD be attempted before such 1229 tunnels are established. 1231 ED-29 Software which uses LCPs SHOULD locate and use the actual 1232 hardware network interface rather than a VPN tunnel interface to 1233 direct LCP requests to the LIS in the actual access network. 1235 ED-30 For devices which are not expected to roam, refreshing location 1236 on the order of once per day is RECOMMENDED. 1238 ED-31 For devices which roam, refresh of location information SHOULD 1239 be more frequent, with the frequency related to the mobility of the 1240 device and the ability of the access network to support the refresh 1241 operation. If the device can detect that it has moved, for example 1242 when it changes access points, the device SHOULD refresh its 1243 location. 1245 ED-32 It is RECOMMENDED that location determination not take longer 1246 than 250 ms to obtain routing location and systems SHOULD be designed 1247 such that the typical response is under 100 ms. However, as much as 1248 3 seconds to obtain routing location MAY be tolerated if location 1249 accuracy can be substantially improved over what can be obtained in 1250 250 ms. 1252 ED-33 Location sent between SIP elements MUST be conveyed using 1253 [I-D.ietf-sip-location-conveyance]. 1255 ED-34 Where the absolute location or the accuracy of location of the 1256 endpoint may change between the time the call is received at the PSAP 1257 and the time dispatch is completed, location update mechanisms MUST 1258 be provided. 1260 ED-35 Mobile devices MUST be provided with a mechanism to get 1261 repeated location updates to track the motion of the device during 1262 the complete processing of the call. 1264 ED-36 The LIS SHOULD provide a location reference which permits a 1265 subscription with appropriate filtering. 1267 ED-37 For calls sent with location-by-reference, with a SIP or SIPS 1268 scheme, the server resolving the reference MUST support a SUBSCRIBE 1269 [RFC3265] to the presence event [RFC3856]. For other location-by- 1270 reference schemes that do not support subscription, the PSAP will 1271 have to repeatedly dereference the URI to determine if the device 1272 moved. 1274 ED-38 If location was sent by value, and the endpoint gets updated 1275 location, it MUST send the updated location to the PSAP via a SIP re- 1276 INVITE or UPDATE request. Such updates SHOULD be limited to no more 1277 than one update every 10 seconds. 1279 ED-39 If the LIS has more than one location for an endpoint it MUST 1280 use the procedures in [I-D.ietf-geopriv-pdif-lo-profile] 1282 ED-40 If a UA has more than one location available to it, it MUST 1283 choose one location to route the call towards the PSAP. If multiple 1284 locations are in a single PIDF, the procedures in 1285 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. If the UA has 1286 multiple PIDFs, and has no reasonable basis to choose from among 1287 them, a random choice is acceptable. 1289 ED-41 Location objects MUST contain information about the method by 1290 which the location was determined, such as GPS, manually entered, or 1291 based on access network topology included in a PIDF- LO "method" 1292 element. In addition, the source of the location information MUST be 1293 included in a PIDF-LO "provided-by" element. 1295 ED-42 The "used-for-routing" parameter MUST be set to the location 1296 that was chosen for routing. 1298 ED-43 Endpoints SHOULD validate civic locations when they receive 1299 them from their LCP. Validation SHOULD be performed in conjunction 1300 with the LoST route query to minimize load on the LoST server. 1302 ED-44 If the LCP does not return location in the form of a PIDF-LO 1303 [RFC4119], the endpoint MUST map the location information it receives 1304 from the configuration protocol to a PIDF-LO. 1306 ED-45 To prevent against spoofing of the DHCP server, elements 1307 implementing DHCP for location configuration SHOULD use [RFC3118] 1308 although the difficulty in providing appropriate credentials is 1309 significant. 1311 ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header 1312 or bodies. 1314 ED-47 TLS MUST be used to protect location (but see Section 9.1). 1315 IPSEC [RFC3986] is an acceptable alternative. 1317 ED-48 Endpoints MUST support one or more mechanisms that allow them 1318 to determine their public IP address. Examples include STUN 1319 [RFC3489] and HTTP get. 1321 ED-49 Endpoints MUST support LIS discovery as described in 1322 [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described 1323 in [RFC5223]. 1325 ED-50 The device MUST have a configurable default LoST server 1326 parameter. If the device is provided by or managed by a service 1327 provider, it is expected that the service provider will configure 1328 this option. 1330 ED-51 DHCP LoST discovery MUST be used, if available, in preference 1331 to configured LoST servers. If neither DHCP nor configuration leads 1332 to an available LoST server, the device MUST query DNS using it's SIP 1333 domain for an SRV record for a LoST service and use that server. 1335 ED-52 When an endpoint has obtained a LoST server via an discovery 1336 mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered 1337 LoST server over LoST servers configured by other means. That is, 1338 the endpoint MUST send queries to this LoST server first, using other 1339 LoST servers only if these queries fail. 1341 ED-53 Endpoints who obtain their own location SHOULD perform LoST 1342 mapping to the PSAP URI. 1344 ED-54 Mapping SHOULD be performed at boot time and whenever location 1345 changes beyond the service boundary obtained from a prior LoST 1346 mapping operation or the time-to-live value of that response has 1347 expired. The value MUST be cached for possible later use. 1349 ED-55 The endpoint MUST attempt to update its location at the time of 1350 an emergency call. If it cannot obtain a new location quickly (see 1351 Section 6), it MUST use the cached value. 1353 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 1354 time of an emergency call. If it cannot obtain a new mapping 1355 quickly, it MUST use the cached value. If the device cannot update 1356 the LoST mapping and does not have a cached value, it MUST signal an 1357 emergency call without a Route header containing a PSAP URI. 1359 ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an 1360 emergency call towards the PSAP's URI. 1362 ED-58 Initial INVITES MUST provide an Offer [RFC3264]. 1364 ED-59 deleted 1366 ED-60 TLS MUST be specified when attempting to signal an emergency 1367 call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. IPSEC 1368 [RFC3986] is an acceptable alternative. 1370 ED-61 If TLS session establishment fails, the call MUST be retried 1371 without TLS. 1373 ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent 1374 TLS connections between elements. 1376 ED-63 TLS MUST be specified when attempting to retrieve location 1377 (configuration or dereferencing) with HELD. The use of [RFC5077] is 1378 RECOMMENDED to minimize the time to establish TLS sessions without 1379 keeping server-side state. 1381 ED-64 If TLS session establishment fails, the location retrieval MUST 1382 be retried without TLS. 1384 ED-65 The initial SIP signaling method is an INVITE request: 1385 1. The Request URI SHOULD be the service URN in the "sos" tree, If 1386 the device cannot interpret local dial strings, the Request-URI 1387 SHOULD be a dial string URI [RFC4967] with the dialed digits. 1388 2. The To header SHOULD be a service URN in the "sos" tree. If the 1389 device cannot interpret local dial strings, the To: SHOULD be a 1390 dial string URI with the dialed digits. 1391 3. The From header MUST be present and SHOULD be the AoR of the 1392 caller. 1393 4. A Via header MUST be present. 1394 5. A Route header SHOULD be present with a PSAP URI obtained from 1395 LoST (see Section 8) and the loose route parameter. If the 1396 device does not interpret dial plans, or was unable to obtain a 1397 route from a LoST server, no Route header will be present. 1398 6. A Contact header MUST be present which MUST be globally 1399 routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid 1400 for several minutes following the termination of the call to 1401 permit an immediate call-back to the specific device which 1402 placed the emergency call. 1403 7. Other headers MAY be included as per normal SIP behavior. 1404 8. A Supported header MUST be included with the 'geolocation' 1405 option tag [I-D.ietf-sip-location-conveyance], unless the device 1406 does not understand the concept of SIP location. 1407 9. If a device understands the SIP location conveyance 1408 [I-D.ietf-sip-location-conveyance] extension and has its 1409 location available, it MUST include location either by-value, 1410 by-reference or both. 1411 10. If a device understands the SIP Location Conveyance extension 1412 and has its location unavailable or unknown to that device, it 1413 MUST include a Supported header with a "geolocation" option tag, 1414 and MUST NOT include a Geolocation header, and not include a 1415 PIDF-LO message body. 1416 11. If a device understands the SIP Location Conveyance extension 1417 and supports LoST [RFC5222], the Geolocation "used-for-routing" 1418 header parameter MUST be added to the corresponding URI in the 1419 Geolocation header. If the device is unable to obtain a PSAP 1420 URI for any reason it MUST NOT include "used-for-routing" on a 1421 Geolocation URI, so that downstream entities know that LoST 1422 routing has not been completed. 1424 12. A SDP offer MUST be included in the INVITE. If voice is 1425 supported the offer MUST include the G.711 codec, see 1426 Section 14. 1427 13. If the device includes location-by-value, the UA MUST support 1428 multipart message bodies, since SDP will likely be also in the 1429 INVITE. 1430 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 1431 on all Geolocation headers. This informs downstream elements 1432 which device entered the location at this URI (either cid-URL or 1433 location-by-reference URI). 1434 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 1435 PSAP should handle the call. For example, a language preference 1436 expressed in an Accept-Language header may be used as a hint to 1437 cause the PSAP to route the call to a call taker who speaks the 1438 requested language. SIP Caller Preferences may also be used to 1439 indicate a need to invoke a relay service for communication with 1440 people with disabilities in the call. 1442 ED-66 Devices device SHOULD have a globally routable URI in a 1443 Contact: header which remains valid for 30 minutes past the time the 1444 original call containing the URI completes unless the device 1445 registration expires and is not renewed. 1447 ED-67 During the course of an emergency call, devices and proxies 1448 MUST support REFER transactions and the Referred-by: header 1449 [RFC3515]. 1451 ED-68 deleted 1453 ED-69 There can be a case where the session signaling path is lost, 1454 and the user agent does not receive the BYE. If the call is hung up, 1455 and the session timer (if implemented) expires, the call MAY be 1456 declared lost. If in the interval, an incoming call is received from 1457 the domain of the PSAP, the device MUST drop the old call and alert 1458 for the (new) incoming call. Dropping of the old call MUST only 1459 occur if the user is attempting to hang up; the domain of an incoming 1460 call can only be determined from the From header, which is not 1461 reliable, and could be spoofed. Dropping an active call by a new 1462 call with a spoofed From: would be a DoS attack. 1464 ED-70 User Agents and proxies MUST disable outgoing call features 1465 such as 1466 o Call Waiting 1467 o Call Transfer 1468 o Three Way Call 1469 o Flash hold 1470 o Outbound Call Blocking 1471 when an emergency call is established. Also see ED-77 in Section 14. 1473 ED-71 The emergency dial strings SHOULD NOT be permitted in Call 1474 Forward numbers or speed dial lists. 1476 ED-72 The User Agent and Proxies SHOULD disable the following 1477 incoming call features on call backs from the PSAP: 1478 o Call Waiting 1479 o Do Not Disturb 1480 o Call Forward (all kinds) 1482 ED-73 Call backs SHOULD be determined by retaining the domain of the 1483 PSAP which answers an outgoing emergency call and instantiating a 1484 timer which starts when the call is terminated. If a call is 1485 received from the same domain and within the timer period, sent to 1486 the Contact: or AoR used in the emergency call, it should be assumed 1487 to be a call back. The suggested timer period is 5 minutes. 1489 ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. 1491 ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 1492 agree on the media streams to be used. 1494 ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law 1495 if they are intended be used in North America) encoded voice as 1496 described in [RFC3551]. It is desirable to include wideband codecs 1497 such as AMR-WB in the offer. 1499 ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT 1500 be used on emergency calls. PSAP call takers sometimes get 1501 information on what is happening in the background to determine how 1502 to process the call. 1504 ED-78 Endpoints supporting Instant Messaging (IM) MUST support both 1505 [RFC3428] and [RFC4975]. 1507 ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The 1508 expectations for emergency service support for the real-time text 1509 medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. 1511 ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. 1513 ED-81 INVITE requests to a service URN ending in ".test" indicates a 1514 request for an automated test. For example, 1515 "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response 1516 indicates that the address was recognized and a 404 (Not found) that 1517 it was not. A 486 (Busy Here) MUST be returned if the test service 1518 is busy, and a 404 (Not Found) MUST be returned if the PSAP does not 1519 support the test mechanism. 1521 ED-82 In its response to the test, the PSAP MAY include a text body 1522 (text/plain) indicating the identity of the PSAP, the requested 1523 service, and the location reported with the call. For the latter, 1524 the PSAP SHOULD return location-by-value even if the original 1525 location delivered with the test was by-reference. If the location- 1526 by-reference was supplied, and the dereference requires credentials, 1527 the PSAP SHOULD use credentials supplied by the LIS for test 1528 purposes. This alerts the LIS that the dereference is not for an 1529 actual emergency call and location hiding techniques, if they are 1530 being used, may be employed for this dereference. The test response 1531 SHOULD be protected with TLS. If the body cannot be protected, the 1532 location SHOULD NOT be included in the response. 1534 ED-83 A PSAP accepting a test call SHOULD accept a media loopback 1535 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 1536 pkt-loopback" and "rtp-start-loopback" options. The user agent would 1537 specify a loopback attribute of "loopback-source", the PSAP being the 1538 mirror. User Agents should expect the PSAP to loop back no more than 1539 3 packets of each media type accepted (which limits the duration of 1540 the test), after which the PSAP would normally send BYE. 1542 ED-84 User agents SHOULD perform a full call test, including media 1543 loopback, after a disconnect and subsequent change in IP address not 1544 due to a reboot. After an initial test, a full test SHOULD be 1545 repeated approximately every 30 days with a random interval. 1547 ED-85 User agents MUST NOT place a test call immediately after 1548 booting. If the IP address changes after booting, the UA should wait 1549 a random amount of time (in perhaps a 30 minute period, sufficient 1550 for any avalanche restart to complete) and then test. 1552 ED-86 PSAPs MAY refuse repeated requests for test from the same 1553 device in a short period of time. Any refusal is signaled with a 486 1554 or 488 response. 1556 A.2. Requirements of Service Providers 1558 SP-1 If a device or application expects to be able to place a call 1559 for help, the service provider that supports it MUST facilitate 1560 emergency calling. Some jurisdictions have regulations governing 1561 this. 1563 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 1564 some reason the endpoint does not recognize them. This cannot be 1565 relied upon by the device if the service provider cannot always 1566 determine the location of the device. 1568 SP-3 Emergency calls MUST be marked with a Service URN in the 1569 Request-URI of the INVITE. 1571 SP-4 Local dial strings MUST be recognized. 1573 SP-6 Emergency dial strings SHOULD be determined from LoST [RFC5222]. 1574 Dial Strings MAY be configured directly in the device. 1576 SP-7 If a proxy server recognizes dial strings on behalf of its 1577 clients it MUST recognize emergency dial strings represented by 1578 [RFC4967] and SHOULD recognize emergency dial strings represented by 1579 a tel URI [RFC3966]. 1581 SP-8 Service providers MAY provide home dial strings by 1582 configuration. 1584 SP-9 All emergency services specified in [RFC5031] MUST be 1585 recognized. 1587 SP-10 Endpoints, Intermediate Devices and Service Providers MUST be 1588 prepared to handle location represented in either civic or geo form. 1590 SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from 1591 the form of location the determination mechanism supplied. 1593 SP-12 Proxies MAY provide location on behalf of devices if: 1594 o The proxy has a relationship with all access networks the device 1595 could connect to, and the relationship allows it to obtain 1596 location. 1597 o The proxy has an identifier, such as an IP address, that can be 1598 used by the access network to determine the location of the 1599 endpoint, even in the presence of NAT and VPN tunnels that may 1600 obscure the identifier between the access network and the service 1601 provider. 1603 SP-13 Where proxies provide location on behalf of endpoints, the 1604 service provider MUST ensure that either the end device is provided 1605 with the local dial strings for its current location (where the end 1606 device recognizes dial strings), or the service provider proxy MUST 1607 detect the appropriate local dial strings at the time of the call. 1609 SP-14 When HELD is the LCP, the request MUST specify a value of 1610 "emergencyRouting" for the "responseTime" parameter and use the 1611 resulting location for routing. If a value for dispatch location 1612 will be sent, another request with the "responseTime" parameter set 1613 to "emergencyDispatch" must be completed, with the result sent for 1614 dispatch purposes. 1616 SP-15 Location sent between SIP elements MUST be conveyed using 1617 [I-D.ietf-sip-location-conveyance]. 1619 SP-16 If the LIS has more than one location for an endpoint it MUST 1620 use the procedures in [I-D.ietf-geopriv-pdif-lo-profile] 1622 SP-17 If a proxy inserts location on behalf of an endpoint, and it 1623 has multiple locations available for the endpoint it MUST choose one 1624 location to use to route the call towards the PSAP. 1626 SP-18 If a proxy is attempting to insert location but the UA conveyed 1627 a location to it, the proxy MUST use the UA's location for routing 1628 and MUST convey that location towards the PSAP. It MAY also include 1629 what it believes the location to be in a separate Geolocation header. 1631 SP-19 All location objects received by a proxy MUST be delivered to 1632 the PSAP. 1634 SP-20 Location objects MUST contain information about the method by 1635 which the location was determined, such as GPS, manually entered, or 1636 based on access network topology included in a PIDF- LO "method" 1637 element. In addition, the source of the location information MUST be 1638 included in a PIDF-LO "provided-by" element. 1640 SP-21 The "used-for-routing" parameter MUST be set to the location 1641 that was chosen for routing. 1643 SP-22 Proxies handling emergency calls MUST insert a default location 1644 if the call does not contain a location and the proxy does not have a 1645 method for obtaining a better location. 1647 SP-23 Default locations MUST be marked with method=Default and the 1648 proxy MUST be identified in provided-by element of the PIDF-LO. 1650 SP-24 TLS MUST be used to protect location (but see Section 9.1). 1651 IPSEC [RFC3986] is an acceptable alternative. 1653 SP-25 Service Providers MUST provide an SRV entry in their DNS server 1654 which leads to a LoST server 1656 SP-26 Networks MUST be designed so that at least one proxy in the 1657 outbound path will recognize emergency calls with a Request URI of 1658 the service URN in the "sos" tree. An endpoint places a service URN 1659 in the Request URI to indicate that the endpoint understood the call 1660 was an emergency call. A proxy that processes such a call looks for 1661 the presence of a SIP Route header field with a URI of a PSAP. 1663 Absence of such a Route header indicates the UAC was unable to invoke 1664 LoST and the proxy MUST perform the LoST mapping and insert a Route 1665 header field with the URI obtained. 1667 SP-27 To deal with old user agents that predate this specification 1668 and with UAs that do not have access to their own location data, a 1669 proxy that recognizes a call as an emergency call that is not marked 1670 as such (see Section 5) MUST also perform this mapping, with the best 1671 location it has available for the endpoint. The resulting PSAP URI 1672 would be placed in a Route header with the service URN in the Request 1673 URI. 1675 SP-28 Proxy servers performing mapping SHOULD use location obtained 1676 from the access network for the mapping. If no location is 1677 available, a default location (see Section 6.11) MUST be supplied. 1679 SP-29 A proxy server which attempts mapping and fails to get a 1680 mapping MUST provide a default mapping. A suitable default mapping 1681 would be the mapping obtained previously for the default location 1682 appropriate for the caller. 1684 SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an 1685 emergency call towards the PSAP's URI. 1687 SP-31 TLS MUST be specified when attempting to signal an emergency 1688 call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. IPSEC 1689 [RFC3986] is an acceptable alternative. 1691 SP-32 If TLS session establishment fails, the call MUST be retried 1692 without TLS. 1694 SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent 1695 TLS connections between elements. 1697 SP-34 SIP Proxy servers processing emergency calls: 1698 1. If the proxy interprets dial plans on behalf of user agents, the 1699 proxy MUST look for the local emergency dial string at the 1700 location of the end device and MAY look for the home dial string. 1701 If it finds it, the proxy MUST: 1702 * Insert a Geolocation header as above. Location-by-reference 1703 MUST be used because proxies must not insert bodies. 1704 * Include the Geolocation "inserted-by=server" and "used-for- 1705 routing" parameters. 1706 * Map the location to a PSAP URI using LoST. 1707 * Add a Route header with the PSAP URI. 1708 * Replace the Request-URI (which was the dial string) with the 1709 service URN appropriate for the emergency dial string. 1711 * Route the call using normal SIP routing mechanisms. 1712 2. If the proxy recognizes the service URN in the Request URI, and 1713 does not find a a Route header, it MUST query a LoST server. If 1714 multiple locations were provided, the proxy uses the location 1715 that has the "used-for-routing" marker set. If a location was 1716 provided (which should be the case), the proxy uses that location 1717 to query LoST. The proxy may have to dereference a location by 1718 reference to get a value. If a location is not present, and the 1719 proxy can query a LIS which has the location of the UA it MUST do 1720 so. If no location is present, and the proxy does not have 1721 access to a LIS which could provide location, the proxy MUST 1722 supply a default location (See Section 6.11). The location (in 1723 the signaling, obtained from a LIS, or default) MUST be used in a 1724 query to LoST with the service URN received with the call. The 1725 resulting URI MUST be placed in a Route header added to the call. 1726 3. The "inserted-by=" parameter in any Geolocation: header received 1727 on the call MUST NOT be modified or deleted in transit. 1728 4. The proxy SHOULD NOT modify any parameters in Geolocation headers 1729 received in the call. It MAY add a Geolocation header. Such an 1730 additional location SHOULD NOT be used for routing; the location 1731 provided by the UA should be used. 1732 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 1733 [RFC4474], or both, SHOULD be included to identify the sender. 1734 For services which must support emergency calls from 1735 unauthenticated devices, valid identity may not be available. 1737 SP-35 Devices device SHOULD have a globally routable URI in a 1738 Contact: header which remains valid for 30 minutes past the time the 1739 original call containing the URI completes unless the device 1740 registration expires and is not renewed. 1742 SP-36 Call backs to the Contact: header URI recieved within 30 1743 minutes of an emergency call must reach the device regardless of call 1744 features or services that would normally cause the call to be routed 1745 to some other entity. 1747 SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- 1748 Identity: header or From: protected by an Identity header suitable 1749 for returning a call some time after the original call. Such a call 1750 back would not necessarily reach the device that originally placed 1751 the call. 1753 SP-38 During the course of an emergency call, devices and proxies 1754 MUST support REFER transactions and the Referred-by: header 1755 [RFC3515]. 1757 SP-39 User Agents and proxies MUST disable outgoing call features 1758 such as 1759 o Call Waiting 1760 o Call Transfer 1761 o Three Way Call 1762 o Flash hold 1763 o Outbound Call Blocking 1764 when an emergency call is established. Also see ED-77 in Section 14. 1766 SP-40 The emergency dial strings SHOULD NOT be permitted in Call 1767 Forward numbers or speed dial lists. 1769 SP-41 The User Agent and Proxies SHOULD disable the following 1770 incoming call features on call backs from the PSAP: 1771 o Call Waiting 1772 o Do Not Disturb 1773 o Call Forward (all kinds) 1775 A.3. Requirements of Access Network 1777 AN-1 LoST servers MUST return dial strings for emergency services 1779 AN-2 Elements MUST NOT convert (civic to geo or geo to civic) from 1780 the form of location the determination mechanism supplied. 1782 AN-3 Any suitable location determination mechanism MAY be used. 1784 AN-4 Devices, intermediate Devices and/or access networks SHOULD 1785 support a manual method to "override" the location the access network 1786 determines. Where a civic form of location is provided, all fields 1787 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1789 AN-5 Access networks supporting copper, fiber or other hard wired IP 1790 packet service SHOULD support location configuration. If the network 1791 does not support location configuration, it MUST require every device 1792 that connects to the network to support end system measured location. 1794 AN-6 Access networks and intermediate devices providing wire database 1795 location information SHOULD provide interior location data (building, 1796 floor, room, cubicle) where possible. It is RECOMMENDED that 1797 interior location be provided when spaces exceed approximately 650 1798 square meters. 1800 AN-7 Access networks and intermediate devices (including enterprise 1801 networks) which support intermediate range wireless connections 1802 (typically 100m or less of range) and which do not support a more 1803 accurate location determination mechanism such as triangulation, MUST 1804 support location configuration where the location of the access point 1805 is reflected as the location of the clients of that access point. 1806 Where the access network provides location configuration, 1807 intermediate devices MUST either be transparent to it, or provide an 1808 interconnected client for the supported configuration mechanism and a 1809 server for a configuration protocol supported by end devices 1810 downstream of the intermediate device 1812 AN-8 Devices that support endpoint measuring of location MUST have at 1813 least a coarse location capability (typically <1km accuracy when not 1814 location hiding) for routing of calls. The location mechanism MAY be 1815 a service provided by the access network. 1817 AN-9 Access networks MAY provide network-measured location 1818 determination. Wireless access network which do not support network 1819 measured location MUST require that all devices connected to the 1820 network have end-system measured location. Uncertainty of less than 1821 100 m with 95% confidence SHOULD be available for dispatch. 1823 AN-10 Access networks that provide network measured location MUST 1824 have at least a coarse location (typically <1km when not location 1825 hiding) capability at all times for routing of calls. 1827 AN-11 Access networks with range of <10 meters (e.g. personnal area 1828 networks such as Bluetooth MUST provide a location to mobile devices 1829 connected to them. The location provided SHOULD be that of the 1830 access point location unless a more accurate mechanism is provided. 1832 AN-12 The access network MUST support either DHCP location options or 1833 HELD. The access network SHOULD support other location technologies 1834 that are specific to the type of access network. 1836 AN-13 Where a router is employed between a LAN and WAN in a small 1837 (less than approximately 650 square meters) area, the router MUST be 1838 transparent to the location provided by the WAN to the LAN. This may 1839 mean the router must obtain location as a client from the WAN, and 1840 supply an LCP server to the LAN with the location it obtains. Where 1841 the area is larger, the LAN MUST have a location configuration 1842 mechanism meeting this BCP. 1844 AN-14 Access networks that support more than one LCP MUST reply with 1845 the same location information (within the limits of the data format 1846 for the specific LCP) for all LCPs it supports. 1848 AN-15 Network administrators MUST take care in assigning IP addresses 1849 such that VPN address assignments can be distinguished from local 1850 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 1851 to provide location to addresses that arrive via VPN connections 1852 unless it can accurately determine the location for such addresses. 1854 AN-16 Placement of NAT devices where an LCP uses IP address for an 1855 identifier SHOULD consider the effect of the NAT on the LCP. The 1856 address used to query the LIS MUST be able to correctly identify the 1857 record in the LIS representing the location of the querying device 1859 AN-17 It is RECOMMENDED that location determination not take longer 1860 than 250 ms to obtain routing location and systems SHOULD be designed 1861 such that the typical response is under 100 ms. However, as much as 1862 3 seconds to obtain routing location MAY be tolerated if location 1863 accuracy can be substantially improved over what can be obtained in 1864 250 ms. 1866 AN-18 Where the absolute location or the accuracy of location of the 1867 endpoint may change between the time the call is received at the PSAP 1868 and the time dispatch is completed, location update mechanisms MUST 1869 be provided. 1871 AN-19 Mobile devices MUST be provided with a mechanism to get 1872 repeated location updates to track the motion of the device during 1873 the complete processing of the call. 1875 AN-20 The LIS SHOULD provide a location reference which permits a 1876 subscription with appropriate filtering. 1878 AN-21 For calls sent with location-by-reference, with a SIP or SIPS 1879 scheme, the server resolving the reference MUST support a SUBSCRIBE 1880 [RFC3265] to the presence event [RFC3856]. For other location-by- 1881 reference schemes that do not support subscription, the PSAP will 1882 have to repeatedly dereference the URI to determine if the device 1883 moved. 1885 AN-22 A LIS should perform location validation of civic locations via 1886 LoST before entering a location in its database. 1888 AN-23 When the access network cannot determine the actual location of 1889 the caller, it MUST supply a default location. The default SHOULD be 1890 chosen to be as close to the probable location of the device as the 1891 network can determine. See [I-D.ietf-ecrit-framework] 1893 AN-24 Default locations MUST be marked with method=Default and the 1894 proxy MUST be identified in provided-by element of the PIDF-LO. 1896 AN-25 To prevent against spoofing of the DHCP server, elements 1897 implementing DHCP for location configuration SHOULD use [RFC3118] 1898 although the difficulty in providing appropriate credentials is 1899 significant. 1901 AN-26 Access networks which support DHCP MUST implement the LoST 1902 discovery option 1903 AN-27 Access Networks that use HELD and that have a DHCP server 1904 SHOULD support DHCP options for providing LIS and LoST servers. 1906 AN-28 TLS MUST be specified when attempting to retrieve location 1907 (configuration or dereferencing) with HELD. The use of [RFC5077] is 1908 RECOMMENDED to minimize the time to establish TLS sessions without 1909 keeping server-side state. 1911 AN-29 If TLS session establishment fails, the location retrieval MUST 1912 be retried without TLS. 1914 A.4. Requirements of Intermediate Devices 1916 INT-1 Endpoints, Intermediate Devices and Service Providers MUST be 1917 prepared to handle location represented in either civic or geo form. 1919 INT-2 Elements MUST NOT convert (civic to geo or geo to civic) from 1920 the form of location the determination mechanism supplied. 1922 INT-3 Any suitable location determination mechanism MAY be used. 1924 INT-4 Devices, intermediate Devices and/or access networks SHOULD 1925 support a manual method to "override" the location the access network 1926 determines. Where a civic form of location is provided, all fields 1927 in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. 1929 INT-5 Access networks and intermediate devices providing wire 1930 database location information SHOULD provide interior location data 1931 (building, floor, room, cubicle) where possible. It is RECOMMENDED 1932 that interior location be provided when spaces exceed approximately 1933 650 square meters. 1935 INT-6 Access networks and intermediate devices (including enterprise 1936 networks) which support intermediate range wireless connections 1937 (typically 100m or less of range) and which do not support a more 1938 accurate location determination mechanism such as triangulation, MUST 1939 support location configuration where the location of the access point 1940 is reflected as the location of the clients of that access point. 1941 Where the access network provides location configuration, 1942 intermediate devices MUST either be transparent to it, or provide an 1943 interconnected client for the supported configuration mechanism and a 1944 server for a configuration protocol supported by end devices 1945 downstream of the intermediate device 1947 INT-7 Devices MAY support end-system measured location. Uncertainty 1948 of less than 100 m with 95% confidence SHOULD be available for 1949 dispatch. 1951 INT-8 Devices that support endpoint measuring of location MUST have 1952 at least a coarse location capability (typically <1km accuracy when 1953 not location hiding) for routing of calls. The location mechanism 1954 MAY be a service provided by the access network. 1956 INT-9 Endpoints SHOULD attempt to configure their own location using 1957 the LCPs listed in ED-21. 1959 INT-10 Where proxies provide location on behalf of endpoints, the 1960 service provider MUST ensure that either the end device is provided 1961 with the local dial strings for its current location (where the end 1962 device recognizes dial strings), or the service provider proxy MUST 1963 detect the appropriate local dial strings at the time of the call. 1965 INT-11 Devices SHOULD be able to accept and forward location by value 1966 or by reference. An end device that receives location by reference 1967 (and does not also get the corresponding value) MUST be able to 1968 perform a dereference operation to obtain a value. 1970 INT-12 Devices MUST support both the DHCP location options [RFC4776], 1971 [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When 1972 devices deploy a specific access network interface in which that 1973 access network supports location discovery such as LLDP-MED or 1974 802.11v, the device SHOULD support the additional respective access 1975 network specific location discovery mechanism. 1977 INT-13 The access network MUST support either DHCP location options 1978 or HELD. The access network SHOULD support other location 1979 technologies that are specific to the type of access network. 1981 INT-14 Where a router is employed between a LAN and WAN in a small 1982 (less than approximately 650 square meters) area, the router MUST be 1983 transparent to the location provided by the WAN to the LAN. This may 1984 mean the router must obtain location as a client from the WAN, and 1985 supply an LCP server to the LAN with the location it obtains. Where 1986 the area is larger, the LAN MUST have a location configuration 1987 mechanism meeting this BCP. 1989 INT-15 Endpoints SHOULD try all LCPs supported by the device in any 1990 order or in parallel. The first one that succeeds in supplying 1991 location can be used. 1993 INT-16 Access networks that support more than one LCP MUST reply with 1994 the same location information (within the limits of the data format 1995 for the specific LCP) for all LCPs it supports. 1997 INT-17 When HELD is the LCP, the request MUST specify a value of 1998 "emergencyRouting" for the "responseTime" parameter and use the 1999 resulting location for routing. If a value for dispatch location 2000 will be sent, another request with the "responseTime" parameter set 2001 to "emergencyDispatch" must be completed, with the result sent for 2002 dispatch purposes. 2004 INT-18 Endpoints SHOULD obtain location immediately after obtaining 2005 local network configuration information. When HELD is the LCP the 2006 client MUST support a random back-off period (between 30 seconds and 2007 300 seconds) for re-trying the HELD query, when no response is 2008 received, and no other LCP provided location information. 2010 INT-19 If the device is configured to use DHCP for bootstrapping, it 2011 MUST include both options for location acquisition (civic and 2012 geodetic), the option for LIS discovery, and the option for LoST 2013 discovery as defined in [RFC4776], [RFC3825], 2014 [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 2016 INT-20 If the device sends a DHCPINFORM message, it MUST include both 2017 options for location acquisition (civic and geodetic), the option for 2018 LIS discovery, and the option for LoST discovery as defined in 2019 [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. 2021 INT-21 To minimize the effects of VPNs that do not allow packets to 2022 be sent via the native hardware interface rather than via the VPN 2023 tunnel, location configuration SHOULD be attempted before such 2024 tunnels are established. 2026 INT-22 Software which uses LCPs SHOULD locate and use the actual 2027 hardware network interface rather than a VPN tunnel interface to 2028 direct LCP requests to the LIS in the actual access network. 2030 INT-23 For devices which are not expected to roam, refreshing 2031 location on the order of once per day is RECOMMENDED. 2033 INT-24 For devices which roam, refresh of location information SHOULD 2034 be more frequent, with the frequency related to the mobility of the 2035 device and the ability of the access network to support the refresh 2036 operation. If the device can detect that it has moved, for example 2037 when it changes access points, the device SHOULD refresh its 2038 location. 2040 INT-25 It is RECOMMENDED that location determination not take longer 2041 than 250 ms to obtain routing location and systems SHOULD be designed 2042 such that the typical response is under 100 ms. However, as much as 2043 3 seconds to obtain routing location MAY be tolerated if location 2044 accuracy can be substantially improved over what can be obtained in 2045 250 ms. 2047 Authors' Addresses 2049 Brian Rosen 2050 NeuStar 2051 470 Conrad Dr. 2052 Mars, PA 16046 2053 US 2055 Phone: +1 724 382 1051 2056 Email: br@brianrosen.net 2058 James Polk 2059 Cisco Systems 2060 3913 Treemont Circle 2061 Colleyville, TX 76034 2062 US 2064 Phone: +1-817-271-3552 2065 Email: jmpolk@cisco.com