idnits 2.17.00 (12 Aug 2021) /tmp/idnits62181/draft-ietf-ecrit-ecall-24.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2017) is 1947 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: July 23, 2017 Individual 6 January 19, 2017 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-24.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 MIME media types and an Emergency Call 22 Additional Data Block for the eCall vehicle data and metadata/control 23 data, and an INFO package to enable carrying this data in SIP INFO 24 requests. 26 Although this specification is designed to meet the requirements of 27 European next-generation eCall, it is specified generically such that 28 the technology can be re-used or extended to suit requirements across 29 jurisdictions. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 23, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 7 69 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 11 74 9.1. The Control Block . . . . . . . . . . . . . . . . . . . . 13 75 9.1.1. The element . . . . . . . . . . . . . . . . . . 13 76 9.1.1.1. Attributes of the element . . . . . . . . . 14 77 9.1.1.2. Child Element of the element . . . . . . . 14 78 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 15 79 9.1.2. The element . . . . . . . . . . . . . 15 80 9.1.2.1. Child Element of the element . . . 15 81 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16 82 9.1.3. The element . . . . . . . . . . . . . . . . 16 83 9.1.3.1. Attributes of the element . . . . . . . 17 84 9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 18 85 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 87 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 88 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 90 14.1. The EmergencyCallData Media Subtree . . . . . . . . . . 28 91 14.2. Service URN Registrations . . . . . . . . . . . . . . . 29 92 14.3. MIME Structured Syntax Suffix Registration for +PER . . 29 93 14.4. MIME Media Type Registration for 94 'application/emergencyCallData.eCall.MSD+per' . . . . . 31 95 14.5. MIME Media Type Registration for 96 'application/emergencyCallData.control+xml' . . . . . . 32 97 14.6. Registration of the 'eCall.MSD' entry in the Emergency 98 Call Additional Data Types registry . . . . . . . . . . 33 99 14.7. Registration of the 'control' entry in the Emergency 100 Call Additional Data Types registry . . . . . . . . . . 34 101 14.8. URN Sub-Namespace Registration . . . . . . . . . . . . . 34 102 14.8.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34 103 14.8.2. Registration for 104 urn:ietf:params:xml:ns:EmergencyCallData:control . . 34 105 14.9. Registry Creation . . . . . . . . . . . . . . . . . . . 35 106 14.9.1. Emergency Call Action Registry . . . . . . . . . . . 35 107 14.9.2. Emergency Call Action Failure Reason Registry . . . 36 108 14.10. The emergencyCallData.eCall.MSD INFO package . . . . . . 37 109 14.10.1. Overall Description . . . . . . . . . . . . . . . . 37 110 14.10.2. Applicability . . . . . . . . . . . . . . . . . . . 38 111 14.10.3. Info Package Name . . . . . . . . . . . . . . . . . 38 112 14.10.4. Info Package Parameters . . . . . . . . . . . . . . 38 113 14.10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 39 114 14.10.6. INFO Request Body Parts . . . . . . . . . . . . . . 39 115 14.10.7. Info Package Usage Restrictions . . . . . . . . . . 39 116 14.10.8. Rate of INFO Requests . . . . . . . . . . . . . . . 39 117 14.10.9. Info Package Security Considerations . . . . . . . 40 118 14.10.10. Implementation Details . . . . . . . . . . . . . . 40 119 14.10.11. Examples . . . . . . . . . . . . . . . . . . . . . 40 120 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 121 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 122 17. Changes from Previous Versions . . . . . . . . . . . . . . . 40 123 17.1. Changes from draft-ietf-19 to draft-ietf-20 . . . . . . 40 124 17.2. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 41 125 17.3. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 41 126 17.4. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 41 127 17.5. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 41 128 17.6. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 41 129 17.7. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 41 130 17.8. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 41 131 17.9. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 42 132 17.10. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 42 133 17.11. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 42 134 17.12. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 42 135 17.13. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 43 136 17.14. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 43 137 17.15. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 43 138 17.16. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 43 139 17.17. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 43 140 17.18. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 44 141 17.19. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 44 142 17.20. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 44 143 17.21. Changes from draft-gellens-02 to -03 . . . . . . . . . . 44 144 17.22. Changes from draft-gellens-01 to -02 . . . . . . . . . . 45 145 17.23. Changes from draft-gellens-00 to -01 . . . . . . . . . . 45 146 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 147 18.1. Normative References . . . . . . . . . . . . . . . . . . 45 148 18.2. Informative references . . . . . . . . . . . . . . . . . 46 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 151 1. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 This document re-uses terminology defined in Section 3 of [RFC5012]. 159 Additionally, we use the following abbreviations: 161 +--------+----------------------------------------+ 162 | Term | Expansion | 163 +--------+----------------------------------------+ 164 | 3GPP | 3rd Generation Partnership Project | 165 | | | 166 | CEN | European Committee for Standardization | 167 | | | 168 | EENA | European Emergency Number Association | 169 | | | 170 | ESInet | Emergency Services IP network | 171 | | | 172 | IMS | IP Multimedia Subsystem | 173 | | | 174 | IVS | In-Vehicle System | 175 | | | 176 | MNO | Mobile Network Operator | 177 | | | 178 | MSD | Minimum Set of Data | 179 | | | 180 | PSAP | Public Safety Answering Point | 181 +--------+----------------------------------------+ 183 2. Document Scope 185 This document is focused on the signaling, data exchange, and 186 protocol needs of next-generation eCall (NG-eCall, also referred to 187 as packet-switched eCall or all-IP eCall) within the SIP framework 188 for emergency calls (as described in [RFC6443] and [RFC6881]). eCall 189 itself is specified by 3GPP (3rd Generation Partnership Project) and 190 CEN (European Committee for Standardization) and these specifications 191 include far greater scope than is covered here. 193 The eCall service operates over cellular wireless communication, but 194 this document does not address cellular-specific details, nor client 195 domain selection (e.g., circuit-switched versus packet-switched). 196 All such aspects are the purview of their respective standards 197 bodies. The scope of this document is limited to eCall operating 198 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling 199 [TS23.167]). 201 Although this specification is designed to meet the requirements of 202 pan-European next-generation eCall, it is specified generically such 203 that the technology can be re-used or extended to suit requirements 204 across jurisdictions (see, e.g., [I-D.ietf-ecrit-car-crash]), and 205 extension points are provided to facilitate this. 207 Note that vehicles designed for multiple regions might need to 208 support eCall and other Advanced Automatic Crash Notification (AACN) 209 systems (such as described in [I-D.ietf-ecrit-car-crash]), but this 210 is out of scope of this document. 212 3. Introduction 214 Emergency calls made from vehicles (e.g., in the event of a crash) 215 assist in significantly reducing road deaths and injuries by allowing 216 emergency services to be aware of the incident, the state of the 217 vehicle, the location of the vehicle, and to have a voice channel 218 with the vehicle occupants. This enables a quick and appropriate 219 response. 221 The European Commission initiative of eCall was conceived in the late 222 1990s, and has evolved to a European Parliament decision requiring 223 the implementation of a compliant in-vehicle system (IVS) in new 224 vehicles and the deployment of eCall in the European Member States in 225 the very near future. Other regions are developing eCall-compatible 226 systems. 228 The pan-European eCall system is a standardized and mandated 229 mechanism for emergency calls by vehicles, providing a voice channel 230 and transmission of data. eCall establishes procedures for such 231 calls to be placed by in-vehicle systems, recognized and processed by 232 the mobile network, and routed to a specialized PSAP where the 233 vehicle data is available to assist the call taker in assessing and 234 responding to the situation. eCall provides a standard set of 235 vehicle, sensor (e.g., crash related), and location data. 237 An eCall can be either user-initiated or automatically triggered. 238 Automatically triggered eCalls indicate a car crash or some other 239 serious incident. Manually triggered eCalls might be reports of 240 witnessed crashes or serious hazards. PSAPs might apply specific 241 operational handling to manual and automatic eCalls. 243 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 244 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 245 call setup mark the call as an eCall, and further indicate if the 246 call was automatically or manually triggered. The call is routed to 247 an eCall-capable PSAP, a voice channel is established between the 248 vehicle and the PSAP, and an eCall in-band modem is used to carry a 249 defined set of vehicle, sensor (e.g., crash related), and location 250 data (the Minimum Set of Data or MSD) within the voice channel. The 251 same in-band mechanism is used for the PSAP to acknowledge successful 252 receipt of the MSD, and to request the vehicle to send a new MSD 253 (e.g., to check if the state of or location of the vehicle or its 254 occupants has changed). NG-eCall moves from circuit switched to all- 255 IP, and carries the vehicle data and eCall signaling as additional 256 data carried with the call. This document describes how IETF 257 mechanisms for IP-based emergency calls (including [RFC6443] and 258 [RFC7852]) are used to provide the signaling and data exchange of the 259 next generation of pan-European eCall. 261 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 262 has published a Technical Report titled "Mobile Standards Group 263 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 264 recommendations regarding support for eCall in an all-IP environment. 265 The recommendations include the use of 3GPP IMS emergency calling 266 with additional elements identifying the call as an eCall and as 267 carrying eCall data and with mechanisms for carrying the data and 268 eCall signaling. 3GPP IMS emergency services support multimedia, 269 providing the ability to carry voice, text, and video. This 270 capability is referred to within 3GPP as Multimedia Emergency 271 Services (MMES). 273 A transition period will exist during which time the various entities 274 involved in initiating and handling an eCall might support next- 275 generation eCall, legacy eCall, or both. The issues of migration and 276 co-existence during the transition period are outside the scope of 277 this document. 279 This document indicates how to use IP-based emergency services 280 mechanisms to support next-generation eCall. 282 This document also registers MIME media types and an Emergency Call 283 Additional Data Block for the eCall vehicle data (MSD) and metadata/ 284 control data, and an INFO package to enable carrying this data in SIP 285 INFO requests. 287 The MSD is carried in the MIME type 'application/ 288 emergencyCallData.eCall.MSD+per' and the metadata/control block is 289 carried in the MIME type 'application/emergencyCallData.control+xml' 290 (both of which are registered in Section 14). An INFO package is 291 defined (in Section 14.10) to enable these MIME types to be carried 292 in SIP INFO requests, per [RFC6086]. 294 4. eCall Requirements 296 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 297 [TS22.101] clauses 10.7 and A.27 and [TS24.229] section 4.7.6. 298 Requirements specific to vehicle data are contained in EN 15722 299 [msd]. 301 5. Vehicle Data 303 Pan-European eCall provides a standardized and mandated set of 304 vehicle related data (including VIN, vehicle type, propulsion type, 305 current and optionally previous location coordinates, and number of 306 occupants), known as the Minimum Set of Data (MSD). The European 307 Committee for Standardization (CEN) has specified this data in EN 308 15722 [msd], along with both ASN.1 and XML encodings. Both circuit- 309 switched eCall and this document use the ASN.1 PER encoding, which is 310 specified in Annex A of EN 15722 [msd] (the XML encoding specified in 311 Annex C is not used in this document, per 3GPP [SDO-3GPP]). 313 This document registers the 'application/ 314 emergencyCallData.eCall.MSD+per' MIME media type to enable the MSD to 315 be carried in SIP. As an ASN.1 PER encoded object, the data is 316 binary and transported using binary content transfer encoding within 317 SIP messages. This document also adds the 'eCall.MSD' entry to the 318 Emergency Call Additional Data Types registry to enable the MSD to be 319 recognized as such in a SIP-based eCall emergency call. (See 320 [RFC7852] for more information about the registry and how it is 321 used.) 323 See Section 6 for a discussion of how the MSD vehicle data is 324 conveyed in an NG-eCall. 326 6. Data Transport 328 [RFC7852] establishes a general mechanism for conveying blocks of 329 data within a SIP emergency call. This document makes use of that 330 mechanism to include vehicle data (the MSD, see Section 5) and/or 331 metadata/control information (see Section 9) within SIP messages. 332 This document also registers an INFO package (in Section 14.10) to 333 enable eCall related data blocks to be carried in SIP INFO requests 334 (per [RFC6086], new INFO usages require the definition of an INFO 335 package). 337 Note that if other data sets need to be transmitted in the future, 338 the appropriate signalling mechanism for such data needs to be 339 evaluated, including factors such as the size and frequency of such 340 data. 342 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 343 encoding it per Annex A of EN 15722 [msd], and including it as a MIME 344 body part within a SIP message per [RFC7852]. The body part is 345 identified by its MIME media type ('application/ 346 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 347 the body part. The body part is assigned a unique identifier which 348 is listed in a Content-ID header field in the body part. The SIP 349 message is marked as containing the MSD by adding (or appending to) a 350 Call-Info header field at the top level of the SIP message. This 351 Call-Info header field contains a CID URL referencing the body part's 352 unique identifier, and a 'purpose' parameter identifying the data as 353 the eCall MSD per the Emergency Call Additional Data Types registry 354 entry; the 'purpose' parameter's value is 355 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 356 SIP INFO request by using the INFO package defined in Section 14.10. 358 A PSAP or IVS transmits a metadata/control object (see Section 9) by 359 encoding it per the description in this document, and including it 360 within a SIP message as a MIME body part per [RFC7852]. The body 361 part is identified by its MIME media type ('application/ 362 emergencyCallData.control+xml') in the Content-Type header field of 363 the body part. The body part is assigned a unique identifier which 364 is listed in a Content-ID header field in the body part. The SIP 365 message is marked as containing the metadata/control object by adding 366 (or appending to) a Call-Info header field at the top level of the 367 SIP message. This Call-Info header field contains a CID URL 368 referencing the body part's unique identifier, and a 'purpose' 369 parameter identifying the data as an eCall metadata/control block per 370 the Emergency Call Additional Data Types registry entry; the 371 'purpose' parameter's value is 'emergencyCallData.control'. Per 372 [RFC6086], a metadata/control object is carried in a SIP INFO request 373 by using the INFO package defined in Section 14.10. 375 An MSD or a metadata/control block is always enclosed in a multipart 376 (normally multipart/mixed) body part (even if it would otherwise be 377 the only body part in the SIP message), since as of the date of this 378 document, the use of Content-ID as a SIP header field is not defined 379 (while it is defined for use as a MIME header field). 381 A body part containing an MSD or metadata/control object has a 382 Content-Disposition header field value containing "By-Reference". 384 An In-Vehicle System (IVS) initiating an NG-eCall includes an MSD as 385 a body part within the initial INVITE, and optionally also includes a 386 metadata/control object informing the PSAP of its capabilities as 387 another body part. The MSD body part (and metadata/control and PIDF- 388 LO body parts if included) have a Content-Disposition header field 389 with the value "By-Reference; handling=optional". Specifying 390 "handling=optional" prevents the SIP INVITE request from being 391 rejected if it is processed by a legacy element (e.g., a gateway 392 between SIP and circuit-switched environments) that does not 393 understand the MSD (or metadata/control object or PIDF-LO). The PSAP 394 creates a metadata/control object acknowledging receipt of the MSD 395 and includes it as a body part within the SIP final response to the 396 SIP INVITE request per [RFC7852]. A metadata/control object is not 397 included in provisional (e.g., 180) responses. 399 A PSAP is able to reject a call while indicating that it is aware of 400 the situation by including a metadata/control object acknowledging 401 the MSD and containing "received=true" within a final response using 402 SIP response code 600 (Busy Everywhere), 486 (Busy Here), or 603 403 (Decline), per [RFC7852]. 405 If the IVS receives an acknowledgment for an MSD containing 406 "received=false", this indicates that the PSAP was unable to properly 407 decode or process the MSD. The IVS action is not defined (e.g., it 408 might only log an error). Since the PSAP is able to request an 409 updated MSD during the call, if an initial MSD is unsatisfactory in 410 any way, the PSAP can choose to request another one. 412 A PSAP can request that the vehicle send an updated MSD during a call 413 (e.g., upon manual request of the PSAP call taker who suspects 414 vehicle state may have changed.) To do so, the PSAP creates a 415 metadata/control object requesting an MSD and includes it within a 416 SIP INFO request sent within the dialog. The IVS then includes an 417 updated MSD within a SIP INFO request and sends it within the dialog. 418 If the IVS is unable to send an MSD, it instead sends a metadata/ 419 control object acknowledging the request with the 'success' parameter 420 set to 'false' and a 'reason' parameter (and optionally a 'details' 421 parameter) indicating why the request could not be accomplished. Per 422 [RFC6086], metadata/control objects and MSDs are sent using the INFO 423 package defined in Section 14.10. In addition, to align with how an 424 MSD or metadata/control block is transmitted in a SIP message other 425 than an INFO request, a Call-Info header field is included in the SIP 426 INFO request to reference the MSD or metadata/control block per 427 [RFC7852]. See Section 14.10 for information about the use of SIP 428 INFO requests to carry data within an eCall. 430 The IVS is not expected to send an unsolicited MSD after the initial 431 INVITE. 433 This document does not mandate support for the data blocks defined in 434 [RFC7852]. 436 7. Call Setup 438 In circuit-switched eCall, the IVS places a special form of a 112 439 emergency call which carries an eCall flag (indicating that the call 440 is an eCall and also if the call was manually or automatically 441 triggered); the mobile network operator (MNO) recognizes the eCall 442 flag and routes the call to an eCall-capable PSAP; vehicle data is 443 transmitted to the PSAP via the eCall in-band modem (in the voice 444 channel). 446 ///----\\\ 112 voice call with eCall flag +------+ 447 ||| IVS |||---------------------------------------->+ PSAP | 448 \\\----/// vehicle data via eCall in-band modem +------+ 450 Figure 1: circuit-switched eCall 452 For NG-eCall, the IVS establishes an emergency call using a Request- 453 URI indicating a manual or automatic eCall; the MNO (or ESInet) 454 recognizes the eCall URN and routes the call to an NG-eCall capable 455 PSAP; the PSAP interprets the vehicle data sent with the call and 456 makes it available to the call taker. 458 ///----\\\ IMS emergency call with eCall URN +------+ 459 IVS ----------------------------------------->+ PSAP | 460 \\\----/// vehicle data included in call setup +------+ 462 Figure 2: NG-eCall 464 See Section 6 for information on how the MSD is transported within an 465 NG-eCall. 467 This document adds new service URN children within the "sos" 468 subservice. These URNs provide the mechanism by which an eCall is 469 identified, and differentiate between manually and automatically 470 triggered eCalls (which might be subject to different treatment, 471 depending on policy). The two service URNs are: 472 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 473 which requests resources associated with an emergency call placed by 474 an in-vehicle system, carrying a standardized set of data related to 475 the vehicle and incident. These are registered in Section 14.2 476 Call routing is outside the scope of this document. 478 8. Test Calls 480 eCall requires the ability to place test calls (see [TS22.101] clause 481 10.7 and [EN_16062] clause 7.2.2). These are calls that are 482 recognized and treated to some extent as eCalls but are not given 483 emergency call treatment and are not handled by call takers. The 484 specific handling of test eCalls is not itself standardized; 485 typically, the test call facility allows the IVS or user to verify 486 that an eCall can be successfully established with voice 487 communication. The IVS might also be able to verify that the MSD was 488 successfully received. 490 A service URN starting with "test." indicates a test call. For 491 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 492 This functionality is defined in [RFC6881]. 494 This document specifies "urn:service:test.sos.ecall" for eCall test 495 calls. This is registered in Section 14.2 497 The circuit switched eCall test call facility is a non-emergency 498 number so does not get treated as an emergency call. For NG-eCall, 499 MNOs, emergency authorities, and PSAPs can determine how to treat a 500 vehicle call requesting the "test" service URN so that the desired 501 functionality is tested, but this is outside the scope of this 502 document. 504 9. The Metadata/Control Object 506 eCall requires the ability for the PSAP to acknowledge successful 507 receipt of an MSD sent by the IVS, and for the PSAP to request that 508 the IVS send an MSD (e.g., the call taker can initiate a request for 509 a new MSD to see if there have been changes in the vehicle's state, 510 e.g., location, direction, number of fastened seatbelts). 512 This document defines a block of metadata/control data as an XML 513 structure containing elements used for eCall and other related 514 emergency call systems and extension points. (This metadata/control 515 block is in effect a high-level protocol between the PSAP and IVS.) 516 When the PSAP sends a metadata/control block in response to data sent 517 by the IVS in a SIP request other than INFO (e.g., the MSD in the 518 initial INVITE), the metadata/control block is sent in the SIP 519 response to that request (e.g., the response to the INVITE request). 520 When the PSAP sends a control block in other circumstances (e.g., 521 mid-call), the control block is transmitted from the PSAP to the IVS 522 in a SIP INFO request within the established dialog. The IVS sends 523 the requested data (the MSD) in a new SIP INFO request (per 525 [RFC6086]). This mechanism flexibly allows the PSAP to send eCall- 526 specific data to the IVS and the IVS to respond. SIP INFO requests 527 are sent using an appropriate SIP INFO Package. See Section 6 for 528 more information on sending a metadata/control block within a SIP 529 message. See Section 14.10 for information about the use of SIP INFO 530 requests to carry data within an eCall. 532 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 533 initial INVITE), the PSAP sends a metadata/control block indicating 534 successful/unsuccessful receipt of the MSD in the SIP response to the 535 request. This also informs the IVS that an NG-eCall is in operation. 536 If the IVS receives a SIP final response without the metadata/control 537 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 538 some part of the call is being handled as a legacy call). When the 539 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 540 receipt of a SIP INFO request containing a metadata/control block 541 requesting an MSD), the PSAP does not send a metadata/control block 542 indicating successful or unsuccessful receipt of the MSD. (Normal 543 SIP retransmission handles non-receipt of requested data; note that, 544 per [RFC6086], a 200 OK response to a SIP INFO request indicates only 545 that the receiver has successfully received and accepted the SIP INFO 546 request, it says nothing about the acceptability of the payload.) If 547 the IVS receives a request to send an MSD but it is unable to do so 548 for any reason, the IVS sends a metadata/control object acknowledging 549 the request and containing "success=false" and "reason" set to an 550 appropriate code. 552 This provides flexibility to handle various circumstances. For 553 example, if a PSAP is unable to accept an eCall (e.g., due to 554 overload or too many calls from the same location), it can reject the 555 INVITE. Since a metadata/control object is also included in the SIP 556 response that rejects the call, the IVS knows if the PSAP received 557 the MSD, and can inform the vehicle occupants that the PSAP 558 successfully received the vehicle location and information but can't 559 talk to the occupants at that time. Especially for SIP response 560 codes that indicate an inability to conduct a call (as opposed to a 561 technical inability to process the request), the IVS can also 562 determine that the call was successful on a technical level (e.g., 563 not helpful to retry as circuit-switched). (Note that there could be 564 edge cases where the PSAP response is not received by the IVS, e.g., 565 if an intermediary sends a CANCEL, and an error response is forwarded 566 towards the IVS before the error response from the PSAP is received, 567 the response will be dropped, but these are unlikely to occur here.) 569 The metadata/control block is carried in the MIME type 'application/ 570 emergencyCallData.control+xml'. 572 The metadata/control block is designed for use with pan-European 573 eCall and also eCall-like systems (i.e., in other regions), and has 574 extension points. Note that eCall-like systems might define their 575 own vehicle data blocks, and so might need to register a new INFO 576 package to accommodate the new data MIME media type and the metadata/ 577 control object. 579 9.1. The Control Block 581 The control block is an XML data structure allowing for 582 acknowledgments, requests, and capabilities information. It is 583 carried in a body part with a specific MIME media type. Three 584 elements are defined for use within a control block: 586 ack Acknowledges receipt of data or a request. 588 capabilities Used in a control block sent from the IVS to the PSAP 589 (e.g., in the initial INVITE) to inform the PSAP of the 590 vehicle capabilities. Child elements contain all 591 actions and data types supported by the vehicle. It is 592 OPTIONAL for the IVS to send this block. Omitting the 593 block indicates that the IVS supports only the 594 mandatory functionality defined in this document. 596 request Used in a control block sent by the PSAP to the IVS, to 597 request the vehicle to perform an action. 599 The element indicates the object being acknowledged and reports 600 success or failure. 602 The element contains attributes to indicate the request and 603 to supply related information. The 'action' attribute is mandatory 604 and indicates the specific action. An IANA registry is created in 605 Section 14.9.1 to contain the allowed values. 607 The element has child elements to indicate 608 the actions supported by the IVS. 610 9.1.1. The element 612 The element acknowledges receipt of an eCall data object or 613 request. An element references the Content-ID of the object 614 being acknowledged. The PSAP MUST send an element 615 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 616 the INVITE); this element indicates if the PSAP considers the 617 MSD successfully received or not. An element is not sent for a 618 element. 620 The element has the following attributes: 622 9.1.1.1. Attributes of the element 624 The element has the following attributes: 626 Name: ref 627 Usage: Mandatory 628 Type: anyURI 629 Direction: Sent in either direction 630 Description: References the Content-ID of the body part being 631 acknowledged. 632 Example: 634 Name: received 635 Usage: Conditional: mandatory in an element sent by a PSAP 636 Type: Boolean 637 Direction: In this document, sent from the PSAP to the IVS 638 Description: Indicates if the referenced object was considered 639 successfully received or not. 640 Example: 642 9.1.1.2. Child Element of the element 644 For extensibility, the element has the following child element: 646 Name: actionResult 647 Usage: Optional 648 Direction: Sent from the IVS to the PSAP 649 Description: An element indicates the result of an 650 action (other than a successfully executed 'send-data' action). 651 The element contains an element for each 652 element that is not a successfully executed 'send-data' 653 action. The element has the following attributes: 655 Name: action 656 Usage: Mandatory 657 Type: token 658 Description: Contains the value of the 'action' attribute of the 659 element 661 Name: success 662 Usage: Mandatory 663 Type: Boolean 664 Description: Indicates if the action was successfully 665 accomplished 667 Name: reason 668 Usage: Conditional 669 Type: token 670 Description: Used when 'success' is "false", this attribute 671 contains a reason code for a failure. A registry for reason 672 codes is defined in Section 14.9.2. The initial values are: 673 damaged (required components are damaged), data-unsupported 674 (the data item referenced in a 'send-data' request is not 675 supported), security-failure (the authenticity of the request 676 or the authority of the requestor could not be verified), 677 unable (a generic error for use when no other code is 678 appropriate), and unsupported (the 'action' value is not 679 supported). 681 Name: details 682 Usage: optional 683 Type: string 684 Description: Contains further explanation of the circumstances of 685 a success or failure. The contents are implementation-specific 686 and human-readable. This is intended for internal use and 687 troubleshooting, not for display to vehicle occupants. 689 9.1.1.3. Ack Examples 691 692 696 698 700 Figure 3: Ack Example from PSAP to IVS 702 9.1.2. The element 704 The element is transmitted by the IVS to indicate to 705 the PSAP its capabilities. No attributes for this element are 706 currently defined. The following child elements are defined: 708 9.1.2.1. Child Element of the element 710 The element has the following child element: 712 Name: request 713 Usage: Mandatory 714 Description: The element contains a child 715 element per action supported by the vehicle. 717 Example: 719 721 723 725 It is OPTIONAL for the IVS to support the element. If 726 the IVS does not send a element, this indicates that 727 the only action supported by the IVS is 'send-data' with 728 'datatype' set to 'eCall.MSD'. 730 9.1.2.2. Capabilities Example 732 733 736 737 738 740 742 Figure 4: Capabilities Example 744 9.1.3. The element 746 A element appears one or more times on its own or as a 747 child of a element. It allows the PSAP to request 748 that the IVS perform an action. The only action that MUST be 749 supported is to send an MSD. The following attributes and child 750 elements are defined: 752 9.1.3.1. Attributes of the element 754 The element has the following attributes: 756 Name: action 757 Usage: Mandatory 758 Type: token 759 Direction: Sent in either direction 760 Description: Identifies the action that the vehicle is requested to 761 perform (in a element within a element, 762 indicates an action that the vehicle is capable of performing). 763 An IANA registry is established in Section 14.9.1 to contain the 764 allowed values. 765 Example: action="send-data" 767 Name: int-id 768 Usage: Conditional 769 Type: int 770 Direction: Sent in either direction 771 Description: Defined for extensibility. Documents that make use of 772 it are expected to explain when it is required and how it is used. 773 Example: int-id="3" 775 Name: persistence 776 Usage: Optional 777 Type: xs:duration 778 Direction: Sent in either direction 779 Description: Defined for extensibility. Specifies how long to carry 780 on the specified action. If absent, the default is for the 781 duration of the call. 782 Example: persistence="PT1H" 784 Name: datatype 785 Usage: Conditional 786 Type: token 787 Direction: Sent in either direction 788 Description: Mandatory with a "send-data" action within a 789 element that is not within a element. Specifies 790 the data block that the IVS is requested to transmit, using the 791 same identifier as in the 'purpose' attribute set in a Call-Info 792 header field to point to the data block. Permitted values are 793 contained in the 'Emergency Call Data Types' IANA registry 794 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 795 to support. 796 Example: datatype="eCall.MSD" 798 Name: supported-values 799 Usage: Conditional 800 Type: string 801 Direction: Sent from the IVS to the PSAP 802 Description: Defined for extensibility. Used in a element 803 that is a child of a element, this attribute lists 804 all supported values of the action type. Permitted values depend 805 on the action value. Multiple values are separated with a 806 semicolon. White space is ignored. Documents that make use of it 807 are expected to explain when it is required, the permitted values, 808 and how it is used. 810 Name: requested-state 811 Usage: Conditional 812 Type: token 813 Direction: Sent from the PSAP to the IVS 814 Description: Defined for extension. Indicates the requested state 815 of an element associated with the request type. Permitted values 816 depend on the request type. Documents that make use of it are 817 expected to explain when it is required, the permitted values, and 818 how it is used. 820 Name: element-id 821 Usage: Conditional 822 Type: token 823 Direction: Sent from the PSAP to the IVS 824 Description: Defined for extension. Identifies the element to be 825 acted on. Permitted values depend on the request type. Documents 826 that make use of it are expected to explain when it is required, 827 the permitted values, and how it is used. 829 9.1.3.2. Request Example 831 832 835 837 839 Figure 5: Request Example 841 10. Examples 843 Figure 6 illustrates an eCall. The call uses the request URI 844 'urn:service:sos.ecall.automatic' service URN and is recognized as an 845 eCall, and further as one that was invoked automatically by the IVS 846 due to a crash or other serious incident. In this example, the 847 originating network routes the call to an ESInet which routes the 848 call to the appropriate NG-eCall capable PSAP. The emergency call is 849 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 850 the entry point into the ESInet. The ESRP routes the call to a PSAP, 851 where it is received by a call taker. In deployments where there is 852 no ESInet, the originating network routes the call directly to the 853 appropriate NG-eCall capable PSAP, an illustration of which would be 854 identical to the one below except without an ESInet or ESRP. 856 +------------+ +---------------------------------------+ 857 | | | +-------+ | 858 | | | | PSAP2 | | 859 | | | +-------+ | 860 | | | | 861 | | | +------+ +-------+ | 862 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 863 | | | +------+ +-------+ | 864 | | | | 865 | | | +-------+ | 866 | | | | PSAP3 | | 867 | Originating| | +-------+ | 868 | Mobile | | | 869 | Network | | ESInet | 870 +------------+ +---------------------------------------+ 872 Figure 6: Example of NG-eCall Message Flow 874 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 875 for an updated MSD. The call flow shows the IVS initiating an 876 emergency call, including the MSD in the INVITE. The PSAP includes 877 in the 200 OK response a metadata/control object acknowledging 878 receipt of the MSD. During the call, the PSAP sends a request for an 879 MSD in an INFO request. The IVS sends the requested MSD in a new 880 INFO request. 882 IVS PSAP 883 |(1) INVITE (eCall MSD) | 884 |------------------------------------------->| 885 | | 886 |(2) 200 OK (eCall metadata [ack MSD]) | 887 |<-------------------------------------------| 888 | | 889 |(3) start media stream(s) | 890 |............................................| 891 | | 892 |(4) INFO (eCall metadata [request MSD]) | 893 |<-------------------------------------------| 894 | | 895 |(5) 200 OK | 896 |------------------------------------------->| 897 | | 898 |(6) INFO (eCall MSD) | 899 |------------------------------------------->| 900 | | 901 |(7) 200 OK | 902 |<-------------------------------------------| 903 | | 904 |(8) BYE | 905 |<-------------------------------------------| 906 | | 907 |(9) end media streams | 908 |............................................| 909 | | 910 |(10) 200 OK | 911 |------------------------------------------->| 913 Figure 7: NG-eCall Call Flow Illustration 915 The example, shown in Figure 8, illustrates a SIP eCall INVITE 916 request containing an MSD. For simplicity, the example does not show 917 all SIP headers, nor the SDP contents, nor does it show any 918 additional data blocks added by the IVS or the originating mobile 919 network. Because the MSD is encoded in ASN.1 PER, which is a binary 920 encoding, its contents cannot be included in a text document. 922 INVITE urn:service:sos.ecall.automatic SIP/2.0 923 To: urn:service:sos.ecall.automatic 924 From: ;tag=9fxced76sl 925 Call-ID: 3848276298220188511@atlanta.example.com 926 Geolocation: 927 Geolocation-Routing: no 928 Call-Info: ; 929 purpose=emergencyCallData.eCall.MSD 930 Accept: application/sdp, application/pidf+xml, 931 application/emergencyCallData.control+xml 932 CSeq: 31862 INVITE 933 Recv-Info: emergencyCallData.eCall.MSD 934 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 935 SUBSCRIBE, NOTIFY, UPDATE 936 Content-Type: multipart/mixed; boundary=boundary1 937 Content-Length: ... 939 --boundary1 940 Content-Type: application/sdp 942 ...Session Description Protocol (SDP) goes here... 944 --boundary1 945 Content-Type: application/pidf+xml 946 Content-ID: 947 Content-Disposition: by-reference;handling=optional 949 ...PIDF-LO goes in here 951 --boundary1 952 Content-Type: application/emergencyCallData.eCall.MSD+per 953 Content-ID: <1234567890@atlanta.example.com> 954 Content-Disposition: by-reference;handling=optional 956 ...MSD in ASN.1 PER encoding goes here... 958 --boundary1-- 960 Figure 8: SIP NG-eCall INVITE 962 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 963 the INVITE request of Figure 8, containing a control block 964 acknowledging successful receipt of the eCall MSD. (For simplicity, 965 the example does not show all SIP headers.) 966 SIP/2.0 200 OK 967 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 968 From: ;tag=9fxced76sl 969 Call-ID: 3848276298220188511@atlanta.example.com 970 Call-Info: ; 971 purpose=emergencyCallData.control 972 Accept: application/sdp, application/pidf+xml, 973 application/emergencyCallData.control+xml, 974 application/emergencyCallData.eCall.MSD+per 975 CSeq: 31862 INVITE 976 Recv-Info: emergencyCallData.eCall.MSD 977 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 978 SUBSCRIBE, NOTIFY, UPDATE 979 Content-Type: multipart/mixed; boundary=boundaryX 980 Content-Length: ... 982 --boundaryX 983 Content-Type: application/sdp 985 ...Session Description Protocol (SDP) goes here... 987 --boundaryX 988 Content-Type: application/emergencyCallData.control+xml 989 Content-ID: <2345678901@atlanta.example.com> 990 Content-Disposition: by-reference 992 993 996 997 999 --boundaryX-- 1001 Figure 9: 200 OK response to INVITE 1003 Figure 10 illustrates a SIP INFO request containing a metadata/ 1004 control block requesting an eCall MSD. (For simplicity, the example 1005 does not show all SIP headers.) 1006 INFO sip:+13145551111@example.com SIP/2.0 1007 To: ;tag=9fxced76sl 1008 From: Exemplar PSAP ;tag=8gydfe65t0 1009 Call-ID: 3848276298220188511@atlanta.example.com 1010 Call-Info: ; 1011 purpose=emergencyCallData.control 1012 CSeq: 41862 INFO 1013 Info-Package: emergencyCallData.eCall.MSD 1014 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1015 SUBSCRIBE, NOTIFY, UPDATE 1016 Content-Type: multipart/mixed; boundary=boundaryZZZ 1017 Content-Disposition: Info-Package 1018 Content-Length: ... 1020 --boundaryZZZ 1021 Content-Disposition: by-reference 1022 Content-Type: application/emergencyCallData.control+xml 1023 Content-ID: <3456789012@atlanta.example.com> 1025 1026 1029 1031 1032 --boundaryZZZ-- 1034 Figure 10: INFO requesting MSD 1036 Figure 11 illustrates a SIP INFO request containing an MSD. For 1037 simplicity, the example does not show all SIP headers. Because the 1038 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1039 cannot be included in a text document. 1041 INFO urn:service:sos.ecall.automatic SIP/2.0 1042 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1043 From: ;tag=9fxced76sl 1044 Call-ID: 3848276298220188511@atlanta.example.com 1045 Call-Info: ; 1046 purpose=emergencyCallData.eCall.MSD 1047 CSeq: 51862 INFO 1048 Info-Package: emergencyCallData.eCall.MSD 1049 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1050 SUBSCRIBE, NOTIFY, UPDATE 1051 Content-Type: multipart/mixed; boundary=boundaryLine 1052 Content-Disposition: Info-Package 1053 Content-Length: ... 1055 --boundaryLine 1056 Content-Type: application/emergencyCallData.eCall.MSD+per 1057 Content-ID: <4567890123@atlanta.example.com> 1058 Content-Disposition: by-reference 1060 ...MSD in ASN.1 PER encoding goes here... 1062 --boundaryLine-- 1064 Figure 11: INFO containing MSD 1066 11. Security Considerations 1068 The security considerations described in [RFC5069] (on marking and 1069 routing emergency calls) apply here. 1071 In addition to any network-provided location (which might be 1072 determined solely by the network, or in cooperation with or possibly 1073 entirely by the originating device), an eCall carries an IVS-supplied 1074 location within the MSD. This is likely to be useful to the PSAP, 1075 especially when no network-provided location is included, or when the 1076 two locations are independently determined. Even in situations where 1077 the network-supplied location is limited to the cell site, this can 1078 be useful as a sanity check on the device-supplied location contained 1079 in the MSD. 1081 The document [RFC7378] discusses trust issues regarding location 1082 provided by or determined in cooperation with end devices. 1084 Security considerations specific to the mechanism by which the PSAP 1085 sends acknowledgments and requests to the vehicle are discussed in 1086 the "Security Considerations" block of Section 14.5. Note that an 1087 attacker that has access to and is capable of generating a response 1088 to the initial INVITE request could generate a 600 (Busy Everywhere), 1089 486 (Busy Here), or 603 (Decline) response that includes a metadata/ 1090 control object containing a reference to the MSD in the initial 1091 INVITE and a "received=true" field, which could result in the IVS 1092 perceiving the PSAP to be overloaded and hence not attempting to 1093 reinitiate the call. The risk can be mitigated as discussed in the 1094 "Security Considerations" block of Section 14.5. 1096 Data received from external sources inherently carries implementation 1097 risks. For example, depending on the platform, buffer overflows can 1098 introduce remote code execution vulnerabilities, null characters can 1099 corrupt strings, numeric values used for internal calculations can 1100 result in underflow/overflow errors, malformed XML objects can expose 1101 parsing bugs, etc. Implementations need to be cognizant of the 1102 potential risks, observe best practices (which might include 1103 sufficiently capable static code analysis, fuzz testing, component 1104 isolation, avoiding use of unsafe coding techniques, third-party 1105 attack tests, signed software, over-the-air updates, etc.), and have 1106 multiple levels of protection. Implementors need to be aware that, 1107 potentially, the data objects described here and elsewhere (including 1108 the MSD and metadata/control objects) might be malformed, might 1109 contain unexpected characters, excessively long attribute values, 1110 elements, etc. 1112 The security considerations discussed in [RFC7852] apply here (see 1113 especially the discussion of TLS, TLS versions, cipher suites, and 1114 PKI). 1116 When vehicle data or control/metadata is contained in a signed or 1117 encrypted body part, the enclosing multipart (e.g., multipart/signed 1118 or multipart/encrypted) has the same Content-ID as the enclosed data 1119 part. This allows an entity to identify and access the data blocks 1120 it is interested in without having to dive deeply into the message 1121 structure or decrypt parts it is not interested in. (The 'purpose' 1122 parameter in a Call-Info header field identifies the data and 1123 contains a CID URL pointing to the data block in the body, which has 1124 a matching Content-ID body part header field). 1126 12. Privacy Considerations 1128 The privacy considerations discussed in [RFC7852] apply here. The 1129 MSD carries some identifying and personal information (mostly about 1130 the vehicle and less about the owner), as well as location 1131 information, and so needs to be protected against unauthorized 1132 disclosure. Local regulations may impose additional privacy 1133 protection requirements. 1135 Privacy considerations specific to the data structure containing 1136 vehicle information are discussed in the "Security Considerations" 1137 block of Section 14.4. 1139 Privacy considerations specific to the mechanism by which the PSAP 1140 sends acknowledgments and requests to the vehicle are discussed in 1141 the "Security Considerations" block of Section 14.5. 1143 13. XML Schema 1145 This section defines an XML schema for the control block. The text 1146 description of the control block in Section 9.1 is normative and 1147 supersedes any conflicting aspect of this schema. 1149 1150 1158 1160 1163 1164 1165 1166 1167 1169 1170 1171 1174 1175 1176 1177 1178 1180 1181 1182 1183 1184 1186 1187 1190 1193 1195 1196 1197 conditionally mandatory 1198 when @success="false" 1199 to indicate reason code 1200 for a failure 1201 1202 1203 1204 1206 1208 1209 1210 1213 1214 1217 1219 1220 1221 1222 1224 1225 1226 1227 1228 1232 1235 1236 1237 1238 1239 1241 1242 1243 1244 1245 1248 1249 1251 1252 1254 1255 1257 1258 1260 1261 1262 1263 1265 1267 Figure 12: Control Block Schema 1269 14. IANA Considerations 1271 14.1. The EmergencyCallData Media Subtree 1273 This document establishes the "EmergencyCallData" media (MIME) 1274 subtype tree, a new media subtree rooted at "application/ 1275 EmergencyCallData". This subtree is used only for content associated 1276 with emergency communications. New subtypes in this subtree follow 1277 the rules specified in Section 3.1 of [RFC6838], with the additional 1278 restriction that the standards-related organization MUST be 1279 responsible for some aspect of emergency communications. 1281 This subtree initially contains the following subtypes (defined here 1282 or in [RFC7852]): 1284 emergencyCallData.control+xml 1285 EmergencyCallData.Comment+xml 1286 EmergencyCallData.DeviceInfo+xml 1287 EmergencyCallData.MSD+per 1288 EmergencyCallData.ProviderInfo+xml 1289 EmergencyCallData.ServiceInfo+xml 1290 EmergencyCallData.SubscriberInfo+xml 1292 14.2. Service URN Registrations 1294 IANA is requested to register the URN 'urn:service:sos.ecall' under 1295 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1297 This service requests resources associated with an emergency call 1298 placed by an in-vehicle system, carrying a standardized set of data 1299 related to the vehicle and incident. Two sub-services are registered 1300 as well: 1302 urn:service:sos.ecall.manual 1304 Used with an eCall invoked due to manual interaction by a vehicle 1305 occupant. 1307 urn:service:sos.ecall.automatic 1309 Used with an eCall invoked automatically, for example, due to a 1310 crash or other serious incident. 1312 IANA is also requested to register the URN 1313 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1314 defined in Setcion 17.2 of [RFC6881]. This service requests 1315 resources associated with a test (non-emergency) call placed by an 1316 in-vehicle system. See Section 8 for more information on the test 1317 eCall request URN. 1319 14.3. MIME Structured Syntax Suffix Registration for +PER 1321 IANA is requested to add "+PER" to the as a media type structured 1322 syntax suffix in the Structured Syntax Suffix registry. The ITU 1323 defined the Packed Encoding Rules (PER) transfer syntax in 1324 [ITU.X691]. The suffix "+per" MAY be used with any media type whose 1325 representation follows the PER transfer syntax. The media type 1326 structured syntax suffix registration form for +per follows: 1328 Name: Packed Encoding Rules (PER) transfer syntax 1330 +suffix: +per 1332 References: [ITU.X691] 1334 Encoding considerations: PER is a binary encoding 1336 Interoperability considerations: none identified 1338 Fragment identifier considerations: 1340 At publication of this document, there is no fragment 1341 identification syntax defined for +per. 1343 The syntax and semantics for fragment identifiers for a 1344 specific "xxx/yyy+per" SHOULD be processed as follows: 1346 For cases defined in +per, where the fragment identifier 1347 resolves per the +per rules, then process as specified in +per. 1349 For cases defined in +per, where the fragment identifier does 1350 not resolve per the +per rules, then process as specified in 1351 "xxx/yyy+per". 1353 For cases not defined in +per, then process as specified in 1354 "xxx/yyy+per". 1356 Security considerations: 1358 Because of the binary and structured nature of PER, it is not 1359 difficult to construct malicious content that could cause 1360 buffer overruns, stack overflows, and other attack vectors. 1362 Implementors should be aware of these issues and take 1363 appropriate measures to guard against buffer overruns, stack 1364 overflows, and related attack vectors. 1366 Contact: Apps Area Working Group (art@ietf.org) 1368 Author/Change controller: 1370 The Apps Area Working Group. IESG has change control over this 1371 registration. 1373 14.4. MIME Media Type Registration for 'application/ 1374 emergencyCallData.eCall.MSD+per' 1376 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1377 as a MIME media type, with a reference to this document, in 1378 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1379 RFC 7303 [RFC7303]. 1381 MIME media type name: application 1383 MIME subtype name: emergencyCallData.eCall.MSD+per 1385 Mandatory parameters: none 1387 Optional parameters: none 1389 Encoding scheme: binary 1391 Encoding considerations: Uses ASN.1 PER, which is a binary 1392 encoding; when transported in SIP, binary content transfer 1393 encoding is used. 1395 Security considerations: This media type is designed to carry 1396 vehicle and incident-related data during an emergency call. This 1397 data contains personal information including vehicle VIN, 1398 location, direction, etc. Appropriate precautions need to be 1399 taken to limit unauthorized access, inappropriate disclosure to 1400 third parties, and eavesdropping of this information. Sections 9 1401 and Section 10 of [RFC7852] contain more discussion. 1403 Interoperability considerations: None 1405 Published specification: Annex A of EN 15722 [msd] 1407 Applications which use this media type: Pan-European eCall 1408 compliant systems 1410 Additional information: None 1412 Magic Number: None 1414 File Extension: None 1416 Macintosh file type code: 'BINA' 1418 Person and email address for further information: Randall Gellens, 1419 rg+ietf@randy.pensive.org 1420 Intended usage: LIMITED USE 1422 Author: The MSD specification was produced by the European 1423 Committee For Standardization (CEN). For contact information, 1424 please see . 1426 Change controller: The European Committee For Standardization 1427 (CEN) 1429 14.5. MIME Media Type Registration for 'application/ 1430 emergencyCallData.control+xml' 1432 IANA is requested to add application/emergencyCallData.control+xml as 1433 a MIME media type, with a reference to this document, in accordance 1434 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1435 [RFC7303]. 1437 MIME media type name: application 1439 MIME subtype name: emergencyCallData.control+xml 1441 Mandatory parameters: none 1443 Optional parameters: charset 1445 Indicates the character encoding of the XML content. 1447 Encoding considerations: Uses XML, which can employ 8-bit 1448 characters, depending on the character encoding used. See 1449 Section 3.2 of RFC 7303 [RFC7303]. 1451 Security considerations: 1453 This media type carries metadata and control information and 1454 requests, such as from a Public Safety Answering Point (PSAP) 1455 to an In-Vehicle System (IVS) during an emergency call. 1457 Metadata (such as an acknowledgment that data sent by the IVS 1458 to the PSAP was successfully received) has limited privacy and 1459 security implications. Control information (such as requests 1460 from the PSAP that the vehicle perform an action) has some 1461 privacy and security implications. The privacy concern arises 1462 from the ability to request the vehicle to transmit a data set, 1463 which as described in Section 14.4, can contain personal 1464 information. The security concern is the ability to request 1465 the vehicle to perform an action. Control information needs to 1466 originate only from a PSAP or other emergency services 1467 provider, and not be modified en-route. The level of integrity 1468 of the cellular network over which the emergency call is placed 1469 is a consideration: when the IVS initiates an eCall over a 1470 cellular network, in most cases it relies on the MNO to route 1471 the call to a PSAP. (Calls placed using other means, such as 1472 Wi-Fi or over-the-top services, generally incur somewhat higher 1473 levels of risk than calls placed "natively" using cellular 1474 networks.) A call-back from a PSAP merits additional 1475 consideration, since current mechanisms are not ideal for 1476 verifying that such a call is indeed a call-back from a PSAP in 1477 response to an emergency call placed by the IVS. See the 1478 discussion in Section 11 and the PSAP Callback document 1479 [RFC7090]. 1481 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1483 Interoperability considerations: None 1485 Published specification: This document 1487 Applications which use this media type: Pan-European eCall 1488 compliant systems 1490 Additional information: None 1492 Magic Number: None 1494 File Extension: .xml 1496 Macintosh file type code: 'TEXT' 1498 Person and email address for further information: Randall Gellens, 1499 rg+ietf@randy.pensive.org 1501 Intended usage: LIMITED USE 1503 Author: The IETF ECRIT WG. 1505 Change controller: The IETF ECRIT WG. 1507 14.6. Registration of the 'eCall.MSD' entry in the Emergency Call 1508 Additional Data Types registry 1510 This specification requests IANA to add the 'eCall.MSD' entry to the 1511 Emergency Call Additional Data Types registry, with a reference to 1512 this document; the 'Data About' value is 'The Call'. 1514 14.7. Registration of the 'control' entry in the Emergency Call 1515 Additional Data Types registry 1517 This specification requests IANA to add the 'control' entry to the 1518 Emergency Call Additional Data Types registry, with a reference to 1519 this document; the 'Data About' value is 'The Call'. 1521 14.8. URN Sub-Namespace Registration 1523 14.8.1. Registration for urn:ietf:params:xml:ns:eCall 1525 This section registers a new XML namespace, as per the guidelines in 1526 RFC 3688 [RFC3688]. 1528 URI: urn:ietf:params:xml:ns:eCall 1530 Registrant Contact: IETF, ECRIT working group, , as 1531 delegated by the IESG . 1533 XML: 1535 BEGIN 1536 1537 1539 1540 1541 1543 Namespace for eCall Data 1544 1545 1546

