idnits 2.17.00 (12 Aug 2021) /tmp/idnits47263/draft-ietf-ecrit-ecall-09.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 6 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (July 21, 2016) is 2129 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-ecrit-additional-data - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ecrit-additional-data' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Core Technology Consulting 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 22, 2017 Individual 6 July 21, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-09.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, providing real-time communications and an 19 integrated set of related data. 21 This document also registers a MIME Content Type and an Emergency 22 Call Additional Data Block for the eCall vehicle data and metadata/ 23 control data. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 22, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 63 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Call Routing . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10 69 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11 70 9.1.1. The element . . . . . . . . . . . . . . . . . . 12 71 9.1.1.1. Attributes of the element . . . . . . . . . 12 72 9.1.1.2. Child Elements of the element . . . . . . . 13 73 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 13 74 9.1.2. The element . . . . . . . . . . . . . . . . 13 75 9.1.2.1. Attributes of the element . . . . . . . 13 76 9.1.2.2. Request Example . . . . . . . . . . . . . . . . . 14 77 10. The emergencyCallData.eCall INFO package . . . . . . . . . . 14 78 10.1. INFO Package Requirements . . . . . . . . . . . . . . . 14 79 10.1.1. Overall Description . . . . . . . . . . . . . . . . 14 80 10.1.2. Applicability . . . . . . . . . . . . . . . . . . . 15 81 10.1.3. Info Package Name . . . . . . . . . . . . . . . . . 15 82 10.1.4. Info Package Parameters . . . . . . . . . . . . . . 15 83 10.1.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 16 84 10.1.6. INFO Message Body Parts . . . . . . . . . . . . . . 16 85 10.1.7. Info Package Usage Restrictions . . . . . . . . . . 16 86 10.1.8. Rate of INFO Requests . . . . . . . . . . . . . . . 16 87 10.1.9. Info Package Security Considerations . . . . . . . . 16 88 10.1.10. Implementation Details . . . . . . . . . . . . . . . 16 89 10.1.11. Examples . . . . . . . . . . . . . . . . . . . . . . 16 90 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 92 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 93 14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 15.1. Service URN Registrations . . . . . . . . . . . . . . . 25 96 15.2. MIME Content-type Registration for 97 'application/emergencyCallData.eCall.MSD+per' . . . . . 26 98 15.3. MIME Content-type Registration for 99 'application/emergencyCallData.eCall.control+xml' . . . 27 100 15.4. Registration of the 'eCall.MSD' entry in the Emergency 101 Call Additional Data Blocks registry . . . . . . . . . . 29 102 15.5. Registration of the 'eCall.control' entry in the 103 Emergency Call Additional Data Blocks registry . . . . . 29 104 15.6. Registration of the emergencyCallData.eCall Info Package 29 105 15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 29 106 15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 29 107 15.7.2. Registration for 108 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 30 109 15.8. Registry creation . . . . . . . . . . . . . . . . . . . 31 110 15.8.1. eCall Control Action Registry . . . . . . . . . . . 31 111 15.8.2. eCall Control Extension Registry . . . . . . . . . . 32 112 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 113 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 114 18. Changes from Previous Versions . . . . . . . . . . . . . . . 33 115 18.1. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 33 116 18.2. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 33 117 18.3. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 34 118 18.4. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 34 119 18.5. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 34 120 18.6. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 34 121 18.7. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 34 122 18.8. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 34 123 18.9. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 35 124 18.10. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 35 125 18.11. Changes from draft-gellens-02 to -03 . . . . . . . . . . 35 126 18.12. Changes from draft-gellens-01 to -02 . . . . . . . . . . 35 127 18.13. Changes from draft-gellens-00 to -01 . . . . . . . . . . 35 128 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 129 19.1. Normative References . . . . . . . . . . . . . . . . . . 36 130 19.2. Informative references . . . . . . . . . . . . . . . . . 37 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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 | | | 148 | CEN | European Committee for Standardization | 149 | | | 150 | EENA | European Emergency Number Association | 151 | | | 152 | ESInet | Emergency Services IP network | 153 | | | 154 | IMS | IP Multimedia Subsystem | 155 | | | 156 | IVS | In-Vehicle System | 157 | | | 158 | MNO | Mobile Network Operator | 159 | | | 160 | MSD | Minimum Set of Data | 161 | | | 162 | PSAP | Public Safety Answering Point | 163 +--------+----------------------------------------+ 165 2. Document Scope 167 This document is limited to the signaling, data exchange, and 168 protocol needs of next-generation eCall (NG-eCall, also referred to 169 as packet-switched eCall or all-IP eCall) within the SIP framework 170 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 171 itself is specified by 3GPP and CEN and these specifications include 172 far greater scope than is covered here. 174 The eCall service operates over cellular wireless communication, but 175 this document does not address cellular-specific details, nor client 176 domain selection (e.g., circuit-switched versus packet-switched). 177 All such aspects are the purview of their respective standards 178 bodies. The scope of this document is limited to eCall operating 179 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 181 The technical contents of this document can be suitable for use in 182 other vehicle-initiated emergency call systems, but this is out of 183 scope for this document. 185 Vehicles designed for multiple regions might need to support eCall 186 and other Advanced Automatic Crash Notification (AACN) systems, such 187 as described in [I-D.ietf-ecrit-car-crash]. 189 3. Introduction 191 Emergency calls made from vehicles (e.g., in the event of a crash) 192 assist in significantly reducing road deaths and injuries by allowing 193 emergency services to be aware of the incident, the state of the 194 vehicle, the location of the vehicle, and to have a voice channel 195 with the vehicle occupants. This enables a quick and appropriate 196 response. 198 The European Commission initiative of eCall was conceived in the late 199 1990s, and has evolved to a European Parliament decision requiring 200 the implementation of a compliant in-vehicle system (IVS) in new 201 vehicles and the deployment of eCall in the European Member States in 202 the very near future. Other regions are developing eCall-compatible 203 systems. 205 The pan-European eCall system provides a standardized and mandated 206 mechanism for emergency calls by vehicles. eCall establishes 207 procedures for such calls to be placed by in-vehicle systems, 208 recognized and processed by the mobile network, and routed to a 209 specialized PSAP where the vehicle data is available to assist the 210 call taker in assessing and responding to the situation. eCall 211 provides a standard set of vehicle, sensor (e.g., crash related), and 212 location data. 214 An eCall can be either user-initiated or automatically triggered. 215 Automatically triggered eCalls indicate a car crash or some other 216 serious incident. Manually triggered eCalls might be reports of 217 witnessed crashes or serious hazards. PSAPs might apply specific 218 operational handling to manual and automatic eCalls. 220 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 221 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 222 call setup mark the call as an eCall, and further indicate if the 223 call was automatically or manually triggered. The call is routed to 224 an eCall-capable PSAP, a voice channel is established between the 225 vehicle and the PSAP, and an eCall in-band modem is used to carry a 226 defined set of vehicle, sensor (e.g., crash related), and location 227 data (the Minimum Set of Data or MSD) within the voice channel. The 228 same in-band mechanism is used for the PSAP to acknowledge successful 229 receipt of the MSD, and to request the vehicle to send a new MSD 230 (e.g., to check if the state of or location of the vehicle or its 231 occupants has changed). NG-eCall moves from circuit switched to all- 232 IP, and carries the vehicle data and other eCall-specific data as 233 additional data carried with the call. This document describes how 234 IETF mechanisms for IP-based emergency calls, including [RFC6443] and 235 [I-D.ietf-ecrit-additional-data] are used to provide the signaling 236 and data exchange of the next generation of pan-European eCall. 238 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 239 has published a Technical Report titled "Mobile Standards Group 240 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 241 recommendations regarding support for eCall in an all-IP environment. 242 The recommendations include the use of 3GPP IMS emergency calling 243 with additional elements identifying the call as an eCall and as 244 carrying eCall data and with mechanisms for carrying the data and 245 eCall-specific signaling. 3GPP IMS emergency services support 246 multimedia, providing the ability to carry voice, text, and video. 247 This capability is referred to within 3GPP as Multimedia Emergency 248 Services (MMES). 250 A transition period will exist during which time the various entities 251 involved in initiating and handling an eCall might support next- 252 generation eCall, legacy eCall, or both. The issues of migration and 253 co-existence during the transition period is outside the scope of 254 this document. 256 4. eCall Requirements 258 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 259 [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle 260 data are contained in EN 15722 [msd]. 262 5. Vehicle Data 264 Pan-European eCall provides a standardized and mandated set of 265 vehicle related data, known as the Minimum Set of Data (MSD). The 266 European Committee for Standardization (CEN) has specified this data 267 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 268 circuit-switched eCall and this document use the ASN.1 PER encoding, 269 which is specified in Annex A of EN 15722 [msd] (the XML encoding 270 specified in Annex C is not used in this document). 272 This document registers the 'application/ 273 emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD 274 to be carried in SIP. As an ASN.1 PER encoded object, the data is 275 binary and transported using binary content transfer encoding within 276 SIP messages. This document also adds the 'eCall.MSD' entry to the 277 Emergency Call Additional Data Blocks registry to enable the MSD to 278 be recognized as such in a SIP-based eCall emergency call. (See 279 [I-D.ietf-ecrit-additional-data] for more information about the 280 registry and how it is used.) 282 See Section 6 for a discussion of how the MSD vehicle data is 283 conveyed in an NG-eCall. 285 6. Data Transport 287 The "Additional Data related to an Emergency Call" document 288 [I-D.ietf-ecrit-additional-data] establishes a general mechanism for 289 attaching blocks of data to a SIP emergency call. This mechanism 290 permits certain MIME types to be attached to SIP messages. This 291 document makes use of that mechanism. 293 Note that if additional data sets are defined and registered (e.g., 294 in the future or in other regions) and transmitted using the same 295 mechanisms, the size and frequency of transmission during a dialog 296 need to be evaluated to be sure it is appropriate to use the 297 signaling channel. 299 An In-Vehicle System (IVS) transmits the MSD (see Section 5) by 300 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 301 message as a MIME body part per [I-D.ietf-ecrit-additional-data]. 302 The body part is identified by its MIME content-type ('application/ 303 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 304 the body part. The body part is assigned a unique identifier which 305 is listed in a Content-ID header field in the body part. The SIP 306 message is marked as containing the MSD by adding (or appending to) a 307 Call-Info header field at the top level of the SIP message. This 308 Call-Info header field contains a CID URL referencing the body part's 309 unique identifier, and a 'purpose' parameter identifying the data as 310 the eCall MSD per the Emergency Call Additional Data Blocks registry 311 entry; the 'purpose' parameter's value is 312 'emergencyCallData.eCall.MSD'. 314 A PSAP transmits a metadata/control object (see Section 9) by 315 encoding it per the description in this document and attaching it to 316 a SIP message as a MIME body part per 317 [I-D.ietf-ecrit-additional-data]. The body part is identified by its 318 MIME content-type ('application/emergencyCallData.eCall.control+xml') 319 in the Content-Type header field of the body part. The body part is 320 assigned a unique identifier which is listed in a Content-ID header 321 field in the body part. The SIP message is marked as containing the 322 MSD by adding (or appending to) a Call-Info header field at the top 323 level of the SIP message. This Call-Info header field contains a CID 324 URL referencing the body part's unique identifier, and a 'purpose' 325 parameter identifying the data as an eCall metadata/control block per 326 the Emergency Call Additional Data Blocks registry entry; the 327 'purpose' parameter's value is 'emergencyCallData.eCall.control'. 329 An In-Vehicle System (IVS) initiating an NG-eCall attaches the MSD to 330 the initial INVITE. The PSAP creates a metadata/control object 331 acknowledging receipt of the MSD and attaches it to the SIP response 332 to the INVITE. 334 A PSAP can request the vehicle to send an updated MSD during a call. 335 The PSAP creates a metadata/control object requesting the MSD and 336 attaches it to a SIP INFO message which it sends within the dialog. 337 The IVS then attaches an updated MSD to a SIP INFO message and sends 338 it within the dialog. The metadata/control object and the MSD are 339 attached to an INFO message in the same way they are attached to 340 other messages (such as the INVITE and the reply to the INVITE as 341 discussed above). See Section 10 for information about the use of 342 INFO messages to carry data within an eCall. 344 When data is being carried in an INFO request message, the body part 345 also carries a Content-Disposition header field set to "Info- 346 Package". 348 Support for the data blocks defined in 349 [I-D.ietf-ecrit-additional-data] is NOT REQUIRED for conformance with 350 this document . 352 7. Call Setup 354 In circuit-switched eCall, the IVS places a special form of a 112 355 emergency call which carries an eCall flag (indicating that the call 356 is an eCall and also if the call was manually or automatically 357 triggered); the mobile network operator (MNO) recognizes the eCall 358 flag and routes the call to an eCall-capable PSAP; vehicle data is 359 transmitted to the PSAP via the eCall in-band modem (in the voice 360 channel). 362 ///----\\\ 112 voice call with eCall flag +------+ 363 ||| IVS |||---------------------------------------->+ PSAP | 364 \\\----/// vehicle data via eCall in-band modem +------+ 366 Figure 1: circuit-switched eCall 368 For NG-eCall, the IVS establishes an emergency call using a Request- 369 URI indicating a manual or automatic eCall; the MNO (or ESInet) 370 recognizes the eCall URN and routes the call to an NG-eCall capable 371 PSAP; the PSAP interpets the vehicle data sent with the call and 372 makes it available to the call taker. 374 ///----\\\ IMS emergency call with eCall URN +------+ 375 IVS ----------------------------------------->+ PSAP | 376 \\\----/// vehicle data included in call setup +------+ 378 Figure 2: NG-eCall 380 See Section 6 for information on how the MSD is transported within an 381 NG-eCall. 383 This document registers new service URN children within the "sos" 384 subservice. These URNs provide the mechanism by which an eCall is 385 identified, and differentiate between manually and automatically 386 triggered eCalls (which might be subject to different treatment, 387 depending on policy). The two service URNs are: 388 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 389 which requests resources associated with an emergency call placed by 390 an in-vehicle system, carrying a standardized set of data related to 391 the vehicle and incident. 393 7.1. Call Routing 395 The routing applied to eCalls might differ from those of other 396 emergency calls, as eCalls are intended to be handled by PSAPs that 397 support eCall. In regions without ESInets, typically the emergency 398 services authorities and the originating network determine how such 399 calls are routed. In a region that uses ESInets, the originating 400 network passes all types of emergency calls to an ESInet (calls which 401 have a request URI containing the "SOS" service URN). The ESInet is 402 then responsible for routing such calls to the appropriate PSAP. 404 8. Test Calls 406 eCall requires the ability to place test calls (see [TS22.101] clause 407 10.7 and [EN_16062] clause 7.2.2). These are calls that are 408 recognized and treated to some extent as eCalls but are not given 409 emergency call treatment and are not handled by call takers. The 410 specific handling of test eCalls is not itself standardized; 411 typically, the test call facility allows the IVS or user to verify 412 that an eCall can be successfully established with voice 413 communication. The IVS might also be able to verify that the MSD was 414 successfully received. 416 A service URN starting with "test." indicates a test call. For 417 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 418 This functionality is defined in [RFC6881]. 420 This document registers "urn:service:test.sos.ecall" for eCall test 421 calls. 423 The CS-eCall test call facility is a non-emergency number so does not 424 get treated as an emergency call. For NG-eCall, MNOs, emergency 425 authorities, and PSAPs can determine how to treat a vehicle call 426 requesting the "test" service URN so that the desired functionality 427 is tested, but this is outside the scope of this document. 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 there have been changes in the vehicle's state, 435 e.g., location, direction, number of fastened seatbelts). 437 This document defines a block of metadata/control data as an XML 438 structure containing eCall-specific elements. When the PSAP needs to 439 send an eCall control block that is in response to data sent by the 440 IVS in a SIP request (e.g., the MSD in the initial INVITE), the 441 control block can be sent in the SIP response to that request (e.g., 442 the response to the INVITE request). When the PSAP needs to send an 443 eCall control block in other circumstances (e.g., mid-call), the 444 control block can be transmitted from the PSAP to the IVS in a SIP 445 INFO request within the established dialog. The IVS sends the 446 requested data (the MSD) in a new INFO request. This mechanism 447 flexibly allows the PSAP to send eCall-specific data to the IVS and 448 the IVS to respond. See Section 6 for more information on attaching 449 a metadata/control block to a SIP message. 451 This mechanism requires 453 o An XML definition of the eCall control object 454 o An extension mechanism by which new elements, attributes, and 455 values can be added to the control object definition 456 o A MIME type registration for the control object (so it can be 457 carried in SIP messages and responses) 458 o An entry in the Emergency Call Additional Data Blocks sub-registry 459 (established by [I-D.ietf-ecrit-additional-data]) so that the 460 control block can be recognized as emergency call specific data 461 within SIP messages 462 o An Info-Package registration per [RFC6086] permitting data blocks 463 registered in the Emergency Call Additional Data Blocks sub- 464 registry (established by [I-D.ietf-ecrit-additional-data]) within 465 Info messages 467 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 468 initial INVITE), the PSAP sends a metadata/control block indicating 469 successful/unsuccessful receipt of the MSD in the SIP response to the 470 request. This also informs the IVS that an NG-eCall is in operation. 471 If the IVS receives a SIP response without the metadata/control 472 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 473 some part of the call is being handled as a legacy call). When the 474 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 475 receipt of a SIP INFO request containing a metadata/control block 476 requesting an MSD), the PSAP does not send a metadata/control block 477 indicating successful or unsuccessful receipt of the MSD. (Normal 478 SIP retransmission handles non-receipt of requested data; if the IVS 479 sends a requested MSD in an INFO request and does not receive a SIP 480 status message for the INFO request, it resends it; if the PSAP 481 requests an MSD and does not receive a SIP status message for the 482 INFO request, it resends it.) 484 This provides flexibility to handle various circumstances. For 485 example, if a PSAP is unable to accept an eCall (e.g., due to 486 overload or too many calls from the same location), it can reject the 487 INVITE. Since a metadata/control object is also included in the SIP 488 response that rejects the call, the IVS knows if the PSAP received 489 the MSD, and can inform the vehicle occupants that the PSAP 490 successfully received the vehicle location and information but can't 491 talk to the occupants at that time. Especially for SIP response 492 codes that indicate an inability to conduct a call (as opposed to a 493 technical inability to process the request), the IVS can also 494 determine that the call was successful on a technical level (e.g., 495 not helpful to retry as a CS-eCall). The SIP response codes 600 496 (Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when 497 the PSAP wants to reject a call but inform the vehicle occupants that 498 it is aware of the situation. (Note that there could be edge cases 499 where the PSAP response is not received by the IVS, e.g., if an 500 intermediary sends a CANCEL, and an error response is forwarded 501 towards the IVS before the error response from the PSAP is received, 502 the response will be dropped, but these are unlikely to occur here.) 504 9.1. The eCall Control Block 506 The eCall control block is an XML data structure allowing for 507 acknowledgments and requests. It is carried in a SIP body part with 508 a specific MIME content type. It can be extended via an IANA 509 registry to add additional elements, attributes, and values. Two 510 top-level elements are defined for use within an eCall control block: 512 ack Used in a control block sent by the PSAP to acknowledge 513 receipt of a data set sent by the IVS. 515 request Used in a control block sent by the PSAP to request the 516 vehicle to perform an action. The only action defined 517 in this document is a request for the IVS to send an 518 MSD. 520 Mandatory Actions (the IVS and the PSAP MUST support): 522 o Transmit data object 524 Optional Actions (the IVS and the PSAP MAY support): 526 o None 528 The element indicates the object being acknowledged (e.g., the 529 MSD), and reports success or failure. 531 The element contains attributes to indicate the request and 532 to supply related information. The 'action' attribute is mandatory 533 and indicates the specific action. An IANA registry is created in 534 Section 15.8.1 to contain the allowed values. 536 Extensibility: New elements, child elements, attributes of new and 537 existing elements, and values for new and existing attributes can be 538 added in the IANA registry created in Section 15.8.2. The registry 539 permits implementors to see what has been added, with a reference to 540 the defining document. (Implementations are not expected to 541 dynamically check the registry.) Implementations MUST ignore 542 unrecognized elements, attributes, and values (this allows new items 543 to be added without breaking older implementations). 545 9.1.1. The element 547 The element is transmitted by the PSAP to acknowledge receipt 548 of an eCall data object. An element sent by a PSAP references 549 the unique ID of the data object that was sent by the IVS, and 550 further indicates if the PSAP considers the receipt successful or 551 not. 553 The element has the following attributes: 555 9.1.1.1. Attributes of the element 557 The element has the following attributes: 559 Name: ref 560 Usage: Mandatory 561 Type: anyURI 562 Description: References the Content-ID of the body part that 563 contained the data object being acknowledged. 564 Example: 566 Name: received 567 Usage: Conditional: mandatory in an >ack< element sent by a PSAP 568 Type: Boolean 569 Description: Indicates if the referenced object was successfully 570 received or not 571 Example: 573 9.1.1.2. Child Elements of the element 575 The element has no child elements 577 9.1.1.3. Ack Examples 579 580 586 588 590 Figure 3: Ack Example from PSAP to IVS 592 9.1.2. The element 594 A element allows the PSAP to request that the IVS send an 595 MSD. The following attributes are defined: 597 9.1.2.1. Attributes of the element 599 The element has the following attributes: 601 Name: action 602 Usage: Mandatory 603 Type: token 604 Description: Identifies the action that the vehicle is requested to 605 perform. An IANA registry is established in Section 15.8.1 to 606 contain the allowed values. 607 Example: action="send-data" 609 Name: datatype 610 Usage: Conditional 611 Type: token 612 Description: Mandatory with a "send-data" action. Specifies the 613 data block that the IVS is requested to transmit, using the same 614 identifier as in the 'purpose' attribute set in a Call-Info header 615 field to point to the data block. Permitted values are contained 616 in the 'Emergency Call Data Types' IANA registry established in 617 [I-D.ietf-ecrit-additional-data]. Only the "eCall.MSD" value is 618 mandatory to support. 620 Example: datatype="eCall.MSD" 622 9.1.2.2. Request Example 624 625 631 633 635 Figure 4: Request Example 637 10. The emergencyCallData.eCall INFO package 639 This document registers the 'emergencyCallData.eCall' INFO package. 641 Both endpoints (the IVS and the PSAP equipment) include 642 'emergencyCallData.eCall' in a Recv-Info header field per [RFC6086] 643 to indicate ability to receive INFO messages carrying data as 644 described here. 646 Support for the 'emergencyCallData.eCall' INFO package indicates the 647 ability to receive body parts registered in the 'Emergency Call Data 648 Types' IANA registry. 650 An INFO request message carrying data related to an emergency call 651 has an Info-Package header field set to 'emergencyCallData.eCall' per 652 [RFC6086]. See Section 6 for details on how to attach eCall data to 653 an INFO message. 655 10.1. INFO Package Requirements 657 The requirements of Section 10 of [RFC6086] are addressed in the 658 following sections. 660 10.1.1. Overall Description 662 This section describes "what type of information is carried in INFO 663 requests associated with the Info Package, and for what types of 664 applications and functionalities UAs can use the Info Package." 665 INFO requests associated with the emergencyCallData.eCall INFO 666 package carry data associated with emergency calls as registered in 667 the 'Emergency Call Data Types' IANA registry. The application is 668 emergency calls established using SIP. The functionality is to carry 669 data, metadata, and control information (requests) between vehicles 670 and PSAPs. Refer to [TBD: THIS DOCUMENT] for more information. 672 10.1.2. Applicability 674 This section describes "why the Info Package mechanism, rather than 675 some other mechanism, has been chosen for the specific use-case...." 677 The use of INFO is based on an analysis of the requirements against 678 the intent and effects of INFO versus other approaches (which 679 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 680 transport, and non-SIP protocols). In particular, the transport of 681 emergency call data blocks occurs within a SIP emergency dialog, per 682 Section 6, and is normally carried in the initial INVITE and its 683 response; the use of INFO only occurs when emergency-call-related 684 data needs to be sent mid-call. While MESSAGE could be used, it is 685 not tied to a SIP dialog as is INFO and thus might not be associated 686 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 687 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 688 service, but the semantics are not a good fit, e.g., the subscribe/ 689 notify mechanism provides one-way communication consisting of (often 690 multiple) notifications from notifier to subscriber indicating that 691 certain events in notifier have occurred, whereas what's needed here 692 is two-way communication of data related to the emergency dialog. 693 Use of the media plane mechanisms was discounted because the number 694 of messages needing to be exchanged in a dialog is normally zero or 695 very few, and the size of the data is likewise very small. The 696 overhead caused by user plane setup (e.g., to use MSRP as transport) 697 would be disproportionately large. 699 Based on the the analyses, the SIP INFO method was chosen to provide 700 for mid-call data transport. 702 10.1.3. Info Package Name 704 The info package name is emergencyCallData.eCall. 706 10.1.4. Info Package Parameters 708 None. 710 10.1.5. SIP Option-Tags 712 None. 714 10.1.6. INFO Message Body Parts 716 Only those body parts registered in the 'Emergency Call Data Types' 717 IANA registry are associated with this INFO package. 719 When more than one body part is included, they are enclosed in a 720 multipart body part (e.g., multipart/mixed). When a body part is 721 digitally signed or encrypted, it is enclosed in an appropriate body 722 part (e.g., multipart/signed or multipart/encrypted). 724 The Content-Disposition value of a message body part associated with 725 the emergencyCallData.eCall info package is "info-package". 727 10.1.7. Info Package Usage Restrictions 729 None. 731 10.1.8. Rate of INFO Requests 733 The rate of SIP INFO requests associated with the 734 emergencyCallData.eCall info package is expected to be quite low 735 (most dialogs are likely to contain zero INFO requests, while others 736 can be expected to carry occasional requests). 738 10.1.9. Info Package Security Considerations 740 The MIME content type registation for each data block listed in the 741 'Emergency Call Data Types' IANA registry contains a discussion of 742 the security and/or privacy considerations specific to that data 743 block. The "Security Considerations" and "Privacy Considerations" 744 sections of [TBD: THIS DOCUMENT] discuss security and privacy 745 considerations of the data carried in eCealls. 747 10.1.10. Implementation Details 749 See [TBD: THIS DOCUMENT] for protocol details. 751 10.1.11. Examples 753 See [TBD: THIS DOCUMENT] for protocol examples. 755 11. Examples 757 Figure 5 illustrates an eCall. The call uses the request URI 758 'urn:service:sos.ecall.automatic' service URN and is recognized as an 759 eCall, and further as one that was invoked automatically by the IVS 760 due to a crash or other serious incident. In this example, the 761 originating network routes the call to an ESInet which routes the 762 call to the appropriate NG-eCall capable PSAP. The emergency call is 763 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 764 the entry point into the ESInet. The ESRP routes the call to a PSAP, 765 where it is received by a call taker. In deployments where there is 766 no ESInet, the originating network routes the call directly to the 767 appropriate NG-eCall capable PSAP, an illustration of which would be 768 identical to the one below except without an ESInet or ESRP. 770 +------------+ +---------------------------------------+ 771 | | | +-------+ | 772 | | | | PSAP2 | | 773 | | | +-------+ | 774 | | | | 775 | | | +------+ +-------+ | 776 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 777 | | | +------+ +-------+ | 778 | | | | 779 | | | +-------+ | 780 | | | | PSAP3 | | 781 | Originating| | +-------+ | 782 | Mobile | | | 783 | Network | | ESInet | 784 +------------+ +---------------------------------------+ 786 Figure 5: Example of NG-eCall Message Flow 788 Figure 6 illustrates an eCall call flow with a mid-call PSAP request 789 for an updated MSD. The call flow shows the IVS initiating an 790 emergency call, including the MSD in the INVITE. The PSAP includes 791 in the 200 OK response a metadata/control object acknowledging 792 receipt of the MSD. During the call, the PSAP sends a request for an 793 MSD in an INFO message. The IVS sends the requested MSD in a new 794 INFO message. 796 IVS PSAP 797 |(1) INVITE (eCall MSD) | 798 |------------------------------------------->| 799 | | 800 |(2) 200 OK (eCall metadata [ack MSD]) | 801 |<-------------------------------------------| 802 | | 803 |(3) start media stream(s) | 804 |............................................| 805 | | 806 |(4) INFO (eCall metadata [request MSD]) | 807 |<-------------------------------------------| 808 | | 809 |(5) 200 OK | 810 |------------------------------------------->| 811 | | 812 |(6) INFO (eCall MSD) | 813 |------------------------------------------->| 814 | | 815 |(7) 200 OK | 816 |<-------------------------------------------| 817 | | 818 |(8) BYE | 819 |<-------------------------------------------| 820 | | 821 |(9) end media streams | 822 |............................................| 823 | | 824 |(10) 200 OK | 825 |------------------------------------------->| 827 Figure 6: NG-eCall Call Flow Illustration 829 The example, shown in Figure 7, illustrates a SIP eCall INVITE that 830 contains an MSD. For simplicity, the example does not show all SIP 831 headers, nor the SDP contents, nor does it show any additional data 832 blocks added by the IVS or the originating mobile network. Because 833 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 834 contents cannot be included in a text document. 836 INVITE urn:service:sos.ecall.automatic SIP/2.0 837 To: urn:service:sos.ecall.automatic 838 From: ;tag=9fxced76sl 839 Call-ID: 3848276298220188511@atlanta.example.com 840 Geolocation: 841 Geolocation-Routing: no 842 Call-Info: cid:1234567890@atlanta.example.com; 843 purpose=emergencyCallData.eCall.MSD; 844 Accept: application/sdp, application/pidf+xml, 845 application/emergencyCallData.eCall.control+xml 846 CSeq: 31862 INVITE 847 Recv-Info: emergencyCallData.eCall 848 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 849 SUBSCRIBE, NOTIFY, UPDATE 850 Content-Type: multipart/mixed; boundary=boundary1 851 Content-Length: ... 853 --boundary1 854 Content-Type: application/sdp 856 ...Session Description Protocol (SDP) goes here... 858 --boundary1 859 Content-Type: application/emergencyCallData.eCall.MSD+per 860 Content-ID: 1234567890@atlanta.example.com 861 Content-Disposition: by-reference;handling=optional 862 Content-Transfer-Encoding: binary 864 ...MSD in ASN.1 PER encoding goes here... 866 --boundary1-- 868 Figure 7: SIP NG-eCall INVITE 870 Continuing the example, Figure 8 illustrates a SIP 200 OK response to 871 the INVITE of Figure 7, containing an eCall control block 872 acknowledging successful receipt of the eCall MSD. (For simplicity, 873 the example does not show all SIP headers.) 874 SIP/2.0 200 OK 875 To: ;tag=9fxced76sl 876 From: Exemplar PSAP 877 Call-ID: 3848276298220188511@atlanta.example.com 878 Call-Info: cid:2345678901@atlanta.example.com; 879 purpose=emergencyCallData.eCall.control; 880 Accept: application/sdp, application/pidf+xml, 881 application/emergencyCallData.eCall.control+xml, 882 application/emergencyCallData.eCall.MSD+per 883 CSeq: 31862 INVITE 884 Recv-Info: emergencyCallData.eCall 885 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 886 SUBSCRIBE, NOTIFY, UPDATE 887 Content-Type: multipart/mixed; boundary=boundaryX 888 Content-Length: ... 890 --boundaryX 891 Content-Type: application/sdp 893 ...Session Description Protocol (SDP) goes here... 895 --boundaryX 896 Content-Type: application/EmergencyCallData.eCall.control+xml 897 Content-ID: 2345678901@atlanta.example.com 898 Content-Disposition: by-reference;handling=optional 900 901 907 909 911 --boundaryX-- 913 Figure 8: 200 OK response to INVITE 915 Figure 9 illustrates an INFO message containing an eCall metadata/ 916 control block requesting an eCall MSD. (For simplicity, the example 917 does not show all SIP headers.) 918 INFO sip:+13145551111@example.com SIP/2.0 919 To: ;tag=9fxced76sl 920 From: Exemplar PSAP 921 Call-ID: 3848276298220188511@atlanta.example.com 922 Call-Info: cid:3456789012@atlanta.example.com; 923 purpose=emergencyCallData.eCall.control; 924 Accept: application/sdp, application/pidf+xml, 925 application/emergencyCallData.eCall.control+xml, 926 application/emergencyCallData.eCall.MSD+per 927 CSeq: 41862 INFO 928 Recv-Info: emergencyCallData.eCall 929 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 930 SUBSCRIBE, NOTIFY, UPDATE 931 Content-Type: application/EmergencyCallData.eCall.control+xml 932 Content-ID: 3456789012@atlanta.example.com 933 Content-Disposition: info-package 935 936 942 944 946 Figure 9: INFO requesting MSD 948 Figure 10 illustrates a SIP eCall INFO that contains an MSD. For 949 simplicity, the example does not show all SIP headers. Because the 950 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 951 cannot be included in a text document. 953 INFO urn:service:sos.ecall.automatic SIP/2.0 954 To: urn:service:sos.ecall.automatic 955 From: ;tag=9fxced76sl 956 Call-ID: 3848276298220188511@atlanta.example.com 957 Call-Info: cid:4567890123@atlanta.example.com; 958 purpose=emergencyCallData.eCall.MSD; 959 Accept: application/sdp, application/pidf+xml, 960 application/emergencyCallData.eCall.control+xml 961 CSeq: 51862 INFO 962 Recv-Info: emergencyCallData.eCall 963 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 964 SUBSCRIBE, NOTIFY, UPDATE 965 Content-Type: application/emergencyCallData.eCall.MSD+per 966 Content-ID: 4567890123@atlanta.example.com 967 Content-Disposition: info-package 968 Content-Transfer-Encoding: binary 970 ...MSD in ASN.1 PER encoding goes here... 972 Figure 10: INFO containing MSD 974 12. Security Considerations 976 The security considerations described in [RFC5069] apply here. 978 In addition to any network-provided location (which might be 979 determined solely by the network, or in cooperation with or possibly 980 entirely by the originating device), an eCall carries an IVS-supplied 981 location within the MSD. This is likely to be useful to the PSAP, 982 especially when no network-provided location is included, or when the 983 two locations are independently determined. Even in situations where 984 the network-supplied location is limited to the cell site, this can 985 be useful as a sanity check on the device-supplied location contained 986 in the MSD. 988 The document [RFC7378] discusses trust issues regarding location 989 provided by or determined in cooperation with end devices. 991 Security considerations specific to the mechanism by which the PSAP 992 sends acknowledgments and requests to the vehicle are discussed in 993 the "Security Considerations" block of Section 15.3. 995 Data received from external sources inherently carries implementation 996 risks. For example, depending on the platform, buffer overflows can 997 introduce remote code execution vulnerabilities, null characters can 998 corrupt strings, numeric values used for internal calculations can 999 result in underflow/overflow errors, malformed XML objects can expose 1000 parsing bugs, etc. Implementations need to be cognizant of the 1001 potential risks, observe best practices (which might include 1002 sufficiently capable static code analysis, fuzz testing, component 1003 isolation, avoiding use of unsafe coding techniques, third-party 1004 attack tests, signed software, over-the-air updates, etc.), and have 1005 multiple levels of protection. Implementors need to be aware that, 1006 potentially, the data objects described here and elsewhere might be 1007 malformed, might contain unexpected characters, excessively long 1008 attribute values, elements, etc. 1010 The security considerations discussed in 1011 [I-D.ietf-ecrit-additional-data] apply here (see especially the 1012 discussion of TLS, TLS versions, cypher suites, and PKI). 1014 When vehicle data or control/metadata is contained in a signed or 1015 encrypted body part, the enclosing multipart (e.g., multipart/signed 1016 or multipart/encrypted) has the same Content-ID as the enclosed data 1017 part. This allows an entity to identify and access the data blocks 1018 it is interested in without having to dive deeply into the message 1019 structure or decrypt parts it is not interested in. (The 'purpose' 1020 parameter in a Call-Info header field identifies the data and 1021 contains a CID URL pointing to the data block in the body, which has 1022 a matching Content-ID body part header field). 1024 13. Privacy Considerations 1026 The privacy considerations discussed in 1027 [I-D.ietf-ecrit-additional-data] apply here. The MSD carries some 1028 identifying and personal information (mostly about the vehicle and 1029 less about the owner), as well as location information, and so needs 1030 to be protected against unauthorized disclosure. Local regulations 1031 may impose additional privacy protection requirements. 1033 Privacy considerations specific to the data structure containing 1034 vehicle information are discussed in the "Security Considerations" 1035 block of Section 15.2. 1037 Privacy considerations specific to the mechanism by which the PSAP 1038 sends acknowledgments and requests to the vehicle are discussed in 1039 the "Security Considerations" block of Section 15.3. 1041 14. XML Schema 1043 This section defines an XML schema for the eCall control block. The 1044 text description of the eCall control block in Section 9.1 is 1045 normative and supersedes any conflicting aspect of this schema. 1047 1048 1057 1060 1063 1064 1065 Permitted values specified in IANA 1066 registries 1067 1068 1070 1071 1072 1073 1074 1075 1077 1079 1082 1083 1084 1085 1086 1088 1089 1090 1091 1093 1097 1098 1100 1103 1105 1106 1107 1108 1110 1111 1112 1113 1114 1117 1118 1119 1121 1124 1125 1126 1127 1129 1131 Figure 11: eCall Control Block Schema 1133 15. IANA Considerations 1135 15.1. Service URN Registrations 1137 IANA is requested to register the URN 'urn:service:sos.ecall' under 1138 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1140 This service requests resources associated with an emergency call 1141 placed by an in-vehicle system, carrying a standardized set of data 1142 related to the vehicle and incident. Two sub-services are registered 1143 as well: 1145 urn:service:sos.ecall.manual 1147 Used with an eCall invoked due to manual interaction by a vehicle 1148 occupant. 1150 urn:service:sos.ecall.automatic 1152 Used with an eCall invoked automatically, for example, due to a 1153 crash or other serious incident. 1155 IANA is also requested to register the URN 1156 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1157 defined in Setcion 17.2 of [RFC6881]. 1159 15.2. MIME Content-type Registration for 'application/ 1160 emergencyCallData.eCall.MSD+per' 1162 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1163 as a MIME content type, with a reference to this document, in 1164 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1165 RFC 7303 [RFC7303]. 1167 MIME media type name: application 1169 MIME subtype name: emergencyCallData.eCall.MSD+per 1171 Mandatory parameters: none 1173 Optional parameters: none 1175 Encoding scheme: binary 1177 Encoding considerations: Uses ASN.1 PER, which is a binary 1178 encoding; when transported in SIP, binary content transfer 1179 encoding is used. 1181 Security considerations: This content type is designed to carry 1182 vehicle and incident-related data during an emergency call. This 1183 data contains personal information including vehicle VIN, 1184 location, direction, etc. Appropriate precautions need to be 1185 taken to limit unauthorized access, inappropriate disclosure to 1186 third parties, and eavesdropping of this information. In general, 1187 it is acceptable for the data to be unprotected while briefly in 1188 transit within the Mobile Network Operator (MNO); the MNO is 1189 trusted to not permit the data to be accessed by third parties. 1190 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1191 contain more discussion. 1193 Interoperability considerations: None 1195 Published specification: Annex A of EN 15722 [msd] 1197 Applications which use this media type: Pan-European eCall 1198 compliant systems 1200 Additional information: None 1202 Magic Number: None 1204 File Extension: None 1206 Macintosh file type code: 'BINA' 1208 Person and email address for further information: Randall Gellens, 1209 rg+ietf@randy.pensive.org 1211 Intended usage: LIMITED USE 1213 Author: The MSD specification was produced by the European 1214 Committee For Standardization (CEN). For contact information, 1215 please see . 1217 Change controller: The European Committee For Standardization 1218 (CEN) 1220 15.3. MIME Content-type Registration for 'application/ 1221 emergencyCallData.eCall.control+xml' 1223 IANA is requested to add application/ 1224 emergencyCallData.eCall.control+xml as a MIME content type, with a 1225 reference to this document, in accordance to the procedures of RFC 1226 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1228 MIME media type name: application 1230 MIME subtype name: emergencyCallData.eCall.control+xml 1232 Mandatory parameters: none 1234 Optional parameters: charset 1235 Indicates the character encoding of the XML content. 1237 Encoding considerations: Uses XML, which can employ 8-bit 1238 characters, depending on the character encoding used. See 1239 Section 3.2 of RFC 7303 [RFC7303]. 1241 Security considerations: 1243 This content type carries metadata and control information and 1244 requests, such as from a Public Safety Answering Point (PSAP) 1245 to an In-Vehicle System (IVS) during an emergency call. 1247 Metadata (such as an acknowledgment that data sent by the IVS 1248 to the PSAP was successfully received) has limited privacy and 1249 security implications. Control information (such as requests 1250 from the PSAP that the vehicle perform an action) has some 1251 privacy and security implications. The privacy concern arises 1252 from the ability to request the vehicle to transmit a data set, 1253 which as described in Section 15.2, can contain personal 1254 information. The security concern is the ability to request 1255 the vehicle to perform an action. Control information needs to 1256 originate only from a PSAP or other emergency services 1257 provider, and not be modified en-route. The level of integrity 1258 of the cellular network over which the emergency call is placed 1259 is a consideration: when the IVS initiates an eCall over a 1260 cellular network, in most cases it relies on the MNO to route 1261 the call to a PSAP. (Calls placed using other means, such as 1262 Wi-Fi or over-the-top services, generally incur somewhat higher 1263 levels of risk than calls placed "natively" using cellular 1264 networks.) A call-back from a PSAP merits additional 1265 consideration, since current mechanisms are not ideal for 1266 verifying that such a call is indeed a call-back from a PSAP in 1267 response to an emergency call placed by the IVS. See the 1268 discussion in Section 12 and the PSAP Callback document 1269 [RFC7090]. 1271 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1272 contain more discussion. 1274 Interoperability considerations: None 1276 Published specification: This document 1278 Applications which use this media type: Pan-European eCall 1279 compliant systems 1281 Additional information: None 1282 Magic Number: None 1284 File Extension: .xml 1286 Macintosh file type code: 'TEXT' 1288 Person and email address for further information: Randall Gellens, 1289 rg+ietf@randy.pensive.org 1291 Intended usage: LIMITED USE 1293 Author: The IETF ECRIT WG. 1295 Change controller: The IETF ECRIT WG. 1297 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1298 Additional Data Blocks registry 1300 This specification requests IANA to add the 'eCall.MSD' entry to the 1301 Emergency Call Additional Data Blocks registry, with a reference to 1302 this document. 1304 15.5. Registration of the 'eCall.control' entry in the Emergency Call 1305 Additional Data Blocks registry 1307 This specification requests IANA to add the 'eCall.control' entry to 1308 the Emergency Call Additional Data Blocks registry, with a reference 1309 to this document. 1311 15.6. Registration of the emergencyCallData.eCall Info Package 1313 IANA is requested to add emergencyCallData.eCall to the Info Packages 1314 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1315 reference to this document. 1317 15.7. URN Sub-Namespace Registration 1319 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1321 This section registers a new XML namespace, as per the guidelines in 1322 RFC 3688 [RFC3688]. 1324 URI: urn:ietf:params:xml:ns:eCall 1326 Registrant Contact: IETF, ECRIT working group, , as 1327 delegated by the IESG . 1329 XML: 1331 BEGIN 1332 1333 1335 1336 1337 1339 Namespace for eCall Data 1340 1341 1342

