idnits 2.17.00 (12 Aug 2021) /tmp/idnits53953/draft-ietf-ecrit-ecall-18.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 9 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 (October 17, 2016) is 2041 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: April 20, 2017 Individual 6 October 17, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-18.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 INFO 24 requests. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 20, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 7 64 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 11 69 9.1. The Control Block . . . . . . . . . . . . . . . . . . . . 12 70 9.1.1. The element . . . . . . . . . . . . . . . . . . 13 71 9.1.1.1. Attributes of the element . . . . . . . . . 13 72 9.1.1.2. Child Element of the element . . . . . . . 14 73 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 15 74 9.1.2. The element . . . . . . . . . . . . . 15 75 9.1.2.1. Child Elements of the element . . 15 76 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15 77 9.1.3. The element . . . . . . . . . . . . . . . . 16 78 9.1.3.1. Attributes of the element . . . . . . . 16 79 9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 18 80 10. The emergencyCallData.eCall.MSD INFO package . . . . . . . . 18 81 10.1. Overall Description . . . . . . . . . . . . . . . . . . 18 82 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . 19 83 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . 19 84 10.4. Info Package Parameters . . . . . . . . . . . . . . . . 19 85 10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 19 86 10.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 19 87 10.7. Info Package Usage Restrictions . . . . . . . . . . . . 20 88 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 20 89 10.9. Info Package Security Considerations . . . . . . . . . . 20 90 10.10. Implementation Details . . . . . . . . . . . . . . . . . 20 91 10.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21 92 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 94 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 95 14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 97 15.1. Service URN Registrations . . . . . . . . . . . . . . . 30 98 15.2. MIME Media Type Registration for 99 'application/emergencyCallData.eCall.MSD+per' . . . . . 31 100 15.3. MIME Media Type Registration for 101 'application/emergencyCallData.control+xml' . . . . . . 32 102 15.4. Registration of the 'eCall.MSD' entry in the Emergency 103 Call Additional Data Blocks registry . . . . . . . . . . 34 104 15.5. Registration of the 'control' entry in the Emergency 105 Call Additional Data Blocks registry . . . . . . . . . . 34 106 15.6. Registration of the emergencyCallData.eCall Info Package 34 107 15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34 108 15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34 109 15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35 110 15.8. Registry creation . . . . . . . . . . . . . . . . . . . 36 111 15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 36 112 15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 37 113 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 114 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 115 18. Changes from Previous Versions . . . . . . . . . . . . . . . 38 116 18.1. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 117 18.2. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 118 18.3. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 38 119 18.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 120 18.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 39 121 18.6. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 39 122 18.7. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 39 123 18.8. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39 124 18.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 125 18.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 40 126 18.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40 127 18.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40 128 18.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40 129 18.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 41 130 18.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41 131 18.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41 132 18.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41 133 18.18. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41 134 18.19. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42 135 18.20. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42 136 18.21. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42 137 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 138 19.1. Normative References . . . . . . . . . . . . . . . . . . 42 139 19.2. Informative references . . . . . . . . . . . . . . . . . 43 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 142 1. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 This document re-uses terminology defined in Section 3 of [RFC5012]. 150 Additionally, we use the following abbreviations: 152 +--------+----------------------------------------+ 153 | Term | Expansion | 154 +--------+----------------------------------------+ 155 | 3GPP | 3rd Generation Partnership Project | 156 | | | 157 | CEN | European Committee for Standardization | 158 | | | 159 | EENA | European Emergency Number Association | 160 | | | 161 | ESInet | Emergency Services IP network | 162 | | | 163 | IMS | IP Multimedia Subsystem | 164 | | | 165 | IVS | In-Vehicle System | 166 | | | 167 | MNO | Mobile Network Operator | 168 | | | 169 | MSD | Minimum Set of Data | 170 | | | 171 | PSAP | Public Safety Answering Point | 172 +--------+----------------------------------------+ 174 2. Document Scope 176 This document is focused on the signaling, data exchange, and 177 protocol needs of next-generation eCall (NG-eCall, also referred to 178 as packet-switched eCall or all-IP eCall) within the SIP framework 179 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 180 itself is specified by 3GPP (3rd Generation Partnership Project) and 181 CEN (European Committee for Standardization) and these specifications 182 include far greater scope than is covered here. 184 The eCall service operates over cellular wireless communication, but 185 this document does not address cellular-specific details, nor client 186 domain selection (e.g., circuit-switched versus packet-switched). 187 All such aspects are the purview of their respective standards 188 bodies. The scope of this document is limited to eCall operating 189 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling 190 [TS23.167]). 192 The technical contents of this document also provide a basis for 193 reuse and extension for related emergency call systems (which is why 194 there are extension points), but such reuse is a topic for other 195 documents. 197 Note that vehicles designed for multiple regions might need to 198 support eCall and other Advanced Automatic Crash Notification (AACN) 199 systems (such as described in [I-D.ietf-ecrit-car-crash]), but this 200 is out of scope of this document. 202 3. Introduction 204 Emergency calls made from vehicles (e.g., in the event of a crash) 205 assist in significantly reducing road deaths and injuries by allowing 206 emergency services to be aware of the incident, the state of the 207 vehicle, the location of the vehicle, and to have a voice channel 208 with the vehicle occupants. This enables a quick and appropriate 209 response. 211 The European Commission initiative of eCall was conceived in the late 212 1990s, and has evolved to a European Parliament decision requiring 213 the implementation of a compliant in-vehicle system (IVS) in new 214 vehicles and the deployment of eCall in the European Member States in 215 the very near future. Other regions are developing eCall-compatible 216 systems. 218 The pan-European eCall system provides a standardized and mandated 219 mechanism for emergency calls by vehicles. eCall establishes 220 procedures for such calls to be placed by in-vehicle systems, 221 recognized and processed by the mobile network, and routed to a 222 specialized PSAP where the vehicle data is available to assist the 223 call taker in assessing and responding to the situation. eCall 224 provides a standard set of vehicle, sensor (e.g., crash related), and 225 location data. 227 An eCall can be either user-initiated or automatically triggered. 228 Automatically triggered eCalls indicate a car crash or some other 229 serious incident. Manually triggered eCalls might be reports of 230 witnessed crashes or serious hazards. PSAPs might apply specific 231 operational handling to manual and automatic eCalls. 233 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 234 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 235 call setup mark the call as an eCall, and further indicate if the 236 call was automatically or manually triggered. The call is routed to 237 an eCall-capable PSAP, a voice channel is established between the 238 vehicle and the PSAP, and an eCall in-band modem is used to carry a 239 defined set of vehicle, sensor (e.g., crash related), and location 240 data (the Minimum Set of Data or MSD) within the voice channel. The 241 same in-band mechanism is used for the PSAP to acknowledge successful 242 receipt of the MSD, and to request the vehicle to send a new MSD 243 (e.g., to check if the state of or location of the vehicle or its 244 occupants has changed). NG-eCall moves from circuit switched to all- 245 IP, and carries the vehicle data and eCall signaling as additional 246 data carried with the call. This document describes how IETF 247 mechanisms for IP-based emergency calls, including [RFC6443] and 248 [RFC7852] are used to provide the signaling and data exchange of the 249 next generation of pan-European eCall. 251 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 252 has published a Technical Report titled "Mobile Standards Group 253 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 254 recommendations regarding support for eCall in an all-IP environment. 255 The recommendations include the use of 3GPP IMS emergency calling 256 with additional elements identifying the call as an eCall and as 257 carrying eCall data and with mechanisms for carrying the data and 258 eCall signaling. 3GPP IMS emergency services support multimedia, 259 providing the ability to carry voice, text, and video. This 260 capability is referred to within 3GPP as Multimedia Emergency 261 Services (MMES). 263 A transition period will exist during which time the various entities 264 involved in initiating and handling an eCall might support next- 265 generation eCall, legacy eCall, or both. The issues of migration and 266 co-existence during the transition period are outside the scope of 267 this document. 269 This document indicates how to use IP-based emergency services 270 mechanisms to support next-generation eCall. 272 This document also registers MIME media types and an Emergency Call 273 Additional Data Block for the eCall vehicle data (MSD) and metadata/ 274 control data, and an INFO package to enable carrying this data in 275 INFO requests. 277 The MSD is carried in the MIME type 'application/ 278 emergencyCallData.eCall.MSD+per' and the metadata/control block is 279 carried in the MIME type 'application/emergencyCallData.control+xml' 280 (both of which are registered in Section 15) An INFO package is 281 defined (in Section 10) to enable these MIME types to be carried in 282 SIP INFO requests, per [RFC6086]. 284 4. eCall Requirements 286 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 287 [TS22.101] clauses 10.7 and A.27 and [TS24.229] section 4.7.6. 288 Requirements specific to vehicle data are contained in EN 15722 289 [msd]. 291 5. Vehicle Data 293 Pan-European eCall provides a standardized and mandated set of 294 vehicle related data, known as the Minimum Set of Data (MSD). The 295 European Committee for Standardization (CEN) has specified this data 296 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 297 circuit-switched eCall and this document use the ASN.1 PER encoding, 298 which is specified in Annex A of EN 15722 [msd] (the XML encoding 299 specified in Annex C is not used in this document). 301 This document registers the 'application/ 302 emergencyCallData.eCall.MSD+per' MIME media type to enable the MSD to 303 be carried in SIP. As an ASN.1 PER encoded object, the data is 304 binary and transported using binary content transfer encoding within 305 SIP messages. This document also adds the 'eCall.MSD' entry to the 306 Emergency Call Additional Data Blocks registry to enable the MSD to 307 be recognized as such in a SIP-based eCall emergency call. (See 308 [RFC7852] for more information about the registry and how it is 309 used.) 311 See Section 6 for a discussion of how the MSD vehicle data is 312 conveyed in an NG-eCall. 314 6. Data Transport 316 [RFC7852] establishes a general mechanism for attaching blocks of 317 data to a SIP emergency call. This mechanism permits certain 318 emergency call MIME types to be attached to SIP messages. This 319 document makes use of that mechanism. This document also registers 320 an INFO package (in Section 10) to enable eCall related data blocks 321 to be carried in SIP INFO requests (per [RFC6086], new INFO usages 322 require the definition of an INFO package). 324 Note that if other data sets need to be transmitted in the future, 325 the appropriate signalling mechanism for such data needs to be 326 evaluated, including factors such as the size and frequency of such 327 data. 329 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 330 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 331 message as a MIME body part per [RFC7852]. The body part is 332 identified by its MIME media type ('application/ 333 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 334 the body part. The body part is assigned a unique identifier which 335 is listed in a Content-ID header field in the body part. The SIP 336 message is marked as containing the MSD by adding (or appending to) a 337 Call-Info header field at the top level of the SIP message. This 338 Call-Info header field contains a CID URL referencing the body part's 339 unique identifier, and a 'purpose' parameter identifying the data as 340 the eCall MSD per the Emergency Call Additional Data Blocks registry 341 entry; the 'purpose' parameter's value is 342 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 343 SIP INFO request by using the INFO package defined in Section 10. 345 A PSAP or IVS transmits a metadata/control object (see Section 9) by 346 encoding it per the description in this document and attaching it to 347 a SIP message as a MIME body part per [RFC7852]. The body part is 348 identified by its MIME media type ('application/ 349 emergencyCallData.control+xml') in the Content-Type header field of 350 the body part. The body part is assigned a unique identifier which 351 is listed in a Content-ID header field in the body part. The SIP 352 message is marked as containing the metadata/control object by adding 353 (or appending to) a Call-Info header field at the top level of the 354 SIP message. This Call-Info header field contains a CID URL 355 referencing the body part's unique identifier, and a 'purpose' 356 parameter identifying the data as an eCall metadata/control block per 357 the Emergency Call Additional Data Blocks registry entry; the 358 'purpose' parameter's value is 'emergencyCallData.control'. Per 359 [RFC6086], a metadata/control object is carried in a SIP INFO request 360 by using the INFO package defined in Section 10. 362 An MSD or a metadata/control block is always enclosed in a multipart 363 body part (even if it would otherwise be the only body part in the 364 SIP message), since as of the date of this document, the use of 365 Content-ID as a SIP header field is not defined (while it is defined 366 for use as a MIME header field). 368 A body part containing an MSD or metadata/control object has a 369 Content-Disposition header field value containing "By-Reference". 371 An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to 372 the initial INVITE and optionally attaches a metadata/control object 373 informing the PSAP of its capabilities. The MSD body part (and 374 metadata/control and PIDF-LO body parts if included) have a Content- 375 Disposition header field with the value "By-Reference; 376 handling=optional". Specifying "handling=optional" prevents the 377 INVITE from being rejected if it is processed by a legacy element 378 (e.g., a gateway between SIP and circuit-switched environments) that 379 does not understand the MSD (or metadata/control object or PIDF-LO). 381 The PSAP creates a metadata/control object acknowledging receipt of 382 the MSD and attaches it to the SIP final response to the INVITE. A 383 metadata/control object is not attached to provisional (e.g., 180) 384 responses. 386 A PSAP is able to reject a call while indicating that it is aware of 387 the situation by including a metadata/control object acknowledging 388 the MSD and containing "received=true" in a final response using SIP 389 response code 600 (Busy Everywhere), 486 (Busy Here), or 603 390 (Decline). 392 If the IVS receives an acknowledgment for an MSD containing 393 "received=false", this indicates that the PSAP was unable to properly 394 decode or process the MSD. The IVS action is not defined (e.g., it 395 might only log an error). Since the PSAP is able to request an 396 updated MSD during the call, if an initial MSD is unsatisfactory in 397 any way, the PSAP can choose to request another one. 399 A PSAP can request that the vehicle send an updated MSD during a 400 call. To do so, the PSAP creates a metadata/control object 401 requesting an MSD and attaches it to a SIP INFO request and sends it 402 within the dialog. The IVS then attaches an updated MSD to a SIP 403 INFO request and sends it within the dialog. If the IVS is unable to 404 send an MSD, it instead sends a metadata/control object acknowledging 405 the request with the 'success' parameter set to 'false' and a 406 'reason' parameter (and optionally a 'details' parameter) indicating 407 why the request could not be accomplished. Per [RFC6086], metadata/ 408 control objects and MSDs are sent using the INFO package defined in 409 Section 10 . In addition, to align with how an MSD or metadata/ 410 control block is transmitted in a SIP message other than an INFO 411 request, a Call-Info header field is included in the SIP INFO request 412 to reference the MSD or metadata/control block. See Section 10 for 413 information about the use of INFO requests to carry data within an 414 eCall. 416 The IVS is not expected to send an unsolicited MSD after the initial 417 INVITE. 419 Support for the data blocks defined in [RFC7852] is NOT REQUIRED for 420 conformance with this document. 422 7. Call Setup 424 In circuit-switched eCall, the IVS places a special form of a 112 425 emergency call which carries an eCall flag (indicating that the call 426 is an eCall and also if the call was manually or automatically 427 triggered); the mobile network operator (MNO) recognizes the eCall 428 flag and routes the call to an eCall-capable PSAP; vehicle data is 429 transmitted to the PSAP via the eCall in-band modem (in the voice 430 channel). 432 ///----\\\ 112 voice call with eCall flag +------+ 433 ||| IVS |||---------------------------------------->+ PSAP | 434 \\\----/// vehicle data via eCall in-band modem +------+ 436 Figure 1: circuit-switched eCall 438 For NG-eCall, the IVS establishes an emergency call using a Request- 439 URI indicating a manual or automatic eCall; the MNO (or ESInet) 440 recognizes the eCall URN and routes the call to an NG-eCall capable 441 PSAP; the PSAP interpets the vehicle data sent with the call and 442 makes it available to the call taker. 444 ///----\\\ IMS emergency call with eCall URN +------+ 445 IVS ----------------------------------------->+ PSAP | 446 \\\----/// vehicle data included in call setup +------+ 448 Figure 2: NG-eCall 450 See Section 6 for information on how the MSD is transported within an 451 NG-eCall. 453 This document registers new service URN children within the "sos" 454 subservice. These URNs provide the mechanism by which an eCall is 455 identified, and differentiate between manually and automatically 456 triggered eCalls (which might be subject to different treatment, 457 depending on policy). The two service URNs are: 458 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 459 which requests resources associated with an emergency call placed by 460 an in-vehicle system, carrying a standardized set of data related to 461 the vehicle and incident. 463 Call routing is outside the scope of this document. 465 8. Test Calls 467 eCall requires the ability to place test calls (see [TS22.101] clause 468 10.7 and [EN_16062] clause 7.2.2). These are calls that are 469 recognized and treated to some extent as eCalls but are not given 470 emergency call treatment and are not handled by call takers. The 471 specific handling of test eCalls is not itself standardized; 472 typically, the test call facility allows the IVS or user to verify 473 that an eCall can be successfully established with voice 474 communication. The IVS might also be able to verify that the MSD was 475 successfully received. 477 A service URN starting with "test." indicates a test call. For 478 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 479 This functionality is defined in [RFC6881]. 481 This document registers "urn:service:test.sos.ecall" for eCall test 482 calls. 484 The CS-eCall test call facility is a non-emergency number so does not 485 get treated as an emergency call. For NG-eCall, MNOs, emergency 486 authorities, and PSAPs can determine how to treat a vehicle call 487 requesting the "test" service URN so that the desired functionality 488 is tested, but this is outside the scope of this document. 490 9. The Metadata/Control Object 492 eCall requires the ability for the PSAP to acknowledge successful 493 receipt of an MSD sent by the IVS, and for the PSAP to request that 494 the IVS send an MSD (e.g., the call taker can initiate a request for 495 a new MSD to see if there have been changes in the vehicle's state, 496 e.g., location, direction, number of fastened seatbelts). 498 This document defines a block of metadata/control data as an XML 499 structure containing elements used for eCall and other related 500 emergency call systems and extension points. (This metadata/control 501 block is in effect a high-level protocol between the PSAP and IVS.) 502 When the PSAP sends a metadata/control block in response to data sent 503 by the IVS in a SIP request other than INFO (e.g., the MSD in the 504 initial INVITE), the metadata/control block is sent in the SIP 505 response to that request (e.g., the response to the INVITE request). 506 When the PSAP sends a control block in other circumstances (e.g., 507 mid-call), the control block is transmitted from the PSAP to the IVS 508 in a SIP INFO request within the established dialog. The IVS sends 509 the requested data (the MSD) in a new INFO request (per [RFC6086]). 510 This mechanism flexibly allows the PSAP to send eCall-specific data 511 to the IVS and the IVS to respond. INFO requests are sent using an 512 appropriate INFO Package. See Section 6 for more information on 513 attaching a metadata/control block to a SIP message. See Section 10 514 for information about the use of INFO requests to carry data within 515 an eCall. 517 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 518 initial INVITE), the PSAP sends a metadata/control block indicating 519 successful/unsuccessful receipt of the MSD in the SIP response to the 520 request. This also informs the IVS that an NG-eCall is in operation. 521 If the IVS receives a SIP final response without the metadata/control 522 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 523 some part of the call is being handled as a legacy call). When the 524 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 525 receipt of a SIP INFO request containing a metadata/control block 526 requesting an MSD), the PSAP does not send a metadata/control block 527 indicating successful or unsuccessful receipt of the MSD. (Normal 528 SIP retransmission handles non-receipt of requested data; note that, 529 per [RFC6086], a 200 OK response to an INFO request indicates only 530 that the receiver has successfully received and accepted the INFO 531 request, it says nothing about the acceptability of the payload.) If 532 the IVS receives a request to send an MSD but it is unable to do so 533 for any reason, the IVS sends a metadata/control object acknowledging 534 the request and containing "success=false" and "reason" set to an 535 appropriate code. 537 This provides flexibility to handle various circumstances. For 538 example, if a PSAP is unable to accept an eCall (e.g., due to 539 overload or too many calls from the same location), it can reject the 540 INVITE. Since a metadata/control object is also included in the SIP 541 response that rejects the call, the IVS knows if the PSAP received 542 the MSD, and can inform the vehicle occupants that the PSAP 543 successfully received the vehicle location and information but can't 544 talk to the occupants at that time. Especially for SIP response 545 codes that indicate an inability to conduct a call (as opposed to a 546 technical inability to process the request), the IVS can also 547 determine that the call was successful on a technical level (e.g., 548 not helpful to retry as a CS-eCall). (Note that there could be edge 549 cases where the PSAP response is not received by the IVS, e.g., if an 550 intermediary sends a CANCEL, and an error response is forwarded 551 towards the IVS before the error response from the PSAP is received, 552 the response will be dropped, but these are unlikely to occur here.) 554 The metadata/control block is carried in the MIME type 'application/ 555 emergencyCallData.control+xml'. 557 The metadata/control block is designed for use with pan-European 558 eCall and also eCall-like systems (i.e., in other regions), and has 559 extension points. Note that eCall-like systems might define their 560 own vehicle data blocks, and so might need to register a new INFO 561 package to accomodate the new data content type and the metadata/ 562 control object. 564 9.1. The Control Block 566 The control block is an XML data structure allowing for 567 acknowledgments, requests, and capabilities information. It is 568 carried in a body part with a specific MIME media type. Three 569 elements are defined for use within a control block: 571 ack Acknowledges receipt of data or a request. 573 capabilities Used in a control block sent from the IVS to the PSAP 574 (e.g., in the initial INVITE) to inform the PSAP of the 575 vehicle capabilities. Child elements contain all 576 actions and data types supported by the vehicle. It is 577 OPTIONAL for the IVS to send this block. Omitting the 578 block indicates that the IVS supports only the 579 mandatory functionality defined in this document. 581 request Used in a control block sent by the PSAP to the IVS, to 582 request the vehicle to perform an action. 584 The element indicates the object being acknowledged and reports 585 success or failure. 587 The element contains attributes to indicate the request and 588 to supply related information. The 'action' attribute is mandatory 589 and indicates the specific action. An IANA registry is created in 590 Section 15.8.1 to contain the allowed values. 592 The element has child elements to indicate 593 the actions supported by the IVS. 595 9.1.1. The element 597 The element acknowledges receipt of an eCall data object or 598 request. An element references the Content-ID of the object 599 being acknowledged. The PSAP MUST send an element 600 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 601 the INVITE); this element indicates if the PSAP considers the 602 MSD successfully received or not. An element is not sent for a 603 element. 605 The element has the following attributes: 607 9.1.1.1. Attributes of the element 609 The element has the following attributes: 611 Name: ref 612 Usage: Mandatory 613 Type: anyURI 614 Direction: Sent in either direction 615 Description: References the Content-ID of the body part being 616 acknowledged. 617 Example: 619 Name: received 620 Usage: Conditional: mandatory in an element sent by a PSAP 621 Type: Boolean 622 Direction: In this document, sent from the PSAP to the IVS 623 Description: Indicates if the referenced object was considered 624 successfully received or not. 625 Example: 627 9.1.1.2. Child Element of the element 629 For extensibility, the element has the following child element: 631 Name: actionResult 632 Usage: Optional 633 Direction: Sent from the IVS to the PSAP 634 Description: An element indicates the result of an 635 action (other than a successfully executed 'send-data' action). 636 The element contains an element for each 637 element that is not a successfully executed 'send-data' 638 action. The element has the following attributes: 640 Name: action 641 Usage: Mandatory 642 Type: token 643 Description: Contains the value of the 'action' attribute of the 644 element 646 Name: success 647 Usage: Mandatory 648 Type: Boolean 649 Description: Indicates if the action was successfully 650 accomplished 652 Name: reason 653 Usage: Conditional 654 Type: token 655 Description: Used when 'success' is "false", this attribute 656 contains a reason code for a failure. A registry for reason 657 codes is defined in Section 15.8.2. 659 Name: details 660 Usage: optional 661 Type: string 662 Description: Contains further explanation of the circumstances of 663 a success or failure. The contents are implementation-specific 664 and human-readable. 666 9.1.1.3. Ack Examples 668 669 673 675 677 Figure 3: Ack Example from PSAP to IVS 679 9.1.2. The element 681 The element is transmitted by the IVS to indicate to 682 the PSAP its capabilities. No attributes for this element are 683 currently defined. The following child elements are defined: 685 9.1.2.1. Child Elements of the element 687 The element has the following child elements: 689 Name: request 690 Usage: Mandatory 691 Description: The element contains a child 692 element per action supported by the vehicle. 694 Examples: 695 697 It is OPTIONAL for the IVS to support the element. If 698 the IVS does not send a element, this indicates that 699 the only action supported by the IVS is 'send-data' with 700 'datatype' set to 'eCall.MSD'. 702 9.1.2.2. Capabilities Example 703 704 708 709 710 712 714 Figure 4: Capabilities Example 716 9.1.3. The element 718 A element appears one or more times on its own or as a 719 child of a element. It allows the PSAP to request 720 that the IVS perform an action. The only action that MUST be 721 supported is to send an MSD. The following attributes and child 722 elements are defined: 724 9.1.3.1. Attributes of the element 726 The element has the following attributes: 728 Name: action 729 Usage: Mandatory 730 Type: token 731 Direction: Sent in either direction 732 Description: Identifies the action that the vehicle is requested to 733 perform (in a element within a element, 734 indicates an action that the vehicle is capable of performing). 735 An IANA registry is established in Section 15.8.1 to contain the 736 allowed values. 737 Example: action="send-data" 739 Name: msgid 740 Usage: Conditional 741 Type: int 742 Direction: Sent in either direction 743 Description: Defined for extensibility. 744 Example: msgid="3" 746 Name: persistance 747 Usage: Optional 748 Type: duration 749 Direction: Sent in either direction 750 Description: Defined for extensibility. Specifies how long to carry 751 on the specified action. If absent, the default is for the 752 duration of the call. 753 Example: persistance="PT1H" 755 Name: datatype 756 Usage: Conditional 757 Type: token 758 Direction: Sent in either direction 759 Description: Mandatory with a "send-data" action within a 760 element that is not within a element. Specifies 761 the data block that the IVS is requested to transmit, using the 762 same identifier as in the 'purpose' attribute set in a Call-Info 763 header field to point to the data block. Permitted values are 764 contained in the 'Emergency Call Data Types' IANA registry 765 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 766 to support. 767 Example: datatype="eCall.MSD" 769 Name: supported-values 770 Usage: Conditional 771 Type: string 772 Direction: Sent from the IVS to the PSAP 773 Description: Defined for extensibility. Used in a element 774 that is a child of a element, this attribute lists 775 all supported values of the action type. Permitted values depend 776 on the action value. Multiple values are separated with a 777 semicolon. 779 Name: requested-state 780 Usage: Conditional 781 Type: token 782 Direction: Sent from the PSAP to the IVS 783 Description: Defined for extension. Indicates the requested state 784 of an element associated with the request type. Permitted values 785 depend on the request type. 787 Name: element-ID 788 Usage: Conditional 789 Type: token 790 Direction: Sent from the PSAP to the IVS 791 Description: Defined for extension. Identifies the element to be 792 acted on. Permitted values depend on the request type. 794 9.1.3.2. Request Example 796 797 801 803 805 Figure 5: Request Example 807 10. The emergencyCallData.eCall.MSD INFO package 809 This document registers the 'emergencyCallData.eCall.MSD' INFO 810 package. 812 Both endpoints (the IVS and the PSAP equipment) include 813 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 814 [RFC6086] to indicate ability to receive INFO requests carrying data 815 as described here. 817 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 818 the ability to receive eCall related body parts as specified in [TBD: 819 THIS DOCUMENT]. 821 An INFO request message carrying body parts related to an emergency 822 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 823 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 825 The requirements of Section 10 of [RFC6086] are addressed in the 826 following sections. 828 10.1. Overall Description 830 This section describes "what type of information is carried in INFO 831 requests associated with the Info Package, and for what types of 832 applications and functionalities UAs can use the Info Package." 834 INFO requests associated with the emergencyCallData.eCall.MSD INFO 835 package carry data associated with emergency calls as defined in 836 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 837 calls established using SIP. The functionality is to carry vehicle 838 data and metadata/control information between vehicles and PSAPs. 839 Refer to [TBD: THIS DOCUMENT] for more information. 841 10.2. Applicability 843 This section describes "why the Info Package mechanism, rather than 844 some other mechanism, has been chosen for the specific use-case...." 846 The use of INFO is based on an analysis of the requirements against 847 the intent and effects of INFO versus other approaches (which 848 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 849 transport, and non-SIP protocols). In particular, the transport of 850 emergency call data blocks occurs within a SIP emergency dialog, per 851 Section 6, and is normally carried in the initial INVITE and its 852 response; the use of INFO only occurs when emergency-call-related 853 data needs to be sent mid-call. While MESSAGE could be used, it is 854 not tied to a SIP dialog as is INFO and thus might not be associated 855 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 856 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 857 service, but the semantics are not a good fit, e.g., the subscribe/ 858 notify mechanism provides one-way communication consisting of (often 859 multiple) notifications from notifier to subscriber indicating that 860 certain events in notifier have occurred, whereas what's needed here 861 is two-way communication of data related to the emergency dialog. 862 Use of the media plane mechanisms was discounted because the number 863 of messages needing to be exchanged in a dialog is normally zero or 864 very few, and the size of the data is likewise very small. The 865 overhead caused by user plane setup (e.g., to use MSRP as transport) 866 would be disproportionately large. 868 Based on the the analyses, the SIP INFO method was chosen to provide 869 for mid-call data transport. 871 10.3. Info Package Name 873 The info package name is emergencyCallData.eCall.MSD 875 10.4. Info Package Parameters 877 None 879 10.5. SIP Option-Tags 881 None 883 10.6. INFO Request Body Parts 885 The body for an emergencyCallData.eCall.MSD info package is a 886 multipart body containing zero or one application/ 887 emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or 888 more application/emergencyCallData.control+xml (containing a 889 metadata/control object) parts. At least one MSD or metadata/control 890 body part is expected; the behavior upon receiving an INFO request 891 with neither is undefined. 893 The body parts are sent per [RFC6086], and in addition, to align with 894 with how these body parts are sent in SIP messages other than INFO 895 requests, each associated body part is referenced by a Call-Info 896 header field at the top level of the SIP message. The body part has 897 a Content-Disposition header field set to "By-Reference". 899 An MSD or metadata/control block is always enclosed in a multipart 900 body part (even if it would otherwise be the only body part in the 901 SIP message), since as of the date of this document, the use of 902 Content-ID as a SIP header field is not defined (while it is defined 903 for use as a MIME header field). The innermost multipart that 904 contains only body parts associated with the INFO package has a 905 Content-Disposition value of Info-Package. 907 See [TBD: THIS DOCUMENT] for more information. 909 10.7. Info Package Usage Restrictions 911 Usage is limited to vehicle-initiated emergency calls as defined in 912 [TBD: THIS DOCUMENT]. 914 10.8. Rate of INFO Requests 916 The rate of SIP INFO requests associated with the 917 emergencyCallData.eCall.MSD info package is normally quite low (most 918 dialogs are likely to contain zero INFO requests, while others can be 919 expected to carry an occasional request). 921 10.9. Info Package Security Considerations 923 The MIME media type registations for the data blocks that can be 924 carried using this INFO package contains a discussion of the security 925 and/or privacy considerations specific to that data block. The 926 "Security Considerations" and "Privacy Considerations" sections of 927 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 928 the data carried in eCalls. 930 10.10. Implementation Details 932 See [TBD: THIS DOCUMENT] for protocol details. 934 10.11. Examples 936 See [TBD: THIS DOCUMENT] for protocol examples. 938 11. Examples 940 Figure 6 illustrates an eCall. The call uses the request URI 941 'urn:service:sos.ecall.automatic' service URN and is recognized as an 942 eCall, and further as one that was invoked automatically by the IVS 943 due to a crash or other serious incident. In this example, the 944 originating network routes the call to an ESInet which routes the 945 call to the appropriate NG-eCall capable PSAP. The emergency call is 946 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 947 the entry point into the ESInet. The ESRP routes the call to a PSAP, 948 where it is received by a call taker. In deployments where there is 949 no ESInet, the originating network routes the call directly to the 950 appropriate NG-eCall capable PSAP, an illustration of which would be 951 identical to the one below except without an ESInet or ESRP. 953 +------------+ +---------------------------------------+ 954 | | | +-------+ | 955 | | | | PSAP2 | | 956 | | | +-------+ | 957 | | | | 958 | | | +------+ +-------+ | 959 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 960 | | | +------+ +-------+ | 961 | | | | 962 | | | +-------+ | 963 | | | | PSAP3 | | 964 | Originating| | +-------+ | 965 | Mobile | | | 966 | Network | | ESInet | 967 +------------+ +---------------------------------------+ 969 Figure 6: Example of NG-eCall Message Flow 971 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 972 for an updated MSD. The call flow shows the IVS initiating an 973 emergency call, including the MSD in the INVITE. The PSAP includes 974 in the 200 OK response a metadata/control object acknowledging 975 receipt of the MSD. During the call, the PSAP sends a request for an 976 MSD in an INFO request. The IVS sends the requested MSD in a new 977 INFO request. 979 IVS PSAP 980 |(1) INVITE (eCall MSD) | 981 |------------------------------------------->| 982 | | 983 |(2) 200 OK (eCall metadata [ack MSD]) | 984 |<-------------------------------------------| 985 | | 986 |(3) start media stream(s) | 987 |............................................| 988 | | 989 |(4) INFO (eCall metadata [request MSD]) | 990 |<-------------------------------------------| 991 | | 992 |(5) 200 OK | 993 |------------------------------------------->| 994 | | 995 |(6) INFO (eCall MSD) | 996 |------------------------------------------->| 997 | | 998 |(7) 200 OK | 999 |<-------------------------------------------| 1000 | | 1001 |(8) BYE | 1002 |<-------------------------------------------| 1003 | | 1004 |(9) end media streams | 1005 |............................................| 1006 | | 1007 |(10) 200 OK | 1008 |------------------------------------------->| 1010 Figure 7: NG-eCall Call Flow Illustration 1012 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 1013 contains an MSD. For simplicity, the example does not show all SIP 1014 headers, nor the SDP contents, nor does it show any additional data 1015 blocks added by the IVS or the originating mobile network. Because 1016 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 1017 contents cannot be included in a text document. 1019 INVITE urn:service:sos.ecall.automatic SIP/2.0 1020 To: urn:service:sos.ecall.automatic 1021 From: ;tag=9fxced76sl 1022 Call-ID: 3848276298220188511@atlanta.example.com 1023 Geolocation: 1024 Geolocation-Routing: no 1025 Call-Info: ; 1026 purpose=emergencyCallData.eCall.MSD 1027 Accept: application/sdp, application/pidf+xml, 1028 application/emergencyCallData.control+xml 1029 CSeq: 31862 INVITE 1030 Recv-Info: emergencyCallData.eCall.MSD 1031 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1032 SUBSCRIBE, NOTIFY, UPDATE 1033 Content-Type: multipart/mixed; boundary=boundary1 1034 Content-Length: ... 1036 --boundary1 1037 Content-Type: application/sdp 1039 ...Session Description Protocol (SDP) goes here... 1041 --boundary1 1042 Content-Type: application/pidf+xml 1043 Content-ID: 1044 Content-Disposition: by-reference;handling=optional 1046 ...PIDF-LO goes in here 1048 --boundary1 1049 Content-Type: application/emergencyCallData.eCall.MSD+per 1050 Content-ID: <1234567890@atlanta.example.com> 1051 Content-Disposition: by-reference;handling=optional 1053 ...MSD in ASN.1 PER encoding goes here... 1055 --boundary1-- 1057 Figure 8: SIP NG-eCall INVITE 1059 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1060 the INVITE of Figure 8, containing a control block acknowledging 1061 successful receipt of the eCall MSD. (For simplicity, the example 1062 does not show all SIP headers.) 1063 SIP/2.0 200 OK 1064 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1065 From: ;tag=9fxced76sl 1066 Call-ID: 3848276298220188511@atlanta.example.com 1067 Call-Info: ; 1068 purpose=emergencyCallData.control 1069 Accept: application/sdp, application/pidf+xml, 1070 application/emergencyCallData.control+xml, 1071 application/emergencyCallData.eCall.MSD+per 1072 CSeq: 31862 INVITE 1073 Recv-Info: emergencyCallData.eCall.MSD 1074 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1075 SUBSCRIBE, NOTIFY, UPDATE 1076 Content-Type: multipart/mixed; boundary=boundaryX 1077 Content-Length: ... 1079 --boundaryX 1080 Content-Type: application/sdp 1082 ...Session Description Protocol (SDP) goes here... 1084 --boundaryX 1085 Content-Type: application/emergencyCallData.control+xml 1086 Content-ID: <2345678901@atlanta.example.com> 1087 Content-Disposition: by-reference 1089 1090 1094 1095 1097 --boundaryX-- 1099 Figure 9: 200 OK response to INVITE 1101 Figure 10 illustrates a SIP INFO request containing a metadata/ 1102 control block requesting an eCall MSD. (For simplicity, the example 1103 does not show all SIP headers.) 1104 INFO sip:+13145551111@example.com SIP/2.0 1105 To: ;tag=9fxced76sl 1106 From: Exemplar PSAP ;tag=8gydfe65t0 1107 Call-ID: 3848276298220188511@atlanta.example.com 1108 Call-Info: ; 1109 purpose=emergencyCallData.control 1110 CSeq: 41862 INFO 1111 Info-Package: emergencyCallData.eCall.MSD 1112 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1113 SUBSCRIBE, NOTIFY, UPDATE 1114 Content-Type: multipart/mixed; boundary=boundaryZZZ 1115 Content-Dispositio: Info-Package 1116 Content-Length: ... 1118 --boundaryZZZ 1119 Content-Disposition: by-reference 1120 Content-Type: application/emergencyCallData.control+xml 1121 Content-ID: <3456789012@atlanta.example.com> 1123 1124 1128 1130 1131 --boundaryZZZ-- 1133 Figure 10: INFO requesting MSD 1135 Figure 11 illustrates a SIP INFO request containing an MSD. For 1136 simplicity, the example does not show all SIP headers. Because the 1137 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1138 cannot be included in a text document. 1140 INFO urn:service:sos.ecall.automatic SIP/2.0 1141 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1142 From: ;tag=9fxced76sl 1143 Call-ID: 3848276298220188511@atlanta.example.com 1144 Call-Info: ; 1145 purpose=emergencyCallData.eCall.MSD 1146 CSeq: 51862 INFO 1147 Info-Package: emergencyCallData.eCall.MSD 1148 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1149 SUBSCRIBE, NOTIFY, UPDATE 1150 Content-Type: multipart/mixed; boundary=boundaryLine 1151 Content-Disposition: Info-Package 1152 Content-Length: ... 1154 --boundaryLine 1155 Content-Type: application/emergencyCallData.eCall.MSD+per 1156 Content-ID: <4567890123@atlanta.example.com> 1157 Content-Disposition: by-reference 1159 ...MSD in ASN.1 PER encoding goes here... 1161 --boundaryLine-- 1163 Figure 11: INFO containing MSD 1165 12. Security Considerations 1167 The security considerations described in [RFC5069] apply here. 1169 In addition to any network-provided location (which might be 1170 determined solely by the network, or in cooperation with or possibly 1171 entirely by the originating device), an eCall carries an IVS-supplied 1172 location within the MSD. This is likely to be useful to the PSAP, 1173 especially when no network-provided location is included, or when the 1174 two locations are independently determined. Even in situations where 1175 the network-supplied location is limited to the cell site, this can 1176 be useful as a sanity check on the device-supplied location contained 1177 in the MSD. 1179 The document [RFC7378] discusses trust issues regarding location 1180 provided by or determined in cooperation with end devices. 1182 Security considerations specific to the mechanism by which the PSAP 1183 sends acknowledgments and requests to the vehicle are discussed in 1184 the "Security Considerations" block of Section 15.3. 1186 Data received from external sources inherently carries implementation 1187 risks. For example, depending on the platform, buffer overflows can 1188 introduce remote code execution vulnerabilities, null characters can 1189 corrupt strings, numeric values used for internal calculations can 1190 result in underflow/overflow errors, malformed XML objects can expose 1191 parsing bugs, etc. Implementations need to be cognizant of the 1192 potential risks, observe best practices (which might include 1193 sufficiently capable static code analysis, fuzz testing, component 1194 isolation, avoiding use of unsafe coding techniques, third-party 1195 attack tests, signed software, over-the-air updates, etc.), and have 1196 multiple levels of protection. Implementors need to be aware that, 1197 potentially, the data objects described here and elsewhere might be 1198 malformed, might contain unexpected characters, excessively long 1199 attribute values, elements, etc. 1201 The security considerations discussed in [RFC7852] apply here (see 1202 especially the discussion of TLS, TLS versions, cypher suites, and 1203 PKI). 1205 When vehicle data or control/metadata is contained in a signed or 1206 encrypted body part, the enclosing multipart (e.g., multipart/signed 1207 or multipart/encrypted) has the same Content-ID as the enclosed data 1208 part. This allows an entity to identify and access the data blocks 1209 it is interested in without having to dive deeply into the message 1210 structure or decrypt parts it is not interested in. (The 'purpose' 1211 parameter in a Call-Info header field identifies the data and 1212 contains a CID URL pointing to the data block in the body, which has 1213 a matching Content-ID body part header field). 1215 13. Privacy Considerations 1217 The privacy considerations discussed in [RFC7852] apply here. The 1218 MSD carries some identifying and personal information (mostly about 1219 the vehicle and less about the owner), as well as location 1220 information, and so needs to be protected against unauthorized 1221 disclosure. Local regulations may impose additional privacy 1222 protection requirements. 1224 Privacy considerations specific to the data structure containing 1225 vehicle information are discussed in the "Security Considerations" 1226 block of Section 15.2. 1228 Privacy considerations specific to the mechanism by which the PSAP 1229 sends acknowledgments and requests to the vehicle are discussed in 1230 the "Security Considerations" block of Section 15.3. 1232 14. XML Schema 1234 This section defines an XML schema for the control block. The text 1235 description of the control block in Section 9.1 is normative and 1236 supersedes any conflicting aspect of this schema. 1238 1239 1241 1249 1251 1254 1255 1256 1257 1258 1260 1261 1262 1265 1266 1267 1268 1269 1271 1272 1273 1274 1275 1277 1278 1281 1284 1286 1287 conditionally 1288 mandatory when @success='false" 1289 to indicate reason code for a 1290 failure 1291 1292 1293 1295 1296 1297 1298 1301 1302 1305 1307 1308 1309 1310 1312 1313 1314 1315 1316 1320 1323 1324 1325 1326 1328 1330 1331 1332 1333 1334 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1350 1352 Figure 12: Control Block Schema 1354 15. IANA Considerations 1356 This document formalizes the "EmergencyCallData" media (MIME) subtype 1357 tree. This tree is used only for content associated with emergency 1358 communications. New subtypes in this tree can be registered by the 1359 IETF or by other standards organizations working with emergency 1360 communications, using the "Specification Required" rule, which 1361 implies expert review. The designated expert is the ECRIT working 1362 group. 1364 15.1. Service URN Registrations 1366 IANA is requested to register the URN 'urn:service:sos.ecall' under 1367 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1369 This service requests resources associated with an emergency call 1370 placed by an in-vehicle system, carrying a standardized set of data 1371 related to the vehicle and incident. Two sub-services are registered 1372 as well: 1374 urn:service:sos.ecall.manual 1375 Used with an eCall invoked due to manual interaction by a vehicle 1376 occupant. 1378 urn:service:sos.ecall.automatic 1380 Used with an eCall invoked automatically, for example, due to a 1381 crash or other serious incident. 1383 IANA is also requested to register the URN 1384 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1385 defined in Setcion 17.2 of [RFC6881]. 1387 15.2. MIME Media Type Registration for 'application/ 1388 emergencyCallData.eCall.MSD+per' 1390 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1391 as a MIME media type, with a reference to this document, in 1392 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1393 RFC 7303 [RFC7303]. 1395 MIME media type name: application 1397 MIME subtype name: emergencyCallData.eCall.MSD+per 1399 Mandatory parameters: none 1401 Optional parameters: none 1403 Encoding scheme: binary 1405 Encoding considerations: Uses ASN.1 PER, which is a binary 1406 encoding; when transported in SIP, binary content transfer 1407 encoding is used. 1409 Security considerations: This content type is designed to carry 1410 vehicle and incident-related data during an emergency call. This 1411 data contains personal information including vehicle VIN, 1412 location, direction, etc. Appropriate precautions need to be 1413 taken to limit unauthorized access, inappropriate disclosure to 1414 third parties, and eavesdropping of this information. In general, 1415 it is acceptable for the data to be unprotected while briefly in 1416 transit within the Mobile Network Operator (MNO); the MNO is 1417 trusted to not permit the data to be accessed by third parties. 1418 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1420 Interoperability considerations: None 1422 Published specification: Annex A of EN 15722 [msd] 1423 Applications which use this media type: Pan-European eCall 1424 compliant systems 1426 Additional information: None 1428 Magic Number: None 1430 File Extension: None 1432 Macintosh file type code: 'BINA' 1434 Person and email address for further information: Randall Gellens, 1435 rg+ietf@randy.pensive.org 1437 Intended usage: LIMITED USE 1439 Author: The MSD specification was produced by the European 1440 Committee For Standardization (CEN). For contact information, 1441 please see . 1443 Change controller: The European Committee For Standardization 1444 (CEN) 1446 15.3. MIME Media Type Registration for 'application/ 1447 emergencyCallData.control+xml' 1449 IANA is requested to add application/emergencyCallData.control+xml as 1450 a MIME media type, with a reference to this document, in accordance 1451 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1452 [RFC7303]. 1454 MIME media type name: application 1456 MIME subtype name: emergencyCallData.control+xml 1458 Mandatory parameters: none 1460 Optional parameters: charset 1462 Indicates the character encoding of the XML content. 1464 Encoding considerations: Uses XML, which can employ 8-bit 1465 characters, depending on the character encoding used. See 1466 Section 3.2 of RFC 7303 [RFC7303]. 1468 Security considerations: 1470 This content type carries metadata and control information and 1471 requests, such as from a Public Safety Answering Point (PSAP) 1472 to an In-Vehicle System (IVS) during an emergency call. 1474 Metadata (such as an acknowledgment that data sent by the IVS 1475 to the PSAP was successfully received) has limited privacy and 1476 security implications. Control information (such as requests 1477 from the PSAP that the vehicle perform an action) has some 1478 privacy and security implications. The privacy concern arises 1479 from the ability to request the vehicle to transmit a data set, 1480 which as described in Section 15.2, can contain personal 1481 information. The security concern is the ability to request 1482 the vehicle to perform an action. Control information needs to 1483 originate only from a PSAP or other emergency services 1484 provider, and not be modified en-route. The level of integrity 1485 of the cellular network over which the emergency call is placed 1486 is a consideration: when the IVS initiates an eCall over a 1487 cellular network, in most cases it relies on the MNO to route 1488 the call to a PSAP. (Calls placed using other means, such as 1489 Wi-Fi or over-the-top services, generally incur somewhat higher 1490 levels of risk than calls placed "natively" using cellular 1491 networks.) A call-back from a PSAP merits additional 1492 consideration, since current mechanisms are not ideal for 1493 verifying that such a call is indeed a call-back from a PSAP in 1494 response to an emergency call placed by the IVS. See the 1495 discussion in Section 12 and the PSAP Callback document 1496 [RFC7090]. 1498 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1500 Interoperability considerations: None 1502 Published specification: This document 1504 Applications which use this media type: Pan-European eCall 1505 compliant systems 1507 Additional information: None 1509 Magic Number: None 1511 File Extension: .xml 1513 Macintosh file type code: 'TEXT' 1515 Person and email address for further information: Randall Gellens, 1516 rg+ietf@randy.pensive.org 1517 Intended usage: LIMITED USE 1519 Author: The IETF ECRIT WG. 1521 Change controller: The IETF ECRIT WG. 1523 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1524 Additional Data Blocks registry 1526 This specification requests IANA to add the 'eCall.MSD' entry to the 1527 Emergency Call Additional Data Blocks registry, with a reference to 1528 this document. 1530 15.5. Registration of the 'control' entry in the Emergency Call 1531 Additional Data Blocks registry 1533 This specification requests IANA to add the 'control' entry to the 1534 Emergency Call Additional Data Blocks registry, with a reference to 1535 this document. 1537 15.6. Registration of the emergencyCallData.eCall Info Package 1539 IANA is requested to add emergencyCallData.eCall to the Info Packages 1540 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1541 reference to this document. 1543 15.7. URN Sub-Namespace Registration 1545 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1547 This section registers a new XML namespace, as per the guidelines in 1548 RFC 3688 [RFC3688]. 1550 URI: urn:ietf:params:xml:ns:eCall 1552 Registrant Contact: IETF, ECRIT working group, , as 1553 delegated by the IESG . 1555 XML: 1557 BEGIN 1558 1559 1561 1562 1563 1565 Namespace for eCall Data 1566 1567 1568

