idnits 2.17.00 (12 Aug 2021) /tmp/idnits47880/draft-ietf-ecrit-ecall-23.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 16, 2017) is 1950 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 20, 2017 Individual 6 January 16, 2017 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-23.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 20, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 urn:ietf:params:xml:ns:control . . 34 104 14.9. Registry Creation . . . . . . . . . . . . . . . . . . . 35 105 14.9.1. Emergency Call Action Registry . . . . . . . . . . . 35 106 14.9.2. Emergency Call Action Failure Reason Registry . . . 36 107 14.10. The emergencyCallData.eCall.MSD INFO package . . . . . . 37 108 14.10.1. Overall Description . . . . . . . . . . . . . . . . 37 109 14.10.2. Applicability . . . . . . . . . . . . . . . . . . . 38 110 14.10.3. Info Package Name . . . . . . . . . . . . . . . . . 38 111 14.10.4. Info Package Parameters . . . . . . . . . . . . . . 38 112 14.10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 39 113 14.10.6. INFO Request Body Parts . . . . . . . . . . . . . . 39 114 14.10.7. Info Package Usage Restrictions . . . . . . . . . . 39 115 14.10.8. Rate of INFO Requests . . . . . . . . . . . . . . . 39 116 14.10.9. Info Package Security Considerations . . . . . . . 40 117 14.10.10. Implementation Details . . . . . . . . . . . . . . 40 118 14.10.11. Examples . . . . . . . . . . . . . . . . . . . . . 40 119 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 120 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 121 17. Changes from Previous Versions . . . . . . . . . . . . . . . 40 122 17.1. Changes from draft-ietf-19 to draft-ietf-20 . . . . . . 40 123 17.2. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 41 124 17.3. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 41 125 17.4. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 41 126 17.5. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 41 127 17.6. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 41 128 17.7. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 41 129 17.8. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 41 130 17.9. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 42 131 17.10. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 42 132 17.11. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 42 133 17.12. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 42 134 17.13. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 43 135 17.14. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 43 136 17.15. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 43 137 17.16. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 43 138 17.17. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 43 139 17.18. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 44 140 17.19. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 44 141 17.20. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 44 142 17.21. Changes from draft-gellens-02 to -03 . . . . . . . . . . 44 143 17.22. Changes from draft-gellens-01 to -02 . . . . . . . . . . 45 144 17.23. Changes from draft-gellens-00 to -01 . . . . . . . . . . 45 145 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 146 18.1. Normative References . . . . . . . . . . . . . . . . . . 45 147 18.2. Informative references . . . . . . . . . . . . . . . . . 46 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 150 1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 This document re-uses terminology defined in Section 3 of [RFC5012]. 158 Additionally, we use the following abbreviations: 160 +--------+----------------------------------------+ 161 | Term | Expansion | 162 +--------+----------------------------------------+ 163 | 3GPP | 3rd Generation Partnership Project | 164 | | | 165 | CEN | European Committee for Standardization | 166 | | | 167 | EENA | European Emergency Number Association | 168 | | | 169 | ESInet | Emergency Services IP network | 170 | | | 171 | IMS | IP Multimedia Subsystem | 172 | | | 173 | IVS | In-Vehicle System | 174 | | | 175 | MNO | Mobile Network Operator | 176 | | | 177 | MSD | Minimum Set of Data | 178 | | | 179 | PSAP | Public Safety Answering Point | 180 +--------+----------------------------------------+ 182 2. Document Scope 184 This document is focused on the signaling, data exchange, and 185 protocol needs of next-generation eCall (NG-eCall, also referred to 186 as packet-switched eCall or all-IP eCall) within the SIP framework 187 for emergency calls (as described in [RFC6443] and [RFC6881]). eCall 188 itself is specified by 3GPP (3rd Generation Partnership Project) and 189 CEN (European Committee for Standardization) and these specifications 190 include far greater scope than is covered here. 192 The eCall service operates over cellular wireless communication, but 193 this document does not address cellular-specific details, nor client 194 domain selection (e.g., circuit-switched versus packet-switched). 195 All such aspects are the purview of their respective standards 196 bodies. The scope of this document is limited to eCall operating 197 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling 198 [TS23.167]). 200 Although this specification is designed to meet the requirements of 201 pan-European next-generation eCall, it is specified generically such 202 that the technology can be re-used or extended to suit requirements 203 across jurisdictions (see, e.g., [I-D.ietf-ecrit-car-crash]), and 204 extension points are provided to facilitate this. 206 Note that vehicles designed for multiple regions might need to 207 support eCall and other Advanced Automatic Crash Notification (AACN) 208 systems (such as described in [I-D.ietf-ecrit-car-crash]), but this 209 is out of scope of this document. 211 3. Introduction 213 Emergency calls made from vehicles (e.g., in the event of a crash) 214 assist in significantly reducing road deaths and injuries by allowing 215 emergency services to be aware of the incident, the state of the 216 vehicle, the location of the vehicle, and to have a voice channel 217 with the vehicle occupants. This enables a quick and appropriate 218 response. 220 The European Commission initiative of eCall was conceived in the late 221 1990s, and has evolved to a European Parliament decision requiring 222 the implementation of a compliant in-vehicle system (IVS) in new 223 vehicles and the deployment of eCall in the European Member States in 224 the very near future. Other regions are developing eCall-compatible 225 systems. 227 The pan-European eCall system is a standardized and mandated 228 mechanism for emergency calls by vehicles, providing a voice channel 229 and transmission of data. eCall establishes procedures for such 230 calls to be placed by in-vehicle systems, recognized and processed by 231 the mobile network, and routed to a specialized PSAP where the 232 vehicle data is available to assist the call taker in assessing and 233 responding to the situation. eCall provides a standard set of 234 vehicle, sensor (e.g., crash related), and location data. 236 An eCall can be either user-initiated or automatically triggered. 237 Automatically triggered eCalls indicate a car crash or some other 238 serious incident. Manually triggered eCalls might be reports of 239 witnessed crashes or serious hazards. PSAPs might apply specific 240 operational handling to manual and automatic eCalls. 242 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 243 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 244 call setup mark the call as an eCall, and further indicate if the 245 call was automatically or manually triggered. The call is routed to 246 an eCall-capable PSAP, a voice channel is established between the 247 vehicle and the PSAP, and an eCall in-band modem is used to carry a 248 defined set of vehicle, sensor (e.g., crash related), and location 249 data (the Minimum Set of Data or MSD) within the voice channel. The 250 same in-band mechanism is used for the PSAP to acknowledge successful 251 receipt of the MSD, and to request the vehicle to send a new MSD 252 (e.g., to check if the state of or location of the vehicle or its 253 occupants has changed). NG-eCall moves from circuit switched to all- 254 IP, and carries the vehicle data and eCall signaling as additional 255 data carried with the call. This document describes how IETF 256 mechanisms for IP-based emergency calls (including [RFC6443] and 257 [RFC7852]) are used to provide the signaling and data exchange of the 258 next generation of pan-European eCall. 260 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 261 has published a Technical Report titled "Mobile Standards Group 262 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 263 recommendations regarding support for eCall in an all-IP environment. 264 The recommendations include the use of 3GPP IMS emergency calling 265 with additional elements identifying the call as an eCall and as 266 carrying eCall data and with mechanisms for carrying the data and 267 eCall signaling. 3GPP IMS emergency services support multimedia, 268 providing the ability to carry voice, text, and video. This 269 capability is referred to within 3GPP as Multimedia Emergency 270 Services (MMES). 272 A transition period will exist during which time the various entities 273 involved in initiating and handling an eCall might support next- 274 generation eCall, legacy eCall, or both. The issues of migration and 275 co-existence during the transition period are outside the scope of 276 this document. 278 This document indicates how to use IP-based emergency services 279 mechanisms to support next-generation eCall. 281 This document also registers MIME media types and an Emergency Call 282 Additional Data Block for the eCall vehicle data (MSD) and metadata/ 283 control data, and an INFO package to enable carrying this data in SIP 284 INFO requests. 286 The MSD is carried in the MIME type 'application/ 287 emergencyCallData.eCall.MSD+per' and the metadata/control block is 288 carried in the MIME type 'application/emergencyCallData.control+xml' 289 (both of which are registered in Section 14). An INFO package is 290 defined (in Section 14.10) to enable these MIME types to be carried 291 in SIP INFO requests, per [RFC6086]. 293 4. eCall Requirements 295 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 296 [TS22.101] clauses 10.7 and A.27 and [TS24.229] section 4.7.6. 297 Requirements specific to vehicle data are contained in EN 15722 298 [msd]. 300 5. Vehicle Data 302 Pan-European eCall provides a standardized and mandated set of 303 vehicle related data (including VIN, vehicle type, propulsion type, 304 current and optionally previous location coordinates, and number of 305 occupants), known as the Minimum Set of Data (MSD). The European 306 Committee for Standardization (CEN) has specified this data in EN 307 15722 [msd], along with both ASN.1 and XML encodings. Both circuit- 308 switched eCall and this document use the ASN.1 PER encoding, which is 309 specified in Annex A of EN 15722 [msd] (the XML encoding specified in 310 Annex C is not used in this document, per 3GPP [SDO-3GPP]). 312 This document registers the 'application/ 313 emergencyCallData.eCall.MSD+per' MIME media type to enable the MSD to 314 be carried in SIP. As an ASN.1 PER encoded object, the data is 315 binary and transported using binary content transfer encoding within 316 SIP messages. This document also adds the 'eCall.MSD' entry to the 317 Emergency Call Additional Data Types registry to enable the MSD to be 318 recognized as such in a SIP-based eCall emergency call. (See 319 [RFC7852] for more information about the registry and how it is 320 used.) 322 See Section 6 for a discussion of how the MSD vehicle data is 323 conveyed in an NG-eCall. 325 6. Data Transport 327 [RFC7852] establishes a general mechanism for conveying blocks of 328 data within a SIP emergency call. This document makes use of that 329 mechanism to include vehicle data (the MSD, see Section 5) and/or 330 metadata/control information (see Section 9) within SIP messages. 331 This document also registers an INFO package (in Section 14.10) to 332 enable eCall related data blocks to be carried in SIP INFO requests 333 (per [RFC6086], new INFO usages require the definition of an INFO 334 package). 336 Note that if other data sets need to be transmitted in the future, 337 the appropriate signalling mechanism for such data needs to be 338 evaluated, including factors such as the size and frequency of such 339 data. 341 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 342 encoding it per Annex A of EN 15722 [msd], and including it as a MIME 343 body part within a SIP message per [RFC7852]. The body part is 344 identified by its MIME media type ('application/ 345 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 346 the body part. The body part is assigned a unique identifier which 347 is listed in a Content-ID header field in the body part. The SIP 348 message is marked as containing the MSD by adding (or appending to) a 349 Call-Info header field at the top level of the SIP message. This 350 Call-Info header field contains a CID URL referencing the body part's 351 unique identifier, and a 'purpose' parameter identifying the data as 352 the eCall MSD per the Emergency Call Additional Data Types registry 353 entry; the 'purpose' parameter's value is 354 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 355 SIP INFO request by using the INFO package defined in Section 14.10. 357 A PSAP or IVS transmits a metadata/control object (see Section 9) by 358 encoding it per the description in this document, and including it 359 within a SIP message as a MIME body part per [RFC7852]. The body 360 part is identified by its MIME media type ('application/ 361 emergencyCallData.control+xml') in the Content-Type header field of 362 the body part. The body part is assigned a unique identifier which 363 is listed in a Content-ID header field in the body part. The SIP 364 message is marked as containing the metadata/control object by adding 365 (or appending to) a Call-Info header field at the top level of the 366 SIP message. This Call-Info header field contains a CID URL 367 referencing the body part's unique identifier, and a 'purpose' 368 parameter identifying the data as an eCall metadata/control block per 369 the Emergency Call Additional Data Types registry entry; the 370 'purpose' parameter's value is 'emergencyCallData.control'. Per 371 [RFC6086], a metadata/control object is carried in a SIP INFO request 372 by using the INFO package defined in Section 14.10. 374 An MSD or a metadata/control block is always enclosed in a multipart 375 (normally multipart/mixed) body part (even if it would otherwise be 376 the only body part in the SIP message), since as of the date of this 377 document, the use of Content-ID as a SIP header field is not defined 378 (while it is defined for use as a MIME header field). 380 A body part containing an MSD or metadata/control object has a 381 Content-Disposition header field value containing "By-Reference". 383 An In-Vehicle System (IVS) initiating an NG-eCall includes an MSD as 384 a body part within the initial INVITE, and optionally also includes a 385 metadata/control object informing the PSAP of its capabilities as 386 another body part. The MSD body part (and metadata/control and PIDF- 387 LO body parts if included) have a Content-Disposition header field 388 with the value "By-Reference; handling=optional". Specifying 389 "handling=optional" prevents the SIP INVITE request from being 390 rejected if it is processed by a legacy element (e.g., a gateway 391 between SIP and circuit-switched environments) that does not 392 understand the MSD (or metadata/control object or PIDF-LO). The PSAP 393 creates a metadata/control object acknowledging receipt of the MSD 394 and includes it as a body part within the SIP final response to the 395 SIP INVITE request per [RFC7852]. A metadata/control object is not 396 included in provisional (e.g., 180) responses. 398 A PSAP is able to reject a call while indicating that it is aware of 399 the situation by including a metadata/control object acknowledging 400 the MSD and containing "received=true" within a final response using 401 SIP response code 600 (Busy Everywhere), 486 (Busy Here), or 603 402 (Decline), per [RFC7852]. 404 If the IVS receives an acknowledgment for an MSD containing 405 "received=false", this indicates that the PSAP was unable to properly 406 decode or process the MSD. The IVS action is not defined (e.g., it 407 might only log an error). Since the PSAP is able to request an 408 updated MSD during the call, if an initial MSD is unsatisfactory in 409 any way, the PSAP can choose to request another one. 411 A PSAP can request that the vehicle send an updated MSD during a call 412 (e.g., upon manual request of the PSAP call taker who suspects 413 vehicle state may have changed.) To do so, the PSAP creates a 414 metadata/control object requesting an MSD and includes it within a 415 SIP INFO request sent within the dialog. The IVS then includes an 416 updated MSD within a SIP INFO request and sends it within the dialog. 417 If the IVS is unable to send an MSD, it instead sends a metadata/ 418 control object acknowledging the request with the 'success' parameter 419 set to 'false' and a 'reason' parameter (and optionally a 'details' 420 parameter) indicating why the request could not be accomplished. Per 421 [RFC6086], metadata/control objects and MSDs are sent using the INFO 422 package defined in Section 14.10. In addition, to align with how an 423 MSD or metadata/control block is transmitted in a SIP message other 424 than an INFO request, a Call-Info header field is included in the SIP 425 INFO request to reference the MSD or metadata/control block per 426 [RFC7852]. See Section 14.10 for information about the use of SIP 427 INFO requests to carry data within an eCall. 429 The IVS is not expected to send an unsolicited MSD after the initial 430 INVITE. 432 This document does not mandate support for the data blocks defined in 433 [RFC7852]. 435 7. Call Setup 437 In circuit-switched eCall, the IVS places a special form of a 112 438 emergency call which carries an eCall flag (indicating that the call 439 is an eCall and also if the call was manually or automatically 440 triggered); the mobile network operator (MNO) recognizes the eCall 441 flag and routes the call to an eCall-capable PSAP; vehicle data is 442 transmitted to the PSAP via the eCall in-band modem (in the voice 443 channel). 445 ///----\\\ 112 voice call with eCall flag +------+ 446 ||| IVS |||---------------------------------------->+ PSAP | 447 \\\----/// vehicle data via eCall in-band modem +------+ 449 Figure 1: circuit-switched eCall 451 For NG-eCall, the IVS establishes an emergency call using a Request- 452 URI indicating a manual or automatic eCall; the MNO (or ESInet) 453 recognizes the eCall URN and routes the call to an NG-eCall capable 454 PSAP; the PSAP interprets the vehicle data sent with the call and 455 makes it available to the call taker. 457 ///----\\\ IMS emergency call with eCall URN +------+ 458 IVS ----------------------------------------->+ PSAP | 459 \\\----/// vehicle data included in call setup +------+ 461 Figure 2: NG-eCall 463 See Section 6 for information on how the MSD is transported within an 464 NG-eCall. 466 This document registers new service URN children within the "sos" 467 subservice. These URNs provide the mechanism by which an eCall is 468 identified, and differentiate between manually and automatically 469 triggered eCalls (which might be subject to different treatment, 470 depending on policy). The two service URNs are: 471 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 472 which requests resources associated with an emergency call placed by 473 an in-vehicle system, carrying a standardized set of data related to 474 the vehicle and incident. 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 registers "urn:service:test.sos.ecall" for eCall test 495 calls. 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 737 738 739 741 743 Figure 4: Capabilities Example 745 9.1.3. The element 747 A element appears one or more times on its own or as a 748 child of a element. It allows the PSAP to request 749 that the IVS perform an action. The only action that MUST be 750 supported is to send an MSD. The following attributes and child 751 elements are defined: 753 9.1.3.1. Attributes of the element 755 The element has the following attributes: 757 Name: action 758 Usage: Mandatory 759 Type: token 760 Direction: Sent in either direction 761 Description: Identifies the action that the vehicle is requested to 762 perform (in a element within a element, 763 indicates an action that the vehicle is capable of performing). 764 An IANA registry is established in Section 14.9.1 to contain the 765 allowed values. 766 Example: action="send-data" 768 Name: int-id 769 Usage: Conditional 770 Type: int 771 Direction: Sent in either direction 772 Description: Defined for extensibility. Documents that make use of 773 it are expected to explain when it is required and how it is used. 774 Example: int-id="3" 776 Name: persistence 777 Usage: Optional 778 Type: xs:duration 779 Direction: Sent in either direction 780 Description: Defined for extensibility. Specifies how long to carry 781 on the specified action. If absent, the default is for the 782 duration of the call. 783 Example: persistence="PT1H" 785 Name: datatype 786 Usage: Conditional 787 Type: token 788 Direction: Sent in either direction 789 Description: Mandatory with a "send-data" action within a 790 element that is not within a element. Specifies 791 the data block that the IVS is requested to transmit, using the 792 same identifier as in the 'purpose' attribute set in a Call-Info 793 header field to point to the data block. Permitted values are 794 contained in the 'Emergency Call Data Types' IANA registry 795 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 796 to support. 797 Example: datatype="eCall.MSD" 799 Name: supported-values 800 Usage: Conditional 801 Type: string 802 Direction: Sent from the IVS to the PSAP 803 Description: Defined for extensibility. Used in a element 804 that is a child of a element, this attribute lists 805 all supported values of the action type. Permitted values depend 806 on the action value. Multiple values are separated with a 807 semicolon. White space is ignored. Documents that make use of it 808 are expected to explain when it is required, the permitted values, 809 and how it is used. 811 Name: requested-state 812 Usage: Conditional 813 Type: token 814 Direction: Sent from the PSAP to the IVS 815 Description: Defined for extension. Indicates the requested state 816 of an element associated with the request type. Permitted values 817 depend on the request type. Documents that make use of it are 818 expected to explain when it is required, the permitted values, and 819 how it is used. 821 Name: element-id 822 Usage: Conditional 823 Type: token 824 Direction: Sent from the PSAP to the IVS 825 Description: Defined for extension. Identifies the element to be 826 acted on. Permitted values depend on the request type. Documents 827 that make use of it are expected to explain when it is required, 828 the permitted values, and how it is used. 830 9.1.3.2. Request Example 832 833 837 839 841 Figure 5: Request Example 843 10. Examples 845 Figure 6 illustrates an eCall. The call uses the request URI 846 'urn:service:sos.ecall.automatic' service URN and is recognized as an 847 eCall, and further as one that was invoked automatically by the IVS 848 due to a crash or other serious incident. In this example, the 849 originating network routes the call to an ESInet which routes the 850 call to the appropriate NG-eCall capable PSAP. The emergency call is 851 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 852 the entry point into the ESInet. The ESRP routes the call to a PSAP, 853 where it is received by a call taker. In deployments where there is 854 no ESInet, the originating network routes the call directly to the 855 appropriate NG-eCall capable PSAP, an illustration of which would be 856 identical to the one below except without an ESInet or ESRP. 858 +------------+ +---------------------------------------+ 859 | | | +-------+ | 860 | | | | PSAP2 | | 861 | | | +-------+ | 862 | | | | 863 | | | +------+ +-------+ | 864 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 865 | | | +------+ +-------+ | 866 | | | | 867 | | | +-------+ | 868 | | | | PSAP3 | | 869 | Originating| | +-------+ | 870 | Mobile | | | 871 | Network | | ESInet | 872 +------------+ +---------------------------------------+ 874 Figure 6: Example of NG-eCall Message Flow 876 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 877 for an updated MSD. The call flow shows the IVS initiating an 878 emergency call, including the MSD in the INVITE. The PSAP includes 879 in the 200 OK response a metadata/control object acknowledging 880 receipt of the MSD. During the call, the PSAP sends a request for an 881 MSD in an INFO request. The IVS sends the requested MSD in a new 882 INFO request. 884 IVS PSAP 885 |(1) INVITE (eCall MSD) | 886 |------------------------------------------->| 887 | | 888 |(2) 200 OK (eCall metadata [ack MSD]) | 889 |<-------------------------------------------| 890 | | 891 |(3) start media stream(s) | 892 |............................................| 893 | | 894 |(4) INFO (eCall metadata [request MSD]) | 895 |<-------------------------------------------| 896 | | 897 |(5) 200 OK | 898 |------------------------------------------->| 899 | | 900 |(6) INFO (eCall MSD) | 901 |------------------------------------------->| 902 | | 903 |(7) 200 OK | 904 |<-------------------------------------------| 905 | | 906 |(8) BYE | 907 |<-------------------------------------------| 908 | | 909 |(9) end media streams | 910 |............................................| 911 | | 912 |(10) 200 OK | 913 |------------------------------------------->| 915 Figure 7: NG-eCall Call Flow Illustration 917 The example, shown in Figure 8, illustrates a SIP eCall INVITE 918 request containing an MSD. For simplicity, the example does not show 919 all SIP headers, nor the SDP contents, nor does it show any 920 additional data blocks added by the IVS or the originating mobile 921 network. Because the MSD is encoded in ASN.1 PER, which is a binary 922 encoding, its contents cannot be included in a text document. 924 INVITE urn:service:sos.ecall.automatic SIP/2.0 925 To: urn:service:sos.ecall.automatic 926 From: ;tag=9fxced76sl 927 Call-ID: 3848276298220188511@atlanta.example.com 928 Geolocation: 929 Geolocation-Routing: no 930 Call-Info: ; 931 purpose=emergencyCallData.eCall.MSD 932 Accept: application/sdp, application/pidf+xml, 933 application/emergencyCallData.control+xml 934 CSeq: 31862 INVITE 935 Recv-Info: emergencyCallData.eCall.MSD 936 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 937 SUBSCRIBE, NOTIFY, UPDATE 938 Content-Type: multipart/mixed; boundary=boundary1 939 Content-Length: ... 941 --boundary1 942 Content-Type: application/sdp 944 ...Session Description Protocol (SDP) goes here... 946 --boundary1 947 Content-Type: application/pidf+xml 948 Content-ID: 949 Content-Disposition: by-reference;handling=optional 951 ...PIDF-LO goes in here 953 --boundary1 954 Content-Type: application/emergencyCallData.eCall.MSD+per 955 Content-ID: <1234567890@atlanta.example.com> 956 Content-Disposition: by-reference;handling=optional 958 ...MSD in ASN.1 PER encoding goes here... 960 --boundary1-- 962 Figure 8: SIP NG-eCall INVITE 964 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 965 the INVITE request of Figure 8, containing a control block 966 acknowledging successful receipt of the eCall MSD. (For simplicity, 967 the example does not show all SIP headers.) 968 SIP/2.0 200 OK 969 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 970 From: ;tag=9fxced76sl 971 Call-ID: 3848276298220188511@atlanta.example.com 972 Call-Info: ; 973 purpose=emergencyCallData.control 974 Accept: application/sdp, application/pidf+xml, 975 application/emergencyCallData.control+xml, 976 application/emergencyCallData.eCall.MSD+per 977 CSeq: 31862 INVITE 978 Recv-Info: emergencyCallData.eCall.MSD 979 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 980 SUBSCRIBE, NOTIFY, UPDATE 981 Content-Type: multipart/mixed; boundary=boundaryX 982 Content-Length: ... 984 --boundaryX 985 Content-Type: application/sdp 987 ...Session Description Protocol (SDP) goes here... 989 --boundaryX 990 Content-Type: application/emergencyCallData.control+xml 991 Content-ID: <2345678901@atlanta.example.com> 992 Content-Disposition: by-reference 994 995 999 1000 1002 --boundaryX-- 1004 Figure 9: 200 OK response to INVITE 1006 Figure 10 illustrates a SIP INFO request containing a metadata/ 1007 control block requesting an eCall MSD. (For simplicity, the example 1008 does not show all SIP headers.) 1009 INFO sip:+13145551111@example.com SIP/2.0 1010 To: ;tag=9fxced76sl 1011 From: Exemplar PSAP ;tag=8gydfe65t0 1012 Call-ID: 3848276298220188511@atlanta.example.com 1013 Call-Info: ; 1014 purpose=emergencyCallData.control 1015 CSeq: 41862 INFO 1016 Info-Package: emergencyCallData.eCall.MSD 1017 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1018 SUBSCRIBE, NOTIFY, UPDATE 1019 Content-Type: multipart/mixed; boundary=boundaryZZZ 1020 Content-Disposition: Info-Package 1021 Content-Length: ... 1023 --boundaryZZZ 1024 Content-Disposition: by-reference 1025 Content-Type: application/emergencyCallData.control+xml 1026 Content-ID: <3456789012@atlanta.example.com> 1028 1029 1033 1035 1036 --boundaryZZZ-- 1038 Figure 10: INFO requesting MSD 1040 Figure 11 illustrates a SIP INFO request containing an MSD. For 1041 simplicity, the example does not show all SIP headers. Because the 1042 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1043 cannot be included in a text document. 1045 INFO urn:service:sos.ecall.automatic SIP/2.0 1046 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1047 From: ;tag=9fxced76sl 1048 Call-ID: 3848276298220188511@atlanta.example.com 1049 Call-Info: ; 1050 purpose=emergencyCallData.eCall.MSD 1051 CSeq: 51862 INFO 1052 Info-Package: emergencyCallData.eCall.MSD 1053 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1054 SUBSCRIBE, NOTIFY, UPDATE 1055 Content-Type: multipart/mixed; boundary=boundaryLine 1056 Content-Disposition: Info-Package 1057 Content-Length: ... 1059 --boundaryLine 1060 Content-Type: application/emergencyCallData.eCall.MSD+per 1061 Content-ID: <4567890123@atlanta.example.com> 1062 Content-Disposition: by-reference 1064 ...MSD in ASN.1 PER encoding goes here... 1066 --boundaryLine-- 1068 Figure 11: INFO containing MSD 1070 11. Security Considerations 1072 The security considerations described in [RFC5069] (on marking and 1073 routing emergency calls) apply here. 1075 In addition to any network-provided location (which might be 1076 determined solely by the network, or in cooperation with or possibly 1077 entirely by the originating device), an eCall carries an IVS-supplied 1078 location within the MSD. This is likely to be useful to the PSAP, 1079 especially when no network-provided location is included, or when the 1080 two locations are independently determined. Even in situations where 1081 the network-supplied location is limited to the cell site, this can 1082 be useful as a sanity check on the device-supplied location contained 1083 in the MSD. 1085 The document [RFC7378] discusses trust issues regarding location 1086 provided by or determined in cooperation with end devices. 1088 Security considerations specific to the mechanism by which the PSAP 1089 sends acknowledgments and requests to the vehicle are discussed in 1090 the "Security Considerations" block of Section 14.5. Note that an 1091 attacker that has access to and is capable of generating a response 1092 to the initial INVITE request could generate a 600 (Busy Everywhere), 1093 486 (Busy Here), or 603 (Decline) response that includes a metadata/ 1094 control object containing a reference to the MSD in the initial 1095 INVITE and a "received=true" field, which could result in the IVS 1096 perceiving the PSAP to be overloaded and hence not attempting to 1097 reinitiate the call. The risk can be mitigated as discussed in the 1098 "Security Considerations" block of Section 14.5. 1100 Data received from external sources inherently carries implementation 1101 risks. For example, depending on the platform, buffer overflows can 1102 introduce remote code execution vulnerabilities, null characters can 1103 corrupt strings, numeric values used for internal calculations can 1104 result in underflow/overflow errors, malformed XML objects can expose 1105 parsing bugs, etc. Implementations need to be cognizant of the 1106 potential risks, observe best practices (which might include 1107 sufficiently capable static code analysis, fuzz testing, component 1108 isolation, avoiding use of unsafe coding techniques, third-party 1109 attack tests, signed software, over-the-air updates, etc.), and have 1110 multiple levels of protection. Implementors need to be aware that, 1111 potentially, the data objects described here and elsewhere (including 1112 the MSD and metadata/control objects) might be malformed, might 1113 contain unexpected characters, excessively long attribute values, 1114 elements, etc. 1116 The security considerations discussed in [RFC7852] apply here (see 1117 especially the discussion of TLS, TLS versions, cipher suites, and 1118 PKI). 1120 When vehicle data or control/metadata is contained in a signed or 1121 encrypted body part, the enclosing multipart (e.g., multipart/signed 1122 or multipart/encrypted) has the same Content-ID as the enclosed data 1123 part. This allows an entity to identify and access the data blocks 1124 it is interested in without having to dive deeply into the message 1125 structure or decrypt parts it is not interested in. (The 'purpose' 1126 parameter in a Call-Info header field identifies the data and 1127 contains a CID URL pointing to the data block in the body, which has 1128 a matching Content-ID body part header field). 1130 12. Privacy Considerations 1132 The privacy considerations discussed in [RFC7852] apply here. The 1133 MSD carries some identifying and personal information (mostly about 1134 the vehicle and less about the owner), as well as location 1135 information, and so needs to be protected against unauthorized 1136 disclosure. Local regulations may impose additional privacy 1137 protection requirements. 1139 Privacy considerations specific to the data structure containing 1140 vehicle information are discussed in the "Security Considerations" 1141 block of Section 14.4. 1143 Privacy considerations specific to the mechanism by which the PSAP 1144 sends acknowledgments and requests to the vehicle are discussed in 1145 the "Security Considerations" block of Section 14.5. 1147 13. XML Schema 1149 This section defines an XML schema for the control block. The text 1150 description of the control block in Section 9.1 is normative and 1151 supersedes any conflicting aspect of this schema. 1153 1154 1162 1164 1167 1168 1169 1170 1171 1173 1174 1175 1178 1179 1180 1181 1182 1184 1185 1186 1187 1188 1190 1191 1194 1197 1199 1200 1201 conditionally mandatory 1202 when @success="false" 1203 to indicate reason code 1204 for a failure 1205 1206 1207 1208 1210 1212 1213 1214 1217 1218 1221 1223 1224 1225 1226 1228 1229 1230 1231 1232 1236 1239 1240 1241 1242 1243 1245 1246 1247 1248 1249 1252 1253 1255 1256 1258 1259 1261 1262 1264 1265 1266 1267 1269 1271 Figure 12: Control Block Schema 1273 14. IANA Considerations 1275 14.1. The EmergencyCallData Media Subtree 1277 This document establishes the "EmergencyCallData" media (MIME) 1278 subtype tree, a new media subtree rooted at "application/ 1279 EmergencyCallData". This subtree is used only for content associated 1280 with emergency communications. New subtypes in this subtree follow 1281 the rules specified in Section 3.1 of [RFC6838], with the additional 1282 restriction that the standards-related organization MUST be 1283 responsible for some aspect of emergency communications. 1285 This subtree initially contains the following subtypes (defined here 1286 or in [RFC7852]): 1288 emergencyCallData.control+xml 1289 EmergencyCallData.Comment+xml 1290 EmergencyCallData.DeviceInfo+xml 1291 EmergencyCallData.MSD+per 1292 EmergencyCallData.ProviderInfo+xml 1293 EmergencyCallData.ServiceInfo+xml 1294 EmergencyCallData.SubscriberInfo+xml 1296 14.2. Service URN Registrations 1298 IANA is requested to register the URN 'urn:service:sos.ecall' under 1299 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1301 This service requests resources associated with an emergency call 1302 placed by an in-vehicle system, carrying a standardized set of data 1303 related to the vehicle and incident. Two sub-services are registered 1304 as well: 1306 urn:service:sos.ecall.manual 1308 Used with an eCall invoked due to manual interaction by a vehicle 1309 occupant. 1311 urn:service:sos.ecall.automatic 1313 Used with an eCall invoked automatically, for example, due to a 1314 crash or other serious incident. 1316 IANA is also requested to register the URN 1317 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1318 defined in Setcion 17.2 of [RFC6881]. This service requests 1319 resources associated with a test (non-emergency) call placed by an 1320 in-vehicle system. See Section 8 for more information on the test 1321 eCall request URN. 1323 14.3. MIME Structured Syntax Suffix Registration for +PER 1325 IANA is requested to add "+PER" to the as a media type structured 1326 syntax suffix in the Structured Syntax Suffix registry. The ITU 1327 defined the Packed Encoding Rules (PER) transfer syntax in 1328 [ITU.X691]. The suffix "+per" MAY be used with any media type whose 1329 representation follows the PER transfer syntax. The media type 1330 structured syntax suffix registration form for +per follows: 1332 Name: Packed Encoding Rules (PER) transfer syntax 1334 +suffix: +per 1336 References: [ITU.X691] 1338 Encoding considerations: PER is a binary encoding 1340 Interoperability considerations: none identified 1342 Fragment identifier considerations: 1344 At publication of this document, there is no fragment 1345 identification syntax defined for +per. 1347 The syntax and semantics for fragment identifiers for a 1348 specific "xxx/yyy+per" SHOULD be processed as follows: 1350 For cases defined in +per, where the fragment identifier 1351 resolves per the +per rules, then process as specified in +per. 1353 For cases defined in +per, where the fragment identifier does 1354 not resolve per the +per rules, then process as specified in 1355 "xxx/yyy+per". 1357 For cases not defined in +per, then process as specified in 1358 "xxx/yyy+per". 1360 Security considerations: 1362 Because of the binary and structured nature of PER, it is not 1363 difficult to construct malicious content that could cause 1364 buffer overruns, stack overflows, and other attack vectors. 1366 Implementors should be aware of these issues and take 1367 appropriate measures to guard against buffer overruns, stack 1368 overflows, and related attack vectors. 1370 Contact: Apps Area Working Group (apps-discuss@ietf.org) 1372 Author/Change controller: 1374 The Apps Area Working Group. IESG has change control over this 1375 registration. 1377 14.4. MIME Media Type Registration for 'application/ 1378 emergencyCallData.eCall.MSD+per' 1380 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1381 as a MIME media type, with a reference to this document, in 1382 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1383 RFC 7303 [RFC7303]. 1385 MIME media type name: application 1387 MIME subtype name: emergencyCallData.eCall.MSD+per 1389 Mandatory parameters: none 1391 Optional parameters: none 1393 Encoding scheme: binary 1395 Encoding considerations: Uses ASN.1 PER, which is a binary 1396 encoding; when transported in SIP, binary content transfer 1397 encoding is used. 1399 Security considerations: This media type is designed to carry 1400 vehicle and incident-related data during an emergency call. This 1401 data contains personal information including vehicle VIN, 1402 location, direction, etc. Appropriate precautions need to be 1403 taken to limit unauthorized access, inappropriate disclosure to 1404 third parties, and eavesdropping of this information. Sections 9 1405 and Section 10 of [RFC7852] contain more discussion. 1407 Interoperability considerations: None 1409 Published specification: Annex A of EN 15722 [msd] 1411 Applications which use this media type: Pan-European eCall 1412 compliant systems 1414 Additional information: None 1416 Magic Number: None 1418 File Extension: None 1420 Macintosh file type code: 'BINA' 1422 Person and email address for further information: Randall Gellens, 1423 rg+ietf@randy.pensive.org 1424 Intended usage: LIMITED USE 1426 Author: The MSD specification was produced by the European 1427 Committee For Standardization (CEN). For contact information, 1428 please see . 1430 Change controller: The European Committee For Standardization 1431 (CEN) 1433 14.5. MIME Media Type Registration for 'application/ 1434 emergencyCallData.control+xml' 1436 IANA is requested to add application/emergencyCallData.control+xml as 1437 a MIME media type, with a reference to this document, in accordance 1438 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1439 [RFC7303]. 1441 MIME media type name: application 1443 MIME subtype name: emergencyCallData.control+xml 1445 Mandatory parameters: none 1447 Optional parameters: charset 1449 Indicates the character encoding of the XML content. 1451 Encoding considerations: Uses XML, which can employ 8-bit 1452 characters, depending on the character encoding used. See 1453 Section 3.2 of RFC 7303 [RFC7303]. 1455 Security considerations: 1457 This media type carries metadata and control information and 1458 requests, such as from a Public Safety Answering Point (PSAP) 1459 to an In-Vehicle System (IVS) during an emergency call. 1461 Metadata (such as an acknowledgment that data sent by the IVS 1462 to the PSAP was successfully received) has limited privacy and 1463 security implications. Control information (such as requests 1464 from the PSAP that the vehicle perform an action) has some 1465 privacy and security implications. The privacy concern arises 1466 from the ability to request the vehicle to transmit a data set, 1467 which as described in Section 14.4, can contain personal 1468 information. The security concern is the ability to request 1469 the vehicle to perform an action. Control information needs to 1470 originate only from a PSAP or other emergency services 1471 provider, and not be modified en-route. The level of integrity 1472 of the cellular network over which the emergency call is placed 1473 is a consideration: when the IVS initiates an eCall over a 1474 cellular network, in most cases it relies on the MNO to route 1475 the call to a PSAP. (Calls placed using other means, such as 1476 Wi-Fi or over-the-top services, generally incur somewhat higher 1477 levels of risk than calls placed "natively" using cellular 1478 networks.) A call-back from a PSAP merits additional 1479 consideration, since current mechanisms are not ideal for 1480 verifying that such a call is indeed a call-back from a PSAP in 1481 response to an emergency call placed by the IVS. See the 1482 discussion in Section 11 and the PSAP Callback document 1483 [RFC7090]. 1485 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1487 Interoperability considerations: None 1489 Published specification: This document 1491 Applications which use this media type: Pan-European eCall 1492 compliant systems 1494 Additional information: None 1496 Magic Number: None 1498 File Extension: .xml 1500 Macintosh file type code: 'TEXT' 1502 Person and email address for further information: Randall Gellens, 1503 rg+ietf@randy.pensive.org 1505 Intended usage: LIMITED USE 1507 Author: The IETF ECRIT WG. 1509 Change controller: The IETF ECRIT WG. 1511 14.6. Registration of the 'eCall.MSD' entry in the Emergency Call 1512 Additional Data Types registry 1514 This specification requests IANA to add the 'eCall.MSD' entry to the 1515 Emergency Call Additional Data Types registry, with a reference to 1516 this document; the 'Data About' value is 'The Call'. 1518 14.7. Registration of the 'control' entry in the Emergency Call 1519 Additional Data Types registry 1521 This specification requests IANA to add the 'control' entry to the 1522 Emergency Call Additional Data Types registry, with a reference to 1523 this document; the 'Data About' value is 'The Call'. 1525 14.8. URN Sub-Namespace Registration 1527 14.8.1. Registration for urn:ietf:params:xml:ns:eCall 1529 This section registers a new XML namespace, as per the guidelines in 1530 RFC 3688 [RFC3688]. 1532 URI: urn:ietf:params:xml:ns:eCall 1534 Registrant Contact: IETF, ECRIT working group, , as 1535 delegated by the IESG . 1537 XML: 1539 BEGIN 1540 1541 1543 1544 1545 1547 Namespace for eCall Data 1548 1549 1550

Namespace for eCall Data

1551

See [TBD: This document].

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

Namespace for eCall Data

1580

Control Block

1581

See [TBD: This document].

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