Namespace for eCall Data

1343

See [TBD: This document].

1344 1345 1346 END 1348 15.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1350 This section registers a new XML namespace, as per the guidelines in 1351 RFC 3688 [RFC3688]. 1353 URI: urn:ietf:params:xml:ns:eCall:control 1355 Registrant Contact: IETF, ECRIT working group, , as 1356 delegated by the IESG . 1358 XML: 1360 BEGIN 1361 1362 1364 1365 1366 1368 Namespace for eCall Data: 1369 Control Block 1370 1371 1372

Namespace for eCall Data

1373

Control Block

1374

See [TBD: This document].

1375 1376 1377 END 1379 15.8. Registry creation 1381 This document creates a new registry called 'eCall Control Data'. 1382 The following sub-registries are created for this registry. 1384 15.8.1. eCall Control Action Registry 1386 This document creates a new sub-registry called "eCall Control Action 1387 Registry". As defined in [RFC5226], this registry operates under 1388 "Expert Review" rules. The expert should determine that the proposed 1389 action is within the purview of a vehicle, is sufficiently 1390 distinguishable from other actions, and the action is clearly and 1391 fully described. In most cases, a published and stable document is 1392 referenced for the description of the action. 1394 The content of this registry includes: 1396 Name: The identifier to be used in the 'action' attribute of an 1397 eCall control element. 1399 Description: A description of the action. In most cases this will 1400 be a reference to a published and stable document. The 1401 description MUST specify if any attributes or child elements are 1402 optional or mandatory, and describe the action to be taken by the 1403 vehicle. 1405 The initial set of values is listed in Table 2. 1407 +-----------+--------------------------------------+ 1408 | Name | Description | 1409 +-----------+--------------------------------------+ 1410 | send-data | See Section 9.1.2.1 of this document | 1411 +-----------+--------------------------------------+ 1413 Table 2: eCall Control Action Registry Initial Values 1415 15.8.2. eCall Control Extension Registry 1417 This document creates a new sub-registry called "eCall Control 1418 Extension Registry". This registry contains elements, attributes, 1419 and values for the eCall metadata/control object. As defined in 1420 [RFC5226], this registry operates under "Expert Review" rules. The 1421 expert should determine that the proposed elements, attributes, and/ 1422 or values are within the purview of a vehicle, are sufficiently 1423 distinguishable, and clearly and fully described. In most cases, a 1424 published and stable document is referenced for the description of 1425 each element, attribute, or value. New values MUST indicate for 1426 which attributes or elements they are appropriate. New attributes 1427 MUST indicate in which elements they can appear and to which values 1428 that can be set. New elements MUST indicate if they can appear as 1429 child elements within other elements, and if so which elements, and/ 1430 or if they can appear at the top level of an eCall metadata/control 1431 object. New elements MUST also describe which attributes and/or sub- 1432 elements they can contain and which are optional and which are 1433 mandatory. Note that this mechanism allows new items to be added 1434 while maintaining compatibility with existing implementations, since 1435 unrecognized items are ignored. 1437 The content of this registry includes: 1439 Type: 'Element', 'Attribute', or 'Value'. 1441 Name: The name of the new element or attribute. Not used for new 1442 values. 1444 Description: A description of the element, attribute, or value. In 1445 most cases this will be a reference to a published and stable 1446 document. 1448 16. Contributors 1450 Brian Rosen was a co-author of the original document upon which this 1451 document is based. 1453 17. Acknowledgements 1455 We would like to thank Bob Williams and Ban Al-Bakri for their 1456 feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith 1457 Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and 1458 James Winterbottom for their review and comments; Robert Sparks and 1459 Paul Kyzivat for their help with the SIP mechanisms. We would like 1460 to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and 1461 Ulrich Dietz for their help with the original document upon which 1462 this document is based. 1464 18. Changes from Previous Versions 1466 18.1. Changes from draft-ietf-08 to draft-ietf-09 1468 o Created a new "Data Transport" section that describes how the MSD 1469 and metadata/control blocks are attached, and then referred to 1470 that section rather than repeat the information about the CID and 1471 Call-Info and so forth, which means most references to the 1472 additional-data draft have now been deleted 1473 o Mentioned edge cases where a PSAP response to INVITE isn't 1474 received by the IVS 1475 o Reworded description of which status codes are used when a PSAP 1476 wishes to reject a call but inform the vehicle occupants that it 1477 is aware of the situation to be more definite 1478 o Added examples showing INFO 1479 o Added references for eCall test call requirement 1480 o Described meaning of eCall URNs in Section 8 as well as in IANA 1481 registration 1483 18.2. Changes from draft-ietf-07 to draft-ietf-08 1485 o eCall MSD now encoded as ASN.1 PER, using binary content transfer 1486 encoding 1487 o Added text to point out aspects of call handling and metadata/ 1488 control usage, such as use in rejected calls, and solicited MSDs 1489 o Revised use of INFO to require that when a request for an MSD is 1490 sent in INFO, the MSD sent in response is in its own INFO, not the 1491 response to the requesting INFO 1492 o Added material to INFO package registation to comply with 1493 Section 10 of [RFC6086] 1494 o Moved material not required by 3GPP into 1495 [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ 1496 control elements, attributes, and values 1497 o Revised test call wording to clarify that specific handling is out 1498 of scope 1499 o Revised wording throughout the document to simplify 1500 o Moved new Section Section 7.1 to be a subsection of Section 7 1501 o Moved new Section Section 10 to be a main section instead of a 1502 subsection of Section 9 1503 o Revised SIP INFO usage and package registration per advice from 1504 Robert Sparks and Paul Kyzivat 1506 18.3. Changes from draft-ietf-06 to draft-ietf-07 1508 o Fixed typo in Acknowledgements 1510 18.4. Changes from draft-ietf-05 to draft-ietf-06 1512 o Added additional security and privacy clarifications regarding 1513 signed and encrypted data 1514 o Additional security and privacy text 1515 o Deleted informative section on ESINets as unnecessary. 1517 18.5. Changes from draft-ietf-04 to draft-ietf-05 1519 o Reworked the security and privacy considerations material in the 1520 document as a whole and in the MIME registation sections of the 1521 MSD and control objects 1522 o Clarified that the element can appear multiple 1523 times within an element 1524 o Fixed IMS definition 1525 o Added clarifying text for the 'msgid' attribute 1527 18.6. Changes from draft-ietf-03 to draft-ietf-04 1529 o Added Privacy Considerations section 1530 o Reworded most uses of non-normative "may", "should", "must", and 1531 "recommended." 1532 o Fixed nits in examples 1534 18.7. Changes from draft-ietf-02 to draft-ietf-03 1536 o Added request to enable cameras 1537 o Improved examples and XML schema 1538 o Clarifications and wording improvements 1540 18.8. Changes from draft-ietf-01 to draft-ietf-02 1542 o Added clarifying text reinforcing that the data exchange is for 1543 small blocks of data infrequently transmitted 1544 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1545 establish a one-way media stream 1546 o Clarified that the scope is the needs of eCall within the SIP 1547 emergency call environment 1549 o Added informative statement that the document may be suitable for 1550 reuse by other ACN systems 1551 o Clarified that normative language for the control block applies to 1552 both IVS and PSAP 1553 o Removed 'ref', 'supported-mime', and elements 1554 o Minor wording improvements and clarifications 1556 18.9. Changes from draft-ietf-00 to draft-ietf-01 1558 o Added further discussion of test calls 1559 o Added further clarification to the document scope 1560 o Mentioned that multi-region vehicles may need to support other 1561 crash notification specifications in addition to eCall 1562 o Added details of the eCall metadata and control functionality 1563 o Added IANA registration for the MIME content type for the eCall 1564 control object 1565 o Added IANA registries for protocol elements and tokens used in the 1566 eCall control object 1567 o Minor wording improvements and clarifications 1569 18.10. Changes from draft-gellens-03 to draft-ietf-00 1571 o Renamed from draft-gellens- to draft-ietf-. 1572 o Added mention of and reference to ETSI TR "Mobile Standards Group 1573 (MSG); eCall for VoIP" 1574 o Added text to Introduction regarding migration/co-existence being 1575 out of scope 1576 o Added mention in Security Considerations that even if the network- 1577 supplied location is just the cell site, this can be useful as a 1578 sanity check on the IVS-supplied location 1579 o Minor wording improvements and clarifications 1581 18.11. Changes from draft-gellens-02 to -03 1583 o Clarifications and editorial improvements. 1585 18.12. Changes from draft-gellens-01 to -02 1587 o Minor wording improvements 1588 o Removed ".automatic" and ".manual" from 1589 "urn:service:test.sos.ecall" registration and discussion text. 1591 18.13. Changes from draft-gellens-00 to -01 1593 o Now using 'EmergencyCallData' for purpose parameter values and 1594 MIME subtypes, in accordance with changes to 1595 [I-D.ietf-ecrit-additional-data] 1596 o Added reference to RFC 6443 1597 o Fixed bug that caused Figure captions to not appear 1599 19. References 1601 19.1. Normative References 1603 [EN_16062] 1604 CEN, , "Intelligent transport systems - eSafety - eCall 1605 High Level Application Requirements (HLAP) Using GSM/UMTS 1606 Circuit Switched Networks, EN 16062", April 2015. 1608 [EN_16072] 1609 CEN, , "Intelligent transport systems - eSafety - Pan- 1610 European eCall operating requirements, EN 16072", April 1611 2015. 1613 [I-D.ietf-ecrit-additional-data] 1614 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1615 J. Winterbottom, "Additional Data Related to an Emergency 1616 Call", draft-ietf-ecrit-additional-data-38 (work in 1617 progress), April 2016. 1619 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1620 minimum set of data (MSD), EN 15722", April 2015. 1622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1623 Requirement Levels", BCP 14, RFC 2119, 1624 DOI 10.17487/RFC2119, March 1997, 1625 . 1627 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1628 DOI 10.17487/RFC3688, January 2004, 1629 . 1631 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1632 Emergency and Other Well-Known Services", RFC 5031, 1633 DOI 10.17487/RFC5031, January 2008, 1634 . 1636 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1637 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1638 DOI 10.17487/RFC5226, May 2008, 1639 . 1641 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1642 "Framework for Emergency Calling Using Internet 1643 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1644 2011, . 1646 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1647 Specifications and Registration Procedures", BCP 13, 1648 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1649 . 1651 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1652 Communications Services in Support of Emergency Calling", 1653 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1654 . 1656 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1657 DOI 10.17487/RFC7303, July 2014, 1658 . 1660 [TS22.101] 1661 3GPP, , "3GPP TS 22.101: Technical Specification Group 1662 Services and System Aspects; Service aspects; Service 1663 principles". 1665 19.2. Informative references 1667 [CEN] "European Committee for Standardization", 1668 . 1670 [I-D.ietf-ecrit-car-crash] 1671 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1672 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1673 ecrit-car-crash-08 (work in progress), July 2016. 1675 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1676 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1677 April 2014. 1679 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1680 Emergency Context Resolution with Internet Technologies", 1681 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1682 . 1684 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1685 Shanmugam, "Security Threats and Requirements for 1686 Emergency Call Marking and Mapping", RFC 5069, 1687 DOI 10.17487/RFC5069, January 2008, 1688 . 1690 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1691 Initiation Protocol (SIP) INFO Method and Package 1692 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1693 . 1695 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1696 Patel, "Public Safety Answering Point (PSAP) Callback", 1697 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1698 . 1700 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1701 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1702 December 2014, . 1704 [SDO-3GPP] 1705 "3d Generation Partnership Project", 1706 . 1708 [SDO-ETSI] 1709 "European Telecommunications Standards Institute (ETSI)", 1710 . 1712 Authors' Addresses 1714 Randall Gellens 1715 Core Technology Consulting 1717 Email: rg+ietf@randy.pensive.org 1719 Hannes Tschofenig 1720 Individual 1722 Email: Hannes.Tschofenig@gmx.net 1723 URI: http://www.tschofenig.priv.at