idnits 2.17.1 draft-rosen-ecrit-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1398. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 18, 2006) is 6514 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 289 -- Looks like a reference, but probably isn't: '6' on line 291 -- Looks like a reference, but probably isn't: '7' on line 291 -- Looks like a reference, but probably isn't: '4' on line 293 -- Looks like a reference, but probably isn't: '5' on line 293 -- Looks like a reference, but probably isn't: '8' on line 293 -- Looks like a reference, but probably isn't: '9' on line 293 == Missing Reference: 'M7' is mentioned on line 389, but not defined == Missing Reference: 'M8' is mentioned on line 392, but not defined == Missing Reference: 'M9' is mentioned on line 394, but not defined == Missing Reference: 'M10' is mentioned on line 397, but not defined == Missing Reference: 'M11' is mentioned on line 399, but not defined == Missing Reference: 'M1' is mentioned on line 374, but not defined == Missing Reference: 'M2' is mentioned on line 376, but not defined == Missing Reference: 'M3' is mentioned on line 378, but not defined == Missing Reference: 'M4' is mentioned on line 380, but not defined == Missing Reference: 'M5' is mentioned on line 382, but not defined == Missing Reference: 'M6' is mentioned on line 384, but not defined == Missing Reference: 'M12' is mentioned on line 401, but not defined == Unused Reference: 'I-D.ietf-avt-rfc2793bis' is defined on line 1181, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-media-loopback' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-config-framework' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-service-examples' is defined on line 1329, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.hardie-ecrit-lost' == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-10 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-requirements (ref. 'I-D.ietf-ecrit-requirements') == Outdated reference: A later version (-07) exists of draft-ietf-ecrit-service-urn-03 == Outdated reference: A later version (-27) exists of draft-ietf-mmusic-media-loopback-02 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-08 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-08 == Outdated reference: A later version (-05) exists of draft-rosen-iptel-dialstring-03 == Outdated reference: A later version (-01) exists of draft-rosen-sos-phonebcp-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.rosen-sos-phonebcp' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-10 Summary: 10 errors (**), 0 flaws (~~), 28 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Rosen 3 Internet-Draft NeuStar 4 Expires: December 20, 2006 H. Schulzrinne 5 Columbia U. 6 J. Polk 7 Cisco Systems 8 A. Newton 9 SunRocket 10 June 18, 2006 12 Framework for Emergency Calling in Internet Multimedia 13 draft-rosen-ecrit-framework-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 20, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Summoning emergency help by the public is a core feature of telephone 47 networks. This document describes a framework of how various IETF 48 protocols are combined to place emergency calls. This includes how 49 these calls are routed to the correct Public Safety Answering Point 50 (PSAP) based on the physical location of the caller, while providing 51 the call taker the necessary information to dispatch a first 52 responder to that location. This document explains how location 53 mapping, call identification and end system behavior are combined to 54 allow multimedia emergency calls. It describes at a high level how 55 the pieces (recognizing a call as an emergency call, marking it as 56 such, determining the location of the caller, routing the call based 57 on location) go together, and references the Internet standards that 58 define the details of these mechanisms. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Overview of How Emergency Calls are Placed . . . . . . . . . . 7 65 4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 11 66 5. Location and Its Role in an Emergency Call . . . . . . . . . . 11 67 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.2. Types of Location Information . . . . . . . . . . . . . . 12 69 5.3. Location Determination . . . . . . . . . . . . . . . . . . 13 70 5.3.1. User-Entered Location Information . . . . . . . . . . 13 71 5.3.2. Access Network "Wire Database" Location Information . 14 72 5.3.3. End-System Measured Location Information . . . . . . . 15 73 5.3.4. Third-party Measured Location Information . . . . . . 15 74 5.4. Location and References to Location . . . . . . . . . . . 15 75 5.5. End System Acquisition of Location . . . . . . . . . . . . 16 76 5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 17 77 5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 17 78 5.8. Location Validation . . . . . . . . . . . . . . . . . . . 18 79 5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 19 80 6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 19 81 7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 21 82 8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 21 83 9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 21 84 10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 22 85 11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 22 86 12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 13.1. Testing Mechanism . . . . . . . . . . . . . . . . . . . . 23 89 13.2. Manual Testing . . . . . . . . . . . . . . . . . . . . . . 24 90 13.3. Automatic 'sos service urn' Resolution Testing . . . . . . 24 91 14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 24 92 15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 24 93 15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 16. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 25 96 16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 25 97 16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 26 98 16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 26 99 16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 26 100 16.6. Media Integrity and Confidentiality . . . . . . . . . . . 26 101 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 102 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 18.1. Normative References . . . . . . . . . . . . . . . . . . . 27 104 18.2. Informative References . . . . . . . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 106 Intellectual Property and Copyright Statements . . . . . . . . . . 32 108 1. Terminology 110 As a framework document, we do not define any new protocols or 111 proscribe behavior. Thus we do not use RFC2119 [RFC2119] notation. 112 In this document, we reuse terms, and their definition, from 113 [I-D.ietf-ecrit-requirements]. In addition, the following terms are 114 used: 115 (Emergency) call taker: see [I-D.ietf-ecrit-requirements] 116 ESRP (emergency service routing proxy): see [I-D.ietf-ecrit- 117 requirements] 118 Access Network: The wide area network that supplies IP packet service 119 to an endpoint. In a residential or small business environment, 120 this might be a DSL or cable modem or WiMax service. In a large 121 enterprise environment, this would be the enterprise network. In 122 a mobile environment, this might be a mobile (cellular) data 123 network or a WiFi network. 124 Location Acquisition: The process by which an endpoint learns its 125 physical location. 126 Location Conveyance: The process of sending location to another 127 element. 128 Location Determination: The mechanism used to resolve where an 129 endpoint is physically. For example, the endpoint may have a GPS 130 receiver. 131 Location Validation: see [I-D.ietf-ecrit-requirements] 132 Mapping: see [I-D.ietf-ecrit-requirements] 133 NENA (National Emergency Number Association: A North American 134 organization of public safety focused individuals defining 135 emergency calling specifications and procedures. 136 PSAP (public safety answering point): see [I-D.ietf-ecrit- 137 requirements] 138 SIP B2BUA see [RFC3261] 139 SIP proxy: see [RFC3261]. 140 SIP Server see [RFC3261] 141 SIP UA (user agent): see [RFC3261]. 142 Stationary device (user): An immobile user agent that is connected to 143 the network at a fixed, long-term-stable geographic location. 144 Examples include a home PC or a payphone. 145 Nomadic device (user): User agent that is connected to the network 146 temporarily, for relatively short durations, but does not move 147 significantly during the lifetime of a network connection or 148 during the emergency call. Examples include a laptop using an 149 802.11 hotspot or a desk IP phone that is moved from one cubicle 150 to another. 151 Mobile device (user): User agent that changes geographic location and 152 possibly its network attachment point during an emergency call. 154 2. Introduction 156 Summoning police, the fire department or an ambulance in emergencies 157 is one of the fundamental and most-valued functions of the telephone. 158 As telephone functionality moves from circuit-switched telephony to 159 Internet telephony, its users rightfully expect that this core 160 functionality will continue to work at least as well as is has for 161 the older technology. New devices and services are being made 162 available which could be used to make a request for help which are 163 not traditional telephones, and users are increasingly expecting them 164 to be used to place emergency calls. However, many of the technical 165 advantages of Internet multimedia require re-thinking of the 166 traditional emergency calling architecture. This challenge also 167 offers an opportunity to improve the operation of emergency calling 168 technology, while potentially lowering its cost and complexity. 170 It is beyond the scope of this document to enumerate and discuss all 171 the differences between traditional (PSTN) and Internet telephony, 172 but the core differences can be summarized as: 173 o the separation/interleaving of signaling and media data packets; 174 o the emergence of application-independent carriers; 175 o the plethora of different media that can be accommodated; 176 o potential mobility of all end systems, including endpoints 177 nominally thought of as fixed systems and not just those using 178 radio access technology. For example, a wired phone connected to 179 a router using a mobile data network such as EV-DO as an uplink; 181 This document focuses on how devices using the Internet can place 182 emergency calls and how PSAPs can natively handle Internet multimedia 183 emergency calls, rather than describing how circuit-switched PSAPs 184 can handle VoIP calls. In many cases, PSAPs making the transition 185 from circuit-switched interfaces to packet-switched interfaces may be 186 able to use some of the mechanisms described here, in combination 187 with gateways that translate packet-switched calls into legacy 188 interfaces, e.g., to continue to be able to use existing call taker 189 equipment. 191 We distinguish an individual request for help, usually accomplished 192 by dialing a short digit sequence like 9-1-1 or 1-1-2 from a call 193 placed by specially designated persons who have authority to claim 194 priority on available Internet communications facilities. This 195 document only discusses the former - a request for help by an 196 ordinary user answered at an emergency call center. 198 Existing emergency call systems are organized locally/nationally; 199 there are currently no international standards. However, the 200 Internet does not respect national boundaries, and thus international 201 standards for equipment and software required. To further complicate 202 matters, VoIP endpoints can be connected through tunneling mechanisms 203 such as virtual private networks (VPNs). This significantly 204 complicates emergency calling, because the location of the caller and 205 the first element that routes emergency calls can be on different 206 continents, with different conventions and processes for handling of 207 emergency calls. 209 The IETF has historically refused to create national variants of its 210 standards. Thus, this document attempts to take into account best 211 practices that have evolved for circuit switched PSAPs, but makes no 212 assumptions on particular operating practices currently in use, 213 numbering schemes or organizational structures. 215 This document discusses the use of the Session Initiation Protocol 216 (SIP) by PSAPs and calling parties. While other inter-domain call 217 signaling protocols may be used for emergency calling, SIP is 218 ubiquitous and possesses, through its related specifications, more of 219 the needed features for the proper support of this use case. Only 220 protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable for 221 inter-domain communications, ruling out master-slave protocols such 222 as MGCP or H.248/Megaco. The latter protocols can naturally be used 223 by the enterprise or carrier placing the call, but any such call 224 would reach the PSAP through a media gateway controller, similar to 225 how interdomain VoIP calls would be placed. Other signaling 226 protocols may also use protocol translation to communicate with a 227 SIP-enabled PSAP. 229 Existing emergency services rely exclusively on voice and 230 conventional text telephony (known as TTY in the United States) media 231 streams. However, more choices of media offer additional ways to 232 communicate and evaluate the situation as well as to assist callers 233 and call takers to handle emergency calls. For example, instant 234 messaging and video could improve the ability to communicate and 235 evaluate the situation and to provide appropriate instruction prior 236 to arrival of emergency crews. Thus, the architecture described here 237 supports the creation of sessions of any media type, negotiated 238 between the caller and PSAP using existing SIP protocol mechanisms 239 [RFC3264]. To ensure that at least one common means of 240 communications, this document recommends certain minimal capabilities 241 in [I-D.rosen-sos-phonebcp] that call taker user agents and PSAP- 242 operated proxies should possess. 244 This document does not prescribe the detailed network architecture 245 for a PSAP or collection of PSAPs. For example, it does not describe 246 where PSAPs may place firewalls or how many SIP proxies they should 247 use. 249 This document does not introduce any new SIP header fields, request 250 methods, status codes, message bodies, or event packages. User 251 agents unaware of the recommendations in this draft can place 252 emergency calls, but may not be able to provide the same elevated 253 user interface functionality. The document suggests behavior for 254 proxy servers, in particular outbound proxy servers. 256 3. Overview of How Emergency Calls are Placed 258 We distinguish (Section 4) an emergency call from any other call by a 259 unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in 260 the initial call set-up signaling when a home or visited dialstring 261 is detected. We route emergency calls based on the location ( 262 (Section 5)) of the caller. To get this location we either include a 263 form of measuring (e.g. GPS) ( (Section 5.3.3)) device location in 264 the endpoint, or the endpoint acquires ( (Section 5.5)) its location 265 from the access network. The location is conveyed ( (Section 5.6)) 266 in the SIP signaling with the call. We route( (Section 6)) the call 267 based on location using the LoST protocol ( [I-D.hardie-ecrit-lost]) 268 which maps a location to a set of PSAP URIs. Each URI resolves to a 269 PSAP or an Emergency Services Routing Proxy which serves a group of 270 PSAPs. The call arrives at the PSAP with the location included in 271 the INVITE request. 273 Configuration Servers 274 . . . . . . . . . . . . . . . . . 275 . . 276 . +--------+ +----------+ . 277 . +--------+ | +----------+ | . 278 . | DHCP | | | SIP | | . 279 . | Servers|-+ | Registrar|-+ . 280 . +--------+ +----------+ . 281 . ^ ^ . 282 . . | . . . . . . . | . . . . . . 283 | | 284 |[1] |[2] 285 | | +--------+ 286 |+--------------+ +--------+ | 287 || | LoST | | 288 ||+-------------------->| Servers|-+ 289 ||| [3] +--------+ +-------+ 290 ||| ^ | | PSAP2 | 291 ||| [6] | | [7] +-------+ 292 ||| | v 293 ||| [4] +-------+ [5] +------+ [8] +-------+ [9] 294 Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 295 +-------+ +------+ +-------+ 297 +-------+ 298 | PSAP3 | 299 +-------+ 301 Figure 1: Generic ECRIT Component Topology 303 Figure 2 shows a generic emergency call establishment. This includes 304 the following: 305 o Alice - who will make the emergency call. 306 o Configuration Servers - Servers providing Alice's UA its IP 307 address and other configuration information, perhaps including 308 Location by-value or by-reference. In this flow, we use DHCP as 309 an example location acquisition protocol. To make this flow 310 easier to read, these configuration servers include a SIP 311 Registrar server, for Alice's UA to register with the local 312 domain, which will most likely be the case for an emergency call. 313 All these configuration messages are labeled M1 through M4, but 314 could easily require more messages than 4 to complete. 315 o ESRP - The Emergency Services Routing Proxy Server that recognizes 316 any INVITE as an emergency session initiation, and does special 317 things (knows to look for Location in the INVITE, dereferences a 318 location-by-reference, initiated a LoST Query to learn the PSAP 319 SIP(S)-URI for a UA at this location, etc). ESRPs are optional 320 elements and in some jurisdictions an emergency call may not pass 321 through one 322 o Mapping Server - Processes the LoST request for Location to PSAP- 323 URI Mapping function, either for an initial request from a UA, or 324 an in-call establishment request by an ESRP. 325 o PSAP - Call center where emergency calls are destined for in times 326 of emergencies. 328 Generally, Alice's UA either has location configured within her UA 329 when her UA boots, or she configures it with location once it boots 330 up, or her UA receives measured location from the network. Her UA 331 may have asked for location during boot-time, for example in a 332 DHCPREQUEST message or another location acquisition mechanism. 333 Alice's UA then will most likely register with a SIP domain. This 334 allows her to be contacted by other SIP entities. Next, her UA will 335 perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn an 336 early URI, for use if the Lost Query fails during an emergency call. 337 This learned early PSAP-URI will be placed in a Route header within 338 an emergency INVITE message, message [M7] in Figure 1. 340 Some time has hopefully passed since Alice's UA booted. In this 341 example, she dials or initiated an emergency call. This may have 342 been through her keypad with her locally known emergency dialstring. 343 It is important that this dialstring be recognized by her UA wherever 344 Alice is because she may be in enough distress she forgets what the 345 traveled-to emergency dialstring is; as there are more than 60 around 346 the world. 348 This emergency INVITE arrives at a SIP Proxy that understands the 349 concept of emergency calling, meaning it is an ESRP. In recognizing 350 the INVITE as an emergency call set-up, the ESRP looks for Location 351 within the message. [I-D.ietf-sip-location-conveyance] defines a SIP 352 Location header that either contain the location-by-reference URI, or 353 a [RFC2396] "cid:" indicating where in the message body the location- 354 by-value is. The ESRP can dereference the UA provided Location URI, 355 and insert the location information from the PIDF-LO into the LoST 356 query. This will prevent any problems of the LoST Mapping server 357 experiencing dereferencing problems with this request. This is 358 message [M7] and [M8] in Figure 1. The LoST response provides the 359 ESRP with the freshest PSAP-URI for that location (of Alice's UA) for 360 the most up to date routing choice. This is message [M9]. 362 The INVITE message receives a new Request-URI in the ESRP, which was 363 returned in the LoST response. This message, [M10] is transmitted 364 towards the most current PSAP for Alice's location. Message [M11], 365 the 200 OK to the INVITE may traverse one or more proxies if they 366 chose insert a Record-Route header, or if one or more are B2BUAs. 367 Figure 1 does not show this. The ACK completes the call set-up and 368 the emergency call is established, allowing the PSAP call-taker to 369 talk to Alice about her emergency. 371 Configuration Mapping 372 Alice Servers ESRP Server PSAP 374 [M1] DHCP Request(s) (may ask for Location) 375 ----------> 376 [M2] DHCP Reply(s) (replies with location if asked) 377 <--------- 378 [M3] SIP REGISTER (perhaps with PIDF-LO) 379 ----------> 380 [M4] SIP 200 OK (REGISTER) 381 <--------- 382 [M5] Initial LoST Protocol Query (contains Location) 383 ------------------------------> 384 [M6] Initial LoST Protocol Response (contains PSAP-URI) 385 <------------------------------ 387 ***Some time later, Alice dials/initiates emergency call*** 389 [M7] INVITE (sos, Location & early Mapping URI) 390 ---------------------> 392 [M8] LoST Protocol Query (with Location) 393 -----------------> 394 [M9] LoST Protocol Response (with PSAP-URI) 395 <----------------- 397 [M10] INVITE (sos, Location & PSAP-URI) 398 --------------------------------------> 399 [M11] 200 OK 400 <-------------------------------------------------------------- 401 [M12] ACK 402 --------------------------------------------------------------> 403 Emergency Session Established 404 <=============================================================> 406 Figure 2: General Flow of an Emergency Call Establishment 408 This is a very rough example of the operation of an emergency call 409 establishment. There are no layer 3 routers in the message flow, and 410 whatever security messages exist in the call are not shown either. 411 Each of those aspects will be addressed individually, to keep each 412 discussion in context of that subject, for clarity. 414 4. Identifying an Emergency Call 416 Using the PSTN, emergency help can often be summoned by dialing a 417 nationally designated, widely known number, regardless of where the 418 telephone was purchased. The appropriate number is determined by 419 which infrastructure the telephone is connected to. However, this 420 number differs between localities, even though it is often the same 421 for a country or region, such as many countries in the European 422 Union. In some countries, there is a single digit sequence that is 423 used for all types of emergencies. In others, there are several 424 sequences that are specific to the responder, e.g., one for police, 425 another for fire. It is deemed impractical to change the dialed 426 digits to summon help. For end systems, it is desirable to have a 427 universal identifier, independent of location, to allow the automated 428 inclusion of location information and to allow the device and other 429 entities in the call path to perform appropriate processing within 430 the signaling protocol in an emergency call set-up. 432 As part of the overall emergency calling architecture, we define 433 common emergency call URIs which are defined in [I-D.ietf-ecrit- 434 service-urn]. Users are not expected to "dial" an emergency URN. 435 Rather, the current dial sequence should be translated to the 436 appropriate service URN. Such translation could ideally be performed 437 in the endpoint, but could be performed in a signaling intermediary 438 (proxy server). For devices that are mobile or nomadic, an issue 439 arises of whether the home or visited dialing strings should be used. 440 Many users would prefer that their home dialing sequences work no 441 matter where they are. Local laws and preferences of the emergency 442 response professionals are that the visited dialing sequences be 443 used. The best answer seems to be for both to work. 445 The mechanism for obtaining the dialing sequences for a given 446 location is provided by LoST [I-D.hardie-ecrit-lost] and the 447 procedures for the translation are detailed in [I-D.rosen-sos- 448 phonebcp]. Where the endpoint does not support the translation of 449 dialstrings to telephone numbers, the dialing sequence would be 450 represented as a dialstring [I-D.rosen-iptel-dialstring]. 452 If the endpoint recognizes the dialstring, the service URN would 453 appear in the To: field. If it does not, the dialstring would 454 appear. If a proxy detects the emergency dialstring, it would, if it 455 does not also perform the location mapping, place the service URN in 456 the Request-URI and/or a Route header. 458 5. Location and Its Role in an Emergency Call 459 5.1. Introduction 461 Caller location plays a central role in routing emergency calls. For 462 practical reasons, each PSAP generally handles only calls for a 463 certain geographic area (overload arrangements between PSAPs to 464 handle each others calls notwithstanding). Other calls that reach it 465 by accident must be manually re-routed (transferred) to the 466 appropriate PSAP, increasing call handling delay and the chance for 467 errors. The area covered by each PSAP differs by jurisdiction, where 468 some countries have only a small number of PSAPs, while others 469 decentralize PSAP responsibilities to the level of counties or 470 municipalities. 472 In most cases, PSAPs cover at least a city or town, but there are 473 some areas where PSAP coverage areas follow old telephone rate center 474 boundaries and may straddle more than one city. Irregular boundaries 475 are common, often for historical reasons. Routing must be done on 476 PSAP service boundaries, not "closest" or "best fit" algorithms. 478 5.2. Types of Location Information 480 There are four primary types of location information: civic, postal, 481 geospatial, and cellular cell tower and sector. 483 Civic: Civic location information describes the location of a person 484 or object by a street address that corresponds to a building or 485 other structure. (This is sometimes also called "civil" location 486 information.) Civic location may include more finer grained 487 location information such as floor, room, cubicle. Civic 488 information comes in two forms: 489 Jurisdictional - This refers to a civic location using actual 490 political subdivisions, especially for the community name. 491 Postal - This refers to a civic location used to mail a letter to. 492 The name of the post office sometimes does not correspond to 493 the actual community name and a postal addrress may contain 494 post office boxes or street addresses that do not correspond to 495 an actual building. Postal addresses are generally unsuitable 496 for emergency call routing, but may be the only address 497 available. 498 Geospatial: Geospatial addresses contain longitude, latitude and 499 altitude information based on an understood datum (starting point) 500 and earth shape model. While there have been many datums 501 developed over time, most modern systems are using or moving 502 towards WGS84. 504 Cell tower/sector: Cell tower and sectors identify the cell tower and 505 the antenna sector that the mobile device is currently using. 506 Cell/sector information could also be transmitted as an 507 irregularly shaped polygon of geospatial coordinates reflecting 508 the likely geospatial location of the mobile device, but since 509 these boundaries are not sharp, transmitting the raw information 510 is probably preferable. 512 In IETF protocols, civic and geo forms are both supported. The civic 513 forms include both the postal and jurisdictional fields. The cell 514 tower/sector can be represented as a polygon. 516 5.3. Location Determination 518 Location information can be entered by the user or installer of a 519 device ("manual configuration"), can be measured by the end system, 520 can be delivered to the end system by some protocol or can be 521 measured by a third party and inserted into the call signaling. We 522 discuss these in detail below. 524 In some cases, an entity may have multiple sources of location 525 information, possibly partially contradictory. This is particularly 526 likely if the location information is determined both by the end 527 system and a third party. Handling multiple locations is discussed 528 in XRef??. Conflicting location information is particularly harmful 529 if it points to multiple distinct PSAPs. Guidelines for dealing with 530 multiple locations is given in [I-D.rosen-sos-phonebcp]. 532 All location objects MUST be delivered to the PSAP. To facilitate 533 such policy decisions, location information should contain 534 information about the source of data, such as GPS, manually entered 535 or based on access network topology. In addition, the generator of 536 the location information should be included. 538 The call should indicate which location information has been used for 539 routing, so that the same location information is used for all call 540 routing decisions. Otherwise, two proxies might pick different 541 location information from the call request, resulting in different 542 routing decisions for different transactions. 544 End systems and network elements can derive location information from 545 a variety of sources. It is not the goal of this document to 546 exhaustively enumerate them, but we provide a few common examples in 547 the sections below. 549 5.3.1. User-Entered Location Information 551 Location information can be maintained by the end user or the 552 installer of an endpoint in the endpoint itself, or in a database. 554 Location information added by end users is almost always inferior to 555 measured or wire database information, as users may mistype civic 556 location information, may not know the meaning of geospatial 557 coordinates or may use address information that does not correspond 558 to a recognized civic address. A user-entered location can fail to 559 be changed when the location of a device changes during or after 560 movement. For example, a user could move their residence to another 561 dwelling, not update their device/equipment with this new location, 562 and place an emergency call with old location information. 564 All that said, there are always a small number of cases where the 565 mechanisms used by the access network to determine location fail to 566 accurately reflect the actual location of the endpoint. For example, 567 the user may deploy his own WAN behind an access network, effectively 568 remoting an endpoint some distance from the access network's notion 569 of its location. There must be some mechanism provided to provision 570 a location for an endpoint by the user or by the access network on 571 behalf of a user. As an aside, normally, if an emergency caller 572 insists he is at a location different from what any automatic 573 location determination system reports he is, responders will always 574 be sent to the user's self-declared location. However this is a 575 matter of local policy and is outside the scope of this document. 577 5.3.2. Access Network "Wire Database" Location Information 579 Location information can be maintained by the access network, 580 relating some form of identifier for the end subscriber or device to 581 a location database ("wire database"). In enterprise LANs, wiremap 582 databases map Ethernet switch ports to building layouts at known 583 locations. In DSL installations, the local telephone carrier 584 maintains a mapping of wire-pairs to subscriber addresses. 586 Even for IEEE 802.11 wireless access points, wire databases may 587 provide sufficient location resolution; the location of the access 588 point may be sufficient location information for each of the clients 589 served by that access point. This may be the connectivity type for 590 both residential users of DSL and Cable Modem installations, as well 591 as the only infrastructure at a WiFi hotspot, such as a coffee shop. 592 Each of these cases will have a known civic address of the dwelling/ 593 business, likely providing sufficient location resolution. 595 Wire databases to the home are likely to be the most promising 596 solution for residential users where a service provider knows the 597 customer's service address. The service provider can then perform 598 address verification, similar to the current system in some 599 jurisdictions. 601 5.3.3. End-System Measured Location Information 603 Global Positioning System (GPS) sensors may be embedded directly in 604 the end device. GPS produces relatively high precision location 605 fixes in open-sky conditions, but the technology still faces several 606 challenges in terms of performance (time-to-fix and time-to-first- 607 fix), as well as obtaining successful location fixes within shielded 608 structures, or underneath the ground (tunnels, basements, etc.). It 609 also requires all devices to be equipped with the appropriate GPS 610 capability. GPS technology is improving, and is increasingly 611 successful in more difficult conditions such as dense urban canyons 612 and inside commercial structures. It is currently accurate to tens 613 of meters using some kind of "assist", which may be operated by the 614 access network (A-GPS) or by a government (WAAS). Newer multi- 615 frequency systems will improve accuracy without assist. 617 GPS equipped devices vary depending on which element intitiates 618 requests, which element actually determines final location, assist 619 mechanisms, etc. Some common implementations include: 620 1. GPS S/A (standalone), device initiated 621 2. GPS S/A, network initiated 622 3. AGPS-device initiated, network determined 623 4. AGPS-device initiated, network augmented 624 5. AGPS-network initiated, network determined 625 6. AGPS-network initiated, network augmented 627 5.3.4. Third-party Measured Location Information 629 Wireless triangulation: Elements in the network infrastructure 630 triangulate end systems based on signal strength, angle of arrival 631 or time of arrival. Common mechanisms deployed include. 632 1. Time Difference Of Arrival - TDOA 633 2. Uplink Time Difference Of Arrival - U-TDOA 634 3. Angle of Arrival - AOA 635 4. RF-Fingerprinting 636 5. Advanced Forward Link Trilateration - AFLT 637 6. Enhanced Forward Link Trilateration - EFLT 638 Sometimes triangulation and measured mechanisms are combined, for 639 example A-GPS with AFLT 640 Location beacons: A short range wireless beacon, e.g., using 641 Bluetooth or infrared, announces its location to mobile devices in 642 the vicinity. 644 5.4. Location and References to Location 646 Location information may be expressed as the actual civic or geo 647 value but can transmitted as by-value (wholly contained within the 648 signaling message) or by-reference (a URI pointing to the value 649 residing on a remote node waiting to be dereferenced). There are 650 pros and cons to each form: 651 location-by-value: 652 pro- Value available to each device along the path immediately for 653 further processing. 654 con- Size, especially if constrained to a UDP transport. Value 655 fixed at the time the value is acquired from the access 656 network. Value can be changed by endpoint, which may be 657 considered untrustworthy for this critical usage. 658 location-by-reference 659 pro- 'Small size. Value can fixed at time of dereference. Value 660 cannot be changed by endpoint 661 con- URI resolution requires location source be available and 662 accessible by dereferencer. Dereferencing takes time. 663 Dereferencing may fail. 665 5.5. End System Acquisition of Location 667 Unless a user agent has access to provisioned or locally measured 668 location information, it must obtain it from the access network. We 669 call that "acquisition". There are several protocols that can be 670 used for this purpose. 672 DHCP can deliver civic [I-D.ietf-geopriv-dhcp-civil] or geospatial 673 [RFC3825] information. User agents would need to support both 674 formats. Note that a user agent can use DHCP, via the DHCP 675 REQUEST or INFORM messages, even if it uses other means to acquire 676 its IP address. 677 Insert reference to L7 acquisition protocol document> is another 678 choice. 679 Link-Layer Discovery Protocol [LLDP]), with proposed extensions 680 [LLDP-MED], may also be used to deliver location information. 681 SUPL OASIS is yet another choice. 683 Other protocols may be devised by other standards bodies. For 684 endpoints with common network connections (such as an Ethernet jack 685 or a WiFi connection), unless every network supported every protocol, 686 or alternatively, every device supported every protocol, serious 687 incompatibilities would ensue. [I-D.rosen-sos-phonebcp] contains a 688 (short) list of protocols such devices must support. 690 Where an access network can control the specification of EVERY 691 endpoint that could make an emergency call that is directly connected 692 to the network, or indirectly connected (for example, a device on a 693 LAN behind a network attachment unit), it may specify any protocol it 694 wishes for each endpoint. This is a very unusual case; nearly every 695 access network can be used to support an Ethernet based LAN behind 696 it. For example, existing mobile networks are being used to support 697 routers and LANs behind a wireless data network WAN connection. It 698 is possible that the access network supports a protocol not on the 699 phonebcp list, but another element which the access network provider 700 controls the specification of can acquire location using that 701 protocol and then that element can support one of the phonebcp's list 702 of protocols. For example, if the access network provider supplies a 703 router which includes a DHCP server, it can acquire location using an 704 access network specific protocol, and use the location information to 705 supply it to its clients via DHCP. 707 Location for non-mobile devices is normally expected to be acquired 708 at network attachment time and retained by the device. It should be 709 refreshed when the cached value becomes invalid (for example, if DHCP 710 is the acquisition protocol, refresh of location may occur when the 711 IP address lease is renewed). At the time of an emergency call, the 712 location should be refreshed, with the retained location used if the 713 location acquisition does not immediately return a value. Mobile 714 devices may determine location at network attachment time and 715 periodically thereafter as a backup in case location determination at 716 the time of call does not work. Mobile device location may be 717 refreshed when a TTL expires, the device moves beyond some 718 boundaries, etc. Normally, mobile devices will acquire its location 719 at call time for use in an emergency call, but see Section 5.7 721 5.6. Conveyance of Location 723 When an emergency call is placed, the endpoint (normally) puts 724 location information in the signaling with the call. We refer to 725 that as "conveyance" to distinguish it from "acquisition". 726 Acquisition gets location from access network to endpoint, conveyance 727 sends location from endpoint to elements that route the call based on 728 that location object and the PSAP. Using SIP, the location 729 information is conveyed following the procedures in [I-D.ietf-sip- 730 location-conveyance]. The form of the location information obtained 731 by the acquisition protocol may not be the same as the conveyance 732 protocol uses (PIDF-LO [RFC4119]). Conversion by the endpoint may be 733 required. 735 For emergency call purposes, conversion of location information from 736 civic to geo or vice versa is not desirable. The location should be 737 sent in the form it was determined. The PSAP may convert, if it 738 needs to, and if conversion resulted from an earlier conversion, 739 unacceptable errors may be introduced. 741 5.7. Location Updates 743 Location information may not be available at call setup time for 744 mobile devices. For example, if a GPS-enabled cell phone is turned 745 on and then immediately places an emergency call, it can take 746 significant additional time before the cell phone acquires a GPS fix 747 and its location. Thus, while it is desirous to base emergency 748 routing on precise caller location information, it is not possible in 749 all circumstances to do so. In some cases, the initial call setup 750 will proceed based on, for example, cell and sector information and 751 then add location information during the call, rather than delaying 752 the initial call setup by an unacceptable amount of time. 754 In addition, the location of a mobile caller, e.g., in a vehicle or 755 aircraft, can change significantly during the emergency call. The 756 PSAP must be able to get updated location information while it is 757 processing the call. 759 Location updates may be conveyed either in a re-INVITE or UPDATE 760 [RFC3311] request message (where UPDATE is preferred) or the PSAP may 761 subscribe to the location information of the caller, using SIP 762 presence mechanisms (RFC 3265 [RFC3265] RFC 3856 [RFC3856]). 763 Authorization for subscriptions is for future study. 765 5.8. Location Validation 767 Location must be validated prior to a device placing an actual 768 emergency call. Validation in this context means both that there is 769 a mapping from the address to a PSAP and that the PSAP understands 770 how to direct responders to the location. This is not as easy as it 771 sounds. There are, for example, many cases of two names for the same 772 street, or two streets with the same name in a city. In some 773 countries, the current system provides validation. For example, in 774 the United States, the Master Street Address Guide (MSAG) records all 775 valid street addresses and is used to ensure that phone billing 776 records correspond to valid emergency service street addresses. 777 Validation is normally a concern for civic addresses, although there 778 could be a concern that a given geo is within at least one PSAP 779 service boundary; that is, a "valid" geo is one for which there is a 780 mapping. 782 The LoST resolver[I-D.hardie-ecrit-lost] includes a validation 783 function. Validation should ideally be performed when a location is 784 entered into a Location Information Server (which is normally a 785 provisioning mechanism in the access carrier's operation and support 786 system). It should be confirmed periodically, because the mapping 787 database undergoes slow change; new streets are added or removed, 788 community names change, postal codes change, etc. Test functions 789 (Section 13) should also re-validate. 791 5.9. Default Location 793 Occasionally, a failure may occur where the access network cannot 794 determine the actual location of the caller. In these cases, it must 795 supply a default location. The default location should be as 796 accurate as the network can determine. For example, in a cable 797 network, a default location for each CMTS, with a representative 798 location for all cable modems served by that CMTS could be provided 799 if the network is unable to resolve the subscriber to any unit less 800 than the CMTS. Default locations must be marked as such (how?) so 801 that the PSAP knows that the location is not accurate. 803 6. Routing the Call to the PSAP 805 Emergency calls are routed based on one or more of the following 806 criteria expressed in the call setup request (INVITE): 808 Location: Since each PSAP serves a limited geographic region and 809 transferring existing calls delays the emergency response, calls 810 need to be routed to the most appropriate PSAP. In this 811 architecture, emergency call setup requests contain location 812 information, expressed in civic or geospatial coordinates, that 813 allows such routing. If there is no or imprecise (e.g., cell 814 tower and sector) information at call setup time, an on-going 815 emergency call may also be transferred to another PSAP based on 816 location information that becomes available in mid-call. 817 Type of emergency service: In some jurisdictions, emergency calls for 818 fire, police, ambulance or mountain rescue are directed to just 819 those emergency-specific PSAPs. We support this mechanism by 820 optionally labeling calls with a service identifier [I-D.ietf- 821 ecrit-service-urn]. 822 Media capabilities of caller: In some cases, emergency call centers 823 for specific caller media preferences, such as typed text or 824 video, are separate from voice systems. Also, even if media 825 capability does not affect the selection of the PSAP, there may be 826 call takers within the PSAP that are specifically trained, e.g., 827 in interactive text or sign language communications. Again, we 828 use the callee capabilities [RFC3840] mechanism to label and route 829 such calls. 831 Routing for calls by location and by service is the primary function 832 LoST [I-D.hardie-ecrit-lost] provides. LoST accepts a query with 833 location (by-value) in either civic or geo form, plus a service 834 identifier, and returns an xml data structure containing a URI (or 835 set of URIs) to route the call to. Normal SIP [RFC3261] routing 836 functions are used to resolve the URI to a next hop destination. 838 The endpoint can complete the LoST mapping from its location at boot 839 time, and periodically thereafter. It should attempt to obtain a 840 "fresh" location, and from that a current mapping when it places an 841 emergency call, and if accessing either its location acquisition 842 function or mapping function fails, it should use this cached value. 843 The call would follow its normal outbound call processing, setting 844 the 'To:' header to the service URN, and placing the mapping result 845 URI in a Route header. Most implementations would also have the 846 mapping result in the Request-URI. If the endpoint does not perform 847 mapping on its location, it should set the Request-URI to the service 848 URN. 850 Each proxy receiving an emergency call request, identified as 851 described in Section 4, in the Request-URI it should assume that the 852 endpoint did not map the location, and it should attempt mapping. 854 With the URI obtained from mapping, whether by the endpoint or the 855 proxy, the proxy routes the call. There are three types of routing 856 actions: default routing, SIP routing and local routing. Not all 857 routing actions can take all three dimensions (location, type of 858 service, capabilities) into account. 860 ESRPs and user agents using default routing forward all emergency 861 call requests to one designated ESRP, regardless of the location of 862 the caller, type of service or media capabilities. Default routing 863 is always used when no location is available, or routing to all of 864 the URIs received from mapping fail. 866 Normal SIP[RFC3261] mechanisms are used to route calls to the URI 867 obtained from the LoST dip. 869 Finally, an ESRP may use a local database or other query protocols to 870 perform call routing using location, type of service or callee 871 capabilities. The details of such a database are beyond the scope of 872 this document. 874 Call routing may combine several of these methods. For example, an 875 outbound proxy might route all emergency calls to a designated ESRP. 876 This then uses LoST with both the service type and the location. 877 That may route to a region, state or country level ESRP which uses 878 the user part of the URI that it receives, PSAP status and congestion 879 information to route to a PSAP. 881 If an emergency call INVITE request does not contain location 882 information and no other location hints (such as subscriber identity) 883 are available, the first ESRP in the call path should route it to a 884 PSAP or group of PSAPs that is geographically local to that proxy, 885 since no other call routing can be performed. 887 Jurisdictions organizing PSAPs may choose to implement multiple 888 levels of routing based on location. For example, a state, province 889 or county might deploy an ESRP in front of a collection of PSAPs. 890 The information available to a VoIP carrier or enterprise ESRP may be 891 coarse, so that any location within the state or province gets routed 892 to that representative ESRP, with that ESRP performing the detailed 893 routing to a specific PSAP. The routing mechanism used by the ESRP 894 may nor may not rely on public information. Depending on choices 895 made by the operator of the PSAP and ESRP, the PSAP may only be 896 reachable by SIP requests routed through the ESRP. 898 7. Signaling of Emergency Calls 900 Since emergency calls carry privacy-sensitive information, they are 901 subject to the requirements for geospatial protocols [RFC3693] . In 902 particular, signaling information should be carried in TLS, i.e., in 903 'sips' mode. While requiring TLS is actually the way the standards 904 are written, it is unacceptable to have an emergency call fail to 905 complete because a TLS connection was not created, for any reason. 906 In many cases, persistant TLS connections can be maintained between 907 elements to minimize the time needed to establish them. 909 Details can be found in [I-D.ietf-sip-location-conveyance]. 911 8. Caller Preferences 913 SIP Caller Preferences [RFC3841] may be used to signal how the PSAP 914 should handle the call. For example, a language preference expressed 915 in an Accept-Language header may used as a hint to cause the PSAP to 916 route the call to a call taker who speaks the requested language. 918 9. Including a Valid Call-Back Identifier 920 The call-taker must be able to reach the emergency caller if the 921 original call is disconnected. In traditional emergency calls, 922 wireline and wireless emergency calls include a callback identifier 923 for this purpose. In SIP systems, the caller should include a 924 Contact header field indicating its device URI, if available, or 925 possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a 926 proxy. This identifier would be used to initiate call-backs 927 immediately by the call-taker if, for example, the call is 928 prematurely dropped. 930 In addition, a call-back identifier should be included either as the 931 URI in the From header field [RFC3261] or, preferably as a SIP 932 Identity[I-D.ietf-sip-identity]. This identity would be used to 933 initiate a call-back at a later time and may reach the caller, not 934 necessarily on the same device (and at the same location) as the 935 original emergency call. 937 Finally, there may be two other call identifiers included in an 938 emergency call. An identifier may be included which can be used to 939 identify the caller, as opposed to the device or the subscriber of a 940 specific calling service. This identifier may be used to retrieve 941 information about the caller that is independent of calling service. 942 For example, Alice may have home, office and mobile telephony 943 services, but she is the same Alice in all of them. Information 944 about Alice may be kept by an entity independent of any telephony 945 service provider. The caller identity is a URI and is placed in a 946 SIP Call-Info header [RFC3261] using the token "?" following the 947 recommendations in ???. 949 The communications service provider may also include an identifier 950 that may be used to retrieve information specific to the call held by 951 the service provider. This identifier, also a URI may be placed in 952 the Call-Info header using the token "?". 954 10. Mid-Call Services and Behavior 956 A PSAP may need to REFER[RFC3515] a call to a bridge for 957 conferencing. The caller should also be prepared to have the call 958 transferred (usually attended, but possibly blind) as per[I-D.ietf- 959 sipping-service-examples]. 961 . 963 11. Call Termination 965 It is undesirable for the caller to terminate an emergency call. 966 Strategies for devices to handle caller attempts to terminate may be 967 found in [I-D.rosen-sos-phonebcp]. PSAP call termination is 968 accomplished with normal SIP call termination procedures. 970 The PSAP may return 403 (Forbidden) in response to a BYE request if 971 caller hangs up before the PSAP wants to relinquish the call. 973 12. Media 975 PSAPs should accept media streams on RTP [RFC3550]. Traditionally, 976 voice has been the only media stream accepted by PSAPs. In some 977 countries, text, in the form of BAUDOT codes or similar tone encoded 978 signaling within a voiceband is accepted ("TTY") for persons who have 979 hearing disabilities. With the Internet comes a wider array of 980 potential media which a PSAP may wish to accept. Using SIP signaling 981 includes the capability to negotiate media. Normal SIP offer/answer 982 [RFC3264] negotiations should be used to agree on the media streams 983 to be used. PSAPs should accept interactive text [I-D.ietf-avt- 984 rfc2793bis]. All PSAPs should accept G.711 encoded voice as 985 described in [RFC3551]. Newer text forms are rapidly appearing, with 986 Instant Messaging now very common, PSAPs should accept IM with at 987 least [RFC3428] as well as [RFC3920]. 989 13. Testing 991 13.1. Testing Mechanism 993 Since the emergency calling architecture consists of a number of 994 pieces operated by independent entities, it is important to be able 995 to test whether an emergency call is likely to succeed without 996 actually occupying the human resources at a PSAP. Both signaling and 997 media paths need to be tested since NATs and firewalls may allow the 998 session setup request to reach the PSAP, while preventing the 999 exchange of media. 1001 INVITE requests to a service urn with a urn parameter of "test" 1002 indicates a request for an automated test. For example, 1003 "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response 1004 indicates that the address was recognized and a 404 (Not found) that 1005 it was not. A 486 (Busy Here) should be returned if the test service 1006 is busy, and a 488 (Not Acceptable Here) should be returned if the 1007 PSAP does not support the test mechanism. 1009 In its response to the test, the PSAP may include a text body 1010 indicating the identity of the PSAP, the requested service, and the 1011 location reported with the call. For the latter, the PSAP should 1012 return location-by-value even if the original location delivered with 1013 the test was by-reference. 1015 A PSAP accepting a test call should accept a media loopback test[I- 1016 D.ietf-mmusic-media-loopback] and should support the "rtp-pkt- 1017 loopback" and "rtp-start-loopback" options. The user agent would 1018 specify a loopback attribute of "loopback-source", the PSAP being the 1019 mirror. User Agents should expect the PSAP to loop back no more than 1020 3 packets of each media type accepted, after which the PSAP would 1021 normally send BYE. 1023 User agents should perform a full call test, including media loopback 1024 to after a disconnect and subsequent change in IP address, as the NAT 1025 configuration may have changed. 1027 User agents must not place a test call immediately after booting, as 1028 a widespread power outage and subsequent restoration would impose an 1029 inordinate load on the emergency call routing system. 1031 PSAPs may refuse repeated requests for test from the same device in a 1032 short period of time. 1034 13.2. Manual Testing 1036 A compliant user agent implementation MUST have the capability to 1037 perform the test outlined in Section 13.1 by explicit user request. 1039 13.3. Automatic 'sos service urn' Resolution Testing 1041 If a user agent does its own call routing, it MUST periodically and 1042 after every significant location change or network attachment 1043 ascertain that it can still resolve its current location to a PSAP 1044 address. It does not actually have to generate a SIP request to test 1045 emergency calls. 1047 A significant location change is defined here as a change of [insert 1048 a reasonable metric here] or a change in the A1 or A2 level of civil 1049 locations. 1051 14. Example Call Flows 1053 TBD 1055 15. Alternatives Considered 1057 This is a non-normative appendix. During discussions of emergency 1058 calling, a number of suggestions are commonly made. Below, we 1059 discuss some of the reasons why these alternatives do not satisfy the 1060 requirements of emergency calling. 1062 15.1. tel URIs 1064 Instead of providing URIs to call routing proxies or end systems, it 1065 has been suggested that end systems be configured with a "tel" URI 1066 [RFC3966]. Such a "tel" URI would have to be routed to a 1067 geographically appropriate telephony gateway, as it is unlikely that 1068 every building, enterprise or residence will have its own gateway. 1069 VoIP devices can be used in networks that are completely unaware of 1070 VoIP services, with VoIP service providers that are physically far 1071 removed from the caller's network location. Thus, the use of a tel 1072 URI simply moves the problem to the outbound proxy, which has to use 1073 the caller's location to determine the appropriate telephony gateway. 1075 In addition, emergency telephone numbers are far from universal, with 1076 some such numbers used for non-emergency purposes elsewhere. Thus, 1077 an outbound proxy would have to ascertain the location of the caller 1078 to guess whether the "tel" URI identifies an emergency call or some 1079 other number. 1081 Thus, "tel" URIs are not likely to be appropriate or sufficient for 1082 identifying emergency calls and do not, by themselves, solve the call 1083 routing problem. 1085 16. Security Considerations 1087 16.1. Caller Authentication 1089 Authentication is broken out to into two parts: authentication of end 1090 devices and authentication of end users. If all emergency calls are 1091 to handled in some way, authentication of either case should not be 1092 required, but may be recommended to prevent or reduce fraudulent 1093 calls into a PSAP. While it is possible to authenticate either the 1094 device or user, the most common approach is to authenticate the end 1095 user only. A requirement to authenticate carries with it the risk of 1096 disallowing an emergency call altogether. Mechanisms such as the 1097 RFC3893 [RFC3893] may be used to assert identities. 1099 In keeping with established customs in circuit-switched emergency 1100 calling, authentication cannot be made a prerequisite for routing or 1101 accepting an emergency call. However, a call taker may be more 1102 suspicious of a caller and request additional information if the call 1103 authenticity cannot be verified. 1105 16.2. Location Privacy 1107 Location is sensitive information, it must be protected against 1108 disclosure to unauthorized persons. In most jurisdictions placing an 1109 emergency call implies disclosure of location to all the entities 1110 needing location to properly route and respond to the call. 1111 Nevertheless, even in an emergency, callers have an expectation that 1112 their location will not be divulged outside of that implied release. 1114 During acquisition of the location information, an eavesdropper or 1115 impersonator may obtain location. When DHCP is used, authentication 1116 [RFC3118] should be used to protect the location option. 1118 16.3. PSAP Impersonation 1120 See Section 16.4. 1122 With LoST-based call routing (Section 6), an attacker could modify 1123 the mapping entries for one or more locations, re-routing calls 1124 destined for them. The security mechanisms for provisioning the data 1125 in the LoST database must be robust. 1127 LoST is a distributed database, with many replicas of authoritative 1128 data. An attacker may impersonate a valid LoST server and supply 1129 fraudulent data. An attacker may also perpetrate a denial of service 1130 attack on LoST servers. These issues are addressed in [I-D.hardie- 1131 ecrit-lost]. 1133 Finally, the URI LoST returns would normally contain a domain name. 1134 The domain can be hijacked by several known attacks. TLS should be 1135 used to place calls, with the domain name verified. Using DNSSEC 1136 [RFC4033] on the DNS entries is recommended. 1138 16.4. Preventing Call Misdirection 1140 We need to prevent an emergency call reaching a destination other 1141 than a PSAP. For example, a rogue UA able to intercept SIP requests 1142 might be able to impersonate a PSAP. 1144 In the absence of a globally recognized certificate that ensures that 1145 the owner is a legitimate PSAP, we rely on a chain of trust enforced 1146 by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop 1147 to route the call only to destinations supporting TLS transport. 1148 Each ESRP verifies that the next-hop destination chosen as described 1149 in Section 6 corresponds to the server certificate offered by that 1150 destination. 1152 16.5. Call Signaling Integrity 1154 Preventing a malicious outsider from manipulating call information in 1155 SIP requests can be assured by using "sips" (that is, TLS, hop-by-hop 1156 from caller to emergency call taker. 1158 16.6. Media Integrity and Confidentiality 1160 Media integrity and confidentiality can be assured by the use of 1161 SRTP[RFC3711]. 1163 17. Acknowledgements 1164 This draft was created from a 1165 draft-schulzrinne-sipping-emergency-arch-02 together with sections 1166 from draft-polk-newton-ecrit-arch-considerations-02. 1168 Design Team members participating in this draft creation include 1169 Hannes Tshofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger 1170 Marshall, Stu Goldman, Shida Schubert and Tom Taylor. 1172 18. References 1174 18.1. Normative References 1176 [I-D.hardie-ecrit-lost] 1177 Hardie, T., "LoST: A Location-to-Service Translation 1178 Protocol", draft-hardie-ecrit-lost-00 (work in progress), 1179 March 2006. 1181 [I-D.ietf-avt-rfc2793bis] 1182 Hellstrom, G., "RTP Payload for Text Conversation", 1183 draft-ietf-avt-rfc2793bis-09 (work in progress), 1184 August 2004. 1186 [I-D.ietf-ecrit-requirements] 1187 Schulzrinne, H. and R. Marshall, "Requirements for 1188 Emergency Context Resolution with Internet Technologies", 1189 draft-ietf-ecrit-requirements-10 (work in progress), 1190 June 2006. 1192 [I-D.ietf-ecrit-service-urn] 1193 Schulzrinne, H., "A Uniform Resource Name (URN) for 1194 Services", draft-ietf-ecrit-service-urn-03 (work in 1195 progress), May 2006. 1197 [I-D.ietf-geopriv-dhcp-civil] 1198 Schulzrinne, H., "Dynamic Host Configuration Protocol 1199 (DHCPv4 and DHCPv6) Option for Civic Addresses 1200 Configuration Information", 1201 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 1202 January 2006. 1204 [I-D.ietf-mmusic-media-loopback] 1205 Hedayat, K., "An Extension to the Session Description 1206 Protocol (SDP) for Media Loopback", 1207 draft-ietf-mmusic-media-loopback-02 (work in progress), 1208 November 2005. 1210 [I-D.ietf-sip-gruu] 1211 Rosenberg, J., "Obtaining and Using Globally Routable User 1212 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1213 (SIP)", draft-ietf-sip-gruu-08 (work in progress), 1214 June 2006. 1216 [I-D.ietf-sip-identity] 1217 Peterson, J. and C. Jennings, "Enhancements for 1218 Authenticated Identity Management in the Session 1219 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 1220 (work in progress), October 2005. 1222 [I-D.ietf-sip-location-conveyance] 1223 Polk, J. and B. Rosen, "Session Initiation Protocol 1224 Location Conveyance", 1225 draft-ietf-sip-location-conveyance-02 (work in progress), 1226 March 2006. 1228 [I-D.ietf-sipping-config-framework] 1229 Petrie, D., "A Framework for Session Initiation Protocol 1230 User Agent Profile Delivery", 1231 draft-ietf-sipping-config-framework-08 (work in progress), 1232 March 2006. 1234 [I-D.rosen-iptel-dialstring] 1235 Rosen, B., "Dialstring parameter for the Session 1236 Initiation Protocol URI", draft-rosen-iptel-dialstring-03 1237 (work in progress), March 2006. 1239 [I-D.rosen-sos-phonebcp] 1240 Rosen, B. and J. Polk, "Best Current Practice for 1241 Communications Services in support of Emergency Calling", 1242 draft-rosen-sos-phonebcp-00 (work in progress), 1243 March 2006. 1245 [LLDP] "IEEE802.1ab Station and Media Access Control", Dec 2004. 1247 [LLDP-MED] 1248 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1249 Endpoint Discovery". 1251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1252 Requirement Levels", BCP 14, RFC 2119, March 1997. 1254 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1255 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1256 August 1998. 1258 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1259 Messages", RFC 3118, June 2001. 1261 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1262 A., Peterson, J., Sparks, R., Handley, M., and E. 1263 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1264 June 2002. 1266 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1267 with Session Description Protocol (SDP)", RFC 3264, 1268 June 2002. 1270 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1271 Event Notification", RFC 3265, June 2002. 1273 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1274 UPDATE Method", RFC 3311, October 2002. 1276 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1277 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1278 for Instant Messaging", RFC 3428, December 2002. 1280 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1281 Method", RFC 3515, April 2003. 1283 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1284 Jacobson, "RTP: A Transport Protocol for Real-Time 1285 Applications", STD 64, RFC 3550, July 2003. 1287 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1288 Video Conferences with Minimal Control", STD 65, RFC 3551, 1289 July 2003. 1291 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1292 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1294 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1295 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1296 RFC 3711, March 2004. 1298 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1299 Configuration Protocol Option for Coordinate-based 1300 Location Configuration Information", RFC 3825, July 2004. 1302 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1303 "Indicating User Agent Capabilities in the Session 1304 Initiation Protocol (SIP)", RFC 3840, August 2004. 1306 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1307 Preferences for the Session Initiation Protocol (SIP)", 1308 RFC 3841, August 2004. 1310 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1311 Initiation Protocol (SIP)", RFC 3856, August 2004. 1313 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1314 Authenticated Identity Body (AIB) Format", RFC 3893, 1315 September 2004. 1317 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1318 Protocol (XMPP): Core", RFC 3920, October 2004. 1320 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1321 Rose, "DNS Security Introduction and Requirements", 1322 RFC 4033, March 2005. 1324 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1325 Format", RFC 4119, December 2005. 1327 18.2. Informative References 1329 [I-D.ietf-sipping-service-examples] 1330 Johnston, A., "Session Initiation Protocol Service 1331 Examples", draft-ietf-sipping-service-examples-10 (work in 1332 progress), March 2006. 1334 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1335 RFC 3966, December 2004. 1337 Authors' Addresses 1339 Brian Rosen 1340 NeuStar, Inc. 1341 470 Conrad Dr 1342 Mars, PA 16046 1343 US 1345 Email: br@brianrosen.net 1347 Henning Schulzrinne 1348 Columbia University 1349 Department of Computer Science 1350 450 Computer Science Building 1351 New York, NY 10027 1352 US 1354 Phone: +1 212 939 7042 1355 Email: hgs@cs.columbia.edu 1356 URI: http://www.cs.columbia.edu 1358 James Polk 1359 Cisco Systems 1360 3913 Treemont Circle 1361 Colleyville, Texas 76034 1362 US 1364 Phone: +1-817-271-3552 1365 Email: jmpolk@cisco.com 1367 Andrew Newton 1368 SunRocket 1369 8045 Leesburg Pike, Suite 300 1370 Vienna, VA 22182 1371 US 1373 Phone: +1 703 636 8052 1374 Email: andy@hxr.us 1376 Intellectual Property Statement 1378 The IETF takes no position regarding the validity or scope of any 1379 Intellectual Property Rights or other rights that might be claimed to 1380 pertain to the implementation or use of the technology described in 1381 this document or the extent to which any license under such rights 1382 might or might not be available; nor does it represent that it has 1383 made any independent effort to identify any such rights. Information 1384 on the procedures with respect to rights in RFC documents can be 1385 found in BCP 78 and BCP 79. 1387 Copies of IPR disclosures made to the IETF Secretariat and any 1388 assurances of licenses to be made available, or the result of an 1389 attempt made to obtain a general license or permission for the use of 1390 such proprietary rights by implementers or users of this 1391 specification can be obtained from the IETF on-line IPR repository at 1392 http://www.ietf.org/ipr. 1394 The IETF invites any interested party to bring to its attention any 1395 copyrights, patents or patent applications, or other proprietary 1396 rights that may cover technology that may be required to implement 1397 this standard. Please address the information to the IETF at 1398 ietf-ipr@ietf.org. 1400 Disclaimer of Validity 1402 This document and the information contained herein are provided on an 1403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1405 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1406 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1407 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1410 Copyright Statement 1412 Copyright (C) The Internet Society (2006). This document is subject 1413 to the rights, licenses and restrictions contained in BCP 78, and 1414 except as set forth therein, the authors retain all their rights. 1416 Acknowledgment 1418 Funding for the RFC Editor function is currently provided by the 1419 Internet Society.