idnits 2.17.00 (12 Aug 2021) /tmp/idnits42618/draft-ietf-ecrit-ecall-06.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 (February 19, 2016) is 2282 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: August 22, 2016 (Individual) 6 February 19, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-06.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 August 22, 2016. 54 Copyright Notice 56 Copyright (c) 2016 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 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 9 80 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 10 81 9.1.1. The element . . . . . . . . . . . . . . . . . . 12 82 9.1.1.1. Attributes of the element . . . . . . . . . 12 83 9.1.1.2. Child Elements of the element . . . . . . . 12 84 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 13 85 9.1.2. The element . . . . . . . . . . . . . 14 86 9.1.2.1. Child Elements of the element . . 14 87 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15 88 9.1.3. The element . . . . . . . . . . . . . . . . 16 89 9.1.3.1. Attributes of the element . . . . . . . 16 90 9.1.3.2. Child Elements of the element . . . . . 18 91 9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19 92 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 19 93 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 96 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 14.1. Service URN Registrations . . . . . . . . . . . . . . . 29 99 14.2. MIME Content-type Registration for 100 'application/emergencyCallData.eCall.MSD+xml' . . . . . 30 101 14.3. MIME Content-type Registration for 102 'application/emergencyCallData.eCall.control+xml' . . . 31 103 14.4. Registration of the 'eCall.MSD' entry in the Emergency 104 Call Additional Data Blocks registry . . . . . . . . . . 33 105 14.5. Registration of the 'eCall.control' entry in the 106 Emergency Call Additional Data Blocks registry . . . . . 33 107 14.6. Registration of the emergencyCallData.eCall Info Package 33 108 14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33 109 14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33 110 14.7.2. Registration for 111 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34 112 14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 113 14.8.1. eCall Control Action Registry . . . . . . . . . . . 35 114 14.8.2. eCall Static Message Registry . . . . . . . . . . . 36 115 14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37 116 14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 38 117 14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 39 118 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 119 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 120 17. Changes from Previous Versions . . . . . . . . . . . . . . . 39 121 17.1. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40 122 17.2. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40 123 17.3. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40 124 17.4. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40 125 17.5. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 126 17.6. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41 127 17.7. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41 128 17.8. Changes from draft-gellens-02 to -03 . . . . . . . . . . 41 129 17.9. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41 130 17.10. Changes from draft-gellens-00 to -01 . . . . . . . . . . 41 131 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 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 8. Test Calls 403 eCall requires the ability to place test calls. These are calls that 404 are recognized and treated to some extent as eCalls but are not given 405 emergency call treatment and are not handled by call takers. The 406 test call facility allows the IVS or user to verify that an eCall can 407 be successfully established with voice communication. The IVS can 408 also verify that the MSD was successfully received. 410 A service URN starting with "test." indicates a test call. For 411 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 412 This functionality is defined in [RFC6881]. 414 This document registers "urn:service:test.sos.ecall" for eCall test 415 calls. 417 the current eCall test call facility is a non-emergency number so 418 does not get treated as an emergency call. MNOs can treat a vehicle 419 call in the "test" service URN in a way that tests as much 420 functionality as desired, but this is outside the scope of this 421 document. 423 PSAPs that have the ability to process NG-eCalls SHOULD accept test 424 calls and send an acknowledgment if the MSD was successfully 425 received, per this document. Such PSAPs MAY also play an audio clip 426 (for example, saying that the call reached a PSAP) in addition to 427 supporting media loopback per [RFC6881]. 429 9. eCall-Specific Control/Metadata 431 eCall requires the ability for the PSAP to acknowledge successful 432 receipt of an MSD sent by the IVS, and for the PSAP to request that 433 the IVS send an MSD (e.g., the call taker can initiate a request for 434 a new MSD to see if the vehicle's state or location has changed). 435 Future enhancements are desired to enable the PSAP to send other 436 requests to the vehicle, such as locking or unlocking doors, sounding 437 the horn, flashing the lights, starting a video stream from on-board 438 cameras (such as rear focus or blind-spot), etc. 440 The mechanism established in [I-D.ietf-ecrit-additional-data], used 441 in Section 5 of this document to carry the MSD from the IVS to the 442 PSAP, is also used to carry a block of control data from the PSAP to 443 the IVS. This eCall control block (sometimes referred to as eCall 444 metadata) is an XML structure containing eCall-specific elements. 445 When the PSAP needs to send an eCall control block that is in 446 response to the MSD or other data sent by the IVS in a SIP request, 447 the control block can be sent in the SIP response to that request 448 (e.g., the INVITE). When the PSAP needs to send an eCall control 449 block that is not an immediate response to an MSD or other data sent 450 by the IVS, the control block can be transmitted from the PSAP to the 451 IVS in a SIP INFO message within the established session. The IVS 452 can then send any requested data (such as a new MSD) in the reply to 453 the INFO message. This mechanism flexibly allows the PSAP to send 454 eCall-specific data to the IVS and the IVS to respond. If control 455 data sent in a response message requests the IVS to send a new MSD or 456 other data block, or to perform an action other than sending data, 457 the IVS can send the requested data or an acknowledgment regarding 458 the action in an INFO message within the session (it could also use 459 re-INVITE but that is unnecessary when no aspect of the session or 460 media is changing). 462 This mechanism requires 464 o An XML definition of the eCall control object 465 o An extension mechanism by which new elements can be added to the 466 control object definition (e.g., permitting additional elements to 467 be included by adding their namespace) 468 o A MIME type registration for the control object (so it can be 469 carried in SIP messages and responses) 470 o An entry in the Emergency Call Additional Data Blocks sub-registry 471 (established by [I-D.ietf-ecrit-additional-data]) so that the 472 control block can be recognized as emergency call specific data 473 within the SIP messages 474 o An Info-Package registration per [RFC6086] permitting the control 475 block within Info messages 477 9.1. The eCall Control Block 479 The eCall control block is an XML data structure allowing for 480 acknowledgments, requests, and capabilities information. It is 481 carried in a SIP body part with a specific MIME content type. Three 482 top-level elements are defined for use within an eCall control block: 484 ack Used in a control block sent by either side. The PSAP 485 uses this to acknowledge receipt of a data set sent by 486 the IVS. The IVS uses this to acknowledge receipt of a 487 request by the PSAP when that request would not 488 otherwise be acknowledged (if the PSAP requests the 489 vehicle to send data and the vehicle does so, the data 490 serves as a success acknowledgement). 492 capabilities: Used in a control block sent from the IVS to the PSAP 493 (e.g., in the initial INVITE) to inform the PSAP of the 494 vehicle capabilities. Child elements contain all 495 actions and data types supported by the vehicle and all 496 available lamps (lights) and cameras. 498 request Used in a control block sent by the PSAP to the IVS, to 499 request the vehicle to perform an action. 501 Mandatory Actions (the IVS and the PSAP MUST support): 503 o Transmit data object 505 Optional Actions (the IVS and the PSAP MAY support): 507 o Play and/or display static (pre-defined) message 508 o Speak/display dynamic text (text supplied in action) 509 o Flash or turn on or off a lamp (light) 510 o Honk horn 511 o Enable a camera 513 The element indicates the object being acknowledged (i.e., a 514 data object or a element), and reports success or failure. 516 The element has child elements to indicate 517 the actions supported by the IVS. 519 The element contains attributes to indicate the request and 520 to supply any needed information, and MAY contain a child 521 element to contain the text for a dynamic message. The 'action' 522 attribute is mandatory and indicates the specific action. An IANA 523 registry is created in Section 14.8.1 to contain the allowed values. 525 Extensibility: New elements, child elements, and attributes can be 526 defined in new namespaces. IANA registries are used to specify the 527 permitted values of several elements and attributes. These 528 mechanisms allow for extension. 530 There is no 'request' action to play dynamic media (such as a pre- 531 recorded audio message). The SIP re-INVITE mechanism can be used to 532 establish a one-way media stream for this purpose. 534 9.1.1. The element 536 The element is transmitted by the PSAP to acknowledge receipt 537 of an eCall data object. An element sent by a PSAP references 538 the unique ID of the data object that was sent by the IVS, and 539 further indicates if the PSAP considers the receipt successful or 540 not. The element is also transmitted by the IVS to the PSAP to 541 acknowledge receipt of a element that requested the IVS to 542 perform an action other than transmitting a data object (e.g., a 543 request to display a message would be acknowledged, but a request to 544 transmit a data object would not result in a separate element 545 being sent, since the data object itself serves as acknowledgment.) 546 An element sent by an IVS references the unique ID of the 547 request being acknowledged, indicates whether the request was 548 successfully performed, and if not, optionally includes an 549 explanation. 551 The element has the following attributes and child elements: 553 9.1.1.1. Attributes of the element 555 The element has the following attributes: 557 Name: ref 558 Usage: Mandatory 559 Type: anyURI 560 Description: References the Content-ID of the body part that 561 contained the data object or control object being acknowledged. 562 Example: 564 Name: received 565 Usage: Conditional: mandatory in an >ack< element sent by a PSAP; 566 not applicable in an >ack< element sent by an IVS 567 Type: Boolean 568 Description: Indicates if the referenced object was successfully 569 received or not 570 Example: 572 9.1.1.2. Child Elements of the element 574 The element has the following child elements: 576 Name: actionResult 577 Usage: Optional 578 Description: An element indicates the result of an 579 action (other than a 'send-data' action). When an element 580 is in response to a control object with multiple 581 elements (that are not 'send-data' actions), the element 582 contains an element for each. The 583 element has the following attributes: 585 Name: action 586 Usage: Mandatory 587 Type: token 588 Description: Contains the value of the 'action' attribute of the 589 element 591 Name: success 592 Usage: Mandatory 593 Type: Boolean 594 Description: Indicates if the action was successfully 595 accomplished 597 Name: reason 598 Usage: Conditional 599 Type: token 600 Description: Used when 'success' is "False", this attribute 601 contains a reason code for a failure. A registry for reason 602 codes is defined in Section 14.8.3. 604 Name: details 605 Usage: optional 606 Type: string 607 Description: Contains further explanation of the circumstances of 608 a success or failure. The contents are implementation-specific 609 and human-readable. 611 Example: 613 Example: 616 9.1.1.3. Ack Examples 617 618 624 626 628 Figure 3: Ack Example from PSAP to IVS 630 631 637 638 639 641 643 645 Figure 4: Ack Example from IVS to PSAP 647 9.1.2. The element 649 The element is transmitted by the IVS to indicate to 650 the PSAP its capabilities. No attributes for this element are 651 currently defined. The following child elements are defined: 653 9.1.2.1. Child Elements of the element 655 The element has the following child elements: 657 Name: request 658 Usage: Mandatory 659 Description: The element contains a child 660 element per action supported by the vehicle. 662 Because support for a 'send-data' action is REQUIRED, a 663 child element with a "send-data" 'action' attribute is also 664 REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this 665 element within a element, and MUST 666 contain at a minimum the 'eCall.MSD' data block value; it SHOULD 667 contain all data blocks supported by the IVS. 669 All other actions are OPTIONAL. 671 If the "msg-static" action is supported, a child element 672 with a "msg-static" 'action' attribute is sent, with a 'msgid' 673 attribute set to the highest supported static message supported by 674 the vehicle. A registry is created in Section 14.8.2 to map 675 'msgid' values to static text messages. By sending the highest 676 supported static message number in its element, the 677 vehicle indicates its support for all static messages in the 678 registry up to and including that value. 680 If the "lamp" action is supported, a child element with 681 a "lamp" 'action' is sent, with a 'supported-lamps' attribute set 682 to all supported lamp IDs. 684 If the "enable-camera" action is supported, a child 685 element with an "enable-camera" 'action' is sent, with a 686 'supported-cameras' attribute set to all supported camera IDs. 688 Examples: 689 690 692 693 695 9.1.2.2. Capabilities Example 696 697 703 704 705 708 709 710 711 712 714 716 Figure 5: Capabilities Example 718 9.1.3. The element 720 A element appears one or more times on its own or as a 721 child of a element. The following attributes and 722 child elements are defined: 724 9.1.3.1. Attributes of the element 726 The element has the following attributes: 728 Name: action 729 Usage: Mandatory 730 Type: token 731 Description: Identifies the action that the vehicle is requested to 732 perform. An IANA registry is established in Section 14.8.1 to 733 contain the allowed values. 734 Example: action="send-data" 736 Name: msgid 737 Usage: Conditional 738 Type: int 739 Description: Mandatory with a "msg-static" action. Indicates the 740 identifier of the static message to be displayed and/or spoken for 741 the vehicle occupants. This document established an IANA registry 742 for messages and their IDs, in Section 14.8.2 744 Example: msgid="3" 746 Name: persistance 747 Usage: Optional 748 Type: duration 749 Description: Specifies how long to carry on the specified action, 750 for example, how long to continue honking or flashing. If absent, 751 the default is indefinitely. 752 Example: persistance="PT1H" 754 Name: datatype 755 Usage: Conditional 756 Type: token 757 Description: Mandatory with a "send-data" action. Specifies the 758 data block that the IVS is requested to transmit, using the same 759 identifier as in the 'purpose' attribute set in a Call-Info header 760 field to point to the data block. Permitted values are contained 761 in the 'Emergency Call Data Types' IANA registry established in 762 [I-D.ietf-ecrit-additional-data]. 763 Example: datatype="eCall.MSD" 765 Name: supported-datatypes 766 Usage: Conditional 767 Type: string 768 Description: Used with a 'send-data' action in a element 769 that is a child of a element, this attribute lists 770 all data blocks that the vehicle can transmit, using the same 771 identifier as in the 'purpose' attribute in a Call-Info header 772 field to point to the data block. Permitted values are contained 773 in the 'Emergency Call Data Types' IANA registry established in 774 [I-D.ietf-ecrit-additional-data]. Multiple values are separated 775 with a semicolon. 776 Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo" 778 Name: lamp-action 779 Usage: Conditional 780 Type: token 781 Description: Used with a 'lamp' action, indicates if the lamp is to 782 be illuminated, turned off, or flashed. Permitted values are 783 'on', 'off', and 'flash'. 784 Example: lamp-action="flash" 786 Name: lamp-ID 787 Usage: Conditional 788 Type: token 789 Description: Used with a 'lamp' action, indicates which lamp the 790 action affects. Permitted values are contained in the registry of 791 lamp-ID tokens created in Section 14.8.4 793 Example: lamp-ID="hazard" 795 Name: supported-lamps 796 Usage: Conditional 797 Type: string 798 Description: Used with a 'lamp' action in a element that 799 is a child of a element, this attribute lists all 800 supported lamps, using values in the registry of lamp-ID tokens 801 created in Section 14.8.4. Multiple values are separated with a 802 semicolon. 803 Example: supported-lamps="head; interior; fog-front; fog-rear; 804 brake; position-front; position-rear; turn-left; turn-right; 805 hazard" 807 Name: camera-ID 808 Usage: Conditional 809 Type: token 810 Description: Used with an 'enable-camera' action, indicates which 811 camera to enable. Permitted values are contained in the registry 812 of camera-ID tokens created in Section 14.8.5. When a vehicle 813 camera is enabled, the IVS sends a re-INVITE to negotiate a one- 814 way media stream for the camera. 815 Example: camera-ID="backup" 817 Name: supported-cameras 818 Usage: Conditional 819 Type: string 820 Description: Used with an 'enable-camera' action in a 821 element that is a child of a element, this attribute 822 lists all cameras that the vehicle supports (can add as a video 823 feed in the current session), using the same identifiers as are 824 used in the 'camera-ID' attribute (contained in the camera ID 825 registry in Section 14.8.5). Multiple values are separated with a 826 semicolon. 827 Example: supported-cameras="backup; interior" 829 9.1.3.2. Child Elements of the element 831 The element has the following child elements: 833 Name: text 834 Usage: Conditional 835 Type: string 836 Description: Used within a element to 837 contain the text to be displayed and/or spoken (via text-to- 838 speech) for the vehicle occupants. 839 Example: Emergency authorities are aware of your incident and 840 location. Due to a multi-vehicle incident in your area, no one is 841 able to speak with you right now. Please remain calm. We will 842 assist you soon. 844 9.1.3.3. Request Example 846 847 853 854 856 857 858 Remain calm. Help is on the way. 859 861 863 Figure 6: Request Example 865 9.2. The emergencyCallData.eCall INFO package 867 This document registers the 'emergencyCallData.eCall' INFO package. 868 Both endpoints (the IVS and the PSAP equipment) set the Recv-Info 869 header field to 'emergencyCallData.eCall' per [RFC6086] to indicate 870 ability to receive INFO messages carrying eCall data or control 871 blocks. 873 Support for the 'emergencyCallData.eCall' INFO package indicates the 874 ability to receive eCall data and control blocks, which are carried 875 in a body part whose subtype starts with 'emergencyCallData.eCall.'. 876 At present there is only one defined eCall data block, which has the 877 'application/emergencyCallData.eCall.MSD+xml' MIME type, and one 878 eCall control block, which has the 'application/ 879 emergencyCallData.eCall.control+xml' MIME type. The eCall control 880 block includes the ability for the IVS to indicate its capabilities, 881 so in the event additional eCall blocks are defined, the IVS can 882 indicate which it supports. 884 The use of INFO is based on an analysis of the requirements against 885 the intent and effects of INFO versus other approaches (such as SIP 886 MESSAGE, media plane, or non-SIP protocols). In particular, the 887 transport of eCall data and control blocks is done only during an 888 emergency session established with SIP, using the mechanism 889 established in [I-D.ietf-ecrit-additional-data], and is normally 890 carried in the initial INVITE and its response; the use of INFO only 891 occurs when a data block or request needs to be sent subsequently 892 during the call. While MESSAGE could be used, it is not tied to a 893 SIP session as is INFO. REINVITE could also be used, but is normally 894 used to modify the session. SUBSCRIBE/NOTIFY could be coerced into 895 service, but the semantics are not a clean fit. Hence, INFO is 896 appropriate. 898 An INFO request message carrying an eCall data or control block has 899 an Info-Package header field set to 'emergencyCallData.eCall' per 900 [RFC6086]. The INFO request message is marked as containing the 901 eCall data or control block by a Call-Info header field containing a 902 CID URL referencing the unique identifier of the body part containing 903 the eCall data or control, and a 'purpose' parameter identifying the 904 block. Because the eCall data or control block is being carried in 905 an INFO request message, the body part also carries a Content- 906 Disposition header field set to "Info-Package". 908 Per [I-D.ietf-ecrit-additional-data], emergency call related 909 additional data MAY be included in any SIP request or response 910 message that can contain a body. Hence, notwithstanding 911 Section 4.3.2. of [RFC6086], INFO response messages MAY contain eCall 912 data or control blocks, provided they are included as described in 913 this document (with a Call-Info header field containing a CID URL 914 referencing the unique identifier of the body part, and a 'purpose' 915 parameter identifying the block). When eCall data or control blocks 916 are included in an INFO response message, this is done per 917 [I-D.ietf-ecrit-additional-data] and this document, and not under 918 [RFC6086]; that is, they are included as emergency call additional 919 data, not as an INFO package associated data. 921 10. Examples 923 Figure 7 shows an eCall. The call uses the request URI 924 'urn:service:sos.ecall.automatic' service URN and is recognized as an 925 eCall, and further as one that was invoked automatically by the IVS 926 due to a crash or other serious incident. In this example, the 927 originating network routes the call to an ESInet (as for any 928 emergency call in an environment with an ESInet). The ESInet routes 929 the call to the appropriate NG-eCall capable PSAP. The emergency 930 call is received by the ESInet's Emergency Services Routing Proxy 931 (ESRP), as the entry point into the ESInet. The ESRP routes the call 932 to a PSAP, where it is received by a call taker. In deployments 933 where there is no ESInet, the originating network routes the call 934 directly to the appropriate NG-eCall capable PSAP. 936 +------------+ +---------------------------------------+ 937 | | | +-------+ | 938 | | | | PSAP2 | | 939 | | | +-------+ | 940 | | | | 941 | | | +------+ +-------+ | 942 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 943 | | | +------+ +-------+ | 944 | | | | 945 | | | +-------+ | 946 | | | | PSAP3 | | 947 | Originating| | +-------+ | 948 | Mobile | | | 949 | Network | | ESInet | 950 +------------+ +---------------------------------------+ 952 Figure 7: Example of NG-eCall Message Flow 954 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 955 contains an MSD and an eCall control block with vehicle capabilities. 956 For simplicity, the example does not show all SIP headers, nor does 957 it show the additional data blocks added by the IVS and the 958 originating mobile network. 960 INVITE urn:service:sos.ecall.automatic SIP/2.0 961 To: urn:service:sos.ecall.automatic 962 From: ;tag=9fxced76sl 963 Call-ID: 3848276298220188511@atlanta.example.com 964 Geolocation: 965 Geolocation-Routing: no 966 Call-Info: cid:1234567890@atlanta.example.com; 967 purpose=emergencyCallData.eCall.MSD; 968 cid:2345678901@atlanta.example.com; 969 purpose=emergencyCallData.eCall.control; 970 Accept: application/sdp, application/pidf+xml, 971 application/emergencyCallData.eCall.control 972 CSeq: 31862 INVITE 973 Recv-Info: emergencyCallData.eCall 974 Content-Type: multipart/mixed; boundary=boundary1 975 Content-Length: ... 977 --boundary1 978 Content-Type: application/sdp 980 ...Session Description Protocol (SDP) goes here... 982 --boundary1 983 Content-Type: application/emergencyCallData.eCall.MSD+xml 984 Content-ID: 1234567890@atlanta.example.com 985 Content-Disposition: by-reference;handling=optional 987 988 1 990 991 993 1 995 996 997 998 999 1000 1002 1003 WMI 1004 VDSVDS 1005 Y 1006 A123456 1007 1009 1010 1011 1012 1014 123456789 1016 1017 173881200 1018 41822520 1019 1021 14 1023 1024 10 1025 -10 1026 1028 1029 10 1030 -20 1031 1032 2 1034 1036 1037 1.2.125 1038 30304646 1039 1040 1041 1043 --boundary1 1044 Content-Type: application/emergencyCallData.eCall.control+xml 1045 Content-ID: 2345678901@atlanta.example.com 1046 Content-Disposition: by-reference;handling=optional 1048 1049 1055 1056 1057 1061 1062 1063 1064 1066 1068 1070 --boundary1-- 1072 Figure 8: SIP NG-eCall INVITE 1074 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1075 the INVITE of Figure 8, containing an eCall control block 1076 acknowledging successful receipt of the eCall MSD. (For simplicity, 1077 the example does not show all SIP headers.) 1078 SIP/2.0 200 OK 1079 To: ;tag=9fxced76sl 1080 From: Exemplar PSAP 1081 Call-ID: 3848276298220188511@atlanta.example.com 1082 Call-Info: cid:2345678901@atlanta.example.com; 1083 purpose=emergencyCallData.eCall.control; 1084 Accept: application/sdp, application/pidf+xml, 1085 application/emergencyCallData.eCall.control, 1086 application/emergencyCallData.eCall.MSD 1087 CSeq: 31862 INVITE 1088 Recv-Info: emergencyCallData.eCall 1089 Content-Type: multipart/mixed; boundary=boundaryX 1090 Content-Length: ... 1092 --boundaryX 1093 Content-Type: application/sdp 1095 ...Session Description Protocol (SDP) goes here... 1097 --boundaryX 1098 Content-Type: application/EmergencyCallData:eCall-control+xml 1099 Content-ID: 2345678901@atlanta.example.com 1100 Content-Disposition: by-reference;handling=optional 1102 1103 1109 1111 1113 --boundaryX-- 1115 Figure 9: 200 OK response to INVITE 1117 11. Security Considerations 1119 The security considerations described in [RFC5069] apply here. 1121 In addition to any network-provided location that is inherently 1122 permitted for IMS emergency calls (which might be determined solely 1123 by the network, or in cooperation with or possibly entirely by the 1124 originating device), an eCall carries an IVS-supplied location within 1125 the MSD. This is likely to be useful to the PSAP, especially when 1126 the two locations are independently determined. Even in situations 1127 where the network-supplied location is limited to the cell site, this 1128 can be useful as a sanity check on the device-supplied location 1129 contained in the MSD. 1131 The document [RFC7378] discusses trust issues regarding location 1132 provided by or determined in cooperation with end devices. 1134 Security considerations specific to the mechanism by which the PSAP 1135 sends acknowledgments and requests to the vehicle are discussed in 1136 the "Security Considerations" block of Section 14.3. In addition to 1137 that discussion, it's important to note that vehicles MAY decline to 1138 carry out any requested action, e.g., if the vehicle is unable to 1139 verify the certificate used to sign the request. The vehicle MAY use 1140 any value in the reason registry in Section 14.8.3 to indicate why it 1141 did not take an action (e.g., the generic "unable" or the more 1142 specific "security-failure"). 1144 Data received from external sources inherently carries implementation 1145 risks including buffer overflows, which in many platforms can 1146 introduce remote code execution vulnerabilities; null characters can 1147 corrupt strings, numeric values used for internal calculations can 1148 result in underflow/overflow errors; malformed XML objects can expose 1149 parsing bugs, etc. Implementations need to be cognizant of the 1150 potential risks, observe best practices (e.g., good quality static 1151 code analysis, fuzz testing, component isolation, avoiding use of 1152 unsafe coding techniques, third-party attack tests, signed software, 1153 over-the-air updates, etc.), and have multiple levels of protection. 1154 Implementors need to be aware that, potentially, the data objects 1155 described here and elsewhere might be malformed, might contain 1156 unexpected characters, excessively long attribute values, elements, 1157 etc. (This applies across the board, not just to the 'text' 1158 attribute of a element.) 1160 Since this document depends on [I-D.ietf-ecrit-additional-data], the 1161 security considerations discussed there apply here (see especially 1162 the discussion of TLS, TLS versions, cypher suites, and PKI). 1164 When vehicle data or control/metadata is contained in a signed or 1165 encrypted body part, the enclosing multipart (e.g., multipart/signed 1166 or multipart/encrypted) has the same Content-ID as the data part. 1167 This allows an entity to identify and access the data blocks it is 1168 interested in without having to dive deeply into the message 1169 structure or decrypt parts it is not interested in. (The 'purpose' 1170 parameter in a Call-Info header field identifies the data, and the 1171 CID URL points to the data block in the body, which has a matching 1172 Content-ID body part header field). 1174 12. Privacy Considerations 1176 Since this document builds on [I-D.ietf-ecrit-additional-data], the 1177 data structures specified there, and the corresponding privacy 1178 considerations discussed there, apply here as well. The MSD carries 1179 some additional identifying and personal information (mostly about 1180 the vehicle and less about the owner), as well as location 1181 information, and so needs to be protected against unauthorized 1182 disclosure. Local regulations may impose additional privacy 1183 protection requirements. The additional functionality enabled by 1184 this document, such as access to vehicle camera streams, carries a 1185 burden of protection and so implementations need to be careful that 1186 access is only provided within the context of an emergency call and 1187 to an emergency services provider, for example, by verifying that the 1188 request for camera access is signed by a certificate issued by an 1189 emergency services registrar. 1191 Privacy considerations specific to the data structure containing 1192 vehicle information are discussed in the "Security Considerations" 1193 block of Section 14.2. 1195 Privacy considerations specific to the mechanism by which the PSAP 1196 sends acknowledgments and requests to the vehicle are discussed in 1197 the "Security Considerations" block of Section 14.3. 1199 13. XML Schema 1201 This section defines the XML schema of the eCall control block. (The 1202 schema for the MSD can be found in EN 15722 [msd].) 1204 1205 1213 1216 1219 1220 1221 1222 1223 1225 1226 1227 1230 1231 1232 1233 1234 1236 1237 1238 1239 1240 1242 1243 1246 1249 1251 1252 conditionally 1253 mandatory when @success='false" 1254 to indicate reason code for a 1255 failure 1256 1257 1258 1260 1261 1262 1263 1266 1267 1270 1272 1273 1274 1275 1277 1278 1279 1280 1281 1285 1288 1289 1290 1291 1292 1294 1295 1296 1297 1298 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1327 1329 Figure 10: eCall Control Block Schema 1331 14. IANA Considerations 1333 14.1. Service URN Registrations 1335 IANA is requested to register the URN 'urn:service:sos.ecall' under 1336 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1338 This service identifies a type of emergency call (placed by a 1339 specialized in-vehicle system and a carrying standardized set of data 1340 related to the vehicle and crash or incident, and is needed to direct 1341 the call to a specialized public safety answering point (PSAP) with 1342 technical and operational capabilities to handle such calls. Two 1343 sub-services are registered as well, namely 1345 urn:service:sos.ecall.manual 1347 This service URN indicates that an eCall had been triggered based 1348 on the manual interaction of the driver or a passenger. 1350 urn:service:sos.ecall.automatic 1352 This service URN indicates that an eCall had been triggered 1353 automatically, for example, due to a crash or other serious 1354 incident (e.g., fire). 1356 IANA is also requested to register the URN 1357 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1358 defined in Setcion 17.2 of [RFC6881]. 1360 14.2. MIME Content-type Registration for 'application/ 1361 emergencyCallData.eCall.MSD+xml' 1363 IANA is requested to add application/emergencyCallData.eCall.MSD+xml 1364 as a MIME content type, with a reference to this document, in 1365 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1366 RFC 7303 [RFC7303]. 1368 MIME media type name: application 1370 MIME subtype name: emergencyCallData.eCall.MSD+xml 1372 Mandatory parameters: none 1374 Optional parameters: charset 1376 Indicates the character encoding of the XML content. 1378 Encoding considerations: Uses XML, which can employ 8-bit 1379 characters, depending on the character encoding used. See 1380 Section 3.2 of RFC 7303 [RFC7303]. 1382 Security considerations: This content type is designed to carry 1383 vehicle and incident-related data during an emergency call. This 1384 data contains personal information including vehicle VIN, 1385 location, direction, etc. Appropriate precautions need to be 1386 taken to limit unauthorized access, inappropriate disclosure to 1387 third parties, and eavesdropping of this information. In general, 1388 it is permissible for the data to be unprotected while briefly in 1389 transit within the Mobile Network Operator (MNO); the MNO is 1390 trusted to not permit the data to be accessed by third parties. 1391 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1392 contain more discussion. 1394 Interoperability considerations: None 1396 Published specification: Annex C of EN 15722 [msd] 1398 Applications which use this media type: Pan-European eCall 1399 compliant systems 1401 Additional information: None 1403 Magic Number: None 1405 File Extension: .xml 1407 Macintosh file type code: 'TEXT' 1408 Person and email address for further information: Hannes 1409 Tschofenig, Hannes.Tschofenig@gmx.net 1411 Intended usage: LIMITED USE 1413 Author: This specification was produced by the European Committee 1414 For Standardization (CEN). For contact information, please see 1415 . 1417 Change controller: The European Committee For Standardization 1418 (CEN) 1420 14.3. MIME Content-type Registration for 'application/ 1421 emergencyCallData.eCall.control+xml' 1423 IANA is requested to add application/ 1424 emergencyCallData.eCall.control+xml as a MIME content type, with a 1425 reference to this document, in accordance to the procedures of RFC 1426 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1428 MIME media type name: application 1430 MIME subtype name: emergencyCallData.eCall.control+xml 1432 Mandatory parameters: none 1434 Optional parameters: charset 1436 Indicates the character encoding of the XML content. 1438 Encoding considerations: Uses XML, which can employ 8-bit 1439 characters, depending on the character encoding used. See 1440 Section 3.2 of RFC 7303 [RFC7303]. 1442 Security considerations: 1444 This content type carries metadata and control information and 1445 requests, primarily from a Public Safety Answering Point (PSAP) 1446 to an In-Vehicle System (IVS) during an emergency call, and 1447 also capabilities from the IVS to the PSAP. 1449 Metadata (such as an acknowledgment that data sent by the IVS 1450 to the PSAP was successfully received) has limited privacy and 1451 security implications. Control information (such as requests 1452 from the PSAP that the vehicle perform an action) has some 1453 privacy and important security implications. The privacy 1454 concern arises from the ability to request the vehicle to 1455 transmit a data set, which as described in Section 14.2, can 1456 contain personal information. The security concern is the 1457 ability to request the vehicle to perform an action. It is 1458 important that control information originate only from a PSAP 1459 or other emergency services provider, and not be modified en- 1460 route. The level of integrity of the cellular network over 1461 which the emergency call is placed is important: when the IVS 1462 initiates an eCall over a cellular network, it relies on the 1463 MNO to route the call to a PSAP. (Calls placed using other 1464 means, such as Wi-Fi or over-the-top services, generally incur 1465 higher levels of risk than calls placed over cellular 1466 networks.) A call-back from a PSAP incurs additional risk, 1467 since the current mechanisms are not ideal for verifying that 1468 such a call is indeed a call-back from a PSAP in response to an 1469 emergency call placed by the IVS. See the discussion in 1470 Section 11 and the PSAP Callback document [RFC7090]. One 1471 safeguard, applicable regardless of which end initiated the 1472 call and the means of the call, is for the PSAP or emergency 1473 service provider to sign the body part using a certificate 1474 issued by a known emergency services certificate authority and 1475 for which the IVS can verify the root certificate. 1477 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1478 contain more discussion. 1480 Interoperability considerations: None 1482 Published specification: Annex C of EN 15722 [msd] 1484 Applications which use this media type: Pan-European eCall 1485 compliant systems 1487 Additional information: None 1489 Magic Number: None 1491 File Extension: .xml 1493 Macintosh file type code: 'TEXT' 1495 Person and email address for further information: Randall Gellens, 1496 rg+ietf@qti.qualcomm.com 1498 Intended usage: LIMITED USE 1500 Author: The IETF ECRIT WG. 1502 Change controller: The IETF ECRIT WG. 1504 14.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1505 Additional Data Blocks registry 1507 This specification requests IANA to add the 'eCall.MSD' entry to the 1508 Emergency Call Additional Data Blocks registry (established by 1509 [I-D.ietf-ecrit-additional-data]), with a reference to this document. 1511 14.5. Registration of the 'eCall.control' entry in the Emergency Call 1512 Additional Data Blocks registry 1514 This specification requests IANA to add the 'eCall.control' entry to 1515 the Emergency Call Additional Data Blocks registry (established by 1516 [I-D.ietf-ecrit-additional-data]), with a reference to this document. 1518 14.6. Registration of the emergencyCallData.eCall Info Package 1520 IANA is requested to add emergencyCallData.eCall to the Info Packages 1521 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1522 reference to this document. 1524 14.7. URN Sub-Namespace Registration 1526 14.7.1. Registration for urn:ietf:params:xml:ns:eCall 1528 This section registers a new XML namespace, as per the guidelines in 1529 RFC 3688 [RFC3688]. 1531 URI: urn:ietf:params:xml:ns:eCall 1533 Registrant Contact: IETF, ECRIT working group, , as 1534 delegated by the IESG . 1536 XML: 1538 BEGIN 1539 1540 1542 1543 1544 1546 Namespace for eCall Data 1547 1548 1549

Namespace for eCall Data

1550

See [TBD: This document].

1551 1552 1553 END 1555 14.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1557 This section registers a new XML namespace, as per the guidelines in 1558 RFC 3688 [RFC3688]. 1560 URI: urn:ietf:params:xml:ns:eCall:control 1562 Registrant Contact: IETF, ECRIT working group, , as 1563 delegated by the IESG . 1565 XML: 1567 BEGIN 1568 1569 1571 1572 1573 1575 Namespace for eCall Data: 1576 Control Block 1577 1578 1579

Namespace for eCall Data

1580

Control Block

1581

See [TBD: This document].

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