idnits 2.17.00 (12 Aug 2021) /tmp/idnits55320/draft-ietf-ecrit-ecall-03.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 (July 4, 2015) is 2512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5491' is defined on line 1897, but no explicit reference was found in the text == Unused Reference: 'RFC6442' is defined on line 1906, but no explicit reference was found in the text -- 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-trustworthy-location has been published as RFC 7378 Summary: 2 errors (**), 0 flaws (~~), 4 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: January 5, 2016 6 July 4, 2015 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-03.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 January 5, 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 . . . . . . . . . . . . . . . . 16 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. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 13.1. Service URN Registrations . . . . . . . . . . . . . . . 29 99 13.2. MIME Content-type Registration for 100 'application/emergencyCallData.eCall.MSD+xml' . . . . . 30 101 13.3. MIME Content-type Registration for 102 'application/emergencyCallData.eCall.control+xml' . . . 31 103 13.4. Registration of the 'eCall.MSD' entry in the Emergency 104 Call Additional Data Blocks registry . . . . . . . . . . 32 105 13.5. Registration of the 'eCall.control' entry in the 106 Emergency Call Additional Data Blocks registry . . . . . 33 107 13.6. Registration of the emergencyCallData.eCall Info Package 33 108 13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33 109 13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33 110 13.7.2. Registration for 111 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34 112 13.8. Registry creation . . . . . . . . . . . . . . . . . . . 34 113 13.8.1. eCall Control Action Registry . . . . . . . . . . . 34 114 13.8.2. eCall Static Message Registry . . . . . . . . . . . 35 115 13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 36 116 13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 37 117 13.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 38 118 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 119 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 120 16. Changes from Previous Versions . . . . . . . . . . . . . . . 39 121 16.1. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 122 16.2. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 123 16.3. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 124 16.4. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 40 125 16.5. Changes from draft-gellens-02 to -03 . . . . . . . . . . 40 126 16.6. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 127 16.7. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 128 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 129 17.1. Normative References . . . . . . . . . . . . . . . . . . 41 130 17.2. Informative references . . . . . . . . . . . . . . . . . 42 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 133 1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 This document re-uses terminology defined in Section 3 of [RFC5012]. 141 Additionally, we use the following abbreviations: 143 +--------+----------------------------------------+ 144 | Term | Expansion | 145 +--------+----------------------------------------+ 146 | 3GPP | 3rd Generation Partnership Project | 147 | CEN | European Committee for Standardization | 148 | EENA | European Emergency Number Association | 149 | ESInet | Emergency Services IP network | 150 | IMS | Internet Multimedia Subsystem | 151 | IVS | In-Vehicle System | 152 | MNO | Mobile Network Operator | 153 | MSD | Minimum Set of Data | 154 | PSAP | Public Safety Answering Point | 155 +--------+----------------------------------------+ 157 2. Document Scope 159 This document is limited to the signaling, data exchange, and 160 protocol needs of next-generation eCall (NG-eCall, also referred to 161 as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP 162 framework for emergency calls, as described in [RFC6443] and 163 [RFC6881]. eCall itself is specified by 3GPP and CEN and these 164 specifications include far greater scope than is covered here. 166 The eCall service operates over cellular wireless communication, but 167 this document does not address cellular-specific details, nor client 168 domain selection (e.g., circuit-switched versus packet-switched). 169 All such aspects are the purview of their respective standards 170 bodies. The scope of this document is limited to eCall operating 171 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 173 The technical contents of this document may be suitable for use in 174 other vehicle-initiated emergency call systems, but this is out of 175 scope for this document. 177 Vehicles designed for multiple regions may need to support eCall and 178 other Advanced Automatic Crash Notification systems, such as 179 described in [draft-ietf-ecrit-car-crash]. That system is compatible 180 with eCall, differing primarily in the specific data set that is 181 sent. 183 3. Introduction 185 Emergency calls made from vehicles (e.g., in the event of a crash) 186 assist in significantly reducing road deaths and injuries by allowing 187 emergency services to be aware of the incident, the state of the 188 vehicle, the location of the vehicle, and to have a voice channel 189 with the vehicle occupants. This enables a quick and appropriate 190 response. 192 The European Commission initiative of eCall was conceived in the late 193 1990s, and has evolved to a European Parliament decision requiring 194 the implementation of compliant in-vehicle systems (IVS) in new 195 vehicles and the deployment of eCall in the European Member States in 196 the very near future. eCall (and eCall-compatible systems) are also 197 being adopted in other regions. 199 The pan-European eCall system provides a standardized and mandated 200 mechanism for emergency calls by vehicles. eCall establishes 201 procedures for such calls to be placed by in-vehicle systems, 202 recognized and processed by the network, and routed to a specialized 203 PSAP where the vehicle data is available to assist the call taker in 204 assessing and responding to the situation. eCall provides a standard 205 set of vehicle, sensor (e.g., crash related), and location data. 207 An eCall may be either user-initiated or automatically triggered. 208 Automatically triggered eCalls indicate a car crash or some other 209 serious incident and carry a greater presumption of risk of injury. 210 Manually triggered eCalls may be reports of serious hazards and are 211 likely to require a different response than an automatically 212 triggered eCall. Manually triggered eCalls are also more likely to 213 be false (e.g., accidental) calls and may thus be subject to 214 different handling by the PSAP. 216 Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) 217 as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in 218 the call setup mark the call as an eCall, and further indicate if the 219 call was automatically or manually triggered. The call is routed to 220 an eCall-capable PSAP, a voice channel is established between the 221 vehicle and the PSAP, and an eCall in-band modem is used to carry a 222 defined set of vehicle, sensor (e.g., crash related), and location 223 data (the Minimum Set of Data or MSD) within the voice channel. The 224 same in-band mechanism is used for the PSAP to acknowledge successful 225 receipt of the MSD, and to request the vehicle to send a new MSD 226 (e.g., to check if the state of or location of the vehicle or its 227 occupants has changed). Work on next-generation eCall (NG-eCall, 228 also referred to as packet-switched eCall or PS eCall) is now in 229 process. As part of this work, the European Telecommunications 230 Standards Institute (ETSI) [SDO-ETSI] has published a Technical 231 Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] 232 that presents findings and recommendations regarding support for 233 eCall in an all-IP environment. NG-eCall moves from circuit switched 234 to all-IP, and carries the vehicle data and other eCall-specific data 235 as additional data associated with the call. This document describes 236 how IETF mechanisms for IP-based emergency calls, including [RFC6443] 237 and [additional-data-draft] are used to provide the signaling and 238 data exchange of the next generation of pan-European eCall. 240 The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency 241 calling with additional elements identifying the call as an eCall and 242 as carrying eCall data and with mechanisms for carrying the data. 243 3GPP IMS emergency services support multimedia, providing the ability 244 to carry voice, text, and video. This capability is referred to 245 within 3GPP as Multimedia Emergency Services (MMES). 247 A transition period will exist during which time the various entities 248 involved in initiating and handling an eCall might support next- 249 generation eCall, legacy eCall, or both. This transition period 250 might last several years or longer. The issue of migration/co- 251 existence during the transition period is very important but is 252 outside the scope of this document. The ETSI TR "Mobile Standards 253 Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in 254 Clause 7. 256 4. eCall Requirements 258 Overall eCall requirements are specified by CEN in [EN_16072] and by 259 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements specific to 260 vehicle data are contained in EN 15722 [msd]. For convenience, the 261 requirements most applicable to the limited scope of this document 262 are summarized very briefly below. 264 eCall requires: 266 o The call be recognized as an eCall (which is inherently an 267 emergency call) 268 o The call setup indicates if the call was manually or automatically 269 triggered 270 o A voice channel between the vehicle and the PSAP 271 o Carrying the MSD intrinsically with the call (the MSD needs to be 272 available to the same call-taker as the voice) 273 o The ability for the PSAP to acknowledge receipt of the MSD 274 o The ability for the PSAP to request that the vehicle generate and 275 transmit a new MSD 276 o The ability of the PSAP to be able to re-contact the occupants of 277 vehicle after the initial eCall is concluded 278 o The ability to perform a test call (which may be routed to a PSAP 279 but is not treated as an emergency call and not handled by a call 280 taker) 282 It is recognized that NG-eCall offers many potential enhancements, 283 although these are not required by current EU regulations. For 284 convenience, the enhancements most applicable to the limited scope of 285 this document are summarized very briefly below. 287 NG-eCall is expected to offer: 289 o The ability to carry more data (e.g., an enhanced MSD or an MSD 290 plus additional sets of data) 291 o The ability to handle video 292 o The ability to handle text 293 o The ability for the PSAP to access vehicle components (e.g., an 294 onboard camera (such as rear facing or blind-spot cameras) for a 295 visual assessment of the crash site situation) 296 o The ability for the PSAP to request the vehicle to take actions 297 (e.g., sound the horn, disable the ignition, lock/unlock doors) 298 o The ability to avoid audio muting of the voice channel (because 299 the MSD is not transferred using an in-band modem) 301 5. Vehicle Data 303 Pan-European eCall provides a standardized and mandated set of 304 vehicle related data, known as the Minimum Set of Data (MSD). The 305 European Committee for Standardization (CEN) has specified this data 306 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 307 MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML 308 encoding is better suited for use in SIP messages and is used in this 309 document. (The ASN.1 encoding is specified in Annex A of EN 15722 310 [msd], while the XML encoding is specified in Annex C.) 312 The "Additional Data related to an Emergency Call" document 313 [additional-data-draft] establishes a general mechanism for attaching 314 blocks of data to a SIP emergency call. This document makes use of 315 that mechanism to carry the eCall MSD in a SIP emergency call. 317 This document registers the 'application/ 318 emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD 319 to be carried in SIP. This document also adds the 'eCall.MSD' entry 320 to the Emergency Call Additional Data Blocks registry (established by 321 [additional-data-draft]) to enable the MSD to be recognized as such 322 in a SIP-based eCall emergency call. 324 Note that if additional data sets are defined and registered (e.g., 325 in the future or in other regions) and transmitted using the same 326 mechanisms, the size and frequency of transmission during a session 327 needs to be evaluated to be sure it is appropriate to use the 328 signaling channel. 330 6. Call Setup 332 In circuit-switched eCall, the IVS places a special form of a 112 333 emergency call which carries an eCall flag (indicating that the call 334 is an eCall and also if the call was manually or automatically 335 triggered); the mobile network operator (MNO) recognizes the eCall 336 flag and routes the call to an eCall-capable PSAP; vehicle data is 337 transmitted to the PSAP via the eCall in-band modem (in the voice 338 channel). 340 ///----\\\ 112 voice call with eCall flag +------+ 341 ||| IVS |||---------------------------------------->+ PSAP | 342 \\\----/// vehicle data via eCall in-band modem +------+ 344 Figure 1: circuit-switched eCall 346 An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD 347 in accordance with [additional-data-draft] by encoding it as 348 specified (per Appendix C of EN 15722 [msd]) and attaching it to an 349 INVITE as a MIME body part. The body part is identified by its MIME 350 content-type ('application/emergencyCallData.eCall.MSD+xml') in the 351 Content-Type header field of the body part. The body part is 352 assigned a unique identifier which is listed in a Content-ID header 353 field in the body part. The INVITE is marked as containing the MSD 354 by adding (or appending to) a Call-Info header field at the top level 355 of the INVITE. This Call-Info header field contains a CID URL 356 referencing the body part's unique identifier, and a 'purpose' 357 parameter identifying the data as the eCall MSD per the registry 358 entry; the 'purpose' parameter's value is 'emergencyCallData.' and 359 the root of the MIME type (not including the 'emergencyCallData' 360 prefix and any suffix such as '+xml' (e.g., 361 'purpose=emergencyCallData.eCall.MSD'). 363 For NG-eCall, the IVS establishes an emergency call using the 3GPP 364 IMS solution with a Request-URI indicating an eCall type of emergency 365 call and with vehicle data attached; the MNO or ESInet recognizes the 366 eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP 367 interpets the vehicle data sent with the call and makes it available 368 to the call taker. 370 ///----\\\ IMS emergency call with eCall URN +------+ 371 IVS ----------------------------------------->+ PSAP | 372 \\\----/// vehicle data included in call setup +------+ 374 Figure 2: NG-eCall 376 This document registers new service URN children within the "sos" 377 subservice. These URNs provide the mechanism by which an eCall is 378 identified, and differentiate between manually and automatically 379 triggered eCalls (which may be subject to different treatment, 380 depending on policy). The two service URNs are: 381 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 383 7. Call Routing 385 The routing rules for eCalls are likely to differ from those of other 386 emergency calls because eCalls are special types of emergency calls 387 (with implications for the types of response required) and need to be 388 handled by specially designated PSAPs. In an environment that uses 389 ESInets, the originating network passes all types of emergency calls 390 to an ESInet (which have a request URI containing the "SOS" service 391 URN). The ESInet is then responsible for routing such calls to the 392 appropriate PSAP. In an environment without an ESInet, the emergency 393 services authorities and the originating network jointly determine 394 how such calls are routed. 396 7.1. ESInets 398 This section provides background information on ESInets for 399 information only. 401 An Emergency Services IP Network (ESInet) is a network operated by 402 emergency services authorities. It handles emergency call routing 403 and processing before delivery to a PSAP. In the NG1-1-2 404 architecture adopted by EENA, each PSAP is connected to one or more 405 ESInets. Each originating network is also connected to one or more 406 ESInets. The ESInets maintain policy-based routing rules which 407 control the routing and processing of emergency calls. The 408 centralization of such rules within ESInets provides for a cleaner 409 separation between the responsibilities of the originating network 410 and that of the emergency services network, and provides greater 411 flexibility and control over processing of emergency calls by the 412 emergency services authorities. This makes it easier to react 413 quickly to unusual situations that require changes in how emergency 414 calls are routed or handled (e.g., a natural disaster closes a PSAP), 415 as well as ease in making long-term changes that affect such routing 416 (e.g., cooperative agreements to specially handle calls requiring 417 translation or relay services). ESInets may support the ability to 418 interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that 419 are not IP PSAPs (similarly to the ability to interwork IP emergency 420 calls to legacy non-IP PSAPs). Note that in order to support legacy 421 eCall-capable PSAPs that are not IP PSAPs and are not attached to an 422 ESInet, an originating network may need the ability to route an eCall 423 itself (e.g., to an interworking facility with interconnection to a 424 suitable legacy eCall capable PSAP) based on the eCall and manual or 425 automatic indications. The ETSI TR "Mobile Standards Group (MSG); 426 eCall for VoIP" [MSG_TR] discusses transition issues in Clause 7. 428 8. Test Calls 430 eCall requires the ability to place test calls. These are calls that 431 are recognized and treated to some extent as eCalls but are not given 432 emergency call treatment and are not handled by call takers. The 433 test call facility allows the IVS or user to verify that an eCall can 434 be successfully established with voice communication. The IVS can 435 also verify that the MSD was successfully received. 437 A service URN starting with "test." indicates a test call. For 438 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 439 This functionality is defined in [RFC6881]. 441 This document registers "urn:service:test.sos.ecall" for eCall test 442 calls. 444 the current eCall test call facility is a non-emergency number so 445 does not get treated as an emergency call. MNOs may treat a vehicle 446 call in the "test" service URN in a way that tests as much 447 functionality as desired, but this is outside the scope of this 448 document. 450 PSAPs that have the ability to process NG-eCalls SHOULD accept test 451 calls and send an acknowledgment if the MSD was successfully 452 received, per this document. Such PSAPs MAY also play an audio clip 453 (for example, saying that the call reached a PSAP) in addition to 454 supporting media loopback per [RFC6881]. 456 9. eCall-Specific Control/Metadata 458 eCall requires the ability for the PSAP to acknowledge successful 459 receipt of an MSD sent by the IVS, and for the PSAP to request that 460 the IVS send an MSD (e.g., the call taker may initiate a request for 461 a new MSD to see if the vehicle's state or location has changed). 462 Future enhancements are desired to enable the PSAP to send other 463 requests to the vehicle, such as locking or unlocking doors, sounding 464 the horn, flashing the lights, starting a video stream from on-board 465 cameras (such as rear focus or blind-spot), etc. 467 The mechanism established in [additional-data-draft], used in 468 Section 5 of this document to carry the MSD from the IVS to the PSAP, 469 is also used to carry a block of control data from the PSAP to the 470 IVS. This eCall control block (sometimes referred to as eCall 471 metadata) is an XML structure containing eCall-specific elements. 472 When the PSAP needs to send an eCall control block that is in 473 response to the MSD or other data sent by the IVS in a SIP request, 474 the control block can be sent in the SIP response to that request 475 (e.g., the INVITE). When the PSAP needs to send an eCall control 476 block that is not an immediate response to an MSD or other data sent 477 by the IVS, the control block can be transmitted from the PSAP to the 478 IVS in a SIP INFO message within the established session. The IVS 479 can then send any requested data (such as a new MSD) in the reply to 480 the INFO message. This mechanism flexibly allows the PSAP to send 481 eCall-specific data to the IVS and the IVS to respond. If control 482 data sent in a response message requests the IVS to send a new MSD or 483 other data block, or to perform an action other than sending data, 484 the IVS can send the requested data or an acknowledgment regarding 485 the action in an INFO message within the session (it could also use 486 re-INVITE but that is unnecessary when no aspect of the session or 487 media is changing). 489 This mechanism requires 491 o An XML definition of the eCall control object 492 o An extension mechanism by which new elements can be added to the 493 control object definition (e.g., permitting additional elements to 494 be included by adding their namespace) 495 o A MIME type registration for the control object (so it can be 496 carried in SIP messages and responses) 497 o An entry in the Emergency Call Additional Data Blocks sub-registry 498 (established by [additional-data-draft]) so that the control block 499 can be recognized as emergency call specific data within the SIP 500 messages 501 o An Info-Package registration per [RFC6086] permitting the control 502 block within Info messages 504 9.1. The eCall Control Block 506 The eCall control block is an XML data structure allowing for 507 acknowledgments, requests, and capabilities information. It is 508 carried in a SIP body part with a specific MIME content type. Three 509 top-level elements are defined for use within an eCall control block: 511 ack Used in a control block sent by either side. The PSAP 512 uses this to acknowledge receipt of data set sent by 513 the IVS. The IVS uses this to acknowledge receipt of a 514 request by the PSAP when that request would not 515 otherwise be acknowledged (if the PSAP requests the 516 vehicle to send data and the vehicle does so, the data 517 serves as a success acknowledgement). 519 capabilities: Used in a control block sent from the IVS to the PSAP 520 (e.g., in the initial INVITE) to inform the PSAP of the 521 vehicle capabilities. Child elements contain all 522 actions and data types supported by the vehicle and all 523 available lamps (lights) and cameras. 525 request Used in a control block sent by the PSAP to the IVS, to 526 request the vehicle to perform an action. 528 Mandatory Actions (the IVS and the PSAP MUST support): 530 o Transmit data object 532 Optional Actions (the IVS and the PSAP MAY support): 534 o Play and/or display static (pre-defined) message 535 o Speak/display dynamic text (text supplied in action) 536 o Flash or turn on or off a lamp (light) 537 o Honk horn 538 o Enable a camera 540 The element indicates the object being acknowledged (i.e., a 541 data object or a element), and reports success or failure. 543 The element has child elements to indicate 544 the actions supported by the IVS. 546 The element contains attributes to indicate the request and 547 to supply any needed information, and MAY contain a child 548 element to contain the text for a dynamic message. The 'action' 549 attribute is mandatory and indicates the specific action. An IANA 550 registry is created in Section 13.8.1 to contain the allowed values. 552 Extensibility: New elements, child elements, and attributes can be 553 defined in new namespaces. IANA registries are used to specify the 554 permitted values of several elements and attributes. These 555 mechanisms allow for extension. 557 The control block does not contain a 'request' action to play dynamic 558 media (such as a pre-recorded audio message). The SIP re-INVITE 559 mechanism can be used to establish a one-way media stream for this 560 purpose. 562 9.1.1. The element 564 The element is transmitted by the PSAP to acknowledge receipt 565 of an eCall data object. An element sent by a PSAP references 566 the unique ID of the data object that was sent by the IVS, and 567 further indicates if the PSAP considers the receipt successful or 568 not. The element is also transmitted by the IVS to the PSAP to 569 acknowledge receipt of a element that requested the IVS to 570 perform an action other than transmitting a data object (e.g., a 571 request to display a message would be acknowledged, but a request to 572 transmit a data object would not result in a separate element 573 being sent, since the data object itself serves as acknowledgment.) 574 An element sent by an IVS references the unique ID of the 575 request being acknowledged, indicates whether the request was 576 successfully performed, and if not, optionally includes an 577 explanation. 579 The element has the following attributes and child elements: 581 9.1.1.1. Attributes of the element 583 The element has the following attributes: 585 Name: ref 586 Usage: Mandatory 587 Type: anyURI 588 Description: References the Content-ID of the body part that 589 contained the data object or control object being acknowledged. 590 Example: 592 Name: received 593 Usage: Conditional: mandatory in an >ack< element sent by a PSAP; 594 not applicable in an >ack< element sent by an IVS 595 Type: Boolean 596 Description: Indicates if the referenced object was successfully 597 received or not 598 Example: 600 9.1.1.2. Child Elements of the element 602 The element has the following child elements: 604 Name: actionResult 605 Usage: Optional 606 Description: An element indicates the result of an 607 action (other than a 'send-data' action). It has the following 608 attributes: 610 Name: action 611 Usage: Mandatory 612 Type: token 613 Description: Contains the value of the 'action' attribute of the 614 element 616 Name: success 617 Usage: Mandatory 618 Type: Boolean 619 Description: Indicates if the action was successfully 620 accomplished 622 Name: reason 623 Usage: Conditional 624 Type: token 625 Description: Used when 'success' is "False", this attribute 626 contains a reason code for a failure. A registry for reason 627 codes is defined in Section 13.8.3. 629 Name: details 630 Usage: optional 631 Type: string 632 Description: Contains further explanation of the circumstances of 633 a success or failure. The contents are implementation-specific 634 and human-readable. 636 Example: 638 Example: 641 9.1.1.3. Ack Examples 643 644 650 652 654 Figure 3: Ack Example from PSAP to IVS 656 657 663 664 665 667 669 671 Figure 4: Ack Example from IVS to PSAP 673 9.1.2. The element 675 The element is transmitted by the IVS to indicate to 676 the PSAP its capabilities. No attributes for this element are 677 currently defined. The following child elements are defined: 679 9.1.2.1. Child Elements of the element 681 The element has the following child elements: 683 Name: request 684 Usage: Mandatory 685 Description: The element contains a child 686 element per action supported by the vehicle. 688 Because support for a 'send-data' action is REQUIRED, a 689 child element with a "send-data" 'action' attribute is also 690 REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this 691 element within a element, and MUST 692 contain at a minimum the 'eCall.MSD' data block value; it SHOULD 693 contain all data blocks supported by the IVS. 695 All other actions are OPTIONAL. 697 If the "msg-static" action is supported, a child element 698 with a "msg-static" 'action' attribute is sent, with a 'msgid' 699 attribute set to the highest supported static message supported by 700 the vehicle. 702 If the "lamp" action is supported, a child element with 703 a "lamp" 'action' is sent, with a 'supported-lamps' attribute set 704 to all supported lamp IDs. 706 If the "enable-camera" action is supported, a child 707 element with an "enable-camera" 'action' is sent, with a 708 'supported-cameras' attribute set to all supported camera IDs. 710 Examples: 711 712 714 715 717 9.1.2.2. Capabilities Example 719 720 726 727 728 731 732 733 734 735 737 739 Figure 5: Capabilities Example 741 9.1.3. The element 743 A element appears one or more times on its own or as a 744 child of a element. The following attributes and 745 child elements may be used: 747 9.1.3.1. Attributes of the element 749 The element has the following attributes: 751 Name: action 752 Usage: Mandatory 753 Type: token 754 Description: Identifies the action that the vehicle is requested to 755 perform. An IANA registry is established in Section 13.8.1 to 756 contain the allowed values. 757 Example: action="send-data" 759 Name: msgid 760 Usage: Conditional 761 Type: int 762 Description: Mandatory with a "msg-static" action. Indicates the 763 identifier of the static message to be displayed and/or spoken for 764 the vehicle occupants. This document established an IANA registry 765 for messages and their IDs, in Section 13.8.2 766 Example: msgid="3" 768 Name: persistance 769 Usage: Optional 770 Type: duration 771 Description: Specifies how long to carry on the specified action, 772 for example, how long to continue honking or flashing. If absent, 773 the default is indefinitely. 774 Example: persistance="PT1H" 776 Name: datatype 777 Usage: Conditional 778 Type: token 779 Description: Mandatory with a "send-data" action. Specifies the 780 data block that the IVS is requested to transmit, using the same 781 identifier as in the 'purpose' attribute set in a Call-Info header 782 field to point to the data block. Permitted values are contained 783 in the 'Emergency Call Data Types' IANA registry established in 784 [additional-data-draft]. 785 Example: datatype="eCall.MSD" 787 Name: supported-datatypes 788 Usage: Conditional 789 Type: string 790 Description: Used with a 'send-data' action in a element 791 that is a child of a element, this attribute lists 792 all data blocks that the vehicle can transmit, using the same 793 identifier as in the 'purpose' attribute 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 [additional-data-draft]. Multiple values are separated with a 797 semicolon. 798 Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo" 800 Name: lamp-action 801 Usage: Conditional 802 Type: token 803 Description: Used with a 'lamp' action, indicates if the lamp should 804 be illuminated, turned off, or flashed. Permitted values are 805 'on', 'off', and 'flash'. 806 Example: lamp-action="flash" 808 Name: lamp-ID 809 Usage: Conditional 810 Type: token 811 Description: Used with a 'lamp' action, indicates which lamp the 812 action affects. Permitted values are contained in the registry of 813 lamp-ID tokens created in Section 13.8.4 814 Example: lamp-ID="hazard" 816 Name: supported-lamps 817 Usage: Conditional 818 Type: string 819 Description: Used with a 'lamp' action in a element that 820 is a child of a element, this attribute lists all 821 supported lamps, using values in the registry of lamp-ID tokens 822 created in Section 13.8.4. Multiple values are separated with a 823 semicolon. 824 Example: supported-lamps="head; interior; fog-front; fog-rear; 825 brake; position-front; position-rear; turn-left; turn-right; 826 hazard" 828 Name: camera-ID 829 Usage: Conditional 830 Type: token 831 Description: Used with an 'enable-camera' action, indicates which 832 camera to enable. Permitted values are contained in the registry 833 of camera-ID tokens created in Section 13.8.5. When a vehicle 834 camera is enabled, the IVS sends a re-INVITE to negotiate a one- 835 way media stream for the camera. 836 Example: camera-ID="backup" 838 Name: supported-cameras 839 Usage: Conditional 840 Type: string 841 Description: Used with an 'enable-camera' action in a 842 element that is a child of a element, this attribute 843 lists all cameras that the vehicle supports (can add as a video 844 feed in the current session), using the same identifiers as are 845 used in the 'camera-ID' attribute (contained in the camera ID 846 registry in Section 13.8.5). Multiple values are separated with a 847 semicolon. 848 Example: supported-cameras="backup; interior" 850 9.1.3.2. Child Elements of the element 852 The element has the following child elements: 854 Name: text 855 Usage: Conditional 856 Type: string 857 Description: Used within a element to 858 contain the text to be displayed and/or spoken (via text-to- 859 speech) for the vehicle occupants. 860 Example: Emergency authorities are aware of your incident and 861 location. Due to a multi-vehicle incident in your area, no one is 862 able to speak with you right now. Please remain calm. We will 863 assist you soon. 865 9.1.3.3. Request Example 867 868 874 875 877 878 879 Remain calm. Help is on the way. 880 882 884 Figure 6: Request Example 886 9.2. The emergencyCallData.eCall INFO package 888 This document registers the 'emergencyCallData.eCall' INFO package. 889 Both endpoints (the IVS and the PSAP equipment) set the Recv-Info 890 header field to 'emergencyCallData.eCall' per [RFC6086] to indicate 891 ability to receive INFO messages carrying eCall data or control 892 blocks. 894 Support for the 'emergencyCallData.eCall' INFO package indicates the 895 ability to receive eCall data and control blocks, which are carried 896 in a body part whose subtype starts with 'emergencyCallData.eCall.'. 897 At present there is only one defined eCall data block, which has the 898 'application/emergencyCallData.eCall.MSD+xml' MIME type, and one 899 eCall control block, which has the 'application/ 900 emergencyCallData.eCall.control+xml' MIME type. The eCall control 901 block includes the ability for the IVS to indicate its capabilities, 902 so in the event additional eCall blocks are defined, the IVS can 903 indicate which it supports. 905 The use of INFO is based on an analysis of the requirements against 906 the intent and effects of INFO versus other approaches (such as SIP 907 MESSAGE, media plane, or non-SIP protocols). In particular, the 908 transport of eCall data and control blocks is done only during an 909 emergency session established with SIP, using the mechanism 910 established in [additional-data-draft], and is normally carried in 911 the initial INVITE and its response; the use of INFO only occurs when 912 a data block or request needs to be sent subsequently during the 913 call. While MESSAGE could be used, it is not tied to a SIP session 914 as is INFO. REINVITE could also be used, but is normally used to 915 modify the session. SUBSCRIBE/NOTIFY could be coerced into service, 916 but the semantics are not a clean fit. Hence, INFO is appropriate. 918 An INFO request message carrying an eCall data or control block has 919 an Info-Package header field set to 'emergencyCallData.eCall' per 920 [RFC6086]. The INFO request message is marked as containing the 921 eCall data or control block by a Call-Info header field containing a 922 CID URL referencing the unique identifier of the body part containing 923 the eCall data or control, and a 'purpose' parameter identifying the 924 block. Because the eCall data or control block is being carried in 925 an INFO request message, the body part also carries a Content- 926 Disposition header field set to "Info-Package". 928 Per [additional-data-draft], emergency call related additional data 929 MAY be included in any SIP request or response message that may 930 contain a body. Hence, notwithstanding Section 4.3.2. of [RFC6086], 931 INFO response messages MAY contain eCall data or control blocks, 932 provided they are included as described in this document (with a 933 Call-Info header field containing a CID URL referencing the unique 934 identifier of the body part, and a 'purpose' parameter identifying 935 the block). When eCall data or control blocks are included in an 936 INFO response message, this is done per [additional-data-draft] and 937 this document, and not under [RFC6086]; that is, they are included as 938 emergency call additional data, not as an INFO package associated 939 data. 941 10. Examples 943 Figure 7 shows an eCall. The call uses the request URI 944 'urn:service:sos.ecall.automatic' service URN and is recognized as an 945 eCall, and further as one that was invoked automatically by the IVS 946 due to a crash or other serious incident. In this example, the 947 originating network routes the call to an ESInet (as for any 948 emergency call in an environment with an ESInet). The ESInet routes 949 the call to the appropriate NG-eCall capable PSAP. The emergency 950 call is received by the ESInet's Emergency Services Routing Proxy 951 (ESRP), as the entry point into the ESInet. The ESRP routes the call 952 to a PSAP, where it is received by a call taker. In deployments 953 where there is no ESInet, the originating network routes the call 954 directly to the appropriate NG-eCall capable PSAP. 956 +------------+ +---------------------------------------+ 957 | | | +-------+ | 958 | | | | PSAP2 | | 959 | | | +-------+ | 960 | | | | 961 | | | +------+ +-------+ | 962 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 963 | | | +------+ +-------+ | 964 | | | | 965 | | | +-------+ | 966 | | | | PSAP3 | | 967 | Originating| | +-------+ | 968 | Mobile | | | 969 | Network | | ESInet | 970 +------------+ +---------------------------------------+ 972 Figure 7: Example of NG-eCall Message Flow 974 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 975 contains an MSD and an eCall control block with vehicle capabilities. 976 For simplicity, the example does not show all SIP headers, nor does 977 it show the additional data blocks added by the IVS and the 978 originating mobile network. 980 INVITE urn:service:sos.ecall.automatic SIP/2.0 981 To: urn:service:sos.ecall.automatic 982 From: ;tag=9fxced76sl 983 Call-ID: 3848276298220188511@atlanta.example.com 984 Geolocation: 985 Geolocation-Routing: no 986 Call-Info: cid:1234567890@atlanta.example.com; 987 purpose=emergencyCallData.eCall.MSD; 988 cid:2345678901@atlanta.example.com; 989 purpose=emergencyCallData.eCall.control; 990 Accept: application/sdp, application/pidf+xml, 991 application/emergencyCallData.eCall.control 992 CSeq: 31862 INVITE 993 Recv-Info: emergencyCallData.eCall 994 Content-Type: multipart/mixed; boundary=boundary1 995 Content-Length: ... 997 --boundary1 999 Content-Type: application/sdp 1001 ...Session Description Protocol (SDP) goes here... 1003 --boundary1 1005 Content-Type: application/emergencyCallData.eCall.MSD+xml 1006 Content-ID: 1234567890@atlanta.example.com 1008 1009 1 1011 1012 1014 1 1016 1017 1018 1019 1020 1021 1023 1024 WMI 1025 VDSVDS 1026 Y 1027 A123456 1028 1029 1030 1031 1032 1034 123456789 1036 1037 173881200 1038 41822520 1039 1041 14 1043 1044 10 1045 -10 1046 1048 1049 10 1050 -20 1051 1053 2 1055 1057 1058 1.2.125 1059 30304646 1060 1061 1062 1064 --boundary1 1066 Content-Type: application/emergencyCallData.eCall.control+xml 1067 Content-ID: 2345678901@atlanta.example.com 1069 1070 1076 1077 1078 1082 1083 1084 1085 1087 1089 1091 --boundary1-- 1093 Figure 8: SIP NG-eCall INVITE 1095 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1096 the INVITE of Figure 8, containing an eCall control block 1097 acknowledging successful receipt of the eCall MSD. (For simplicity, 1098 the example does not show all SIP headers.) 1099 SIP/2.0 200 OK 1100 To: ;tag=9fxced76sl 1101 From: Exemplar PSAP 1102 Call-ID: 3848276298220188511@atlanta.example.com 1103 Call-Info: cid:2345678901@atlanta.example.com; 1104 purpose=emergencyCallData.eCall.control; 1105 Accept: application/sdp, application/pidf+xml, 1106 application/emergencyCallData.eCall.control, 1107 application/emergencyCallData.eCall.MSD 1108 CSeq: 31862 INVITE 1109 Recv-Info: emergencyCallData.eCall 1110 Content-Type: multipart/mixed; boundary=boundaryX 1111 Content-Length: ... 1113 --boundaryX 1115 Content-Type: application/sdp 1117 ...Session Description Protocol (SDP) goes here... 1119 --boundaryX 1121 1122 1128 1130 1132 --boundaryX 1134 Figure 9: 200 OK response to INVITE 1136 11. Security Considerations 1138 The security considerations described in [RFC5069] apply here. 1140 An eCall will carry two forms of location data: the network-provided 1141 location that is inherently part of IMS emergency calls (which might 1142 be determined solely by the network, or in cooperation with or 1143 possibly entirely by the originating device), and the IVS-supplied 1144 location within the MSD. This is likely to be useful to the PSAP, 1145 especially when the two locations are independently determined. Even 1146 in situations where the network-supplied location is limited to the 1147 cell site, this can be useful as a sanity check on the device- 1148 supplied location contained in the MSD. 1150 The document [I-D.ietf-ecrit-trustworthy-location] discusses trust 1151 issues regarding location provided by or determined in cooperation 1152 with end devices. 1154 The mechanism by which the PSAP sends acknowledgments and requests to 1155 the vehicle requires authenticity considerations; when the PSAP 1156 request is received within a session initiated by the vehicle as an 1157 eCall emergency call placed over a cellular network, there is a 1158 higher degree of trust that the source is indeed a PSAP. If the PSAP 1159 request is received in other situations, such as a call-back, the 1160 trust issues in verifying that a call-back is indeed from a PSAP are 1161 more complex (see the PSAP Callback document [RFC7090]). A further 1162 safeguard (applicable regardless of which end initiated the call and 1163 the means of the call) is for the PSAP or emergency service provider 1164 to sign the body part using a certificate issued by a known emergency 1165 services certificate authority and for which the IVS can verify the 1166 root certificate. 1168 12. XML Schema 1170 This section defines the XML schema of the eCall control block. (The 1171 schema for the MSD can be found in EN 15722 [msd].) 1173 1174 1182 1185 1188 1189 1190 1191 1192 1194 1195 1196 1199 1200 1201 1202 1203 1205 1206 1207 1208 1209 1210 1211 1214 1217 1219 1220 conditionally 1221 mandatory when @success='false" 1222 to indicate reason code for a 1223 failure 1224 1225 1226 1228 1229 1230 1231 1234 1235 1238 1240 1241 1242 1243 1245 1246 1247 1248 1249 1253 1256 1257 1258 1259 1260 1262 1263 1264 1265 1266 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1286 1287 1288 1289 1290 1291 1292 1293 1294 1296 1298 Figure 10: eCall Control Block Schema 1300 13. IANA Considerations 1302 13.1. Service URN Registrations 1304 IANA is requested to register the URN 'urn:service:sos.ecall' under 1305 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1307 This service identifies a type of emergency call (placed by a 1308 specialized in-vehicle system and a carrying standardized set of data 1309 related to the vehicle and crash or incident, and is needed to direct 1310 the call to a specialized public safety answering point (PSAP) with 1311 technical and operational capabilities to handle such calls. Two 1312 sub-services are registered as well, namely 1314 urn:service:sos.ecall.manual 1316 This service URN indicates that an eCall had been triggered based 1317 on the manual interaction of the driver or a passenger. 1319 urn:service:sos.ecall.automatic 1321 This service URN indicates that an eCall had been triggered 1322 automatically, for example, due to a crash or other serious 1323 incident (e.g., fire). 1325 IANA is also requested to register the URN 1326 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1327 defined in Setcion 17.2 of [RFC6881]. 1329 13.2. MIME Content-type Registration for 'application/ 1330 emergencyCallData.eCall.MSD+xml' 1332 IANA is requested to add application/emergencyCallData.eCall.MSD+xml 1333 as a MIME content type, with a reference to this document, in 1334 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1335 RFC 7303 [RFC7303]. 1337 MIME media type name: application 1339 MIME subtype name: emergencyCallData.eCall.MSD+xml 1341 Mandatory parameters: none 1343 Optional parameters: charset 1345 Indicates the character encoding of the XML content. 1347 Encoding considerations: Uses XML, which can employ 8-bit 1348 characters, depending on the character encoding used. See 1349 Section 3.2 of RFC 7303 [RFC7303]. 1351 Security considerations: This content type is designed to carry 1352 vehicle and incident-related data during an emergency call. This 1353 data contains personal information including vehicle VIN, 1354 location, direction, etc. Appropriate precautions need to be 1355 taken to limit unauthorized access, inappropriate disclosure to 1356 third parties, and eavesdropping of this information. In general, 1357 it is permissible for the data to be unprotected while briefly in 1358 transit within the Mobile Network Operator (MNO); the MNO is 1359 trusted to not permit the data to be accessed by third parties. 1360 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1361 contain more discussion. 1363 Interoperability considerations: None 1365 Published specification: Annex C of EN 15722 [msd] 1367 Applications which use this media type: Pan-European eCall 1368 compliant systems 1370 Additional information: None 1372 Magic Number: None 1374 File Extension: .xml 1376 Macintosh file type code: 'TEXT' 1377 Person and email address for further information: Hannes 1378 Tschofenig, Hannes.Tschofenig@gmx.net 1380 Intended usage: LIMITED USE 1382 Author: This specification was produced by the European Committee 1383 For Standardization (CEN). For contact information, please see 1384 . 1386 Change controller: The European Committee For Standardization 1387 (CEN) 1389 13.3. MIME Content-type Registration for 'application/ 1390 emergencyCallData.eCall.control+xml' 1392 IANA is requested to add application/ 1393 emergencyCallData.eCall.control+xml as a MIME content type, with a 1394 reference to this document, in accordance to the procedures of RFC 1395 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1397 MIME media type name: application 1399 MIME subtype name: emergencyCallData.eCall.control+xml 1401 Mandatory parameters: none 1403 Optional parameters: charset 1405 Indicates the character encoding of the XML content. 1407 Encoding considerations: Uses XML, which can employ 8-bit 1408 characters, depending on the character encoding used. See 1409 Section 3.2 of RFC 7303 [RFC7303]. 1411 Security considerations: This content type carries metadata and 1412 control information and requests, primarily from a Public Safety 1413 Answering Point (PSAP) to an In-Vehicle System (IVS) during an 1414 emergency call, and also capabilities from the IVS to the PSAP. 1415 Metadata (such as an acknowledgment that data sent by the IVS to 1416 the PSAP was successfully received) has limited privacy and 1417 security implications. Control information (such as requests from 1418 the PSAP that the vehicle perform an action) has some privacy and 1419 important security implications. The privacy concern arises from 1420 the ability to request the vehicle to transmit a data set, which 1421 as described in Section 13.2, may contain personal information. 1422 The security implication is the ability to request the vehicle to 1423 perform an action. It is important that control information 1424 originate only from a PSAP or other emergency services provider, 1425 and not from an impostor. The first safeguard for this is the 1426 security of the cellular network over which the emergency call was 1427 placed. In particular, when the IVS initiates an eCall over a 1428 cellular network, the MNO routes the call to a PSAP. (Calls 1429 placed using other means, such as Wi-Fi or over-the-top services, 1430 do not carry the same degree of trust.) Calls received by the 1431 IVS, such as a call-back from a PSAP, also do not carry the same 1432 degree of trust, since the current mechanisms are not ideal for 1433 verifying that such a call is indeed from a PSAP in response to an 1434 emergency call placed by the IVS. See the discussion in 1435 Section 11 and the PSAP Callback document [RFC7090]. A further 1436 safeguard, and one applicable regardless of which end initiated 1437 the call and the means of the call, is for the PSAP or emergency 1438 service provider to sign the body part using a certificate issued 1439 by a known emergency services certificate authority and for which 1440 the IVS can verify the root certificate. Sections 7 and Section 8 1441 of [I-D.ietf-ecrit-additional-data] contain more discussion. 1443 Interoperability considerations: None 1445 Published specification: Annex C of EN 15722 [msd] 1447 Applications which use this media type: Pan-European eCall 1448 compliant systems 1450 Additional information: None 1452 Magic Number: None 1454 File Extension: .xml 1456 Macintosh file type code: 'TEXT' 1458 Person and email address for further information: Randall Gellens, 1459 rg+ietf@qti.qualcomm.com 1461 Intended usage: LIMITED USE 1463 Author: The IETF ECRIT WG. 1465 Change controller: The IETF ECRIT WG. 1467 13.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1468 Additional Data Blocks registry 1470 This specification requests IANA to add the 'eCall.MSD' entry to the 1471 Emergency Call Additional Data Blocks registry (established by 1472 [additional-data-draft]), with a reference to this document. 1474 13.5. Registration of the 'eCall.control' entry in the Emergency Call 1475 Additional Data Blocks registry 1477 This specification requests IANA to add the 'eCall.control' entry to 1478 the Emergency Call Additional Data Blocks registry (established by 1479 [additional-data-draft]), with a reference to this document. 1481 13.6. Registration of the emergencyCallData.eCall Info Package 1483 IANA is requested to add emergencyCallData.eCall to the Info Packages 1484 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1485 reference to this document. 1487 13.7. URN Sub-Namespace Registration 1489 13.7.1. Registration for urn:ietf:params:xml:ns:eCall 1491 This section registers a new XML namespace, as per the guidelines in 1492 RFC 3688 [RFC3688]. 1494 URI: urn:ietf:params:xml:ns:eCall 1496 Registrant Contact: IETF, ECRIT working group, , as 1497 delegated by the IESG . 1499 XML: 1501 BEGIN 1502 1503 1505 1506 1507 1509 Namespace for eCall Data 1510 1511 1512

