idnits 2.17.00 (12 Aug 2021) /tmp/idnits64111/draft-ietf-ecrit-ecall-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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 2388 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-ecrit-additional-data - is the name correct? ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 H. Tschofenig 5 Expires: May 8, 2016 (Individual) 6 November 5, 2015 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-05.txt 11 Abstract 13 This document describes how to use IP-based emergency services 14 mechanisms to support the next generation of the Pan European in- 15 vehicle emergency call service defined under the eSafety initiative 16 of the European Commission (generally referred to as "eCall"). eCall 17 is a standardized and mandated system for a special form of emergency 18 calls placed by vehicles. eCall deployment is required in the very 19 near future in European Union member states, and eCall (and eCall- 20 compatible systems) are also being deployed in other regions. eCall 21 provides an integrated voice path and a standardized set of vehicle, 22 sensor (e.g., crash related), and location data. An eCall is 23 recognized and handled as a specialized form of emergency call and is 24 routed to a specialized eCall-capable Public Safety Answering Point 25 (PSAP) capable of processing the vehicle data and trained in handling 26 emergency calls from vehicles. 28 Currently, eCall functions over circuit-switched cellular telephony; 29 work on next-generation eCall (NG-eCall, sometimes called packet- 30 switched eCall or PS-eCall) is now in process, and this document 31 assists in that work by describing how to support eCall within the 32 IP-based emergency services infrastructure. 34 This document also registers a MIME Content Type and an Emergency 35 Call Additional Data Block for the eCall vehicle data. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 8, 2016. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 75 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10 81 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11 82 9.1.1. The element . . . . . . . . . . . . . . . . . . 12 83 9.1.1.1. Attributes of the element . . . . . . . . . 13 84 9.1.1.2. Child Elements of the element . . . . . . . 13 85 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14 86 9.1.2. The element . . . . . . . . . . . . . 15 87 9.1.2.1. Child Elements of the element . . 15 88 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16 89 9.1.3. The element . . . . . . . . . . . . . . . . 17 90 9.1.3.1. Attributes of the element . . . . . . . 17 91 9.1.3.2. Child Elements of the element . . . . . 19 92 9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19 93 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 20 94 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 97 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 99 14.1. Service URN Registrations . . . . . . . . . . . . . . . 30 100 14.2. MIME Content-type Registration for 101 'application/emergencyCallData.eCall.MSD+xml' . . . . . 30 102 14.3. MIME Content-type Registration for 103 'application/emergencyCallData.eCall.control+xml' . . . 32 104 14.4. Registration of the 'eCall.MSD' entry in the Emergency 105 Call Additional Data Blocks registry . . . . . . . . . . 33 106 14.5. Registration of the 'eCall.control' entry in the 107 Emergency Call Additional Data Blocks registry . . . . . 34 108 14.6. Registration of the emergencyCallData.eCall Info Package 34 109 14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34 110 14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34 111 14.7.2. Registration for 112 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 35 113 14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 114 14.8.1. eCall Control Action Registry . . . . . . . . . . . 35 115 14.8.2. eCall Static Message Registry . . . . . . . . . . . 36 116 14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37 117 14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 38 118 14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 39 119 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 120 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 121 17. Changes from Previous Versions . . . . . . . . . . . . . . . 40 122 17.1. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40 123 17.2. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40 124 17.3. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41 125 17.4. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41 126 17.5. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41 127 17.6. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41 128 17.7. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42 129 17.8. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42 130 17.9. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42 131 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 132 18.1. Normative References . . . . . . . . . . . . . . . . . . 42 133 18.2. Informative references . . . . . . . . . . . . . . . . . 43 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 136 1. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 This document re-uses terminology defined in Section 3 of [RFC5012]. 144 Additionally, we use the following abbreviations: 146 +--------+----------------------------------------+ 147 | Term | Expansion | 148 +--------+----------------------------------------+ 149 | 3GPP | 3rd Generation Partnership Project | 150 | CEN | European Committee for Standardization | 151 | EENA | European Emergency Number Association | 152 | ESInet | Emergency Services IP network | 153 | IMS | IP Multimedia Subsystem | 154 | IVS | In-Vehicle System | 155 | MNO | Mobile Network Operator | 156 | MSD | Minimum Set of Data | 157 | PSAP | Public Safety Answering Point | 158 +--------+----------------------------------------+ 160 2. Document Scope 162 This document is limited to the signaling, data exchange, and 163 protocol needs of next-generation eCall (NG-eCall, also referred to 164 as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP 165 framework for emergency calls, as described in [RFC6443] and 166 [RFC6881]. eCall itself is specified by 3GPP and CEN and these 167 specifications include far greater scope than is covered here. 169 The eCall service operates over cellular wireless communication, but 170 this document does not address cellular-specific details, nor client 171 domain selection (e.g., circuit-switched versus packet-switched). 172 All such aspects are the purview of their respective standards 173 bodies. The scope of this document is limited to eCall operating 174 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 176 The technical contents of this document can be suitable for use in 177 other vehicle-initiated emergency call systems, but this is out of 178 scope for this document. 180 Vehicles designed for multiple regions might need to support eCall 181 and other Advanced Automatic Crash Notification (AACN) systems, such 182 as described in [I-D.ietf-ecrit-car-crash]. That system is 183 compatible with eCall, differing primarily in the specific data set 184 that is sent. 186 3. Introduction 188 Emergency calls made from vehicles (e.g., in the event of a crash) 189 assist in significantly reducing road deaths and injuries by allowing 190 emergency services to be aware of the incident, the state of the 191 vehicle, the location of the vehicle, and to have a voice channel 192 with the vehicle occupants. This enables a quick and appropriate 193 response. 195 The European Commission initiative of eCall was conceived in the late 196 1990s, and has evolved to a European Parliament decision requiring 197 the implementation of compliant in-vehicle systems (IVS) in new 198 vehicles and the deployment of eCall in the European Member States in 199 the very near future. eCall (and eCall-compatible systems) are also 200 being adopted in other regions. 202 The pan-European eCall system provides a standardized and mandated 203 mechanism for emergency calls by vehicles. eCall establishes 204 procedures for such calls to be placed by in-vehicle systems, 205 recognized and processed by the network, and routed to a specialized 206 PSAP where the vehicle data is available to assist the call taker in 207 assessing and responding to the situation. eCall provides a standard 208 set of vehicle, sensor (e.g., crash related), and location data. 210 An eCall can be either user-initiated or automatically triggered. 211 Automatically triggered eCalls indicate a car crash or some other 212 serious incident and carry a greater presumption of risk of injury. 213 Manually triggered eCalls might be reports of serious hazards and are 214 likely to require a different response than an automatically 215 triggered eCall. Manually triggered eCalls are also more likely to 216 be false (e.g., accidental) calls and so might be subject to 217 different operational handling by the PSAP. 219 Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) 220 as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in 221 the call setup mark the call as an eCall, and further indicate if the 222 call was automatically or manually triggered. The call is routed to 223 an eCall-capable PSAP, a voice channel is established between the 224 vehicle and the PSAP, and an eCall in-band modem is used to carry a 225 defined set of vehicle, sensor (e.g., crash related), and location 226 data (the Minimum Set of Data or MSD) within the voice channel. The 227 same in-band mechanism is used for the PSAP to acknowledge successful 228 receipt of the MSD, and to request the vehicle to send a new MSD 229 (e.g., to check if the state of or location of the vehicle or its 230 occupants has changed). Work on next-generation eCall (NG-eCall, 231 also referred to as packet-switched eCall or PS eCall) is now in 232 process. As part of this work, the European Telecommunications 233 Standards Institute (ETSI) [SDO-ETSI] has published a Technical 234 Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] 235 that presents findings and recommendations regarding support for 236 eCall in an all-IP environment. NG-eCall moves from circuit switched 237 to all-IP, and carries the vehicle data and other eCall-specific data 238 as additional data associated with the call. This document describes 239 how IETF mechanisms for IP-based emergency calls, including [RFC6443] 240 and [I-D.ietf-ecrit-additional-data] are used to provide the 241 signaling and data exchange of the next generation of pan-European 242 eCall. 244 The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency 245 calling with additional elements identifying the call as an eCall and 246 as carrying eCall data and with mechanisms for carrying the data. 247 3GPP IMS emergency services support multimedia, providing the ability 248 to carry voice, text, and video. This capability is referred to 249 within 3GPP as Multimedia Emergency Services (MMES). 251 A transition period will exist during which time the various entities 252 involved in initiating and handling an eCall might support next- 253 generation eCall, legacy eCall, or both. This transition period 254 might last several years or longer. The issue of migration/co- 255 existence during the transition period is very important but is 256 outside the scope of this document. The ETSI TR "Mobile Standards 257 Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in 258 Clause 7. 260 4. eCall Requirements 262 Overall eCall requirements are specified by CEN in [EN_16072] and by 263 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements specific to 264 vehicle data are contained in EN 15722 [msd]. For convenience, the 265 requirements most applicable to the limited scope of this document 266 are summarized very briefly below. 268 eCall requires: 270 o The call be recognized as an eCall (which is inherently an 271 emergency call) 272 o The call setup indicates if the call was manually or automatically 273 triggered 274 o A voice channel between the vehicle and the PSAP 275 o Carrying the MSD intrinsically with the call (the MSD needs to be 276 available to the same call-taker as the voice) 277 o The ability for the PSAP to acknowledge receipt of the MSD 278 o The ability for the PSAP to request that the vehicle generate and 279 transmit a new MSD 280 o The ability of the PSAP to be able to re-contact the occupants of 281 vehicle after the initial eCall is concluded 282 o The ability to perform a test call (which can be routed to a PSAP 283 but is not treated as an emergency call and not handled by a call 284 taker) 286 It is recognized that NG-eCall offers many potential enhancements, 287 although these are not required by current EU regulations. For 288 convenience, the enhancements most applicable to the limited scope of 289 this document are summarized very briefly below. 291 NG-eCall is expected to offer: 293 o The ability to carry more data (e.g., an enhanced MSD or an MSD 294 plus additional sets of data) 295 o The ability to handle video 296 o The ability to handle text 297 o The ability for the PSAP to access vehicle components (e.g., an 298 onboard camera (such as rear facing or blind-spot cameras) for a 299 visual assessment of the crash site situation) 300 o The ability for the PSAP to request the vehicle to take actions 301 (e.g., sound the horn, disable the ignition, lock/unlock doors) 302 o The ability to avoid audio muting of the voice channel (because 303 the MSD is not transferred using an in-band modem) 305 5. Vehicle Data 307 Pan-European eCall provides a standardized and mandated set of 308 vehicle related data, known as the Minimum Set of Data (MSD). The 309 European Committee for Standardization (CEN) has specified this data 310 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 311 MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML 312 encoding is better suited for use in SIP messages and is used in this 313 document. (The ASN.1 encoding is specified in Annex A of EN 15722 314 [msd], while the XML encoding is specified in Annex C.) 316 The "Additional Data related to an Emergency Call" document 317 [I-D.ietf-ecrit-additional-data] establishes a general mechanism for 318 attaching blocks of data to a SIP emergency call. This document 319 makes use of that mechanism to carry the eCall MSD in a SIP emergency 320 call. 322 This document registers the 'application/ 323 emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD 324 to be carried in SIP. This document also adds the 'eCall.MSD' entry 325 to the Emergency Call Additional Data Blocks registry (established by 326 [I-D.ietf-ecrit-additional-data]) to enable the MSD to be recognized 327 as such in a SIP-based eCall emergency call. 329 Note that if additional data sets are defined and registered (e.g., 330 in the future or in other regions) and transmitted using the same 331 mechanisms, the size and frequency of transmission during a session 332 needs to be evaluated to be sure it is appropriate to use the 333 signaling channel. 335 6. Call Setup 337 In circuit-switched eCall, the IVS places a special form of a 112 338 emergency call which carries an eCall flag (indicating that the call 339 is an eCall and also if the call was manually or automatically 340 triggered); the mobile network operator (MNO) recognizes the eCall 341 flag and routes the call to an eCall-capable PSAP; vehicle data is 342 transmitted to the PSAP via the eCall in-band modem (in the voice 343 channel). 345 ///----\\\ 112 voice call with eCall flag +------+ 346 ||| IVS |||---------------------------------------->+ PSAP | 347 \\\----/// vehicle data via eCall in-band modem +------+ 349 Figure 1: circuit-switched eCall 351 An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD 352 in accordance with [I-D.ietf-ecrit-additional-data] by encoding it as 353 specified (per Appendix C of EN 15722 [msd]) and attaching it to an 354 INVITE as a MIME body part. The body part is identified by its MIME 355 content-type ('application/emergencyCallData.eCall.MSD+xml') in the 356 Content-Type header field of the body part. The body part is 357 assigned a unique identifier which is listed in a Content-ID header 358 field in the body part. The INVITE is marked as containing the MSD 359 by adding (or appending to) a Call-Info header field at the top level 360 of the INVITE. This Call-Info header field contains a CID URL 361 referencing the body part's unique identifier, and a 'purpose' 362 parameter identifying the data as the eCall MSD per the registry 363 entry; the 'purpose' parameter's value is 'emergencyCallData.' and 364 the root of the MIME type (not including the 'emergencyCallData' 365 prefix and any suffix such as '+xml' (e.g., 366 'purpose=emergencyCallData.eCall.MSD'). 368 For NG-eCall, the IVS establishes an emergency call using the 3GPP 369 IMS solution with a Request-URI indicating an eCall type of emergency 370 call and with vehicle data attached; the MNO or ESInet recognizes the 371 eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP 372 interpets the vehicle data sent with the call and makes it available 373 to the call taker. 375 ///----\\\ IMS emergency call with eCall URN +------+ 376 IVS ----------------------------------------->+ PSAP | 377 \\\----/// vehicle data included in call setup +------+ 379 Figure 2: NG-eCall 381 This document registers new service URN children within the "sos" 382 subservice. These URNs provide the mechanism by which an eCall is 383 identified, and differentiate between manually and automatically 384 triggered eCalls (which can be subject to different treatment, 385 depending on policy). The two service URNs are: 386 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 388 7. Call Routing 390 The routing rules for eCalls are likely to differ from those of other 391 emergency calls because eCalls are special types of emergency calls 392 (with implications for the types of response required) and need to be 393 handled by specially designated PSAPs. In an environment that uses 394 ESInets, the originating network passes all types of emergency calls 395 to an ESInet (which have a request URI containing the "SOS" service 396 URN). The ESInet is then responsible for routing such calls to the 397 appropriate PSAP. In an environment without an ESInet, the emergency 398 services authorities and the originating network jointly determine 399 how such calls are routed. 401 7.1. ESInets 403 This section provides background information on ESInets for 404 information only. 406 An Emergency Services IP Network (ESInet) is a network operated by 407 emergency services authorities. It handles emergency call routing 408 and processing before delivery to a PSAP. In the NG1-1-2 409 architecture adopted by EENA, each PSAP is connected to one or more 410 ESInets. Each originating network is also connected to one or more 411 ESInets. The ESInets maintain policy-based routing rules which 412 control the routing and processing of emergency calls. The 413 centralization of such rules within ESInets provides for a cleaner 414 separation between the responsibilities of the originating network 415 and that of the emergency services network, and provides greater 416 flexibility and control over processing of emergency calls by the 417 emergency services authorities. This makes it easier to react 418 quickly to unusual situations that require changes in how emergency 419 calls are routed or handled (e.g., a natural disaster closes a PSAP), 420 as well as ease in making long-term changes that affect such routing 421 (e.g., cooperative agreements to specially handle calls requiring 422 translation or relay services). ESInets might support the ability to 423 interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that 424 are not IP PSAPs (similarly to the ability to interwork IP emergency 425 calls to legacy non-IP PSAPs). Note that in order to support legacy 426 eCall-capable PSAPs that are not IP PSAPs and are not attached to an 427 ESInet, an originating network might need the ability to route an 428 eCall itself (e.g., to an interworking facility with interconnection 429 to a suitable legacy eCall capable PSAP) based on the eCall and 430 manual or automatic indications. The ETSI TR "Mobile Standards Group 431 (MSG); eCall for VoIP" [MSG_TR] discusses transition issues in Clause 432 7. 434 8. Test Calls 436 eCall requires the ability to place test calls. These are calls that 437 are recognized and treated to some extent as eCalls but are not given 438 emergency call treatment and are not handled by call takers. The 439 test call facility allows the IVS or user to verify that an eCall can 440 be successfully established with voice communication. The IVS can 441 also verify that the MSD was successfully received. 443 A service URN starting with "test." indicates a test call. For 444 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 445 This functionality is defined in [RFC6881]. 447 This document registers "urn:service:test.sos.ecall" for eCall test 448 calls. 450 the current eCall test call facility is a non-emergency number so 451 does not get treated as an emergency call. MNOs can treat a vehicle 452 call in the "test" service URN in a way that tests as much 453 functionality as desired, but this is outside the scope of this 454 document. 456 PSAPs that have the ability to process NG-eCalls SHOULD accept test 457 calls and send an acknowledgment if the MSD was successfully 458 received, per this document. Such PSAPs MAY also play an audio clip 459 (for example, saying that the call reached a PSAP) in addition to 460 supporting media loopback per [RFC6881]. 462 9. eCall-Specific Control/Metadata 464 eCall requires the ability for the PSAP to acknowledge successful 465 receipt of an MSD sent by the IVS, and for the PSAP to request that 466 the IVS send an MSD (e.g., the call taker can initiate a request for 467 a new MSD to see if the vehicle's state or location has changed). 468 Future enhancements are desired to enable the PSAP to send other 469 requests to the vehicle, such as locking or unlocking doors, sounding 470 the horn, flashing the lights, starting a video stream from on-board 471 cameras (such as rear focus or blind-spot), etc. 473 The mechanism established in [I-D.ietf-ecrit-additional-data], used 474 in Section 5 of this document to carry the MSD from the IVS to the 475 PSAP, is also used to carry a block of control data from the PSAP to 476 the IVS. This eCall control block (sometimes referred to as eCall 477 metadata) is an XML structure containing eCall-specific elements. 478 When the PSAP needs to send an eCall control block that is in 479 response to the MSD or other data sent by the IVS in a SIP request, 480 the control block can be sent in the SIP response to that request 481 (e.g., the INVITE). When the PSAP needs to send an eCall control 482 block that is not an immediate response to an MSD or other data sent 483 by the IVS, the control block can be transmitted from the PSAP to the 484 IVS in a SIP INFO message within the established session. The IVS 485 can then send any requested data (such as a new MSD) in the reply to 486 the INFO message. This mechanism flexibly allows the PSAP to send 487 eCall-specific data to the IVS and the IVS to respond. If control 488 data sent in a response message requests the IVS to send a new MSD or 489 other data block, or to perform an action other than sending data, 490 the IVS can send the requested data or an acknowledgment regarding 491 the action in an INFO message within the session (it could also use 492 re-INVITE but that is unnecessary when no aspect of the session or 493 media is changing). 495 This mechanism requires 497 o An XML definition of the eCall control object 498 o An extension mechanism by which new elements can be added to the 499 control object definition (e.g., permitting additional elements to 500 be included by adding their namespace) 501 o A MIME type registration for the control object (so it can be 502 carried in SIP messages and responses) 503 o An entry in the Emergency Call Additional Data Blocks sub-registry 504 (established by [I-D.ietf-ecrit-additional-data]) so that the 505 control block can be recognized as emergency call specific data 506 within the SIP messages 507 o An Info-Package registration per [RFC6086] permitting the control 508 block within Info messages 510 9.1. The eCall Control Block 512 The eCall control block is an XML data structure allowing for 513 acknowledgments, requests, and capabilities information. It is 514 carried in a SIP body part with a specific MIME content type. Three 515 top-level elements are defined for use within an eCall control block: 517 ack Used in a control block sent by either side. The PSAP 518 uses this to acknowledge receipt of a data set sent by 519 the IVS. The IVS uses this to acknowledge receipt of a 520 request by the PSAP when that request would not 521 otherwise be acknowledged (if the PSAP requests the 522 vehicle to send data and the vehicle does so, the data 523 serves as a success acknowledgement). 525 capabilities: Used in a control block sent from the IVS to the PSAP 526 (e.g., in the initial INVITE) to inform the PSAP of the 527 vehicle capabilities. Child elements contain all 528 actions and data types supported by the vehicle and all 529 available lamps (lights) and cameras. 531 request Used in a control block sent by the PSAP to the IVS, to 532 request the vehicle to perform an action. 534 Mandatory Actions (the IVS and the PSAP MUST support): 536 o Transmit data object 538 Optional Actions (the IVS and the PSAP MAY support): 540 o Play and/or display static (pre-defined) message 541 o Speak/display dynamic text (text supplied in action) 542 o Flash or turn on or off a lamp (light) 543 o Honk horn 544 o Enable a camera 546 The element indicates the object being acknowledged (i.e., a 547 data object or a element), and reports success or failure. 549 The element has child elements to indicate 550 the actions supported by the IVS. 552 The element contains attributes to indicate the request and 553 to supply any needed information, and MAY contain a child 554 element to contain the text for a dynamic message. The 'action' 555 attribute is mandatory and indicates the specific action. An IANA 556 registry is created in Section 14.8.1 to contain the allowed values. 558 Extensibility: New elements, child elements, and attributes can be 559 defined in new namespaces. IANA registries are used to specify the 560 permitted values of several elements and attributes. These 561 mechanisms allow for extension. 563 There is no 'request' action to play dynamic media (such as a pre- 564 recorded audio message). The SIP re-INVITE mechanism can be used to 565 establish a one-way media stream for this purpose. 567 9.1.1. The element 569 The element is transmitted by the PSAP to acknowledge receipt 570 of an eCall data object. An element sent by a PSAP references 571 the unique ID of the data object that was sent by the IVS, and 572 further indicates if the PSAP considers the receipt successful or 573 not. The element is also transmitted by the IVS to the PSAP to 574 acknowledge receipt of a element that requested the IVS to 575 perform an action other than transmitting a data object (e.g., a 576 request to display a message would be acknowledged, but a request to 577 transmit a data object would not result in a separate element 578 being sent, since the data object itself serves as acknowledgment.) 579 An element sent by an IVS references the unique ID of the 580 request being acknowledged, indicates whether the request was 581 successfully performed, and if not, optionally includes an 582 explanation. 584 The element has the following attributes and child elements: 586 9.1.1.1. Attributes of the element 588 The element has the following attributes: 590 Name: ref 591 Usage: Mandatory 592 Type: anyURI 593 Description: References the Content-ID of the body part that 594 contained the data object or control object being acknowledged. 595 Example: 597 Name: received 598 Usage: Conditional: mandatory in an >ack< element sent by a PSAP; 599 not applicable in an >ack< element sent by an IVS 600 Type: Boolean 601 Description: Indicates if the referenced object was successfully 602 received or not 603 Example: 605 9.1.1.2. Child Elements of the element 607 The element has the following child elements: 609 Name: actionResult 610 Usage: Optional 611 Description: An element indicates the result of an 612 action (other than a 'send-data' action). When an element 613 is in response to a control object with multiple 614 elements (that are not 'send-data' actions), the element 615 contains an element for each. The 616 element has the following attributes: 618 Name: action 619 Usage: Mandatory 620 Type: token 621 Description: Contains the value of the 'action' attribute of the 622 element 624 Name: success 625 Usage: Mandatory 626 Type: Boolean 627 Description: Indicates if the action was successfully 628 accomplished 630 Name: reason 631 Usage: Conditional 632 Type: token 633 Description: Used when 'success' is "False", this attribute 634 contains a reason code for a failure. A registry for reason 635 codes is defined in Section 14.8.3. 637 Name: details 638 Usage: optional 639 Type: string 640 Description: Contains further explanation of the circumstances of 641 a success or failure. The contents are implementation-specific 642 and human-readable. 644 Example: 646 Example: 649 9.1.1.3. Ack Examples 651 652 658 660 662 Figure 3: Ack Example from PSAP to IVS 664 665 671 672 673 675 677 679 Figure 4: Ack Example from IVS to PSAP 681 9.1.2. The element 683 The element is transmitted by the IVS to indicate to 684 the PSAP its capabilities. No attributes for this element are 685 currently defined. The following child elements are defined: 687 9.1.2.1. Child Elements of the element 689 The element has the following child elements: 691 Name: request 692 Usage: Mandatory 693 Description: The element contains a child 694 element per action supported by the vehicle. 696 Because support for a 'send-data' action is REQUIRED, a 697 child element with a "send-data" 'action' attribute is also 698 REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this 699 element within a element, and MUST 700 contain at a minimum the 'eCall.MSD' data block value; it SHOULD 701 contain all data blocks supported by the IVS. 703 All other actions are OPTIONAL. 705 If the "msg-static" action is supported, a child element 706 with a "msg-static" 'action' attribute is sent, with a 'msgid' 707 attribute set to the highest supported static message supported by 708 the vehicle. A registry is created in Section 14.8.2 to map 709 'msgid' values to static text messages. By sending the highest 710 supported static message number in its element, the 711 vehicle indicates its support for all static messages in the 712 registry up to and including that value. 714 If the "lamp" action is supported, a child element with 715 a "lamp" 'action' is sent, with a 'supported-lamps' attribute set 716 to all supported lamp IDs. 718 If the "enable-camera" action is supported, a child 719 element with an "enable-camera" 'action' is sent, with a 720 'supported-cameras' attribute set to all supported camera IDs. 722 Examples: 723 724 726 727 729 9.1.2.2. Capabilities Example 731 732 738 739 740 743 744 745 746 747 749 751 Figure 5: Capabilities Example 753 9.1.3. The element 755 A element appears one or more times on its own or as a 756 child of a element. The following attributes and 757 child elements are defined: 759 9.1.3.1. Attributes of the element 761 The element has the following attributes: 763 Name: action 764 Usage: Mandatory 765 Type: token 766 Description: Identifies the action that the vehicle is requested to 767 perform. An IANA registry is established in Section 14.8.1 to 768 contain the allowed values. 769 Example: action="send-data" 771 Name: msgid 772 Usage: Conditional 773 Type: int 774 Description: Mandatory with a "msg-static" action. Indicates the 775 identifier of the static message to be displayed and/or spoken for 776 the vehicle occupants. This document established an IANA registry 777 for messages and their IDs, in Section 14.8.2 778 Example: msgid="3" 780 Name: persistance 781 Usage: Optional 782 Type: duration 783 Description: Specifies how long to carry on the specified action, 784 for example, how long to continue honking or flashing. If absent, 785 the default is indefinitely. 786 Example: persistance="PT1H" 788 Name: datatype 789 Usage: Conditional 790 Type: token 791 Description: Mandatory with a "send-data" action. Specifies the 792 data block that the IVS is requested to transmit, using the same 793 identifier as in the 'purpose' attribute set in a Call-Info header 794 field to point to the data block. Permitted values are contained 795 in the 'Emergency Call Data Types' IANA registry established in 796 [I-D.ietf-ecrit-additional-data]. 797 Example: datatype="eCall.MSD" 799 Name: supported-datatypes 800 Usage: Conditional 801 Type: string 802 Description: Used with a 'send-data' action in a element 803 that is a child of a element, this attribute lists 804 all data blocks that the vehicle can transmit, using the same 805 identifier as in the 'purpose' attribute in a Call-Info header 806 field to point to the data block. Permitted values are contained 807 in the 'Emergency Call Data Types' IANA registry established in 808 [I-D.ietf-ecrit-additional-data]. Multiple values are separated 809 with a semicolon. 810 Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo" 812 Name: lamp-action 813 Usage: Conditional 814 Type: token 815 Description: Used with a 'lamp' action, indicates if the lamp is to 816 be illuminated, turned off, or flashed. Permitted values are 817 'on', 'off', and 'flash'. 818 Example: lamp-action="flash" 820 Name: lamp-ID 821 Usage: Conditional 822 Type: token 823 Description: Used with a 'lamp' action, indicates which lamp the 824 action affects. Permitted values are contained in the registry of 825 lamp-ID tokens created in Section 14.8.4 826 Example: lamp-ID="hazard" 828 Name: supported-lamps 829 Usage: Conditional 830 Type: string 831 Description: Used with a 'lamp' action in a element that 832 is a child of a element, this attribute lists all 833 supported lamps, using values in the registry of lamp-ID tokens 834 created in Section 14.8.4. Multiple values are separated with a 835 semicolon. 836 Example: supported-lamps="head; interior; fog-front; fog-rear; 837 brake; position-front; position-rear; turn-left; turn-right; 838 hazard" 840 Name: camera-ID 841 Usage: Conditional 842 Type: token 843 Description: Used with an 'enable-camera' action, indicates which 844 camera to enable. Permitted values are contained in the registry 845 of camera-ID tokens created in Section 14.8.5. When a vehicle 846 camera is enabled, the IVS sends a re-INVITE to negotiate a one- 847 way media stream for the camera. 848 Example: camera-ID="backup" 849 Name: supported-cameras 850 Usage: Conditional 851 Type: string 852 Description: Used with an 'enable-camera' action in a 853 element that is a child of a element, this attribute 854 lists all cameras that the vehicle supports (can add as a video 855 feed in the current session), using the same identifiers as are 856 used in the 'camera-ID' attribute (contained in the camera ID 857 registry in Section 14.8.5). Multiple values are separated with a 858 semicolon. 859 Example: supported-cameras="backup; interior" 861 9.1.3.2. Child Elements of the element 863 The element has the following child elements: 865 Name: text 866 Usage: Conditional 867 Type: string 868 Description: Used within a element to 869 contain the text to be displayed and/or spoken (via text-to- 870 speech) for the vehicle occupants. 871 Example: Emergency authorities are aware of your incident and 872 location. Due to a multi-vehicle incident in your area, no one is 873 able to speak with you right now. Please remain calm. We will 874 assist you soon. 876 9.1.3.3. Request Example 877 878 884 885 887 888 889 Remain calm. Help is on the way. 890 892 894 Figure 6: Request Example 896 9.2. The emergencyCallData.eCall INFO package 898 This document registers the 'emergencyCallData.eCall' INFO package. 899 Both endpoints (the IVS and the PSAP equipment) set the Recv-Info 900 header field to 'emergencyCallData.eCall' per [RFC6086] to indicate 901 ability to receive INFO messages carrying eCall data or control 902 blocks. 904 Support for the 'emergencyCallData.eCall' INFO package indicates the 905 ability to receive eCall data and control blocks, which are carried 906 in a body part whose subtype starts with 'emergencyCallData.eCall.'. 907 At present there is only one defined eCall data block, which has the 908 'application/emergencyCallData.eCall.MSD+xml' MIME type, and one 909 eCall control block, which has the 'application/ 910 emergencyCallData.eCall.control+xml' MIME type. The eCall control 911 block includes the ability for the IVS to indicate its capabilities, 912 so in the event additional eCall blocks are defined, the IVS can 913 indicate which it supports. 915 The use of INFO is based on an analysis of the requirements against 916 the intent and effects of INFO versus other approaches (such as SIP 917 MESSAGE, media plane, or non-SIP protocols). In particular, the 918 transport of eCall data and control blocks is done only during an 919 emergency session established with SIP, using the mechanism 920 established in [I-D.ietf-ecrit-additional-data], and is normally 921 carried in the initial INVITE and its response; the use of INFO only 922 occurs when a data block or request needs to be sent subsequently 923 during the call. While MESSAGE could be used, it is not tied to a 924 SIP session as is INFO. REINVITE could also be used, but is normally 925 used to modify the session. SUBSCRIBE/NOTIFY could be coerced into 926 service, but the semantics are not a clean fit. Hence, INFO is 927 appropriate. 929 An INFO request message carrying an eCall data or control block has 930 an Info-Package header field set to 'emergencyCallData.eCall' per 931 [RFC6086]. The INFO request message is marked as containing the 932 eCall data or control block by a Call-Info header field containing a 933 CID URL referencing the unique identifier of the body part containing 934 the eCall data or control, and a 'purpose' parameter identifying the 935 block. Because the eCall data or control block is being carried in 936 an INFO request message, the body part also carries a Content- 937 Disposition header field set to "Info-Package". 939 Per [I-D.ietf-ecrit-additional-data], emergency call related 940 additional data MAY be included in any SIP request or response 941 message that can contain a body. Hence, notwithstanding 942 Section 4.3.2. of [RFC6086], INFO response messages MAY contain eCall 943 data or control blocks, provided they are included as described in 944 this document (with a Call-Info header field containing a CID URL 945 referencing the unique identifier of the body part, and a 'purpose' 946 parameter identifying the block). When eCall data or control blocks 947 are included in an INFO response message, this is done per 948 [I-D.ietf-ecrit-additional-data] and this document, and not under 949 [RFC6086]; that is, they are included as emergency call additional 950 data, not as an INFO package associated data. 952 10. Examples 954 Figure 7 shows an eCall. The call uses the request URI 955 'urn:service:sos.ecall.automatic' service URN and is recognized as an 956 eCall, and further as one that was invoked automatically by the IVS 957 due to a crash or other serious incident. In this example, the 958 originating network routes the call to an ESInet (as for any 959 emergency call in an environment with an ESInet). The ESInet routes 960 the call to the appropriate NG-eCall capable PSAP. The emergency 961 call is received by the ESInet's Emergency Services Routing Proxy 962 (ESRP), as the entry point into the ESInet. The ESRP routes the call 963 to a PSAP, where it is received by a call taker. In deployments 964 where there is no ESInet, the originating network routes the call 965 directly to the appropriate NG-eCall capable PSAP. 967 +------------+ +---------------------------------------+ 968 | | | +-------+ | 969 | | | | PSAP2 | | 970 | | | +-------+ | 971 | | | | 972 | | | +------+ +-------+ | 973 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 974 | | | +------+ +-------+ | 975 | | | | 976 | | | +-------+ | 977 | | | | PSAP3 | | 978 | Originating| | +-------+ | 979 | Mobile | | | 980 | Network | | ESInet | 981 +------------+ +---------------------------------------+ 983 Figure 7: Example of NG-eCall Message Flow 985 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 986 contains an MSD and an eCall control block with vehicle capabilities. 987 For simplicity, the example does not show all SIP headers, nor does 988 it show the additional data blocks added by the IVS and the 989 originating mobile network. 991 INVITE urn:service:sos.ecall.automatic SIP/2.0 992 To: urn:service:sos.ecall.automatic 993 From: ;tag=9fxced76sl 994 Call-ID: 3848276298220188511@atlanta.example.com 995 Geolocation: 996 Geolocation-Routing: no 997 Call-Info: cid:1234567890@atlanta.example.com; 998 purpose=emergencyCallData.eCall.MSD; 999 cid:2345678901@atlanta.example.com; 1000 purpose=emergencyCallData.eCall.control; 1001 Accept: application/sdp, application/pidf+xml, 1002 application/emergencyCallData.eCall.control 1003 CSeq: 31862 INVITE 1004 Recv-Info: emergencyCallData.eCall 1005 Content-Type: multipart/mixed; boundary=boundary1 1006 Content-Length: ... 1008 --boundary1 1009 Content-Type: application/sdp 1011 ...Session Description Protocol (SDP) goes here... 1013 --boundary1 1014 Content-Type: application/emergencyCallData.eCall.MSD+xml 1015 Content-ID: 1234567890@atlanta.example.com 1016 Content-Disposition: by-reference;handling=optional 1018 1019 1 1021 1022 1024 1 1026 1027 1028 1029 1030 1031 1033 1034 WMI 1035 VDSVDS 1036 Y 1037 A123456 1038 1040 1041 1042 1043 1045 123456789 1047 1048 173881200 1049 41822520 1050 1052 14 1054 1055 10 1056 -10 1057 1059 1060 10 1061 -20 1062 1063 2 1065 1067 1068 1.2.125 1069 30304646 1070 1071 1072 1074 --boundary1 1075 Content-Type: application/emergencyCallData.eCall.control+xml 1076 Content-ID: 2345678901@atlanta.example.com 1077 Content-Disposition: by-reference;handling=optional 1079 1080 1086 1087 1088 1092 1093 1094 1095 1097 1099 1101 --boundary1-- 1103 Figure 8: SIP NG-eCall INVITE 1105 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1106 the INVITE of Figure 8, containing an eCall control block 1107 acknowledging successful receipt of the eCall MSD. (For simplicity, 1108 the example does not show all SIP headers.) 1109 SIP/2.0 200 OK 1110 To: ;tag=9fxced76sl 1111 From: Exemplar PSAP 1112 Call-ID: 3848276298220188511@atlanta.example.com 1113 Call-Info: cid:2345678901@atlanta.example.com; 1114 purpose=emergencyCallData.eCall.control; 1115 Accept: application/sdp, application/pidf+xml, 1116 application/emergencyCallData.eCall.control, 1117 application/emergencyCallData.eCall.MSD 1118 CSeq: 31862 INVITE 1119 Recv-Info: emergencyCallData.eCall 1120 Content-Type: multipart/mixed; boundary=boundaryX 1121 Content-Length: ... 1123 --boundaryX 1124 Content-Type: application/sdp 1126 ...Session Description Protocol (SDP) goes here... 1128 --boundaryX 1129 Content-Type: application/EmergencyCallData:eCall-control+xml 1130 Content-ID: 2345678901@atlanta.example.com 1131 Content-Disposition: by-reference;handling=optional 1133 1134 1140 1142 1144 --boundaryX-- 1146 Figure 9: 200 OK response to INVITE 1148 11. Security Considerations 1150 The security considerations described in [RFC5069] apply here. 1152 In addition to any network-provided location that is inherently 1153 permitted for IMS emergency calls (which might be determined solely 1154 by the network, or in cooperation with or possibly entirely by the 1155 originating device), an eCall carries an IVS-supplied location within 1156 the MSD. This is likely to be useful to the PSAP, especially when 1157 the two locations are independently determined. Even in situations 1158 where the network-supplied location is limited to the cell site, this 1159 can be useful as a sanity check on the device-supplied location 1160 contained in the MSD. 1162 The document [RFC7378] discusses trust issues regarding location 1163 provided by or determined in cooperation with end devices. 1165 Security considerations specific to the mechanism by which the PSAP 1166 sends acknowledgments and requests to the vehicle are discussed in 1167 the "Security Considerations" block of Section 14.3. In addition to 1168 that discussion, it's important to note that vehicles MAY decline to 1169 carry out any requested action, e.g., if the vehicle is unable to 1170 verify the certificate used to sign the request. The vehicle MAY use 1171 any value in the reason registry in Section 14.8.3 to indicate why it 1172 did not take an action (e.g., the generic "unable" or the more 1173 specific "security-failure"). 1175 Data received from external sources inherently carries implementation 1176 risks including buffer overflows, which in many platforms can 1177 introduce remote code execution vulnerabilities; null characters can 1178 corrupt strings, numeric values used for internal calculations can 1179 result in underflow/overflow errors; malformed XML objects can expose 1180 parsing bugs, etc. Implementations need to be cognizant of the 1181 potential risks, observe best practices (e.g., good quality static 1182 code analysis, fuzz testing, component isolation, avoiding use of 1183 unsafe coding techniques, third-party attack tests, signed software, 1184 over-the-air updates, etc.), and have multiple levels of protection. 1185 Implementors need to be aware that, potentially, the data objects 1186 described here and elsewhere might be malformed, might contain 1187 unexpected characters, excessively long attribute values, elements, 1188 etc. (This applies across the board, not just to the 'text' 1189 attribute of a element.) 1191 Since this document depends on [I-D.ietf-ecrit-additional-data], the 1192 security considerations discussed there apply here (see especially 1193 the discussion of TLS, TLS versions, cypher suites, and PKI). 1195 12. Privacy Considerations 1197 Since this document builds on [I-D.ietf-ecrit-additional-data], the 1198 data structures specified there, and the corresponding privacy 1199 considerations discussed there, apply here as well. The MSD carries 1200 some additional identifying and personal information (mostly about 1201 the vehicle and less about the owner), as well as location 1202 information, and so needs to be protected against unauthorized 1203 disclosure. Local regulations may impose additional privacy 1204 protection requirements. The additional functionality enabled by 1205 this document, such as access to vehicle camera streams, carries a 1206 burden of protection and so implementations need to be careful that 1207 access is only provided within the context of an emergency call and 1208 to an emergency services provider, for example, by verifying that the 1209 request for camera access is signed by a certificate issued by an 1210 emergency services registrar. 1212 Privacy considerations specific to the data structure containing 1213 vehicle information are discussed in the "Security Considerations" 1214 block of Section 14.2. 1216 Privacy considerations specific to the mechanism by which the PSAP 1217 sends acknowledgments and requests to the vehicle are discussed in 1218 the "Security Considerations" block of Section 14.3. 1220 13. XML Schema 1222 This section defines the XML schema of the eCall control block. (The 1223 schema for the MSD can be found in EN 15722 [msd].) 1225 1226 1234 1237 1240 1241 1242 1243 1244 1246 1247 1248 1251 1252 1253 1254 1255 1257 1258 1259 1260 1261 1263 1264 1267 1270 1272 1273 conditionally 1274 mandatory when @success='false" 1275 to indicate reason code for a 1276 failure 1277 1278 1279 1281 1282 1283 1284 1287 1288 1291 1293 1294 1295 1296 1297 1298 1299 1300 1301 1305 1308 1309 1310 1311 1312 1314 1315 1316 1317 1318 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1345 1346 1348 1350 Figure 10: eCall Control Block Schema 1352 14. IANA Considerations 1354 14.1. Service URN Registrations 1356 IANA is requested to register the URN 'urn:service:sos.ecall' under 1357 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1359 This service identifies a type of emergency call (placed by a 1360 specialized in-vehicle system and a carrying standardized set of data 1361 related to the vehicle and crash or incident, and is needed to direct 1362 the call to a specialized public safety answering point (PSAP) with 1363 technical and operational capabilities to handle such calls. Two 1364 sub-services are registered as well, namely 1366 urn:service:sos.ecall.manual 1368 This service URN indicates that an eCall had been triggered based 1369 on the manual interaction of the driver or a passenger. 1371 urn:service:sos.ecall.automatic 1373 This service URN indicates that an eCall had been triggered 1374 automatically, for example, due to a crash or other serious 1375 incident (e.g., fire). 1377 IANA is also requested to register the URN 1378 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1379 defined in Setcion 17.2 of [RFC6881]. 1381 14.2. MIME Content-type Registration for 'application/ 1382 emergencyCallData.eCall.MSD+xml' 1384 IANA is requested to add application/emergencyCallData.eCall.MSD+xml 1385 as a MIME content type, with a reference to this document, in 1386 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1387 RFC 7303 [RFC7303]. 1389 MIME media type name: application 1391 MIME subtype name: emergencyCallData.eCall.MSD+xml 1392 Mandatory parameters: none 1394 Optional parameters: charset 1396 Indicates the character encoding of the XML content. 1398 Encoding considerations: Uses XML, which can employ 8-bit 1399 characters, depending on the character encoding used. See 1400 Section 3.2 of RFC 7303 [RFC7303]. 1402 Security considerations: This content type is designed to carry 1403 vehicle and incident-related data during an emergency call. This 1404 data contains personal information including vehicle VIN, 1405 location, direction, etc. Appropriate precautions need to be 1406 taken to limit unauthorized access, inappropriate disclosure to 1407 third parties, and eavesdropping of this information. In general, 1408 it is permissible for the data to be unprotected while briefly in 1409 transit within the Mobile Network Operator (MNO); the MNO is 1410 trusted to not permit the data to be accessed by third parties. 1411 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1412 contain more discussion. 1414 Interoperability considerations: None 1416 Published specification: Annex C of EN 15722 [msd] 1418 Applications which use this media type: Pan-European eCall 1419 compliant systems 1421 Additional information: None 1423 Magic Number: None 1425 File Extension: .xml 1427 Macintosh file type code: 'TEXT' 1429 Person and email address for further information: Hannes 1430 Tschofenig, Hannes.Tschofenig@gmx.net 1432 Intended usage: LIMITED USE 1434 Author: This specification was produced by the European Committee 1435 For Standardization (CEN). For contact information, please see 1436 . 1438 Change controller: The European Committee For Standardization 1439 (CEN) 1441 14.3. MIME Content-type Registration for 'application/ 1442 emergencyCallData.eCall.control+xml' 1444 IANA is requested to add application/ 1445 emergencyCallData.eCall.control+xml as a MIME content type, with a 1446 reference to this document, in accordance to the procedures of RFC 1447 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1449 MIME media type name: application 1451 MIME subtype name: emergencyCallData.eCall.control+xml 1453 Mandatory parameters: none 1455 Optional parameters: charset 1457 Indicates the character encoding of the XML content. 1459 Encoding considerations: Uses XML, which can employ 8-bit 1460 characters, depending on the character encoding used. See 1461 Section 3.2 of RFC 7303 [RFC7303]. 1463 Security considerations: 1465 This content type carries metadata and control information and 1466 requests, primarily from a Public Safety Answering Point (PSAP) 1467 to an In-Vehicle System (IVS) during an emergency call, and 1468 also capabilities from the IVS to the PSAP. 1470 Metadata (such as an acknowledgment that data sent by the IVS 1471 to the PSAP was successfully received) has limited privacy and 1472 security implications. Control information (such as requests 1473 from the PSAP that the vehicle perform an action) has some 1474 privacy and important security implications. The privacy 1475 concern arises from the ability to request the vehicle to 1476 transmit a data set, which as described in Section 14.2, can 1477 contain personal information. The security concern is the 1478 ability to request the vehicle to perform an action. It is 1479 important that control information originate only from a PSAP 1480 or other emergency services provider, and not be modified en- 1481 route. The level of integrity of the cellular network over 1482 which the emergency call is placed is important: when the IVS 1483 initiates an eCall over a cellular network, it relies on the 1484 MNO to route the call to a PSAP. (Calls placed using other 1485 means, such as Wi-Fi or over-the-top services, generally incur 1486 higher levels of risk than calls placed over cellular 1487 networks.) A call-back from a PSAP incurs additional risk, 1488 since the current mechanisms are not ideal for verifying that 1489 such a call is indeed a call-back from a PSAP in response to an 1490 emergency call placed by the IVS. See the discussion in 1491 Section 11 and the PSAP Callback document [RFC7090]. One 1492 safeguard, applicable regardless of which end initiated the 1493 call and the means of the call, is for the PSAP or emergency 1494 service provider to sign the body part using a certificate 1495 issued by a known emergency services certificate authority and 1496 for which the IVS can verify the root certificate. 1498 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1499 contain more discussion. 1501 Interoperability considerations: None 1503 Published specification: Annex C of EN 15722 [msd] 1505 Applications which use this media type: Pan-European eCall 1506 compliant systems 1508 Additional information: None 1510 Magic Number: None 1512 File Extension: .xml 1514 Macintosh file type code: 'TEXT' 1516 Person and email address for further information: Randall Gellens, 1517 rg+ietf@qti.qualcomm.com 1519 Intended usage: LIMITED USE 1521 Author: The IETF ECRIT WG. 1523 Change controller: The IETF ECRIT WG. 1525 14.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1526 Additional Data Blocks registry 1528 This specification requests IANA to add the 'eCall.MSD' entry to the 1529 Emergency Call Additional Data Blocks registry (established by 1530 [I-D.ietf-ecrit-additional-data]), with a reference to this document. 1532 14.5. Registration of the 'eCall.control' entry in the Emergency Call 1533 Additional Data Blocks registry 1535 This specification requests IANA to add the 'eCall.control' entry to 1536 the Emergency Call Additional Data Blocks registry (established by 1537 [I-D.ietf-ecrit-additional-data]), with a reference to this document. 1539 14.6. Registration of the emergencyCallData.eCall Info Package 1541 IANA is requested to add emergencyCallData.eCall to the Info Packages 1542 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1543 reference to this document. 1545 14.7. URN Sub-Namespace Registration 1547 14.7.1. Registration for urn:ietf:params:xml:ns:eCall 1549 This section registers a new XML namespace, as per the guidelines in 1550 RFC 3688 [RFC3688]. 1552 URI: urn:ietf:params:xml:ns:eCall 1554 Registrant Contact: IETF, ECRIT working group, , as 1555 delegated by the IESG . 1557 XML: 1559 BEGIN 1560 1561 1563 1564 1565 1567 Namespace for eCall Data 1568 1569 1570

