idnits 2.17.1 draft-ietf-ecrit-phonebcp-20.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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 7, 2011) is 4587 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) == Outdated reference: A later version (-27) exists of draft-ietf-mmusic-media-loopback-15 -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) == 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: 5 errors (**), 0 flaws (~~), 4 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: March 10, 2012 Cisco Systems 6 September 7, 2011 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-ietf-ecrit-phonebcp-20.txt 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 using IETF protocols should use such standards 18 to make emergency 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 March 10, 2012. 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 . . . . . . . . . . . . . . 7 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 . . . . . . . 8 65 6.2.4. Network-measured location information . . . . . . . . 8 66 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 11 71 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 12 72 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12 73 6.10. Location validation . . . . . . . . . . . . . . . . . . . 13 74 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13 75 6.12. Other location considerations . . . . . . . . . . . . . . 13 76 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . 16 81 9.3. SIP signaling requirements for proxy servers . . . . . . . 17 82 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 84 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 85 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 86 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21 91 17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21 92 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 93 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 19.1. Normative References . . . . . . . . . . . . . . . . . . . 22 95 19.2. Informative References . . . . . . . . . . . . . . . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 This document uses terms from [RFC3261], [RFC5012] and 107 [I-D.ietf-ecrit-framework]. 109 2. Introduction 111 This document describes how access networks, Session Initiation 112 Protocol [RFC3261] user agents, proxy servers and Public Safety 113 Access Points (PSAPs) support emergency calling, as outlined in 114 [I-D.ietf-ecrit-framework], which is designed to complement the 115 present document in section headings, numbering and content. 116 Understanding [I-D.ietf-ecrit-framework] is necessary to understand 117 this document. This BCP succinctly describes the requirements of end 118 devices and applications (requirements prefaced by "ED-"), access 119 networks (including enterprise access networks) (requirements 120 prefaced by "AN-"), service providers (requirements prefaced by 121 "SP-") and PSAPs to achieve globally interoperable emergency calling 122 on the Internet. 124 This document also defines requirements for "Intermediate" devices 125 which exist between end devices or applications and the access 126 network. For example, a home router is an "Intermediate" device. 127 Reporting location on an emergency call (see Section 6) may depend on 128 the ability of such intermediate devices to meet the requirements 129 prefaced by "INT-". 131 The access network requirements apply to those networks which may be 132 used to place emergency calls using IETF protocols. Local 133 regulations may impact the need to support this document's access 134 network requirements. 136 Other organizations, such as the North American Emergency Number 137 Association (NENA), define the PSAP interface. NENA's documents 138 reference this document. 140 3. Overview of how emergency calls are placed 142 An emergency call can be distinguished (Section 5) from any other 143 call by a unique Service URN [RFC5031], which is placed in the call 144 set-up signaling when a home or visited emergency dial string is 145 detected. Because emergency services are local to specific 146 geographic regions, a caller must obtain his location (Section 6) 147 prior to making emergency calls. To get this location, either a form 148 of measuring (e.g., GPS) (Section 6.2.3) device location in the 149 endpoint is deployed, or the endpoint is configured (Section 6.5) 150 with its location from the access network's Location Information 151 Server (LIS). The location is conveyed (Section 6.7) in the SIP 152 signaling with the call. The call is routed (Section 8) based on 153 location using the Location-to-Service Translation (LoST) protocol 154 [RFC5222], which maps a location to a set of PSAP URIs. Each URI 155 resolves to a PSAP or an Emergency Services Routing Proxy (ESRP), 156 which serves a group of PSAPs. The call arrives at the PSAP with the 157 location included in the SIP INVITE request. 159 4. Which devices and services should support emergency calls 161 ED-1 A device or application that implements SIP calling SHOULD 162 support emergency calling. Some jurisdictions have regulations 163 governing which devices need to support emergency calling and 164 developers are encouraged to ensure that devices they develop meet 165 relevant regulatory requirements. Unfortunately, the natural 166 variation in those regulations also makes it impossible to accurately 167 describe the cases when developers do or do not have to support 168 emergency calling. 170 SP-1 If a device or application expects to be able to place a call 171 for help, the service provider that supports it MUST facilitate 172 emergency calling. Some jurisdictions have regulations governing 173 this. 175 ED-2 Devices that create media sessions and exchange real-time audio, 176 video and/or text, have the capability to establish sessions to a 177 wide variety of addresses, and communicate over private IP networks 178 or the Internet, SHOULD support emergency calls. Some jurisdictions 179 have regulations governing this. 181 5. Identifying an emergency call 183 ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If 184 the service provider always knows the location of the device (the 185 correct dial string depends on which country you are in), the service 186 provider may recognize them, see SP-2. 188 SP-2 Proxy servers SHOULD recognize emergency dial strings if for 189 some reason the endpoint does not recognize them. 191 ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the 192 Request-URI of the INVITE. 194 ED-5/SP-4 Geographically local dial strings MUST be recognized. 196 ED-6/SP-5 Devices MUST be able to be configured with the home country 197 from which the home dial string(s) can be determined. 199 ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST 200 [RFC5222]. Dial Strings MAY be configured directly into the device. 202 AN-1 LoST servers MUST return dial strings for emergency services. 204 ED-8 Endpoints which do not recognize emergency dial strings SHOULD 205 send dial strings as per [RFC4967]. 207 SP-7 If a proxy server recognizes dial strings on behalf of its 208 clients, it MUST recognize emergency dial strings represented by 209 [RFC4967] and SHOULD recognize the emergency dial strings represented 210 by a tel URI [RFC3966]. 212 ED-9 Endpoints SHOULD be able to have home dial strings provisioned. 214 SP-8 Service providers MAY provision home dial strings in devices. 216 ED-10 Devices SHOULD NOT have one button emergency calling 217 initiation. 219 ED-11/SP-9 All sub-services for the 'sos' service specified in 220 [RFC5031]. MUST be recognized. 222 6. Location and its role in an emergency call 224 Handling location for emergency calling usually involves several 225 steps to process and multiple entities are involved. In Internet 226 emergency calling, where the endpoint is located is "determined" 227 using a variety of measurement or wiretracing methods. Endpoints can 228 be "configured" with their own location by the access network. In 229 some circumstances, a proxy server can insert location into the 230 signaling on behalf of the endpoint. The location is "mapped" to the 231 URI to send the call to, and the location is "conveyed" to the PSAP 232 (and other entities) in the signaling. Likewise, we employ Location 233 Configuration Protocols (LCPs), the Location-to-Service Mapping 234 Protocol, and Location Conveyance Protocols for these functions. The 235 Location-to-Service Translation protocol [RFC5222] is the Location 236 Mapping Protocol defined by the IETF. 238 6.1. Types of location information 240 There are several forms of location. All IETF location configuration 241 and location conveyance protocols support both civic and geospatial 242 (geo) forms. The civic forms include both postal and jurisdictional 243 fields. A cell tower/sector can be represented as a point (geo or 244 civic) or polygon. Endpoints, Intermediate Devices and Service 245 Providers receiving other forms of location representation MUST map 246 them into either a geo or civic for use in emergency calls. 248 ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service 249 Providers MUST be prepared to handle location represented in either 250 civic or geo form. 252 ED-13/INT-2/SP-11/AN-2 Entities MUST NOT convert (civic to geo or geo 253 to civic) from the form of location the determination mechanism (see 254 Section Section 6.2) supplied prior to receipt by the PSAP. 256 6.2. Location Determination 258 ED-14/INT-3/AN-3 Any location determination mechanism MAY be used, 259 provided the accuracy of the location meets local requirements. 261 6.2.1. User-entered location information 263 ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks 264 SHOULD support a manual method to override the location the access 265 network determines. When the override location is supplied in civic 266 form, it MUST be possible for the resultant Presence Information Data 267 Format - Location Object (PIDF-LO) received at the PSAP to contain 268 any of the elements specified in [RFC4119] and [RFC5139]. 270 6.2.2. Access network "wire database" location information 272 AN-5 Access networks supporting copper, fiber or other hard wired IP 273 packet service SHOULD support location configuration. If the network 274 does not support location configuration, it MUST require every device 275 or intermediate device that connects to the network to support end 276 system measured location. 278 AN-6/INT-5 Access networks and intermediate devices providing wire 279 database location information SHOULD provide interior location data 280 (building, floor, room, cubicle) where possible. It is RECOMMENDED 281 that interior location be provided when spaces exceed approximately 282 650 square meters. See [I-D.ietf-ecrit-framework] Section 6.2.2 for 283 a discussion of how this value was determined. 285 AN-7/INT-6 Access networks and intermediate devices (including 286 enterprise networks) which support intermediate range wireless 287 connections (typically 100m or less of range) and which do not 288 support a more accurate location determination mechanism such as 289 triangulation, MUST support location configuration where the location 290 of the access point is reflected as the location of the clients of 291 that access point. 293 AN-8/INT-7 Where the access network provides location configuration, 294 intermediate devices MUST either be transparent to it, or provide an 295 interconnected client for the supported configuration mechanism and a 296 server for a configuration protocol supported by end devices 297 downstream of the intermediate device such that the location provided 298 by the access network is available to clients as if the intermediate 299 device was not in the path. 301 6.2.3. End-system measured location information 303 ED-16/INT-8 Devices MAY support end-system measured location. See 304 [I-D.ietf-ecrit-framework] Section 6 for a discussion of accuracy of 305 location. 307 ED-17/INT-9/AN-9 Devices that support endpoint measuring of location 308 MUST have at least a coarse location capability (typically <1km 309 accuracy) for routing of calls. The location mechanism MAY be a 310 service provided by the access network. 312 6.2.4. Network-measured location information 314 AN-10 Access networks MAY provide network-measured location 315 determination. Wireless access networks that do not supply network 316 measured location MUST require every device or intermediate device 317 connected to the network to support end-system measured location. 318 Uncertainty and confidence may be specified by local regulation. 319 Where not specified, uncertainty of less than 100 meters with 95% 320 confidence is RECOMMENDED for dispatch location. 322 AN-11 Access networks that provide network measured location MUST 323 have at least a coarse location (typically <1km when not location 324 hiding) capability at all times for routing of calls. 326 AN-12 Access networks with range of <10 meters (e.g. personal area 327 networks such as Bluetooth MUST provide a location to mobile devices 328 connected to them. The location provided SHOULD be that reported by 329 the upstream access network unless a more accurate mechanism is 330 available. 332 6.3. Who adds location, endpoint or proxy 334 ED-18/INT-10 Endpoints SHOULD attempt to configure their own location 335 using the Location Configuration Protocols (LCPs) listed in ED-21. 337 SP-12 Proxies MAY provide location on behalf of devices if: 338 o The proxy has a relationship with all access networks the device 339 could connect to, and the relationship allows it to obtain 340 location. 341 o The proxy has an identifier, such as an IP address, that can be 342 used by the access network to determine the location of the 343 endpoint, even in the presence of NAT and VPN tunnels that may 344 obscure the identifier between the access network and the service 345 provider. 347 ED-19/INT-11/SP-13 Where proxies provide location on behalf of 348 endpoints, the service provider MUST ensure that either the end 349 device is provided with the local dial strings for its current 350 location (where the end device recognizes dial strings), or the 351 service provider proxy MUST detect the appropriate local dial strings 352 at the time of the call. 354 6.4. Location and references to location 356 ED-20/INT-12 Devices SHOULD be able to accept and forward location by 357 value or by reference. An end device that receives location by 358 reference (and does not also get the corresponding value) MUST be 359 able to perform a dereference operation to obtain a value. 361 6.5. End system location configuration 363 Obtaining location from the access network may be preferable even if 364 the device can measure its own location, especially indoors where 365 most measurement mechanisms are not accurate enough. This sections 366 requirements do not apply to devices that can accurately measure 367 their own location. 369 ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration 370 Protocol (DHCP) location options [RFC4776], [RFC6225] and HTTP 371 Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a 372 specific access network interface for which location configuration 373 mechanisms such as Link Layer Discovery Protocol - Media Endpoint 374 Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device 375 SHOULD support the additional respective access network specific 376 location configuration mechanism. 378 AN-13/INT-14 The access network MUST support either DHCP location 379 options or HELD. The access network SHOULD support other location 380 configuration technologies that are specific to the type of access 381 network. 383 AN-14/INT-15 Where a router is employed between a LAN and WAN in a 384 small (less than approximately 650 square meters) area, the router 385 MUST be transparent to the location provided by the WAN to the LAN. 386 This may mean the router must obtain location as a client from the 387 WAN, and supply an LCP server to the LAN with the location it 388 obtains. Where the area is larger, the LAN MUST have a location 389 configuration mechanism satisfying the requirements of this document. 391 ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in 392 any order or in parallel. The first one that succeeds in supplying 393 location MUST be used. 395 AN-15/INT-17 Access networks that support more than one LCP MUST 396 reply with the same location information (within the limits of the 397 data format for the specific LCP) for all LCPs it supports. 399 ED-23/INT-18/SP-14 When HELD is the LCP, the request MUST specify a 400 value of "emergencyRouting" for the "responseTime" parameter and use 401 the resulting location for routing. If a value for dispatch location 402 will be sent, another request with the "responseTime" parameter set 403 to "emergencyDispatch" must be completed, with the result sent for 404 dispatch purposes. 406 ED-24 Where the operating system supporting application programs 407 which need location for emergency calls does not allow access to 408 Layer 2 and Layer 3 functions necessary for a client application to 409 use DHCP location options and/or other location technologies that are 410 specific to the type of access network, the operating system MUST 411 provide a published API conforming to ED-12 through ED-23 and ED-25 412 through ED-32. It is RECOMMENDED that all operating systems provide 413 such an API. 415 6.6. When location should be configured 417 If an endpoint is manually configured, the requirements in this 418 section are not applicable. 420 ED-25/INT-19 Endpoints SHOULD obtain location immediately after 421 obtaining local network configuration information. 423 ED-26/INT-20 If the device is configured to use DHCP for 424 bootstrapping, and does not use it MUST include both options for 425 location acquisition (civic and geodetic), the option for LIS 426 discovery, and the option for LoST discovery as defined in [RFC4776], 427 [RFC6225], [RFC5986] and [RFC5223]. 429 ED-27/INT-21 If the device sends a DHCPINFORM message, it MUST 430 include both options for location acquisition (civic and geodetic), 431 the option for LIS discovery, and the option for LoST discovery as 432 defined in [RFC4776], [RFC6225], [RFC5986] and [RFC5223]. 434 ED-28/INT-22 To minimize the effects of VPNs that do not allow 435 packets to be sent via the native hardware interface rather than via 436 the VPN tunnel, location configuration SHOULD be attempted before 437 such tunnels are established. 439 ED-29/INT-23 Software which uses LCPs SHOULD locate and use the 440 actual hardware network interface rather than a VPN tunnel interface 441 to direct LCP requests to the LIS in the actual access network. 443 AN-16 Network administrators MUST take care in assigning IP addresses 444 such that VPN address assignments can be distinguished from local 445 devices (by subnet choice, for example), and LISs SHOULD NOT attempt 446 to provide location to addresses that arrive via VPN connections 447 unless it can accurately determine the location for such addresses. 449 AN-17 Placement of NAT devices where an LCP uses IP address for an 450 identifier SHOULD consider the effect of the NAT on the LCP. The 451 address used to query the LIS MUST be able to correctly identify the 452 record in the LIS representing the location of the querying device 454 ED-30/INT-24 For devices which are not expected to change location, 455 refreshing location on the order of once per day is RECOMMENDED. 457 ED-31/INT-25 For devices which roam, refresh of location information 458 SHOULD be more frequent, with the frequency related to the mobility 459 of the device and the ability of the access network to support the 460 refresh operation. If the device detects a link state change that 461 might indicate having moved, for example when it changes access 462 points, the device SHOULD refresh its location. 464 ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not 465 take longer than 250 ms to obtain routing location and systems SHOULD 466 be designed such that the typical response is under 100 ms. However, 467 as much as 3 seconds to obtain routing location MAY be tolerated if 468 location accuracy can be substantially improved over what can be 469 obtained in 250 ms. 471 6.7. Conveying location 473 ED-33/SP-15 Location sent between SIP entities MUST be conveyed using 474 [I-D.ietf-sipcore-location-conveyance]. 476 6.8. Location updates 478 ED-34/AN-19 Where the absolute location or the accuracy of location 479 of the endpoint may change between the time the call is received at 480 the PSAP and the time dispatch is completed, location update 481 mechanisms MUST be implemented and used. 483 ED-35/AN-20 Mobile devices MUST be provided with a mechanism to get 484 repeated location updates to track the motion of the device during 485 the complete processing of the call. 487 ED-36/AN-21 The LIS SHOULD provide a location reference which permits 488 a subscription with appropriate filtering. 490 ED-37/AN-22 For calls sent with location-by-reference, with a SIP or 491 SIPS scheme, the server resolving the reference MUST support a 492 SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other 493 location-by-reference schemes that do not support subscription, the 494 PSAP will have to repeatedly dereference the URI to determine if the 495 device moved. 497 ED-38 If location was sent by value, and the endpoint gets updated 498 location, it MUST send the updated location to the PSAP via a SIP re- 499 INVITE or UPDATE request. Such updates SHOULD be limited to no more 500 than one update every 10 seconds, a value selected to keep the load 501 on a large PSAP manageable, and yet provide sufficient indication to 502 the PSAP of motion. 504 6.9. Multiple locations 506 ED-39/SP-16 If the LIS has more than one location for an endpoint it 507 MUST conform to the rules in Section 3 of [RFC5491] 509 ED-40 If an endpoint has more than one location available to it, it 510 MUST choose one location to route the call towards the PSAP. If 511 multiple locations are in a single Presence Information Data Format 512 (PIDF), the procedures in [RFC5491] MUST be followed. If the 513 endpoint has multiple PIDFs, and has no reasonable basis to choose 514 from among them, a random choice is acceptable. 516 SP-17 If a proxy inserts location on behalf of an endpoint, and it 517 has multiple locations available for the endpoint it MUST choose one 518 location to use to route the call towards the PSAP. If multiple 519 locations are in a single PIDF, the procedures in [RFC5491] MUST be 520 followed. If the proxy has multiple PIDFs, and has no reasonable 521 basis to choose from among them, a random choice is acceptable. 523 SP-18 If a proxy is attempting to insert location but the endpoint 524 conveyed a location to it, the proxy MUST use the endpoint's location 525 for routing in the initial INVITE and MUST convey that location 526 towards the PSAP. It MAY also include what it believes the location 527 to be in a separate Geolocation header. 529 SP-19 All location objects received by a proxy MUST be delivered to 530 the PSAP. 532 ED-41/SP-20 Location objects MUST be created with information about 533 the method by which the location was determined, such as GPS, 534 manually entered, or based on access network topology included in a 535 PIDF- LO "method" element. In addition, the source of the location 536 information MUST be included in a PIDF-LO "provided-by" element. 538 ED-42/SP-21 A location with a method of "derived" MUST NOT be used 539 unless no other location is available. 541 6.10. Location validation 543 AN-23 A LIS SHOULD perform location validation of civic locations via 544 LoST before entering a location in its database. 546 ED-44 Endpoints SHOULD validate civic locations when they receive 547 them from their LCP. Validation SHOULD be performed in conjunction 548 with the LoST route query to minimize load on the LoST server. 550 6.11. Default location 552 AN-24 When the access network cannot determine the actual location of 553 the caller, it MUST supply a default location. The default SHOULD be 554 chosen to be as close to the probable location of the device as the 555 network can determine. See [I-D.ietf-ecrit-framework] 557 SP-22 Proxies handling emergency calls MUST insert a default location 558 in the INVITE if the incoming INVITE does not contain a location and 559 the proxy does not have a method for obtaining a better location. 561 AN-25/SP-23 Default locations MUST be marked with method=Default and 562 the proxy MUST be identified in provided-by element of the PIDF-LO. 564 6.12. Other location considerations 566 ED-45 If the LCP does not return location in the form of a PIDF-LO 567 [RFC4119], the endpoint MUST map the location information it receives 568 from the configuration protocol to a PIDF-LO. 570 ED-46/AN-26 To prevent against spoofing of the DHCP server, entities 571 implementing DHCP for location configuration SHOULD use [RFC3118], 572 although the difficulty in providing appropriate credentials is 573 significant. 575 ED-47 If S/MIME [RFC5751] is used, the INVITE message MUST provide 576 enough information unencrypted for intermediate proxies to route the 577 call based on the location information included. This would include 578 the Geolocation header, and any bodies containing location 579 information. Use of S/MIME with emergency calls is NOT RECOMMENDED 580 for this reason. 582 ED-48/SP-24 TLS [RFC5746] MUST be used to protect location (but see 583 Section 9.1). All implementations MUST support TLS. 585 7. LIS and LoST Discovery 587 ED-49 Endpoints MUST support one or more mechanisms that allow them 588 to determine their public IP address, for example, STUN [RFC5389]. 590 ED-50 Endpoints MUST support LIS discovery as described in [RFC5986], 591 and the LoST discovery as described in [RFC5223]. 593 ED-51 The device MUST have a configurable default LoST server 594 parameter. 596 ED-52 DHCP LoST discovery MUST be used, if available, in preference 597 to configured LoST servers. That is, the endpoint MUST send queries 598 to this LoST server first, using other LoST servers only if these 599 queries fail. 601 AN-27 Access networks which support DHCP MUST implement the LIS and 602 LoST discovery options in their DHCP servers and return suitable 603 server addresses as appropriate. 605 8. Routing the call to the PSAP 607 ED-53 Endpoints who obtain their own location SHOULD perform LoST 608 mapping to the PSAP URI. 610 ED-54 Mapping SHOULD be performed at boot time and whenever location 611 changes beyond the service boundary obtained from a prior LoST 612 mapping operation or the time-to-live value of that response has 613 expired. The value MUST be cached for possible later use. 615 ED-55 The endpoint MUST attempt to update its location at the time of 616 an emergency call. If it cannot obtain a new location quickly (see 617 Section 6), it MUST use the cached value. 619 ED-56 The endpoint SHOULD attempt to update the LoST mapping at the 620 time of an emergency call. If it cannot obtain a new mapping 621 quickly, it MUST use the cached value. If the device cannot update 622 the LoST mapping and does not have a cached value, it MUST signal an 623 emergency call without a Route header containing a PSAP URI. 625 SP-25 Networks MUST be designed so that at least one proxy in the 626 outbound path will recognize emergency calls with a Request URI of 627 the service URN in the "sos" tree. An endpoint places a service URN 628 in the Request URI to indicate that the endpoint understood the call 629 was an emergency call. A proxy that processes such a call looks for 630 the presence of a SIP Route header field with a URI of a PSAP. 631 Absence of such a Route header indicates the endpoint was unable to 632 invoke LoST and the proxy MUST perform the LoST mapping and insert a 633 Route header field with the URI obtained. 635 SP-26 To deal with old user agents that predate this specification 636 and with endpoints that do not have access to their own location 637 data, a proxy that recognizes a call as an emergency call that is not 638 marked as such (see Section 5) MUST also perform this mapping, with 639 the best location it has available for the endpoint. The resulting 640 PSAP URI would be placed in a Route header with the service URN in 641 the Request URI. 643 SP-27 Proxy servers performing mapping SHOULD use location obtained 644 from the access network for the mapping. If no location is 645 available, a default location (see Section 6.11) MUST be supplied. 647 SP-28 A proxy server which attempts mapping and fails to get a 648 mapping MUST provide a default mapping. A suitable default mapping 649 would be the mapping obtained previously for the default location 650 appropriate for the caller. 652 ED-57/SP-29 [RFC3261] and [RFC3263] procedures MUST be used to route 653 an emergency call towards the PSAP's URI. 655 9. Signaling of emergency calls 657 9.1. Use of TLS 659 ED-58/SP-30 TLS is the primary mechanism used to secure the signaling 660 for emergency calls. IPsec [RFC4301] MAY be used instead of TLS for 661 any hop. Either TLS or IPSEC MUST be used when attempting to signal 662 an emergency call. 664 ED-59/SP-31 If TLS session establishment is not available, or fails, 665 the call MUST be retried without TLS. 667 ED-60/SP-32 [RFC5626] is RECOMMENDED to maintain persistent TLS 668 connections between entities when one of the entity is an endpoint. 669 Persistent TLS connection between proxies is RECOMMENDED using any 670 suitable mechanism. 672 ED-61/AN-28 TLS SHOULD be used when attempting to retrieve location 673 (configuration or dereferencing) with HELD. The use of [RFC5077] is 674 RECOMMENDED to minimize the time to establish TLS sessions without 675 keeping server-side state. IPsec MAY be used instead of TLS. 677 ED-62/AN-29 When TLS session establishment fails, the location 678 retrieval MUST be retried without TLS. 680 9.2. SIP signaling requirements for User Agents 682 ED-63 The initial SIP signaling method is an INVITE request: 683 1. The Request URI SHOULD be the service URN in the "sos" tree. If 684 the device does not interpret local dial strings, the Request- 685 URI MUST be a dial string URI [RFC4967] with the dialed digits. 686 2. The To header field SHOULD be a service URN in the "sos" tree. 687 If the device does not interpret local dial strings, the To: 688 MUST be a dial string URI with the dialed digits. 689 3. The From header field SHOULD contain the AoR of the caller. 690 4. A Route header field SHOULD be present with a PSAP URI obtained 691 from LoST (see Section 8). If the device does not interpret 692 dial plans, or was unable to obtain a route from a LoST server, 693 no such Route header field will be present. 694 5. A Contact header field MUST be globally routable, for example a 695 GRUU [RFC5627], and be valid for several minutes following the 696 termination of the call, provided that the UAC remains 697 registered with the same registrar, to permit an immediate call- 698 back to the specific device which placed the emergency call. It 699 is acceptable if the UAC inserts a locally routable URI and a 700 subsequent B2BUA maps that to a globally routable URI. 701 6. Other header fields MAY be included as per normal SIP behavior. 702 7. If a geolocation URI is included in the INVITE, a Supported 703 header field MUST be included with a 'geolocation-sip' or 704 'geolocation-http" option tag, as appropriate. 705 [I-D.ietf-sipcore-location-conveyance]. 706 8. If a device understands the SIP location conveyance 707 [I-D.ietf-sipcore-location-conveyance] extension and has its 708 location available, it MUST include location either by-value, 709 by-reference or both. 710 9. A SDP offer SHOULD be included in the INVITE. If voice is 711 supported the offer SHOULD include the G.711 codec, see 712 Section 14. As PSAPs may support a wide range of media types 713 and codecs, sending an offerless INVITE may result in a lengthy 714 return offer, but is permitted. Cautions in [RFC3261] on 715 offerless INVITEs should be considered before such use. 716 10. If the device includes location-by-value, the UA MUST support 717 multipart message bodies, since SDP will likely be also in the 718 INVITE. 720 9.3. SIP signaling requirements for proxy servers 722 SP-33 SIP Proxy servers processing emergency calls: 723 1. If the proxy interprets dial plans on behalf of user agents, the 724 proxy MUST look for the local emergency dial string at the 725 location of the end device and MAY look for the home dial string. 726 If it finds it, the proxy MUST: 727 * Insert a Geolocation header field. Location-by-reference MUST 728 be used because proxies must not insert bodies. 729 * Insert the Geolocation-Routing header with appropriate 730 parameters . 731 * Map the location to a PSAP URI using LoST. 732 * Add a Route header with the PSAP URI. 733 * Replace the Request-URI (which was the dial string) with the 734 service URN appropriate for the emergency dial string. 735 * Route the call using normal SIP routing mechanisms. 736 2. If the proxy recognizes the service URN in the Request URI, and 737 does not find a Route header, it MUST query a LoST server 738 immediately. If a location was provided (which should be the 739 case), the proxy uses that location to query LoST. The proxy may 740 have to dereference a location by reference to get a value. If a 741 location is not present, and the proxy can query a LIS which has 742 the location of the UA it MUST do so. If no location is present, 743 and the proxy does not have access to a LIS which could provide 744 location, the proxy MUST supply a default location (See 745 Section 6.11). The location (in the signaling, obtained from a 746 LIS, or default) MUST be used in a query to LoST with the service 747 URN received with the call. The resulting URI MUST be placed in 748 a Route header added to the call. 749 3. The proxy MAY add a Geolocation header field. Such an additional 750 location SHOULD NOT be used for routing; the location provided by 751 the UA should be used. 752 4. Either a P-Asserted-Identity [RFC3325] or an Identity header 753 field [RFC4474], or both, SHOULD be included to identify the 754 sender. For services which must support emergency calls from 755 unauthenticated devices, valid identity may not be available. 756 Proxies encountering a P-Asserted-Identity will need to pass the 757 header to the PSAP, which is in a different domain. [RFC3325] 758 requires a "spec(T)" to determine what happens if the "id" 759 privacy service, or a Privacy header is present and requests 760 privacy. In the absence of another spec(T), such proxies should 761 pass the header unmodified if and only if the connection between 762 the proxy and the PSAP is, as far as the proxy can determine, 763 protected by TLS with mutual authentication using keys reliably 764 known by the parties, encrypted with no less strength than AES 765 and the local regulations governing the PSAP do not otherwise 766 specify. 767 5. Proxies SHOULD NOT return a 424 error. It should process the 768 INVITE as best as it can. 769 6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a 770 missing value if the proxy must query LoST to obtain a route. 771 Emergency calls are always routed by location. 773 10. Call backs 775 ED-64/SP-34 Devices device SHOULD have a globally routable URI in a 776 Contact: header field which remains valid for several minutes past 777 the time the original call containing the URI completes unless the 778 device registration expires and is not renewed. 780 SP-35 Call backs to the Contact: header URI received within 30 781 minutes of an emergency call must reach the device regardless of call 782 features or services that would normally cause the call to be routed 783 to some other entity. 785 SP-36 Devices MUST have a persistent AOR URI either in a P-Asserted- 786 Identity header field or From protected by an Identity header field 787 suitable for returning a call some time after the original call. 788 Such a call back would not necessarily reach the device that 789 originally placed the call. 791 11. Mid-call behavior 793 ED-65/SP-37 During the course of an emergency call, devices and 794 proxies MUST initiate a call transfer upon receipt of REFER request 795 within the dialog with method=INVITE and the Referred-by header field 796 [RFC3515] in that request. 798 12. Call termination 800 ED-66 Normal [RFC3261] procedures for termination MUST be used for 801 termination of the call. 803 13. Disabling of features 805 ED-67/SP-38 User Agents and proxies MUST disable features that will 806 interrupt an ongoing emergency call, such as: 808 o Call Waiting 809 o Call Transfer 810 o Three Way Call 811 o Hold 812 o Outbound Call Blocking 813 when an emergency call is established, but see ED-66 with respect to 814 Call Waiting. Also see ED-74 in Section 14. 816 ED-68/SP-39 The emergency dial strings SHOULD NOT be permitted in 817 Call Forward numbers or speed dial lists. 819 ED-69/SP-40 The User Agent and Proxies MUST disable call features 820 which would interfere with the ability of call backs from the PSAP to 821 be completed such as: 822 o Do Not Disturb 823 o Call Forward (all kinds) 824 These features SHOULD be disabled for approximately 30 minutes 825 following termination of an emergency call. 827 ED-70 Call backs SHOULD be determined by retaining the domain of the 828 PSAP which answers an outgoing emergency call and instantiating a 829 timer which starts when the call is terminated. If a call is 830 received from the same domain and within the timer period, sent to 831 the Contact: or AoR used in the emergency call, it should be assumed 832 to be a call back. The suggested timer period is 5 minutes. 833 [RFC4916] may be used by the PSAP to inform the endpoint of the 834 domain of the PSAP. Recognizing a call back from the domain of the 835 PSAP will not always work, and further standardization will be 836 required to give the endpoint the ability to recognize a call back. 838 14. Media 840 ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550]. 842 ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to 843 agree on the media streams to be used. 845 ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in 846 North America) encoded voice as described in [RFC3551] MUST be 847 supported. If the endpoint cannot support G.711, a transcoder MUST 848 be used so that the offer received at the PSAP contains G.711. It is 849 desirable to include wideband codecs such as G.722 and AMR-WB in the 850 offer. PSAPs SHOULD support narrowband codecs common on endpoints in 851 their area to avoid transcoding. 853 ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT 854 be used on emergency calls. PSAP call takers sometimes get 855 information on what is happening in the background to determine how 856 to process the call. 858 ED-75 Endpoints supporting Instant Messaging (IM) MUST support either 859 [RFC3428] and [RFC4975]. 861 ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The 862 expectations for emergency service support for the real-time text 863 medium are described in [RFC5194], Section 7.1. 865 ED-77 Endpoints supporting video MUST support H.264 per [RFC6184]. 867 15. Testing 869 ED-78 INVITE requests to a service URN starting with "test." 870 indicates a request for an automated test. For example, 871 "urn:service:test.sos.fire". As in standard SIP, a 200 (OK) response 872 indicates that the address was recognized and a 404 (Not found) that 873 it was not. A 486 (Busy Here) MUST be returned if the test service 874 is busy, and a 404 (Not found) MUST be returned if the PSAP does not 875 support the test mechanism. 877 ED-79 In its response to the test, the PSAP MAY include a text body 878 (text/plain) indicating the identity of the PSAP, the requested 879 service, and the location reported with the call. For the latter, 880 the PSAP SHOULD return location-by-value even if the original 881 location delivered with the test was by-reference. If the location- 882 by-reference was supplied, and the dereference requires credentials, 883 the PSAP SHOULD use credentials supplied by the LIS for test 884 purposes. This alerts the LIS that the dereference is not for an 885 actual emergency call and location hiding techniques, if they are 886 being used, may be employed for this dereference. Use of SIPS for 887 the request would assure the response containing the location is kept 888 private 890 ED-80 A PSAP accepting a test call SHOULD accept a media loopback 891 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 892 pkt-loopback" and "rtp-start-loopback" options. The user agent would 893 specify a loopback attribute of "loopback-source", the PSAP being the 894 mirror. User Agents should expect the PSAP to loop back no more than 895 3 packets of each media type accepted (which limits the duration of 896 the test), after which the PSAP would normally send BYE. 898 ED-81 User agents SHOULD perform a full call test, including media 899 loopback, after a disconnect and subsequent change in IP address not 900 due to a reboot. After an initial test, a full test SHOULD be 901 repeated approximately every 30 days with a random interval. 903 ED-82 User agents MUST NOT place a test call immediately after 904 booting. If the IP address changes after booting, the endpoint 905 should wait a random amount of time (in perhaps a 30 minute period, 906 sufficient for any avalanche restart to complete) and then test. 908 ED-83 PSAPs MAY refuse repeated requests for test from the same 909 device in a short period of time. Any refusal is signaled with a 486 910 or 488 response. 912 16. Security Considerations 914 Security considerations for emergency calling have been documented in 915 [RFC5069], and [RFC6280]. This document suggests that security (TLS 916 or IPsec) be used hop by hop on a SIP call to protect location 917 information, identity, etc. It also suggests that if the attempt to 918 create a security association fails, the call be retried without the 919 security. It's more important to get an emergency call through than 920 to protect the data; indeed, in many jurisdictions privacy is 921 explicitly waived when making emergency calls. Placing a call 922 without security may reveal user information, including location. 923 The alternative - failing the call if security cannot be established, 924 is considered unacceptable. 926 17. IANA Considerations 928 This document registers service URNs in the Service URN Labels 929 registry per [RFC5031] for testing. 931 17.1. test service urn 933 A new entry in the URN Service Label registry is added. The new 934 service is "test", the reference is this document, and the 935 description is "self test". 937 17.2. 'test' Subregistry 939 A new Subregistry is created, the "'test' Sub-Service. The 940 registration process is Expert Review per [RFC5226]. The expert 941 review should consider that the entries in this registry nominally 942 track the entries in the sos sub registry, although it is not 943 required that every entry in sos have an entry in test, and it is 944 possible that entries in the test sub-registry not necessarily be in 945 the sos sub registry. For example, testing of non-emergency URNs may 946 be allowed. The Reference is this document. The initial content of 947 the subregistry is: 949 Service Reference Description 950 -------------------------------------------------------------------- 951 test.sos [this document] test for sos 952 test.sos.ambulance [this document] test for sos.ambulance 953 test.sos.animal-control [this document] test for sos.animal-control 954 test.sos.fire [this document] test for sos.fire 955 test.sos.gas [this document] test for sos.gas 956 test.sos.marine [this document] test for sos.marine 957 test.sos.mountain [this document] test for sos.mountain 958 test.sos.physician [this document] test for sos.physician 959 test.sos.poison [this document] test for sos.poison 960 test.sos.police [this document] test for sos.police 962 18. Acknowledgements 964 Work group members participating in the creation and review of this 965 document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger 966 Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara 967 Stark, Richard Barnes and Peter Blatherwick. 969 19. References 971 19.1. Normative References 973 [I-D.ietf-mmusic-media-loopback] 974 Sivachelvan, C., Venna, N., Jones, P., Stratton, N., 975 Roychowdhury, A., and K. Hedayat, "An Extension to the 976 Session Description Protocol (SDP) for Media Loopback", 977 draft-ietf-mmusic-media-loopback-15 (work in progress), 978 March 2011. 980 [I-D.ietf-sipcore-location-conveyance] 981 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 982 for the Session Initiation Protocol", 983 draft-ietf-sipcore-location-conveyance-09 (work in 984 progress), September 2011. 986 [LLDP-MED] 987 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 988 Endpoint Discovery". 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 994 Messages", RFC 3118, June 2001. 996 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 997 A., Peterson, J., Sparks, R., Handley, M., and E. 998 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 999 June 2002. 1001 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1002 Protocol (SIP): Locating SIP Servers", RFC 3263, 1003 June 2002. 1005 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1006 with Session Description Protocol (SDP)", RFC 3264, 1007 June 2002. 1009 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1010 Event Notification", RFC 3265, June 2002. 1012 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1013 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1014 for Instant Messaging", RFC 3428, December 2002. 1016 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1017 Method", RFC 3515, April 2003. 1019 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1020 Jacobson, "RTP: A Transport Protocol for Real-Time 1021 Applications", STD 64, RFC 3550, July 2003. 1023 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1024 Video Conferences with Minimal Control", STD 65, RFC 3551, 1025 July 2003. 1027 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1028 Initiation Protocol (SIP)", RFC 3856, August 2004. 1030 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1031 RFC 3966, December 2004. 1033 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1034 Conversation", RFC 4103, June 2005. 1036 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1037 Format", RFC 4119, December 2005. 1039 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1040 Internet Protocol", RFC 4301, December 2005. 1042 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1043 Authenticated Identity Management in the Session 1044 Initiation Protocol (SIP)", RFC 4474, August 2006. 1046 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1047 (DHCPv4 and DHCPv6) Option for Civic Addresses 1048 Configuration Information", RFC 4776, November 2006. 1050 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1051 Protocol (SIP)", RFC 4916, June 2007. 1053 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1054 Initiation Protocol Uniform Resource Identifier", 1055 RFC 4967, July 2007. 1057 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1058 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1060 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1061 Emergency and Other Well-Known Services", RFC 5031, 1062 January 2008. 1064 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1065 Format for Presence Information Data Format Location 1066 Object (PIDF-LO)", RFC 5139, February 2008. 1068 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1069 Tschofenig, "LoST: A Location-to-Service Translation 1070 Protocol", RFC 5222, August 2008. 1072 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1073 Location-to-Service Translation (LoST) Servers Using the 1074 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1075 August 2008. 1077 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1078 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1079 May 2008. 1081 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1082 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1083 October 2008. 1085 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1086 Presence Information Data Format Location Object (PIDF-LO) 1087 Usage Clarification, Considerations, and Recommendations", 1088 RFC 5491, March 2009. 1090 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 1091 Initiated Connections in the Session Initiation Protocol 1092 (SIP)", RFC 5626, October 2009. 1094 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1095 Agent URIs (GRUUs) in the Session Initiation Protocol 1096 (SIP)", RFC 5627, October 2009. 1098 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1099 "Transport Layer Security (TLS) Renegotiation Indication 1100 Extension", RFC 5746, February 2010. 1102 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1103 Mail Extensions (S/MIME) Version 3.2 Message 1104 Specification", RFC 5751, January 2010. 1106 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1107 RFC 5985, September 2010. 1109 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1110 Location Information Server (LIS)", RFC 5986, 1111 September 2010. 1113 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1114 Payload Format for H.264 Video", RFC 6184, May 2011. 1116 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 1117 Host Configuration Protocol Options for Coordinate-Based 1118 Location Configuration Information", RFC 6225, July 2011. 1120 19.2. Informative References 1122 [I-D.ietf-ecrit-framework] 1123 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1124 "Framework for Emergency Calling using Internet 1125 Multimedia", draft-ietf-ecrit-framework-12 (work in 1126 progress), October 2010. 1128 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1129 Extensions to the Session Initiation Protocol (SIP) for 1130 Asserted Identity within Trusted Networks", RFC 3325, 1131 November 2002. 1133 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1134 Emergency Context Resolution with Internet Technologies", 1135 RFC 5012, January 2008. 1137 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1138 Shanmugam, "Security Threats and Requirements for 1139 Emergency Call Marking and Mapping", RFC 5069, 1140 January 2008. 1142 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1143 "Transport Layer Security (TLS) Session Resumption without 1144 Server-Side State", RFC 5077, January 2008. 1146 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 1147 over IP Using the Session Initiation Protocol (SIP)", 1148 RFC 5194, June 2008. 1150 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1151 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1152 Location and Location Privacy in Internet Applications", 1153 BCP 160, RFC 6280, July 2011. 1155 Authors' Addresses 1157 Brian Rosen 1158 NeuStar 1159 470 Conrad Dr. 1160 Mars, PA 16046 1161 USA 1163 Phone: +1 724 382 1051 1164 Email: br@brianrosen.net 1166 James Polk 1167 Cisco Systems 1168 3913 Treemont Circle 1169 Colleyville, TX 76034 1170 USA 1172 Phone: +1-817-271-3552 1173 Email: jmpolk@cisco.com