idnits 2.17.00 (12 Aug 2021) /tmp/idnits61412/draft-ietf-ecrit-ecall-10.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-10.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 . . . . . . . . . . . . . . . . 15 80 10.1.2. Applicability . . . . . . . . . . . . . . . . . . . 15 81 10.1.3. Info Package Name . . . . . . . . . . . . . . . . . 15 82 10.1.4. Info Package Parameters . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . 17 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 focused on 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 also provide a basis for 182 reuse and extension for other vehicle-initiated emergency call 183 systems. 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. Because new body parts can be added to the 649 registry, implementations MUST ignore any unsupported or unrecognized 650 body parts. Only the 'application/emergencyCallData.eCall.MSD+per' 651 and 'application/emergencyCallData.eCall.control+xml' body parts are 652 REQUIRED to be supported for conformance with this document. 654 An INFO request message carrying data related to an emergency call 655 has an Info-Package header field set to 'emergencyCallData.eCall' per 656 [RFC6086]. See Section 6 for details on how to attach eCall data to 657 an INFO message. 659 10.1. INFO Package Requirements 661 The requirements of Section 10 of [RFC6086] are addressed in the 662 following sections. 664 10.1.1. Overall Description 666 This section describes "what type of information is carried in INFO 667 requests associated with the Info Package, and for what types of 668 applications and functionalities UAs can use the Info Package." 670 INFO requests associated with the emergencyCallData.eCall INFO 671 package carry data associated with emergency calls as registered in 672 the 'Emergency Call Data Types' IANA registry. The application is 673 emergency calls established using SIP. The functionality is to carry 674 data, metadata, and control information (requests) between vehicles 675 and PSAPs. Refer to [TBD: THIS DOCUMENT] for more information. 677 10.1.2. Applicability 679 This section describes "why the Info Package mechanism, rather than 680 some other mechanism, has been chosen for the specific use-case...." 682 The use of INFO is based on an analysis of the requirements against 683 the intent and effects of INFO versus other approaches (which 684 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 685 transport, and non-SIP protocols). In particular, the transport of 686 emergency call data blocks occurs within a SIP emergency dialog, per 687 Section 6, and is normally carried in the initial INVITE and its 688 response; the use of INFO only occurs when emergency-call-related 689 data needs to be sent mid-call. While MESSAGE could be used, it is 690 not tied to a SIP dialog as is INFO and thus might not be associated 691 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 692 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 693 service, but the semantics are not a good fit, e.g., the subscribe/ 694 notify mechanism provides one-way communication consisting of (often 695 multiple) notifications from notifier to subscriber indicating that 696 certain events in notifier have occurred, whereas what's needed here 697 is two-way communication of data related to the emergency dialog. 698 Use of the media plane mechanisms was discounted because the number 699 of messages needing to be exchanged in a dialog is normally zero or 700 very few, and the size of the data is likewise very small. The 701 overhead caused by user plane setup (e.g., to use MSRP as transport) 702 would be disproportionately large. 704 Based on the the analyses, the SIP INFO method was chosen to provide 705 for mid-call data transport. 707 10.1.3. Info Package Name 709 The info package name is emergencyCallData.eCall. 711 10.1.4. Info Package Parameters 713 None. 715 10.1.5. SIP Option-Tags 717 None. 719 10.1.6. INFO Message Body Parts 721 Only those body parts registered in the 'Emergency Call Data Types' 722 IANA registry are associated with this INFO package. 724 When more than one body part is included, they are enclosed in a 725 multipart body part (e.g., multipart/mixed). When a body part is 726 digitally signed or encrypted, it is enclosed in an appropriate body 727 part (e.g., multipart/signed or multipart/encrypted). 729 The Content-Disposition value of a message body part associated with 730 the emergencyCallData.eCall info package is "info-package". 732 10.1.7. Info Package Usage Restrictions 734 None. 736 10.1.8. Rate of INFO Requests 738 The rate of SIP INFO requests associated with the 739 emergencyCallData.eCall info package is expected to be quite low 740 (most dialogs are likely to contain zero INFO requests, while others 741 can be expected to carry occasional requests). 743 10.1.9. Info Package Security Considerations 745 The MIME content type registation for each data block listed in the 746 'Emergency Call Data Types' IANA registry contains a discussion of 747 the security and/or privacy considerations specific to that data 748 block. The "Security Considerations" and "Privacy Considerations" 749 sections of [TBD: THIS DOCUMENT] discuss security and privacy 750 considerations of the data carried in eCealls. 752 10.1.10. Implementation Details 754 See [TBD: THIS DOCUMENT] for protocol details. 756 10.1.11. Examples 758 See [TBD: THIS DOCUMENT] for protocol examples. 760 11. Examples 762 Figure 5 illustrates an eCall. The call uses the request URI 763 'urn:service:sos.ecall.automatic' service URN and is recognized as an 764 eCall, and further as one that was invoked automatically by the IVS 765 due to a crash or other serious incident. In this example, the 766 originating network routes the call to an ESInet which routes the 767 call to the appropriate NG-eCall capable PSAP. The emergency call is 768 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 769 the entry point into the ESInet. The ESRP routes the call to a PSAP, 770 where it is received by a call taker. In deployments where there is 771 no ESInet, the originating network routes the call directly to the 772 appropriate NG-eCall capable PSAP, an illustration of which would be 773 identical to the one below except without an ESInet or ESRP. 775 +------------+ +---------------------------------------+ 776 | | | +-------+ | 777 | | | | PSAP2 | | 778 | | | +-------+ | 779 | | | | 780 | | | +------+ +-------+ | 781 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 782 | | | +------+ +-------+ | 783 | | | | 784 | | | +-------+ | 785 | | | | PSAP3 | | 786 | Originating| | +-------+ | 787 | Mobile | | | 788 | Network | | ESInet | 789 +------------+ +---------------------------------------+ 791 Figure 5: Example of NG-eCall Message Flow 793 Figure 6 illustrates an eCall call flow with a mid-call PSAP request 794 for an updated MSD. The call flow shows the IVS initiating an 795 emergency call, including the MSD in the INVITE. The PSAP includes 796 in the 200 OK response a metadata/control object acknowledging 797 receipt of the MSD. During the call, the PSAP sends a request for an 798 MSD in an INFO message. The IVS sends the requested MSD in a new 799 INFO message. 801 IVS PSAP 802 |(1) INVITE (eCall MSD) | 803 |------------------------------------------->| 804 | | 805 |(2) 200 OK (eCall metadata [ack MSD]) | 806 |<-------------------------------------------| 807 | | 808 |(3) start media stream(s) | 809 |............................................| 810 | | 811 |(4) INFO (eCall metadata [request MSD]) | 812 |<-------------------------------------------| 813 | | 814 |(5) 200 OK | 815 |------------------------------------------->| 816 | | 817 |(6) INFO (eCall MSD) | 818 |------------------------------------------->| 819 | | 820 |(7) 200 OK | 821 |<-------------------------------------------| 822 | | 823 |(8) BYE | 824 |<-------------------------------------------| 825 | | 826 |(9) end media streams | 827 |............................................| 828 | | 829 |(10) 200 OK | 830 |------------------------------------------->| 832 Figure 6: NG-eCall Call Flow Illustration 834 The example, shown in Figure 7, illustrates a SIP eCall INVITE that 835 contains an MSD. For simplicity, the example does not show all SIP 836 headers, nor the SDP contents, nor does it show any additional data 837 blocks added by the IVS or the originating mobile network. Because 838 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 839 contents cannot be included in a text document. 841 INVITE urn:service:sos.ecall.automatic SIP/2.0 842 To: urn:service:sos.ecall.automatic 843 From: ;tag=9fxced76sl 844 Call-ID: 3848276298220188511@atlanta.example.com 845 Geolocation: 846 Geolocation-Routing: no 847 Call-Info: cid:1234567890@atlanta.example.com; 848 purpose=emergencyCallData.eCall.MSD; 849 Accept: application/sdp, application/pidf+xml, 850 application/emergencyCallData.eCall.control+xml 851 CSeq: 31862 INVITE 852 Recv-Info: emergencyCallData.eCall 853 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 854 SUBSCRIBE, NOTIFY, UPDATE 855 Content-Type: multipart/mixed; boundary=boundary1 856 Content-Length: ... 858 --boundary1 859 Content-Type: application/sdp 861 ...Session Description Protocol (SDP) goes here... 863 --boundary1 864 Content-Type: application/emergencyCallData.eCall.MSD+per 865 Content-ID: 1234567890@atlanta.example.com 866 Content-Disposition: by-reference;handling=optional 867 Content-Transfer-Encoding: binary 869 ...MSD in ASN.1 PER encoding goes here... 871 --boundary1-- 873 Figure 7: SIP NG-eCall INVITE 875 Continuing the example, Figure 8 illustrates a SIP 200 OK response to 876 the INVITE of Figure 7, containing an eCall control block 877 acknowledging successful receipt of the eCall MSD. (For simplicity, 878 the example does not show all SIP headers.) 879 SIP/2.0 200 OK 880 To: ;tag=9fxced76sl 881 From: Exemplar PSAP 882 Call-ID: 3848276298220188511@atlanta.example.com 883 Call-Info: cid:2345678901@atlanta.example.com; 884 purpose=emergencyCallData.eCall.control; 885 Accept: application/sdp, application/pidf+xml, 886 application/emergencyCallData.eCall.control+xml, 887 application/emergencyCallData.eCall.MSD+per 888 CSeq: 31862 INVITE 889 Recv-Info: emergencyCallData.eCall 890 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 891 SUBSCRIBE, NOTIFY, UPDATE 892 Content-Type: multipart/mixed; boundary=boundaryX 893 Content-Length: ... 895 --boundaryX 896 Content-Type: application/sdp 898 ...Session Description Protocol (SDP) goes here... 900 --boundaryX 901 Content-Type: application/EmergencyCallData.eCall.control+xml 902 Content-ID: 2345678901@atlanta.example.com 903 Content-Disposition: by-reference;handling=optional 905 906 912 914 916 --boundaryX-- 918 Figure 8: 200 OK response to INVITE 920 Figure 9 illustrates an INFO message containing an eCall metadata/ 921 control block requesting an eCall MSD. (For simplicity, the example 922 does not show all SIP headers.) 923 INFO sip:+13145551111@example.com SIP/2.0 924 To: ;tag=9fxced76sl 925 From: Exemplar PSAP 926 Call-ID: 3848276298220188511@atlanta.example.com 927 Call-Info: cid:3456789012@atlanta.example.com; 928 purpose=emergencyCallData.eCall.control; 929 Accept: application/sdp, application/pidf+xml, 930 application/emergencyCallData.eCall.control+xml, 931 application/emergencyCallData.eCall.MSD+per 932 CSeq: 41862 INFO 933 Recv-Info: emergencyCallData.eCall 934 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 935 SUBSCRIBE, NOTIFY, UPDATE 936 Content-Type: application/EmergencyCallData.eCall.control+xml 937 Content-ID: 3456789012@atlanta.example.com 938 Content-Disposition: info-package 940 941 947 949 951 Figure 9: INFO requesting MSD 953 Figure 10 illustrates a SIP eCall INFO that contains an MSD. For 954 simplicity, the example does not show all SIP headers. Because the 955 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 956 cannot be included in a text document. 958 INFO urn:service:sos.ecall.automatic SIP/2.0 959 To: urn:service:sos.ecall.automatic 960 From: ;tag=9fxced76sl 961 Call-ID: 3848276298220188511@atlanta.example.com 962 Call-Info: cid:4567890123@atlanta.example.com; 963 purpose=emergencyCallData.eCall.MSD; 964 Accept: application/sdp, application/pidf+xml, 965 application/emergencyCallData.eCall.control+xml 966 CSeq: 51862 INFO 967 Recv-Info: emergencyCallData.eCall 968 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 969 SUBSCRIBE, NOTIFY, UPDATE 970 Content-Type: application/emergencyCallData.eCall.MSD+per 971 Content-ID: 4567890123@atlanta.example.com 972 Content-Disposition: info-package 973 Content-Transfer-Encoding: binary 975 ...MSD in ASN.1 PER encoding goes here... 977 Figure 10: INFO containing MSD 979 12. Security Considerations 981 The security considerations described in [RFC5069] apply here. 983 In addition to any network-provided location (which might be 984 determined solely by the network, or in cooperation with or possibly 985 entirely by the originating device), an eCall carries an IVS-supplied 986 location within the MSD. This is likely to be useful to the PSAP, 987 especially when no network-provided location is included, or when the 988 two locations are independently determined. Even in situations where 989 the network-supplied location is limited to the cell site, this can 990 be useful as a sanity check on the device-supplied location contained 991 in the MSD. 993 The document [RFC7378] discusses trust issues regarding location 994 provided by or determined in cooperation with end devices. 996 Security considerations specific to the mechanism by which the PSAP 997 sends acknowledgments and requests to the vehicle are discussed in 998 the "Security Considerations" block of Section 15.3. 1000 Data received from external sources inherently carries implementation 1001 risks. For example, depending on the platform, buffer overflows can 1002 introduce remote code execution vulnerabilities, null characters can 1003 corrupt strings, numeric values used for internal calculations can 1004 result in underflow/overflow errors, malformed XML objects can expose 1005 parsing bugs, etc. Implementations need to be cognizant of the 1006 potential risks, observe best practices (which might include 1007 sufficiently capable static code analysis, fuzz testing, component 1008 isolation, avoiding use of unsafe coding techniques, third-party 1009 attack tests, signed software, over-the-air updates, etc.), and have 1010 multiple levels of protection. Implementors need to be aware that, 1011 potentially, the data objects described here and elsewhere might be 1012 malformed, might contain unexpected characters, excessively long 1013 attribute values, elements, etc. 1015 The security considerations discussed in 1016 [I-D.ietf-ecrit-additional-data] apply here (see especially the 1017 discussion of TLS, TLS versions, cypher suites, and PKI). 1019 When vehicle data or control/metadata is contained in a signed or 1020 encrypted body part, the enclosing multipart (e.g., multipart/signed 1021 or multipart/encrypted) has the same Content-ID as the enclosed data 1022 part. This allows an entity to identify and access the data blocks 1023 it is interested in without having to dive deeply into the message 1024 structure or decrypt parts it is not interested in. (The 'purpose' 1025 parameter in a Call-Info header field identifies the data and 1026 contains a CID URL pointing to the data block in the body, which has 1027 a matching Content-ID body part header field). 1029 13. Privacy Considerations 1031 The privacy considerations discussed in 1032 [I-D.ietf-ecrit-additional-data] apply here. The MSD carries some 1033 identifying and personal information (mostly about the vehicle and 1034 less about the owner), as well as location information, and so needs 1035 to be protected against unauthorized disclosure. Local regulations 1036 may impose additional privacy protection requirements. 1038 Privacy considerations specific to the data structure containing 1039 vehicle information are discussed in the "Security Considerations" 1040 block of Section 15.2. 1042 Privacy considerations specific to the mechanism by which the PSAP 1043 sends acknowledgments and requests to the vehicle are discussed in 1044 the "Security Considerations" block of Section 15.3. 1046 14. XML Schema 1048 This section defines an XML schema for the eCall control block. The 1049 text description of the eCall control block in Section 9.1 is 1050 normative and supersedes any conflicting aspect of this schema. 1052 1053 1062 1065 1068 1069 1070 Permitted values specified in IANA 1071 registries 1072 1073 1075 1076 1077 1078 1079 1080 1082 1084 1087 1088 1089 1090 1091 1093 1094 1095 1096 1098 1102 1103 1105 1108 1110 1111 1112 1113 1115 1116 1117 1118 1119 1122 1123 1124 1126 1129 1130 1131 1132 1134 1136 Figure 11: eCall Control Block Schema 1138 15. IANA Considerations 1140 15.1. Service URN Registrations 1142 IANA is requested to register the URN 'urn:service:sos.ecall' under 1143 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1145 This service requests resources associated with an emergency call 1146 placed by an in-vehicle system, carrying a standardized set of data 1147 related to the vehicle and incident. Two sub-services are registered 1148 as well: 1150 urn:service:sos.ecall.manual 1152 Used with an eCall invoked due to manual interaction by a vehicle 1153 occupant. 1155 urn:service:sos.ecall.automatic 1157 Used with an eCall invoked automatically, for example, due to a 1158 crash or other serious incident. 1160 IANA is also requested to register the URN 1161 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1162 defined in Setcion 17.2 of [RFC6881]. 1164 15.2. MIME Content-type Registration for 'application/ 1165 emergencyCallData.eCall.MSD+per' 1167 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1168 as a MIME content type, with a reference to this document, in 1169 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1170 RFC 7303 [RFC7303]. 1172 MIME media type name: application 1174 MIME subtype name: emergencyCallData.eCall.MSD+per 1176 Mandatory parameters: none 1178 Optional parameters: none 1180 Encoding scheme: binary 1182 Encoding considerations: Uses ASN.1 PER, which is a binary 1183 encoding; when transported in SIP, binary content transfer 1184 encoding is used. 1186 Security considerations: This content type is designed to carry 1187 vehicle and incident-related data during an emergency call. This 1188 data contains personal information including vehicle VIN, 1189 location, direction, etc. Appropriate precautions need to be 1190 taken to limit unauthorized access, inappropriate disclosure to 1191 third parties, and eavesdropping of this information. In general, 1192 it is acceptable for the data to be unprotected while briefly in 1193 transit within the Mobile Network Operator (MNO); the MNO is 1194 trusted to not permit the data to be accessed by third parties. 1195 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1196 contain more discussion. 1198 Interoperability considerations: None 1200 Published specification: Annex A of EN 15722 [msd] 1202 Applications which use this media type: Pan-European eCall 1203 compliant systems 1205 Additional information: None 1207 Magic Number: None 1209 File Extension: None 1211 Macintosh file type code: 'BINA' 1213 Person and email address for further information: Randall Gellens, 1214 rg+ietf@randy.pensive.org 1216 Intended usage: LIMITED USE 1218 Author: The MSD specification was produced by the European 1219 Committee For Standardization (CEN). For contact information, 1220 please see . 1222 Change controller: The European Committee For Standardization 1223 (CEN) 1225 15.3. MIME Content-type Registration for 'application/ 1226 emergencyCallData.eCall.control+xml' 1228 IANA is requested to add application/ 1229 emergencyCallData.eCall.control+xml as a MIME content type, with a 1230 reference to this document, in accordance to the procedures of RFC 1231 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1233 MIME media type name: application 1235 MIME subtype name: emergencyCallData.eCall.control+xml 1237 Mandatory parameters: none 1239 Optional parameters: charset 1240 Indicates the character encoding of the XML content. 1242 Encoding considerations: Uses XML, which can employ 8-bit 1243 characters, depending on the character encoding used. See 1244 Section 3.2 of RFC 7303 [RFC7303]. 1246 Security considerations: 1248 This content type carries metadata and control information and 1249 requests, such as from a Public Safety Answering Point (PSAP) 1250 to an In-Vehicle System (IVS) during an emergency call. 1252 Metadata (such as an acknowledgment that data sent by the IVS 1253 to the PSAP was successfully received) has limited privacy and 1254 security implications. Control information (such as requests 1255 from the PSAP that the vehicle perform an action) has some 1256 privacy and security implications. The privacy concern arises 1257 from the ability to request the vehicle to transmit a data set, 1258 which as described in Section 15.2, can contain personal 1259 information. The security concern is the ability to request 1260 the vehicle to perform an action. Control information needs to 1261 originate only from a PSAP or other emergency services 1262 provider, and not be modified en-route. The level of integrity 1263 of the cellular network over which the emergency call is placed 1264 is a consideration: when the IVS initiates an eCall over a 1265 cellular network, in most cases it relies on the MNO to route 1266 the call to a PSAP. (Calls placed using other means, such as 1267 Wi-Fi or over-the-top services, generally incur somewhat higher 1268 levels of risk than calls placed "natively" using cellular 1269 networks.) A call-back from a PSAP merits additional 1270 consideration, since current mechanisms are not ideal for 1271 verifying that such a call is indeed a call-back from a PSAP in 1272 response to an emergency call placed by the IVS. See the 1273 discussion in Section 12 and the PSAP Callback document 1274 [RFC7090]. 1276 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1277 contain more discussion. 1279 Interoperability considerations: None 1281 Published specification: This document 1283 Applications which use this media type: Pan-European eCall 1284 compliant systems 1286 Additional information: None 1287 Magic Number: None 1289 File Extension: .xml 1291 Macintosh file type code: 'TEXT' 1293 Person and email address for further information: Randall Gellens, 1294 rg+ietf@randy.pensive.org 1296 Intended usage: LIMITED USE 1298 Author: The IETF ECRIT WG. 1300 Change controller: The IETF ECRIT WG. 1302 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1303 Additional Data Blocks registry 1305 This specification requests IANA to add the 'eCall.MSD' entry to the 1306 Emergency Call Additional Data Blocks registry, with a reference to 1307 this document. 1309 15.5. Registration of the 'eCall.control' entry in the Emergency Call 1310 Additional Data Blocks registry 1312 This specification requests IANA to add the 'eCall.control' entry to 1313 the Emergency Call Additional Data Blocks registry, with a reference 1314 to this document. 1316 15.6. Registration of the emergencyCallData.eCall Info Package 1318 IANA is requested to add emergencyCallData.eCall to the Info Packages 1319 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1320 reference to this document. 1322 15.7. URN Sub-Namespace Registration 1324 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1326 This section registers a new XML namespace, as per the guidelines in 1327 RFC 3688 [RFC3688]. 1329 URI: urn:ietf:params:xml:ns:eCall 1331 Registrant Contact: IETF, ECRIT working group, , as 1332 delegated by the IESG . 1334 XML: 1336 BEGIN 1337 1338 1340 1341 1342 1344 Namespace for eCall Data 1345 1346 1347

Namespace for eCall Data

1348

See [TBD: This document].

1349 1350 1351 END 1353 15.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1355 This section registers a new XML namespace, as per the guidelines in 1356 RFC 3688 [RFC3688]. 1358 URI: urn:ietf:params:xml:ns:eCall:control 1360 Registrant Contact: IETF, ECRIT working group, , as 1361 delegated by the IESG . 1363 XML: 1365 BEGIN 1366 1367 1369 1370 1371 1373 Namespace for eCall Data: 1374 Control Block 1375 1376 1377

Namespace for eCall Data

1378

Control Block

1379

See [TBD: This document].

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