idnits 2.17.00 (12 Aug 2021) /tmp/idnits41933/draft-ietf-ecrit-ecall-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (August 1, 2016) is 2118 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) ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Core Technology Consulting 4 Intended status: Standards Track H. Tschofenig 5 Expires: February 2, 2017 Individual 6 August 1, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-11.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 Content Types and an Emergency Call 22 Additional Data Blocks for the eCall vehicle data and metadata/ 23 control data. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 2, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 63 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Call Routing . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 10 69 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 12 70 9.1.1. The element . . . . . . . . . . . . . . . . . . 12 71 9.1.1.1. Attributes of the element . . . . . . . . . 12 72 9.1.1.2. Child Element of the element . . . . . . . 13 73 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14 74 9.1.2. The element . . . . . . . . . . . . . 14 75 9.1.2.1. Child Elements of the element . . 14 76 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15 77 9.1.3. The element . . . . . . . . . . . . . . . . 15 78 9.1.3.1. Attributes of the element . . . . . . . 15 79 9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 17 80 10. The emergencyCallData.eCall.MSD INFO package . . . . . . . . 17 81 10.1. INFO Package Requirements . . . . . . . . . . . . . . . 17 82 10.1.1. Overall Description . . . . . . . . . . . . . . . . 18 83 10.1.2. Applicability . . . . . . . . . . . . . . . . . . . 18 84 10.1.3. Info Package Name . . . . . . . . . . . . . . . . . 18 85 10.1.4. Info Package Parameters . . . . . . . . . . . . . . 19 86 10.1.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 19 87 10.1.6. INFO Message Body Parts . . . . . . . . . . . . . . 19 88 10.1.7. Info Package Usage Restrictions . . . . . . . . . . 19 89 10.1.8. Rate of INFO Requests . . . . . . . . . . . . . . . 19 90 10.1.9. Info Package Security Considerations . . . . . . . . 19 91 10.1.10. Implementation Details . . . . . . . . . . . . . . . 19 92 10.1.11. Examples . . . . . . . . . . . . . . . . . . . . . . 19 93 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 96 14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 15.1. Service URN Registrations . . . . . . . . . . . . . . . 29 99 15.2. MIME Content-type Registration for 100 'application/emergencyCallData.eCall.MSD+per' . . . . . 30 101 15.3. MIME Content-type Registration for 102 'application/emergencyCallData.eCall.control+xml' . . . 31 103 15.4. Registration of the 'eCall.MSD' entry in the Emergency 104 Call Additional Data Blocks registry . . . . . . . . . . 32 105 15.5. Registration of the 'eCall.control' entry in the 106 Emergency Call Additional Data Blocks registry . . . . . 33 107 15.6. Registration of the emergencyCallData.eCall Info Package 33 108 15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33 109 15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33 110 15.7.2. Registration for 111 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34 112 15.8. Registry creation . . . . . . . . . . . . . . . . . . . 34 113 15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 34 114 15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 35 115 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 116 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 117 18. Changes from Previous Versions . . . . . . . . . . . . . . . 36 118 18.1. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 36 119 18.2. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 37 120 18.3. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 37 121 18.4. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 37 122 18.5. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 123 18.6. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38 124 18.7. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38 125 18.8. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 38 126 18.9. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 38 127 18.10. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 128 18.11. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 39 129 18.12. Changes from draft-gellens-02 to -03 . . . . . . . . . . 39 130 18.13. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 131 18.14. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39 132 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 133 19.1. Normative References . . . . . . . . . . . . . . . . . . 40 134 19.2. Informative references . . . . . . . . . . . . . . . . . 41 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 137 1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 This document re-uses terminology defined in Section 3 of [RFC5012]. 145 Additionally, we use the following abbreviations: 147 +--------+----------------------------------------+ 148 | Term | Expansion | 149 +--------+----------------------------------------+ 150 | 3GPP | 3rd Generation Partnership Project | 151 | | | 152 | CEN | European Committee for Standardization | 153 | | | 154 | EENA | European Emergency Number Association | 155 | | | 156 | ESInet | Emergency Services IP network | 157 | | | 158 | IMS | IP Multimedia Subsystem | 159 | | | 160 | IVS | In-Vehicle System | 161 | | | 162 | MNO | Mobile Network Operator | 163 | | | 164 | MSD | Minimum Set of Data | 165 | | | 166 | PSAP | Public Safety Answering Point | 167 +--------+----------------------------------------+ 169 2. Document Scope 171 This document is focused on the signaling, data exchange, and 172 protocol needs of next-generation eCall (NG-eCall, also referred to 173 as packet-switched eCall or all-IP eCall) within the SIP framework 174 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 175 itself is specified by 3GPP and CEN and these specifications include 176 far greater scope than is covered here. 178 The eCall service operates over cellular wireless communication, but 179 this document does not address cellular-specific details, nor client 180 domain selection (e.g., circuit-switched versus packet-switched). 181 All such aspects are the purview of their respective standards 182 bodies. The scope of this document is limited to eCall operating 183 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 185 The technical contents of this document also provide a basis for 186 reuse and extension for other vehicle-initiated emergency call 187 systems. 189 Vehicles designed for multiple regions might need to support eCall 190 and other Advanced Automatic Crash Notification (AACN) systems, such 191 as described in [I-D.ietf-ecrit-car-crash]. 193 3. Introduction 195 Emergency calls made from vehicles (e.g., in the event of a crash) 196 assist in significantly reducing road deaths and injuries by allowing 197 emergency services to be aware of the incident, the state of the 198 vehicle, the location of the vehicle, and to have a voice channel 199 with the vehicle occupants. This enables a quick and appropriate 200 response. 202 The European Commission initiative of eCall was conceived in the late 203 1990s, and has evolved to a European Parliament decision requiring 204 the implementation of a compliant in-vehicle system (IVS) in new 205 vehicles and the deployment of eCall in the European Member States in 206 the very near future. Other regions are developing eCall-compatible 207 systems. 209 The pan-European eCall system provides a standardized and mandated 210 mechanism for emergency calls by vehicles. eCall establishes 211 procedures for such calls to be placed by in-vehicle systems, 212 recognized and processed by the mobile network, and routed to a 213 specialized PSAP where the vehicle data is available to assist the 214 call taker in assessing and responding to the situation. eCall 215 provides a standard set of vehicle, sensor (e.g., crash related), and 216 location data. 218 An eCall can be either user-initiated or automatically triggered. 219 Automatically triggered eCalls indicate a car crash or some other 220 serious incident. Manually triggered eCalls might be reports of 221 witnessed crashes or serious hazards. PSAPs might apply specific 222 operational handling to manual and automatic eCalls. 224 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 225 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 226 call setup mark the call as an eCall, and further indicate if the 227 call was automatically or manually triggered. The call is routed to 228 an eCall-capable PSAP, a voice channel is established between the 229 vehicle and the PSAP, and an eCall in-band modem is used to carry a 230 defined set of vehicle, sensor (e.g., crash related), and location 231 data (the Minimum Set of Data or MSD) within the voice channel. The 232 same in-band mechanism is used for the PSAP to acknowledge successful 233 receipt of the MSD, and to request the vehicle to send a new MSD 234 (e.g., to check if the state of or location of the vehicle or its 235 occupants has changed). NG-eCall moves from circuit switched to all- 236 IP, and carries the vehicle data and eCall signaling as additional 237 data carried with the call. This document describes how IETF 238 mechanisms for IP-based emergency calls, including [RFC6443] and 239 [RFC7852] are used to provide the signaling and data exchange of the 240 next generation of pan-European eCall. 242 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 243 has published a Technical Report titled "Mobile Standards Group 244 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 245 recommendations regarding support for eCall in an all-IP environment. 246 The recommendations include the use of 3GPP IMS emergency calling 247 with additional elements identifying the call as an eCall and as 248 carrying eCall data and with mechanisms for carrying the data and 249 eCall signaling. 3GPP IMS emergency services support multimedia, 250 providing the ability to carry voice, text, and video. This 251 capability is referred to within 3GPP as Multimedia Emergency 252 Services (MMES). 254 A transition period will exist during which time the various entities 255 involved in initiating and handling an eCall might support next- 256 generation eCall, legacy eCall, or both. The issues of migration and 257 co-existence during the transition period are outside the scope of 258 this document. 260 The MSD is carried in the MIME type 'application/ 261 emergencyCallData.eCall.MSD+per' and the metadata/control block is 262 carried in the MIME type 'application/ 263 emergencyCallData.eCall.control+xml' (both of which are registered in 264 this document). 266 4. eCall Requirements 268 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 269 [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle 270 data are contained in EN 15722 [msd]. 272 5. Vehicle Data 274 Pan-European eCall provides a standardized and mandated set of 275 vehicle related data, known as the Minimum Set of Data (MSD). The 276 European Committee for Standardization (CEN) has specified this data 277 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 278 circuit-switched eCall and this document use the ASN.1 PER encoding, 279 which is specified in Annex A of EN 15722 [msd] (the XML encoding 280 specified in Annex C is not used in this document). 282 This document registers the 'application/ 283 emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD 284 to be carried in SIP. As an ASN.1 PER encoded object, the data is 285 binary and transported using binary content transfer encoding within 286 SIP messages. This document also adds the 'eCall.MSD' entry to the 287 Emergency Call Additional Data Blocks registry to enable the MSD to 288 be recognized as such in a SIP-based eCall emergency call. (See 290 [RFC7852] for more information about the registry and how it is 291 used.) 293 See Section 6 for a discussion of how the MSD vehicle data is 294 conveyed in an NG-eCall. 296 6. Data Transport 298 [RFC7852] establishes a general mechanism for attaching blocks of 299 data to a SIP emergency call. This mechanism permits certain 300 emergency call MIME types to be attached to SIP messages. This 301 document makes use of that mechanism. 303 Note that if additional data sets are defined and registered (e.g., 304 in the future or in other regions) and transmitted using the same 305 mechanisms, the size and frequency of transmission during a dialog 306 need to be evaluated to be sure it is appropriate to use the 307 signaling channel. 309 An In-Vehicle System (IVS) transmits the MSD (see Section 5) by 310 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 311 message as a MIME body part per [RFC7852]. The body part is 312 identified by its MIME content-type ('application/ 313 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 314 the body part. The body part is assigned a unique identifier which 315 is listed in a Content-ID header field in the body part. The SIP 316 message is marked as containing the MSD by adding (or appending to) a 317 Call-Info header field at the top level of the SIP message. This 318 Call-Info header field contains a CID URL referencing the body part's 319 unique identifier, and a 'purpose' parameter identifying the data as 320 the eCall MSD per the Emergency Call Additional Data Blocks registry 321 entry; the 'purpose' parameter's value is 322 'emergencyCallData.eCall.MSD'. 324 A PSAP or IVS transmits a metadata/control object (see Section 9) by 325 encoding it per the description in this document and attaching it to 326 a SIP message as a MIME body part per [RFC7852]. The body part is 327 identified by its MIME content-type ('application/ 328 emergencyCallData.eCall.control+xml') in the Content-Type header 329 field of the body part. The body part is assigned a unique 330 identifier which is listed in a Content-ID header field in the body 331 part. The SIP message is marked as containing the metadata/control 332 object by adding (or appending to) a Call-Info header field at the 333 top level of the SIP message. This Call-Info header field contains a 334 CID URL referencing the body part's unique identifier, and a 335 'purpose' parameter identifying the data as an eCall metadata/control 336 block per the Emergency Call Additional Data Blocks registry entry; 337 the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. 339 An In-Vehicle System (IVS) initiating an NG-eCall attaches the MSD to 340 the initial INVITE and optionally attaches a metadata/control object 341 informing the PSAP of its capabilities. The PSAP creates a metadata/ 342 control object acknowledging receipt of the MSD and attaches it to 343 the SIP response to the INVITE. 345 A PSAP can request the vehicle to send an updated MSD during a call. 346 The PSAP creates a metadata/control object requesting the MSD and 347 attaches it to a SIP INFO message which it sends within the dialog. 348 The IVS then attaches an updated MSD to a SIP INFO message and sends 349 it within the dialog. The metadata/control object and the MSD are 350 attached to an INFO message in the same way they are attached to 351 other messages (such as the INVITE and the reply to the INVITE as 352 discussed above). INFO messages are sent using an appropriate INFO 353 Package. See Section 10 for information about the use of INFO 354 messages to carry data within an eCall. 356 When data is being carried in an INFO request message, the body part 357 also carries a Content-Disposition header field set to "Info- 358 Package". 360 Support for the data blocks defined in [RFC7852] is NOT REQUIRED for 361 conformance with this document. 363 7. Call Setup 365 In circuit-switched eCall, the IVS places a special form of a 112 366 emergency call which carries an eCall flag (indicating that the call 367 is an eCall and also if the call was manually or automatically 368 triggered); the mobile network operator (MNO) recognizes the eCall 369 flag and routes the call to an eCall-capable PSAP; vehicle data is 370 transmitted to the PSAP via the eCall in-band modem (in the voice 371 channel). 373 ///----\\\ 112 voice call with eCall flag +------+ 374 ||| IVS |||---------------------------------------->+ PSAP | 375 \\\----/// vehicle data via eCall in-band modem +------+ 377 Figure 1: circuit-switched eCall 379 For NG-eCall, the IVS establishes an emergency call using a Request- 380 URI indicating a manual or automatic eCall; the MNO (or ESInet) 381 recognizes the eCall URN and routes the call to an NG-eCall capable 382 PSAP; the PSAP interpets the vehicle data sent with the call and 383 makes it available to the call taker. 385 ///----\\\ IMS emergency call with eCall URN +------+ 386 IVS ----------------------------------------->+ PSAP | 387 \\\----/// vehicle data included in call setup +------+ 389 Figure 2: NG-eCall 391 See Section 6 for information on how the MSD is transported within an 392 NG-eCall. 394 This document registers new service URN children within the "sos" 395 subservice. These URNs provide the mechanism by which an eCall is 396 identified, and differentiate between manually and automatically 397 triggered eCalls (which might be subject to different treatment, 398 depending on policy). The two service URNs are: 399 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 400 which requests resources associated with an emergency call placed by 401 an in-vehicle system, carrying a standardized set of data related to 402 the vehicle and incident. 404 7.1. Call Routing 406 The routing applied to eCalls might differ from those of other 407 emergency calls, as eCalls are intended to be handled by PSAPs that 408 support eCall. In regions without ESInets, typically the emergency 409 services authorities and the originating network determine how such 410 calls are routed. In a region that uses ESInets, the originating 411 network passes all types of emergency calls to an ESInet (calls which 412 have a request URI containing the "SOS" service URN). The ESInet is 413 then responsible for routing such calls to the appropriate PSAP. 415 8. Test Calls 417 eCall requires the ability to place test calls (see [TS22.101] clause 418 10.7 and [EN_16062] clause 7.2.2). These are calls that are 419 recognized and treated to some extent as eCalls but are not given 420 emergency call treatment and are not handled by call takers. The 421 specific handling of test eCalls is not itself standardized; 422 typically, the test call facility allows the IVS or user to verify 423 that an eCall can be successfully established with voice 424 communication. The IVS might also be able to verify that the MSD was 425 successfully received. 427 A service URN starting with "test." indicates a test call. For 428 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 429 This functionality is defined in [RFC6881]. 431 This document registers "urn:service:test.sos.ecall" for eCall test 432 calls. 434 The CS-eCall test call facility is a non-emergency number so does not 435 get treated as an emergency call. For NG-eCall, MNOs, emergency 436 authorities, and PSAPs can determine how to treat a vehicle call 437 requesting the "test" service URN so that the desired functionality 438 is tested, but this is outside the scope of this document. 440 9. The Metadata/Control Object 442 eCall requires the ability for the PSAP to acknowledge successful 443 receipt of an MSD sent by the IVS, and for the PSAP to request that 444 the IVS send an MSD (e.g., the call taker can initiate a request for 445 a new MSD to see if there have been changes in the vehicle's state, 446 e.g., location, direction, number of fastened seatbelts). 448 This document defines a block of metadata/control data as an XML 449 structure containing elements used for eCall and other vehicle- 450 initiated emergency call systems (i.e., in other regions) and 451 extension points. (This metadata/control block is in effect a high- 452 level protocol between the PSAP and IVS.) When the PSAP sends an 453 eCall metadata/control block in response to data sent by the IVS in a 454 SIP request other than INFO (e.g., the MSD in the initial INVITE), 455 the metadata/control block is sent in the SIP response to that 456 request (e.g., the response to the INVITE request). When the PSAP 457 sends an eCall control block in other circumstances (e.g., mid-call), 458 the control block is transmitted from the PSAP to the IVS in a SIP 459 INFO request within the established dialog. The IVS sends the 460 requested data (the MSD) in a new INFO request (per [RFC6086]). This 461 mechanism flexibly allows the PSAP to send eCall-specific data to the 462 IVS and the IVS to respond. INFO messages are sent using an 463 appropriate INFO Package. See Section 6 for more information on 464 attaching a metadata/control block to a SIP message. See Section 10 465 for information about the use of INFO messages to carry data within 466 an eCall. 468 This mechanism requires 470 o An XML definition of the eCall control object 471 o Extension points for use by eCall-like systems in other regions 472 o A MIME type registration for the control object (so it can be 473 carried in SIP messages and responses) 474 o An entry in the Emergency Call Additional Data Blocks registry so 475 that the control block can be recognized as emergency call 476 specific data within SIP messages 477 o An Info-Package registration per [RFC6086] permitting the 478 metadata/control block and the MSD within INFO messages 480 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 481 initial INVITE), the PSAP sends a metadata/control block indicating 482 successful/unsuccessful receipt of the MSD in the SIP response to the 483 request. This also informs the IVS that an NG-eCall is in operation. 484 If the IVS receives a SIP response without the metadata/control 485 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 486 some part of the call is being handled as a legacy call). When the 487 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 488 receipt of a SIP INFO request containing a metadata/control block 489 requesting an MSD), the PSAP does not send a metadata/control block 490 indicating successful or unsuccessful receipt of the MSD. (Normal 491 SIP retransmission handles non-receipt of requested data; if the IVS 492 sends a requested MSD in an INFO request and does not receive a SIP 493 status message for the INFO request, it resends it; if the PSAP 494 requests an MSD and does not receive a SIP status message for the 495 INFO request, it resends it.) 497 This provides flexibility to handle various circumstances. For 498 example, if a PSAP is unable to accept an eCall (e.g., due to 499 overload or too many calls from the same location), it can reject the 500 INVITE. Since a metadata/control object is also included in the SIP 501 response that rejects the call, the IVS knows if the PSAP received 502 the MSD, and can inform the vehicle occupants that the PSAP 503 successfully received the vehicle location and information but can't 504 talk to the occupants at that time. Especially for SIP response 505 codes that indicate an inability to conduct a call (as opposed to a 506 technical inability to process the request), the IVS can also 507 determine that the call was successful on a technical level (e.g., 508 not helpful to retry as a CS-eCall). The SIP response codes 600 509 (Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when 510 the PSAP wants to reject a call but inform the vehicle occupants that 511 it is aware of the situation. (Note that there could be edge cases 512 where the PSAP response is not received by the IVS, e.g., if an 513 intermediary sends a CANCEL, and an error response is forwarded 514 towards the IVS before the error response from the PSAP is received, 515 the response will be dropped, but these are unlikely to occur here.) 517 The metadata/control block is carried in the MIME type 'application/ 518 emergencyCallData.eCall.control+xml'. 520 The metadata/control block is designed for use with with pan-European 521 eCall and also eCall-like systems (i.e., in other regions), and has 522 extension points to accomodate variances. Note that eCall-like 523 systems might define their own vehicle data blocks, and so might need 524 to register a new INFO package to accomodate the new data MIME type 525 and the metadata/control object. 527 9.1. The eCall Control Block 529 The eCall control block is an XML data structure allowing for 530 acknowledgments, requests, and capabilities information. It is 531 carried in a SIP body part with a specific MIME content type. Three 532 elements are defined for use within an eCall control block: 534 ack Acknowledges receipt of data or a request. 536 capabilities: Used in a control block sent from the IVS to the PSAP 537 (e.g., in the initial INVITE) to inform the PSAP of the 538 vehicle capabilities. Child elements contain all 539 actions and data types supported by the vehicle. It is 540 OPTIONAL for the IVS to send this block. Omitting the 541 block indicates that the IVS supports only the 542 mandatory functionality defined in this document. 544 request Used in a control block sent by the PSAP to the IVS, to 545 request the vehicle to perform an action. 547 The element indicates the object being acknowledged and reports 548 success or failure. 550 The element contains attributes to indicate the request and 551 to supply related information. The 'action' attribute is mandatory 552 and indicates the specific action. An IANA registry is created in 553 Section 15.8.1 to contain the allowed values. 555 The element has child elements to indicate 556 the actions supported by the IVS. 558 9.1.1. The element 560 The element acknowledges receipt of an eCall data object or 561 request. An element references the unique ID of the data 562 object being acknowledged. The PSAP MUST send an element 563 acknowledging reeipt of an unsolicited MSD (e.g., sent by the IVS in 564 the INVITE); this element indicates if the PSAP considers the 565 MSD successfully received or not. An element is not sent for a 566 element. 568 The element has the following attributes: 570 9.1.1.1. Attributes of the element 572 The element has the following attributes: 574 Name: ref 575 Usage: Mandatory 576 Type: anyURI 577 Direction: In this document, sent from the PSAP to the IVS 578 Description: References the Content-ID of the body part being 579 acknowledged. 580 Example: 582 Name: received 583 Usage: Conditional: mandatory in an >ack< element sent by a PSAP 584 Type: Boolean 585 Direction: In this document, sent from the PSAP to the IVS 586 Description: Indicates if the referenced object was considered 587 successfully received or not 588 Example: 590 9.1.1.2. Child Element of the element 592 For extensibility, the element has the following child element: 594 Name: actionResult 595 Usage: Optional 596 Direction: Provided for extension, sent from the IVS to the PSAP 597 Description: An element indicates the result of an 598 action (other than a 'send-data' action). When an element 599 is in response to a control object with multiple 600 elements, the element contains an element for 601 each element that is not a 'send-data' action. The 602 element has the following attributes: 604 Name: action 605 Usage: Mandatory 606 Type: token 607 Direction: In this document, sent from the PSAP to the IVS 608 Description: Contains the value of the 'action' attribute of the 609 element 611 Name: success 612 Usage: Mandatory 613 Type: Boolean 614 Direction: Provided for extension, sent from the IVS to the PSAP 615 Description: Indicates if the action was successfully 616 accomplished 618 Name: reason 619 Usage: Conditional 620 Type: token 621 Direction: Provided for extension, sent from the IVS to the PSAP 622 Description: Used when 'success' is "False", this attribute 623 contains a reason code for a failure. A registry for reason 624 codes is defined in Section 15.8.2. 626 Name: details 627 Usage: optional 628 Type: string 629 Direction: Provided for extension, sent from the IVS to the PSAP 630 Description: Contains further explanation of the circumstances of 631 a success or failure. The contents are implementation-specific 632 and human-readable. 634 9.1.1.3. Ack Examples 636 637 643 645 647 Figure 3: Ack Example from PSAP to IVS 649 9.1.2. The element 651 The element is transmitted by the IVS to indicate to 652 the PSAP its capabilities. No attributes for this element are 653 currently defined. The following child elements are defined: 655 9.1.2.1. Child Elements of the element 657 The element has the following child elements: 659 Name: request 660 Usage: Mandatory 661 Description: The element contains a child 662 element per action supported by the vehicle. 664 Examples: 665 667 It is OPTIONAL for the IVS to support the element. If 668 the IVS does not send a element, this indicates that 669 the only action supported by the IVS is 'send-data' with 670 'datatype' set to 'eCall.MSD'. 672 9.1.2.2. Capabilities Example 674 675 681 682 683 685 687 Figure 4: Capabilities Example 689 9.1.3. The element 691 A element appears one or more times on its own or as a 692 child of a element. It allows the PSAP to request 693 that the IVS perform an action. The only action that MUST be 694 supported is to send an MSD. The following attributes and child 695 elements are defined: 697 9.1.3.1. Attributes of the element 699 The element has the following attributes: 701 Name: action 702 Usage: Mandatory 703 Type: token 704 Direction: In this document, sent from the PSAP to the IVS; for 705 extension, sent from the IVS to the PSAP 706 Description: Identifies the action that the vehicle is requested to 707 perform. An IANA registry is established in Section 15.8.1 to 708 contain the allowed values. 709 Example: action="send-data" 711 Name: msgid 712 Usage: Conditional 713 Type: int 714 Direction: Sent from the PSAP to the IVS 715 Description: Defined for extensibility. 716 Example: msgid="3" 718 Name: persistance 719 Usage: Optional 720 Type: duration 721 Direction: Sent from the PSAP to the IVS 722 Description: Defined for extensibility. Specifies how long to carry 723 on the specified action. If absent, the default is for the 724 duration of the call. 725 Example: persistance="PT1H" 727 Name: datatype 728 Usage: Conditional 729 Type: token 730 Direction: In this document, sent from the PSAP to the IVS; as an 731 extension, sent from the IVS to the PSAP 732 Description: Mandatory with a "send-data" action within a 733 element that is not within a element. Specifies 734 the data block that the IVS is requested to transmit, using the 735 same identifier as in the 'purpose' attribute set in a Call-Info 736 header field to point to the data block. Permitted values are 737 contained in the 'Emergency Call Data Types' IANA registry 738 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 739 to support. 740 Example: datatype="eCall.MSD" 742 Name: supported-values 743 Usage: Conditional 744 Type: string 745 Direction: Sent from the IVS to the PSAP 746 Description: Defined for extensibility. Used in a element 747 that is a child of a element, this attribute lists 748 all supported values of the action type. Permitted values depend 749 on the action value. Multiple values are separated with a 750 semicolon. 752 Name: requested-state 753 Usage: Conditional 754 Type: token 755 Direction: Sent from the PSAP to the IVS 756 Description: Defined for extension. Indicates the requested state 757 of an element associated with the request type. Permitted values 758 depend on the request type. 760 Name: element-ID 761 Usage: Conditional 762 Type: token 763 Direction: Sent from the PSAP to the IVS 764 Description: Defined for extension. Identifies the element to be 765 acted on. Permitted values depend on the request type. 767 9.1.3.2. Request Example 769 770 776 778 780 Figure 5: Request Example 782 10. The emergencyCallData.eCall.MSD INFO package 784 This document registers the 'emergencyCallData.eCall.MSD' INFO 785 package. 787 Both endpoints (the IVS and the PSAP equipment) include 788 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 789 [RFC6086] to indicate ability to receive INFO messages carrying data 790 as described here. 792 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 793 the ability to receive the MSD and metadata/control body parts as 794 specified in [TBD: THIS DOCUMENT]. 796 An INFO request message carrying body parts related to an emergency 797 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 798 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 800 10.1. INFO Package Requirements 802 The requirements of Section 10 of [RFC6086] are addressed in the 803 following sections. 805 10.1.1. Overall Description 807 This section describes "what type of information is carried in INFO 808 requests associated with the Info Package, and for what types of 809 applications and functionalities UAs can use the Info Package." 811 INFO requests associated with the emergencyCallData.eCall.MSD INFO 812 package carry data associated with emergency calls as defined in 813 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 814 calls established using SIP. The functionality is to carry vehicle 815 data and metadata/control information between vehicles and PSAPs. 816 Refer to [TBD: THIS DOCUMENT] for more information. 818 10.1.2. Applicability 820 This section describes "why the Info Package mechanism, rather than 821 some other mechanism, has been chosen for the specific use-case...." 823 The use of INFO is based on an analysis of the requirements against 824 the intent and effects of INFO versus other approaches (which 825 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 826 transport, and non-SIP protocols). In particular, the transport of 827 emergency call data blocks occurs within a SIP emergency dialog, per 828 Section 6, and is normally carried in the initial INVITE and its 829 response; the use of INFO only occurs when emergency-call-related 830 data needs to be sent mid-call. While MESSAGE could be used, it is 831 not tied to a SIP dialog as is INFO and thus might not be associated 832 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 833 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 834 service, but the semantics are not a good fit, e.g., the subscribe/ 835 notify mechanism provides one-way communication consisting of (often 836 multiple) notifications from notifier to subscriber indicating that 837 certain events in notifier have occurred, whereas what's needed here 838 is two-way communication of data related to the emergency dialog. 839 Use of the media plane mechanisms was discounted because the number 840 of messages needing to be exchanged in a dialog is normally zero or 841 very few, and the size of the data is likewise very small. The 842 overhead caused by user plane setup (e.g., to use MSRP as transport) 843 would be disproportionately large. 845 Based on the the analyses, the SIP INFO method was chosen to provide 846 for mid-call data transport. 848 10.1.3. Info Package Name 850 The info package name is emergencyCallData.eCall.MSD 852 10.1.4. Info Package Parameters 854 None 856 10.1.5. SIP Option-Tags 858 None 860 10.1.6. INFO Message Body Parts 862 The 'application/emergencyCallData.eCall.MSD+per' and 'application/ 863 emergencyCallData.eCall.control+xml' MIME types are associated with 864 this INFO package. See [TBD: THIS DOCUMENT] for more information. 866 10.1.7. Info Package Usage Restrictions 868 Usage is limited to vehicle-initiated emergency calls as defined in 869 [TBD: THIS DOCUMENT]. 871 10.1.8. Rate of INFO Requests 873 The rate of SIP INFO requests associated with the 874 emergencyCallData.eCall.MSD info package is normally quite low (most 875 dialogs are likely to contain zero INFO requests, while others can be 876 expected to carry an occasional request). 878 10.1.9. Info Package Security Considerations 880 The MIME content type registations for the data blocks that can be 881 carried using this IFO package contains a discussion of the security 882 and/or privacy considerations specific to that data block. The 883 "Security Considerations" and "Privacy Considerations" sections of 884 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 885 the data carried in eCalls. 887 10.1.10. Implementation Details 889 See [TBD: THIS DOCUMENT] for protocol details. 891 10.1.11. Examples 893 See [TBD: THIS DOCUMENT] for protocol examples. 895 11. Examples 897 Figure 6 illustrates an eCall. The call uses the request URI 898 'urn:service:sos.ecall.automatic' service URN and is recognized as an 899 eCall, and further as one that was invoked automatically by the IVS 900 due to a crash or other serious incident. In this example, the 901 originating network routes the call to an ESInet which routes the 902 call to the appropriate NG-eCall capable PSAP. The emergency call is 903 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 904 the entry point into the ESInet. The ESRP routes the call to a PSAP, 905 where it is received by a call taker. In deployments where there is 906 no ESInet, the originating network routes the call directly to the 907 appropriate NG-eCall capable PSAP, an illustration of which would be 908 identical to the one below except without an ESInet or ESRP. 910 +------------+ +---------------------------------------+ 911 | | | +-------+ | 912 | | | | PSAP2 | | 913 | | | +-------+ | 914 | | | | 915 | | | +------+ +-------+ | 916 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 917 | | | +------+ +-------+ | 918 | | | | 919 | | | +-------+ | 920 | | | | PSAP3 | | 921 | Originating| | +-------+ | 922 | Mobile | | | 923 | Network | | ESInet | 924 +------------+ +---------------------------------------+ 926 Figure 6: Example of NG-eCall Message Flow 928 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 929 for an updated MSD. The call flow shows the IVS initiating an 930 emergency call, including the MSD in the INVITE. The PSAP includes 931 in the 200 OK response a metadata/control object acknowledging 932 receipt of the MSD. During the call, the PSAP sends a request for an 933 MSD in an INFO message. The IVS sends the requested MSD in a new 934 INFO message. 936 IVS PSAP 937 |(1) INVITE (eCall MSD) | 938 |------------------------------------------->| 939 | | 940 |(2) 200 OK (eCall metadata [ack MSD]) | 941 |<-------------------------------------------| 942 | | 943 |(3) start media stream(s) | 944 |............................................| 945 | | 946 |(4) INFO (eCall metadata [request MSD]) | 947 |<-------------------------------------------| 948 | | 949 |(5) 200 OK | 950 |------------------------------------------->| 951 | | 952 |(6) INFO (eCall MSD) | 953 |------------------------------------------->| 954 | | 955 |(7) 200 OK | 956 |<-------------------------------------------| 957 | | 958 |(8) BYE | 959 |<-------------------------------------------| 960 | | 961 |(9) end media streams | 962 |............................................| 963 | | 964 |(10) 200 OK | 965 |------------------------------------------->| 967 Figure 7: NG-eCall Call Flow Illustration 969 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 970 contains an MSD. For simplicity, the example does not show all SIP 971 headers, nor the SDP contents, nor does it show any additional data 972 blocks added by the IVS or the originating mobile network. Because 973 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 974 contents cannot be included in a text document. 976 INVITE urn:service:sos.ecall.automatic SIP/2.0 977 To: urn:service:sos.ecall.automatic 978 From: ;tag=9fxced76sl 979 Call-ID: 3848276298220188511@atlanta.example.com 980 Geolocation: 981 Geolocation-Routing: no 982 Call-Info: cid:1234567890@atlanta.example.com; 983 purpose=emergencyCallData.eCall.MSD; 984 Accept: application/sdp, application/pidf+xml, 985 application/emergencyCallData.eCall.control+xml 986 CSeq: 31862 INVITE 987 Recv-Info: emergencyCallData.eCall.MSD 988 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 989 SUBSCRIBE, NOTIFY, UPDATE 990 Content-Type: multipart/mixed; boundary=boundary1 991 Content-Length: ... 993 --boundary1 994 Content-Type: application/sdp 996 ...Session Description Protocol (SDP) goes here... 998 --boundary1 999 Content-Type: application/emergencyCallData.eCall.MSD+per 1000 Content-ID: 1234567890@atlanta.example.com 1001 Content-Disposition: by-reference;handling=optional 1002 Content-Transfer-Encoding: binary 1004 ...MSD in ASN.1 PER encoding goes here... 1006 --boundary1-- 1008 Figure 8: SIP NG-eCall INVITE 1010 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1011 the INVITE of Figure 8, containing an eCall control block 1012 acknowledging successful receipt of the eCall MSD. (For simplicity, 1013 the example does not show all SIP headers.) 1014 SIP/2.0 200 OK 1015 To: ;tag=9fxced76sl 1016 From: Exemplar PSAP 1017 Call-ID: 3848276298220188511@atlanta.example.com 1018 Call-Info: cid:2345678901@atlanta.example.com; 1019 purpose=emergencyCallData.eCall.control; 1020 Accept: application/sdp, application/pidf+xml, 1021 application/emergencyCallData.eCall.control+xml, 1022 application/emergencyCallData.eCall.MSD+per 1023 CSeq: 31862 INVITE 1024 Recv-Info: emergencyCallData.eCall.MSD 1025 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1026 SUBSCRIBE, NOTIFY, UPDATE 1027 Content-Type: multipart/mixed; boundary=boundaryX 1028 Content-Length: ... 1030 --boundaryX 1031 Content-Type: application/sdp 1033 ...Session Description Protocol (SDP) goes here... 1035 --boundaryX 1036 Content-Type: application/EmergencyCallData.eCall.control+xml 1037 Content-ID: 2345678901@atlanta.example.com 1038 Content-Disposition: by-reference;handling=optional 1040 1041 1047 1049 1051 --boundaryX-- 1053 Figure 9: 200 OK response to INVITE 1055 Figure 10 illustrates an INFO message containing an eCall metadata/ 1056 control block requesting an eCall MSD. (For simplicity, the example 1057 does not show all SIP headers.) 1058 INFO sip:+13145551111@example.com SIP/2.0 1059 To: ;tag=9fxced76sl 1060 From: Exemplar PSAP 1061 Call-ID: 3848276298220188511@atlanta.example.com 1062 Call-Info: cid:3456789012@atlanta.example.com; 1063 purpose=emergencyCallData.eCall.control; 1064 Accept: application/sdp, application/pidf+xml, 1065 application/emergencyCallData.eCall.control+xml, 1066 application/emergencyCallData.eCall.MSD+per 1067 CSeq: 41862 INFO 1068 Recv-Info: emergencyCallData.eCall.MSD 1069 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1070 SUBSCRIBE, NOTIFY, UPDATE 1071 Content-Type: application/EmergencyCallData.eCall.control+xml 1072 Content-ID: 3456789012@atlanta.example.com 1073 Content-Disposition: info-package 1075 1076 1082 1084 1086 Figure 10: INFO requesting MSD 1088 Figure 11 illustrates a SIP eCall INFO that contains an MSD. For 1089 simplicity, the example does not show all SIP headers. Because the 1090 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1091 cannot be included in a text document. 1093 INFO urn:service:sos.ecall.automatic SIP/2.0 1094 To: urn:service:sos.ecall.automatic 1095 From: ;tag=9fxced76sl 1096 Call-ID: 3848276298220188511@atlanta.example.com 1097 Call-Info: cid:4567890123@atlanta.example.com; 1098 purpose=emergencyCallData.eCall.MSD; 1099 Accept: application/sdp, application/pidf+xml, 1100 application/emergencyCallData.eCall.control+xml 1101 CSeq: 51862 INFO 1102 Recv-Info: emergencyCallData.eCall.MSD 1103 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1104 SUBSCRIBE, NOTIFY, UPDATE 1105 Content-Type: application/emergencyCallData.eCall.MSD+per 1106 Content-ID: 4567890123@atlanta.example.com 1107 Content-Disposition: info-package 1108 Content-Transfer-Encoding: binary 1110 ...MSD in ASN.1 PER encoding goes here... 1112 Figure 11: INFO containing MSD 1114 12. Security Considerations 1116 The security considerations described in [RFC5069] apply here. 1118 In addition to any network-provided location (which might be 1119 determined solely by the network, or in cooperation with or possibly 1120 entirely by the originating device), an eCall carries an IVS-supplied 1121 location within the MSD. This is likely to be useful to the PSAP, 1122 especially when no network-provided location is included, or when the 1123 two locations are independently determined. Even in situations where 1124 the network-supplied location is limited to the cell site, this can 1125 be useful as a sanity check on the device-supplied location contained 1126 in the MSD. 1128 The document [RFC7378] discusses trust issues regarding location 1129 provided by or determined in cooperation with end devices. 1131 Security considerations specific to the mechanism by which the PSAP 1132 sends acknowledgments and requests to the vehicle are discussed in 1133 the "Security Considerations" block of Section 15.3. 1135 Data received from external sources inherently carries implementation 1136 risks. For example, depending on the platform, buffer overflows can 1137 introduce remote code execution vulnerabilities, null characters can 1138 corrupt strings, numeric values used for internal calculations can 1139 result in underflow/overflow errors, malformed XML objects can expose 1140 parsing bugs, etc. Implementations need to be cognizant of the 1141 potential risks, observe best practices (which might include 1142 sufficiently capable static code analysis, fuzz testing, component 1143 isolation, avoiding use of unsafe coding techniques, third-party 1144 attack tests, signed software, over-the-air updates, etc.), and have 1145 multiple levels of protection. Implementors need to be aware that, 1146 potentially, the data objects described here and elsewhere might be 1147 malformed, might contain unexpected characters, excessively long 1148 attribute values, elements, etc. 1150 The security considerations discussed in [RFC7852] apply here (see 1151 especially the discussion of TLS, TLS versions, cypher suites, and 1152 PKI). 1154 When vehicle data or control/metadata is contained in a signed or 1155 encrypted body part, the enclosing multipart (e.g., multipart/signed 1156 or multipart/encrypted) has the same Content-ID as the enclosed data 1157 part. This allows an entity to identify and access the data blocks 1158 it is interested in without having to dive deeply into the message 1159 structure or decrypt parts it is not interested in. (The 'purpose' 1160 parameter in a Call-Info header field identifies the data and 1161 contains a CID URL pointing to the data block in the body, which has 1162 a matching Content-ID body part header field). 1164 13. Privacy Considerations 1166 The privacy considerations discussed in [RFC7852] apply here. The 1167 MSD carries some identifying and personal information (mostly about 1168 the vehicle and less about the owner), as well as location 1169 information, and so needs to be protected against unauthorized 1170 disclosure. Local regulations may impose additional privacy 1171 protection requirements. 1173 Privacy considerations specific to the data structure containing 1174 vehicle information are discussed in the "Security Considerations" 1175 block of Section 15.2. 1177 Privacy considerations specific to the mechanism by which the PSAP 1178 sends acknowledgments and requests to the vehicle are discussed in 1179 the "Security Considerations" block of Section 15.3. 1181 14. XML Schema 1183 This section defines an XML schema for the eCall control block. The 1184 text description of the eCall control block in Section 9.1 is 1185 normative and supersedes any conflicting aspect of this schema. 1187 1188 1190 1198 1201 1204 1205 1206 1207 1208 1210 1211 1212 1215 1216 1217 1218 1219 1221 1222 1223 1224 1225 1227 1228 1231 1234 1236 1237 conditionally 1238 mandatory when @success='false" 1239 to indicate reason code for a 1240 failure 1241 1242 1243 1245 1246 1247 1248 1251 1252 1255 1257 1258 1259 1260 1262 1263 1264 1265 1266 1270 1273 1274 1275 1276 1277 1279 1280 1281 1282 1283 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1299 1301 Figure 12: eCall Control Block Schema 1303 15. IANA Considerations 1305 15.1. Service URN Registrations 1307 IANA is requested to register the URN 'urn:service:sos.ecall' under 1308 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1310 This service requests resources associated with an emergency call 1311 placed by an in-vehicle system, carrying a standardized set of data 1312 related to the vehicle and incident. Two sub-services are registered 1313 as well: 1315 urn:service:sos.ecall.manual 1317 Used with an eCall invoked due to manual interaction by a vehicle 1318 occupant. 1320 urn:service:sos.ecall.automatic 1322 Used with an eCall invoked automatically, for example, due to a 1323 crash or other serious incident. 1325 IANA is also requested to register the URN 1326 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1327 defined in Setcion 17.2 of [RFC6881]. 1329 15.2. MIME Content-type Registration for 'application/ 1330 emergencyCallData.eCall.MSD+per' 1332 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1333 as a MIME content type, with a reference to this document, in 1334 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1335 RFC 7303 [RFC7303]. 1337 MIME media type name: application 1339 MIME subtype name: emergencyCallData.eCall.MSD+per 1341 Mandatory parameters: none 1343 Optional parameters: none 1345 Encoding scheme: binary 1347 Encoding considerations: Uses ASN.1 PER, which is a binary 1348 encoding; when transported in SIP, binary content transfer 1349 encoding is used. 1351 Security considerations: This content type is designed to carry 1352 vehicle and incident-related data during an emergency call. This 1353 data contains personal information including vehicle VIN, 1354 location, direction, etc. Appropriate precautions need to be 1355 taken to limit unauthorized access, inappropriate disclosure to 1356 third parties, and eavesdropping of this information. In general, 1357 it is acceptable for the data to be unprotected while briefly in 1358 transit within the Mobile Network Operator (MNO); the MNO is 1359 trusted to not permit the data to be accessed by third parties. 1360 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1362 Interoperability considerations: None 1364 Published specification: Annex A of EN 15722 [msd] 1366 Applications which use this media type: Pan-European eCall 1367 compliant systems 1369 Additional information: None 1371 Magic Number: None 1373 File Extension: None 1375 Macintosh file type code: 'BINA' 1376 Person and email address for further information: Randall Gellens, 1377 rg+ietf@randy.pensive.org 1379 Intended usage: LIMITED USE 1381 Author: The MSD specification was produced by the European 1382 Committee For Standardization (CEN). For contact information, 1383 please see . 1385 Change controller: The European Committee For Standardization 1386 (CEN) 1388 15.3. MIME Content-type Registration for 'application/ 1389 emergencyCallData.eCall.control+xml' 1391 IANA is requested to add application/ 1392 emergencyCallData.eCall.control+xml as a MIME content type, with a 1393 reference to this document, in accordance to the procedures of RFC 1394 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1396 MIME media type name: application 1398 MIME subtype name: emergencyCallData.eCall.control+xml 1400 Mandatory parameters: none 1402 Optional parameters: charset 1404 Indicates the character encoding of the XML content. 1406 Encoding considerations: Uses XML, which can employ 8-bit 1407 characters, depending on the character encoding used. See 1408 Section 3.2 of RFC 7303 [RFC7303]. 1410 Security considerations: 1412 This content type carries metadata and control information and 1413 requests, such as from a Public Safety Answering Point (PSAP) 1414 to an In-Vehicle System (IVS) during an emergency call. 1416 Metadata (such as an acknowledgment that data sent by the IVS 1417 to the PSAP was successfully received) has limited privacy and 1418 security implications. Control information (such as requests 1419 from the PSAP that the vehicle perform an action) has some 1420 privacy and security implications. The privacy concern arises 1421 from the ability to request the vehicle to transmit a data set, 1422 which as described in Section 15.2, can contain personal 1423 information. The security concern is the ability to request 1424 the vehicle to perform an action. Control information needs to 1425 originate only from a PSAP or other emergency services 1426 provider, and not be modified en-route. The level of integrity 1427 of the cellular network over which the emergency call is placed 1428 is a consideration: when the IVS initiates an eCall over a 1429 cellular network, in most cases it relies on the MNO to route 1430 the call to a PSAP. (Calls placed using other means, such as 1431 Wi-Fi or over-the-top services, generally incur somewhat higher 1432 levels of risk than calls placed "natively" using cellular 1433 networks.) A call-back from a PSAP merits additional 1434 consideration, since current mechanisms are not ideal for 1435 verifying that such a call is indeed a call-back from a PSAP in 1436 response to an emergency call placed by the IVS. See the 1437 discussion in Section 12 and the PSAP Callback document 1438 [RFC7090]. 1440 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1442 Interoperability considerations: None 1444 Published specification: This document 1446 Applications which use this media type: Pan-European eCall 1447 compliant systems 1449 Additional information: None 1451 Magic Number: None 1453 File Extension: .xml 1455 Macintosh file type code: 'TEXT' 1457 Person and email address for further information: Randall Gellens, 1458 rg+ietf@randy.pensive.org 1460 Intended usage: LIMITED USE 1462 Author: The IETF ECRIT WG. 1464 Change controller: The IETF ECRIT WG. 1466 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1467 Additional Data Blocks registry 1469 This specification requests IANA to add the 'eCall.MSD' entry to the 1470 Emergency Call Additional Data Blocks registry, with a reference to 1471 this document. 1473 15.5. Registration of the 'eCall.control' entry in the Emergency Call 1474 Additional Data Blocks registry 1476 This specification requests IANA to add the 'eCall.control' entry to 1477 the Emergency Call Additional Data Blocks registry, with a reference 1478 to this document. 1480 15.6. Registration of the emergencyCallData.eCall Info Package 1482 IANA is requested to add emergencyCallData.eCall to the Info Packages 1483 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1484 reference to this document. 1486 15.7. URN Sub-Namespace Registration 1488 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1490 This section registers a new XML namespace, as per the guidelines in 1491 RFC 3688 [RFC3688]. 1493 URI: urn:ietf:params:xml:ns:eCall 1495 Registrant Contact: IETF, ECRIT working group, , as 1496 delegated by the IESG . 1498 XML: 1500 BEGIN 1501 1502 1504 1505 1506 1508 Namespace for eCall Data 1509 1510 1511

