idnits 2.17.1 draft-ietf-ecrit-phonebcp-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 28, 2011) is 4777 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3841' is defined on line 999, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-mmusic-media-loopback-15 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-12 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft NeuStar 4 Intended status: BCP J. Polk 5 Expires: September 29, 2011 Cisco Systems 6 March 28, 2011 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-17 12 Abstract 14 The IETF and other standards organization have efforts targeted at 15 standardizing various aspects of placing emergency calls on IP 16 networks. This memo describes best current practice on how devices, 17 networks and services should use such standards to make emergency 18 calls. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 29, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Overview of how emergency calls are placed . . . . . . . . . . 4 57 4. Which devices and services should support emergency calls . . 5 58 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 59 6. Location and its role in an emergency call . . . . . . . . . . 6 60 6.1. Types of location information . . . . . . . . . . . . . . 6 61 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 62 6.2.1. User-entered location information . . . . . . . . . . 7 63 6.2.2. Access network "wire database" location information . 7 64 6.2.3. End-system measured location information . . . . . . . 7 65 6.2.4. Network-measured location information . . . . . . . . 8 66 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 67 6.4. Location and references to location . . . . . . . . . . . 9 68 6.5. End system location configuration . . . . . . . . . . . . 9 69 6.6. When location should be configured . . . . . . . . . . . . 10 70 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11 71 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 72 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12 73 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 74 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13 75 6.12. Other location considerations . . . . . . . . . . . . . . 13 76 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 77 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 78 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 79 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.2. SIP signaling requirements for User Agents . . . . . . . . 15 81 9.3. SIP signaling requirements for proxy servers . . . . . . . 16 82 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 84 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 85 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 86 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21 91 17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21 92 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 93 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 95 19.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 This document uses terms from [RFC3261], [RFC5012] and 106 [I-D.ietf-ecrit-framework]. 108 2. Introduction 110 This document describes how access networks, Session Initiation 111 Protocol [RFC3261] user agents, proxy servers and Public Safety 112 Access Points (PSAPs) support emergency calling, as outlined in 113 [I-D.ietf-ecrit-framework], which is designed to complement the 114 present document in section headings, numbering and content. This 115 BCP succinctly describes the requirements of end devices and 116 applications (requirements prefaced by "ED-"), access networks 117 (including enterprise access networks) (requirements prefaced by 118 "AN-"), service providers (requirements prefaced by "SP-") and PSAPs 119 to achieve globally interoperable emergency calling on the Internet. 121 This document also defines requirements for "Intermediate" devices 122 which exist between end devices or applications and the access 123 network. For example, a home router is an "Intermediate" device. 124 Reporting location on an emergency call (see Section 6) may depend on 125 the ability of such intermediate devices to meet the requirements 126 prefaced by "INT-". 128 3. Overview of how emergency calls are placed 130 An emergency call can be distinguished (Section 5) from any other 131 call by a unique Service URN [RFC5031], which is placed in the call 132 set-up signaling when a home or visited emergency dial string is 133 detected. Because emergency services are local to specific 134 geographic regions, a caller must obtain his location (Section 6) 135 prior to making emergency calls. To get this location, either a form 136 of measuring (e.g., GPS) (Section 6.2.3) device location in the 137 endpoint is deployed, or the endpoint is configured (Section 6.5) 138 with its location from the access network's Location Information 139 Server (LIS). The location is conveyed (Section 6.7) in the SIP 140 signaling with the call. The call is routed (Section 8) based on 141 location using the Location-to-Service Translation (LoST) protocol 142 [RFC5222], which maps a location to a set of PSAP URIs. Each URI 143 resolves to a PSAP or an Emergency Services Routing Proxy (ESRP), 144 which serves a group of PSAPs. The call arrives at the PSAP with the 145 location included in the SIP INVITE request. 147 4. Which devices and services should support emergency calls 149 ED-1 A device or application SHOULD support emergency calling if a 150 user could reasonably expect to be able to place a call for help with 151 the device. Some jurisdictions have regulations governing this. 153 SP-1 If a device or application expects to be able to place a call 154 for help, the service provider that supports it MUST facilitate 155 emergency calling. Some jurisdictions have regulations governing 156 this. 158 ED-2 Devices that create media sessions and exchange real-time audio, 159 video and/or text, have the capability to establish sessions to a 160 wide variety of addresses, and communicate over private IP networks 161 or the Internet, SHOULD support emergency calls. Some jurisdictions 162 have regulations governing this. 164 5. Identifying an emergency call 166 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 167 the service provider always knows the location of the device, then 168 the service provider could recognize them. 170 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 171 some reason the endpoint does not recognize them. 173 ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the 174 Request-URI of the INVITE. 176 ED-5/SP-4 Geographically local dial strings MUST be recognized. 178 ED-6/SP-5 Devices MUST be able to be configured with the home country 179 from which the home dial string(s) can be determined. 181 ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST 182 [RFC5222]. Dial Strings MAY be configured directly into the device. 184 AN-1 LoST servers MUST return dial strings for emergency services. 186 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 187 send dial strings as per [RFC4967]. 189 SP-7 If a proxy server recognizes dial strings on behalf of its 190 clients, it MUST recognize emergency dial strings represented by 192 [RFC4967] and SHOULD recognize the emergency dial strings represented 193 by a tel URI [RFC3966]. 195 ED-9 Endpoints SHOULD be able to have home dial strings provisioned. 197 SP-8 Service providers MAY provision home dial strings in devices. 199 ED-10 Devices SHOULD NOT have one button emergency calling 200 initiation. 202 ED-11/SP-9 All sub-services for the 'sos' service specified in 203 [RFC5031]. MUST be recognized. 205 6. Location and its role in an emergency call 207 Handling location for emergency calling usually involves several 208 steps to process and multiple elements are involved. In Internet 209 emergency calling, where the endpoint is located is "determined" 210 using a variety of measurement or wiretracing methods. Endpoints can 211 be "configured" with their own location by the access network. In 212 some circumstances, a proxy server can insert location into the 213 signaling on behalf of the endpoint. The location is "mapped" to the 214 URI to send the call to, and the location is "conveyed" to the PSAP 215 (and other elements) in the signaling. Likewise, we employ Location 216 Configuration Protocols, the Location-to-Service Mapping Protocol, 217 and Location Conveyance Protocols for these functions. The Location- 218 to-Service Translation protocol [RFC5222] is the Location Mapping 219 Protocol defined by the IETF. 221 6.1. Types of location information 223 There are several forms of location. All IETF location configuration 224 and location conveyance protocols support both civic and geospatial 225 (geo) forms. The civic forms include both postal and jurisdictional 226 fields. A cell tower/sector can be represented as a point (geo or 227 civic) or polygon. Other forms of location representation MUST be 228 mapped into either a geo or civic for use in emergency calls. 230 ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service 231 Providers MUST be prepared to handle location represented in either 232 civic or geo form. 234 ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo 235 to civic) from the form of location the determination mechanism 236 supplied prior to receipt by the PSAP. 238 6.2. Location Determination 240 ED-14/INT-3/AN-3 Any location determination mechanism MAY be used, 241 provided the accuracy of the location meets local requirements. 243 6.2.1. User-entered location information 245 ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks 246 SHOULD support a manual method to override the location the access 247 network determines. When the override location is supplied in civic 248 form, it MUST be possible for the resultant Presence Information Data 249 Format - Location Object (PIDF-LO) received at the PSAP to contain 250 any of the elements specified in [RFC4119] and [RFC5139]. 252 6.2.2. Access network "wire database" location information 254 AN-5 Access networks supporting copper, fiber or other hard wired IP 255 packet service SHOULD support location configuration. If the network 256 does not support location configuration, it MUST require every device 257 that connects to the network to support end system measured location. 259 AN-6/INT-5 Access networks and intermediate devices providing wire 260 database location information SHOULD provide interior location data 261 (building, floor, room, cubicle) where possible. It is RECOMMENDED 262 that interior location be provided when spaces exceed approximately 263 650 square meters. See [I-D.ietf-ecrit-framework] Section 6.2.2 for 264 a discussion of how this value was determined. 266 AN-7/INT-6 Access networks and intermediate devices (including 267 enterprise networks) which support intermediate range wireless 268 connections (typically 100m or less of range) and which do not 269 support a more accurate location determination mechanism such as 270 triangulation, MUST support location configuration where the location 271 of the access point is reflected as the location of the clients of 272 that access point. 274 AN-8/INT-7 Where the access network provides location configuration, 275 intermediate devices MUST either be transparent to it, or provide an 276 interconnected client for the supported configuration mechanism and a 277 server for a configuration protocol supported by end devices 278 downstream of the intermediate device such that the location provided 279 by the access network is available to clients as if the intermediate 280 device was not in the path. 282 6.2.3. End-system measured location information 284 ED-16/INT-8 Devices MAY support end-system measured location. See 285 [I-D.ietf-ecrit-framework] Section 6 for a discussion of accuracy of 286 location. 288 ED-17/INT-9/AN-9 Devices that support endpoint measuring of location 289 MUST have at least a coarse location capability (typically <1km 290 accuracy) for routing of calls. The location mechanism MAY be a 291 service provided by the access network. 293 6.2.4. Network-measured location information 295 AN-10 Access networks MAY provide network-measured location 296 determination. Wireless access networks that do not supply network 297 measured location MUST require that all devices connected to the 298 network have end-system measured location. Uncertainty and 299 confidence may be specified by local regulation. Where not 300 specified, uncertainty of less than 100 meters with 95% confidence is 301 RECOMMENDED for dispatch location. 303 AN-11 Access networks that provide network measured location MUST 304 have at least a coarse location (typically <1km when not location 305 hiding) capability at all times for routing of calls. 307 AN-12 Access networks with range of <10 meters (e.g. personal area 308 networks such as Bluetooth MUST provide a location to mobile devices 309 connected to them. The location provided SHOULD be that reported by 310 the upstream access network unless a more accurate mechanism is 311 available. 313 6.3. Who adds location, endpoint or proxy 315 ED-18/INT-10 Endpoints SHOULD attempt to configure their own location 316 using the Location Configuration Protocols (LCPs) listed in ED-21. 318 SP-12 Proxies MAY provide location on behalf of devices if: 319 o The proxy has a relationship with all access networks the device 320 could connect to, and the relationship allows it to obtain 321 location. 322 o The proxy has an identifier, such as an IP address, that can be 323 used by the access network to determine the location of the 324 endpoint, even in the presence of NAT and VPN tunnels that may 325 obscure the identifier between the access network and the service 326 provider. 328 ED-19/INT-11/SP-13 Where proxies provide location on behalf of 329 endpoints, the service provider MUST ensure that either the end 330 device is provided with the local dial strings for its current 331 location (where the end device recognizes dial strings), or the 332 service provider proxy MUST detect the appropriate local dial strings 333 at the time of the call. 335 6.4. Location and references to location 337 ED-20/INT-12 Devices SHOULD be able to accept and forward location by 338 value or by reference. An end device that receives location by 339 reference (and does not also get the corresponding value) MUST be 340 able to perform a dereference operation to obtain a value. 342 6.5. End system location configuration 344 ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration 345 Protocol (DHCP) location options [RFC4776], [RFC3825] and HTTP 346 Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a 347 specific access network interface for which location configuration 348 mechanisms such as Link Layer Discovery Protocol - Media Endpoint 349 Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device 350 SHOULD support the additional respective access network specific 351 location configuration mechanism. 353 AN-13/INT-14 The access network MUST support either DHCP location 354 options or HELD. The access network SHOULD support other location 355 configuration technologies that are specific to the type of access 356 network. 358 AN-14/INT-15 Where a router is employed between a LAN and WAN in a 359 small (less than approximately 650 square meters) area, the router 360 MUST be transparent to the location provided by the WAN to the LAN. 361 This may mean the router must obtain location as a client from the 362 WAN, and supply an LCP server to the LAN with the location it 363 obtains. Where the area is larger, the LAN MUST have a location 364 configuration mechanism satisfying the requirements of this document. 366 ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in 367 any order or in parallel. The first one that succeeds in supplying 368 location MUST be used. 370 AN-15/INT-17 Access networks that support more than one LCP MUST 371 reply with the same location information (within the limits of the 372 data format for the specific LCP) for all LCPs it supports. 374 ED-23/INT-18/SP-14 When HELD is the LCP, the request MUST specify a 375 value of "emergencyRouting" for the "responseTime" parameter and use 376 the resulting location for routing. If a value for dispatch location 377 will be sent, another request with the "responseTime" parameter set 378 to "emergencyDispatch" must be completed, with the result sent for 379 dispatch purposes. 381 ED-24 Where the operating system supporting application programs 382 which need location for emergency calls does not allow access to 383 Layer 2 and Layer 3 functions necessary for a client application to 384 use DHCP location options and/or other location technologies that are 385 specific to the type of access network, the operating system MUST 386 provide a published API conforming to ED-12 through ED-23 and ED-25 387 through ED-32. It is RECOMMENDED that all operating systems provide 388 such an API. 390 6.6. When location should be configured 392 ED-25/INT-19 Endpoints SHOULD obtain location immediately after 393 obtaining local network configuration information. 395 ED-26/INT-20 If the device is configured to use DHCP for 396 bootstrapping, it MUST include both options for location acquisition 397 (civic and geodetic), the option for LIS discovery, and the option 398 for LoST discovery as defined in [RFC4776], [RFC3825], [RFC5986] and 399 [RFC5223]. 401 ED-27/INT-21 If the device sends a DHCPINFORM message, it MUST 402 include both options for location acquisition (civic and geodetic), 403 the option for LIS discovery, and the option for LoST discovery as 404 defined in [RFC4776], [RFC3825], [RFC5986] and [RFC5223]. 406 ED-28/INT-22 To minimize the effects of VPNs that do not allow 407 packets to be sent via the native hardware interface rather than via 408 the VPN tunnel, location configuration SHOULD be attempted before 409 such tunnels are established. 411 ED-29/INT-23 Software which uses LCPs SHOULD locate and use the 412 actual hardware network interface rather than a VPN tunnel interface 413 to direct LCP requests to the LIS in the actual access network. 415 AN-16 Network administrators MUST take care in assigning IP addresses 416 such that VPN address assignments can be distinguished from local 417 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 418 to provide location to addresses that arrive via VPN connections 419 unless it can accurately determine the location for such addresses. 421 AN-17 Placement of NAT devices where an LCP uses IP address for an 422 identifier SHOULD consider the effect of the NAT on the LCP. The 423 address used to query the LIS MUST be able to correctly identify the 424 record in the LIS representing the location of the querying device 426 ED-30/INT-24 For devices which are not expected to change location, 427 refreshing location on the order of once per day is RECOMMENDED. 429 ED-31/INT-25 For devices which roam, refresh of location information 430 SHOULD be more frequent, with the frequency related to the mobility 431 of the device and the ability of the access network to support the 432 refresh operation. If the device detects a link state change that 433 might indicate having moved, for example when it changes access 434 points, the device SHOULD refresh its location. 436 ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not 437 take longer than 250 ms to obtain routing location and systems SHOULD 438 be designed such that the typical response is under 100 ms. However, 439 as much as 3 seconds to obtain routing location MAY be tolerated if 440 location accuracy can be substantially improved over what can be 441 obtained in 250 ms. 443 6.7. Conveying location in SIP 445 ED-33/SP-15 Location sent between SIP elements MUST be conveyed using 446 [I-D.ietf-sipcore-location-conveyance]. 448 6.8. Location updates 450 ED-34/AN-19 Where the absolute location or the accuracy of location 451 of the endpoint may change between the time the call is received at 452 the PSAP and the time dispatch is completed, location update 453 mechanisms MUST be implemented and used. 455 ED-35/AN-20 Mobile devices MUST be provided with a mechanism to get 456 repeated location updates to track the motion of the device during 457 the complete processing of the call. 459 ED-36/AN-21 The LIS SHOULD provide a location reference which permits 460 a subscription with appropriate filtering. 462 ED-37/AN-22 For calls sent with location-by-reference, with a SIP or 463 SIPS scheme, the server resolving the reference MUST support a 464 SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other 465 location-by-reference schemes that do not support subscription, the 466 PSAP will have to repeatedly dereference the URI to determine if the 467 device moved. 469 ED-38 If location was sent by value, and the endpoint gets updated 470 location, it MUST send the updated location to the PSAP via a SIP re- 471 INVITE or UPDATE request. Such updates SHOULD be limited to no more 472 than one update every 10 seconds, a value selected to keep the load 473 on a large PSAP manageable, and yet provide sufficient indication to 474 the PSAP of motion. 476 6.9. Multiple locations 478 ED-39/SP-16 If the LIS has more than one location for an endpoint it 479 MUST conform to the rules in Section 3 of [RFC5491] 481 ED-40 If a UA has more than one location available to it, it MUST 482 choose one location to route the call towards the PSAP. If multiple 483 locations are in a single Presence Information Data Format (PIDF), 484 the procedures in [RFC5491] MUST be followed. If the UA has multiple 485 PIDFs, and has no reasonable basis to choose from among them, a 486 random choice is acceptable. 488 SP-17 If a proxy inserts location on behalf of an endpoint, and it 489 has multiple locations available for the endpoint it MUST choose one 490 location to use to route the call towards the PSAP. If multiple 491 locations are in a single PIDF, the procedures in [RFC5491] MUST be 492 followed. If the proxy has multiple PIDFs, and has no reasonable 493 basis to choose from among them, a random choice is acceptable. 495 SP-18 If a proxy is attempting to insert location but the UA conveyed 496 a location to it, the proxy MUST use the UA's location for routing in 497 the initial INVITE and MUST convey that location towards the PSAP. 498 It MAY also include what it believes the location to be in a separate 499 Geolocation header. 501 SP-19 All location objects received by a proxy MUST be delivered to 502 the PSAP. 504 ED-41/SP-20 Location objects MUST be created with information about 505 the method by which the location was determined, such as GPS, 506 manually entered, or based on access network topology included in a 507 PIDF- LO "method" element. In addition, the source of the location 508 information MUST be included in a PIDF-LO "provided-by" element. 510 ED-42/SP-21 A location with a method of "derived" MUST NOT be used 511 unless no other location is available. 513 6.10. Location validation 515 AN-23 A LIS SHOULD perform location validation of civic locations via 516 LoST before entering a location in its database. 518 ED-44 Endpoints SHOULD validate civic locations when they receive 519 them from their LCP. Validation SHOULD be performed in conjunction 520 with the LoST route query to minimize load on the LoST server. 522 6.11. Default location 524 AN-24 When the access network cannot determine the actual location of 525 the caller, it MUST supply a default location. The default SHOULD be 526 chosen to be as close to the probable location of the device as the 527 network can determine. See [I-D.ietf-ecrit-framework] 529 SP-22 Proxies handling emergency calls MUST insert a default location 530 in the INVITE if the incoming INVITE does not contain a location and 531 the proxy does not have a method for obtaining a better location. 533 AN-25/SP-23 Default locations MUST be marked with method=Default and 534 the proxy MUST be identified in provided-by element of the PIDF-LO. 536 6.12. Other location considerations 538 ED-45 If the LCP does not return location in the form of a PIDF-LO 539 [RFC4119], the endpoint MUST map the location information it receives 540 from the configuration protocol to a PIDF-LO. 542 ED-46/AN-26 To prevent against spoofing of the DHCP server, elements 543 implementing DHCP for location configuration SHOULD use [RFC3118], 544 although the difficulty in providing appropriate credentials is 545 significant. 547 ED-47 If S/MIME is used, the INVITE message MUST provide enough 548 information unencrypted for intermediate proxies to route the call 549 based on the location information included. This would include the 550 Geolocation header, and any bodies containing location information. 551 Use of S/MIME with emergency calls is NOT RECOMMENDED. 553 ED-48/SP-24 Either TLS or IPSEC [RFC3986] MUST be used to protect 554 location (but see Section 9.1). 556 7. LIS and LoST Discovery 558 ED-49 Endpoints MUST support one or more mechanisms that allow them 559 to determine their public IP address, for example, STUN [RFC5389]. 561 ED-50 Endpoints MUST support LIS discovery as described in [RFC5986], 562 and the LoST discovery as described in [RFC5223]. 564 ED-51 The device MUST have a configurable default LoST server 565 parameter. 567 ED-52 DHCP LoST discovery MUST be used, if available, in preference 568 to configured LoST servers. That is, the endpoint MUST send queries 569 to this LoST server first, using other LoST servers only if these 570 queries fail. 572 AN-27 Access networks which support DHCP MUST implement the LIS and 573 LoST discovery options in their DHCP servers and return suitable 574 server addresses as appropriate. 576 8. Routing the call to the PSAP 578 ED-53 Endpoints who obtain their own location SHOULD perform LoST 579 mapping to the PSAP URI. 581 ED-54 Mapping SHOULD be performed at boot time and whenever location 582 changes beyond the service boundary obtained from a prior LoST 583 mapping operation or the time-to-live value of that response has 584 expired. The value MUST be cached for possible later use. 586 ED-55 The endpoint MUST attempt to update its location at the time of 587 an emergency call. If it cannot obtain a new location quickly (see 588 Section 6), it MUST use the cached value. 590 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 591 time of an emergency call. If it cannot obtain a new mapping 592 quickly, it MUST use the cached value. If the device cannot update 593 the LoST mapping and does not have a cached value, it MUST signal an 594 emergency call without a Route header containing a PSAP URI. 596 SP-25 Networks MUST be designed so that at least one proxy in the 597 outbound path will recognize emergency calls with a Request URI of 598 the service URN in the "sos" tree. An endpoint places a service URN 599 in the Request URI to indicate that the endpoint understood the call 600 was an emergency call. A proxy that processes such a call looks for 601 the presence of a SIP Route header field with a URI of a PSAP. 602 Absence of such a Route header indicates the UAC was unable to invoke 603 LoST and the proxy MUST perform the LoST mapping and insert a Route 604 header field with the URI obtained. 606 SP-26 To deal with old user agents that predate this specification 607 and with UAs that do not have access to their own location data, a 608 proxy that recognizes a call as an emergency call that is not marked 609 as such (see Section 5) MUST also perform this mapping, with the best 610 location it has available for the endpoint. The resulting PSAP URI 611 would be placed in a Route header with the service URN in the Request 612 URI. 614 SP-27 Proxy servers performing mapping SHOULD use location obtained 615 from the access network for the mapping. If no location is 616 available, a default location (see Section 6.11) MUST be supplied. 618 SP-28 A proxy server which attempts mapping and fails to get a 619 mapping MUST provide a default mapping. A suitable default mapping 620 would be the mapping obtained previously for the default location 621 appropriate for the caller. 623 ED-57/SP-29 [RFC3261] and [RFC3263] procedures MUST be used to route 624 an emergency call towards the PSAP's URI. 626 9. Signaling of emergency calls 628 9.1. Use of TLS 630 ED-58/SP-30 Either TLS or IPsec MUST be used when attempting to 631 signal an emergency call. 633 ED-59/SP-31 If TLS session establishment is not available, or fails, 634 the call MUST be retried without TLS. 636 ED-60/SP-32 [RFC5626] is RECOMMENDED to maintain persistent TLS 637 connections between elements when one of the element is an endpoint. 638 Persistent TLS connection between proxies is RECOMMENDED using any 639 suitable mechanism. 641 ED-61/AN-28 TLS MUST be used when attempting to retrieve location 642 (configuration or dereferencing) with HELD. The use of [RFC5077] is 643 RECOMMENDED to minimize the time to establish TLS sessions without 644 keeping server-side state. 646 ED-62/AN-29 When TLS session establishment fails, the location 647 retrieval MUST be retried without TLS. 649 9.2. SIP signaling requirements for User Agents 651 ED-63 The initial SIP signaling method is an INVITE request: 652 1. The Request URI SHOULD be the service URN in the "sos" tree. If 653 the device does not interpret local dial strings, the Request- 654 URI MUST be a dial string URI [RFC4967] with the dialed digits. 655 2. The To header field SHOULD be a service URN in the "sos" tree. 656 If the device does not interpret local dial strings, the To: 657 MUST be a dial string URI with the dialed digits. 658 3. The From header field SHOULD contain the AoR of the caller. 659 4. A Route header field SHOULD be present with a PSAP URI obtained 660 from LoST (see Section 8). If the device does not interpret 661 dial plans, or was unable to obtain a route from a LoST server, 662 no such Route header field will be present. 664 5. A Contact header field MUST be globally routable, for example a 665 GRUU [RFC5627], and be valid for several minutes following the 666 termination of the call, provided that the UAC remains 667 registered with the same registrar, to permit an immediate call- 668 back to the specific device which placed the emergency call. It 669 is acceptable if the UAC inserts a locally routable URI and a 670 subsequent B2BUA maps that to a globally routable URI. 671 6. Other header fields MAY be included as per normal SIP behavior. 672 7. If a geolocation URI is included in the INVITE, a Supported 673 header field MUST be included with a 'geolocation-sip' or 674 'geolocation-http" option tag, as appropriate. 675 [I-D.ietf-sipcore-location-conveyance]. 676 8. If a device understands the SIP location conveyance 677 [I-D.ietf-sipcore-location-conveyance] extension and has its 678 location available, it MUST include location either by-value, 679 by-reference or both. 680 9. A SDP offer SHOULD be included in the INVITE. If voice is 681 supported the offer SHOULD include the G.711 codec, see 682 Section 14. As PSAPs may support a wide range of media types 683 and codecs, sending an offerless INVITE may result in a lengthy 684 return offer, but is permitted. Cautions in [RFC3261] on 685 offerless INVITEs should be considered before such use. 686 10. If the device includes location-by-value, the UA MUST support 687 multipart message bodies, since SDP will likely be also in the 688 INVITE. 690 9.3. SIP signaling requirements for proxy servers 692 SP-33 SIP Proxy servers processing emergency calls: 693 1. If the proxy interprets dial plans on behalf of user agents, the 694 proxy MUST look for the local emergency dial string at the 695 location of the end device and MAY look for the home dial string. 696 If it finds it, the proxy MUST: 697 * Insert a Geolocation header field. Location-by-reference MUST 698 be used because proxies must not insert bodies. 699 * Insert the Geolocation-Routing header with appropriate 700 parameters . 701 * Map the location to a PSAP URI using LoST. 702 * Add a Route header with the PSAP URI. 703 * Replace the Request-URI (which was the dial string) with the 704 service URN appropriate for the emergency dial string. 705 * Route the call using normal SIP routing mechanisms. 706 2. If the proxy recognizes the service URN in the Request URI, and 707 does not find a Route header, it MUST query a LoST server 708 immediately. If a location was provided (which should be the 709 case), the proxy uses that location to query LoST. The proxy may 710 have to dereference a location by reference to get a value. If a 711 location is not present, and the proxy can query a LIS which has 712 the location of the UA it MUST do so. If no location is present, 713 and the proxy does not have access to a LIS which could provide 714 location, the proxy MUST supply a default location (See 715 Section 6.11). The location (in the signaling, obtained from a 716 LIS, or default) MUST be used in a query to LoST with the service 717 URN received with the call. The resulting URI MUST be placed in 718 a Route header added to the call. 719 3. The proxy MAY add a Geolocation header field. Such an additional 720 location SHOULD NOT be used for routing; the location provided by 721 the UA should be used. 722 4. Either a P-Asserted-Identity [RFC3325] or an Identity header 723 field [RFC4474], or both, SHOULD be included to identify the 724 sender. For services which must support emergency calls from 725 unauthenticated devices, valid identity may not be available. 726 Proxies encountering a P-Asserted-Identity will need to pass the 727 header to the PSAP, which is in a different domain. [RFC3325] 728 requires a "spec(T)" to determine what happens if the "id" 729 privacy service, or a Privacy header is present and requests 730 privacy. In the absence of another spec(T), such proxies should 731 pass the header unmodified if and only if the connection between 732 the proxy and the PSAP is, as far as the proxy can determine, 733 protected by TLS with mutual authentication using keys reliably 734 known by the parties, encrypted with no less strength than AES 735 and the local regulations governing the PSAP do not otherwise 736 specify. 737 5. Proxies SHOULD NOT return a 424 error. It should process the 738 INVITE as best as it can. 739 6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a 740 missing value if the proxy must query LoST to obtain a route. 741 Emergency calls are always routed by location. 743 10. Call backs 745 ED-64/SP-34 Devices device SHOULD have a globally routable URI in a 746 Contact: header field which remains valid for several minutes past 747 the time the original call containing the URI completes unless the 748 device registration expires and is not renewed. 750 SP-35 Call backs to the Contact: header URI received within 30 751 minutes of an emergency call must reach the device regardless of call 752 features or services that would normally cause the call to be routed 753 to some other entity. 755 SP-36 Devices MUST have a persistent AOR URI either in a P-Asserted- 756 Identity header field or From protected by an Identity header field 757 suitable for returning a call some time after the original call. 758 Such a call back would not necessarily reach the device that 759 originally placed the call. 761 11. Mid-call behavior 763 ED-65/SP-37 During the course of an emergency call, devices and 764 proxies MUST initiate a call transfer upon receipt of REFER request 765 within the dialog with method=INVITE and the Referred-by header field 766 [RFC3515] in that request. 768 12. Call termination 770 ED-66 There can be a case where the session signaling path is lost, 771 the PSAP terminates the call but the user agent does not receive the 772 BYE. The PSAP would not receive the ACK and may initiate a call 773 back. If an incoming call is received from the domain of the PSAP, 774 the device MUST alert for the (new) incoming call. The domain of an 775 incoming call can only be determined from the From header, which is 776 not reliable, and could be spoofed. Dropping an active call by a new 777 call with a spoofed From header field would be a DoS attack. 779 13. Disabling of features 781 ED-67/SP-38 User Agents and proxies MUST disable features that will 782 interrupt an ongoing emergency call, such as: 783 o Call Waiting 784 o Call Transfer 785 o Three Way Call 786 o Hold 787 o Outbound Call Blocking 788 when an emergency call is established, but see ED-66 with respect to 789 Call Waiting. Also see ED-74 in Section 14. 791 ED-68/SP-39 The emergency dial strings SHOULD NOT be permitted in 792 Call Forward numbers or speed dial lists. 794 ED-69/SP-40 The User Agent and Proxies MUST disable call features 795 which would interfere with the ability of call backs from the PSAP to 796 be completed such as: 797 o Do Not Disturb 798 o Call Forward (all kinds) 799 These features SHOULD be disabled for approximately 30 minutes 800 following termination of an emergency call. 802 ED-70 Call backs SHOULD be determined by retaining the domain of the 803 PSAP which answers an outgoing emergency call and instantiating a 804 timer which starts when the call is terminated. If a call is 805 received from the same domain and within the timer period, sent to 806 the Contact: or AoR used in the emergency call, it should be assumed 807 to be a call back. The suggested timer period is 5 minutes. 808 [RFC4916] may be used by the PSAP to inform the UA of the domain of 809 the PSAP. Recognizing a call back from the domain of the PSAP will 810 not always work, and further standardization will be required to give 811 the UA the ability to recognize a call back. 813 14. Media 815 ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550]. 817 ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 818 agree on the media streams to be used. 820 ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in 821 North America) encoded voice as described in [RFC3551] MUST be 822 supported. If the endpoint cannot support G.711, a transcoder MUST 823 be used so that the offer received at the PSAP contains G.711. It is 824 desirable to include wideband codecs such as G.722 and AMR-WB in the 825 offer. PSAPs SHOULD support narrowband codecs common on endpoints in 826 their area to avoid transcoding. 828 ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT 829 be used on emergency calls. PSAP call takers sometimes get 830 information on what is happening in the background to determine how 831 to process the call. 833 ED-75 Endpoints supporting Instant Messaging (IM) MUST support either 834 [RFC3428] and [RFC4975]. 836 ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The 837 expectations for emergency service support for the real-time text 838 medium are described in [RFC5194], Section 7.1. 840 ED-77 Endpoints supporting video MUST support H.264 per 841 [I-D.ietf-avt-rtp-rfc3984bis]. 843 15. Testing 845 ED-78 INVITE requests to a service URN starting with "test." 846 indicates a request for an automated test. For example, 847 "urn:servicetest.sos.fire". As in standard SIP, a 200 (OK) response 848 indicates that the address was recognized and a 404 (Not found) that 849 it was not. A 486 (Busy Here) MUST be returned if the test service 850 is busy, and a 404 (Not found) MUST be returned if the PSAP does not 851 support the test mechanism. 853 ED-79 In its response to the test, the PSAP MAY include a text body 854 (text/plain) indicating the identity of the PSAP, the requested 855 service, and the location reported with the call. For the latter, 856 the PSAP SHOULD return location-by-value even if the original 857 location delivered with the test was by-reference. If the location- 858 by-reference was supplied, and the dereference requires credentials, 859 the PSAP SHOULD use credentials supplied by the LIS for test 860 purposes. This alerts the LIS that the dereference is not for an 861 actual emergency call and location hiding techniques, if they are 862 being used, may be employed for this dereference. Use of SIPS for 863 the request would assure the response containing the location is kept 864 private 866 ED-80 A PSAP accepting a test call SHOULD accept a media loopback 867 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 868 pkt-loopback" and "rtp-start-loopback" options. The user agent would 869 specify a loopback attribute of "loopback-source", the PSAP being the 870 mirror. User Agents should expect the PSAP to loop back no more than 871 3 packets of each media type accepted (which limits the duration of 872 the test), after which the PSAP would normally send BYE. 874 ED-81 User agents SHOULD perform a full call test, including media 875 loopback, after a disconnect and subsequent change in IP address not 876 due to a reboot. After an initial test, a full test SHOULD be 877 repeated approximately every 30 days with a random interval. 879 ED-82 User agents MUST NOT place a test call immediately after 880 booting. If the IP address changes after booting, the UA should wait 881 a random amount of time (in perhaps a 30 minute period, sufficient 882 for any avalanche restart to complete) and then test. 884 ED-83 PSAPs MAY refuse repeated requests for test from the same 885 device in a short period of time. Any refusal is signaled with a 486 886 or 488 response. 888 16. Security Considerations 890 Security considerations for emergency calling have been documented in 891 [RFC5069], and [I-D.ietf-geopriv-arch]. 893 17. IANA Considerations 895 This document registers service URNs in the Service URN Labels 896 registry per [RFC5031] for testing. 898 17.1. test service urn 900 A new entry in the URN Service Label registry is added. The new 901 service is "test", the reference is this document, and the 902 description is "self test". 904 17.2. 'test' Subregistry 906 A new Subregistry is created, the "'test' Sub-Service. The 907 registration process is Expert review by ECRIT working group, its 908 successor, or, in their absence, the IESG. The Reference is this 909 document. The initial content of the subregistry is: 911 Service Reference Description 912 -------------------------------------------------------------------- 913 test.sos [this document] test for sos 914 test.sos.ambulance [this document] test for sos.ambulance 915 test.sos.animal-control [this document] test for sos.animal-control 916 test.sos.fire [this document] test for sos.fire 917 test.sos.gas [this document] test for sos.gas 918 test.sos.marine [this document] test for sos.marine 919 test.sos.mountain [this document] test for sos.mountain 920 test.sos.physician [this document] test for sos.physician 921 test.sos.poison [this document] test for sos.poison 922 test.sos.police [this document] test for sos.police 924 18. Acknowledgements 926 Work group members participating in the creation and review of this 927 document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger 928 Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara 929 Stark, Richard Barnes and Peter Blatherwick. 931 19. References 933 19.1. Normative References 935 [I-D.ietf-avt-rtp-rfc3984bis] 936 Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 937 Payload Format for H.264 Video", 938 draft-ietf-avt-rtp-rfc3984bis-12 (work in progress), 939 October 2010. 941 [I-D.ietf-mmusic-media-loopback] 942 Sivachelvan, C., Venna, N., Jones, P., Stratton, N., 943 Roychowdhury, A., and K. Hedayat, "An Extension to the 944 Session Description Protocol (SDP) for Media Loopback", 945 draft-ietf-mmusic-media-loopback-15 (work in progress), 946 March 2011. 948 [I-D.ietf-sipcore-location-conveyance] 949 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 950 for the Session Initiation Protocol", 951 draft-ietf-sipcore-location-conveyance-06 (work in 952 progress), February 2011. 954 [LLDP-MED] 955 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 956 Endpoint Discovery". 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, March 1997. 961 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 962 Messages", RFC 3118, June 2001. 964 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 965 A., Peterson, J., Sparks, R., Handley, M., and E. 966 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 967 June 2002. 969 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 970 Protocol (SIP): Locating SIP Servers", RFC 3263, 971 June 2002. 973 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 974 with Session Description Protocol (SDP)", RFC 3264, 975 June 2002. 977 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 978 Event Notification", RFC 3265, June 2002. 980 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 981 and D. Gurle, "Session Initiation Protocol (SIP) Extension 982 for Instant Messaging", RFC 3428, December 2002. 984 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 985 Method", RFC 3515, April 2003. 987 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 988 Jacobson, "RTP: A Transport Protocol for Real-Time 989 Applications", STD 64, RFC 3550, July 2003. 991 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 992 Video Conferences with Minimal Control", STD 65, RFC 3551, 993 July 2003. 995 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 996 Configuration Protocol Option for Coordinate-based 997 Location Configuration Information", RFC 3825, July 2004. 999 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1000 Preferences for the Session Initiation Protocol (SIP)", 1001 RFC 3841, August 2004. 1003 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1004 Initiation Protocol (SIP)", RFC 3856, August 2004. 1006 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1007 RFC 3966, December 2004. 1009 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1010 Resource Identifier (URI): Generic Syntax", STD 66, 1011 RFC 3986, January 2005. 1013 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1014 Conversation", RFC 4103, June 2005. 1016 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1017 Format", RFC 4119, December 2005. 1019 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1020 Authenticated Identity Management in the Session 1021 Initiation Protocol (SIP)", RFC 4474, August 2006. 1023 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1024 (DHCPv4 and DHCPv6) Option for Civic Addresses 1025 Configuration Information", RFC 4776, November 2006. 1027 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1028 Protocol (SIP)", RFC 4916, June 2007. 1030 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1031 Initiation Protocol Uniform Resource Identifier", 1032 RFC 4967, July 2007. 1034 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1035 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1037 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1038 Emergency and Other Well-Known Services", RFC 5031, 1039 January 2008. 1041 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1042 Format for Presence Information Data Format Location 1043 Object (PIDF-LO)", RFC 5139, February 2008. 1045 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1046 Tschofenig, "LoST: A Location-to-Service Translation 1047 Protocol", RFC 5222, August 2008. 1049 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1050 Location-to-Service Translation (LoST) Servers Using the 1051 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1052 August 2008. 1054 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1055 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1056 October 2008. 1058 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1059 Presence Information Data Format Location Object (PIDF-LO) 1060 Usage Clarification, Considerations, and Recommendations", 1061 RFC 5491, March 2009. 1063 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 1064 Initiated Connections in the Session Initiation Protocol 1065 (SIP)", RFC 5626, October 2009. 1067 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1068 Agent URIs (GRUUs) in the Session Initiation Protocol 1069 (SIP)", RFC 5627, October 2009. 1071 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1072 RFC 5985, September 2010. 1074 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1075 Location Information Server (LIS)", RFC 5986, 1076 September 2010. 1078 19.2. Informative References 1080 [I-D.ietf-ecrit-framework] 1081 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1082 "Framework for Emergency Calling using Internet 1083 Multimedia", draft-ietf-ecrit-framework-12 (work in 1084 progress), October 2010. 1086 [I-D.ietf-geopriv-arch] 1087 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1088 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1089 Location and Location Privacy in Internet Applications", 1090 draft-ietf-geopriv-arch-03 (work in progress), 1091 October 2010. 1093 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1094 Extensions to the Session Initiation Protocol (SIP) for 1095 Asserted Identity within Trusted Networks", RFC 3325, 1096 November 2002. 1098 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1099 Emergency Context Resolution with Internet Technologies", 1100 RFC 5012, January 2008. 1102 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1103 Shanmugam, "Security Threats and Requirements for 1104 Emergency Call Marking and Mapping", RFC 5069, 1105 January 2008. 1107 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1108 "Transport Layer Security (TLS) Session Resumption without 1109 Server-Side State", RFC 5077, January 2008. 1111 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 1112 over IP Using the Session Initiation Protocol (SIP)", 1113 RFC 5194, June 2008. 1115 Authors' Addresses 1117 Brian Rosen 1118 NeuStar 1119 470 Conrad Dr. 1120 Mars, PA 16046 1121 USA 1123 Phone: +1 724 382 1051 1124 Email: br@brianrosen.net 1125 James Polk 1126 Cisco Systems 1127 3913 Treemont Circle 1128 Colleyville, TX 76034 1129 USA 1131 Phone: +1-817-271-3552 1132 Email: jmpolk@cisco.com