Namespace for eCall Data

1513

See [TBD: This document].

1514 1515 1516 END 1518 13.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1520 This section registers a new XML namespace, as per the guidelines in 1521 RFC 3688 [RFC3688]. 1523 URI: urn:ietf:params:xml:ns:eCall:control 1525 Registrant Contact: IETF, ECRIT working group, , as 1526 delegated by the IESG . 1528 XML: 1530 BEGIN 1531 1532 1534 1535 1536 1538 Namespace for eCall Data: 1539 Control Block 1540 1541 1542

Namespace for eCall Data

1543

Control Block

1544

See [TBD: This document].

1545 1546 1547 END 1549 13.8. Registry creation 1551 This document creates a new registry called 'eCall Control Data'. 1552 The following sub-registries are created for this registry. 1554 13.8.1. eCall Control Action Registry 1556 This document creates a new sub-registry called "eCall Control Action 1557 Registry". As defined in [RFC5226], this registry operates under 1558 "Expert Review" rules. The expert should determine that the proposed 1559 action is within the purview of a vehicle, is sufficiently 1560 distinguishable from other actions, and the actions is clearly and 1561 fully described. In most cases, a published and stable document is 1562 referenced for the description of the action. 1564 The content of this registry includes: 1566 Name: The identifier to be used in the 'action' attribute of an 1567 eCall control element. 1569 Description: A description of the action. In most cases this will 1570 be a reference to a published and stable document. The 1571 description MUST specify if any attributes or child elements are 1572 optional or mandatory, and describe the action to be taken by the 1573 vehicle. 1575 The initial set of values is listed in Table 2. 1577 +---------------+------------------------------+ 1578 | Name | Description | 1579 +---------------+------------------------------+ 1580 | send-data | Section xxx of this document | 1581 | | | 1582 | msg-static | Section xxx of this document | 1583 | | | 1584 | msg-dynamic | Section xxx of this document | 1585 | | | 1586 | honk | Section xxx of this document | 1587 | | | 1588 | lamp | Section xxx of this document | 1589 | | | 1590 | enable-camera | Section xxx of this document | 1591 +---------------+------------------------------+ 1593 Table 2: eCall Control Action Registry Initial Values 1595 13.8.2. eCall Static Message Registry 1597 This document creates a new sub-registry called "eCall Static Message 1598 Registry". Because all compliant vehicles are expected to support 1599 all static messages translated into all languages supported by the 1600 vehicle, it is important to limit the number of such messages. As 1601 defined in [RFC5226], this registry operates under "Publication 1602 Required" rules, which require a stable, public document and imply 1603 expert review of the publication. The expert should determine that 1604 the document has been published by an appropriate emergency services 1605 organization (e.g., NENA, EENA, APCO) and that the proposed message 1606 is sufficiently distinguishable from other messages. 1608 The content of this registry includes: 1610 ID: An integer identifier to be used in the 'msgid' attribute of an 1611 eCall control element. 1613 Message: The text of the message. Messages are listed in the 1614 registry in English; vehicles are expected to implement 1615 translations into languages supported by the vehicle. 1617 When new messages are added to the registry, the message text is 1618 determined by the registrant; IANA assigns the IDs. Each message is 1619 assigned a consecutive integer value as its ID. This allows an IVS 1620 to indicate by a single integer value that it supports all messages 1621 with that value or lower. 1623 The initial set of values is listed in Table 3. 1625 +----+--------------------------------------------------------------+ 1626 | ID | Message | 1627 +----+--------------------------------------------------------------+ 1628 | 1 | Emergency authorities are aware of your incident and | 1629 | | location, but are unable to speak with you right now. We | 1630 | | will help you as soon as possible. | 1631 +----+--------------------------------------------------------------+ 1633 Table 3: eCall Static Message Registry 1635 13.8.3. eCall Reason Registry 1637 This document creates a new sub-registry called "eCall Reason 1638 Registry" which contains values for the 'reason' attribute of the 1639 element. As defined in [RFC5226], this registry 1640 operates under "Expert Review" rules. The expert should determine 1641 that the proposed reason is sufficiently distinguishable from other 1642 reasons and that the proposed description is understandable and 1643 correctly worded. 1645 The content of this registry includes: 1647 ID: A short string identifying the reason, for use in the 'reason' 1648 attribute of an element. 1650 Description: A description of the reason. 1652 The initial set of values is listed in Table 4. 1654 +------------------+------------------------------------------------+ 1655 | ID | Description | 1656 +------------------+------------------------------------------------+ 1657 | unsupported | The 'action' is not supported. | 1658 | | | 1659 | unable | The 'action' could not be accomplished. | 1660 | | | 1661 | data-unsupported | The data item referenced in a 'send-data' | 1662 | | request is not supported. | 1663 +------------------+------------------------------------------------+ 1665 Table 4: eCall Reason Registry 1667 13.8.4. eCall Lamp ID Registry 1669 This document creates a new sub-registry called "eCall Lamp ID 1670 Registry" to standardize the names of automotive lamps (lights). As 1671 defined in [RFC5226], this registry operates under "Expert Review" 1672 rules. The expert should determine that the proposed lamp name is 1673 clearly understandable and is sufficiently distinguishable from other 1674 lamp names. 1676 The content of this registry includes: 1678 Name: The identifier to be used in the 'lamp-ID' attribute of an 1679 eCall control element. 1681 Description: A description of the lamp (light). 1683 The initial set of values is listed in Table 5. 1685 +----------------+---------------------------------------------+ 1686 | Name | Description | 1687 +----------------+---------------------------------------------+ 1688 | head | The main lamps used to light the road ahead | 1689 | | | 1690 | interior | Interior lamp, often at the top center | 1691 | | | 1692 | fog-front | Front fog lamps | 1693 | | | 1694 | fog-rear | Rear fog lamps | 1695 | | | 1696 | brake | Brake indicator lamps | 1697 | | | 1698 | position-front | Front position/parking/standing lamps | 1699 | | | 1700 | position-rear | Rear position/parking/standing lamps | 1701 | | | 1702 | turn-left | Left turn/directional lamps | 1703 | | | 1704 | turn-right | Right turn/directional lamps | 1705 | | | 1706 | hazard | Hazard/four-way lamps | 1707 +----------------+---------------------------------------------+ 1709 Table 5: eCall Lamp ID Registry Initial Values 1711 13.8.5. eCall Camera ID Registry 1713 This document creates a new sub-registry called "eCall Camera ID 1714 Registry" to standardize the names of automotive camera. As defined 1715 in [RFC5226], this registry operates under "Expert Review" rules. 1716 The expert should determine that the proposed camera name is clearly 1717 understandable and is sufficiently distinguishable from other camera 1718 names. 1720 The content of this registry includes: 1722 Name: The identifier to be used in the 'camera-ID' attribute of an 1723 eCall control element. 1725 Description: A description of the camera. 1727 The initial set of values is listed in Table 6. 1729 +----------+--------------------------------------------------------+ 1730 | Name | Description | 1731 +----------+--------------------------------------------------------+ 1732 | backup | Shows what is behind the vehicle. Also known as | 1733 | | rearview, reverse, etc. | 1734 | | | 1735 | interior | Shows the interior (driver) | 1736 +----------+--------------------------------------------------------+ 1738 Table 6: eCall Camera ID Registry Initial Values 1740 14. Contributors 1742 Brian Rosen was a co-author of the original document upon which this 1743 document is based. 1745 15. Acknowledgements 1747 We would like to thank Bob Williams and Ban Al-Bakri for their 1748 feedback and suggestions, and Keith Drage for his review comments. 1749 We would like to thank Michael Montag, Arnoud van Wijk, Gunnar 1750 Hellstrom, and Ulrich Dietz for their help with the original document 1751 upon which this document is based. 1753 16. Changes from Previous Versions 1755 16.1. Changes from draft-ietf-02 to draft-ietf-03 1757 o Added request to enable cameras 1758 o Improved examples and XML schema 1759 o Clarifications and wording improvements 1761 16.2. Changes from draft-ietf-01 to draft-ietf-02 1763 o Added clarifying text reinforcing that the data exchange is for 1764 small blocks of data infrequently transmitted 1765 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1766 establish a one-way media stream 1767 o Clarified that the scope is the needs of eCall within the SIP 1768 emergency call environment 1769 o Added informative statement that the document may be suitable for 1770 reuse by other ACN systems 1771 o Clarified that normative language for the control block applies to 1772 both IVS and PSAP 1773 o Removed 'ref', 'supported-mime', and elements 1774 o Minor wording improvements and clarifications 1776 16.3. Changes from draft-ietf-00 to draft-ietf-01 1778 o Added further discussion of test calls 1779 o Added further clarification to the document scope 1780 o Mentioned that multi-region vehicles may need to support other 1781 crash notification specifications in addition to eCall 1782 o Added details of the eCall metadata and control functionality 1783 o Added IANA registration for the MIME content type for the eCall 1784 control object 1785 o Added IANA registries for protocol elements and tokens used in the 1786 eCall control object 1787 o Minor wording improvements and clarifications 1789 16.4. Changes from draft-gellens-03 to draft-ietf-00 1791 o Renamed from draft-gellens- to draft-ietf-. 1792 o Added mention of and reference to ETSI TR "Mobile Standards Group 1793 (MSG); eCall for VoIP" 1794 o Added text to Introduction regarding migration/co-existence being 1795 out of scope 1796 o Added mention in Security Considerations that even if the network- 1797 supplied location is just the cell site, this can be useful as a 1798 sanity check on the IVS-supplied location 1799 o Minor wording improvements and clarifications 1801 16.5. Changes from draft-gellens-02 to -03 1803 o Clarifications and editorial improvements. 1805 16.6. Changes from draft-gellens-01 to -02 1807 o Minor wording improvements 1808 o Removed ".automatic" and ".manual" from 1809 "urn:service:test.sos.ecall" registration and discussion text. 1811 16.7. Changes from draft-gellens-00 to -01 1813 o Now using 'EmergencyCallData' for purpose parameter values and 1814 MIME subtypes, in accordance with changes to 1815 [additional-data-draft] 1816 o Added reference to RFC 6443 1817 o Fixed bug that caused Figure captions to not appear 1819 17. References 1820 17.1. Normative References 1822 [EN_16072] 1823 CEN, , "Intelligent transport systems - eSafety - Pan- 1824 European eCall operating requirements", December 2011. 1826 [I-D.ietf-ecrit-additional-data] 1827 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1828 J. Winterbottom, "Additional Data Related to an Emergency 1829 Call", draft-ietf-ecrit-additional-data-30 (work in 1830 progress), June 2015. 1832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1833 Requirement Levels", BCP 14, RFC 2119, March 1997. 1835 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1836 January 2004. 1838 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1839 Emergency and Other Well-Known Services", RFC 5031, 1840 January 2008. 1842 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1843 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1844 May 2008. 1846 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1847 "Framework for Emergency Calling Using Internet 1848 Multimedia", RFC 6443, December 2011. 1850 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1851 Specifications and Registration Procedures", BCP 13, RFC 1852 6838, January 2013. 1854 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1855 Communications Services in Support of Emergency Calling", 1856 BCP 181, RFC 6881, March 2013. 1858 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1859 July 2014. 1861 [TS22.101] 1862 3GPP, , "Technical Specification Group Services and System 1863 Aspects; Service aspects; Service principles", . 1865 [additional-data-draft] 1866 Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and 1867 J. Winterbottom, "Additional Data related to an Emergency 1868 Call", draft-ietf-ecrit-additional-data-11 (work in 1869 progress), July 2013. 1871 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1872 minimum set of data (MSD), EN 15722", June 2011. 1874 17.2. Informative references 1876 [CEN] "European Committee for Standardization", 1877 . 1879 [I-D.ietf-ecrit-trustworthy-location] 1880 Tschofenig, H., Schulzrinne, H., and B. Aboba, 1881 "Trustworthy Location", draft-ietf-ecrit-trustworthy- 1882 location-14 (work in progress), July 2014. 1884 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1885 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1886 April 2014. 1888 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1889 Emergency Context Resolution with Internet Technologies", 1890 RFC 5012, January 2008. 1892 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1893 Shanmugam, "Security Threats and Requirements for 1894 Emergency Call Marking and Mapping", RFC 5069, January 1895 2008. 1897 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1898 Presence Information Data Format Location Object (PIDF-LO) 1899 Usage Clarification, Considerations, and Recommendations", 1900 RFC 5491, March 2009. 1902 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1903 Initiation Protocol (SIP) INFO Method and Package 1904 Framework", RFC 6086, January 2011. 1906 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1907 for the Session Initiation Protocol", RFC 6442, December 1908 2011. 1910 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1911 Patel, "Public Safety Answering Point (PSAP) Callback", 1912 RFC 7090, April 2014. 1914 [SDO-3GPP] 1915 "3d Generation Partnership Project", 1916 . 1918 [SDO-ETSI] 1919 "European Telecommunications Standards Institute (ETSI)", 1920 . 1922 [draft-ietf-ecrit-car-crash] 1923 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1924 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1925 ecrit-car-crash (work in progress), March 2015. 1927 Authors' Addresses 1929 Randall Gellens 1930 Qualcomm Technologies, Inc. 1931 5775 Morehouse Drive 1932 San Diego 92651 1933 US 1935 Email: rg+ietf@qti.qualcomm.com 1937 Hannes Tschofenig 1939 Email: Hannes.Tschofenig@gmx.net 1940 URI: http://www.tschofenig.priv.at