idnits 2.17.00 (12 Aug 2021) /tmp/idnits3503/draft-ietf-ecrit-phonebcp-01.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 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 935. 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 -- 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 (March 05, 2007) is 5556 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) == Missing Reference: 'L7 LCP' is mentioned on line 704, but not defined == Unused Reference: 'I-D.ietf-sipping-service-examples' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'I-D.rosen-iptel-dialstring' is defined on line 786, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-framework (ref. 'I-D.ietf-ecrit-framework') == Outdated reference: draft-ietf-ecrit-lost has been published as RFC 5222 == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 == Outdated reference: draft-ietf-mmusic-media-loopback has been published as RFC 6849 == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-07 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: draft-ietf-sipping-service-examples has been published as RFC 5359 == Outdated reference: draft-ietf-sipping-toip has been published as RFC 5194 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-toip (ref. 'I-D.ietf-sipping-toip') == Outdated reference: draft-rosen-iptel-dialstring has been published as RFC 4967 -- 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: 13 errors (**), 0 flaws (~~), 14 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: September 6, 2007 Cisco Systems 6 March 05, 2007 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-01.txt 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 September 6, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 Requesting help in an emergency using a communications device such as 44 a telephone or mobile is an accepted practice in most of the world. 45 As communications devices increasingly utilize the Internet to 46 interconnect and communicate, users will continue to expect to use 47 such devices to request help, regardless of whether or not they 48 communicate using IP. The emergency response community will have to 49 upgrade their facilities to support the wider range of communications 50 services, but cannot be expected to handle wide variation in device 51 and service capability. The IETF has several efforts targeted at 52 standardizing various aspects of placing emergency calls. This memo 53 describes best current practice on how devices and services should 54 use such standards to reliably make emergency calls 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Which devices and services should support emergency calls . . 4 61 4. Location . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Endpoints learn their own location . . . . . . . . . . . . 5 63 4.2. Location Configuration Protocols . . . . . . . . . . . . . 5 64 4.3. Self reported Location . . . . . . . . . . . . . . . . . . 6 65 4.4. When Location should be Configured . . . . . . . . . . . . 6 66 4.5. Other location considerations . . . . . . . . . . . . . . 7 67 5. Determining an emergency call . . . . . . . . . . . . . . . . 7 68 6. Session Signaling . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. SIP signaling requirements for User Agents . . . . . . . . 9 70 6.2. SIP signaling requirements for proxy servers and B2BUAs . 10 71 6.3. Mapping from Location to a PSAP URI . . . . . . . . . . . 11 72 6.4. Routing the call . . . . . . . . . . . . . . . . . . . . . 12 73 6.5. Responding to PSAP signaling . . . . . . . . . . . . . . . 12 74 6.6. Disabling of features . . . . . . . . . . . . . . . . . . 13 75 7. Location Update . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Testing Mechanism . . . . . . . . . . . . . . . . . . . . 14 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 10.1. Threats against endpoints . . . . . . . . . . . . . . . . 15 81 10.2. Threats against the Emergency Service . . . . . . . . . . 16 82 11. Normative References . . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Intellectual Property and Copyright Statements . . . . . . . . . . 21 86 1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 This document describes how SIP User Agents and proxy servers support 95 emergency calling, as outlined in [I-D.ietf-ecrit-framework]. Here, 96 an emergency call refers to a communications session established by a 97 user to a "Public Safety Answering Point" (PSAP) which is a call 98 center established by response agencies to accept emergency calls. 99 We differentiate such calls from other sessions which are created by 100 responders using public communications infrastructure often involving 101 some kind of priority access as defined in Emergency 102 Telecommunications Service (ETS) in IP Telephony [RFC4190]. By 103 implication, this document describes the interface between the 104 emergency services network and the Internet. This memo also 105 describes how location may be obtained from the local access 106 infrastructure (broadband network), and thus specifies requirements 107 to support location in such infrastructure. 109 Making an emergency call involves the use of location information, 110 referring to the physical location of the caller. Location is used 111 within the emergency calling system to route a call to the correct 112 PSAP, as well as by the PSAP to choose the correct responder, and 113 direct them to the person in need of assistance. 115 The steps involved in an emergency call from an IP based device are 116 (with a rough ordering of operation) 117 1. Device connects to access network, and obtains initial location 118 2. User dials visited location's emergency number 119 3. User device identifies call as emergency call 120 4. User device includes location indication (by value or by 121 reference) in the call set-up messaging 122 5. emergency call set-up is routed to appropriate PSAP based on 123 location of the caller 124 6. call is established with PSAP 125 7. caller's location is presented to PSAP operator for dispatch 127 As a quick overview for a typical Ethernet connected telephone using 128 SIP signaling: 129 o the phone "boots" and connects to its access network 130 o the phone would get location from the DHCP server [an L7 server] 131 or the first level switch's LLDP server. 133 o the phone obtains the local emergency dialstring(s) from the 134 [I-D.ietf-ecrit-lost] server. 135 o It recognizes an emergency call from the dialstrings and uses 136 "urn:service:sos" to mark an emergency call. 137 o It would determine the PSAP's URI by using the 138 [I-D.ietf-ecrit-lost] mapping server from the location provided 139 o It would put its location in the SIP INVITE as a PIDF-LO in the 140 body of the INVITE (or a reference to location in a Location 141 header) [I-D.ietf-sip-location-conveyance] and forward the call to 142 its first hop proxy. 143 o The proxy recognizes the call as an emergency call and routes the 144 call using normal SIP routing mechanisms. 145 o The call is established and common media streams opened. 147 Best Current Practice for SIP user agents including handling of audio 148 and real-time text [RFC4103]media detailed in [RFC4504] SHOULD be 149 applied. This memo can be considered an addition to it for 150 endpoints. 152 3. Which devices and services should support emergency calls 154 Support for voice calls and real-time text calls placed through PSTN 155 facilities or systems connected to the PSTN is found in present 156 PSAPs. Future PSAPs will however support Internet connectivity and a 157 wider range of media types and provide higher functionality.. In 158 general, if a user could reasonably expect to be able to call for 159 help with the device, then the device or service should support 160 emergency calling. Certainly, any device or service that looks like 161 and works like a telephone (wired or mobile) should support emergency 162 calling, but increasingly, users have expectations that other devices 163 and services should work. 165 Using current (evolving) standards, devices that create media 166 sessions and exchange audio, video and/or text, and have the 167 capability to establish sessions to a wide variety of addresses, and 168 communicate over private IP networks or the Internet, should support 169 emergency calls. 171 4. Location 173 Location is central to the operation of emergency services. Location 174 is used to route a call to the PSAP that serves the location, and it 175 is used to dispatch responders to the person in need of help. It is 176 frequently the case that the user in an emergency is unable to 177 provide a unique, valid location themselves. For this reason, 178 automatic location is the norm. 180 In Internet emergency calling, we "Determine" where the endpoint is 181 located using a variety of measurement or wiretracing methods. We 182 "Configure" endpoints with their own location. We "Map" the location 183 to the URI to send the call to, and we "Convey" the location to the 184 PSAP (and other elements) in the signaling. These topics are 185 detailed in [I-D.ietf-ecrit-framework]. 187 4.1. Endpoints learn their own location 189 With Internet based communications services, determining where the 190 caller is located is more problematic than in PSTN and mobile 191 systems. Existing wired phones are tethered with a wire that is 192 connected directly to a call control device, a circuit switch. 193 Cellular phones are tethered via a radio channel to a cell tower, 194 which connects that cell phone to a circuit switch. The primary 195 difficulty with IP based phones is that the connectivity, whether 196 wired or radio channel, is decoupled from the call control device. 197 The communications service may not have any relationship with the 198 access network carrier, and, with NAT and VPN tunnels, may have no 199 way to even find out who the access carrier is. 201 For this reason, standards have been created for endpoints (devices) 202 to obtain location information where it is the access network that 203 knows the location of the endpoint. To obtain location information, 204 the endpoint can use a Location Configuration Protocol. The endpoint 205 is a subscriber to both the access network and the communications 206 service, and thus is in a position to obtain its location from the 207 access network, and supply it to the communications service. These 208 issues, and the necessity for endpoints and access networks to 209 support LCPs is detailed in [I-D.ietf-ecrit-framework]. 211 4.2. Location Configuration Protocols 213 For devices that operate on a network where the network operator 214 controls the specification of every device connected to that network 215 that could be used for emergency calls, the method by which location 216 is determined need not be an IETF standard, but can be any method 217 that achieves the desired result. Such a method MUST be specified, 218 and every device MUST support it. It is recommended that, in 219 addition, the network SHOULD support one or more of DHCP, 220 [Placeholder for L7 LCP} or LLDP-MED. 222 For all other devices, the device MUST support DHCP, [Placeholder for 223 L7 LCP] and LLDP-MED. The access network MUST support at least one 224 of these. 226 DHCP [RFC2131] has been enhanced to provide the location of a device. 227 [RFC3825] describes how a geo-location (lat/lon/alt) may be obtained 228 and [RFC4676] describes how a civic (street address) location can be 229 obtained via DHCP. 231 [Placeholder for HELD, RELO or other L7 location determination 232 methods] 234 [LLDP] with [LLDP-MED] extensions provides location configuration 235 applicable in many enterprise environments. 237 For devices that operate in a network where the network operator 238 controls the specification of every device connected to that network, 239 but the network attachment supports upstream networks to which 240 communications devices are connected (such as any network that 241 supports Ethernet connected telephones and terminal adapters), the 242 method by which location is determined need not be an IETF standard, 243 but can be any method which achieves the desired result. However, 244 the network attachment MUST support at least one of DHCP [L7 LCP] or 245 LLDP-MED for upstream communications devices to obtain location. For 246 smaller interior (e.g, LAN) networks, the DHCP, [L7 LCP] or LLDP-MED 247 server should simply repeat the location obtained from the access 248 network. For larger networks, other mechanisms, such as a DHCP Relay 249 Agent [RFC3046] SHOULD be used to provide more accurate location of 250 endpoints. 252 4.3. Self reported Location 254 Self reported location, where a user enters location himself, is 255 generally unacceptable in emergency calls, although it is being used 256 prior to automatic location determination schemes being fielded. 257 Local laws may govern what is acceptable in any country or area. 258 Devices and/or access networks SHOULD support a manual method to 259 "override" the location the access network determines. The access 260 network generally only knows the location of its demarcation point 261 between the access network and the subscriber. The subscriber could 262 have an extended network behind the demarc unknown to the access 263 network. A method to account for this condition SHOULD be provided. 265 4.4. When Location should be Configured 267 Devices SHOULD get location immediately after obtaining local network 268 configuration information. It is essential for the location to be 269 determined BEFORE any VPN tunnels are established. It is equally 270 essential that this location information is *not* overwritten by any 271 process engaged from establishing a VPN connection. In other words, 272 the established VPN to Chicago from the device in Dallas MUST NOT 273 overwrite the Dallas location for any reason especially an emergency 274 call. 276 It is desirable that location information be periodically refreshed. 277 For devices which are not expected to roam, refreshing on the order 278 of once per day is RECOMMENDED. For devices which roam, refresh of 279 location SHOULD be more frequent, with the frequency related to the 280 mobility of the device and the ability of the access network to 281 support the refresh operation. There can be instances in which a 282 device is aware of when it moves, for example when it changes access 283 points. When this type of event occurs, the device SHOULD refresh 284 its location. 286 It is desirable for location information to be requested immediately 287 before placing an emergency call. However, if there is any delay in 288 getting more recent location, the call SHOULD be placed with the most 289 recent location information the device has. It is RECOMMENDED that 290 the device not wait longer than 1 sec to obtain updated location, and 291 systems should ideally be designed such that the typical response is 292 under 100ms. These numbers are empirically derived, but are intended 293 to keep total call signaling time below 2 seconds. There are 294 conflicts between the time it takes to generate location when 295 measuring techniques are used and the desire to route the call 296 quickly. If an accurate location cannot be determined quickly, a 297 rough location SHOULD be returned within 100ms which can be used to 298 route the call. The location of the nearest base station in a 299 wireless network is an example of a rough location. 301 4.5. Other location considerations 303 If the LCP does not return location in the form of a PIDF-LO 304 [RFC4119], the endpoint MUST map the location information it receives 305 from the configuration protocol to a PIDF-LO. 307 To prevent against spoofing of the DHCP server, devices implementing 308 DHCP for location configuration SHOULD use [RFC3118]. 310 5. Determining an emergency call 312 An emergency call is distinguished by the device (or a downstream 313 element) by an "address", which in most cases for Internet connected 314 devices is still a dialstring, although other user interfaces may be 315 used. 317 Note: It is undesirable to have a single "button" emergency call user 318 interface element. These mechanisms have a very high false call 319 rate. PSAPs prefer devices to use their local emergency call 320 dialstring. 322 While in some countries there is a single 3 digit dialstring that is 323 used for all emergency calls (i.e. 911 in North America), in some 324 countries there are several 3 digit numbers used for different types 325 of calls. For example, in Switzerland, 117 is used to call police, 326 118 is used to call the fire brigade, and 144 is used for emergency 327 medical assistance. In other countries, there are no "short codes" 328 or "service codes" for 3 digit dialing of emergency services and 329 local (PSTN) numbers are used. 331 [I-D.ietf-ecrit-service-urn] introduces a universal emergency service 332 URN scheme. On the wire, emergency calls SHOULD include this type of 333 URI as a Route header [RFC3261]. The scheme includes a single 334 emergency URN (urn:service:sos) and responder specific ones 335 (urn:service:sos.police). Using the service:sos URN scheme, 336 emergency calls can be recognized as such throughout the Internet. 338 Devices MUST use the service:sos URN scheme to mark emergency calls. 340 To determine which calls are emergency calls, some entity needs to 341 map a user entered dialstring into this URN scheme. A user may 342 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 343 mapping is SHOULD performed at the endpoint device, but MAY be 344 performed at an intermediate entity (such as a SIP proxy server). 346 Note: It is strongly RECOMMENDED that devices recognize the emergency 347 dialstring(s) and map to the universal emergency URN. If devices 348 cannot do "dial plan interpretation", then the first signaling aware 349 element (first hop proxy in SIP signaled devices) SHOULD do the 350 mapping. It is important to not require a large number of active 351 elements handle a call before it is recognized as an emergency call 353 In systems that support roaming, there may be a concept of "visited" 354 and "home" networks. Even when there is not a "visited network", the 355 user may be roaming (or nomadic) in a different country from their 356 home. This gives rise to the problem of which dialstring(s) to 357 recognize, the "home" or "visited"? While the "home" dialstrings 358 SHOULD be recognized, it is required (by law in some countries) that 359 the "visited" dialstrings MUST be recognized. "Visited" dialstrings 360 would be essential if a guest used a roaming phone. Dial plan 361 interpretation may need to take "visited" emergency dialstrings into 362 account. 364 To give an example of this difference in dialstrings: If the device 365 is from North America, the home and visited emergency dialstring is 366 "9-1-1". If that devices roams to the UK, the home emergency 367 dialstring is still "9-1-1", but the visited emergency dialstring 368 would become "9-9-9". If the device roams to Paris, the home 369 dialstring remains the same, "9-1-1", but the visited dialstring 370 changes from 999 to "1-1-2". 372 The home emergency dialstrings MAY be provisioned into the device (or 373 other element doing dialstring to universal emergency call URN 374 mapping). [I-D.ietf-ecrit-lost]) provides dialstrings for a given 375 location and SHOULD be used by devices to learn the local (i.e. 376 "visited" dialstrings. "Home" dialstrings MAY be learned by 377 configuration. 379 6. Session Signaling 381 SIP signaling [RFC3261] is expected be supported by upgraded PSAPs. 382 Gateways MAY be used between Internet connected devices and older 383 PSAPs. Some countries may support other signaling protocols into 384 PSAPs. 386 6.1. SIP signaling requirements for User Agents 388 The initial SIP signaling Method is an INVITE. 389 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see 390 Section 6.3). If the device cannot access a LoST server, the 391 To: SHOULD be a service URN in the "sos" tree. If the device 392 cannot do local dialstring interpretation, the Request-URI 393 SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the 394 dialed digits. A sips URI [RFC3261] MUST be specified, unless 395 the operation must be retried due to a failure to establish a 396 TLS connection. 397 2. The To: header MUST be present and SHOULD be a service URN in 398 the "sos" tree. If the device cannot do local dialstring 399 interpretation, the To: SHOULD be a dialstring URI with the 400 dialed digits. sips MUST be specified, unless the operation must 401 be retried due to a failure to establish a TLS connection. 402 3. The From: header MUST be present and SHOULD be the AoR of the 403 caller. 405 NOTE: unintialized devices may not have an AoR available 406 4. A Via: header MUST be present and SHOULD include the URI of the 407 device 408 5. A Route header SHOULD be present with the service URN in the 409 "sos" tree, and the loose route parameter. 410 6. Either a P-Asserted-Identity [RFC3325] or an Identity header 411 [RFC4474], or both, SHOULD be included to identify the sender. 412 7. A Contact header MUST be present (which might contain a GRUU 413 [I-D.ietf-sip-gruu]) to permit an immediate call-back to the 414 specific device which placed the emergency call. 415 8. Other headers MAY be included as per normal sip behavior 416 9. A Supported: header MUST be included with the 'geolocation' 417 option tag [I-D.ietf-sip-location-conveyance], unless the device 418 does not understand the concept of SIP Location. 420 10. If the device's location is by-reference, a Geolocation: header 421 [I-D.ietf-sip-location-conveyance] MUST be present containing 422 the URI of the PIDF-LO reference for that device. Whichever 423 location is used for routing the message towards the PSAP or 424 ESRP, even if there is only one, the Geolocation "message- 425 routed-on-this-uri" header parameter SHOULD be added to the 426 corresponding URI in the Geolocation header. 427 11. if a device understands the SIP Location Conveyance 428 [I-D.ietf-sip-location-conveyance] extension and has its 429 location available, it MUST include location either by-value or 430 by-reference. If it is by-value, the INVITE contains a 431 Supported header with a "geolocation" option tag, and a "cid- 432 URL" [RFC2396] as the value in the Geolocation header, 433 indicating which message body part contains the PIDF-LO. If the 434 INVITE contains a location by-reference, it includes the same 435 Supported header with the "geolocation" option tag, and includes 436 the URI of the PIDF-LO on a remote node in a Geolocation header. 437 [I-D.ietf-geopriv-pdif-lo-profile] MUST be used 438 12. If a device understands the SIP Location Conveyance extension 439 and has its location unavailable or unknown to that device, it 440 MUST include a Supported header with a "geolocation" option tag, 441 and not include a Geolocation header, and not include a PIDF-LO 442 message body. 443 13. A normal SDP offer SHOULD be included in the INVITE. The offer 444 MUST include the G.711 codec, see Section 8. 445 14. If the device includes location-by-value, the UA MUST support 446 multipart message bodies, since SDP will likely be also in the 447 INVITE. 448 15. A UAC SHOULD include the Geolocation "inserted-by=endpoint" 449 header parameter. This informs downstream elements which device 450 entered the location at this URI (either cid-URL or location-by- 451 reference URI). 453 6.2. SIP signaling requirements for proxy servers and B2BUAs 455 SIP Proxy servers processing emergency calls: 456 1. If the proxy does dial plan interpretation on behalf of user 457 agents, the proxy MUST look for the local emergency dialstring at 458 the location of the end device. If it finds it it MUST: 459 * Obtain the location (or a reference to it) for the endpoint 460 * Insert a Geolocation header as per 10-12 above 461 * Include the Geolocation "inserted-by=server" AND "routed-by- 462 this-uri" parameters. 463 * Map the location to a PSAP uri using LoST. 464 * Add a Route header with the service URN appropriate for the 465 emergency dialstring. 467 * Replace the Request-URI (which was the dialstring) with the 468 PSAP URI obtained from LoST. 469 * Route the call using normal SIP routing mechanisms. 470 2. The "inserted-by=" header parameter MUST NOT be modified or 471 deleted in transit. 472 3. If a Geolocation "message-routed-on-this-uri" header parameter 473 exists when a new SIP server processes a message, and the message 474 is routing is now to be done based on another Geolocation URI 475 (by-value or by-reference), the "message-routed-on-this-uri" 476 header parameter MUST be removed from the old Geolocation URI and 477 inserted with the now applicable location URI in the Geolocation 478 header. 480 6.3. Mapping from Location to a PSAP URI 482 To route an emergency call, we make use of the [I-D.ietf-ecrit-lost] 483 mapping service which takes a location expressed by a PIDF-LO and 484 returns one or more PSAP URIs. The request includes the service URN 485 which is used to determine which entity should receive the call. 486 Ideally, mapping from location to the PSAP URI would be accomplished 487 at the time the emergency call is placed. However, it could be that 488 when the emergency occurs, the LoST server is unavailable to the 489 caller, or busy. To guard against that, devices MUST cache a 490 mapping. The mapping MUST be performed at boot time, and whenever 491 the location changes such that the previous mapping may no longer 492 valid. To facilitate this operation, LoST provides a mechanism that 493 a device can use to determine when it should refresh the mapping. 494 Devices where location changes SHOULD use this mechanism to maintain 495 a desired mapping. 497 User agents that can obtain location information MUST perform the 498 mapping from location information to PSAP URI using 499 [I-D.ietf-ecrit-lost]. The mapping is performed whenever the UA 500 acquires new location information that is outside the bounds of the 501 current PSAP coverage region specified in the LoST response or the 502 time-to-live value of that response has expired. 504 Determining when the device leaves the area provided by the LoST 505 service can tax small mobile devices. For this reason, the LoST 506 server SHOULD return a simple (small number of points) polygon for 507 geo reported location. This can be an enclosing subset of the area 508 when the reported point is not near an edge, or a smaller edge 509 section when the reported location is near an edge. Civic location 510 is uncommon for mobile devices, but reporting that the same mapping 511 is good within a community name, or even a street, may be very 512 helpful for WiFi connected devices that roam and obtain civic 513 location from the AP they are connected to. 515 All proxies in the outbound path SHOULD recognize emergency calls 516 with a Request URI of the service URN in the "sos" tree. A proxy 517 recognizing such a call (which indicates that the endpoint understood 518 the call was an emergency call, but was unable to map its location to 519 a PSAP URI) MUST perform the LoST mapping and retarget the call to 520 the PSAP URI (the service URN SHOULD remain as a Route header). 522 To deal with old user agents that predate this specification and with 523 UAs that do not have access to their own location data, proxies that 524 recognize a call as an emergency call that is not marked as such (see 525 Section 5) or where the Request-URI is a service:sos URN MUST also 526 perform this mapping, with the best location it has available for the 527 endpoint. The resulting PSAP URI would become the Request URI. 529 6.4. Routing the call 531 Normal routing mechanisms for the specified URI should be used. For 532 SIP signaled devices, the domain of the URI should be extracted, and 533 the DNS consulted for a sip (or sips) SRV. The resulting NAPTR, if 534 present, should be used for the FQDN of the server. 536 6.5. Responding to PSAP signaling 538 The PSAP is expected to use normal signaling (e.g. SIP) as per IETF 539 standards. Devices and proxies should expect to: 540 1. Be REFERed to a conference bridge; PSAPs often include 541 dispatchers, responders or specialists on a call. 542 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are 543 not located in the primary PSAP. The call may have to be 544 transferred to another PSAP. Most often this will be an attended 545 transfer, or a bridged transfer. 546 3. (For devices that are Mobile) SUBSCRIBE to the Presence of the 547 AoR (or equivalent for other signaling schemes) to get location 548 updates. 549 4. Support Session Timer (or equivalent) to guard against session 550 corruption 552 Devices with an active emergency call (i.e. SIP Dialog) MUST NOT 553 generate a BYE request (or equivalent for other non-SIP signaling). 554 The PSAP must be the only entity that can terminate a call. If the 555 user "hangs up" an emergency call, the device should ring, and when 556 answered, reconnect the caller to the PSAP. 558 There can be a case where the session signaling path is lost, and the 559 user agent does not receive the BYE. If the call is hung up, the 560 session timer expires, and 5 minutes elapses from the last message 561 received by the device from the PSAP, the call may be declared lost. 562 If in the 5 minute interval an incoming call is received from the 563 domain of the PSAP, the device should drop the old call and alert for 564 the (new) incoming call. 566 6.6. Disabling of features 568 The calling device and/or service SHOULD disable outgoing call 569 features such as: 570 o Call Waiting 571 o Call Transfer 572 o Three Way Call 573 o Flash hold 574 o Outbound Call Blocking 576 The emergency dialstrings SHOULD NOT be permitted in Call Forward 577 numbers or speed dial lists. 579 The device and/or service SHOULD disable the following incoming call 580 features on calls from the PSAP: 581 o Call Waiting (all kinds) 582 o Do Not Disturb 583 o Call Forward (all kinds) (if the PSAP calls back within some 584 (30min) interval) 586 7. Location Update 588 Devices which are mobile may not be able to report an accurate 589 location when an emergency call is placed. Some deployments of 590 location measurement are not always on, and when an emergency call is 591 initiated, the time to get an accurate "first fix" may be several 592 seconds. That is too long to wait to begin processing of the call. 593 In such cases, a fast fix, or the location of a tower serving a 594 wireless mobile device may be used to route the call, with accurate 595 location coming later on, after the call is answered. It is possible 596 that the PSAP that should handle the call once the accurate location 597 is available is different from the PSAP serving the tower or the 598 first fix location. 600 Mobile devices may be moving while an emergency call is in progress. 601 The PSAPs, and/or the responders may change as the location changes. 603 For these reasons, and others, update of location is needed. 604 Generally, updates should occur after the call is completed. The 605 PSAP controls location update. For calls sent with location-by- 606 value, the PSAP MAY reINVITE the endpoint and the 200 OK from the 607 endpoint MUST include the location. For calls send with location-by- 608 reference, with a SIP or SIPS scheme, the server resolving the 609 reference MUST support a SUBSCRIBE [RFC3118] to the presence event 611 [RFC3856]. For other location-by-reference schemes, a repeated 612 location dereference by the PSAP MUST be supported. 614 8. Media 616 Endpoints MUST send and receive media streams on RTP [RFC3550]. 617 Traditionally, voice has been the only media stream accepted by 618 PSAPs. In some countries, text, in the form of BAUDOT codes or 619 similar tone encoded signaling within a voiceband is accepted ("TTY") 620 for persons who have hearing disabilities. With the Internet comes a 621 wider array of potential media which a PSAP should accept. Using SIP 622 signaling includes the capability to negotiate media. Normal SIP 623 offer/answer [RFC3264] negotiations MUST be used to agree on the 624 media streams to be used. 626 Endpoints supporting voice MUST support G.711 A law (and mu Law in 627 North America) encoded voice as described in [RFC3551]. It is 628 desirable to support wideband codecs in the offer Silence suppression 629 (Voice Activity Detection methods) MUST NOT be used on emergency 630 calls. PSAP call takers sometimes get information on what is 631 happening in the background to determine how to process the call. 633 Newer text forms are rapidly appearing, with Instant Messaging now 634 very common, endpoints supporting IM MUST support either [RFC3428] or 635 [RFC3920]. Endpoints supporting real-time text MUST use [RFC4103]. 636 The expectations for emergency service support for the real-time text 637 medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be 638 fulfilled. 640 Video may be important to support Video Relay Service (Sign language 641 interpretation) as well as modern video phones. Endpoints supporting 642 video MUST support H.264 per [RFC3984]. 644 9. Testing 646 9.1. Testing Mechanism 648 INVITE requests to a service urn with a urn parameter of "test" 649 indicates a request for an automated test. For example, 650 "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response 651 indicates that the address was recognized and a 404 (Not found) that 652 it was not. A 486 (Busy Here) MUST be returned if the test service 653 is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP 654 does not support the test mechanism. 656 In its response to the test, the PSAP MAY include a text body 657 indicating the identity of the PSAP, the requested service, and the 658 location reported with the call. For the latter, the PSAP SHOULD 659 return location-by-value even if the original location delivered with 660 the test was by-reference. 662 A PSAP accepting a test call SHOULD accept a media loopback 663 test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt- 664 loopback" and "rtp-start-loopback" options. The user agent would 665 specify a loopback attribute of "loopback-source", the PSAP being the 666 mirror. User Agents should expect the PSAP to loop back no more than 667 3 packets of each media type accepted, after which the PSAP would 668 normally send BYE. 670 User agents SHOULD perform a full call test, including media 671 loopback, after a disconnect and subsequent change in IP address. 672 After an initial IP address assignment test, a full test SHOULD be 673 repeated approximately every 30 days with a random interval. 675 User agents MUST NOT place a test call immediately after booting, as 676 a widespread power outage and subsequent restoration would impose an 677 inordinate load on the emergency call routing system. 679 PSAPs MAY refuse repeated requests for test from the same device in a 680 short period of time. 682 10. Security Considerations 684 There are no new security considerations beyond those in the 685 normative references. This memo does not introduce any new 686 protocols; it specifies use of several of them. 688 10.1. Threats against endpoints 690 The largest threat against the endpoint is inadvertent disclosure of 691 its location. The endpoint acquires location from a Location 692 Configuration Protocol. Some of the protocols are very limited as to 693 the scope which messages within the protocol are distributed. DHCP 694 for example is limited to the local subnet. LLDP is limited to the 695 link. The [L7 LCP] is not limited and TLS SHOULD be used to protect 696 location privacy. 698 The location configuration server could be spoofed, thus providing 699 wrong location, and misdirecting help when an emergency call is 700 placed. When DHCP is the LCP [RFC3118] SHOULD be used to prevent 701 spoofing if possible. LLDP server spoofing would be limited to 702 devices connected to the link and is not seen as a credible threat. 703 Deployments should limit hubs and downstream switches to IP connected 704 devices that could be used to place emergency calls. [L7 LCP] SHOULD 705 use DIGEST authentication (or better) to identify the LIS. 707 The LoST server, which is the source of Location to PSAP URI mapping, 708 and local dialstrings, could be spoofed. Use of DHCP to obtain the 709 location of the server limits the ability to misdirect the user. 710 LoST protocol use SHOULD include TLS with server certs to prevent 711 spoofing. 713 The PSAP could be spoofed. Client SHOULD use TLS with server certs 714 to prevent spoofing. 716 10.2. Threats against the Emergency Service 718 The largest threats to the Emergency Service are forgery of location 719 and denial of service attacks on the PSAP and/or ESRP. 721 To mitigate forgery of location, location object SHOULD be signed. 722 Since access networks and PSAPs are usually local to each other, 723 providing a PKI should not be onerous for many residential 724 deployments. However, enterprises may deploy access networks with 725 location, which is to be encouraged. PKI covering all enterprises 726 within a PSAP service area may be much more problematic. 728 To mitigate denial of service attacks, endpoint SHOULD use TLS (which 729 implies TCP) in the signaling towards the LoST server and the PSAP/ 730 ESRP. Return routability of signaling would help significantly. Use 731 of P-Asserted-Identity or SIP Identity is also REQUIRED of calling 732 networks. 734 11. Normative References 736 [I-D.ietf-ecrit-framework] 737 Rosen, B., "Framework for Emergency Calling in Internet 738 Multimedia", draft-ietf-ecrit-framework-00 (work in 739 progress), October 2006. 741 [I-D.ietf-ecrit-lost] 742 Hardie, T., "LoST: A Location-to-Service Translation 743 Protocol", draft-ietf-ecrit-lost-04 (work in progress), 744 February 2007. 746 [I-D.ietf-ecrit-service-urn] 747 Schulzrinne, H., "A Uniform Resource Name (URN) for 748 Services", draft-ietf-ecrit-service-urn-05 (work in 749 progress), August 2006. 751 [I-D.ietf-geopriv-pdif-lo-profile] 752 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 753 Considerations and Recommendations", 754 draft-ietf-geopriv-pdif-lo-profile-05 (work in progress), 755 October 2006. 757 [I-D.ietf-mmusic-media-loopback] 758 Hedayat, K., "An Extension to the Session Description 759 Protocol (SDP) for Media Loopback", 760 draft-ietf-mmusic-media-loopback-05 (work in progress), 761 September 2006. 763 [I-D.ietf-sip-gruu] 764 Rosenberg, J., "Obtaining and Using Globally Routable User 765 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 766 (SIP)", draft-ietf-sip-gruu-11 (work in progress), 767 October 2006. 769 [I-D.ietf-sip-location-conveyance] 770 Polk, J. and B. Rosen, "Session Initiation Protocol 771 Location Conveyance", 772 draft-ietf-sip-location-conveyance-07 (work in progress), 773 February 2007. 775 [I-D.ietf-sipping-service-examples] 776 Johnston, A., "Session Initiation Protocol Service 777 Examples", draft-ietf-sipping-service-examples-12 (work in 778 progress), January 2007. 780 [I-D.ietf-sipping-toip] 781 Wijk, A. and G. Gybels, "Framework for real-time text over 782 IP using the Session Initiation Protocol (SIP)", 783 draft-ietf-sipping-toip-07 (work in progress), 784 August 2006. 786 [I-D.rosen-iptel-dialstring] 787 Rosen, B., "Dialstring parameter for the Session 788 Initiation Protocol Uniform Resource Identifier", 789 draft-rosen-iptel-dialstring-05 (work in progress), 790 March 2007. 792 [LLDP] IEEE, "IEEE 802.1AB-2005, Station and Media Access Control 793 Connectivity Discovery (aka Link Layer Discovery Protocol 794 - LLDP)", May 2004. 796 [LLDP-MED] 797 TIA, "ANSI/TIA-1057, Link Layer Discovery Protocol for 798 Media Endpoint Devices (aka LLDP-MED)", Apr 2006. 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, March 1997. 803 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 804 RFC 2131, March 1997. 806 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 807 Resource Identifiers (URI): Generic Syntax", RFC 2396, 808 August 1998. 810 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 811 RFC 3046, January 2001. 813 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 814 Messages", RFC 3118, June 2001. 816 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 817 A., Peterson, J., Sparks, R., Handley, M., and E. 818 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 819 June 2002. 821 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 822 with Session Description Protocol (SDP)", RFC 3264, 823 June 2002. 825 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 826 Extensions to the Session Initiation Protocol (SIP) for 827 Asserted Identity within Trusted Networks", RFC 3325, 828 November 2002. 830 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 831 and D. Gurle, "Session Initiation Protocol (SIP) Extension 832 for Instant Messaging", RFC 3428, December 2002. 834 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 835 Jacobson, "RTP: A Transport Protocol for Real-Time 836 Applications", STD 64, RFC 3550, July 2003. 838 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 839 Video Conferences with Minimal Control", STD 65, RFC 3551, 840 July 2003. 842 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 843 Configuration Protocol Option for Coordinate-based 844 Location Configuration Information", RFC 3825, July 2004. 846 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 847 Initiation Protocol (SIP)", RFC 3856, August 2004. 849 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 850 Protocol (XMPP): Core", RFC 3920, October 2004. 852 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 853 M., and D. Singer, "RTP Payload Format for H.264 Video", 854 RFC 3984, February 2005. 856 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 857 Conversation", RFC 4103, June 2005. 859 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 860 Format", RFC 4119, December 2005. 862 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 863 Supporting Emergency Telecommunications Service (ETS) in 864 IP Telephony", RFC 4190, November 2005. 866 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 867 Authenticated Identity Management in the Session 868 Initiation Protocol (SIP)", RFC 4474, August 2006. 870 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 871 Device Requirements and Configuration", RFC 4504, 872 May 2006. 874 [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol 875 (DHCPv4 and DHCPv6) Option for Civic Addresses 876 Configuration Information", RFC 4676, October 2006. 878 Authors' Addresses 880 Brian Rosen 881 NeuStar 882 470 Conrad Dr. 883 Mars, PA 16046 884 US 886 Phone: +1 724 382 1051 887 Email: br@brianrosen.net 888 James M. Polk 889 Cisco Systems 890 3913 Treemont Circle 891 Colleyville, TX 76034 892 US 894 Phone: +1-817-271-3552 895 Email: jmpolk@cisco.com 897 Full Copyright Statement 899 Copyright (C) The IETF Trust (2007). 901 This document is subject to the rights, licenses and restrictions 902 contained in BCP 78, and except as set forth therein, the authors 903 retain all their rights. 905 This document and the information contained herein are provided on an 906 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 907 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 908 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 909 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 910 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 911 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 913 Intellectual Property 915 The IETF takes no position regarding the validity or scope of any 916 Intellectual Property Rights or other rights that might be claimed to 917 pertain to the implementation or use of the technology described in 918 this document or the extent to which any license under such rights 919 might or might not be available; nor does it represent that it has 920 made any independent effort to identify any such rights. Information 921 on the procedures with respect to rights in RFC documents can be 922 found in BCP 78 and BCP 79. 924 Copies of IPR disclosures made to the IETF Secretariat and any 925 assurances of licenses to be made available, or the result of an 926 attempt made to obtain a general license or permission for the use of 927 such proprietary rights by implementers or users of this 928 specification can be obtained from the IETF on-line IPR repository at 929 http://www.ietf.org/ipr. 931 The IETF invites any interested party to bring to its attention any 932 copyrights, patents or patent applications, or other proprietary 933 rights that may cover technology that may be required to implement 934 this standard. Please address the information to the IETF at 935 ietf-ipr@ietf.org. 937 Acknowledgment 939 Funding for the RFC Editor function is provided by the IETF 940 Administrative Support Activity (IASA).