Namespace for eCall Data

1547

See [TBD: This document].

1548 1549 1550 END 1552 14.8.2. Registration for 1553 urn:ietf:params:xml:ns:EmergencyCallData:control 1555 This section registers a new XML namespace, as per the guidelines in 1556 RFC 3688 [RFC3688]. 1558 URI: urn:ietf:params:xml:ns:EmergencyCallData:control 1559 Registrant Contact: IETF, ECRIT working group, , as 1560 delegated by the IESG . 1562 XML: 1564 BEGIN 1565 1566 1568 1569 1570 1572 Namespace for Emergency Call Data Control Block 1573 1574 1575

Namespace for Emergency Call Data Control Block

1576

See [TBD: This document].

1577 1578 1579 END 1581 14.9. Registry Creation 1583 This document creates a new registry called "Emergency Call Metadata/ 1584 Control Data". The following sub-registries are created for this 1585 registry. 1587 14.9.1. Emergency Call Action Registry 1589 This document creates a new sub-registry called "Emergency Call 1590 Action". As defined in [RFC5226], this registry operates under 1591 "Expert Review" rules. The expert should determine that the proposed 1592 action is within the purview of a vehicle, is sufficiently 1593 distinguishable from other actions, and the action is clearly and 1594 fully described. In most cases, a published and stable document is 1595 referenced for the description of the action. 1597 The content of this registry includes: 1599 Name: The identifier to be used in the 'action' attribute of a 1600 control element. 1602 Description: A description of the action. In most cases this will 1603 be a reference to a published and stable document. The 1604 description MUST specify if any attributes or child elements are 1605 optional or mandatory, and describe the action to be taken by the 1606 vehicle. 1608 The initial set of values is listed in Table 2. 1610 +-----------+--------------------------------------+ 1611 | Name | Description | 1612 +-----------+--------------------------------------+ 1613 | send-data | See Section 9.1.3.1 of this document | 1614 +-----------+--------------------------------------+ 1616 Table 2: Emergency Call Action Registry Initial Values 1618 14.9.2. Emergency Call Action Failure Reason Registry 1620 This document creates a new sub-registry called "Emergency Call 1621 Action Failure Reason" which contains values for the 'reason' 1622 attribute of the element. As defined in [RFC5226], 1623 this registry operates under "Expert Review" rules. The expert 1624 should determine that the proposed reason is sufficiently 1625 distinguishable from other reasons and that the proposed description 1626 is understandable and correctly worded. 1628 The content of this registry includes: 1630 ID: A short string identifying the reason, for use in the 'reason' 1631 attribute of an element. 1633 Description: A description of the reason. 1635 The initial set of values is listed in Table 3. 1637 +------------------+------------------------------------------------+ 1638 | ID | Description | 1639 +------------------+------------------------------------------------+ 1640 | damaged | Required components are damaged. | 1641 | | | 1642 | data-unsupported | The data item referenced in a 'send-data' | 1643 | | request is not supported. | 1644 | | | 1645 | security-failure | The authenticity of the request or the | 1646 | | authority of the requestor could not be | 1647 | | verified. | 1648 | | | 1649 | unable | The action could not be accomplished (a | 1650 | | generic error for use when no other code is | 1651 | | appropriate). | 1652 | | | 1653 | unsupported | The 'action' value is not supported. | 1654 +------------------+------------------------------------------------+ 1656 Table 3: Emergency Call Action Failure Reason Registry Initial Values 1658 14.10. The emergencyCallData.eCall.MSD INFO package 1660 This document registers the 'emergencyCallData.eCall.MSD' INFO 1661 package. 1663 Both endpoints (the IVS and the PSAP equipment) include 1664 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 1665 [RFC6086] to indicate ability to receive INFO requests carrying data 1666 as described here. 1668 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 1669 the ability to receive eCall related body parts as specified in [TBD: 1670 THIS DOCUMENT]. 1672 An INFO request message carrying body parts related to an emergency 1673 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 1674 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 1676 The requirements of Section 10 of [RFC6086] are addressed in the 1677 following sections. 1679 14.10.1. Overall Description 1681 This section describes "what type of information is carried in INFO 1682 requests associated with the Info Package, and for what types of 1683 applications and functionalities UAs can use the Info Package." 1684 INFO requests associated with the emergencyCallData.eCall.MSD INFO 1685 package carry data associated with emergency calls as defined in 1686 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 1687 calls established using SIP. The functionality is to carry vehicle 1688 data and metadata/control information between vehicles and PSAPs. 1689 Refer to [TBD: THIS DOCUMENT] for more information. 1691 14.10.2. Applicability 1693 This section describes "why the Info Package mechanism, rather than 1694 some other mechanism, has been chosen for the specific use-case...." 1696 The use of the SIP INFO method is based on an analysis of the 1697 requirements against the intent and effects of the INFO method versus 1698 other approaches (which included the SIP MESSAGE method, the SIP 1699 OPTIONS method, the SIP re-INVITE method, media plane transport, and 1700 non-SIP protocols). In particular, the transport of emergency call 1701 data blocks occurs within a SIP emergency dialog, per Section 6, and 1702 is normally carried in the initial INVITE request and response; the 1703 use of the SIP INFO method only occurs when emergency-call-related 1704 data needs to be sent mid-call. While the SIP MESSAGE method could 1705 be used, it is not tied to a SIP dialog as is the SIP INFO method and 1706 thus might not be associated with the dialog. Either the SIP OPTIONS 1707 or re-INVITE methods could also be used, but is seen as less clean 1708 than the SIP INFO method. The SIP SUBSCRIBE/NOTIFY method could be 1709 coerced into service, but the semantics are not a good fit, e.g., the 1710 subscribe/notify mechanism provides one-way communication consisting 1711 of (often multiple) notifications from notifier to subscriber 1712 indicating that certain events in notifier have occurred, whereas 1713 what's needed here is two-way communication of data related to the 1714 emergency dialog. Use of the media plane mechanisms was discounted 1715 because the number of messages needing to be exchanged in a dialog is 1716 normally zero or very few, and the size of the data is likewise very 1717 small. The overhead caused by user plane setup (e.g., to use MSRP as 1718 transport) would be disproportionately large. 1720 Based on the analyses, the SIP INFO method was chosen to provide for 1721 mid-call data transport. 1723 14.10.3. Info Package Name 1725 The info package name is emergencyCallData.eCall.MSD 1727 14.10.4. Info Package Parameters 1729 None 1731 14.10.5. SIP Option-Tags 1733 None 1735 14.10.6. INFO Request Body Parts 1737 The body for an emergencyCallData.eCall.MSD info package is a 1738 multipart (normally multipart/mixed) body containing zero or one 1739 application/emergencyCallData.eCall.MSD+per part (containing an MSD) 1740 and zero or more application/emergencyCallData.control+xml 1741 (containing a metadata/control object) parts. At least one MSD or 1742 metadata/control body part is expected; the behavior upon receiving 1743 an INFO request with neither is undefined. 1745 The body parts are sent per [RFC6086], and in addition, to align with 1746 with how these body parts are sent in SIP messages other than INFO 1747 requests, each associated body part is referenced by a Call-Info 1748 header field at the top level of the SIP message. The body part has 1749 a Content-Disposition header field set to "By-Reference". 1751 An MSD or metadata/control block is always enclosed in a multipart 1752 body part (even if it would otherwise be the only body part in the 1753 SIP message), since as of the date of this document, the use of 1754 Content-ID as a SIP header field is not defined (while it is defined 1755 for use as a MIME header field). The innermost multipart that 1756 contains only body parts associated with the INFO package has a 1757 Content-Disposition value of Info-Package. 1759 See [TBD: THIS DOCUMENT] for more information. 1761 14.10.7. Info Package Usage Restrictions 1763 Usage is limited to vehicle-initiated emergency calls as defined in 1764 [TBD: THIS DOCUMENT]. 1766 14.10.8. Rate of INFO Requests 1768 The SIP INFO request is used within an established emergency call 1769 dialog for the PSAP to request the IVS to send an updated MSD, and 1770 for the IVS to send a requested MSD. Because this is normally done 1771 only on manual request of the PSAP call taker (who suspects some 1772 aspect of the vehicle state has changed), the rate of SIP INFO 1773 requests associated with the emergencyCallData.eCall.MSD info package 1774 is normally quite low (most dialogs are likely to contain zero INFO 1775 requests, while others might carry an occasional request). 1777 14.10.9. Info Package Security Considerations 1779 The MIME media type registrations specified for use with this INFO 1780 package (Section 14.4 and Section 14.5) contain a discussion of the 1781 security and/or privacy considerations specific to that data block. 1782 The "Security Considerations" and "Privacy Considerations" sections 1783 of [TBD: THIS DOCUMENT] discuss security and privacy considerations 1784 of the data carried in eCalls. 1786 14.10.10. Implementation Details 1788 See [TBD: THIS DOCUMENT] for protocol details. 1790 14.10.11. Examples 1792 See [TBD: THIS DOCUMENT] for protocol examples. 1794 15. Contributors 1796 Brian Rosen was a co-author of the original document upon which this 1797 document is based. 1799 16. Acknowledgements 1801 We would like to thank Bob Williams and Ban Al-Bakri for their 1802 feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Alissa 1803 Cooper, Keith Drage, Stephen Edge, Wes George, Mirja Kuehlewind, 1804 Allison Mankin, Alexey Melnikov, Ivo Sedlacek, and James Winterbottom 1805 for their review and comments; Robert Sparks and Paul Kyzivat for 1806 their help with the SIP mechanisms; Mark Baker and Ned Freed for 1807 their help with the media subtype registration issue. We would like 1808 to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and 1809 Ulrich Dietz for their help with the original document upon which 1810 this document is based. Christer Holmberg deserves special mention 1811 for his many detailed reviews. 1813 17. Changes from Previous Versions 1815 RFC Editor: Please remove this section prior to publication. 1817 17.1. Changes from draft-ietf-19 to draft-ietf-20 1819 o Fixed various nits 1821 17.2. Changes from draft-ietf-18 to draft-ietf-19 1823 o Added additional text to "Rate of Info Requests" 1824 o Added additional text to "Security Considerations" 1825 o Further corrected "content type" to "media type" 1827 17.3. Changes from draft-ietf-17 to draft-ietf-18 1829 o Added reference to 3GPP TS24.229 1830 o Clarified that an INFO request is expected to have at least one 1831 MSD or metadata/control body part 1832 o Fixed minor errors in examples 1833 o Corrected "content type" to "media type" 1834 o Deleted "xsi:schemaLocation" from examples 1836 17.4. Changes from draft-ietf-16 to draft-ietf-17 1838 o Clarify Content-Disposition value in INFO requests 1840 17.5. Changes from draft-ietf-15 to draft-ietf-16 1842 o Various clarifications and simplifications 1843 o Added reference to 3GPP 23.167 1845 17.6. Changes from draft-ietf-14 to draft-ietf-15 1847 o eCall body parts now always sent enclosed in multipart (even if 1848 only body part in SIP message) and hence always have a Content- 1849 Disposition of By-Reference 1850 o Fixed errors in attribute directionality text 1851 o Fixed typos. 1853 17.7. Changes from draft-ietf-13 to draft-ietf-14 1855 o Added text to the IANA Considerations to formalize the 1856 EmergencyCallData media subtree 1857 o Fixed some typos 1859 17.8. Changes from draft-ietf-12 to draft-ietf-13 1861 o Clarifications suggested by Christer 1862 o Corrections to Content-Disposition text and examples as suggested 1863 by Paul Kyzivat 1864 o Clarifications to Content-Disposition text and examples to clarify 1865 that handling=optional is only used in the initial INVITE 1867 17.9. Changes from draft-ietf-11 to draft-ietf-12 1869 o Fixed errors in examples found by Dale 1870 o Removed enclosing sub-section of INFO package registration section 1871 o Added text per Christer and Dale's suggestions that the MSD and 1872 metadata/control blocks are sent in INFO with a Call-Info header 1873 field referencing them 1874 o Deleted Call Routing section (7.1) in favor of a statement that 1875 call routing is outside the scope of the document 1876 o Other text changes per comments received from Christer and Ivo. 1878 17.10. Changes from draft-ietf-09 to draft-ietf-11 1880 o Renamed INFO package to emergencyCallData.eCall.MSD 1881 o Changed INFO package to only permit MSD and metadata/control MIME 1882 types 1883 o Moved element back from car-crash but made it 1884 OPTIONAL 1885 o Moved other extension points back from car-crash so that extension 1886 points are in base spec (and also to get XML schema to compile) 1887 o Text changes for clarification. 1889 17.11. Changes from draft-ietf-08 to draft-ietf-09 1891 o Created a new "Data Transport" section that describes how the MSD 1892 and metadata/control blocks are attached, and then referred to 1893 that section rather than repeat the information about the CID and 1894 Call-Info and so forth, which means most references to the 1895 additional-data draft have now been deleted 1896 o Mentioned edge cases where a PSAP response to INVITE isn't 1897 received by the IVS 1898 o Reworded description of which status codes are used when a PSAP 1899 wishes to reject a call but inform the vehicle occupants that it 1900 is aware of the situation to be more definite 1901 o Added examples showing INFO 1902 o Added references for eCall test call requirement 1903 o Described meaning of eCall URNs in Section 8 as well as in IANA 1904 registration 1906 17.12. Changes from draft-ietf-07 to draft-ietf-08 1908 o eCall MSD now encoded as ASN.1 PER, using binary content transfer 1909 encoding 1910 o Added text to point out aspects of call handling and metadata/ 1911 control usage, such as use in rejected calls, and solicited MSDs 1912 o Revised use of INFO to require that when a request for an MSD is 1913 sent in INFO, the MSD sent in response is in its own INFO, not the 1914 response to the requesting INFO 1916 o Added material to INFO package registation to comply with 1917 Section 10 of [RFC6086] 1918 o Moved material not required by 3GPP into 1919 [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ 1920 control elements, attributes, and values 1921 o Revised test call wording to clarify that specific handling is out 1922 of scope 1923 o Revised wording throughout the document to simplify 1924 o Moved new Section 7.1 to be a subsection of 7 1925 o Moved new Section Section 14.10 to be a main section instead of a 1926 subsection of Section 9 1927 o Revised SIP INFO usage and package registration per advice from 1928 Robert Sparks and Paul Kyzivat 1930 17.13. Changes from draft-ietf-06 to draft-ietf-07 1932 o Fixed typo in Acknowledgements 1934 17.14. Changes from draft-ietf-05 to draft-ietf-06 1936 o Added additional security and privacy clarifications regarding 1937 signed and encrypted data 1938 o Additional security and privacy text 1939 o Deleted informative section on ESINets as unnecessary. 1941 17.15. Changes from draft-ietf-04 to draft-ietf-05 1943 o Reworked the security and privacy considerations material in the 1944 document as a whole and in the MIME registation sections of the 1945 MSD and control objects 1946 o Clarified that the element can appear multiple 1947 times within an element 1948 o Fixed IMS definition 1949 o Added clarifying text for the 'msgid' attribute 1951 17.16. Changes from draft-ietf-03 to draft-ietf-04 1953 o Added Privacy Considerations section 1954 o Reworded most uses of non-normative "may", "should", "must", and 1955 "recommended." 1956 o Fixed nits in examples 1958 17.17. Changes from draft-ietf-02 to draft-ietf-03 1960 o Added request to enable cameras 1961 o Improved examples and XML schema 1962 o Clarifications and wording improvements 1964 17.18. Changes from draft-ietf-01 to draft-ietf-02 1966 o Added clarifying text reinforcing that the data exchange is for 1967 small blocks of data infrequently transmitted 1968 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1969 establish a one-way media stream 1970 o Clarified that the scope is the needs of eCall within the SIP 1971 emergency call environment 1972 o Added informative statement that the document may be suitable for 1973 reuse by other ACN systems 1974 o Clarified that normative language for the control block applies to 1975 both IVS and PSAP 1976 o Removed 'ref', 'supported-mime', and elements 1977 o Minor wording improvements and clarifications 1979 17.19. Changes from draft-ietf-00 to draft-ietf-01 1981 o Added further discussion of test calls 1982 o Added further clarification to the document scope 1983 o Mentioned that multi-region vehicles may need to support other 1984 crash notification specifications in addition to eCall 1985 o Added details of the eCall metadata and control functionality 1986 o Added IANA registration for the MIME media type for the control 1987 object 1988 o Added IANA registries for protocol elements and tokens used in the 1989 control object 1990 o Minor wording improvements and clarifications 1992 17.20. Changes from draft-gellens-03 to draft-ietf-00 1994 o Renamed from draft-gellens- to draft-ietf-. 1995 o Added mention of and reference to ETSI TR "Mobile Standards Group 1996 (MSG); eCall for VoIP" 1997 o Added text to Introduction regarding migration/co-existence being 1998 out of scope 1999 o Added mention in Security Considerations that even if the network- 2000 supplied location is just the cell site, this can be useful as a 2001 sanity check on the IVS-supplied location 2002 o Minor wording improvements and clarifications 2004 17.21. Changes from draft-gellens-02 to -03 2006 o Clarifications and editorial improvements. 2008 17.22. Changes from draft-gellens-01 to -02 2010 o Minor wording improvements 2011 o Removed ".automatic" and ".manual" from 2012 "urn:service:test.sos.ecall" registration and discussion text. 2014 17.23. Changes from draft-gellens-00 to -01 2016 o Now using 'EmergencyCallData' for purpose parameter values and 2017 MIME subtypes, in accordance with changes to [RFC7852] 2018 o Added reference to RFC 6443 2019 o Fixed bug that caused Figure captions to not appear 2021 18. References 2023 18.1. Normative References 2025 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 2026 minimum set of data (MSD), EN 15722", April 2015. 2028 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2029 Requirement Levels", BCP 14, RFC 2119, 2030 DOI 10.17487/RFC2119, March 1997, 2031 . 2033 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2034 DOI 10.17487/RFC3688, January 2004, 2035 . 2037 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 2038 Emergency and Other Well-Known Services", RFC 5031, 2039 DOI 10.17487/RFC5031, January 2008, 2040 . 2042 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2043 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2044 DOI 10.17487/RFC5226, May 2008, 2045 . 2047 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 2048 Initiation Protocol (SIP) INFO Method and Package 2049 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 2050 . 2052 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2053 Specifications and Registration Procedures", BCP 13, 2054 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2055 . 2057 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 2058 Communications Services in Support of Emergency Calling", 2059 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 2060 . 2062 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 2063 DOI 10.17487/RFC7303, July 2014, 2064 . 2066 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 2067 J. Winterbottom, "Additional Data Related to an Emergency 2068 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 2069 . 2071 18.2. Informative references 2073 [CEN] "European Committee for Standardization", 2074 . 2076 [EN_16062] 2077 CEN, , "Intelligent transport systems -- eSafety -- eCall 2078 High Level Application Requirements (HLAP) Using GSM/UMTS 2079 Circuit Switched Networks, EN 16062", April 2015. 2081 [EN_16072] 2082 CEN, , "Intelligent transport systems -- eSafety -- Pan- 2083 European eCall operating requirements, EN 16072", April 2084 2015. 2086 [I-D.ietf-ecrit-car-crash] 2087 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 2088 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 2089 ecrit-car-crash-21 (work in progress), January 2017. 2091 [ITU.X691] 2092 International Telecommunications Union, , "Information 2093 technology -- ASN.1 encoding rules: Specification of 2094 Packed Encoding Rules (PER), ITU-T X.691", July 2002, 2095 . 2098 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 2099 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 2100 April 2014. 2102 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 2103 Emergency Context Resolution with Internet Technologies", 2104 RFC 5012, DOI 10.17487/RFC5012, January 2008, 2105 . 2107 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 2108 Shanmugam, "Security Threats and Requirements for 2109 Emergency Call Marking and Mapping", RFC 5069, 2110 DOI 10.17487/RFC5069, January 2008, 2111 . 2113 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 2114 "Framework for Emergency Calling Using Internet 2115 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2116 2011, . 2118 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 2119 Patel, "Public Safety Answering Point (PSAP) Callback", 2120 RFC 7090, DOI 10.17487/RFC7090, April 2014, 2121 . 2123 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 2124 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 2125 December 2014, . 2127 [SDO-3GPP] 2128 "3d Generation Partnership Project", 2129 . 2131 [SDO-ETSI] 2132 "European Telecommunications Standards Institute (ETSI)", 2133 . 2135 [TS22.101] 2136 3GPP, , "3GPP TS 22.101: Technical Specification Group 2137 Services and System Aspects; Service aspects; Service 2138 principles". 2140 [TS23.167] 2141 3GPP, , "3GPP TS 23.167: IP Multimedia Subsystem (IMS) 2142 emergency sessions". 2144 [TS24.229] 2145 3GPP, , "3GPP TS 24.229: IP multimedia call control 2146 protocol based on Session Initiation Protocol (SIP) and 2147 Session Description Protocol (SDP); Stage 3". 2149 Authors' Addresses 2151 Randall Gellens 2152 Core Technology Consulting 2154 Email: rg+ietf@randy.pensive.org 2156 Hannes Tschofenig 2157 Individual 2159 Email: Hannes.Tschofenig@gmx.net 2160 URI: http://www.tschofenig.priv.at