Namespace for eCall Data

1571

See [TBD: This document].

1572 1573 1574 END 1576 14.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1578 This section registers a new XML namespace, as per the guidelines in 1579 RFC 3688 [RFC3688]. 1581 URI: urn:ietf:params:xml:ns:eCall:control 1583 Registrant Contact: IETF, ECRIT working group, , as 1584 delegated by the IESG . 1586 XML: 1588 BEGIN 1589 1590 1592 1593 1594 1596 Namespace for eCall Data: 1597 Control Block 1598 1599 1600

Namespace for eCall Data

1601

Control Block

1602

See [TBD: This document].

1603 1604 1605 END 1607 14.8. Registry creation 1609 This document creates a new registry called 'eCall Control Data'. 1610 The following sub-registries are created for this registry. 1612 14.8.1. eCall Control Action Registry 1614 This document creates a new sub-registry called "eCall Control Action 1615 Registry". As defined in [RFC5226], this registry operates under 1616 "Expert Review" rules. The expert should determine that the proposed 1617 action is within the purview of a vehicle, is sufficiently 1618 distinguishable from other actions, and the actions is clearly and 1619 fully described. In most cases, a published and stable document is 1620 referenced for the description of the action. 1622 The content of this registry includes: 1624 Name: The identifier to be used in the 'action' attribute of an 1625 eCall control element. 1627 Description: A description of the action. In most cases this will 1628 be a reference to a published and stable document. The 1629 description MUST specify if any attributes or child elements are 1630 optional or mandatory, and describe the action to be taken by the 1631 vehicle. 1633 The initial set of values is listed in Table 2. 1635 +---------------+------------------------------+ 1636 | Name | Description | 1637 +---------------+------------------------------+ 1638 | send-data | Section xxx of this document | 1639 | | | 1640 | msg-static | Section xxx of this document | 1641 | | | 1642 | msg-dynamic | Section xxx of this document | 1643 | | | 1644 | honk | Section xxx of this document | 1645 | | | 1646 | lamp | Section xxx of this document | 1647 | | | 1648 | enable-camera | Section xxx of this document | 1649 +---------------+------------------------------+ 1651 Table 2: eCall Control Action Registry Initial Values 1653 14.8.2. eCall Static Message Registry 1655 This document creates a new sub-registry called "eCall Static Message 1656 Registry". Because all compliant vehicles are expected to support 1657 all static messages translated into all languages supported by the 1658 vehicle, it is important to limit the number of such messages. As 1659 defined in [RFC5226], this registry operates under "Publication 1660 Required" rules, which require a stable, public document and imply 1661 expert review of the publication. The expert should determine that 1662 the document has been published by an appropriate emergency services 1663 organization (e.g., NENA, EENA, APCO) and that the proposed message 1664 is sufficiently distinguishable from other messages. 1666 The content of this registry includes: 1668 ID: An integer identifier to be used in the 'msgid' attribute of an 1669 eCall control element. 1671 Message: The text of the message. Messages are listed in the 1672 registry in English; vehicles are expected to implement 1673 translations into languages supported by the vehicle. 1675 When new messages are added to the registry, the message text is 1676 determined by the registrant; IANA assigns the IDs. Each message is 1677 assigned a consecutive integer value as its ID. This allows an IVS 1678 to indicate by a single integer value that it supports all messages 1679 with that value or lower. 1681 The initial set of values is listed in Table 3. 1683 +----+--------------------------------------------------------------+ 1684 | ID | Message | 1685 +----+--------------------------------------------------------------+ 1686 | 1 | Emergency authorities are aware of your incident and | 1687 | | location, but are unable to speak with you right now. We | 1688 | | will help you as soon as possible. | 1689 +----+--------------------------------------------------------------+ 1691 Table 3: eCall Static Message Registry 1693 14.8.3. eCall Reason Registry 1695 This document creates a new sub-registry called "eCall Reason 1696 Registry" which contains values for the 'reason' attribute of the 1697 element. As defined in [RFC5226], this registry 1698 operates under "Expert Review" rules. The expert should determine 1699 that the proposed reason is sufficiently distinguishable from other 1700 reasons and that the proposed description is understandable and 1701 correctly worded. 1703 The content of this registry includes: 1705 ID: A short string identifying the reason, for use in the 'reason' 1706 attribute of an element. 1708 Description: A description of the reason. 1710 The initial set of values is listed in Table 4. 1712 +------------------+------------------------------------------------+ 1713 | ID | Description | 1714 +------------------+------------------------------------------------+ 1715 | unsupported | The 'action' is not supported. | 1716 | | | 1717 | unable | The 'action' could not be accomplished. | 1718 | | | 1719 | data-unsupported | The data item referenced in a 'send-data' | 1720 | | request is not supported. | 1721 | | | 1722 | security-failure | The authenticity of the request or the | 1723 | | authority of the requestor could not be | 1724 | | verified. | 1725 +------------------+------------------------------------------------+ 1727 Table 4: eCall Reason Registry 1729 14.8.4. eCall Lamp ID Registry 1731 This document creates a new sub-registry called "eCall Lamp ID 1732 Registry" to standardize the names of automotive lamps (lights). As 1733 defined in [RFC5226], this registry operates under "Expert Review" 1734 rules. The expert should determine that the proposed lamp name is 1735 clearly understandable and is sufficiently distinguishable from other 1736 lamp names. 1738 The content of this registry includes: 1740 Name: The identifier to be used in the 'lamp-ID' attribute of an 1741 eCall control element. 1743 Description: A description of the lamp (light). 1745 The initial set of values is listed in Table 5. 1747 +----------------+---------------------------------------------+ 1748 | Name | Description | 1749 +----------------+---------------------------------------------+ 1750 | head | The main lamps used to light the road ahead | 1751 | | | 1752 | interior | Interior lamp, often at the top center | 1753 | | | 1754 | fog-front | Front fog lamps | 1755 | | | 1756 | fog-rear | Rear fog lamps | 1757 | | | 1758 | brake | Brake indicator lamps | 1759 | | | 1760 | position-front | Front position/parking/standing lamps | 1761 | | | 1762 | position-rear | Rear position/parking/standing lamps | 1763 | | | 1764 | turn-left | Left turn/directional lamps | 1765 | | | 1766 | turn-right | Right turn/directional lamps | 1767 | | | 1768 | hazard | Hazard/four-way lamps | 1769 +----------------+---------------------------------------------+ 1771 Table 5: eCall Lamp ID Registry Initial Values 1773 14.8.5. eCall Camera ID Registry 1775 This document creates a new sub-registry called "eCall Camera ID 1776 Registry" to standardize the names of automotive camera. As defined 1777 in [RFC5226], this registry operates under "Expert Review" rules. 1778 The expert should determine that the proposed camera name is clearly 1779 understandable and is sufficiently distinguishable from other camera 1780 names. 1782 The content of this registry includes: 1784 Name: The identifier to be used in the 'camera-ID' attribute of an 1785 eCall control element. 1787 Description: A description of the camera. 1789 The initial set of values is listed in Table 6. 1791 +----------+--------------------------------------------------------+ 1792 | Name | Description | 1793 +----------+--------------------------------------------------------+ 1794 | backup | Shows what is behind the vehicle. Also known as | 1795 | | rearview, reverse, etc. | 1796 | | | 1797 | interior | Shows the interior (driver) | 1798 +----------+--------------------------------------------------------+ 1800 Table 6: eCall Camera ID Registry Initial Values 1802 15. Contributors 1804 Brian Rosen was a co-author of the original document upon which this 1805 document is based. 1807 16. Acknowledgements 1809 We would like to thank Bob Williams and Ban Al-Bakri for their 1810 feedback and suggestions, and Keith Drage, James Winterbottom, and 1811 Wes George for their review and comments. We would like to thank 1812 Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and Ulrich Dietz 1813 for their help with the original document upon which this document is 1814 based. 1816 17. Changes from Previous Versions 1818 17.1. Changes from draft-ietf-04 to draft-ietf-05 1820 o Reworked the security and privacy considerations material in the 1821 document as a whole and in the MIME registation sections of the 1822 MSD and control objects 1823 o Clarified that the element can appear multiple 1824 times within an element 1825 o Fixed IMS definition 1826 o Added clarifying text for the 'msgid' attribute 1828 17.2. Changes from draft-ietf-03 to draft-ietf-04 1830 o Added Privacy Considerations section 1831 o Reworded most uses of non-normative "may", "should", "must", and 1832 "recommended." 1833 o Fixed nits in examples 1835 17.3. Changes from draft-ietf-02 to draft-ietf-03 1837 o Added request to enable cameras 1838 o Improved examples and XML schema 1839 o Clarifications and wording improvements 1841 17.4. Changes from draft-ietf-01 to draft-ietf-02 1843 o Added clarifying text reinforcing that the data exchange is for 1844 small blocks of data infrequently transmitted 1845 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1846 establish a one-way media stream 1847 o Clarified that the scope is the needs of eCall within the SIP 1848 emergency call environment 1849 o Added informative statement that the document may be suitable for 1850 reuse by other ACN systems 1851 o Clarified that normative language for the control block applies to 1852 both IVS and PSAP 1853 o Removed 'ref', 'supported-mime', and elements 1854 o Minor wording improvements and clarifications 1856 17.5. Changes from draft-ietf-00 to draft-ietf-01 1858 o Added further discussion of test calls 1859 o Added further clarification to the document scope 1860 o Mentioned that multi-region vehicles may need to support other 1861 crash notification specifications in addition to eCall 1862 o Added details of the eCall metadata and control functionality 1863 o Added IANA registration for the MIME content type for the eCall 1864 control object 1865 o Added IANA registries for protocol elements and tokens used in the 1866 eCall control object 1867 o Minor wording improvements and clarifications 1869 17.6. Changes from draft-gellens-03 to draft-ietf-00 1871 o Renamed from draft-gellens- to draft-ietf-. 1872 o Added mention of and reference to ETSI TR "Mobile Standards Group 1873 (MSG); eCall for VoIP" 1874 o Added text to Introduction regarding migration/co-existence being 1875 out of scope 1876 o Added mention in Security Considerations that even if the network- 1877 supplied location is just the cell site, this can be useful as a 1878 sanity check on the IVS-supplied location 1879 o Minor wording improvements and clarifications 1881 17.7. Changes from draft-gellens-02 to -03 1883 o Clarifications and editorial improvements. 1885 17.8. Changes from draft-gellens-01 to -02 1887 o Minor wording improvements 1888 o Removed ".automatic" and ".manual" from 1889 "urn:service:test.sos.ecall" registration and discussion text. 1891 17.9. Changes from draft-gellens-00 to -01 1893 o Now using 'EmergencyCallData' for purpose parameter values and 1894 MIME subtypes, in accordance with changes to 1895 [I-D.ietf-ecrit-additional-data] 1896 o Added reference to RFC 6443 1897 o Fixed bug that caused Figure captions to not appear 1899 18. References 1901 18.1. Normative References 1903 [EN_16072] 1904 CEN, , "Intelligent transport systems - eSafety - Pan- 1905 European eCall operating requirements", December 2011. 1907 [I-D.ietf-ecrit-additional-data] 1908 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1909 J. Winterbottom, "Additional Data Related to an Emergency 1910 Call", draft-ietf-ecrit-additional-data-37 (work in 1911 progress), October 2015. 1913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1914 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1915 RFC2119, March 1997, 1916 . 1918 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1919 DOI 10.17487/RFC3688, January 2004, 1920 . 1922 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1923 Emergency and Other Well-Known Services", RFC 5031, DOI 1924 10.17487/RFC5031, January 2008, 1925 . 1927 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1928 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1929 DOI 10.17487/RFC5226, May 2008, 1930 . 1932 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1933 "Framework for Emergency Calling Using Internet 1934 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1935 2011, . 1937 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1938 Specifications and Registration Procedures", BCP 13, RFC 1939 6838, DOI 10.17487/RFC6838, January 2013, 1940 . 1942 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1943 Communications Services in Support of Emergency Calling", 1944 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1945 . 1947 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1948 DOI 10.17487/RFC7303, July 2014, 1949 . 1951 [TS22.101] 1952 3GPP, , "Technical Specification Group Services and System 1953 Aspects; Service aspects; Service principles", . 1955 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1956 minimum set of data (MSD), EN 15722", June 2011. 1958 18.2. Informative references 1960 [CEN] "European Committee for Standardization", 1961 . 1963 [I-D.ietf-ecrit-car-crash] 1964 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1965 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1966 ecrit-car-crash-03 (work in progress), July 2015. 1968 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1969 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1970 April 2014. 1972 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1973 Emergency Context Resolution with Internet Technologies", 1974 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1975 . 1977 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1978 Shanmugam, "Security Threats and Requirements for 1979 Emergency Call Marking and Mapping", RFC 5069, DOI 1980 10.17487/RFC5069, January 2008, 1981 . 1983 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1984 Initiation Protocol (SIP) INFO Method and Package 1985 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1986 . 1988 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1989 Patel, "Public Safety Answering Point (PSAP) Callback", 1990 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1991 . 1993 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1994 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1995 December 2014, . 1997 [SDO-3GPP] 1998 "3d Generation Partnership Project", 1999 . 2001 [SDO-ETSI] 2002 "European Telecommunications Standards Institute (ETSI)", 2003 . 2005 Authors' Addresses 2007 Randall Gellens 2008 Qualcomm Technologies, Inc. 2009 5775 Morehouse Drive 2010 San Diego 92651 2011 US 2013 Email: rg+ietf@randy.pensive.org 2014 Hannes Tschofenig 2015 (Individual) 2017 Email: Hannes.Tschofenig@gmx.net 2018 URI: http://www.tschofenig.priv.at