idnits 2.17.00 (12 Aug 2021) /tmp/idnits52301/draft-ietf-ecrit-ecall-25.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 (February 6, 2017) is 1929 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: August 10, 2017 Individual 6 February 6, 2017 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-25.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 August 10, 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 103 urn:ietf:params:xml:ns:EmergencyCallData:control . . 34 104 14.9. Registry Creation . . . . . . . . . . . . . . . . . . . 34 105 14.9.1. Emergency Call Action Registry . . . . . . . . . . . 35 106 14.9.2. Emergency Call Action Failure Reason Registry . . . 35 107 14.10. The emergencyCallData.eCall.MSD INFO package . . . . . . 36 108 14.10.1. Overall Description . . . . . . . . . . . . . . . . 37 109 14.10.2. Applicability . . . . . . . . . . . . . . . . . . . 37 110 14.10.3. Info Package Name . . . . . . . . . . . . . . . . . 38 111 14.10.4. Info Package Parameters . . . . . . . . . . . . . . 38 112 14.10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 38 113 14.10.6. INFO Request Body Parts . . . . . . . . . . . . . . 38 114 14.10.7. Info Package Usage Restrictions . . . . . . . . . . 38 115 14.10.8. Rate of INFO Requests . . . . . . . . . . . . . . . 38 116 14.10.9. Info Package Security Considerations . . . . . . . 39 117 14.10.10. Implementation Details . . . . . . . . . . . . . . 39 118 14.10.11. Examples . . . . . . . . . . . . . . . . . . . . . 39 119 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 120 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 121 17. Changes from Previous Versions . . . . . . . . . . . . . . . 39 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 . . . . . . 40 124 17.3. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 40 125 17.4. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 40 126 17.5. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 40 127 17.6. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 40 128 17.7. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 40 129 17.8. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 40 130 17.9. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 41 131 17.10. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 41 132 17.11. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 41 133 17.12. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 41 134 17.13. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 42 135 17.14. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 42 136 17.15. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 42 137 17.16. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 42 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 . . . . . . 43 140 17.19. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 43 141 17.20. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 43 142 17.21. Changes from draft-gellens-02 to -03 . . . . . . . . . . 44 143 17.22. Changes from draft-gellens-01 to -02 . . . . . . . . . . 44 144 17.23. Changes from draft-gellens-00 to -01 . . . . . . . . . . 44 145 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 146 18.1. Normative References . . . . . . . . . . . . . . . . . . 44 147 18.2. Informative references . . . . . . . . . . . . . . . . . 45 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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 adds 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. These are registered in Section 14.2 475 Call routing is outside the scope of this document. 477 8. Test Calls 479 eCall requires the ability to place test calls (see [TS22.101] clause 480 10.7 and [EN_16062] clause 7.2.2). These are calls that are 481 recognized and treated to some extent as eCalls but are not given 482 emergency call treatment and are not handled by call takers. The 483 specific handling of test eCalls is not itself standardized; 484 typically, the test call facility allows the IVS or user to verify 485 that an eCall can be successfully established with voice 486 communication. The IVS might also be able to verify that the MSD was 487 successfully received. 489 A service URN starting with "test." indicates a test call. For 490 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 491 This functionality is defined in [RFC6881]. 493 This document specifies "urn:service:test.sos.ecall" for eCall test 494 calls. This is registered in Section 14.2 496 The circuit switched eCall test call facility is a non-emergency 497 number so does not get treated as an emergency call. For NG-eCall, 498 MNOs, emergency authorities, and PSAPs can determine how to treat a 499 vehicle call requesting the "test" service URN so that the desired 500 functionality is tested, but this is outside the scope of this 501 document. 503 9. The Metadata/Control Object 505 eCall requires the ability for the PSAP to acknowledge successful 506 receipt of an MSD sent by the IVS, and for the PSAP to request that 507 the IVS send an MSD (e.g., the call taker can initiate a request for 508 a new MSD to see if there have been changes in the vehicle's state, 509 e.g., location, direction, number of fastened seatbelts). 511 This document defines a block of metadata/control data as an XML 512 structure containing elements used for eCall and other related 513 emergency call systems and extension points. (This metadata/control 514 block is in effect a high-level protocol between the PSAP and IVS.) 515 When the PSAP sends a metadata/control block in response to data sent 516 by the IVS in a SIP request other than INFO (e.g., the MSD in the 517 initial INVITE), the metadata/control block is sent in the SIP 518 response to that request (e.g., the response to the INVITE request). 519 When the PSAP sends a control block in other circumstances (e.g., 520 mid-call), the control block is transmitted from the PSAP to the IVS 521 in a SIP INFO request within the established dialog. The IVS sends 522 the requested data (the MSD) in a new SIP INFO request (per 524 [RFC6086]). This mechanism flexibly allows the PSAP to send eCall- 525 specific data to the IVS and the IVS to respond. SIP INFO requests 526 are sent using an appropriate SIP INFO Package. See Section 6 for 527 more information on sending a metadata/control block within a SIP 528 message. See Section 14.10 for information about the use of SIP INFO 529 requests to carry data within an eCall. 531 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 532 initial INVITE), the PSAP sends a metadata/control block indicating 533 successful/unsuccessful receipt of the MSD in the SIP response to the 534 request. This also informs the IVS that an NG-eCall is in operation. 535 If the IVS receives a SIP final response without the metadata/control 536 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 537 some part of the call is being handled as a legacy call). When the 538 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 539 receipt of a SIP INFO request containing a metadata/control block 540 requesting an MSD), the PSAP does not send a metadata/control block 541 indicating successful or unsuccessful receipt of the MSD. (Normal 542 SIP retransmission handles non-receipt of requested data; note that, 543 per [RFC6086], a 200 OK response to a SIP INFO request indicates only 544 that the receiver has successfully received and accepted the SIP INFO 545 request, it says nothing about the acceptability of the payload.) If 546 the IVS receives a request to send an MSD but it is unable to do so 547 for any reason, the IVS sends a metadata/control object acknowledging 548 the request and containing "success=false" and "reason" set to an 549 appropriate code. 551 This provides flexibility to handle various circumstances. For 552 example, if a PSAP is unable to accept an eCall (e.g., due to 553 overload or too many calls from the same location), it can reject the 554 INVITE. Since a metadata/control object is also included in the SIP 555 response that rejects the call, the IVS knows if the PSAP received 556 the MSD, and can inform the vehicle occupants that the PSAP 557 successfully received the vehicle location and information but can't 558 talk to the occupants at that time. Especially for SIP response 559 codes that indicate an inability to conduct a call (as opposed to a 560 technical inability to process the request), the IVS can also 561 determine that the call was successful on a technical level (e.g., 562 not helpful to retry as circuit-switched). (Note that there could be 563 edge cases where the PSAP response is not received by the IVS, e.g., 564 if an intermediary sends a CANCEL, and an error response is forwarded 565 towards the IVS before the error response from the PSAP is received, 566 the response will be dropped, but these are unlikely to occur here.) 568 The metadata/control block is carried in the MIME type 'application/ 569 emergencyCallData.control+xml'. 571 The metadata/control block is designed for use with pan-European 572 eCall and also eCall-like systems (i.e., in other regions), and has 573 extension points. Note that eCall-like systems might define their 574 own vehicle data blocks, and so might need to register a new INFO 575 package to accommodate the new data MIME media type and the metadata/ 576 control object. 578 9.1. The Control Block 580 The control block is an XML data structure allowing for 581 acknowledgments, requests, and capabilities information. It is 582 carried in a body part with a specific MIME media type. Three 583 elements are defined for use within a control block: 585 ack Acknowledges receipt of data or a request. 587 capabilities Used in a control block sent from the IVS to the PSAP 588 (e.g., in the initial INVITE) to inform the PSAP of the 589 vehicle capabilities. Child elements contain all 590 actions and data types supported by the vehicle. It is 591 OPTIONAL for the IVS to send this block. Omitting the 592 block indicates that the IVS supports only the 593 mandatory functionality defined in this document. 595 request Used in a control block sent by the PSAP to the IVS, to 596 request the vehicle to perform an action. 598 The element indicates the object being acknowledged and reports 599 success or failure. 601 The element contains attributes to indicate the request and 602 to supply related information. The 'action' attribute is mandatory 603 and indicates the specific action. An IANA registry is created in 604 Section 14.9.1 to contain the allowed values. 606 The element has child elements to indicate 607 the actions supported by the IVS. 609 9.1.1. The element 611 The element acknowledges receipt of an eCall data object or 612 request. An element references the Content-ID of the object 613 being acknowledged. The PSAP MUST send an element 614 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 615 the INVITE); this element indicates if the PSAP considers the 616 MSD successfully received or not. An element is not sent for a 617 element. 619 The element has the following attributes: 621 9.1.1.1. Attributes of the element 623 The element has the following attributes: 625 Name: ref 626 Usage: Mandatory 627 Type: anyURI 628 Direction: Sent in either direction 629 Description: References the Content-ID of the body part being 630 acknowledged. 631 Example: 633 Name: received 634 Usage: Conditional: mandatory in an element sent by a PSAP 635 Type: Boolean 636 Direction: In this document, sent from the PSAP to the IVS 637 Description: Indicates if the referenced object was considered 638 successfully received or not. 639 Example: 641 9.1.1.2. Child Element of the element 643 For extensibility, the element has the following child element: 645 Name: actionResult 646 Usage: Optional 647 Direction: Sent from the IVS to the PSAP 648 Description: An element indicates the result of an 649 action (other than a successfully executed 'send-data' action). 650 The element contains an element for each 651 element that is not a successfully executed 'send-data' 652 action. The element has the following attributes: 654 Name: action 655 Usage: Mandatory 656 Type: token 657 Description: Contains the value of the 'action' attribute of the 658 element 660 Name: success 661 Usage: Mandatory 662 Type: Boolean 663 Description: Indicates if the action was successfully 664 accomplished 666 Name: reason 667 Usage: Conditional 668 Type: token 669 Description: Used when 'success' is "false", this attribute 670 contains a reason code for a failure. A registry for reason 671 codes is defined in Section 14.9.2. The initial values are: 672 damaged (required components are damaged), data-unsupported 673 (the data item referenced in a 'send-data' request is not 674 supported), security-failure (the authenticity of the request 675 or the authority of the requestor could not be verified), 676 unable (a generic error for use when no other code is 677 appropriate), and unsupported (the 'action' value is not 678 supported). 680 Name: details 681 Usage: optional 682 Type: string 683 Description: Contains further explanation of the circumstances of 684 a success or failure. The contents are implementation-specific 685 and human-readable. This is intended for internal use and 686 troubleshooting, not for display to vehicle occupants. 688 9.1.1.3. Ack Examples 690 691 695 697 699 Figure 3: Ack Example from PSAP to IVS 701 9.1.2. The element 703 The element is transmitted by the IVS to indicate to 704 the PSAP its capabilities. No attributes for this element are 705 currently defined. The following child elements are defined: 707 9.1.2.1. Child Element of the element 709 The element has the following child element: 711 Name: request 712 Usage: Mandatory 713 Description: The element contains a child 714 element per action supported by the vehicle. 716 Example: 718 720 722 724 It is OPTIONAL for the IVS to support the element. If 725 the IVS does not send a element, this indicates that 726 the only action supported by the IVS is 'send-data' with 727 'datatype' set to 'eCall.MSD'. 729 9.1.2.2. Capabilities Example 731 732 735 736 737 739 741 Figure 4: Capabilities Example 743 9.1.3. The element 745 A element appears one or more times on its own or as a 746 child of a element. It allows the PSAP to request 747 that the IVS perform an action. The only action that MUST be 748 supported is to send an MSD. The following attributes and child 749 elements are defined: 751 9.1.3.1. Attributes of the element 753 The element has the following attributes: 755 Name: action 756 Usage: Mandatory 757 Type: token 758 Direction: Sent in either direction 759 Description: Identifies the action that the vehicle is requested to 760 perform (in a element within a element, 761 indicates an action that the vehicle is capable of performing). 762 An IANA registry is established in Section 14.9.1 to contain the 763 allowed values. 764 Example: action="send-data" 766 Name: int-id 767 Usage: Conditional 768 Type: int 769 Direction: Sent in either direction 770 Description: Defined for extensibility. Documents that make use of 771 it are expected to explain when it is required and how it is used. 772 Example: int-id="3" 774 Name: persistence 775 Usage: Optional 776 Type: xs:duration 777 Direction: Sent in either direction 778 Description: Defined for extensibility. Specifies how long to carry 779 on the specified action. If absent, the default is for the 780 duration of the call. 781 Example: persistence="PT1H" 783 Name: datatype 784 Usage: Conditional 785 Type: token 786 Direction: Sent in either direction 787 Description: Mandatory with a "send-data" action within a 788 element that is not within a element. Specifies 789 the data block that the IVS is requested to transmit, using the 790 same identifier as in the 'purpose' attribute set in a Call-Info 791 header field to point to the data block. Permitted values are 792 contained in the 'Emergency Call Data Types' IANA registry 793 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 794 to support. 795 Example: datatype="eCall.MSD" 797 Name: supported-values 798 Usage: Conditional 799 Type: string 800 Direction: Sent from the IVS to the PSAP 801 Description: Defined for extensibility. Used in a element 802 that is a child of a element, this attribute lists 803 all supported values of the action type. Permitted values depend 804 on the action value. Multiple values are separated with a 805 semicolon. White space is ignored. Documents that make use of it 806 are expected to explain when it is required, the permitted values, 807 and how it is used. 809 Name: requested-state 810 Usage: Conditional 811 Type: token 812 Direction: Sent from the PSAP to the IVS 813 Description: Defined for extension. Indicates the requested state 814 of an element associated with the request type. Permitted values 815 depend on the request type. Documents that make use of it are 816 expected to explain when it is required, the permitted values, and 817 how it is used. 819 Name: element-id 820 Usage: Conditional 821 Type: token 822 Direction: Sent from the PSAP to the IVS 823 Description: Defined for extension. Identifies the element to be 824 acted on. Permitted values depend on the request type. Documents 825 that make use of it are expected to explain when it is required, 826 the permitted values, and how it is used. 828 9.1.3.2. Request Example 830 831 834 836 838 Figure 5: Request Example 840 10. Examples 842 Figure 6 illustrates an eCall. The call uses the request URI 843 'urn:service:sos.ecall.automatic' service URN and is recognized as an 844 eCall, and further as one that was invoked automatically by the IVS 845 due to a crash or other serious incident. In this example, the 846 originating network routes the call to an ESInet which routes the 847 call to the appropriate NG-eCall capable PSAP. The emergency call is 848 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 849 the entry point into the ESInet. The ESRP routes the call to a PSAP, 850 where it is received by a call taker. In deployments where there is 851 no ESInet, the originating network routes the call directly to the 852 appropriate NG-eCall capable PSAP, an illustration of which would be 853 identical to the one below except without an ESInet or ESRP. 855 +------------+ +---------------------------------------+ 856 | | | +-------+ | 857 | | | | PSAP2 | | 858 | | | +-------+ | 859 | | | | 860 | | | +------+ +-------+ | 861 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 862 | | | +------+ +-------+ | 863 | | | | 864 | | | +-------+ | 865 | | | | PSAP3 | | 866 | Originating| | +-------+ | 867 | Mobile | | | 868 | Network | | ESInet | 869 +------------+ +---------------------------------------+ 871 Figure 6: Example of NG-eCall Message Flow 873 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 874 for an updated MSD. The call flow shows the IVS initiating an 875 emergency call, including the MSD in the INVITE. The PSAP includes 876 in the 200 OK response a metadata/control object acknowledging 877 receipt of the MSD. During the call, the PSAP sends a request for an 878 MSD in an INFO request. The IVS sends the requested MSD in a new 879 INFO request. 881 IVS PSAP 882 |(1) INVITE (eCall MSD) | 883 |------------------------------------------->| 884 | | 885 |(2) 200 OK (eCall metadata [ack MSD]) | 886 |<-------------------------------------------| 887 | | 888 |(3) start media stream(s) | 889 |............................................| 890 | | 891 |(4) INFO (eCall metadata [request MSD]) | 892 |<-------------------------------------------| 893 | | 894 |(5) 200 OK | 895 |------------------------------------------->| 896 | | 897 |(6) INFO (eCall MSD) | 898 |------------------------------------------->| 899 | | 900 |(7) 200 OK | 901 |<-------------------------------------------| 902 | | 903 |(8) BYE | 904 |<-------------------------------------------| 905 | | 906 |(9) end media streams | 907 |............................................| 908 | | 909 |(10) 200 OK | 910 |------------------------------------------->| 912 Figure 7: NG-eCall Call Flow Illustration 914 The example, shown in Figure 8, illustrates a SIP eCall INVITE 915 request containing an MSD. For simplicity, the example does not show 916 all SIP headers, nor the SDP contents, nor does it show any 917 additional data blocks added by the IVS or the originating mobile 918 network. Because the MSD is encoded in ASN.1 PER, which is a binary 919 encoding, its contents cannot be included in a text document. 921 INVITE urn:service:sos.ecall.automatic SIP/2.0 922 To: urn:service:sos.ecall.automatic 923 From: ;tag=9fxced76sl 924 Call-ID: 3848276298220188511@atlanta.example.com 925 Geolocation: 926 Geolocation-Routing: no 927 Call-Info: ; 928 purpose=emergencyCallData.eCall.MSD 929 Accept: application/sdp, application/pidf+xml, 930 application/emergencyCallData.control+xml 931 CSeq: 31862 INVITE 932 Recv-Info: emergencyCallData.eCall.MSD 933 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 934 SUBSCRIBE, NOTIFY, UPDATE 935 Content-Type: multipart/mixed; boundary=boundary1 936 Content-Length: ... 938 --boundary1 939 Content-Type: application/sdp 941 ...Session Description Protocol (SDP) goes here... 943 --boundary1 944 Content-Type: application/pidf+xml 945 Content-ID: 946 Content-Disposition: by-reference;handling=optional 948 ...PIDF-LO goes in here 950 --boundary1 951 Content-Type: application/emergencyCallData.eCall.MSD+per 952 Content-ID: <1234567890@atlanta.example.com> 953 Content-Disposition: by-reference;handling=optional 955 ...MSD in ASN.1 PER encoding goes here... 957 --boundary1-- 959 Figure 8: SIP NG-eCall INVITE 961 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 962 the INVITE request of Figure 8, containing a control block 963 acknowledging successful receipt of the eCall MSD. (For simplicity, 964 the example does not show all SIP headers.) 965 SIP/2.0 200 OK 966 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 967 From: ;tag=9fxced76sl 968 Call-ID: 3848276298220188511@atlanta.example.com 969 Call-Info: ; 970 purpose=emergencyCallData.control 971 Accept: application/sdp, application/pidf+xml, 972 application/emergencyCallData.control+xml, 973 application/emergencyCallData.eCall.MSD+per 974 CSeq: 31862 INVITE 975 Recv-Info: emergencyCallData.eCall.MSD 976 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 977 SUBSCRIBE, NOTIFY, UPDATE 978 Content-Type: multipart/mixed; boundary=boundaryX 979 Content-Length: ... 981 --boundaryX 982 Content-Type: application/sdp 984 ...Session Description Protocol (SDP) goes here... 986 --boundaryX 987 Content-Type: application/emergencyCallData.control+xml 988 Content-ID: <2345678901@atlanta.example.com> 989 Content-Disposition: by-reference 991 992 995 996 998 --boundaryX-- 1000 Figure 9: 200 OK response to INVITE 1002 Figure 10 illustrates a SIP INFO request containing a metadata/ 1003 control block requesting an eCall MSD. (For simplicity, the example 1004 does not show all SIP headers.) 1005 INFO sip:+13145551111@example.com SIP/2.0 1006 To: ;tag=9fxced76sl 1007 From: Exemplar PSAP ;tag=8gydfe65t0 1008 Call-ID: 3848276298220188511@atlanta.example.com 1009 Call-Info: ; 1010 purpose=emergencyCallData.control 1011 CSeq: 41862 INFO 1012 Info-Package: emergencyCallData.eCall.MSD 1013 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1014 SUBSCRIBE, NOTIFY, UPDATE 1015 Content-Type: multipart/mixed; boundary=boundaryZZZ 1016 Content-Disposition: Info-Package 1017 Content-Length: ... 1019 --boundaryZZZ 1020 Content-Disposition: by-reference 1021 Content-Type: application/emergencyCallData.control+xml 1022 Content-ID: <3456789012@atlanta.example.com> 1024 1025 1028 1030 1031 --boundaryZZZ-- 1033 Figure 10: INFO requesting MSD 1035 Figure 11 illustrates a SIP INFO request containing an MSD. For 1036 simplicity, the example does not show all SIP headers. Because the 1037 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1038 cannot be included in a text document. 1040 INFO urn:service:sos.ecall.automatic SIP/2.0 1041 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1042 From: ;tag=9fxced76sl 1043 Call-ID: 3848276298220188511@atlanta.example.com 1044 Call-Info: ; 1045 purpose=emergencyCallData.eCall.MSD 1046 CSeq: 51862 INFO 1047 Info-Package: emergencyCallData.eCall.MSD 1048 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1049 SUBSCRIBE, NOTIFY, UPDATE 1050 Content-Type: multipart/mixed; boundary=boundaryLine 1051 Content-Disposition: Info-Package 1052 Content-Length: ... 1054 --boundaryLine 1055 Content-Type: application/emergencyCallData.eCall.MSD+per 1056 Content-ID: <4567890123@atlanta.example.com> 1057 Content-Disposition: by-reference 1059 ...MSD in ASN.1 PER encoding goes here... 1061 --boundaryLine-- 1063 Figure 11: INFO containing MSD 1065 11. Security Considerations 1067 The security considerations described in [RFC5069] (on marking and 1068 routing emergency calls) apply here. 1070 In addition to any network-provided location (which might be 1071 determined solely by the network, or in cooperation with or possibly 1072 entirely by the originating device), an eCall carries an IVS-supplied 1073 location within the MSD. This is likely to be useful to the PSAP, 1074 especially when no network-provided location is included, or when the 1075 two locations are independently determined. Even in situations where 1076 the network-supplied location is limited to the cell site, this can 1077 be useful as a sanity check on the device-supplied location contained 1078 in the MSD. 1080 The document [RFC7378] discusses trust issues regarding location 1081 provided by or determined in cooperation with end devices. 1083 Security considerations specific to the mechanism by which the PSAP 1084 sends acknowledgments and requests to the vehicle are discussed in 1085 the "Security Considerations" block of Section 14.5. Note that an 1086 attacker that has access to and is capable of generating a response 1087 to the initial INVITE request could generate a 600 (Busy Everywhere), 1088 486 (Busy Here), or 603 (Decline) response that includes a metadata/ 1089 control object containing a reference to the MSD in the initial 1090 INVITE and a "received=true" field, which could result in the IVS 1091 perceiving the PSAP to be overloaded and hence not attempting to 1092 reinitiate the call. The risk can be mitigated as discussed in the 1093 "Security Considerations" block of Section 14.5. 1095 Data received from external sources inherently carries implementation 1096 risks. For example, depending on the platform, buffer overflows can 1097 introduce remote code execution vulnerabilities, null characters can 1098 corrupt strings, numeric values used for internal calculations can 1099 result in underflow/overflow errors, malformed XML objects can expose 1100 parsing bugs, etc. Implementations need to be cognizant of the 1101 potential risks, observe best practices (which might include 1102 sufficiently capable static code analysis, fuzz testing, component 1103 isolation, avoiding use of unsafe coding techniques, third-party 1104 attack tests, signed software, over-the-air updates, etc.), and have 1105 multiple levels of protection. Implementors need to be aware that, 1106 potentially, the data objects described here and elsewhere (including 1107 the MSD and metadata/control objects) might be malformed, might 1108 contain unexpected characters, excessively long attribute values, 1109 elements, etc. 1111 The security considerations discussed in [RFC7852] apply here (see 1112 especially the discussion of TLS, TLS versions, cipher suites, and 1113 PKI). 1115 When vehicle data or control/metadata is contained in a signed or 1116 encrypted body part, the enclosing multipart (e.g., multipart/signed 1117 or multipart/encrypted) has the same Content-ID as the enclosed data 1118 part. This allows an entity to identify and access the data blocks 1119 it is interested in without having to dive deeply into the message 1120 structure or decrypt parts it is not interested in. (The 'purpose' 1121 parameter in a Call-Info header field identifies the data and 1122 contains a CID URL pointing to the data block in the body, which has 1123 a matching Content-ID body part header field). 1125 12. Privacy Considerations 1127 The privacy considerations discussed in [RFC7852] apply here. The 1128 MSD carries some identifying and personal information (mostly about 1129 the vehicle and less about the owner), as well as location 1130 information, and so needs to be protected against unauthorized 1131 disclosure. Local regulations may impose additional privacy 1132 protection requirements. 1134 Privacy considerations specific to the data structure containing 1135 vehicle information are discussed in the "Security Considerations" 1136 block of Section 14.4. 1138 Privacy considerations specific to the mechanism by which the PSAP 1139 sends acknowledgments and requests to the vehicle are discussed in 1140 the "Security Considerations" block of Section 14.5. 1142 13. XML Schema 1144 This section defines an XML schema for the control block. The text 1145 description of the control block in Section 9.1 is normative and 1146 supersedes any conflicting aspect of this schema. 1148 1149 1157 1159 1162 1163 1164 1165 1166 1168 1169 1170 1173 1174 1175 1176 1177 1179 1180 1181 1182 1183 1185 1186 1189 1192 1194 1195 1196 conditionally mandatory 1197 when @success="false" 1198 to indicate reason code 1199 for a failure 1200 1201 1202 1203 1205 1207 1208 1209 1212 1213 1216 1218 1219 1220 1221 1223 1224 1225 1226 1227 1231 1234 1235 1236 1237 1238 1240 1241 1242 1243 1244 1247 1248 1250 1251 1253 1254 1256 1257 1259 1260 1261 1262 1264 1266 Figure 12: Control Block Schema 1268 14. IANA Considerations 1270 14.1. The EmergencyCallData Media Subtree 1272 This document establishes the "EmergencyCallData" media (MIME) 1273 subtype tree, a new media subtree rooted at "application/ 1274 EmergencyCallData". This subtree is used only for content associated 1275 with emergency communications. New subtypes in this subtree follow 1276 the rules specified in Section 3.1 of [RFC6838], with the additional 1277 restriction that the standards-related organization MUST be 1278 responsible for some aspect of emergency communications. 1280 This subtree initially contains the following subtypes (defined here 1281 or in [RFC7852]): 1283 emergencyCallData.control+xml 1284 EmergencyCallData.Comment+xml 1285 EmergencyCallData.DeviceInfo+xml 1286 EmergencyCallData.MSD+per 1287 EmergencyCallData.ProviderInfo+xml 1288 EmergencyCallData.ServiceInfo+xml 1289 EmergencyCallData.SubscriberInfo+xml 1291 14.2. Service URN Registrations 1293 IANA is requested to register the URN 'urn:service:sos.ecall' under 1294 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1296 This service requests resources associated with an emergency call 1297 placed by an in-vehicle system, carrying a standardized set of data 1298 related to the vehicle and incident. Two sub-services are registered 1299 as well: 1301 urn:service:sos.ecall.manual 1303 Used with an eCall invoked due to manual interaction by a vehicle 1304 occupant. 1306 urn:service:sos.ecall.automatic 1308 Used with an eCall invoked automatically, for example, due to a 1309 crash or other serious incident. 1311 IANA is also requested to register the URN 1312 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1313 defined in Setcion 17.2 of [RFC6881]. This service requests 1314 resources associated with a test (non-emergency) call placed by an 1315 in-vehicle system. See Section 8 for more information on the test 1316 eCall request URN. 1318 14.3. MIME Structured Syntax Suffix Registration for +PER 1320 IANA is requested to add "+PER" to the as a media type structured 1321 syntax suffix in the Structured Syntax Suffix registry. The ITU 1322 defined the Packed Encoding Rules (PER) transfer syntax in 1323 [ITU.X691]. The suffix "+per" MAY be used with any media type whose 1324 representation follows the PER transfer syntax. The media type 1325 structured syntax suffix registration form for +per follows: 1327 Name: Packed Encoding Rules (PER) transfer syntax 1329 +suffix: +per 1331 References: [ITU.X691] 1333 Encoding considerations: PER is a binary encoding 1335 Interoperability considerations: none identified 1337 Fragment identifier considerations: 1339 At publication of this document, there is no fragment 1340 identification syntax defined for +per. 1342 The syntax and semantics for fragment identifiers for a 1343 specific "xxx/yyy+per" SHOULD be processed as follows: 1345 For cases defined in +per, where the fragment identifier 1346 resolves per the +per rules, then process as specified in +per. 1348 For cases defined in +per, where the fragment identifier does 1349 not resolve per the +per rules, then process as specified in 1350 "xxx/yyy+per". 1352 For cases not defined in +per, then process as specified in 1353 "xxx/yyy+per". 1355 Security considerations: 1357 Because of the binary and structured nature of PER, it is not 1358 difficult to construct malicious content that could cause 1359 buffer overruns, stack overflows, and other attack vectors. 1361 Implementors should be aware of these issues and take 1362 appropriate measures to guard against buffer overruns, stack 1363 overflows, and related attack vectors. 1365 Contact: Apps Area Working Group (art@ietf.org) 1367 Author/Change controller: 1369 The Apps Area Working Group. IESG has change control over this 1370 registration. 1372 14.4. MIME Media Type Registration for 'application/ 1373 emergencyCallData.eCall.MSD+per' 1375 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1376 as a MIME media type, with a reference to this document, in 1377 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1378 RFC 7303 [RFC7303]. 1380 MIME media type name: application 1382 MIME subtype name: emergencyCallData.eCall.MSD+per 1384 Mandatory parameters: none 1386 Optional parameters: none 1388 Encoding scheme: binary 1390 Encoding considerations: Uses ASN.1 PER, which is a binary 1391 encoding; when transported in SIP, binary content transfer 1392 encoding is used. 1394 Security considerations: This media type is designed to carry 1395 vehicle and incident-related data during an emergency call. This 1396 data contains personal information including vehicle VIN, 1397 location, direction, etc. Appropriate precautions need to be 1398 taken to limit unauthorized access, inappropriate disclosure to 1399 third parties, and eavesdropping of this information. Sections 9 1400 and Section 10 of [RFC7852] contain more discussion. 1402 Interoperability considerations: None 1404 Published specification: Annex A of EN 15722 [msd] 1406 Applications which use this media type: Pan-European eCall 1407 compliant systems 1409 Additional information: None 1411 Magic Number: None 1413 File Extension: None 1415 Macintosh file type code: 'BINA' 1417 Person and email address for further information: Randall Gellens, 1418 rg+ietf@randy.pensive.org 1419 Intended usage: LIMITED USE 1421 Author: The MSD specification was produced by the European 1422 Committee For Standardization (CEN). For contact information, 1423 please see . 1425 Change controller: The European Committee For Standardization 1426 (CEN) 1428 14.5. MIME Media Type Registration for 'application/ 1429 emergencyCallData.control+xml' 1431 IANA is requested to add application/emergencyCallData.control+xml as 1432 a MIME media type, with a reference to this document, in accordance 1433 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1434 [RFC7303]. 1436 MIME media type name: application 1438 MIME subtype name: emergencyCallData.control+xml 1440 Mandatory parameters: none 1442 Optional parameters: charset 1444 Indicates the character encoding of the XML content. 1446 Encoding considerations: Uses XML, which can employ 8-bit 1447 characters, depending on the character encoding used. See 1448 Section 3.2 of RFC 7303 [RFC7303]. 1450 Security considerations: 1452 This media type carries metadata and control information and 1453 requests, such as from a Public Safety Answering Point (PSAP) 1454 to an In-Vehicle System (IVS) during an emergency call. 1456 Metadata (such as an acknowledgment that data sent by the IVS 1457 to the PSAP was successfully received) has limited privacy and 1458 security implications. Control information (such as requests 1459 from the PSAP that the vehicle perform an action) has some 1460 privacy and security implications. The privacy concern arises 1461 from the ability to request the vehicle to transmit a data set, 1462 which as described in Section 14.4, can contain personal 1463 information. The security concern is the ability to request 1464 the vehicle to perform an action. Control information needs to 1465 originate only from a PSAP or other emergency services 1466 provider, and not be modified en-route. The level of integrity 1467 of the cellular network over which the emergency call is placed 1468 is a consideration: when the IVS initiates an eCall over a 1469 cellular network, in most cases it relies on the MNO to route 1470 the call to a PSAP. (Calls placed using other means, such as 1471 Wi-Fi or over-the-top services, generally incur somewhat higher 1472 levels of risk than calls placed "natively" using cellular 1473 networks.) A call-back from a PSAP merits additional 1474 consideration, since current mechanisms are not ideal for 1475 verifying that such a call is indeed a call-back from a PSAP in 1476 response to an emergency call placed by the IVS. See the 1477 discussion in Section 11 and the PSAP Callback document 1478 [RFC7090]. 1480 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1482 Interoperability considerations: None 1484 Published specification: This document 1486 Applications which use this media type: Pan-European eCall 1487 compliant systems 1489 Additional information: None 1491 Magic Number: None 1493 File Extension: .xml 1495 Macintosh file type code: 'TEXT' 1497 Person and email address for further information: Randall Gellens, 1498 rg+ietf@randy.pensive.org 1500 Intended usage: LIMITED USE 1502 Author: The IETF ECRIT WG. 1504 Change controller: The IETF ECRIT WG. 1506 14.6. Registration of the 'eCall.MSD' entry in the Emergency Call 1507 Additional Data Types registry 1509 This specification requests IANA to add the 'eCall.MSD' entry to the 1510 Emergency Call Additional Data Types registry, with a reference to 1511 this document; the 'Data About' value is 'The Call'. 1513 14.7. Registration of the 'control' entry in the Emergency Call 1514 Additional Data Types registry 1516 This specification requests IANA to add the 'control' entry to the 1517 Emergency Call Additional Data Types registry, with a reference to 1518 this document; the 'Data About' value is 'The Call'. 1520 14.8. URN Sub-Namespace Registration 1522 14.8.1. Registration for 1523 urn:ietf:params:xml:ns:EmergencyCallData:control 1525 This section registers a new XML namespace, as per the guidelines in 1526 RFC 3688 [RFC3688]. 1528 URI: urn:ietf:params:xml:ns:EmergencyCallData:control 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 Emergency Call Data Control Block 1544 1545 1546

Namespace for Emergency Call Data Control Block

1547

See [TBD: This document].

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