Namespace for eCall Data

1512

See [TBD: This document].

1513 1514 1515 END 1517 15.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1519 This section registers a new XML namespace, as per the guidelines in 1520 RFC 3688 [RFC3688]. 1522 URI: urn:ietf:params:xml:ns:eCall:control 1524 Registrant Contact: IETF, ECRIT working group, , as 1525 delegated by the IESG . 1527 XML: 1529 BEGIN 1530 1531 1533 1534 1535 1537 Namespace for eCall Data: 1538 Control Block 1539 1540 1541

Namespace for eCall Data

1542

Control Block

1543

See [TBD: This document].

1544 1545 1546 END 1548 15.8. Registry creation 1550 This document creates a new registry called 'eCall Metadata/Control 1551 Data'. The following sub-registries are created for this registry. 1553 15.8.1. Action Registry 1555 This document creates a new sub-registry called "Action Registry". 1556 As defined in [RFC5226], this registry operates under "Expert Review" 1557 rules. The expert should determine that the proposed action is 1558 within the purview of a vehicle, is sufficiently distinguishable from 1559 other actions, and the action is clearly and fully described. In 1560 most cases, a published and stable document is referenced for the 1561 description of the action. 1563 The content of this registry includes: 1565 Name: The identifier to be used in the 'action' attribute of an 1566 eCall control element. 1568 Description: A description of the action. In most cases this will 1569 be a reference to a published and stable document. The 1570 description MUST specify if any attributes or child elements are 1571 optional or mandatory, and describe the action to be taken by the 1572 vehicle. 1574 The initial set of values is listed in Table 2. 1576 +-----------+--------------------------------------+ 1577 | Name | Description | 1578 +-----------+--------------------------------------+ 1579 | send-data | See Section 9.1.3.1 of this document | 1580 +-----------+--------------------------------------+ 1582 Table 2: Action Registry Initial Values 1584 15.8.2. Reason Registry 1586 This document creates a new sub-registry called "Reason Registry" 1587 which contains values for the 'reason' attribute of the 1588 element. As defined in [RFC5226], this registry 1589 operates under "Expert Review" rules. The expert should determine 1590 that the proposed reason is sufficiently distinguishable from other 1591 reasons and that the proposed description is understandable and 1592 correctly worded. 1594 The content of this registry includes: 1596 ID: A short string identifying the reason, for use in the 'reason' 1597 attribute of an element. 1599 Description: A description of the reason. 1601 The initial set of values is listed in Table 3. 1603 +------------------+------------------------------------------------+ 1604 | ID | Description | 1605 +------------------+------------------------------------------------+ 1606 | unsupported | The 'action' value is not supported. | 1607 | | | 1608 | unable | The action could not be accomplished. | 1609 | | | 1610 | data-unsupported | The data item referenced in a 'send-data' | 1611 | | request is not supported. | 1612 | | | 1613 | security-failure | The authenticity of the request or the | 1614 | | authority of the requestor could not be | 1615 | | verified. | 1616 +------------------+------------------------------------------------+ 1618 Table 3: Reason Registry 1620 16. Contributors 1622 Brian Rosen was a co-author of the original document upon which this 1623 document is based. 1625 17. Acknowledgements 1627 We would like to thank Bob Williams and Ban Al-Bakri for their 1628 feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith 1629 Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and 1630 James Winterbottom for their review and comments; Robert Sparks and 1631 Paul Kyzivat for their help with the SIP mechanisms. We would like 1632 to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and 1633 Ulrich Dietz for their help with the original document upon which 1634 this document is based. 1636 18. Changes from Previous Versions 1638 18.1. Changes from draft-ietf-09 to draft-ietf-11 1640 o Renamed INFO package to emergencyCallData.eCall.MSD 1641 o Changed INFO package to only permit MSD and metadata/control MIME 1642 types 1643 o Moved element back from car-crash but made it 1644 OPTIONAL 1645 o Moved other extension points back from car-crash so that extension 1646 points are in base spec (and also to get XML schema to compile) 1647 o Text changes for clarification. 1649 18.2. Changes from draft-ietf-08 to draft-ietf-09 1651 o Created a new "Data Transport" section that describes how the MSD 1652 and metadata/control blocks are attached, and then referred to 1653 that section rather than repeat the information about the CID and 1654 Call-Info and so forth, which means most references to the 1655 additional-data draft have now been deleted 1656 o Mentioned edge cases where a PSAP response to INVITE isn't 1657 received by the IVS 1658 o Reworded description of which status codes are used when a PSAP 1659 wishes to reject a call but inform the vehicle occupants that it 1660 is aware of the situation to be more definite 1661 o Added examples showing INFO 1662 o Added references for eCall test call requirement 1663 o Described meaning of eCall URNs in Section 8 as well as in IANA 1664 registration 1666 18.3. Changes from draft-ietf-07 to draft-ietf-08 1668 o eCall MSD now encoded as ASN.1 PER, using binary content transfer 1669 encoding 1670 o Added text to point out aspects of call handling and metadata/ 1671 control usage, such as use in rejected calls, and solicited MSDs 1672 o Revised use of INFO to require that when a request for an MSD is 1673 sent in INFO, the MSD sent in response is in its own INFO, not the 1674 response to the requesting INFO 1675 o Added material to INFO package registation to comply with 1676 Section 10 of [RFC6086] 1677 o Moved material not required by 3GPP into 1678 [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ 1679 control elements, attributes, and values 1680 o Revised test call wording to clarify that specific handling is out 1681 of scope 1682 o Revised wording throughout the document to simplify 1683 o Moved new Section Section 7.1 to be a subsection of Section 7 1684 o Moved new Section Section 10 to be a main section instead of a 1685 subsection of Section 9 1686 o Revised SIP INFO usage and package registration per advice from 1687 Robert Sparks and Paul Kyzivat 1689 18.4. Changes from draft-ietf-06 to draft-ietf-07 1691 o Fixed typo in Acknowledgements 1693 18.5. Changes from draft-ietf-05 to draft-ietf-06 1695 o Added additional security and privacy clarifications regarding 1696 signed and encrypted data 1697 o Additional security and privacy text 1698 o Deleted informative section on ESINets as unnecessary. 1700 18.6. Changes from draft-ietf-04 to draft-ietf-05 1702 o Reworked the security and privacy considerations material in the 1703 document as a whole and in the MIME registation sections of the 1704 MSD and control objects 1705 o Clarified that the element can appear multiple 1706 times within an element 1707 o Fixed IMS definition 1708 o Added clarifying text for the 'msgid' attribute 1710 18.7. Changes from draft-ietf-03 to draft-ietf-04 1712 o Added Privacy Considerations section 1713 o Reworded most uses of non-normative "may", "should", "must", and 1714 "recommended." 1715 o Fixed nits in examples 1717 18.8. Changes from draft-ietf-02 to draft-ietf-03 1719 o Added request to enable cameras 1720 o Improved examples and XML schema 1721 o Clarifications and wording improvements 1723 18.9. Changes from draft-ietf-01 to draft-ietf-02 1725 o Added clarifying text reinforcing that the data exchange is for 1726 small blocks of data infrequently transmitted 1727 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1728 establish a one-way media stream 1729 o Clarified that the scope is the needs of eCall within the SIP 1730 emergency call environment 1731 o Added informative statement that the document may be suitable for 1732 reuse by other ACN systems 1733 o Clarified that normative language for the control block applies to 1734 both IVS and PSAP 1735 o Removed 'ref', 'supported-mime', and elements 1736 o Minor wording improvements and clarifications 1738 18.10. Changes from draft-ietf-00 to draft-ietf-01 1740 o Added further discussion of test calls 1741 o Added further clarification to the document scope 1742 o Mentioned that multi-region vehicles may need to support other 1743 crash notification specifications in addition to eCall 1744 o Added details of the eCall metadata and control functionality 1745 o Added IANA registration for the MIME content type for the eCall 1746 control object 1747 o Added IANA registries for protocol elements and tokens used in the 1748 eCall control object 1749 o Minor wording improvements and clarifications 1751 18.11. Changes from draft-gellens-03 to draft-ietf-00 1753 o Renamed from draft-gellens- to draft-ietf-. 1754 o Added mention of and reference to ETSI TR "Mobile Standards Group 1755 (MSG); eCall for VoIP" 1756 o Added text to Introduction regarding migration/co-existence being 1757 out of scope 1758 o Added mention in Security Considerations that even if the network- 1759 supplied location is just the cell site, this can be useful as a 1760 sanity check on the IVS-supplied location 1761 o Minor wording improvements and clarifications 1763 18.12. Changes from draft-gellens-02 to -03 1765 o Clarifications and editorial improvements. 1767 18.13. Changes from draft-gellens-01 to -02 1769 o Minor wording improvements 1770 o Removed ".automatic" and ".manual" from 1771 "urn:service:test.sos.ecall" registration and discussion text. 1773 18.14. Changes from draft-gellens-00 to -01 1775 o Now using 'EmergencyCallData' for purpose parameter values and 1776 MIME subtypes, in accordance with changes to [RFC7852] 1777 o Added reference to RFC 6443 1778 o Fixed bug that caused Figure captions to not appear 1780 19. References 1781 19.1. Normative References 1783 [EN_16062] 1784 CEN, , "Intelligent transport systems - eSafety - eCall 1785 High Level Application Requirements (HLAP) Using GSM/UMTS 1786 Circuit Switched Networks, EN 16062", April 2015. 1788 [EN_16072] 1789 CEN, , "Intelligent transport systems - eSafety - Pan- 1790 European eCall operating requirements, EN 16072", April 1791 2015. 1793 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1794 minimum set of data (MSD), EN 15722", April 2015. 1796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1797 Requirement Levels", BCP 14, RFC 2119, 1798 DOI 10.17487/RFC2119, March 1997, 1799 . 1801 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1802 DOI 10.17487/RFC3688, January 2004, 1803 . 1805 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1806 Emergency and Other Well-Known Services", RFC 5031, 1807 DOI 10.17487/RFC5031, January 2008, 1808 . 1810 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1811 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1812 DOI 10.17487/RFC5226, May 2008, 1813 . 1815 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1816 "Framework for Emergency Calling Using Internet 1817 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1818 2011, . 1820 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1821 Specifications and Registration Procedures", BCP 13, 1822 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1823 . 1825 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1826 Communications Services in Support of Emergency Calling", 1827 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1828 . 1830 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1831 DOI 10.17487/RFC7303, July 2014, 1832 . 1834 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1835 J. Winterbottom, "Additional Data Related to an Emergency 1836 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1837 . 1839 [TS22.101] 1840 3GPP, , "3GPP TS 22.101: Technical Specification Group 1841 Services and System Aspects; Service aspects; Service 1842 principles". 1844 19.2. Informative references 1846 [CEN] "European Committee for Standardization", 1847 . 1849 [I-D.ietf-ecrit-car-crash] 1850 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1851 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1852 ecrit-car-crash-08 (work in progress), July 2016. 1854 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1855 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1856 April 2014. 1858 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1859 Emergency Context Resolution with Internet Technologies", 1860 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1861 . 1863 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1864 Shanmugam, "Security Threats and Requirements for 1865 Emergency Call Marking and Mapping", RFC 5069, 1866 DOI 10.17487/RFC5069, January 2008, 1867 . 1869 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1870 Initiation Protocol (SIP) INFO Method and Package 1871 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1872 . 1874 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1875 Patel, "Public Safety Answering Point (PSAP) Callback", 1876 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1877 . 1879 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1880 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1881 December 2014, . 1883 [SDO-3GPP] 1884 "3d Generation Partnership Project", 1885 . 1887 [SDO-ETSI] 1888 "European Telecommunications Standards Institute (ETSI)", 1889 . 1891 Authors' Addresses 1893 Randall Gellens 1894 Core Technology Consulting 1896 Email: rg+ietf@randy.pensive.org 1898 Hannes Tschofenig 1899 Individual 1901 Email: Hannes.Tschofenig@gmx.net 1902 URI: http://www.tschofenig.priv.at