idnits 2.17.1 draft-ietf-ecrit-phonebcp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1771. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 53 has weird spacing: '...ergency calls...' == Line 61 has weird spacing: '...ocation infor...' == Line 133 has weird spacing: '...ergency calls...' == Line 231 has weird spacing: '...ocation infor...' == Line 250 has weird spacing: '...ocation infor...' -- 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 (September 18, 2007) is 6065 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ecrit-security-threats' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-pdif-lo-profile' is defined on line 837, but no explicit reference was found in the text == Unused Reference: 'LLDP' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'RFC3046' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC4190' is defined on line 975, but no explicit reference was found in the text == Unused Reference: 'RFC4504' is defined on line 983, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-framework (ref. 'I-D.ietf-ecrit-framework') == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-06 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-requirements (ref. 'I-D.ietf-ecrit-requirements') ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-security-threats (ref. 'I-D.ietf-ecrit-security-threats') == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-01 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-08 == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-revised-civic-lo-05 == Outdated reference: A later version (-27) exists of draft-ietf-mmusic-media-loopback-06 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-14 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-08 -- 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-10 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-12 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-toip-07 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-toip (ref. 'I-D.ietf-sipping-toip') -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3984 (Obsoleted by RFC 6184) ** Downref: Normative reference to an Informational RFC: RFC 4190 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Downref: Normative reference to an Informational RFC: RFC 4504 ** Obsolete normative reference: RFC 4676 (Obsoleted by RFC 4776) Summary: 15 errors (**), 0 flaws (~~), 25 warnings (==), 10 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: Standards Track J. Polk 5 Expires: March 21, 2008 Cisco Systems 6 September 18, 2007 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The IETF has several efforts targeted at standardizing various 44 aspects of placing emergency calls. This memo describes best current 45 practice on how devices, networks and services should use such 46 standards to make emergency calls. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview of how emergency calls are placed . . . . . . . . . . 3 53 4. Which devices and sevices should support emergency calls . . 3 54 5. Identifying an emergency call . . . . . . . . . . . . . . . . 4 55 6. Location and its role in an emergency call . . . . . . . . . . 5 56 6.1. Types of location information . . . . . . . . . . . . . . 5 57 6.2. Location Determination . . . . . . . . . . . . . . . . . . 5 58 6.2.1. User-entered location information . . . . . . . . . . 5 59 6.2.2. Access network "wire database" location 60 information . . . . . . . . . . . . . . . . . . . . . 5 61 6.2.3. End-system measured location information . . . . . . 6 62 6.2.4. Network measured location information . . . . . . . . 6 63 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 6 64 6.4. Location and references to location . . . . . . . . . . . 7 65 6.5. End system location configuration . . . . . . . . . . . . 7 66 6.6. When location should be configured . . . . . . . . . . . . 7 67 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 8 68 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 8 69 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 9 70 6.10. Location validation . . . . . . . . . . . . . . . . . . . 9 71 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 10 72 6.12. Other location considerations . . . . . . . . . . . . . . 10 73 7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 10 74 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 11 75 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 12 76 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9.2. SIP signaling requirements for User Agents . . . . . . . . 12 78 9.3. SIP signaling requirements for proxy servers . . . . . . . 13 79 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 14 81 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 15 82 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 15 83 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 16. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 87 18. Normative References . . . . . . . . . . . . . . . . . . . . . 18 88 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 22 89 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 22 90 A.2. Requirements of Service Providers . . . . . . . . . . . . 30 91 A.3. Requirements of Access Networks . . . . . . . . . . . . . 34 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 93 Intellectual Property and Copyright Statements . . . . . . . . . . 38 95 1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 This document uses terms from [RFC3261], 102 [I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-framework]. 104 2. Introduction 106 This document describes how SIP User Agents and proxy servers support 107 emergency calling, as outlined in [I-D.ietf-ecrit-framework], which 108 is designed to complement the present document in section headings, 109 numbering and content. This BCP succinctly describes the 110 requirements of end devices and applications, access networks, 111 service providers and PSAPs to achieve globally interoperable 112 emergency calling on the Internet. 114 3. Overview of how emergency calls are placed 116 An emergency call can be distinguished (Section 5) from any other 117 call by a unique Service URN[I-D.ietf-ecrit-service-urn], which is 118 placed in the call set-up signaling when a home or visited emergency 119 dial string is detected. Because emergency services are local to 120 specific geographic regions, a caller must obtain his location 121 (Section 6) prior to making emergency calls.. To get this location, 122 either a form of measuring (e.g. GPS) (Section Section 6.2.3) device 123 location in the endpoint is deployed, or the endpoint is configured 124 (Section 6.5) with its location from the access network's Location 125 Information Server (LIS). The location is conveyed ( Section 6.7) in 126 the SIP signaling with the call. The call is routed (Section 8) 127 based on location using the LoST protocol [I-D.ietf-ecrit-lost]) 128 which maps a location to a set of PSAP URIs. Each URI resolves to a 129 PSAP or an Emergency Services Routing Proxy (ESRP) which serves a 130 group of PSAPs. The call arrives at the PSAP with the location 131 included in the INVITE request. 133 4. Which devices and sevices should support emergency calls 135 ED-1 if a user could reasonably expect to be able to place a call for 136 help with the device, then the device or application SHOULD support 137 emergency calling. 139 SP-1 If a device or application expects to be able to place a call 140 for help, the service that supports it SHOULD facilitate emergency 141 calling. 143 ED-2 Devices that create media sessions and exchange audio, video 144 and/or text, and have the capability to establish sessions to a wide 145 variety of addresses, and communicate over private IP networks or the 146 Internet, SHOULD support emergency calls. 148 5. Identifying an emergency call 150 ED-3 Endpoints SHOULD do dial string recognition of emergency dial 151 strings. 153 SP-2 Proxy servers SHOULD do dial string recognition of emergency 154 dial strings if for some reason the endpoint does not recognize them. 156 ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the 157 Request-URI of the INVITE. 159 ED-5/SP-4 Local dial strings MUST be recognized. 161 ED-6/SP-5 Home dial strings MAY be recognized. 163 ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST 164 [I-D.ietf-ecrit-lost]. 166 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 167 send dial strings as per [RFC4967]. 169 SP-7 Proxy Servers MUST recognize emergency dial strings represented 170 by [RFC4967] and SHOULD recognize dial strings represented by a tel 171 URI [RFC3966]. 173 SP-8 Service providers MAY provide home dial strings by configuration 174 [I-D.ietf-sipping-config-framework]. 176 ED-9 Endpoints SHOULD be able to have home dial strings provisioned 177 by configuration. 179 ED-10 Devices SHOULD NOT have one button emergency calling 180 initiation. 182 ED-11/SP-9 All emergency services specified in 183 [I-D.ietf-ecrit-service-urn] MUST be recognized. Devices/Service 184 Providers MUST be capable of recognizing all of the associated dial 185 strings. 187 6. Location and its role in an emergency call 189 Location usually involves several steps to process and multiple 190 elements are involved. In Internet emergency calling, where the 191 endpoint is located is "Determined" using a variety of measurement or 192 wiretracing methods. Endpoints may be "Configured" with their own 193 location by the access network. In some circumstances, a proxy 194 server may insert location into the signaling on behalf of the 195 endpoint. The location is "Mapped" to the URI to send the call to, 196 and the location is "Conveyed" to the PSAP (and other elements) in 197 the signaling. Likewise, we employ Location Configuration Protocols, 198 Location Mapping Protocols, and Location Conveyance Protocols for 199 these functions. The Location-to-Service Translation protocol 200 [I-D.ietf-ecrit-lost] is the Location Mapping Protocol defined by the 201 IETF. 203 6.1. Types of location information 205 There are several ways location can be specified. In IETF protocols, 206 civic and geospatial (geo) forms are both supported. The civic forms 207 include both postal and jurisdictional fields. A cell tower/sector 208 can be represented as a point (geo or civic) or polygon. Other forms 209 of location representation must be mapped into either a geo or civic 210 for use in emergency calls. 212 ED-12/SP-10 Endpoints and Service Providers MUST be prepared to 213 handle location represented in either civic or geo form. 215 ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to 216 civic) from the form of location the determination mechanism 217 supplied. 219 6.2. Location Determination 221 ED-14/AN-2 Any suitable location determination mechanism MAY be used. 223 6.2.1. User-entered location information 225 ED-15/AN-3 Devices and/or access networks SHOULD support a manual 226 method to "override" the location the access network determines. 227 Where a civic form of location is provided, all fields in the PIDF-LO 228 [RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be 229 specified. 231 6.2.2. Access network "wire database" location information 233 AN-4 Access networks supporting copper, fiber or other hard wired IP 234 packet service SHOULD support location configuration. If the network 235 does not support location configuration, it MUST require every device 236 that connects to the network to support end system measured location. 238 AN-5 Access networks providing wire database location information 239 SHOULD provide interior location data where possible. It is 240 RECOMMENDED that interior location be provided when spaces exceed 241 approximately 650 m2. 243 AN-6 Access networks (including enterprise networks) which support 244 intermediate range wireless connections (typically 100m or less of 245 range) and which do not support a more accurate location 246 determination mechanism such as triangulation, MUST support location 247 configuration which reports the location of the access point as the 248 location of the clients of that access point. 250 6.2.3. End-system measured location information 252 ED-16 devices MAY support end-system measured location. Uncertainty 253 of less than 100 m with 95% confidence SHOULD be available for 254 dispatch. 256 ED-17/AN-7 Devices that support endpoint measuring of location MUST 257 have at least a coarse location (<1km) capability at all times for 258 routing of calls. This mechanism MAY be a service provided by the 259 access network. 261 6.2.4. Network measured location information 263 AN-8 Access networks MAY provide network measured location 264 determination. Wireless access network which do not support network 265 measured location MUST require all devices connected to the network 266 have end-system measured location. Uncertainty of less than 100 m 267 with 95% confidence SHOULD be available for dispatch. 269 AN-9 Access networks that provide network measured location MUST have 270 at least a coarse location (<1km) capability at all times for routing 271 of calls. 273 AN-10 Access networks with range of <10M MUST provide a location to 274 mobile devices connected to it. The location provided SHOULD be that 275 of the beacon location unless a more accurate mechanism is provided. 277 6.3. Who adds location, endpoint or proxy 279 ED-18 Endpoints SHOULD do location configuration themselves. 281 SP-12 Proxies MAY provide location on behalf of devices it supports 282 if: 284 o It has a relationship with all access networks the device could 285 connect to, and the relationship allows it to obtain location. 286 o It has an identifier that can be used by the access network to 287 determine the location of the endpoint, particularly in the 288 presence of NAT and VPN tunnels that may exist between the access 289 network and the service provider. 291 ED-19/SP-13 Where proxies provide location on behalf of endpoints, 292 the proxy MUST provide a mechanism to supply emergency dial strings 293 to the device if the device recognizes them, or the proxy MUST track 294 the location of the device with sufficient accuracy and timeliness to 295 be able to recognize the local dial string at the time of an 296 emergency call. 298 6.4. Location and references to location 300 ED-20 Devices SHOULD be able to accept and forward location by value 301 or by reference. An end device that receives location by reference 302 (and does not also get the corresponding value) MUST be able to 303 perform a dereference operation to obtain a value. 305 6.5. End system location configuration 307 ED-21 endpoints MUST support all of: DHCP Location options [RFC4676] 308 and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and 309 LLDP-MED[LLDP-MED]. 311 AN-11 The access network MUST support at least one of DHCP location 312 options, HELD or LLDP-MED. 314 AN-12 Where a router is employed between a LAN and WAN in a small 315 (less than approximately 650m2), the LAN MUST reflect the location 316 provided by the WAN to the LAN. 318 ED-22 Endpoints SHOULD try all LCPs supported by the device in any 319 order or in parallel. The first one that succeeds in supplying 320 location can be used. 322 AN-13 Access networks that support more than one LCP MUST reply with 323 the same location information (within the limits of the data format 324 for the specific LCP) for all LCPs it supports. 326 6.6. When location should be configured 328 ED-23 Endpoints SHOULD obtain location immediately after obtaining 329 local network configuration information. 331 ED-24 To minimize the effects of non-bypassable VPNs, location 332 configuration SHOULD be attempted before such tunnels are 333 established. 335 ED-25 Software which uses LCPs SHOULD locate and use the actual 336 hardware network interface. 338 AN-14 Network administrators MUST take care in assigning IP addresses 339 such that VPN address assignments can be distinguished from local 340 devices (by subnet choice, for example), and LISs should not attempt 341 to provide location to addresses that arrive via VPN connections. 343 AN-15 Placement of NAT devices should consider the effect of the NAT 344 on the LCP. 346 ED-26 For devices which are not expected to roam, refreshing on the 347 order of once per day is RECOMMENDED. 349 ED-27 For devices which roam, refresh of location SHOULD be more 350 frequent, with the frequency related to the mobility of the device 351 and the ability of the access network to support the refresh 352 operation. There can be instances in which a device is aware of when 353 it moves, for example when it changes access points. When this type 354 of event occurs, the device SHOULD refresh its location. 356 ED-28/AN-16 It is RECOMMENDED that location determination not take 357 longer than 250 ms to obtain routing location and systems SHOULD be 358 designed such that the typical response is under 100ms. However, as 359 much as 3 seconds to obtain routing location MAY be tolerated if 360 location accuracy can be substantially improved over what can be 361 obtained in 250 ms. 363 6.7. Conveying location in SIP 365 ED-29/SP-14 Location sent between SIP elements MUST be conveyed using 366 [I-D.ietf-sip-location-conveyance]. 368 6.8. Location updates 370 ED-30/AN-17 Where the absolute location, or the accuracy of location 371 of the endpoint may change between the time the call is received at 372 the PSAP and the time dispatch is completed, location update 373 mechanisms MUST be provided. 375 ED-31/AN-18 mobile devices MUST be provided with a mechanism to get 376 repeated location updates to track the motion of the device during 377 the complete processing of the call. 379 ED-32/AN-19 The LIS SHOULD provide a location reference which permits 380 a subscription with appropriate filtering. 382 ED-33/AN-20 For calls sent with location-by-reference, with a SIP or 383 SIPS scheme, the server resolving the reference MUST support a 384 SUBSCRIBE [RFC3118] to the presence event [RFC3856]. For other 385 location-by-reference schemes, a repeated location dereference by the 386 PSAP MUST be supported. 388 ED-34 If location was sent by value, and the endpoint gets updated 389 location, it MUST send the updated location to the PSAP via reINVITE 390 or UPDATE. Such updates SHOULD be limited to no more than one update 391 every 10 seconds. 393 6.9. Multiple locations 395 ED-35 If a UA has more than one location available to it, it MUST 396 choose one location to use to route the call towards the PSAP. 398 SP-15 If a proxy inserts location on behalf of an endpoint, and it 399 has multiple locations available for the endpoint it MUST choose one 400 location to use to route the call towards the PSAP. 402 SP-16 If a proxy is attempting to assert location but the UA conveyed 403 a location to it, the proxy must use the UA?s location for routing 404 and MUST convey that location towards the PSAP. It MAY also include 405 what it believes the location to be. 407 SP-17 All location objects received by a proxy MUST be delivered to 408 the PSAP. 410 ED-36/SP-18 Location objects MUST contain information about the 411 method by which the location was determined, such as GPS, manually 412 entered, or based on access network topology included in a PIDF- LO 413 ?method? element. In addition, the source of the location 414 information MUST be included in a PIDF-LO "provided-by" element. 416 ED-37/SP-19 The "used-for-routing" parameter MUST be set to the 417 location that was used to query LoST. 419 6.10. Location validation 421 AN-21 Location validation of civic locations via LoST SHOULD be 422 performed by the LIS before entering a location in its database. 424 ED-38 Endpoints SHOULD validate civic locations when they receive 425 them from their LCP. Validation SHOULD be performed in conjunction 426 with the LoST route query to minimize load on the LoST server. 428 6.11. Default location 430 AN-22 When the access network cannot determine the actual location of 431 the caller, it MUST supply a default location. The default SHOULD be 432 chosen to be as close to the probable location of the device as the 433 network can determine. 435 SP-20 Proxies handling emergency calls MUST insert a default location 436 if the call does not contain a location. 438 AN-23/SP-21 Default locations MUST be marked with method=Default and 439 an appropriate provided-by in the PIDF-LO. 441 6.12. Other location considerations 443 ED-39 If the LCP does not return location in the form of a PIDF-LO 444 [RFC4119], the endpoint MUST map the location information it receives 445 from the configuration protocol to a PIDF-LO. 447 ED-40/AN-24 To prevent against spoofing of the DHCP server, elements 448 implementing DHCP for location configuration SHOULD use [RFC3118]. 450 ED-41 S/MIME MUST NOT be used to protect the Geolocation header or 451 bodies. 453 ED-42/SP-22 TLS MUST be used to protect location (but see Section 9). 455 7. Uninitialized devices 457 ED-43 Uninitialized devices SHOULD NOT lead a user to believe an 458 emergency call could be placed on it unless local regulations require 459 it. 461 ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of 462 placing an emergency call unless local regulations require it. 464 ED-45/AN-26/SP-24 Uninitialized devices that can place emergency 465 calls MUST supply location the same as a fully capable device would. 467 ED-46/SP-25 Unitialized Devices MUST supply a call back URI. See 468 Section 7. 470 ED-47/SP-26 Unitialized Devices MUST include identifiers in the 471 signaling that can be used by the service provider to identify the 472 device and to allow filtering of calls from the device by the PSAP/ 473 ESRP. 475 8. Routing the call to the PSAP 477 ED-48 Endpoints who obtain their own location SHOULD perform LoST 478 mapping to the PSAP URI. 480 ED-49 Mapping SHOULD be performed at boot time and whenever location 481 changes beyond the service boundary obtained from a prior LoST 482 mapping operation or the time-to-live value of that response has 483 expired. The value MUST be cached for possible use. 485 ED-50 The endpoint SHOULD attempt to update its location at the time 486 of an emergency call. If it cannot obtain a new location quickly 487 (See Section 6), it MUST use the cached value. 489 ED-51 The endpoint SHOULD attempt to update the LoST mapping at the 490 time of an emergency call. If it cannot obtain a new mapping 491 quickly, it MUST use the cached value. 493 SP-27 All proxies in the outbound path SHOULD recognize emergency 494 calls with a Request URI of the service URN in the "sos" tree. An 495 endpoint places a service URN in the Request URI to indicate that the 496 endpoint understood the call was an emergency call. A proxy that 497 processes such a call looks for the presence of a Route header with a 498 URI of a PSAP. Absence of such a Route header indicates the UAC was 499 unable to invoke LoST and the proxy MUST perform the LoST mapping and 500 insert a Route header with the URI obtained. 502 SP-28 To deal with old user agents that predate this specification 503 and with UAs that do not have access to their own location data, 504 proxies that recognize a call as an emergency call that is not marked 505 as such (see Section 5) MUST also perform this mapping, with the best 506 location it has available for the endpoint. The resulting PSAP URI 507 would become the Request URI. 509 SP-29 Proxy servers performing mapping SHOULD use location obtained 510 from the access network for the mapping. If no location is 511 available, a default location (see Section 6.11) MUST be supplied. 513 SP-30 A proxy server which attempts mapping and fails to get a 514 mapping MUST provide a default mapping. A suitable default mapping 515 would be the mapping obtained previously for the default location 516 appropriate for the caller. 518 ED-52/SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route 519 an emergency call towards the PSAP's URI. 521 ED-53 Initial INVITES MUST provide an Offer [RFC3264]. 523 9. Signaling of emergency calls 525 ED-54 Best Current Practice for SIP user agents including handling of 526 audio, video and real-time text [RFC4103] SHOULD be applied. This 527 memo can be considered as an addition to it for endpoints. 529 9.1. Use of TLS 531 ED-55/SP-32 sips: MUST be specified when attempting to signal an 532 emergency call with SIP. 534 ED-56/SP-33 If TLS session establishment fails, the call MUST be 535 retried with sip:. 537 ED-57/SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain 538 persistent TLS connections between elements. 540 ED-58/AN-27 https: MUST be specified when attempting to retrieve 541 location (configuration or dereferencing) with HELD. 543 ED-59/AN33 If TLS session establishment fails, the location 544 retrieveal MUST be retried with http:. 546 9.2. SIP signaling requirements for User Agents 548 ED-60 The initial SIP signaling Method is an INVITE: 549 1. The Request URI SHOULD be the service URN in the "sos" tree, If 550 the device cannot do local dial string interpretation, the 551 Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed 552 digits. 553 2. The To: header MUST be present and SHOULD be a service URN in 554 the "sos" tree. If the device cannot do local dial string 555 interpretation, the To: SHOULD be a dialstring URI with the 556 dialed digits. 557 3. The From: header MUST be present and SHOULD be the AoR of the 558 caller. 559 4. A Via: header MUST be present and SHOULD include the URI of the 560 device. 561 5. A Route: header SHOULD be present with a PSAP URI obtained from 562 LoST (see Section 8) and the loose route parameter. A sips URI 563 [RFC3261] SHOULD be specified, unless the operation must be 564 retried due to a failure to establish a TLS connection. If the 565 device does not do dial plan interpretation, no Route: header 566 will be present. 567 6. A Contact header MUST be present which MUST be globally 568 routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an 569 immediate call-back to the specific device which placed the 570 emergency call. 572 7. Other headers MAY be included as per normal sip behavior. 573 8. A Supported: header MUST be included with the 'geolocation' 574 option tag [I-D.ietf-sip-location-conveyance], unless the device 575 does not understand the concept of SIP Location. 576 9. If a device understands the SIP Location Conveyance 577 [I-D.ietf-sip-location-conveyance] extension and has its 578 location available, it MUST include location either by- value or 579 by-reference. 580 10. If a device understands the SIP Location Conveyance extension 581 and has its location unavailable or unknown to that device, it 582 MUST include a Supported header with a "geolocation" option tag, 583 and MUST NOT include a Geolocation header, and not include a 584 PIDF-LO message body. 585 11. If a device understands the SIP Location Conveyance extension 586 and supports LoST [I-D.ietf-ecrit-lost] then whichever location 587 is used for routing the message towards the PSAP or ESRP, even 588 if there is only one, the Geolocation "message-routed-on- this- 589 uri" header parameter SHOULD be added to the corresponding URI 590 in the Geolocation header. 591 12. A normal SDP offer SHOULD be included in the INVITE. The offer 592 MUST include the G.711 codec, see Section 14. 593 13. If the device includes location-by-value, the UA MUST support 594 multipart message bodies, since SDP will likely be also in the 595 INVITE. 596 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 597 on all Geolocation headers . This informs downstream elements 598 which device entered the location at this URI (either cid-URL or 599 location-by-reference URI). 600 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 601 PSAP should handle the call. For example, a language preference 602 expressed in an Accept-Language header may be used as a hint to 603 cause the PSAP to route the call to a call taker who speaks the 604 requested language. 606 9.3. SIP signaling requirements for proxy servers 608 SP-35 SIP Proxy servers processing emergency calls: 609 1. If the proxy does dial plan interpretation on behalf of user 610 agents, the proxy MUST look for the local emergency dialstring at 611 the location of the end device and MAY look for the home 612 dialstring. If it finds it, the proxy MUST: 613 * Insert a Geolocation header as per 10-12 above. Location-by- 614 reference MUST be used because proxies may not insert bodies. 615 * Include the Geolocation "inserted-by=server" AND "routed-by- 616 this-uri" parameters. 617 * Map the location to a PSAP uri using LoST. 619 * Add a Route header with the service URN appropriate for the 620 emergency dialstring. 621 * Replace the Request-URI (which was the dialstring) with the 622 PSAP URI obtained from LoST. 623 * Route the call using normal SIP routing mechanisms. 624 2. If the proxy recognizes the service URN in the Request URI, and 625 does not find a Route header with a PSAP URI, it MUST run LoST 626 routing. If a location was provided (which should be the case), 627 the proxy uses that location to query LoST. The proxy may have 628 to dereference a location by reference to get a value. If a 629 location is not present, and the proxy can query a LIS which has 630 the location of the UA it MUST do so. If no location is present, 631 and the proxy does not have access to a LIS which could provide 632 location, the proxy MUST supply a default location (See 633 Section 6.11). The location (in the signaling, obtained from a 634 LIS, or default) MUST be used in a query to LoST with the service 635 URN received with the call. The resulting URI MUST be placed in 636 a Route: header added to the call. 637 3. The "inserted-by=" parameter in any Geolocation: header received 638 on the call MUST NOT be modified or deleted in transit. 639 4. The proxy SHOULD NOT modify any parameters in Geolocation: 640 headers received in the call. It MAY add a Geolocation: header. 641 Such an additional location SHOULD NOT be used for routing; the 642 location provided by the UA should be used. 643 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 644 [RFC4474], or both, MUST be included to identify the sender. 646 10. Call backs 648 SP-36 Unitialized devices MUST have a globally routable URI in a 649 Contact: header. 651 SP-37 Unitialized devices SHOULD have a persistent URI in a 652 P-Asserted-Identity: header. 654 11. Mid-call behavior 656 ED-61/SP-38 During the course of an emergency call, devices and 657 proxies MUST support REFER transactions and the Referred-by: header 658 [RFC3515] to: 659 1. Be REFERed to a conference bridge; PSAPs often include 660 dispatchers, responders or specialists on a call. 661 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are 662 not located in the primary PSAP. The call may have to be 663 transferred to another PSAP. Most often this will be an attended 664 transfer, or a bridged transfer.(For devices that are Mobile). 666 ED-62/SP-39User agents and proxies MUST Support Session 667 Timer[RFC4028] to guard against session corruption. 669 12. Call termination 671 ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT 672 generate a BYE request (or equivalent for other non-SIP signaling). 673 The PSAP must be the only entity that can terminate a call. If the 674 user "hangs up" an emergency call, the device should alert, and when 675 answered, reconnect the caller to the PSAP. 677 ED-64 There can be a case where the session signaling path is lost, 678 and the user agent does not receive the BYE. If the call is hung up, 679 and the session timer expires the call MAY be declared lost. If in 680 the interval, an incoming call is received from the domain of the 681 PSAP, the device SHOULD drop the old call and alert for the (new) 682 incoming call. Dropping of the old call SHOULD only occur if the 683 user is attempting to hang up; the domain of an incoming call can 684 only be determined from the From header, which is not reliable, and 685 could be spoofed. Dropping an active call by a new call with a 686 spoofed From: would be a DoS attack. 688 13. Disabling of features 690 ED-65/SP-40 User Agents and proxys MUST disable outgoing call 691 features such as: 692 o Call Waiting 693 o Call Transfer 694 o Three Way Call 695 o Flash hold 696 o Outbound Call Blocking 697 when an emergency call is established. 699 ED-66/SP-41 The emergency dialstrings SHOULD NOT be permitted in Call 700 Forward numbers or speed dial lists. 702 ED-67/SP-42 The User Agent and Proxies SHOULD disable the following 703 incoming call features on call backs from the PSAP: 704 o Call Waiting 705 o Do Not Disturb 706 o Call Forward (all kinds) 708 ED-68 Call backs SHOULD be determined by retaining the domain of the 709 PSAP which answers an outgoing emergency call and instantiating a 710 timer which starts when the call is terminated. If a call is 711 received from the same domain and within the timer period, sent to 712 the Contact: or AoR used in the emergency call, it should be assumed 713 to be a call back. The suggested timer period is 5 minutes. 715 14. Media 717 ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550]. 719 ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 720 agree on the media streams to be used. 722 ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law 723 in North America) encoded voice as described in [RFC3551]. It is 724 desirable to support wideband codecs in the offer. 726 ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT 727 be used on emergency calls. PSAP call takers sometimes get 728 information on what is happening in the background to determine how 729 to process the call. 731 ED-73 Endpoints supporting IM MUST support either [RFC3428] or 732 [RFC3920]. 734 ED-74 Endpoints supporting real-time text MUST use [RFC4103]. The 735 expectations for emergency service support for the real-time text 736 medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be 737 fulfilled. 739 ED-75 Endpoints supporting video MUST support H.264 per [RFC3984]. 741 15. Testing 743 ED-76 INVITE requests to a service urn with a urn parameter of "test" 744 indicates a request for an automated test. For example, 745 "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response 746 indicates that the address was recognized and a 404 (Not found) that 747 it was not. A 486 (Busy Here) MUST be returned if the test service 748 is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP 749 does not support the test mechanism. 751 ED-77 In its response to the test, the PSAP MAY include a text body 752 (text/plain) indicating the identity of the PSAP, the requested 753 service, and the location reported with the call. For the latter, 754 the PSAP SHOULD return location-by-value even if the original 755 location delivered with the test was by-reference. If the location- 756 by-reference was supplied, and the dereference requires credentials, 757 the PSAP SHOULD use credentials supplied by the LIS for test 758 purposes. This alerts the LIS that the dereference is not for an 759 actual emergency call and location hiding techniques, if they are 760 being used, may be employed for this dereference. The response MAY 761 include the connected identity of the PSAP per 762 [I-D.ietf-sip-connected-identity]. 764 ED-78 A PSAP accepting a test call SHOULD accept a media loopback 765 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 766 pkt-loopback" and "rtp-start-loopback" options. The user agent would 767 specify a loopback attribute of "loopback-source", the PSAP being the 768 mirror. User Agents should expect the PSAP to loop back no more than 769 3 packets of each media type accepted (which limits the duration of 770 the test), after which the PSAP would normally send BYE. 772 ED-79 User agents SHOULD perform a full call test, including media 773 loopback, after a disconnect and subsequent change in IP address. 774 After an initial IP address assignment test, a full test SHOULD be 775 repeated approximately every 30 days with a random interval. 777 ED-80 User agents MUST NOT place a test call immediately after 778 booting. If the IP address changes after booting, the UA should wait 779 a random amount of time (in perhaps a 30 minute period, sufficient 780 for any avalanche restart to complete) and then test. 782 ED-81 PSAPs MAY refuse repeated requests for test from the same 783 device in a short period of time. Any refusal is signaled with a 486 784 or 488 response. 786 16. Security Considerations 788 Security considerations for emergency calling have been documented in 789 draft-ietf-ecrit-security- threats, and the forthcoming GEOPRIV 790 security document(s). 792 Ed. Note: go through that doc and make sure any actions needed are 793 captured in the BCP text. 795 17. Acknowledgements 797 Work group members participating in the creation and review of this 798 document include include Hannes Tschofenig, Ted Hardie, Marc Linsner, 799 Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, 800 Roger Marshall, Barbara Stark, Richard Barnes and Peter Blatherwick. 802 18. Normative References 804 [I-D.ietf-ecrit-framework] 805 Rosen, B., "Framework for Emergency Calling using Internet 806 Multimedia", draft-ietf-ecrit-framework-02 (work in 807 progress), July 2007. 809 [I-D.ietf-ecrit-lost] 810 Hardie, T., "LoST: A Location-to-Service Translation 811 Protocol", draft-ietf-ecrit-lost-06 (work in progress), 812 August 2007. 814 [I-D.ietf-ecrit-requirements] 815 Schulzrinne, H. and R. Marshall, "Requirements for 816 Emergency Context Resolution with Internet Technologies", 817 draft-ietf-ecrit-requirements-13 (work in progress), 818 March 2007. 820 [I-D.ietf-ecrit-security-threats] 821 Taylor, T., "Security Threats and Requirements for 822 Emergency Call Marking and Mapping", 823 draft-ietf-ecrit-security-threats-05 (work in progress), 824 August 2007. 826 [I-D.ietf-ecrit-service-urn] 827 Schulzrinne, H., "A Uniform Resource Name (URN) for 828 Emergency and Other Well-Known Services", 829 draft-ietf-ecrit-service-urn-07 (work in progress), 830 August 2007. 832 [I-D.ietf-geopriv-http-location-delivery] 833 Barnes, M., "HTTP Enabled Location Delivery (HELD)", 834 draft-ietf-geopriv-http-location-delivery-01 (work in 835 progress), July 2007. 837 [I-D.ietf-geopriv-pdif-lo-profile] 838 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 839 Considerations and Recommendations", 840 draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), 841 July 2007. 843 [I-D.ietf-geopriv-revised-civic-lo] 844 Thomson, M. and J. Winterbottom, "Revised Civic Location 845 Format for PIDF-LO", 846 draft-ietf-geopriv-revised-civic-lo-05 (work in progress), 847 February 2007. 849 [I-D.ietf-mmusic-media-loopback] 850 Hedayat, K., "An Extension to the Session Description 851 Protocol (SDP) for Media Loopback", 852 draft-ietf-mmusic-media-loopback-06 (work in progress), 853 April 2007. 855 [I-D.ietf-sip-connected-identity] 856 Elwell, J., "Connected Identity in the Session Initiation 857 Protocol (SIP)", draft-ietf-sip-connected-identity-05 858 (work in progress), February 2007. 860 [I-D.ietf-sip-gruu] 861 Rosenberg, J., "Obtaining and Using Globally Routable User 862 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 863 (SIP)", draft-ietf-sip-gruu-14 (work in progress), 864 June 2007. 866 [I-D.ietf-sip-location-conveyance] 867 Polk, J. and B. Rosen, "Location Conveyance for the 868 Session Initiation Protocol", 869 draft-ietf-sip-location-conveyance-08 (work in progress), 870 July 2007. 872 [I-D.ietf-sip-outbound] 873 Jennings, C. and R. Mahy, "Managing Client Initiated 874 Connections in the Session Initiation Protocol (SIP)", 875 draft-ietf-sip-outbound-10 (work in progress), July 2007. 877 [I-D.ietf-sipping-config-framework] 878 Petrie, D. and S. Channabasappa, "A Framework for Session 879 Initiation Protocol User Agent Profile Delivery", 880 draft-ietf-sipping-config-framework-12 (work in progress), 881 June 2007. 883 [I-D.ietf-sipping-toip] 884 Wijk, A. and G. Gybels, "Framework for real-time text over 885 IP using the Session Initiation Protocol (SIP)", 886 draft-ietf-sipping-toip-07 (work in progress), 887 August 2006. 889 [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", 890 Dec 2004. 892 [LLDP-MED] 893 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 894 Endpoint Discovery". 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 900 RFC 2131, March 1997. 902 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 903 Resource Identifiers (URI): Generic Syntax", RFC 2396, 904 August 1998. 906 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 907 RFC 3046, January 2001. 909 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 910 Messages", RFC 3118, June 2001. 912 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 913 A., Peterson, J., Sparks, R., Handley, M., and E. 914 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 915 June 2002. 917 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 918 Protocol (SIP): Locating SIP Servers", RFC 3263, 919 June 2002. 921 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 922 with Session Description Protocol (SDP)", RFC 3264, 923 June 2002. 925 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 926 Extensions to the Session Initiation Protocol (SIP) for 927 Asserted Identity within Trusted Networks", RFC 3325, 928 November 2002. 930 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 931 and D. Gurle, "Session Initiation Protocol (SIP) Extension 932 for Instant Messaging", RFC 3428, December 2002. 934 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 935 Method", RFC 3515, April 2003. 937 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 938 Jacobson, "RTP: A Transport Protocol for Real-Time 939 Applications", STD 64, RFC 3550, July 2003. 941 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 942 Video Conferences with Minimal Control", STD 65, RFC 3551, 943 July 2003. 945 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 946 Configuration Protocol Option for Coordinate-based 947 Location Configuration Information", RFC 3825, July 2004. 949 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 950 Preferences for the Session Initiation Protocol (SIP)", 951 RFC 3841, August 2004. 953 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 954 Initiation Protocol (SIP)", RFC 3856, August 2004. 956 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 957 Protocol (XMPP): Core", RFC 3920, October 2004. 959 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 960 RFC 3966, December 2004. 962 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 963 M., and D. Singer, "RTP Payload Format for H.264 Video", 964 RFC 3984, February 2005. 966 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 967 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 969 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 970 Conversation", RFC 4103, June 2005. 972 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 973 Format", RFC 4119, December 2005. 975 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 976 Supporting Emergency Telecommunications Service (ETS) in 977 IP Telephony", RFC 4190, November 2005. 979 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 980 Authenticated Identity Management in the Session 981 Initiation Protocol (SIP)", RFC 4474, August 2006. 983 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 984 Device Requirements and Configuration", RFC 4504, 985 May 2006. 987 [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol 988 (DHCPv4 and DHCPv6) Option for Civic Addresses 989 Configuration Information", RFC 4676, October 2006. 991 [RFC4967] Rosen, B., "Dial String Parameter for the Session 992 Initiation Protocol Uniform Resource Identifier", 993 RFC 4967, July 2007. 995 Appendix A. BCP Requirements Sorted by Responsible Party 997 A.1. Requirements of End Devices 999 ED-1 if a user could reasonably expect to be able to place a call for 1000 help with the device, then the device or application SHOULD support 1001 emergency calling. 1003 ED-2 Devices that create media sessions and exchange audio, video 1004 and/or text, and have the capability to establish sessions to a wide 1005 variety of addresses, and communicate over private IP networks or the 1006 Internet, SHOULD support emergency calls 1008 ED-3 Endpoints SHOULD do dial string recognition of emergency dial 1009 strings 1011 ED-4 Emergency calls MUST be marked with a Service URN in the 1012 Request-URI of the INVITE. 1014 ED-5 Local dial strings MUST be recognized. 1016 ED-6 Home dial strings MAY be recognized. 1018 ED-7 Local emergency dial strings SHOULD be determined from LoST LoST 1019 [I-D.ietf-ecrit-lost]. 1021 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 1022 send dial strings as per [RFC4967]. 1024 ED-9 Endpoints SHOULD be able to have home dial strings provisioned 1025 by configuration. 1027 ED-10 Devices SHOULD NOT have one button emergency calling 1028 initiation. 1030 ED-11 All emergency services specified in 1031 [I-D.ietf-ecrit-service-urn] MUST be recognized. Devices/Service 1032 Providers MUST be capable of recognizing all of the associated dial 1033 strings. 1035 ED-12 Endpoints and Service Providers MUST be prepared to handle 1036 location represented in either civic or geo form. 1038 ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from 1039 the form of location the determination mechanism supplied. 1041 ED-14 Any suitable location determination mechanism MAY be used. 1043 ED-15 Devices and/or access networks SHOULD support a manual method 1044 to "override" the location the access network determines. Where a 1045 civic form of location is provided, all fields in the PIDF- LO 1046 [RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be 1047 specified. 1049 ED-16 devices MAY support end-system measured location. Uncertainty 1050 of less than 100 m with 95% confidence SHOULD be available for 1051 dispatch. 1053 ED-17 Devices that support endpoint measuring of location MUST have 1054 at least a coarse location (<1km) capability at all times for routing 1055 of calls. This mechanism MAY be a service provided by the access 1056 network. 1058 ED-18 Endpoints SHOULD do location configuration themselves. 1060 ED-20 Devices SHOULD be able to accept and forward location by value 1061 or by reference. An end device that receives location by reference 1062 (and does not also get the corresponding value) MUST be able to 1063 perform a dereference operation to obtain a value. 1065 ED-21 endpoints MUST support all of: DHCP Location options [RFC4676] 1066 and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and 1067 LLDP-MED[LLDP-MED]. 1069 ED-22 Endpoints SHOULD try all LCPs supported by the device in any 1070 order or in parallel. The first one that succeeds in supplying 1071 location can be used. 1073 ED-23 Endpoints SHOULD obtain location immediately after obtaining 1074 local network configuration information. 1076 ED-24 To minimize the effects of non-bypassable VPNs, location 1077 configuration SHOULD be attempted before such tunnels are 1078 established. 1080 ED-25 Software which uses LCPs SHOULD locate and use the actual 1081 hardware network interface. 1083 ED-26 For devices which are not expected to roam, refreshing on the 1084 order of once per day is RECOMMENDED 1086 ED-27 For devices which roam, refresh of location SHOULD be more 1087 frequent, with the frequency related to the mobility of the device 1088 and the ability of the access network to support the refresh 1089 operation. There can be instances in which a device is aware of when 1090 it moves, for example when it changes access points. When this type 1091 of event occurs, the device SHOULD refresh its location. 1093 ED-28 It is RECOMMENDED that location determination not take longer 1094 than 250 ms to obtain routing location and systems SHOULD be designed 1095 such that the typical response is under 100ms. However, as much as 3 1096 seconds to obtain routing location MAY be tolerated if location 1097 accuracy can be substantially improved over what can be obtained in 1098 250 ms. 1100 ED-29 Location sent between SIP elements MUST be conveyed using 1101 [I-D.ietf-sip-location-conveyance]. 1103 ED-30 Where the absolute location, or the accuracy of location of the 1104 endpoint may change between the time the call is received at the PSAP 1105 and the time dispatch is completed, location update mechanisms MUST 1106 be provided. 1108 ED-31 mobile devices MUST be provided with a mechanism to get 1109 repeated location updates to track the motion of the device during 1110 the complete processing of the call. 1112 ED-32 The LIS SHOULD provide a location reference which permits a 1113 subscription with appropriate filtering. 1115 ED-33 For calls sent with location-by-reference, with a SIP or SIPS 1116 scheme, the server resolving the reference MUST support a SUBSCRIBE 1117 [RFC3118] to the presence event [RFC3856]. For other location-by- 1118 reference schemes, a repeated location dereference by the PSAP MUST 1119 be supported. 1121 ED-34 If location was sent by value, and the endpoint gets updated 1122 location, it MUST send the updated location to the PSAP via reINVITE 1123 or UPDATE. Such updates SHOULD be limited to no more than one update 1124 every 10 seconds. 1126 ED-35 If a UA has more than one location available to it, it MUST 1127 choose one location to use to route the call towards the PSAP. 1129 ED-36/ Location objects MUST contain information about the method by 1130 which the location was determined, such as GPS, manually entered, or 1131 based on access network topology included in a PIDF- LO ?method? 1132 element. In addition, the source of the location information MUST be 1133 included in a PIDF-LO "provided-by" element. 1135 ED-37 The "used-for-routing" parameter MUST be set to the location 1136 that was used to query LoST. 1138 ED-38 Endpoints SHOULD validate civic locations when they receive 1139 them from their LCP. Validation SHOULD be performed in conjunction 1140 with the LoST route query to minimize load on the LoST server. 1142 ED-39 If the LCP does not return location in the form of a PIDF-LO 1143 [RFC4119], the endpoint MUST map the location information it receives 1144 from the configuration protocol to a PIDF-LO. 1146 ED-40 To prevent against spoofing of the DHCP server, elements 1147 implementing DHCP for location configuration SHOULD use [RFC3118]. 1149 ED-41 S/MIME MUST NOT be used to protect the Geolocation header or 1150 bodies. 1152 ED-42 TLS MUST be used to protect location (but see Section 9). 1154 ED-43 Uninitialized devices SHOULD NOT lead a user to believe an 1155 emergency call could be placed on it unless local regulations require 1156 it. 1158 ED-44 Uninitialized devices SHOULD NOT be capable of placing an 1159 emergency call unless local regulations require it. 1161 ED-45 Uninitialized devices that can place emergency calls MUST 1162 supply location the same as a fully capable device would. 1164 ED-46 Unitialized Devices MUST supply a call back URI. See Section 7 1166 ED-47 Unitialized Devices MUST include identifiers in the signaling 1167 that can be used by the service provider to identify the device and 1168 to allow filtering of calls from the device by the PSAP/ESRP. 1170 ED-48 Endpoints who obtain their own location SHOULD perform LoST 1171 mapping to the PSAP URI. 1173 ED-49 Mapping SHOULD be performed at boot time and whenever location 1174 changes beyond the service boundary obtained from a prior LoST 1175 mapping operation or the time-to-live value of that response has 1176 expired. The value MUST be cached for possible use. 1178 ED-50 The endpoint SHOULD attempt to update its location at the time 1179 of an emergency call. If it cannot obtain a new location quickly 1180 (See Section 6), it MUST use the cached value. 1182 ED-51 The endpoint SHOULD attempt to update the LoST mapping at the 1183 time of an emergency call. If it cannot obtain a new mapping 1184 quickly, it MUST use the cached value. 1186 ED-52 [RFC3261] and [RFC3263] procedures MUST be used to route an 1187 emergency call towards the PSAP's URI. 1189 ED-53 Initial INVITES MUST provide an Offer [RFC3264] 1191 ED-54 Best Current Practice for SIP user agents including handling of 1192 audio, video and real-time text [RFC4103] SHOULD be applied. This 1193 memo can be considered as an addition to it for endpoints. 1195 ED-55 sips: MUST be specified when attempting to signal an emergency 1196 call with SIP 1198 ED-56 If TLS session establishment fails, the call MUST be retried 1199 with sip: 1201 ED-57 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent 1202 TLS connections between elements 1204 ED-58 https: MUST be specified when attempting to retrieve location 1205 (configuration or dereferencing) with HELD 1207 ED-59 If TLS session establishment fails, the location retrieveal 1208 MUST be retried with http: 1210 ED-60 The initial SIP signaling Method is an INVITE: 1211 1. The Request URI SHOULD be the service URN in the "sos" tree, If 1212 the device cannot do local dialstring interpretation, the 1213 Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed 1214 digits. 1215 2. The To: header MUST be present and SHOULD be a service URN in 1216 the "sos" tree. If the device cannot do local dialstring 1217 interpretation, the To: SHOULD be a dialstring URI with the 1218 dialed digits. 1219 3. The From: header MUST be present and SHOULD be the AoR of the 1220 caller. 1221 4. A Via: header MUST be present and SHOULD include the URI of the 1222 device. 1223 5. A Route: header SHOULD be present with a PSAP URI obtained from 1224 LoST (see Section 8 ) and the loose route parameter. A sips URI 1225 [RFC3261] SHOULD be specified, unless the operation must be 1226 retried due to a failure to establish a TLS connection. If the 1227 device does not do dial plan interpretation, no Route: header 1228 will be present. 1229 6. A Contact header MUST be present which MUST be globally 1230 routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an 1231 immediate call-back to the specific device which placed the 1232 emergency call. 1234 7. Other headers MAY be included as per normal sip behavior. 1235 8. A Supported: header MUST be included with the 'geolocation' 1236 option tag [I-D.ietf-sip-location-conveyance], unless the device 1237 does not understand the concept of SIP Location. 1238 9. If a device understands the SIP Location Conveyance 1239 [I-D.ietf-sip-location-conveyance] extension and has its 1240 location available, it MUST include location either by- value or 1241 by-reference. 1242 10. If a device understands the SIP Location Conveyance extension 1243 and has its location unavailable or unknown to that device, it 1244 MUST include a Supported header with a "geolocation" option tag, 1245 and MUST NOT include a Geolocation header, and not include a 1246 PIDF-LO message body. 1247 11. If a device understands the SIP Location Conveyance extension 1248 and supports LoST [I-D.ietf-ecrit-lost] then whichever location 1249 is used for routing the message towards the PSAP or ESRP, even 1250 if there is only one, the Geolocation "message-routed-on- this- 1251 uri" header parameter SHOULD be added to the corresponding URI 1252 in the Geolocation header. 1253 12. A normal SDP offer SHOULD be included in the INVITE. The offer 1254 MUST include the G.711 codec, see Section 14. 1255 13. If the device includes location-by-value, the UA MUST support 1256 multipart message bodies, since SDP will likely be also in the 1257 INVITE. 1258 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 1259 on all Geolocation headers . This informs downstream elements 1260 which device entered the location at this URI (either cid-URL or 1261 location-by-reference URI). 1262 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 1263 PSAP should handle the call. For example, a language preference 1264 expressed in an Accept-Language header may be used as a hint to 1265 cause the PSAP to route the call to a call taker who speaks the 1266 requested language. 1268 ED-61 During the course of an emergency call, devices and proxies 1269 MUST support REFER transactions and the Referred-by: header [RFC3515] 1270 to: 1271 1. Be REFERed to a conference bridge; PSAPs often include 1272 dispatchers, responders or specialists on a call. 1273 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are 1274 not located in the primary PSAP. The call may have to be 1275 transferred to another PSAP. Most often this will be an attended 1276 transfer, or a bridged transfer.(For devices that are Mobile). 1278 ED-62 User agents and proxies MUST Support Session Timer [RFC4028] to 1279 guard against session corruption. 1281 ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT 1282 generate a BYE request (or equivalent for other non-SIP signaling). 1283 The PSAP must be the only entity that can terminate a call. If the 1284 user "hangs up" an emergency call, the device should alert, and when 1285 answered, reconnect the caller to the PSAP. 1287 ED-64 There can be a case where the session signaling path is lost, 1288 and the user agent does not receive the BYE. If the call is hung up, 1289 and the session timer expires the call MAY be declared lost. If in 1290 the interval, an incoming call is received from the domain of the 1291 PSAP, the device SHOULD drop the old call and alert for the (new) 1292 incoming call. Dropping of the old call SHOULD only occur if the 1293 user is attempting to hang up; the domain of an incoming call can 1294 only be determined from the From header, which is not reliable, and 1295 could be spoofed. Dropping an active call by a new call with a 1296 spoofed From: would be a DoS attack. 1298 ED-65 User Agents and proxys MUST disable outgoing call features such 1299 as: 1300 o Call Waiting 1301 o Call Transfer 1302 o Three Way Call 1303 o Flash hold 1304 o Outbound Call Blocking 1305 when an emergency call is established. 1307 ED-66 The emergency dialstrings SHOULD NOT be permitted in Call 1308 Forward numbers or speed dial lists. 1310 ED-67 The User Agent and Proxies SHOULD disable the following 1311 incoming call features on call backs from the PSAP: 1312 o Call Waiting 1313 o Do Not Disturb 1314 o Call Forward (all kinds) 1316 ED-68 Call backs SHOULD be determined by retaining the domain of the 1317 PSAP which answers an outgoing emergency call and instantiating a 1318 timer which starts when the call is terminated. If a call is 1319 received from the same domain and within the timer period, sent to 1320 the Contact: or AoR used in the emergency call, it should be assumed 1321 to be a call back. The suggested timer period is 5 minutes. 1323 ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550]. 1325 ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 1326 agree on the media streams to be used. 1328 ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law 1329 in North America) encoded voice as described in [RFC3551]. It is 1330 desirable to support wideband codecs in the offer. 1332 ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT 1333 be used on emergency calls. PSAP call takers sometimes get 1334 information on what is happening in the background to determine how 1335 to process the call. 1337 ED-73 Endpoints supporting IM MUST support either [RFC3428] or 1338 [RFC3920]. 1340 ED-74 Endpoints supporting real-time text MUST use [RFC4103]. The 1341 expectations for emergency service support for the real-time text 1342 medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be 1343 fulfilled. 1345 ED-75 Endpoints supporting video MUST support H.264 per [RFC3984]. 1347 ED-76 INVITE requests to a service urn with a urn parameter of "test" 1348 indicates a request for an automated test. For example, 1349 "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response 1350 indicates that the address was recognized and a 404 (Not found) that 1351 it was not. A 486 (Busy Here) MUST be returned if the test service 1352 is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP 1353 does not support the test mechanism. 1355 ED-77 In its response to the test, the PSAP MAY include a text body 1356 (text/plain) indicating the identity of the PSAP, the requested 1357 service, and the location reported with the call. For the latter, 1358 the PSAP SHOULD return location-by-value even if the original 1359 location delivered with the test was by-reference. If the location- 1360 by-reference was supplied, and the dereference requires credentials, 1361 the PSAP SHOULD use credentials supplied by the LIS for test 1362 purposes. This alerts the LIS that the dereference is not for an 1363 actual emergency call and location hiding techniques, if they are 1364 being used, may be employed for this dereference. The response MAY 1365 include the connected identity of the PSAP per 1366 [I-D.ietf-sip-connected-identity]. 1368 ED-78 A PSAP accepting a test call SHOULD accept a media loopback 1369 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 1370 pkt-loopback" and "rtp-start-loopback" options. The user agent would 1371 specify a loopback attribute of "loopback-source", the PSAP being the 1372 mirror. User Agents should expect the PSAP to loop back no more than 1373 3 packets of each media type accepted (which limits the duration of 1374 the test), after which the PSAP would normally send BYE. 1376 ED-79 User agents SHOULD perform a full call test, including media 1377 loopback, after a disconnect and subsequent change in IP address. 1379 After an initial IP address assignment test, a full test SHOULD be 1380 repeated approximately every 30 days with a random interval. 1382 ED-80 User agents MUST NOT place a test call immediately after 1383 booting. If the IP address changes after booting, the UA should wait 1384 a random amount of time (in perhaps a 30 minute period, sufficient 1385 for any avalanche restart to complete) and then test. 1387 ED-81 PSAPs MAY refuse repeated requests for test from the same 1388 device in a short period of time. Any refusal is signaled with a 486 1389 or 488 response. 1391 A.2. Requirements of Service Providers 1393 SP-1 If a device or application expects to be able to place a call 1394 for help, the service that supports it SHOULD facilitate emergency 1395 calling. 1397 SP-2 Proxy servers SHOULD do dial string recognition of emergency 1398 dial strings if for some reason the endpoint does not recognize them. 1400 SP-3 Emergency calls MUST be marked with a Service URN in the 1401 Request-URI of the INVITE. 1403 SP-4 Local dial strings MUST be recognized. 1405 SP-5 Home dial strings MAY be recognized. 1407 SP-6 Local emergency dial strings SHOULD be determined from LoST LoST 1408 [I-D.ietf-ecrit-lost]. 1410 SP-7 Proxy Servers MUST recognize emergency dial strings represented 1411 by [RFC4967] and SHOULD recognize dial strings represented by a tel 1412 URI [RFC3966]. 1414 SP-8 Service providers MAY provide home dial strings by configuration 1415 [I-D.ietf-sipping-config-framework]. 1417 SP-9 All emergency services specified in [I-D.ietf-ecrit-service-urn] 1418 MUST be recognized. Devices/Service Providers MUST be capable of 1419 recognizing all of the associated dial strings. 1421 SP-10 Endpoints and Service Providers MUST be prepared to handle 1422 location represented in either civic or geo form. 1424 SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from 1425 the form of location the determination mechanism supplied. 1427 SP-12 Proxies MAY provide location on behalf of devices it supports 1428 if: 1429 o It has a relationship with all access networks the device could 1430 connect to, and the relationship allows it to obtain location. 1431 o It has an identifier that can be used by the access network to 1432 determine the location of the endpoint, particularly in the 1433 presence of NAT and VPN tunnels that may exist between the access 1434 network and the service provider. 1436 SP-13 Where proxies provide location on behalf of endpoints, the 1437 proxy MUST provide a mechanism to supply emergency dia lstrings to 1438 the device if the device recognizes them, or the proxy MUST track the 1439 location of the device with sufficient accuracy and timeliness to be 1440 able to recognize the local dial string at the time of an emergency 1441 call. 1443 SP-14 Location sent between SIP elements MUST be conveyed using 1444 [I-D.ietf-sip-location-conveyance]. 1446 SP-15 If a proxy inserts location on behalf of an endpoint, and it 1447 has multiple locations available for the endpoint it MUST choose one 1448 location to use to route the call towards the PSAP. 1450 SP-16 If a proxy is attempting to assert location but the UA conveyed 1451 a location to it, the proxy must use the UA?s location for routing 1452 and MUST convey that location towards the PSAP. It MAY also include 1453 what it believes the location to be. 1455 SP-17 All location objects received by a proxy MUST be delivered to 1456 the PSAP. 1458 SP-18 Location objects MUST contain information about the method by 1459 which the location was determined, such as GPS, manually entered, or 1460 based on access network topology included in a PIDF- LO ?method? 1461 element. In addition, the source of the location information MUST be 1462 included in a PIDF-LO "provided-by" element. 1464 SP-19 The "used-for-routing" parameter MUST be set to the location 1465 that was used to query LoST. 1467 SP-20 Proxies handling emergency calls MUST insert a default location 1468 if the call does not contain a location. 1470 SP-21 Default locations MUST be marked with method=Default and an 1471 appropriate provided-by in the PIDF-LO. 1473 SP-22 TLS MUST be used to protect location (but see Section 9). 1475 SP-23 Uninitialized devices SHOULD NOT be capable of placing an 1476 emergency call unless local regulations require it. 1478 SP-24 Uninitialized devices that can place emergency calls MUST 1479 supply location the same as a fully capable device would. 1481 SP-25 Unitialized Devices MUST supply a call back URI. See Section 7 1483 SP-26 Unitialized Devices MUST include identifiers in the signaling 1484 that can be used by the service provider to identify the device and 1485 to allow filtering of calls from the device by the PSAP/ESRP. 1487 SP-27 All proxies in the outbound path SHOULD recognize emergency 1488 calls with a Request URI of the service URN in the "sos" tree. An 1489 endpoint places a service URN in the Request URI to indicate that the 1490 endpoint understood the call was an emergency call. A proxy that 1491 processes such a call looks for the presence of a Route header with a 1492 URI of a PSAP. Absence of such a Route header indicates the UAC was 1493 unable to invoke LoST and the proxy MUST perform the LoST mapping and 1494 insert a Route header with the URI obtained. 1496 SP-28 To deal with old user agents that predate this specification 1497 and with UAs that do not have access to their own location data, 1498 proxies that recognize a call as an emergency call that is not marked 1499 as such (see Section 5) MUST also perform this mapping, with the best 1500 location it has available for the endpoint. The resulting PSAP URI 1501 would become the Request URI. 1503 SP-29 Proxy servers performing mapping SHOULD use location obtained 1504 from the access network for the mapping. If no location is 1505 available, a default location (see Section 6.11) MUST be supplied. 1507 SP-30 A proxy server which attempts mapping and fails to get a 1508 mapping MUST provide a default mapping. A suitable default mapping 1509 would be the mapping obtained previously for the default location 1510 appropriate for the caller. 1512 SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route an 1513 emergency call towards the PSAP's URI. 1515 SP-32 sips: MUST be specified when attempting to signal an emergency 1516 call with SIP 1518 SP-33 If TLS session establishment fails, the call MUST be retried 1519 with sip: 1521 SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent 1522 TLS connections between elements 1523 SP-35 SIP Proxy servers processing emergency calls: 1524 1. If the proxy does dial plan interpretation on behalf of user 1525 agents, the proxy MUST look for the local emergency dialstring at 1526 the location of the end device and MAY look for the home 1527 dialstring. If it finds it it MUST: 1528 * Insert a Geolocation header as per 10-12 above. Location-by- 1529 reference MUST be used because proxies may not insert bodies. 1530 * Include the Geolocation "inserted-by=server" AND "routed-by- 1531 this-uri" parameters. 1532 * Map the location to a PSAP uri using LoST. 1533 * Add a Route header with the service URN appropriate for the 1534 emergency dialstring. 1535 * Replace the Request-URI (which was the dialstring) with the 1536 PSAP URI obtained from LoST. 1537 * Route the call using normal SIP routing mechanisms. 1538 2. If the proxy recognizes the service URN in the Request URI, and 1539 does not find a Route header with a PSAP URI, it MUST run LoST 1540 routing. If a location was provided (which should be the case), 1541 the proxy uses that location to query LoST. The proxy may have 1542 to dereference a location by reference to get a value. If a 1543 location is not present, and the proxy can query a LIS which has 1544 the location of the UA it MUST do so. If no location is present, 1545 and the proxy does not have access to a LIS which could provide 1546 location, the proxy MUST supply a default location (See 1547 Section 6.11). The location (in the signaling, obtained from a 1548 LIS, or default) MUST be used in a query to LoST with the service 1549 URN received with the call. The resulting URI MUST be placed in 1550 a Route: header added to the call. 1551 3. The "inserted-by=" parameter in any Geolocation: header received 1552 on the call MUST NOT be modified or deleted in transit. 1553 4. The proxy SHOULD NOT modify any parameters in Geolocation: 1554 headers received in the call. It MAY add a Geolocation: header. 1555 Such an additional location SHOULD NOT be used for routing; the 1556 location provided by the UA should be used. 1557 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 1558 [RFC4474], or both, MUST be included to identify the sender. 1560 SP-36 Unitialized devices MUST have a globally routable URI in a 1561 Contact: header 1563 SP-37 Unitialized devices SHOULD have a persistent URI in a 1564 P-Asserted-Identity: header 1566 SP-38 During the course of an emergency call, devices and proxies 1567 MUST support REFER transactions and the Referred-by: header [RFC3515] 1568 to: 1570 1. Be REFERed to a conference bridge; PSAPs often include 1571 dispatchers, responders or specialists on a call. 1572 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are 1573 not located in the primary PSAP. The call may have to be 1574 transferred to another PSAP. Most often this will be an attended 1575 transfer, or a bridged transfer.(For devices that are Mobile) 1577 SP-39User agents and proxies MUST Support Session Timer [RFC4028] to 1578 guard against session corruption. 1580 SP-40 User Agents and proxys MUST disable outgoing call features such 1581 as: 1582 o Call Waiting 1583 o Call Transfer 1584 o Three Way Call 1585 o Flash hold 1586 o Outbound Call Blocking 1587 when an emergency call is established. 1589 SP-41 The emergency dialstrings SHOULD NOT be permitted in Call 1590 Forward numbers or speed dial lists. 1592 SP-42 The User Agent and Proxies SHOULD disable the following 1593 incoming call features on call backs from the PSAP: 1594 o Call Waiting 1595 o Do Not Disturb 1596 o Call Forward (all kinds) 1598 A.3. Requirements of Access Networks 1600 AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from 1601 the form of location the determination mechanism supplied. 1603 AN-2 Any suitable location determination mechanism MAY be used. 1605 AN-3 Devices and/or access networks SHOULD support a manual method to 1606 "override" the location the access network determines. Where a civic 1607 form of location is provided, all fields in the PIDF- LO [RFC4119] 1608 and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be specified. 1610 AN-4 Access networks supporting copper, fiber or other hard wired IP 1611 packet service SHOULD support location configuration. If the network 1612 does not support location configuration, it MUST require every device 1613 that connects to the network to support end system measured location. 1615 AN-5 Access networks providing wire database location information 1616 SHOULD provide interior location data where possible. It is 1617 RECOMMENDED that interior location be provided when spaces exceed 1618 approximately 650 m2 1620 AN-6 Access networks (including enterprise networks) which support 1621 intermediate range wireless connections (typically 100m or less of 1622 range) and which do not support a more accurate location 1623 determination mechanism such as triangulation, MUST support location 1624 configuration which reports the location of the access point as the 1625 location of the clients of that access point. 1627 AN-7 Devices that support endpoint measuring of location MUST have at 1628 least a coarse location (<1km) capability at all times for routing of 1629 calls. This mechanism MAY be a service provided by the access 1630 network. 1632 AN-8 Access networks MAY provide network measured location 1633 determination. Wireless access network which do not support network 1634 measured location MUST require all devices connected to the network 1635 have end-system measured location. Uncertainty of less than 100 m 1636 with 95% confidence SHOULD be available for dispatch. 1638 AN-9 Access networks that provide network measured location MUST have 1639 at least a coarse location (<1km) capability at all times for routing 1640 of calls. 1642 AN-10 Access networks with range of <10M MUST provide a location to 1643 mobile devices connected to it. The location provided SHOULD be that 1644 of the beacon location unless a more accurate mechanism is provided. 1646 AN-11 The access network MUST support at least one of DHCP location 1647 options, HELD or LLDP-MED. 1649 AN-12 Where a router is employed between a LAN and WAN in a small 1650 (less than approximately 650m2), the LAN MUST reflect the location 1651 provided by the WAN to the LAN. 1653 AN-13 Access networks that support more than one LCP MUST reply with 1654 the same location information (within the limits of the data format 1655 for the specific LCP) for all LCPs it supports. 1657 AN-14 Network administrators MUST take care in assigning IP addresses 1658 such that VPN address assignments can be distinguished from local 1659 devices (by subnet choice, for example), and LISs should not attempt 1660 to provide location to addresses that arrive via VPN connections. 1662 AN-15 Placement of NAT devices should consider the effect of the NAT 1663 on the LCP. 1665 AN-16 It is RECOMMENDED that location determination not take longer 1666 than 250 ms to obtain routing location and systems SHOULD be designed 1667 such that the typical response is under 100ms. However, as much as 3 1668 seconds to obtain routing location MAY be tolerated if location 1669 accuracy can be substantially improved over what can be obtained in 1670 250 ms. 1672 AN-17 Where the absolute location, or the accuracy of location of the 1673 endpoint may change between the time the call is received at the PSAP 1674 and the time dispatch is completed, location update mechanisms MUST 1675 be provided. 1677 AN-18 mobile devices MUST be provided with a mechanism to get 1678 repeated location updates to track the motion of the device during 1679 the complete processing of the call. 1681 AN-19 The LIS SHOULD provide a location reference which permits a 1682 subscription with appropriate filtering. 1684 AN-20 For calls sent with location-by-reference, with a SIP or SIPS 1685 scheme, the server resolving the reference MUST support a SUBSCRIBE 1686 [RFC3118] to the presence event [RFC3856]. For other location-by- 1687 reference schemes, a repeated location dereference by the PSAP MUST 1688 be supported. 1690 AN-21 Location validation of civic locations via LoST SHOULD be 1691 performed by the LIS before entering a location in its database. 1693 AN-22 When the access network cannot determine the actual location of 1694 the caller, it MUST supply a default location. The default SHOULD be 1695 chosen to be as close to the probable location of the device as the 1696 network can determine. 1698 AN-23 Default locations MUST be marked with method=Default and an 1699 appropriate provided-by in the PIDF-LO. 1701 AN-24 To prevent against spoofing of the DHCP server, elements 1702 implementing DHCP for location configuration SHOULD use [RFC3118]. 1704 AN-25 Uninitialized devices SHOULD NOT be capable of placing an 1705 emergency call unless local regulations require it. 1707 AN-26 Uninitialized devices that can place emergency calls MUST 1708 supply location the same as a fully capable device would. 1710 AN-27 https: MUST be specified when attempting to retrieve location 1711 (configuration or dereferencing) with HELD 1713 Authors' Addresses 1715 Brian Rosen 1716 NeuStar 1717 470 Conrad Dr. 1718 Mars, PA 16046 1719 US 1721 Phone: +1 724 382 1051 1722 Email: br@brianrosen.net 1724 James M. Polk 1725 Cisco Systems 1726 3913 Treemont Circle 1727 Colleyville, TX 76034 1728 US 1730 Phone: +1-817-271-3552 1731 Email: jmpolk@cisco.com 1733 Full Copyright Statement 1735 Copyright (C) The IETF Trust (2007). 1737 This document is subject to the rights, licenses and restrictions 1738 contained in BCP 78, and except as set forth therein, the authors 1739 retain all their rights. 1741 This document and the information contained herein are provided on an 1742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1744 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1745 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1746 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1749 Intellectual Property 1751 The IETF takes no position regarding the validity or scope of any 1752 Intellectual Property Rights or other rights that might be claimed to 1753 pertain to the implementation or use of the technology described in 1754 this document or the extent to which any license under such rights 1755 might or might not be available; nor does it represent that it has 1756 made any independent effort to identify any such rights. Information 1757 on the procedures with respect to rights in RFC documents can be 1758 found in BCP 78 and BCP 79. 1760 Copies of IPR disclosures made to the IETF Secretariat and any 1761 assurances of licenses to be made available, or the result of an 1762 attempt made to obtain a general license or permission for the use of 1763 such proprietary rights by implementers or users of this 1764 specification can be obtained from the IETF on-line IPR repository at 1765 http://www.ietf.org/ipr. 1767 The IETF invites any interested party to bring to its attention any 1768 copyrights, patents or patent applications, or other proprietary 1769 rights that may cover technology that may be required to implement 1770 this standard. Please address the information to the IETF at 1771 ietf-ipr@ietf.org. 1773 Acknowledgment 1775 Funding for the RFC Editor function is provided by the IETF 1776 Administrative Support Activity (IASA).