Namespace for eCall Data

1569

See [TBD: This document].

1570 1571 1572 END 1574 15.7.2. Registration for urn:ietf:params:xml:ns:control 1576 This section registers a new XML namespace, as per the guidelines in 1577 RFC 3688 [RFC3688]. 1579 URI: urn:ietf:params:xml:ns:control 1581 Registrant Contact: IETF, ECRIT working group, , as 1582 delegated by the IESG . 1584 XML: 1586 BEGIN 1587 1588 1590 1591 1592 1594 Namespace for eCall Data: 1595 Control Block 1596 1597 1598

Namespace for eCall Data

1599

Control Block

1600

See [TBD: This document].

1601 1602 1603 END 1605 15.8. Registry creation 1607 This document creates a new registry called 'Metadata/Control Data'. 1608 The following sub-registries are created for this registry. 1610 15.8.1. Action Registry 1612 This document creates a new sub-registry called "Action Registry". 1613 As defined in [RFC5226], this registry operates under "Expert Review" 1614 rules. The expert should determine that the proposed action is 1615 within the purview of a vehicle, is sufficiently distinguishable from 1616 other actions, and the action is clearly and fully described. In 1617 most cases, a published and stable document is referenced for the 1618 description of the action. 1620 The content of this registry includes: 1622 Name: The identifier to be used in the 'action' attribute of a 1623 control element. 1625 Description: A description of the action. In most cases this will 1626 be a reference to a published and stable document. The 1627 description MUST specify if any attributes or child elements are 1628 optional or mandatory, and describe the action to be taken by the 1629 vehicle. 1631 The initial set of values is listed in Table 2. 1633 +-----------+--------------------------------------+ 1634 | Name | Description | 1635 +-----------+--------------------------------------+ 1636 | send-data | See Section 9.1.3.1 of this document | 1637 +-----------+--------------------------------------+ 1639 Table 2: Action Registry Initial Values 1641 15.8.2. Reason Registry 1643 This document creates a new sub-registry called "Reason Registry" 1644 which contains values for the 'reason' attribute of the 1645 element. As defined in [RFC5226], this registry 1646 operates under "Expert Review" rules. The expert should determine 1647 that the proposed reason is sufficiently distinguishable from other 1648 reasons and that the proposed description is understandable and 1649 correctly worded. 1651 The content of this registry includes: 1653 ID: A short string identifying the reason, for use in the 'reason' 1654 attribute of an element. 1656 Description: A description of the reason. 1658 The initial set of values is listed in Table 3. 1660 +------------------+------------------------------------------------+ 1661 | ID | Description | 1662 +------------------+------------------------------------------------+ 1663 | unsupported | The 'action' value is not supported. | 1664 | | | 1665 | damaged | Required components are damaged. | 1666 | | | 1667 | unable | The action could not be accomplished (a | 1668 | | generic error for use when no other code is | 1669 | | appropriate). | 1670 | | | 1671 | data-unsupported | The data item referenced in a 'send-data' | 1672 | | request is not supported. | 1673 | | | 1674 | security-failure | The authenticity of the request or the | 1675 | | authority of the requestor could not be | 1676 | | verified. | 1677 +------------------+------------------------------------------------+ 1679 Table 3: Reason Registry 1681 16. Contributors 1683 Brian Rosen was a co-author of the original document upon which this 1684 document is based. 1686 17. Acknowledgements 1688 We would like to thank Bob Williams and Ban Al-Bakri for their 1689 feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith 1690 Drage, Stephen Edge, Wes George, Ivo Sedlacek, and James Winterbottom 1691 for their review and comments; Robert Sparks and Paul Kyzivat for 1692 their help with the SIP mechanisms; Mark Baker and Ned Freed for 1693 their help with the media subtype registration issue. We would like 1694 to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and 1695 Ulrich Dietz for their help with the original document upon which 1696 this document is based. Christer Holmberg deserves special mention 1697 for his many detailed reviews. 1699 18. Changes from Previous Versions 1701 18.1. Changes from draft-ietf-17 to draft-ietf-18 1703 o Added reference to 3GPP TS24.229 1704 o Clarified that an INFO request is expected to have at least one 1705 MSD or metadata/control body part 1706 o Fixed minor errors in examples 1707 o Corrected "content type" to "media type" 1708 o Deleted "xsi:schemaLocation" from examples 1710 18.2. Changes from draft-ietf-16 to draft-ietf-17 1712 o Clarify Content-Disposition value in INFO requests 1714 18.3. Changes from draft-ietf-15 to draft-ietf-16 1716 o Various clarifications and simplifications 1717 o Added reference to 3GPP 23.167 1719 18.4. Changes from draft-ietf-14 to draft-ietf-15 1721 o eCall body parts now always sent enclosed in multipart (even if 1722 only body part in SIP message) and hence always have a Content- 1723 Disposition of By-Reference 1724 o Fixed errors in attribute directionality text 1725 o Fixed typos. 1727 18.5. Changes from draft-ietf-13 to draft-ietf-14 1729 o Added text to the IANA Considerations to formalize the 1730 EmergencyCallData media subtree 1731 o Fixed some typos 1733 18.6. Changes from draft-ietf-12 to draft-ietf-13 1735 o Clarifications suggested by Christer 1736 o Corrections to Content-Disposition text and examples as suggested 1737 by Paul Kyzivat 1738 o Clarifications to Content-Disposition text and examples to clarify 1739 that handling=optional is only used in the initial INVITE 1741 18.7. Changes from draft-ietf-11 to draft-ietf-12 1743 o Fixed errors in examples found by Dale 1744 o Removed enclosing sub-section of INFO package registration section 1745 o Added text per Christer and Dale's suggestions that the MSD and 1746 metadata/control blocks are sent in INFO with a Call-Info header 1747 field referencing them 1748 o Deleted Call Routing section (7.1) in favor of a statement that 1749 call routing is outside the scope of the document 1750 o Other text changes per comments received from Christer and Ivo. 1752 18.8. Changes from draft-ietf-09 to draft-ietf-11 1754 o Renamed INFO package to emergencyCallData.eCall.MSD 1755 o Changed INFO package to only permit MSD and metadata/control MIME 1756 types 1757 o Moved element back from car-crash but made it 1758 OPTIONAL 1759 o Moved other extension points back from car-crash so that extension 1760 points are in base spec (and also to get XML schema to compile) 1761 o Text changes for clarification. 1763 18.9. Changes from draft-ietf-08 to draft-ietf-09 1765 o Created a new "Data Transport" section that describes how the MSD 1766 and metadata/control blocks are attached, and then referred to 1767 that section rather than repeat the information about the CID and 1768 Call-Info and so forth, which means most references to the 1769 additional-data draft have now been deleted 1770 o Mentioned edge cases where a PSAP response to INVITE isn't 1771 received by the IVS 1772 o Reworded description of which status codes are used when a PSAP 1773 wishes to reject a call but inform the vehicle occupants that it 1774 is aware of the situation to be more definite 1776 o Added examples showing INFO 1777 o Added references for eCall test call requirement 1778 o Described meaning of eCall URNs in Section 8 as well as in IANA 1779 registration 1781 18.10. Changes from draft-ietf-07 to draft-ietf-08 1783 o eCall MSD now encoded as ASN.1 PER, using binary content transfer 1784 encoding 1785 o Added text to point out aspects of call handling and metadata/ 1786 control usage, such as use in rejected calls, and solicited MSDs 1787 o Revised use of INFO to require that when a request for an MSD is 1788 sent in INFO, the MSD sent in response is in its own INFO, not the 1789 response to the requesting INFO 1790 o Added material to INFO package registation to comply with 1791 Section 10 of [RFC6086] 1792 o Moved material not required by 3GPP into 1793 [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ 1794 control elements, attributes, and values 1795 o Revised test call wording to clarify that specific handling is out 1796 of scope 1797 o Revised wording throughout the document to simplify 1798 o Moved new Section 7.1 to be a subsection of 7 1799 o Moved new Section Section 10 to be a main section instead of a 1800 subsection of Section 9 1801 o Revised SIP INFO usage and package registration per advice from 1802 Robert Sparks and Paul Kyzivat 1804 18.11. Changes from draft-ietf-06 to draft-ietf-07 1806 o Fixed typo in Acknowledgements 1808 18.12. Changes from draft-ietf-05 to draft-ietf-06 1810 o Added additional security and privacy clarifications regarding 1811 signed and encrypted data 1812 o Additional security and privacy text 1813 o Deleted informative section on ESINets as unnecessary. 1815 18.13. Changes from draft-ietf-04 to draft-ietf-05 1817 o Reworked the security and privacy considerations material in the 1818 document as a whole and in the MIME registation sections of the 1819 MSD and control objects 1820 o Clarified that the element can appear multiple 1821 times within an element 1822 o Fixed IMS definition 1823 o Added clarifying text for the 'msgid' attribute 1825 18.14. Changes from draft-ietf-03 to draft-ietf-04 1827 o Added Privacy Considerations section 1828 o Reworded most uses of non-normative "may", "should", "must", and 1829 "recommended." 1830 o Fixed nits in examples 1832 18.15. Changes from draft-ietf-02 to draft-ietf-03 1834 o Added request to enable cameras 1835 o Improved examples and XML schema 1836 o Clarifications and wording improvements 1838 18.16. Changes from draft-ietf-01 to draft-ietf-02 1840 o Added clarifying text reinforcing that the data exchange is for 1841 small blocks of data infrequently transmitted 1842 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1843 establish a one-way media stream 1844 o Clarified that the scope is the needs of eCall within the SIP 1845 emergency call environment 1846 o Added informative statement that the document may be suitable for 1847 reuse by other ACN systems 1848 o Clarified that normative language for the control block applies to 1849 both IVS and PSAP 1850 o Removed 'ref', 'supported-mime', and elements 1851 o Minor wording improvements and clarifications 1853 18.17. Changes from draft-ietf-00 to draft-ietf-01 1855 o Added further discussion of test calls 1856 o Added further clarification to the document scope 1857 o Mentioned that multi-region vehicles may need to support other 1858 crash notification specifications in addition to eCall 1859 o Added details of the eCall metadata and control functionality 1860 o Added IANA registration for the MIME media type for the control 1861 object 1862 o Added IANA registries for protocol elements and tokens used in the 1863 control object 1864 o Minor wording improvements and clarifications 1866 18.18. Changes from draft-gellens-03 to draft-ietf-00 1868 o Renamed from draft-gellens- to draft-ietf-. 1869 o Added mention of and reference to ETSI TR "Mobile Standards Group 1870 (MSG); eCall for VoIP" 1871 o Added text to Introduction regarding migration/co-existence being 1872 out of scope 1874 o Added mention in Security Considerations that even if the network- 1875 supplied location is just the cell site, this can be useful as a 1876 sanity check on the IVS-supplied location 1877 o Minor wording improvements and clarifications 1879 18.19. Changes from draft-gellens-02 to -03 1881 o Clarifications and editorial improvements. 1883 18.20. Changes from draft-gellens-01 to -02 1885 o Minor wording improvements 1886 o Removed ".automatic" and ".manual" from 1887 "urn:service:test.sos.ecall" registration and discussion text. 1889 18.21. Changes from draft-gellens-00 to -01 1891 o Now using 'EmergencyCallData' for purpose parameter values and 1892 MIME subtypes, in accordance with changes to [RFC7852] 1893 o Added reference to RFC 6443 1894 o Fixed bug that caused Figure captions to not appear 1896 19. References 1898 19.1. Normative References 1900 [EN_16062] 1901 CEN, , "Intelligent transport systems - eSafety - eCall 1902 High Level Application Requirements (HLAP) Using GSM/UMTS 1903 Circuit Switched Networks, EN 16062", April 2015. 1905 [EN_16072] 1906 CEN, , "Intelligent transport systems - eSafety - Pan- 1907 European eCall operating requirements, EN 16072", April 1908 2015. 1910 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1911 minimum set of data (MSD), EN 15722", April 2015. 1913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1914 Requirement Levels", BCP 14, RFC 2119, 1915 DOI 10.17487/RFC2119, March 1997, 1916 . 1918 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1919 DOI 10.17487/RFC3688, January 2004, 1920 . 1922 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1923 Emergency and Other Well-Known Services", RFC 5031, 1924 DOI 10.17487/RFC5031, January 2008, 1925 . 1927 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1928 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1929 DOI 10.17487/RFC5226, May 2008, 1930 . 1932 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1933 "Framework for Emergency Calling Using Internet 1934 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1935 2011, . 1937 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1938 Specifications and Registration Procedures", BCP 13, 1939 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1940 . 1942 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1943 Communications Services in Support of Emergency Calling", 1944 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1945 . 1947 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1948 DOI 10.17487/RFC7303, July 2014, 1949 . 1951 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1952 J. Winterbottom, "Additional Data Related to an Emergency 1953 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1954 . 1956 [TS22.101] 1957 3GPP, , "3GPP TS 22.101: Technical Specification Group 1958 Services and System Aspects; Service aspects; Service 1959 principles". 1961 19.2. Informative references 1963 [CEN] "European Committee for Standardization", 1964 . 1966 [I-D.ietf-ecrit-car-crash] 1967 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1968 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1969 ecrit-car-crash-16 (work in progress), October 2016. 1971 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1972 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1973 April 2014. 1975 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1976 Emergency Context Resolution with Internet Technologies", 1977 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1978 . 1980 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1981 Shanmugam, "Security Threats and Requirements for 1982 Emergency Call Marking and Mapping", RFC 5069, 1983 DOI 10.17487/RFC5069, January 2008, 1984 . 1986 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1987 Initiation Protocol (SIP) INFO Method and Package 1988 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1989 . 1991 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1992 Patel, "Public Safety Answering Point (PSAP) Callback", 1993 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1994 . 1996 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1997 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1998 December 2014, . 2000 [SDO-3GPP] 2001 "3d Generation Partnership Project", 2002 . 2004 [SDO-ETSI] 2005 "European Telecommunications Standards Institute (ETSI)", 2006 . 2008 [TS23.167] 2009 3GPP, , "3GPP TS 23.167: IP Multimedia Subsystem (IMS) 2010 emergency sessions". 2012 [TS24.229] 2013 3GPP, , "3GPP TS 24.229: IP multimedia call control 2014 protocol based on Session Initiation Protocol (SIP) and 2015 Session Description Protocol (SDP); Stage 3". 2017 Authors' Addresses 2019 Randall Gellens 2020 Core Technology Consulting 2022 Email: rg+ietf@randy.pensive.org 2024 Hannes Tschofenig 2025 Individual 2027 Email: Hannes.Tschofenig@gmx.net 2028 URI: http://www.tschofenig.priv.at