idnits 2.17.1 draft-ietf-ecrit-car-crash-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 5, 2015) is 3087 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5031' is defined on line 1145, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-37 == Outdated reference: A later version (-27) exists of draft-ietf-ecrit-ecall-03 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Qualcomm Technologies, Inc 4 Intended status: Informational B. Rosen 5 Expires: May 8, 2016 NeuStar, Inc. 6 H. Tschofenig 7 (Individual) 8 November 5, 2015 10 Next-Generation Vehicle-Initiated Emergency Calls 11 draft-ietf-ecrit-car-crash-05.txt 13 Abstract 15 This document describes how to use IP-based emergency services 16 mechanisms to support the next generation of emergency calls placed 17 by vehicles (automatically in the event of a crash or serious 18 incident, or manually invoked by a vehicle occupant) and conveying 19 vehicle, sensor, and location data related to the crash or incident. 20 Such calls are often referred to as "Automatic Crash Notification" 21 (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the 22 case of manual trigger. The "Advanced" qualifier refers to the 23 ability to carry a richer set of data. 25 This document also registers a MIME Content Type and an Emergency 26 Call Additional Data Block for the vehicle, sensor, and location data 27 (often referred to as "crash data" even though there is not 28 necessarily a crash). An external specification for the data format, 29 contents, and structure are referenced in this document. 31 This document reuses the technical aspects of next-generation pan- 32 European eCall (a mandated and standardized system for emergency 33 calls by in-vehicle systems within Europe and other regions). 34 However, this document specifies a different set of vehicle (crash) 35 data, specifically, the Vehicle Emergency Data Set (VEDS) rather than 36 the eCall Minimum Set of Data (MSD). This document is an extension 37 of the eCall document, with the differences being that this document 38 makes the MSD data set optional and VEDS mandatory. This document 39 also discusses legacy (curcuit-switched) ACN systems and their 40 migration to next-generation emergency calling. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 8, 2016. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8 80 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9 81 6. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 13.1. MIME Content-type Registration for 90 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 22 91 13.2. Registration of the 'VEDS' entry in the Emergency Call 92 Additional Data registry . . . . . . . . . . . . . . . . 23 93 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 94 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 16. Changes from Previous Versions . . . . . . . . . . . . . . . 23 96 16.1. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 23 97 16.2. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 23 98 16.3. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 23 99 16.4. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 24 100 16.5. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 24 101 16.6. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 24 102 16.7. Changes from draft-gellens-01 to -02 . . . . . . . . . . 24 103 16.8. Changes from draft-gellens-00 to -01 . . . . . . . . . . 24 104 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 17.1. Normative References . . . . . . . . . . . . . . . . . . 24 106 17.2. Informative references . . . . . . . . . . . . . . . . . 26 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 109 1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 This document re-uses terminology defined in Section 3 of [RFC5012]. 117 Additionally, we use the following abbreviations: 119 +--------+----------------------------------------------------------+ 120 | Term | Expansion | 121 +--------+----------------------------------------------------------+ 122 | 3GPP | 3rd Generation Partnership Project | 123 | AACN | Advanced Automatic Crash Notification | 124 | ACN | Automatic Crash Notification | 125 | APCO | Association of Public-Safety Communications Officials | 126 | EENA | European Emergency Number Association | 127 | ESInet | Emergency Services IP network | 128 | GNSS | Global Satellite Navigation System (which includes the | 129 | | various such systems including the Global Positioning | 130 | | System or GPS) | 131 | IVS | In-Vehicle System | 132 | MNO | Mobile Network Operator | 133 | NENA | National Emergency Number Association | 134 | TSP | Telematics Service Provider | 135 | VEDS | Vehicle Emergency Data Set | 136 +--------+----------------------------------------------------------+ 138 2. Introduction 140 Emergency calls made by in-vehicle systems (e.g., in the event of a 141 crash) assist in significantly reducing road deaths and injuries by 142 allowing emergency services to respond quickly and often with better 143 location. 145 Drivers often have a poor location awareness, especially outside of 146 major cities, at night and when away from home (especially abroad). 147 In the most crucial cases, the victim(s) might not be able to call 148 because they have been injured or trapped. 150 For more than a decade, some vehicles have been equipped with 151 telematics systems that, among other features, place an emergency 152 call automatically in the event of a crash or manually in response to 153 an emergency call button. Such systems generally have on-board 154 location determination systems that make use of satellite-based 155 positioning technology, inertial sensors, gyroscopes, etc., to 156 provide a fairly accurate position for the vehicle. Such built-in 157 systems can take advantage of the benefits of being integrated into a 158 vehicle, such as more reliable power, ability to have larger or 159 specialized antenna, ability to be engineered to avoid or minimise 160 degradation by vehicle glass coatings, interference from other 161 vehicle systems, etc. Thus, the PSAP can be provided with a good 162 estimate of where the vehicle is during an emergency. Vehicle 163 manufacturers are increasingly adopting such systems, both for the 164 safety benefits and for the additional features and services they 165 enable (e.g., remote engine diagnostics, remote door unlock, stolen 166 vehicle tracking and disabling, etc.). 168 The general term for such systems is Automatic Crash Notification 169 (ACN) or "Advanced Automatic Crash Notification" (AACN). "ACN" is 170 used in this document as a general term. ACN systems transmit some 171 amount of data specific to the incident, referred to generally as 172 "crash data" (the term is commonly used even though there might not 173 have been a crash). While different systems transmit different 174 amounts of crash data, standardized formats, structures, and 175 mechanisms are needed to provide interoperability among systems and 176 PSAPs. 178 As of the date of this document, currently deployed in-vehicle 179 telematics systems are circuit-switched and lack a standards-based 180 ability to convey crash data directly to the PSAP (generally relying 181 on either a human call taker or an automated system to provide the 182 PSAP call taker with some crash data orally, or possibly a 183 proprietary mechanism). The PSAP call taker needs to first realize 184 that the call is related to a vehicle incident, and in most cases 185 must then listen to the data and transcribe it. 187 The transition to next-generation calling in general, and emergency 188 calling in particular, provides an opportunity to vastly improve the 189 scope, breadth, reliability and usefulness of crash data during an 190 emergency by allowing it to be presented alongside the call, and to 191 be automatically processed by the PSAP and made available to the call 192 taker in an integrated, automated way. In addition, vehicle 193 manufacturers are provided an opportunity to take advantage of the 194 same standardized mechanisms for data transmission for internal use 195 if they wish (such as telemetry between the vehicle and a service 196 center for both emergency and non-emergency uses, including location- 197 based services, multi-media entertainment systems, and road-side 198 assistance applications). 200 Next-generation ACN provides an opportunity for such calls to be 201 recognized and processed as such during call set-up, and optionally 202 routed to an upgraded PSAP where the vehicle data is available to 203 assist the call taker in assessing and responding to the situation. 205 An ACN call can be either occupant-initiated or automatically 206 triggered. (The "A" in "ACN" does stand for "Automatic," but the 207 term is often used to refer to the class of calls that are placed by 208 an in-vehicle system (IVS) and that carry incident-related data as 209 well as voice.) Automatically triggered calls indicate a car crash 210 or some other serious incident (e.g., a fire) and carry a greater 211 presumption of risk of injury. Manually triggered calls are often 212 reports of serious hazards (such as impaired drivers or roadway 213 debris) and might require different responses depending on the 214 situation. Manually triggered calls are also more likely to be false 215 (e.g., accidental) calls and so might be subject to different 216 operational handling by the PSAP. 218 This document describes how the IETF mechanisms for IP-based 219 emergency calls, including [RFC6443] and 220 [I-D.ietf-ecrit-additional-data], are used to provide the realization 221 of next-generation ACN. 223 This document reuses the technical aspects of next-generation pan- 224 European eCall (a mandated and standardized system for emergency 225 calls by in-vehicle systems within Europe and other regions), as 226 described in [I-D.ietf-ecrit-ecall]. However, this document 227 specifies a different set of vehicle (crash) data, specifically, the 228 Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set 229 of Data (MSD). This document is an extension of 230 [I-D.ietf-ecrit-ecall], with the differences being that this document 231 makes the MSD data set optional and VEDS mandatory. 233 The Association of Public-Safety Communications Officials (APCO) and 234 the National Emergency Number Association (NENA) have jointly 235 developed a standardized set of incident-related vehicle data for ACN 236 use, called the Vehicle Emergency Data Set (VEDS) [VEDS]. Such data 237 is often referred to as crash data although it is applicable in 238 incidents other than crashes. 240 VEDS provides a standard data set for the transmission, exchange, and 241 interpretation of vehicle-related data. A standard data format 242 allows the data to be generated by an IVS, and interpreted by PSAPs, 243 emergency responders, and medical facilities (including those capable 244 of providing trauma level patient care). It includes incident- 245 related information such as airbag deployment, location of the 246 vehicle, if the vehicle was involved in a rollover, various sensor 247 data that can indicate the potential severity of the crash and the 248 likelihood of severe injuries to the vehicle occupants, etc. This 249 data better informs the PSAP and emergency responders as to the type 250 of response that might be needed. This information was recently 251 included in the federal guidelines for field triage of injured 252 patients. These guidelines are designed to help responders at the 253 accident scene identify the potential existence of severe internal 254 injuries and to make critical decisions about how and where a patient 255 needs to be transported. 257 This document registers the 'application/EmergencyCallData.VEDS+xml' 258 MIME content-type, and registers the 'VEDS' entry in the Emergency 259 Call Additional Data registry. 261 VEDS is an XML structure (see [VEDS]). The 'application/ 262 EmergencyCallData.VEDS+xml' MIME content-type is used to identify it. 263 The 'VEDS' entry in the Emergency Call Additional Data registry is 264 used to construct a 'purpose' parameter value for conveying VEDS data 265 in a Call-Info header (as described in 266 [I-D.ietf-ecrit-additional-data]). 268 VEDS is a versatile structure that can accomodate varied needs. 269 However, if additional sets of data are determined to be needed 270 (e.g., in the future or in different regions), the steps to enable 271 each data block are very briefly summarized below: 273 o A standardized format and encoding (such as XML) is defined and 274 published by a Standards Development Organization (SDO) 276 o A MIME Content-Type is registered for it (typically under the 277 'Application' media type) with a sub-type starting with 278 'EmergencyCallData.' 280 o An entry for the block is added to the Emergency Call Additional 281 Data Blocks sub-registry (established by 282 [I-D.ietf-ecrit-additional-data]); the registry entry is the root 283 of the MIME sub-type (not including the 'EmergencyCallData' prefix 284 and any suffix such as '+xml') 286 A next-generation In-Vehicle System (IVS) transmits crash data by 287 encoding it in a standardized and registered format (such as VEDS) 288 and attaching it to an INVITE as a MIME body part. The body part is 289 identified by its MIME content-type (such as 'application/ 290 EmergencyCallData.VEDS+xml') in the Content-Type header field of the 291 body part. The body part is assigned a unique identifier which is 292 listed in a Content-ID header field in the body part. The INVITE is 293 marked as containing the crash data by adding a Call-Info header 294 field at the top level of the INVITE. This Call-Info header field 295 contains a CID URL referencing the body part's unique identifier, and 296 a 'purpose' parameter identifying the data as the crash data per the 297 registry entry; the 'purpose' parameter's value is 298 'EmergencyCallData.' and the root of the MIME type (the 299 'EmergencyCallData' prefix is not repeated), omitting any suffix such 300 as '+xml' (e.g., 'purpose=EmergencyCallData.VEDS'). 302 These mechanisms are thus used to place emergency calls that are 303 identifiable as ACN calls and that carry one or more standardized 304 crash data objects in an interoperable way. 306 3. Document Scope 308 This document is focused on the interface to the PSAP, that is, how 309 an ACN emergency call is setup and incident-related data (including 310 vehicle, sensor, and location data) is transmitted to the PSAP using 311 IETF specifications. (The goal is to re-use specifications rather 312 than to invent new.) For the direct model, this is the end-to-end 313 description (between the vehicle and the PSAP). For the TSP model, 314 this describes the right-hand side (between the TSP and the PSAP), 315 leaving the left-hand side (between the vehicle and the TSP) up to 316 the entities involved (i.e., IVS and TSP vendors) who are then free 317 to use the same mechanism as for the right-hand side (or not). 319 Note that while ACN systems in the U.S. and other regions are not 320 currently (as of the date of this document) mandated, Europe has a 321 mandated and standardized system for emergency calls by in-vehicle 322 systems. This pan-European system is known as "eCall" and is the 323 subject of a separate document, [I-D.ietf-ecrit-ecall], which this 324 document build on. Vehicles designed to operate in multiple regions 325 might need to support eCall as well as the ACN described here. If 326 other regions devise their own specifications or data formats, a 327 multi-region vehicle might need to support those as well. This 328 document adopts the call set-up and other technical aspects of 329 [I-D.ietf-ecrit-ecall], which uses [I-D.ietf-ecrit-additional-data], 330 which makes it easy to substitute a different data set while keeping 331 other technical aspects unchanged. Hence, both NG-eCall and the NG- 332 ACN mechanism described here are fully compatible, differing only in 333 the specific data block that is sent (the eCall MSD in the case of 334 NG-eCall, and the APCO/NENA VEDS used in this document). If other 335 regions adopt their own data set, this can be similarly accomodated 336 without changing other technical aspects. 338 4. Overview of Legacy Deployment Models 340 Legacy (circuit-switched) systems for placing emergency calls by in- 341 vehicle systems, including automatic crash notification systems, 342 generally have some ability to convey at least location and in some 343 cases telematics data to the PSAP. Most such systems use one of 344 three architectural models, which are described here as: "Telematics 345 Service Provider" (TSP), "direct", and "paired". These three models 346 are illustrated below. 348 In the TSP model, both emergency and non-emergency calls are placed 349 to a Telematics Service Provider (TSP); a proprietary technique is 350 used for data transfer (such as proprietary in-band modems) to the 351 TSP. 353 In an emergency, the TSP call taker bridges in the PSAP and 354 communicates location, crash data (such as impact severity and trauma 355 prediction), and other data (such as the vehicle description) to the 356 PSAP call taker verbally. Since the TSP knows the location of the 357 vehicle (from on-board GNSS), location-based routing is usually used 358 to route to the appropriate PSAP. In some cases, the TSP is able to 359 transmit location automatically, using similar techniques as for 360 wireless calls. Typically, a three-way voice call is established 361 between the vehicle, the TSP, and the PSAP, allowing communication 362 between the PSAP call taker, the TSP call taker, and the vehicle 363 occupants (who might be unconscious). 365 ///----\\\ proprietary +------+ 911 trunk +------+ 366 ||| IVS |||-------------->+ TSP +------------------>+ PSAP | 367 \\\----/// crash data +------+ +------+ 369 Figure 1: Legacy TSP Model. 371 In the paired model, the IVS uses a Bluetooth link with a previously- 372 paired handset to establish an emergency call with the PSAP (by 373 dialing a standard emergency number such as 9-1-1), and then 374 communicates location data to the PSAP via text-to-speech; crash data 375 might or might not be conveyed also using text-to-speech in an 376 initial voice greeting. Some such systems use an automated voice 377 prompt menu for the PSAP call taker (e.g., "this is an automatic 378 emergency call from a vehicle; press 1 to open a voice path to the 379 vehicle; press 2 to hear the location read out") to allow the call 380 taker to request location data via text-to-speech. 382 +---+ 383 ///----\\\ | H | 911/etc voice call via handset +------+ 384 ||| IVS |||-->| S +----------------------------------->+ PSAP | 385 \\\----/// +---+ location via text-to-speech +------+ 387 Figure 2: Legacy Paired Model 389 In the direct model, the IVS directly places an emergency call with 390 the PSAP by dialing a standard emergency number such as 9-1-1. Such 391 systems might communicate location data to the PSAP via text-to- 392 speech; crash data might or might not be conveyed using text-to- 393 speech in an initial voice greeting. Some such systems use an 394 automated voice prompt menu (e.g., "this is an automatic emergency 395 call from a vehicle; press 1 to open a voice path to the vehicle; 396 press 2 to hear the location read out") to allow the call taker to 397 request location data via text-to-speech. 399 ///----\\\ 911/etc voice call via IVS +------+ 400 ||| IVS |||---------------------------------------->+ PSAP | 401 \\\----/// location via text-to-speech +------+ 403 Figure 3: Legacy Direct Model 405 5. Migration to Next-Generation 407 Migration of emergency calls placed by in-vehicle systems to next- 408 generation (all-IP) technology provides a standardized mechanism to 409 identify such calls and to present crash data with the call, as well 410 as enabling additional communications modalities and enhanced 411 functionality. This allows ACN calls and crash data to be 412 automatically processed by the PSAP and made available to the call 413 taker in an integrated, automated way. Because the crash data is 414 carried in the initial SIP INVITE (per 415 [I-D.ietf-ecrit-additional-data]) the PSAP can present it to the call 416 taker simultaneously with the appearance of the call. 418 Migration to next-generation (NG) thus provides an opportunity to 419 significantly improve the handling and response to vehicle-initiated 420 emergency calls. Such calls can be recognized as originating from a 421 vehicle, routed to a PSAP equipped both technically and operationally 422 to handle such calls, and the vehicle-determined location and crash 423 data can be made available to the call taker simultaneously with the 424 call appearance. 426 Vehicle manufacturers using the TSP model can choose to take 427 advantage of the same mechanism to carry telematics data between the 428 vehicle and the TSP for both emergency and non-emergency calls as are 429 used to convey this data to the PSAP. 431 A next-generation IVS establishes an emergency call using the 432 emergency call solution as described in [RFC6443] and [RFC6881], with 433 the difference that the Request-URI indicates an ACN type of 434 emergency call and a Call-Info header field indicates that vehicle 435 crash data is attached. When an ESInet is deployed, the MNO only 436 needs to recognize the call as an emergency call and route it to an 437 ESInet. The ESInet can recognize the call as an ACN with vehicle 438 data and can route the call to an NG-ACN capable PSAP. Such a PSAP 439 can interpret the vehicle data sent with the call and make it 440 available to the call taker. 442 Because of the need to identify and specially process Next-Generation 443 ACN calls (as discussed above), [I-D.ietf-ecrit-ecall] registers new 444 service URN children within the "sos" subservice. These URNs provide 445 a mechanism by which an NG-ACN call is identified, and differentiate 446 between manually and automatically triggered NG-ACN calls, which 447 might be subject to different treatment depending on policy. (The 448 two service URNs registered in [I-D.ietf-ecrit-ecall] are 449 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual.) 451 Note that in North America, routing queries performed by clients 452 outside of an ESInet typically treat all sub-services of "sos" 453 identically to "sos" with no sub-service. However, the Request-URI 454 header field retains the full sub-service; route and handling 455 decisions within an ESInet or PSAP can take the sub-service into 456 account. For example, in a region with multiple cooperating PSAPs, 457 an NG-ACN call might be routed to a PSAP that is NG-ACN capable, or 458 one that specializes in vehicle-related incidents. 460 Migration of the three architectural models to next-generation (all- 461 IP) is described below. 463 In the TSP model, the IVS transmits crash and location data to the 464 TSP using either a protocol that is based on a proprietary design or 465 one that re-uses the mechanisms and data objects described here. In 466 an emergency, the TSP call taker bridges in the PSAP and the TSP 467 transmits crash and other data to the PSAP using the mechanisms and 468 data objects described here. There is a three-way call between the 469 vehicle, the TSP, and the PSAP, allowing communication between the 470 PSAP call taker, the TSP call taker, and the vehicle occupants (who 471 might be unconscious). 473 proprietary 474 ///----\\\ or standard +------+ standard +------+ 475 ||| IVS ||| ------------------->+ TSP +------------------->+ PSAP | 476 \\\----/// crash + other data +------+ crash + other data +------+ 478 Figure 4: Next-Generation TSP Model 480 The vehicle manufacturer and the TSP can choose to use the same 481 mechanisms and data objects to transmit crash and location data from 482 the vehicle to the TSP as are described here to transmit such data 483 from to the PSAP. 485 In the direct model, the IVS communicates crash data to the PSAP 486 directly using the mechanisms and data objects described here. 488 ///----\\\ NG emergency call +------+ 489 ||| IVS |||----------------------------------------->+ PSAP | 490 \\\----/// crash + other data +------+ 492 Figure 5: Next-Generation Direct Model 494 In the paired model, the IVS uses a Bluetooth link to a previously- 495 paired handset to establish an emergency call with the PSAP; it is 496 undefined what facilities are or will be available for transmitting 497 crash data through the Bluetooth link to the handset for inclusion in 498 an NG emergency call. Hence, manufacturers that use the paired model 499 for legacy calls might choose to adopt either the direct or TSP 500 models for next-generation calls. 502 +---+ 503 ///----\\\ (undefined) | H | standard +------+ 504 ||| IVS |||------------------>| S +------------------->+ PSAP | 505 \\\----/// (undefined) +---+ crash + other data +------+ 507 Figure 6: Next-Generation Paired Model 509 If the call is routed to a PSAP that is not capable of processing the 510 vehicle data, the PSAP ignores (or does not receive) the vehicle 511 data. This is detectable by the IVS or TSP when it receives a 200 OK 512 to the INVITE which lacks an eCall control structure acknowledging 513 receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or TSP then 514 proceeds as it would for a non-NG ACN call (e.g., verbal conveyance 515 of data) 517 6. Profile 519 In the context of emergncy calls placed by an in-vehicle system it is 520 assumed that the car is equipped with a built-in GNSS receiver. For 521 this reason only geodetic location information will be sent within an 522 emergency call. The following location shapes MUST be implemented: 523 2d and 3d Point (see Section 5.2.1 of [RFC5491]), Circle (see 524 Section 5.2.3 of [RFC5491]), and Ellipsoid (see Section 5.2.7 of 525 [RFC5491]). The coordinate reference systems (CRS) specified in 526 [RFC5491] are also mandatory for this document. The 527 element, as defined in [RFC5962] which indicates the direction of 528 travel of the vehicle, is important for dispatch and hence it MUST be 529 included in the PIDF-LO [RFC4119]. The element specified 530 in [RFC5962] MUST be implemented and MAY be included. 532 Calls by in-vehicle systems are placed via cellular networks, which 533 might ignore location sent by an originating device in an emergency 534 call INVITE, instead attaching their own location (often determined 535 in cooperation with the originating device). Standardized crash data 536 structures often include location as determined by the IVS. A 537 benefit of this is that it allows the PSAP to see both the location 538 as determined by the cellular network (often in cooperation with the 539 originating device) and the location as determined by the IVS. 541 This specification inherits the ability to utilize test call 542 functionality from Section 15 of [RFC6881]. 544 7. Call Setup 546 It is important that ACN calls be easily identifiable as such at all 547 stages of call handling, and that automatic versus manual triggering 548 be known. ACN calls differ from general emergency calls in several 549 aspects, including the presence of standardized crash data, the fact 550 that the call is known to be placed by an in-vehicle system (which 551 has implications for PSAP operational processes), and, especially for 552 automatic calls, information that can indicate a likelihood of severe 553 injury and hence need for trauma services. Knowledge that a call is 554 an ACN and further that it was automatically or manually invoked 555 carries a range of implications about the call, the circumstances, 556 and the vehicle occupants. Calls by in-vehicle systems can be 557 considered a specific sub-class of general emergency calls and are 558 optimally handled by a PSAP with the technical and operational 559 capabilities to serve such calls. (This is especially so in 560 environments such as the U.S. where there are many PSAPs and where 561 individual PSAPs have a range of capabilities.) Technical 562 capabilities include the ability to recognize and process 563 standardized crash data. Operational capabilities include training 564 and processes for assessing severe injury likelihood and responding 565 appropriately (e.g., dispatching trauma-capable medical responders or 566 those trained and equipped to extract occupants from crashed vehicles 567 and handle gasoline or other hazardous materials, transporting 568 victims to a trauma center, alerting the receiving facility, etc.). 570 Because ACN calls differ in significant ways from general emergency 571 calls, and because such calls typically generally are best handled by 572 PSAPs equipped technically to interpet and make use of crash data, 573 and operationally to handle emergency calls placed by in-vehicle 574 systems, [I-D.ietf-ecrit-ecall] registers SOS sub-services. Using a 575 sub-service allows the call to be treated as an amergency call and 576 makes it readily obvious that the call is an ACN; a further child 577 element distinguishes calls automatically placed due to a crash or 578 other serious incident (such as a fire) from those manually invoked 579 by a vehicle occupant (specifically, "SOS.ecall.automatic" and 580 "SOS.ecall.manual"). The distinction between automatic and manual 581 invocation is also significant; automatically triggered calls 582 indicate a car crash or some other serious incident (e.g., a fire) 583 and carry a greater presumption of risk of injury and hence need for 584 specific responders (such as trauma or fire). Manually triggered 585 calls are often reports of serious hazards (such as impaired drivers 586 or roadway debris) and might require different responses depending on 587 the situation. Manually triggered calls also have a greater chance 588 of being false (e.g., accidental) calls and might thus be subject to 589 different handling by the PSAP. 591 A next-generation In-Vehicle System (IVS) transmits crash data by 592 encoding it in a standardized and registered format and attaching it 593 to an INVITE as an additional data block as specified in Section 4.1 594 of [I-D.ietf-ecrit-additional-data]. As described in that document, 595 the block is identified by its MIME content-type, and pointed to by a 596 CID URL in a Call-Info header with a 'purpose' parameter value 597 corresponding to the block. 599 Specifically, the steps required during standardization are: 601 o A set of crash data is standardized by an SDO or appropriate 602 organization 604 o A MIME Content-Type for the crash data set is registered with IANA 606 * If the data is specifically for use in emergency calling, the 607 MIME type is normally under the 'application' type with a 608 subtype starting with 'EmergencyCallData.' 610 * If the data format is XML, then by convention the name has a 611 suffix of '+xml' 613 o The item is registered in the Emergency Call Additional Data 614 registry, as defined in Section 9.1.7 of 615 [I-D.ietf-ecrit-additional-data] 617 * For emergency-call-specific formats, the registered name is the 618 root of the MIME Content-Type (not including the 619 'EmergencyCallData' prefix and any suffix such as '+xml') as 620 described in Section 4.1 of [I-D.ietf-ecrit-additional-data] 622 When placing an emergency call: 624 o The crash data set is created and encoded per its specification 626 o The crash data set is attached to the emergency call INVITE as 627 specified in Section 4.1 of [I-D.ietf-ecrit-additional-data], that 628 is, as a MIME body part identified by its MIME Content-Type in the 629 body part's Content-Type header field 631 o The body part is assigned a unique identifier label in a Content- 632 ID header field of the body part 634 o A Call-Info header field at the top level of the INVITE is added 635 that references the crash data and identifies it by its MIME root 636 (as registered in the Emergency Call Additional Data registry) 638 * The crash data is referenced in the Call-Info header field by a 639 CID URL that contains the unique Content ID assigned to the 640 crash data body part 642 * The crash data is identified in the Call-Info header field by a 643 'purpose' parameter whose value is 'EmergencyCallData.' 644 concatenated with the specific crash data entry in the 645 Emergency Call Additional Data registry 647 * The Call-Info header field MAY be either solely to reference 648 the crash data (and hence have only the one URL) or can also 649 contain other URLs referencing other data 651 o Additional crash data sets MAY be included by following the same 652 steps 654 The Vehicle Emergency Data Set (VEDS) is an XML structure defined by 655 the Association of Public-Safety Communications Officials (APCO) and 656 the National Emergency Number Association (NENA) [VEDS]. The 657 'application/EmergencyCallData.VEDS+xml' MIME content-type is used to 658 identify it. The 'VEDS' entry in the Emergency Call Additional Data 659 registry is used to construct a 'purpose' parameter value for 660 conveying VEDS data in a Call-Info header. 662 The VEDS data is attached as a body part with MIME content type 663 'application/EmergencyCallData.VEDS+xml' which is pointed at by a 664 Call-Info URL of type CID with a 'purpose' parameter of 665 'EmergencyCallData.VEDS'. 667 Entities along the path between the vehicle and the PSAP are able to 668 identify the call as an ACN call and handle it appropriately. The 669 PSAP is able to identify the crash data as well as any other 670 additional data attached to the INVITE by examining the Call-Info 671 header fields for 'purpose' parameters whose values start with 672 'EmergencyCallData.' The PSAP is able to access and the data it is 673 capable of handling and is interested in by checking the 'purpose' 674 parameter values. 676 This document extends [I-D.ietf-ecrit-ecall] by reusing the call set- 677 up and other normative requirements except that in this document, 678 support for the eCall MSD is OPTIONAL and support for VEDS in 679 REQUIRED. 681 8. Call Routing 683 An Emergency Services IP Network (ESInet) is a network operated by or 684 on behalf of emergency services authorities. It handles emergency 685 call routing and processing before delivery to a PSAP. In the 686 NG9-1-1 architecture adopted by NENA as well as the NG1-1-2 687 architecture adopted by EENA, each PSAP is connected to one or more 688 ESInets. Each originating network is also connected to one or more 689 ESInets. The ESInets maintain policy-based routing rules which 690 control the routing and processing of emergency calls. The 691 centralization of such rules within ESInets provides for a cleaner 692 separation between the responsibilities of the originating network 693 and that of the emergency services network, and provides greater 694 flexibility and control over processing of emergency calls by the 695 emergency services authorities. This makes it easier to react 696 quickly to unusual situations that require changes in how emergency 697 calls are routed or handled (e.g., a natural disaster closes a PSAP), 698 as well as ease in making long-term changes that affect such routing 699 (e.g., cooperative agreements to specially handle calls requiring 700 translation or relay services). 702 In an environment that uses ESInets, the originating network need 703 only detect that the service URN of an emergency call is or starts 704 with "sos", passing all types of emergency calls to an ESInet. The 705 ESInet is then responsible for routing such calls to an appropriate 706 PSAP. In an environment without an ESInet, the emergency services 707 authorities and the originating carriers would need to determine how 708 such calls are routed. 710 9. Test Calls 712 This document builds on [I-D.ietf-ecrit-ecall], which inherits the 713 ability to utilize test call functionality from Section 15 of 714 [RFC6881]. 716 A service URN starting with "test." indicates a request for an 717 automated test. Per [I-D.ietf-ecrit-ecall], 718 "urn:service:test.sos.ecall.automatic" indicates such a test feature. 719 This functionality is defined in [RFC6881]. 721 Note that since test calls are placed using "test" as the parent 722 service URN and "sos" as a child, such calls are not treated as an 723 emergency call and so some functionality will not apply (such as 724 preemption or service availability for devices lacking service ("non- 725 service-initialized" or "NSI") if those are available for emergency 726 calls); this is by design. MNOs can recognize test calls and treat 727 them in a way that tests as much functionality as desired, but this 728 is outside the scope of this document. 730 10. Example 732 Figure 7 shows an emergency call placed by a vehicle whereby location 733 information and VEDS crash data are both attached to the SIP INVITE 734 message. The INVITE has a request URI containing the 735 'urn:service:sos.ecall.automatic' service URN and is thus recognized 736 as an ACN type of emergency call, and is also recognizable as an 737 emergency call because the request URI starts with 'urn:service:sos'. 738 The mobile network operator (MNO) routes the call to an Emergency 739 services IP Network (ESInet), as for any emergency call. The ESInet 740 processes the call as an ACN and routes the call to an appropriate 741 ACN-capable PSAP (using location information and the fact that that 742 it is an ACN). The call is processed by the Emergency Services 743 Routing Proxy (ESRP), as the entry point to the ESInet. The ESRP 744 routes the call to an appropriate ACN-capable PSAP, where the call is 745 received by a call taker. (In deployments where there is no ESInet, 746 the MNO itself routes the call directly to an appropriate ACN-capable 747 PSAP.) 748 +---------------------------------------+ 749 | | 750 +------------+ | +-------+ | 751 | | | | PSAP2 | | 752 | | | +-------+ | 753 | Originating| | | 754 | Mobile | | +------+ +-------+ | 755 Vehicle-->| Network |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 756 | | | +------+ +-------+ | 757 | | | | 758 +------------+ | +-------+ | 759 | | PSAP3 | | 760 | +-------+ | 761 | | 762 | | 763 | | 764 | ESInet | 765 +---------------------------------------+ 767 Figure 7: Example of Vehicle-Placed Emergency Call Message Flow 769 The example, shown in Figure 8, illustrates a SIP emergency call 770 INVITE that is being conveyed with location information (a PIDF-LO) 771 and crash data (as VEDS data). 773 The example VEDS data structure shows information about about a 774 crashed vehicle. The example communicates that the car is a model 775 year 2015 Saab 9-5 (a car which does not exist). The front airbag 776 deployed as a consequence of the crash. The 777 'VehicleBodyCategoryCode' indicates that the crashed vehicle is a 778 passenger car (the code is set to '101') and that it is not a 779 convertible (the 'ConvertibleIndicator' value is set to 'false'). 781 The 'VehicleCrashPulse' element provides further information about 782 the crash, namely that the force of impact based on the change in 783 velocity over the duration of the crash pulse was 100 MPH. The 784 principal direction of the force of the impact is set to '12' (which 785 refers to 12 O'Clock, corresponding to a frontal collision). This 786 value is described in the 'CrashPulsePrincipalDirectionOfForceValue' 787 element. 789 The 'CrashPulseRolloverQuarterTurnsValue' indicates the number of 790 quarter turns in concert with a rollover expressed as a number; in 791 our case 1. 793 No roll bar was deployed, as indicated in 794 'VehicleRollbarDeployedIndicator' being set to 'false'. 796 Next, there is information indicating seatbelt and seat sensor data 797 for individual seat positions in the vehicle. In our example, 798 information from the driver seat is available (value '1' in the 799 'VehicleSeatLocationCategoryCode' element), that the seatbelt was 800 monitored ('VehicleSeatbeltMonitoredIndicator' element), that the 801 seatbelt was fastened ('VehicleSeatbeltFastenedIndicator' element) 802 and the seat sensor determined that the seat is occupied 803 ('VehicleSeatOccupiedIndicator' element). 805 Finally, information about the weight of the vehicle, which is 600 806 kilogram in our example. 808 In addition to the information about the vehicle, further indications 809 are provided, namely the presence of fuel leakage 810 ('FuelLeakingIndicator' element), an indication whether the vehicle 811 was subjected to multiple impacts ('MultipleImpactsIndicator' 812 element), the orientation of the vehicle at final rest 813 ('VehicleFinalRestOrientationCategoryCode' element) and an indication 814 that there are no parts of the vehicle on fire (the 815 'VehicleFireIndicator' element). 817 INVITE urn:service:sos.ecall.automatic SIP/2.0 818 To: urn:service:sos.ecall.automatic 819 From: ;tag=9fxced76sl 820 Call-ID: 3848276298220188511@atlanta.example.com 821 Geolocation: 822 Geolocation-Routing: no 823 Call-Info: cid:1234567890@atlanta.example.com; 824 purpose=EmergencyCallData.VEDS 825 Accept: application/sdp, application/pidf+xml 826 CSeq: 31862 INVITE 827 Content-Type: multipart/mixed; boundary=boundary1 828 Content-Length: ... 830 --boundary1 831 Content-Type: application/sdp 833 ...Session Description Protocol (SDP) goes here 835 --boundary1 836 Content-Type: application/pidf+xml 837 Content-ID: 839 840 848 849 850 851 852 -34.407 150.883 853 854 855 278 856 857 858 859 860 gps 861 862 2012-04-5T10:18:29Z 863 1M8GDM9A_KP042788 864 865 867 --boundary1 868 Content-Type: application/EmergencyCallData.VEDS+xml 869 Content-ID: 1234567890@atlanta.example.com 870 Content-Disposition: by-reference;handling=optional 872 873 877 878 879 Saab 880 881 882 9-5 883 884 886 2015 887 888 889 FRONT 890 true 891 893 894 false 895 MAIN 896 898 101 899 900 901 902 904 100 905 906 908 MPH 909 910 12 911 912 1 913 914 915 false 916 917 918 1 919 920 true 921 922 true 923 924 true 925 926 927 929 931 600 932 933 935 kilogram 936 937 938 939 true 940 false 941 true 942 Driver 943 944 false 945 946 948 --boundary1-- 950 Figure 8: SIP INVITE indicating a Vehicule-Initated Emergency Call 952 11. Security Considerations 954 Since this document relies on [I-D.ietf-ecrit-ecall] and 955 [I-D.ietf-ecrit-additional-data], the security considerations 956 described there and in [RFC5069] apply here. Implementors are 957 strongly cautioned to read and understand the discussion in those 958 documents. 960 As with emergency service systems where location data is supplied or 961 determined with the assistance of an end host, there is the 962 possibility that that location is incorrect, either intentially (in 963 case of an a denial of service attack against the emergency services 964 infrastructure) or due to a malfunctioning device. The reader is 965 referred to [RFC7378] for a discussion of some of these 966 vulnerabilities. 968 12. Privacy Considerations 970 Since this document builds on [I-D.ietf-ecrit-ecall], which itself 971 builds on [I-D.ietf-ecrit-additional-data], the data structures 972 specified there, and the corresponding privacy considerations 973 discussed there, apply here as well. The VEDS data structure 974 contains optional elements that can carry identifying and personal 975 information, both about the vehicle and about the owner, as well as 976 location information, and so needs to be protected against 977 unauthorized disclosure, as discussed in 978 [I-D.ietf-ecrit-additional-data]. Local regulations may impose 979 additional privacy protection requirements. 981 13. IANA Considerations 982 13.1. MIME Content-type Registration for 'application/ 983 EmergencyCall.VEDS+xml' 985 This specification requests the registration of a new MIME type 986 according to the procedures of RFC 4288 [RFC4288] and guidelines in 987 RFC 3023 [RFC3023]. 989 MIME media type name: application 991 MIME subtype name: EmergencyCallData.VEDS+xml 993 Mandatory parameters: none 995 Optional parameters: charset 997 Indicates the character encoding of enclosed XML. 999 Encoding considerations: Uses XML, which can employ 8-bit 1000 characters, depending on the character encoding used. See 1001 Section 3.2 of RFC 3023 [RFC3023]. 1003 Security considerations: 1005 This content type is designed to carry vehicle crash data 1006 during an emergency call. 1008 This data can contain personal information including vehicle 1009 VIN, location, direction, etc. Appropriate precautions need to 1010 be taken to limit unauthorized access, inappropriate disclosure 1011 to third parties, and eavesdropping of this information. 1012 Please refer to Section 7 and Section 8 of 1013 [I-D.ietf-ecrit-additional-data] for more information. 1015 Interoperability considerations: None 1017 Published specification: [VEDS] 1019 Applications which use this media type: Emergency Services 1021 Additional information: None 1023 Magic Number: None 1025 File Extension: .xml 1027 Macintosh file type code: 'TEXT' 1028 Person and email address for further information: Hannes 1029 Tschofenig, Hannes.Tschofenig@gmx.net 1031 Intended usage: LIMITED USE 1033 Author: This specification is a work item of the IETF ECRIT 1034 working group, with mailing list address . 1036 Change controller: The IESG 1038 13.2. Registration of the 'VEDS' entry in the Emergency Call Additional 1039 Data registry 1041 This specification requests IANA to add the 'VEDS' entry to the 1042 Emergency Call Additional Data registry, with a reference to this 1043 document. The Emergency Call Additional Data registry has been 1044 established by [I-D.ietf-ecrit-additional-data]. 1046 14. Contributors 1048 We would like to thank Ulrich Dietz for his help with earlier 1049 versions of the original version of this document. 1051 15. Acknowledgements 1053 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 1054 Wes George, and Gunnar Hellstrom for their feedback. 1056 16. Changes from Previous Versions 1058 16.1. Changes from draft-ietf-04 to draft-ietf-05 1060 o Reworded security text in main document and in MIME registration 1061 for the VEDS object 1063 16.2. Changes from draft-ietf-03 to draft-ietf-04 1065 o Added example VEDS object 1066 o Additional clarifications and corrections 1067 o Removed references from Abstract 1068 o Moved Document Scope section to follow Introduction 1070 16.3. Changes from draft-ietf-02 to draft-ietf-03 1072 o Additional clarifications and corrections 1074 16.4. Changes from draft-ietf-01 to draft-ietf-02 1076 o This document now refers to [I-D.ietf-ecrit-ecall] for technical 1077 aspects including the service URN; this document no longer 1078 proposes a unique service URN for non-eCall NG-ACN calls; the same 1079 service URN is now used for all NG-ACN calls including NG-eCall 1080 and non-eCall 1081 o Added discussion of an NG-ACN call placed to a PSAP that doesn't 1082 support it 1083 o Minor wording improvements and clarifications 1085 16.5. Changes from draft-ietf-00 to draft-ietf-01 1087 o Added further discussion of test calls 1088 o Added further clarification to the document scope 1089 o Mentioned that multi-region vehicles may need to support other 1090 crash notification specifications such as eCall 1091 o Minor wording improvements and clarifications 1093 16.6. Changes from draft-gellens-02 to draft-ietf-00 1095 o Renamed from draft-gellens- to draft-ietf- 1096 o Added text to Introduction to clarify that during a CS ACN, the 1097 PSAP call taker usually needs to listen to the data and transcribe 1098 it 1100 16.7. Changes from draft-gellens-01 to -02 1102 o Fixed case of 'EmergencyCallData', in accordance with changes to 1103 [I-D.ietf-ecrit-additional-data] 1105 16.8. Changes from draft-gellens-00 to -01 1107 o Now using 'EmergencyCallData' for purpose parameter values and 1108 MIME subtypes, in accordance with changes to 1109 [I-D.ietf-ecrit-additional-data] 1110 o Added reference to RFC 6443 1111 o Fixed bug that caused Figure captions to not appear 1113 17. References 1115 17.1. Normative References 1117 [I-D.ietf-ecrit-additional-data] 1118 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1119 J. Winterbottom, "Additional Data Related to an Emergency 1120 Call", draft-ietf-ecrit-additional-data-37 (work in 1121 progress), October 2015. 1123 [I-D.ietf-ecrit-ecall] 1124 Gellens, R. and H. Tschofenig, "Next-Generation Pan- 1125 European eCall", draft-ietf-ecrit-ecall-03 (work in 1126 progress), July 2015. 1128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1129 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1130 RFC2119, March 1997, 1131 . 1133 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1134 Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, 1135 . 1137 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1138 Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, 1139 . 1141 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1142 Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, 1143 December 2005, . 1145 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1146 Emergency and Other Well-Known Services", RFC 5031, DOI 1147 10.17487/RFC5031, January 2008, 1148 . 1150 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1151 Presence Information Data Format Location Object (PIDF-LO) 1152 Usage Clarification, Considerations, and Recommendations", 1153 RFC 5491, DOI 10.17487/RFC5491, March 2009, 1154 . 1156 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 1157 Thomson, "Dynamic Extensions to the Presence Information 1158 Data Format Location Object (PIDF-LO)", RFC 5962, DOI 1159 10.17487/RFC5962, September 2010, 1160 . 1162 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1163 "Framework for Emergency Calling Using Internet 1164 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1165 2011, . 1167 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1168 Communications Services in Support of Emergency Calling", 1169 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1170 . 1172 [VEDS] "Vehicular Emergency Data Set (VEDS) version 3", July 1173 2012, . 1176 17.2. Informative references 1178 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1179 Emergency Context Resolution with Internet Technologies", 1180 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1181 . 1183 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1184 Shanmugam, "Security Threats and Requirements for 1185 Emergency Call Marking and Mapping", RFC 5069, DOI 1186 10.17487/RFC5069, January 2008, 1187 . 1189 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1190 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1191 December 2014, . 1193 Authors' Addresses 1195 Randall Gellens 1196 Qualcomm Technologies, Inc 1197 5775 Morehouse Drive 1198 San Diego 92651 1199 US 1201 Email: rg+ietf@randy.pensive.org 1203 Brian Rosen 1204 NeuStar, Inc. 1205 470 Conrad Dr 1206 Mars, PA 16046 1207 US 1209 Email: br@brianrosen.net 1211 Hannes Tschofenig 1212 (Individual) 1214 Email: Hannes.Tschofenig@gmx.net 1215 URI: http://www.tschofenig.priv.at