idnits 2.17.00 (12 Aug 2021) /tmp/idnits2062/draft-ietf-ecrit-ecall-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2016) is 2013 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Core Technology Consulting 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 18, 2017 Individual 6 November 14, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-20.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 May 18, 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 . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . 31 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. Emergency Call Action Registry . . . . . . . . . . . 36 112 15.8.2. Emergency Call Action Failure 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-19 to draft-ietf-20 . . . . . . 38 117 18.2. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 38 118 18.3. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 119 18.4. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 120 18.5. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 38 121 18.6. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 39 122 18.7. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 39 123 18.8. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 39 124 18.9. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 39 125 18.10. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39 126 18.11. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 40 127 18.12. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 40 128 18.13. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40 129 18.14. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 41 130 18.15. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 41 131 18.16. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 41 132 18.17. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41 133 18.18. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41 134 18.19. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 42 135 18.20. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 42 136 18.21. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42 137 18.22. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42 138 18.23. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42 139 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 140 19.1. Normative References . . . . . . . . . . . . . . . . . . 43 141 19.2. Informative references . . . . . . . . . . . . . . . . . 44 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 144 1. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 This document re-uses terminology defined in Section 3 of [RFC5012]. 152 Additionally, we use the following abbreviations: 154 +--------+----------------------------------------+ 155 | Term | Expansion | 156 +--------+----------------------------------------+ 157 | 3GPP | 3rd Generation Partnership Project | 158 | | | 159 | CEN | European Committee for Standardization | 160 | | | 161 | EENA | European Emergency Number Association | 162 | | | 163 | ESInet | Emergency Services IP network | 164 | | | 165 | IMS | IP Multimedia Subsystem | 166 | | | 167 | IVS | In-Vehicle System | 168 | | | 169 | MNO | Mobile Network Operator | 170 | | | 171 | MSD | Minimum Set of Data | 172 | | | 173 | PSAP | Public Safety Answering Point | 174 +--------+----------------------------------------+ 176 2. Document Scope 178 This document is focused on the signaling, data exchange, and 179 protocol needs of next-generation eCall (NG-eCall, also referred to 180 as packet-switched eCall or all-IP eCall) within the SIP framework 181 for emergency calls (as described in [RFC6443] and [RFC6881]). eCall 182 itself is specified by 3GPP (3rd Generation Partnership Project) and 183 CEN (European Committee for Standardization) and these specifications 184 include far greater scope than is covered here. 186 The eCall service operates over cellular wireless communication, but 187 this document does not address cellular-specific details, nor client 188 domain selection (e.g., circuit-switched versus packet-switched). 189 All such aspects are the purview of their respective standards 190 bodies. The scope of this document is limited to eCall operating 191 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling 192 [TS23.167]). 194 The technical contents of this document also provide a basis for 195 reuse and extension for related emergency call systems (which is why 196 there are extension points), but such reuse is a topic for other 197 documents. 199 Note that vehicles designed for multiple regions might need to 200 support eCall and other Advanced Automatic Crash Notification (AACN) 201 systems (such as described in [I-D.ietf-ecrit-car-crash]), but this 202 is out of scope of this document. 204 3. Introduction 206 Emergency calls made from vehicles (e.g., in the event of a crash) 207 assist in significantly reducing road deaths and injuries by allowing 208 emergency services to be aware of the incident, the state of the 209 vehicle, the location of the vehicle, and to have a voice channel 210 with the vehicle occupants. This enables a quick and appropriate 211 response. 213 The European Commission initiative of eCall was conceived in the late 214 1990s, and has evolved to a European Parliament decision requiring 215 the implementation of a compliant in-vehicle system (IVS) in new 216 vehicles and the deployment of eCall in the European Member States in 217 the very near future. Other regions are developing eCall-compatible 218 systems. 220 The pan-European eCall system provides a standardized and mandated 221 mechanism for emergency calls by vehicles. eCall establishes 222 procedures for such calls to be placed by in-vehicle systems, 223 recognized and processed by the mobile network, and routed to a 224 specialized PSAP where the vehicle data is available to assist the 225 call taker in assessing and responding to the situation. eCall 226 provides a standard set of vehicle, sensor (e.g., crash related), and 227 location data. 229 An eCall can be either user-initiated or automatically triggered. 230 Automatically triggered eCalls indicate a car crash or some other 231 serious incident. Manually triggered eCalls might be reports of 232 witnessed crashes or serious hazards. PSAPs might apply specific 233 operational handling to manual and automatic eCalls. 235 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 236 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 237 call setup mark the call as an eCall, and further indicate if the 238 call was automatically or manually triggered. The call is routed to 239 an eCall-capable PSAP, a voice channel is established between the 240 vehicle and the PSAP, and an eCall in-band modem is used to carry a 241 defined set of vehicle, sensor (e.g., crash related), and location 242 data (the Minimum Set of Data or MSD) within the voice channel. The 243 same in-band mechanism is used for the PSAP to acknowledge successful 244 receipt of the MSD, and to request the vehicle to send a new MSD 245 (e.g., to check if the state of or location of the vehicle or its 246 occupants has changed). NG-eCall moves from circuit switched to all- 247 IP, and carries the vehicle data and eCall signaling as additional 248 data carried with the call. This document describes how IETF 249 mechanisms for IP-based emergency calls (including [RFC6443] and 250 [RFC7852]) are used to provide the signaling and data exchange of the 251 next generation of pan-European eCall. 253 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 254 has published a Technical Report titled "Mobile Standards Group 255 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 256 recommendations regarding support for eCall in an all-IP environment. 257 The recommendations include the use of 3GPP IMS emergency calling 258 with additional elements identifying the call as an eCall and as 259 carrying eCall data and with mechanisms for carrying the data and 260 eCall signaling. 3GPP IMS emergency services support multimedia, 261 providing the ability to carry voice, text, and video. This 262 capability is referred to within 3GPP as Multimedia Emergency 263 Services (MMES). 265 A transition period will exist during which time the various entities 266 involved in initiating and handling an eCall might support next- 267 generation eCall, legacy eCall, or both. The issues of migration and 268 co-existence during the transition period are outside the scope of 269 this document. 271 This document indicates how to use IP-based emergency services 272 mechanisms to support next-generation eCall. 274 This document also registers MIME media types and an Emergency Call 275 Additional Data Block for the eCall vehicle data (MSD) and metadata/ 276 control data, and an INFO package to enable carrying this data in 277 INFO requests. 279 The MSD is carried in the MIME type 'application/ 280 emergencyCallData.eCall.MSD+per' and the metadata/control block is 281 carried in the MIME type 'application/emergencyCallData.control+xml' 282 (both of which are registered in Section 15) An INFO package is 283 defined (in Section 10) to enable these MIME types to be carried in 284 SIP INFO requests, per [RFC6086]. 286 4. eCall Requirements 288 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 289 [TS22.101] clauses 10.7 and A.27 and [TS24.229] section 4.7.6. 290 Requirements specific to vehicle data are contained in EN 15722 291 [msd]. 293 5. Vehicle Data 295 Pan-European eCall provides a standardized and mandated set of 296 vehicle related data, known as the Minimum Set of Data (MSD). The 297 European Committee for Standardization (CEN) has specified this data 298 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 299 circuit-switched eCall and this document use the ASN.1 PER encoding, 300 which is specified in Annex A of EN 15722 [msd] (the XML encoding 301 specified in Annex C is not used in this document). 303 This document registers the 'application/ 304 emergencyCallData.eCall.MSD+per' MIME media type to enable the MSD to 305 be carried in SIP. As an ASN.1 PER encoded object, the data is 306 binary and transported using binary content transfer encoding within 307 SIP messages. This document also adds the 'eCall.MSD' entry to the 308 Emergency Call Additional Data Blocks registry to enable the MSD to 309 be recognized as such in a SIP-based eCall emergency call. (See 310 [RFC7852] for more information about the registry and how it is 311 used.) 313 See Section 6 for a discussion of how the MSD vehicle data is 314 conveyed in an NG-eCall. 316 6. Data Transport 318 [RFC7852] establishes a general mechanism for attaching blocks of 319 data to a SIP emergency call. This mechanism permits certain 320 emergency call MIME types to be attached to SIP messages. This 321 document makes use of that mechanism. This document also registers 322 an INFO package (in Section 10) to enable eCall related data blocks 323 to be carried in SIP INFO requests (per [RFC6086], new INFO usages 324 require the definition of an INFO package). 326 Note that if other data sets need to be transmitted in the future, 327 the appropriate signalling mechanism for such data needs to be 328 evaluated, including factors such as the size and frequency of such 329 data. 331 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 332 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 333 message as a MIME body part per [RFC7852]. The body part is 334 identified by its MIME media type ('application/ 335 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 336 the body part. The body part is assigned a unique identifier which 337 is listed in a Content-ID header field in the body part. The SIP 338 message is marked as containing the MSD by adding (or appending to) a 339 Call-Info header field at the top level of the SIP message. This 340 Call-Info header field contains a CID URL referencing the body part's 341 unique identifier, and a 'purpose' parameter identifying the data as 342 the eCall MSD per the Emergency Call Additional Data Blocks registry 343 entry; the 'purpose' parameter's value is 344 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 345 SIP INFO request by using the INFO package defined in Section 10. 347 A PSAP or IVS transmits a metadata/control object (see Section 9) by 348 encoding it per the description in this document and attaching it to 349 a SIP message as a MIME body part per [RFC7852]. The body part is 350 identified by its MIME media type ('application/ 351 emergencyCallData.control+xml') in the Content-Type header field of 352 the body part. The body part is assigned a unique identifier which 353 is listed in a Content-ID header field in the body part. The SIP 354 message is marked as containing the metadata/control object by adding 355 (or appending to) a Call-Info header field at the top level of the 356 SIP message. This Call-Info header field contains a CID URL 357 referencing the body part's unique identifier, and a 'purpose' 358 parameter identifying the data as an eCall metadata/control block per 359 the Emergency Call Additional Data Blocks registry entry; the 360 'purpose' parameter's value is 'emergencyCallData.control'. Per 361 [RFC6086], a metadata/control object is carried in a SIP INFO request 362 by using the INFO package defined in Section 10. 364 An MSD or a metadata/control block is always enclosed in a multipart 365 (normally multipart/mixed) body part (even if it would otherwise be 366 the only body part in the SIP message), since as of the date of this 367 document, the use of Content-ID as a SIP header field is not defined 368 (while it is defined for use as a MIME header field). 370 A body part containing an MSD or metadata/control object has a 371 Content-Disposition header field value containing "By-Reference". 373 An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to 374 the initial INVITE and optionally attaches a metadata/control object 375 informing the PSAP of its capabilities. The MSD body part (and 376 metadata/control and PIDF-LO body parts if included) have a Content- 377 Disposition header field with the value "By-Reference; 378 handling=optional". Specifying "handling=optional" prevents the 379 INVITE from being rejected if it is processed by a legacy element 380 (e.g., a gateway between SIP and circuit-switched environments) that 381 does not understand the MSD (or metadata/control object or PIDF-LO). 383 The PSAP creates a metadata/control object acknowledging receipt of 384 the MSD and attaches it to the SIP final response to the INVITE. A 385 metadata/control object is not attached to provisional (e.g., 180) 386 responses. 388 A PSAP is able to reject a call while indicating that it is aware of 389 the situation by including a metadata/control object acknowledging 390 the MSD and containing "received=true" in a final response using SIP 391 response code 600 (Busy Everywhere), 486 (Busy Here), or 603 392 (Decline). 394 If the IVS receives an acknowledgment for an MSD containing 395 "received=false", this indicates that the PSAP was unable to properly 396 decode or process the MSD. The IVS action is not defined (e.g., it 397 might only log an error). Since the PSAP is able to request an 398 updated MSD during the call, if an initial MSD is unsatisfactory in 399 any way, the PSAP can choose to request another one. 401 A PSAP can request that the vehicle send an updated MSD during a call 402 (e.g., upon manual request of the PSAP call taker who suspects 403 vehicle state may have changed.) To do so, the PSAP creates a 404 metadata/control object requesting an MSD and attaches it to a SIP 405 INFO request and sends it within the dialog. The IVS then attaches 406 an updated MSD to a SIP INFO request and sends it within the dialog. 407 If the IVS is unable to send an MSD, it instead sends a metadata/ 408 control object acknowledging the request with the 'success' parameter 409 set to 'false' and a 'reason' parameter (and optionally a 'details' 410 parameter) indicating why the request could not be accomplished. Per 411 [RFC6086], metadata/control objects and MSDs are sent using the INFO 412 package defined in Section 10 . In addition, to align with how an 413 MSD or metadata/control block is transmitted in a SIP message other 414 than an INFO request, a Call-Info header field is included in the SIP 415 INFO request to reference the MSD or metadata/control block. See 416 Section 10 for information about the use of INFO requests to carry 417 data within an eCall. 419 The IVS is not expected to send an unsolicited MSD after the initial 420 INVITE. 422 This document does not mandate support for the data blocks defined in 423 [RFC7852]. 425 7. Call Setup 427 In circuit-switched eCall, the IVS places a special form of a 112 428 emergency call which carries an eCall flag (indicating that the call 429 is an eCall and also if the call was manually or automatically 430 triggered); the mobile network operator (MNO) recognizes the eCall 431 flag and routes the call to an eCall-capable PSAP; vehicle data is 432 transmitted to the PSAP via the eCall in-band modem (in the voice 433 channel). 435 ///----\\\ 112 voice call with eCall flag +------+ 436 ||| IVS |||---------------------------------------->+ PSAP | 437 \\\----/// vehicle data via eCall in-band modem +------+ 439 Figure 1: circuit-switched eCall 441 For NG-eCall, the IVS establishes an emergency call using a Request- 442 URI indicating a manual or automatic eCall; the MNO (or ESInet) 443 recognizes the eCall URN and routes the call to an NG-eCall capable 444 PSAP; the PSAP interpets the vehicle data sent with the call and 445 makes it available to the call taker. 447 ///----\\\ IMS emergency call with eCall URN +------+ 448 IVS ----------------------------------------->+ PSAP | 449 \\\----/// vehicle data included in call setup +------+ 451 Figure 2: NG-eCall 453 See Section 6 for information on how the MSD is transported within an 454 NG-eCall. 456 This document registers new service URN children within the "sos" 457 subservice. These URNs provide the mechanism by which an eCall is 458 identified, and differentiate between manually and automatically 459 triggered eCalls (which might be subject to different treatment, 460 depending on policy). The two service URNs are: 461 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 462 which requests resources associated with an emergency call placed by 463 an in-vehicle system, carrying a standardized set of data related to 464 the vehicle and incident. 466 Call routing is outside the scope of this document. 468 8. Test Calls 470 eCall requires the ability to place test calls (see [TS22.101] clause 471 10.7 and [EN_16062] clause 7.2.2). These are calls that are 472 recognized and treated to some extent as eCalls but are not given 473 emergency call treatment and are not handled by call takers. The 474 specific handling of test eCalls is not itself standardized; 475 typically, the test call facility allows the IVS or user to verify 476 that an eCall can be successfully established with voice 477 communication. The IVS might also be able to verify that the MSD was 478 successfully received. 480 A service URN starting with "test." indicates a test call. For 481 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 482 This functionality is defined in [RFC6881]. 484 This document registers "urn:service:test.sos.ecall" for eCall test 485 calls. 487 The CS-eCall test call facility is a non-emergency number so does not 488 get treated as an emergency call. For NG-eCall, MNOs, emergency 489 authorities, and PSAPs can determine how to treat a vehicle call 490 requesting the "test" service URN so that the desired functionality 491 is tested, but this is outside the scope of this document. 493 9. The Metadata/Control Object 495 eCall requires the ability for the PSAP to acknowledge successful 496 receipt of an MSD sent by the IVS, and for the PSAP to request that 497 the IVS send an MSD (e.g., the call taker can initiate a request for 498 a new MSD to see if there have been changes in the vehicle's state, 499 e.g., location, direction, number of fastened seatbelts). 501 This document defines a block of metadata/control data as an XML 502 structure containing elements used for eCall and other related 503 emergency call systems and extension points. (This metadata/control 504 block is in effect a high-level protocol between the PSAP and IVS.) 505 When the PSAP sends a metadata/control block in response to data sent 506 by the IVS in a SIP request other than INFO (e.g., the MSD in the 507 initial INVITE), the metadata/control block is sent in the SIP 508 response to that request (e.g., the response to the INVITE request). 509 When the PSAP sends a control block in other circumstances (e.g., 510 mid-call), the control block is transmitted from the PSAP to the IVS 511 in a SIP INFO request within the established dialog. The IVS sends 512 the requested data (the MSD) in a new INFO request (per [RFC6086]). 513 This mechanism flexibly allows the PSAP to send eCall-specific data 514 to the IVS and the IVS to respond. INFO requests are sent using an 515 appropriate INFO Package. See Section 6 for more information on 516 attaching a metadata/control block to a SIP message. See Section 10 517 for information about the use of INFO requests to carry data within 518 an eCall. 520 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 521 initial INVITE), the PSAP sends a metadata/control block indicating 522 successful/unsuccessful receipt of the MSD in the SIP response to the 523 request. This also informs the IVS that an NG-eCall is in operation. 524 If the IVS receives a SIP final response without the metadata/control 525 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 526 some part of the call is being handled as a legacy call). When the 527 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 528 receipt of a SIP INFO request containing a metadata/control block 529 requesting an MSD), the PSAP does not send a metadata/control block 530 indicating successful or unsuccessful receipt of the MSD. (Normal 531 SIP retransmission handles non-receipt of requested data; note that, 532 per [RFC6086], a 200 OK response to an INFO request indicates only 533 that the receiver has successfully received and accepted the INFO 534 request, it says nothing about the acceptability of the payload.) If 535 the IVS receives a request to send an MSD but it is unable to do so 536 for any reason, the IVS sends a metadata/control object acknowledging 537 the request and containing "success=false" and "reason" set to an 538 appropriate code. 540 This provides flexibility to handle various circumstances. For 541 example, if a PSAP is unable to accept an eCall (e.g., due to 542 overload or too many calls from the same location), it can reject the 543 INVITE. Since a metadata/control object is also included in the SIP 544 response that rejects the call, the IVS knows if the PSAP received 545 the MSD, and can inform the vehicle occupants that the PSAP 546 successfully received the vehicle location and information but can't 547 talk to the occupants at that time. Especially for SIP response 548 codes that indicate an inability to conduct a call (as opposed to a 549 technical inability to process the request), the IVS can also 550 determine that the call was successful on a technical level (e.g., 551 not helpful to retry as a CS-eCall). (Note that there could be edge 552 cases where the PSAP response is not received by the IVS, e.g., if an 553 intermediary sends a CANCEL, and an error response is forwarded 554 towards the IVS before the error response from the PSAP is received, 555 the response will be dropped, but these are unlikely to occur here.) 557 The metadata/control block is carried in the MIME type 'application/ 558 emergencyCallData.control+xml'. 560 The metadata/control block is designed for use with pan-European 561 eCall and also eCall-like systems (i.e., in other regions), and has 562 extension points. Note that eCall-like systems might define their 563 own vehicle data blocks, and so might need to register a new INFO 564 package to accomodate the new data MIME media type and the metadata/ 565 control object. 567 9.1. The Control Block 569 The control block is an XML data structure allowing for 570 acknowledgments, requests, and capabilities information. It is 571 carried in a body part with a specific MIME media type. Three 572 elements are defined for use within a control block: 574 ack Acknowledges receipt of data or a request. 576 capabilities Used in a control block sent from the IVS to the PSAP 577 (e.g., in the initial INVITE) to inform the PSAP of the 578 vehicle capabilities. Child elements contain all 579 actions and data types supported by the vehicle. It is 580 OPTIONAL for the IVS to send this block. Omitting the 581 block indicates that the IVS supports only the 582 mandatory functionality defined in this document. 584 request Used in a control block sent by the PSAP to the IVS, to 585 request the vehicle to perform an action. 587 The element indicates the object being acknowledged and reports 588 success or failure. 590 The element contains attributes to indicate the request and 591 to supply related information. The 'action' attribute is mandatory 592 and indicates the specific action. An IANA registry is created in 593 Section 15.8.1 to contain the allowed values. 595 The element has child elements to indicate 596 the actions supported by the IVS. 598 9.1.1. The element 600 The element acknowledges receipt of an eCall data object or 601 request. An element references the Content-ID of the object 602 being acknowledged. The PSAP MUST send an element 603 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 604 the INVITE); this element indicates if the PSAP considers the 605 MSD successfully received or not. An element is not sent for a 606 element. 608 The element has the following attributes: 610 9.1.1.1. Attributes of the element 612 The element has the following attributes: 614 Name: ref 615 Usage: Mandatory 616 Type: anyURI 617 Direction: Sent in either direction 618 Description: References the Content-ID of the body part being 619 acknowledged. 620 Example: 621 Name: received 622 Usage: Conditional: mandatory in an element sent by a PSAP 623 Type: Boolean 624 Direction: In this document, sent from the PSAP to the IVS 625 Description: Indicates if the referenced object was considered 626 successfully received or not. 627 Example: 629 9.1.1.2. Child Element of the element 631 For extensibility, the element has the following child element: 633 Name: actionResult 634 Usage: Optional 635 Direction: Sent from the IVS to the PSAP 636 Description: An element indicates the result of an 637 action (other than a successfully executed 'send-data' action). 638 The element contains an element for each 639 element that is not a successfully executed 'send-data' 640 action. The element has the following attributes: 642 Name: action 643 Usage: Mandatory 644 Type: token 645 Description: Contains the value of the 'action' attribute of the 646 element 648 Name: success 649 Usage: Mandatory 650 Type: Boolean 651 Description: Indicates if the action was successfully 652 accomplished 654 Name: reason 655 Usage: Conditional 656 Type: token 657 Description: Used when 'success' is "false", this attribute 658 contains a reason code for a failure. A registry for reason 659 codes is defined in Section 15.8.2. 661 Name: details 662 Usage: optional 663 Type: string 664 Description: Contains further explanation of the circumstances of 665 a success or failure. The contents are implementation-specific 666 and human-readable. 668 9.1.1.3. Ack Examples 670 671 675 677 679 Figure 3: Ack Example from PSAP to IVS 681 9.1.2. The element 683 The element is transmitted by the IVS to indicate to 684 the PSAP its capabilities. No attributes for this element are 685 currently defined. The following child elements are defined: 687 9.1.2.1. Child Elements of the element 689 The element has the following child elements: 691 Name: request 692 Usage: Mandatory 693 Description: The element contains a child 694 element per action supported by the vehicle. 696 Examples: 697 699 It is OPTIONAL for the IVS to support the element. If 700 the IVS does not send a element, this indicates that 701 the only action supported by the IVS is 'send-data' with 702 'datatype' set to 'eCall.MSD'. 704 9.1.2.2. Capabilities Example 705 706 710 711 712 714 716 Figure 4: Capabilities Example 718 9.1.3. The element 720 A element appears one or more times on its own or as a 721 child of a element. It allows the PSAP to request 722 that the IVS perform an action. The only action that MUST be 723 supported is to send an MSD. The following attributes and child 724 elements are defined: 726 9.1.3.1. Attributes of the element 728 The element has the following attributes: 730 Name: action 731 Usage: Mandatory 732 Type: token 733 Direction: Sent in either direction 734 Description: Identifies the action that the vehicle is requested to 735 perform (in a element within a element, 736 indicates an action that the vehicle is capable of performing). 737 An IANA registry is established in Section 15.8.1 to contain the 738 allowed values. 739 Example: action="send-data" 741 Name: msgid 742 Usage: Conditional 743 Type: int 744 Direction: Sent in either direction 745 Description: Defined for extensibility. 746 Example: msgid="3" 748 Name: persistance 749 Usage: Optional 750 Type: duration 751 Direction: Sent in either direction 752 Description: Defined for extensibility. Specifies how long to carry 753 on the specified action. If absent, the default is for the 754 duration of the call. 755 Example: persistance="PT1H" 757 Name: datatype 758 Usage: Conditional 759 Type: token 760 Direction: Sent in either direction 761 Description: Mandatory with a "send-data" action within a 762 element that is not within a element. Specifies 763 the data block that the IVS is requested to transmit, using the 764 same identifier as in the 'purpose' attribute set in a Call-Info 765 header field to point to the data block. Permitted values are 766 contained in the 'Emergency Call Data Types' IANA registry 767 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 768 to support. 769 Example: datatype="eCall.MSD" 771 Name: supported-values 772 Usage: Conditional 773 Type: string 774 Direction: Sent from the IVS to the PSAP 775 Description: Defined for extensibility. Used in a element 776 that is a child of a element, this attribute lists 777 all supported values of the action type. Permitted values depend 778 on the action value. Multiple values are separated with a 779 semicolon. 781 Name: requested-state 782 Usage: Conditional 783 Type: token 784 Direction: Sent from the PSAP to the IVS 785 Description: Defined for extension. Indicates the requested state 786 of an element associated with the request type. Permitted values 787 depend on the request type. 789 Name: element-ID 790 Usage: Conditional 791 Type: token 792 Direction: Sent from the PSAP to the IVS 793 Description: Defined for extension. Identifies the element to be 794 acted on. Permitted values depend on the request type. 796 9.1.3.2. Request Example 798 799 803 805 807 Figure 5: Request Example 809 10. The emergencyCallData.eCall.MSD INFO package 811 This document registers the 'emergencyCallData.eCall.MSD' INFO 812 package. 814 Both endpoints (the IVS and the PSAP equipment) include 815 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 816 [RFC6086] to indicate ability to receive INFO requests carrying data 817 as described here. 819 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 820 the ability to receive eCall related body parts as specified in [TBD: 821 THIS DOCUMENT]. 823 An INFO request message carrying body parts related to an emergency 824 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 825 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 827 The requirements of Section 10 of [RFC6086] are addressed in the 828 following sections. 830 10.1. Overall Description 832 This section describes "what type of information is carried in INFO 833 requests associated with the Info Package, and for what types of 834 applications and functionalities UAs can use the Info Package." 836 INFO requests associated with the emergencyCallData.eCall.MSD INFO 837 package carry data associated with emergency calls as defined in 838 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 839 calls established using SIP. The functionality is to carry vehicle 840 data and metadata/control information between vehicles and PSAPs. 841 Refer to [TBD: THIS DOCUMENT] for more information. 843 10.2. Applicability 845 This section describes "why the Info Package mechanism, rather than 846 some other mechanism, has been chosen for the specific use-case...." 848 The use of INFO is based on an analysis of the requirements against 849 the intent and effects of INFO versus other approaches (which 850 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 851 transport, and non-SIP protocols). In particular, the transport of 852 emergency call data blocks occurs within a SIP emergency dialog, per 853 Section 6, and is normally carried in the initial INVITE and its 854 response; the use of INFO only occurs when emergency-call-related 855 data needs to be sent mid-call. While MESSAGE could be used, it is 856 not tied to a SIP dialog as is INFO and thus might not be associated 857 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 858 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 859 service, but the semantics are not a good fit, e.g., the subscribe/ 860 notify mechanism provides one-way communication consisting of (often 861 multiple) notifications from notifier to subscriber indicating that 862 certain events in notifier have occurred, whereas what's needed here 863 is two-way communication of data related to the emergency dialog. 864 Use of the media plane mechanisms was discounted because the number 865 of messages needing to be exchanged in a dialog is normally zero or 866 very few, and the size of the data is likewise very small. The 867 overhead caused by user plane setup (e.g., to use MSRP as transport) 868 would be disproportionately large. 870 Based on the the analyses, the SIP INFO method was chosen to provide 871 for mid-call data transport. 873 10.3. Info Package Name 875 The info package name is emergencyCallData.eCall.MSD 877 10.4. Info Package Parameters 879 None 881 10.5. SIP Option-Tags 883 None 885 10.6. INFO Request Body Parts 887 The body for an emergencyCallData.eCall.MSD info package is a 888 multipart (normally multipart/mixed) body containing zero or one 889 application/emergencyCallData.eCall.MSD+per part (containing an MSD) 890 and zero or more application/emergencyCallData.control+xml 891 (containing a metadata/control object) parts. At least one MSD or 892 metadata/control body part is expected; the behavior upon receiving 893 an INFO request with neither is undefined. 895 The body parts are sent per [RFC6086], and in addition, to align with 896 with how these body parts are sent in SIP messages other than INFO 897 requests, each associated body part is referenced by a Call-Info 898 header field at the top level of the SIP message. The body part has 899 a Content-Disposition header field set to "By-Reference". 901 An MSD or metadata/control block is always enclosed in a multipart 902 body part (even if it would otherwise be the only body part in the 903 SIP message), since as of the date of this document, the use of 904 Content-ID as a SIP header field is not defined (while it is defined 905 for use as a MIME header field). The innermost multipart that 906 contains only body parts associated with the INFO package has a 907 Content-Disposition value of Info-Package. 909 See [TBD: THIS DOCUMENT] for more information. 911 10.7. Info Package Usage Restrictions 913 Usage is limited to vehicle-initiated emergency calls as defined in 914 [TBD: THIS DOCUMENT]. 916 10.8. Rate of INFO Requests 918 The SIP INFO request is used within an established emergency call 919 dialog for the PSAP to request the IVS to send an updated MSD, and 920 for the IVS to send a requested MSD. Because this is normally done 921 only on manual request of the PSAP call taker (who suspects some 922 aspect of the vehicle state has changed), the rate of SIP INFO 923 requests associated with the emergencyCallData.eCall.MSD info package 924 is normally quite low (most dialogs are likely to contain zero INFO 925 requests, while others might carry an occasional request). 927 10.9. Info Package Security Considerations 929 The MIME media type registations for the data blocks that can be 930 carried using this INFO package contains a discussion of the security 931 and/or privacy considerations specific to that data block. The 932 "Security Considerations" and "Privacy Considerations" sections of 933 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 934 the data carried in eCalls. 936 10.10. Implementation Details 938 See [TBD: THIS DOCUMENT] for protocol details. 940 10.11. Examples 942 See [TBD: THIS DOCUMENT] for protocol examples. 944 11. Examples 946 Figure 6 illustrates an eCall. The call uses the request URI 947 'urn:service:sos.ecall.automatic' service URN and is recognized as an 948 eCall, and further as one that was invoked automatically by the IVS 949 due to a crash or other serious incident. In this example, the 950 originating network routes the call to an ESInet which routes the 951 call to the appropriate NG-eCall capable PSAP. The emergency call is 952 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 953 the entry point into the ESInet. The ESRP routes the call to a PSAP, 954 where it is received by a call taker. In deployments where there is 955 no ESInet, the originating network routes the call directly to the 956 appropriate NG-eCall capable PSAP, an illustration of which would be 957 identical to the one below except without an ESInet or ESRP. 959 +------------+ +---------------------------------------+ 960 | | | +-------+ | 961 | | | | PSAP2 | | 962 | | | +-------+ | 963 | | | | 964 | | | +------+ +-------+ | 965 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 966 | | | +------+ +-------+ | 967 | | | | 968 | | | +-------+ | 969 | | | | PSAP3 | | 970 | Originating| | +-------+ | 971 | Mobile | | | 972 | Network | | ESInet | 973 +------------+ +---------------------------------------+ 975 Figure 6: Example of NG-eCall Message Flow 977 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 978 for an updated MSD. The call flow shows the IVS initiating an 979 emergency call, including the MSD in the INVITE. The PSAP includes 980 in the 200 OK response a metadata/control object acknowledging 981 receipt of the MSD. During the call, the PSAP sends a request for an 982 MSD in an INFO request. The IVS sends the requested MSD in a new 983 INFO request. 985 IVS PSAP 986 |(1) INVITE (eCall MSD) | 987 |------------------------------------------->| 988 | | 989 |(2) 200 OK (eCall metadata [ack MSD]) | 990 |<-------------------------------------------| 991 | | 992 |(3) start media stream(s) | 993 |............................................| 994 | | 995 |(4) INFO (eCall metadata [request MSD]) | 996 |<-------------------------------------------| 997 | | 998 |(5) 200 OK | 999 |------------------------------------------->| 1000 | | 1001 |(6) INFO (eCall MSD) | 1002 |------------------------------------------->| 1003 | | 1004 |(7) 200 OK | 1005 |<-------------------------------------------| 1006 | | 1007 |(8) BYE | 1008 |<-------------------------------------------| 1009 | | 1010 |(9) end media streams | 1011 |............................................| 1012 | | 1013 |(10) 200 OK | 1014 |------------------------------------------->| 1016 Figure 7: NG-eCall Call Flow Illustration 1018 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 1019 contains an MSD. For simplicity, the example does not show all SIP 1020 headers, nor the SDP contents, nor does it show any additional data 1021 blocks added by the IVS or the originating mobile network. Because 1022 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 1023 contents cannot be included in a text document. 1025 INVITE urn:service:sos.ecall.automatic SIP/2.0 1026 To: urn:service:sos.ecall.automatic 1027 From: ;tag=9fxced76sl 1028 Call-ID: 3848276298220188511@atlanta.example.com 1029 Geolocation: 1030 Geolocation-Routing: no 1031 Call-Info: ; 1032 purpose=emergencyCallData.eCall.MSD 1033 Accept: application/sdp, application/pidf+xml, 1034 application/emergencyCallData.control+xml 1035 CSeq: 31862 INVITE 1036 Recv-Info: emergencyCallData.eCall.MSD 1037 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1038 SUBSCRIBE, NOTIFY, UPDATE 1039 Content-Type: multipart/mixed; boundary=boundary1 1040 Content-Length: ... 1042 --boundary1 1043 Content-Type: application/sdp 1045 ...Session Description Protocol (SDP) goes here... 1047 --boundary1 1048 Content-Type: application/pidf+xml 1049 Content-ID: 1050 Content-Disposition: by-reference;handling=optional 1052 ...PIDF-LO goes in here 1054 --boundary1 1055 Content-Type: application/emergencyCallData.eCall.MSD+per 1056 Content-ID: <1234567890@atlanta.example.com> 1057 Content-Disposition: by-reference;handling=optional 1059 ...MSD in ASN.1 PER encoding goes here... 1061 --boundary1-- 1063 Figure 8: SIP NG-eCall INVITE 1065 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1066 the INVITE of Figure 8, containing a control block acknowledging 1067 successful receipt of the eCall MSD. (For simplicity, the example 1068 does not show all SIP headers.) 1069 SIP/2.0 200 OK 1070 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1071 From: ;tag=9fxced76sl 1072 Call-ID: 3848276298220188511@atlanta.example.com 1073 Call-Info: ; 1074 purpose=emergencyCallData.control 1075 Accept: application/sdp, application/pidf+xml, 1076 application/emergencyCallData.control+xml, 1077 application/emergencyCallData.eCall.MSD+per 1078 CSeq: 31862 INVITE 1079 Recv-Info: emergencyCallData.eCall.MSD 1080 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1081 SUBSCRIBE, NOTIFY, UPDATE 1082 Content-Type: multipart/mixed; boundary=boundaryX 1083 Content-Length: ... 1085 --boundaryX 1086 Content-Type: application/sdp 1088 ...Session Description Protocol (SDP) goes here... 1090 --boundaryX 1091 Content-Type: application/emergencyCallData.control+xml 1092 Content-ID: <2345678901@atlanta.example.com> 1093 Content-Disposition: by-reference 1095 1096 1100 1101 1103 --boundaryX-- 1105 Figure 9: 200 OK response to INVITE 1107 Figure 10 illustrates a SIP INFO request containing a metadata/ 1108 control block requesting an eCall MSD. (For simplicity, the example 1109 does not show all SIP headers.) 1110 INFO sip:+13145551111@example.com SIP/2.0 1111 To: ;tag=9fxced76sl 1112 From: Exemplar PSAP ;tag=8gydfe65t0 1113 Call-ID: 3848276298220188511@atlanta.example.com 1114 Call-Info: ; 1115 purpose=emergencyCallData.control 1116 CSeq: 41862 INFO 1117 Info-Package: emergencyCallData.eCall.MSD 1118 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1119 SUBSCRIBE, NOTIFY, UPDATE 1120 Content-Type: multipart/mixed; boundary=boundaryZZZ 1121 Content-Dispositio: Info-Package 1122 Content-Length: ... 1124 --boundaryZZZ 1125 Content-Disposition: by-reference 1126 Content-Type: application/emergencyCallData.control+xml 1127 Content-ID: <3456789012@atlanta.example.com> 1129 1130 1134 1136 1137 --boundaryZZZ-- 1139 Figure 10: INFO requesting MSD 1141 Figure 11 illustrates a SIP INFO request containing an MSD. For 1142 simplicity, the example does not show all SIP headers. Because the 1143 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1144 cannot be included in a text document. 1146 INFO urn:service:sos.ecall.automatic SIP/2.0 1147 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1148 From: ;tag=9fxced76sl 1149 Call-ID: 3848276298220188511@atlanta.example.com 1150 Call-Info: ; 1151 purpose=emergencyCallData.eCall.MSD 1152 CSeq: 51862 INFO 1153 Info-Package: emergencyCallData.eCall.MSD 1154 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1155 SUBSCRIBE, NOTIFY, UPDATE 1156 Content-Type: multipart/mixed; boundary=boundaryLine 1157 Content-Disposition: Info-Package 1158 Content-Length: ... 1160 --boundaryLine 1161 Content-Type: application/emergencyCallData.eCall.MSD+per 1162 Content-ID: <4567890123@atlanta.example.com> 1163 Content-Disposition: by-reference 1165 ...MSD in ASN.1 PER encoding goes here... 1167 --boundaryLine-- 1169 Figure 11: INFO containing MSD 1171 12. Security Considerations 1173 The security considerations described in [RFC5069] apply here. 1175 In addition to any network-provided location (which might be 1176 determined solely by the network, or in cooperation with or possibly 1177 entirely by the originating device), an eCall carries an IVS-supplied 1178 location within the MSD. This is likely to be useful to the PSAP, 1179 especially when no network-provided location is included, or when the 1180 two locations are independently determined. Even in situations where 1181 the network-supplied location is limited to the cell site, this can 1182 be useful as a sanity check on the device-supplied location contained 1183 in the MSD. 1185 The document [RFC7378] discusses trust issues regarding location 1186 provided by or determined in cooperation with end devices. 1188 Security considerations specific to the mechanism by which the PSAP 1189 sends acknowledgments and requests to the vehicle are discussed in 1190 the "Security Considerations" block of Section 15.3. Note that an 1191 attacker that has access to and is capable of generating a response 1192 to the initial INVITE request could generate a 600 (Busy Everywhere), 1193 486 (Busy Here), or 603 (Decline) response that includes a metadata/ 1194 control object containing a reference to the MSD in the initial 1195 INVITE and a "received=true" field, which could result in the IVS 1196 perceiving the PSAP to be overloaded and hence not attempting to 1197 reinitiate the call. The risk can be mitigated as discussed in the 1198 "Security Considerations" block of Section 15.3. 1200 Data received from external sources inherently carries implementation 1201 risks. For example, depending on the platform, buffer overflows can 1202 introduce remote code execution vulnerabilities, null characters can 1203 corrupt strings, numeric values used for internal calculations can 1204 result in underflow/overflow errors, malformed XML objects can expose 1205 parsing bugs, etc. Implementations need to be cognizant of the 1206 potential risks, observe best practices (which might include 1207 sufficiently capable static code analysis, fuzz testing, component 1208 isolation, avoiding use of unsafe coding techniques, third-party 1209 attack tests, signed software, over-the-air updates, etc.), and have 1210 multiple levels of protection. Implementors need to be aware that, 1211 potentially, the data objects described here and elsewhere might be 1212 malformed, might contain unexpected characters, excessively long 1213 attribute values, elements, etc. 1215 The security considerations discussed in [RFC7852] apply here (see 1216 especially the discussion of TLS, TLS versions, cypher suites, and 1217 PKI). 1219 When vehicle data or control/metadata is contained in a signed or 1220 encrypted body part, the enclosing multipart (e.g., multipart/signed 1221 or multipart/encrypted) has the same Content-ID as the enclosed data 1222 part. This allows an entity to identify and access the data blocks 1223 it is interested in without having to dive deeply into the message 1224 structure or decrypt parts it is not interested in. (The 'purpose' 1225 parameter in a Call-Info header field identifies the data and 1226 contains a CID URL pointing to the data block in the body, which has 1227 a matching Content-ID body part header field). 1229 13. Privacy Considerations 1231 The privacy considerations discussed in [RFC7852] apply here. The 1232 MSD carries some identifying and personal information (mostly about 1233 the vehicle and less about the owner), as well as location 1234 information, and so needs to be protected against unauthorized 1235 disclosure. Local regulations may impose additional privacy 1236 protection requirements. 1238 Privacy considerations specific to the data structure containing 1239 vehicle information are discussed in the "Security Considerations" 1240 block of Section 15.2. 1242 Privacy considerations specific to the mechanism by which the PSAP 1243 sends acknowledgments and requests to the vehicle are discussed in 1244 the "Security Considerations" block of Section 15.3. 1246 14. XML Schema 1248 This section defines an XML schema for the control block. The text 1249 description of the control block in Section 9.1 is normative and 1250 supersedes any conflicting aspect of this schema. 1252 1253 1255 1263 1265 1268 1269 1270 1271 1272 1274 1275 1276 1279 1280 1281 1282 1283 1285 1286 1287 1288 1289 1291 1292 1295 1298 1300 1301 1302 conditionally mandatory 1303 when @success='false" 1304 to indicate reason code 1305 for a failure 1306 1307 1308 1309 1311 1313 1314 1315 1318 1319 1322 1324 1325 1326 1327 1329 1330 1331 1332 1333 1338 1341 1342 1343 1344 1345 1347 1348 1349 1350 1351 1354 1355 1357 1358 1360 1361 1363 1364 1366 1367 1368 1369 1371 1373 Figure 12: Control Block Schema 1375 15. IANA Considerations 1377 This document formalizes the "EmergencyCallData" media (MIME) subtype 1378 tree. This tree is used only for content associated with emergency 1379 communications. New subtypes in this tree can be registered by the 1380 IETF or by other standards organizations working with emergency 1381 communications, using the "Specification Required" rule, which 1382 implies expert review. The designated expert is the ECRIT working 1383 group. 1385 15.1. Service URN Registrations 1387 IANA is requested to register the URN 'urn:service:sos.ecall' under 1388 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1390 This service requests resources associated with an emergency call 1391 placed by an in-vehicle system, carrying a standardized set of data 1392 related to the vehicle and incident. Two sub-services are registered 1393 as well: 1395 urn:service:sos.ecall.manual 1397 Used with an eCall invoked due to manual interaction by a vehicle 1398 occupant. 1400 urn:service:sos.ecall.automatic 1402 Used with an eCall invoked automatically, for example, due to a 1403 crash or other serious incident. 1405 IANA is also requested to register the URN 1406 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1407 defined in Setcion 17.2 of [RFC6881]. 1409 15.2. MIME Media Type Registration for 'application/ 1410 emergencyCallData.eCall.MSD+per' 1412 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1413 as a MIME media type, with a reference to this document, in 1414 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1415 RFC 7303 [RFC7303]. 1417 MIME media type name: application 1419 MIME subtype name: emergencyCallData.eCall.MSD+per 1421 Mandatory parameters: none 1423 Optional parameters: none 1425 Encoding scheme: binary 1427 Encoding considerations: Uses ASN.1 PER, which is a binary 1428 encoding; when transported in SIP, binary content transfer 1429 encoding is used. 1431 Security considerations: This media type is designed to carry 1432 vehicle and incident-related data during an emergency call. This 1433 data contains personal information including vehicle VIN, 1434 location, direction, etc. Appropriate precautions need to be 1435 taken to limit unauthorized access, inappropriate disclosure to 1436 third parties, and eavesdropping of this information. In general, 1437 it is acceptable for the data to be unprotected while briefly in 1438 transit within the Mobile Network Operator (MNO); the MNO is 1439 trusted to not permit the data to be accessed by third parties. 1440 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1442 Interoperability considerations: None 1444 Published specification: Annex A of EN 15722 [msd] 1446 Applications which use this media type: Pan-European eCall 1447 compliant systems 1449 Additional information: None 1451 Magic Number: None 1453 File Extension: None 1455 Macintosh file type code: 'BINA' 1457 Person and email address for further information: Randall Gellens, 1458 rg+ietf@randy.pensive.org 1460 Intended usage: LIMITED USE 1462 Author: The MSD specification was produced by the European 1463 Committee For Standardization (CEN). For contact information, 1464 please see . 1466 Change controller: The European Committee For Standardization 1467 (CEN) 1469 15.3. MIME Media Type Registration for 'application/ 1470 emergencyCallData.control+xml' 1472 IANA is requested to add application/emergencyCallData.control+xml as 1473 a MIME media type, with a reference to this document, in accordance 1474 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1475 [RFC7303]. 1477 MIME media type name: application 1479 MIME subtype name: emergencyCallData.control+xml 1480 Mandatory parameters: none 1482 Optional parameters: charset 1484 Indicates the character encoding of the XML content. 1486 Encoding considerations: Uses XML, which can employ 8-bit 1487 characters, depending on the character encoding used. See 1488 Section 3.2 of RFC 7303 [RFC7303]. 1490 Security considerations: 1492 This media type carries metadata and control information and 1493 requests, such as from a Public Safety Answering Point (PSAP) 1494 to an In-Vehicle System (IVS) during an emergency call. 1496 Metadata (such as an acknowledgment that data sent by the IVS 1497 to the PSAP was successfully received) has limited privacy and 1498 security implications. Control information (such as requests 1499 from the PSAP that the vehicle perform an action) has some 1500 privacy and security implications. The privacy concern arises 1501 from the ability to request the vehicle to transmit a data set, 1502 which as described in Section 15.2, can contain personal 1503 information. The security concern is the ability to request 1504 the vehicle to perform an action. Control information needs to 1505 originate only from a PSAP or other emergency services 1506 provider, and not be modified en-route. The level of integrity 1507 of the cellular network over which the emergency call is placed 1508 is a consideration: when the IVS initiates an eCall over a 1509 cellular network, in most cases it relies on the MNO to route 1510 the call to a PSAP. (Calls placed using other means, such as 1511 Wi-Fi or over-the-top services, generally incur somewhat higher 1512 levels of risk than calls placed "natively" using cellular 1513 networks.) A call-back from a PSAP merits additional 1514 consideration, since current mechanisms are not ideal for 1515 verifying that such a call is indeed a call-back from a PSAP in 1516 response to an emergency call placed by the IVS. See the 1517 discussion in Section 12 and the PSAP Callback document 1518 [RFC7090]. 1520 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1522 Interoperability considerations: None 1524 Published specification: This document 1526 Applications which use this media type: Pan-European eCall 1527 compliant systems 1528 Additional information: None 1530 Magic Number: None 1532 File Extension: .xml 1534 Macintosh file type code: 'TEXT' 1536 Person and email address for further information: Randall Gellens, 1537 rg+ietf@randy.pensive.org 1539 Intended usage: LIMITED USE 1541 Author: The IETF ECRIT WG. 1543 Change controller: The IETF ECRIT WG. 1545 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1546 Additional Data Blocks registry 1548 This specification requests IANA to add the 'eCall.MSD' entry to the 1549 Emergency Call Additional Data Blocks registry, with a reference to 1550 this document. 1552 15.5. Registration of the 'control' entry in the Emergency Call 1553 Additional Data Blocks registry 1555 This specification requests IANA to add the 'control' entry to the 1556 Emergency Call Additional Data Blocks registry, with a reference to 1557 this document. 1559 15.6. Registration of the emergencyCallData.eCall Info Package 1561 IANA is requested to add emergencyCallData.eCall to the Info Packages 1562 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1563 reference to this document. 1565 15.7. URN Sub-Namespace Registration 1567 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1569 This section registers a new XML namespace, as per the guidelines in 1570 RFC 3688 [RFC3688]. 1572 URI: urn:ietf:params:xml:ns:eCall 1574 Registrant Contact: IETF, ECRIT working group, , as 1575 delegated by the IESG . 1577 XML: 1579 BEGIN 1580 1581 1583 1584 1585 1587 Namespace for eCall Data 1588 1589 1590

Namespace for eCall Data

1591

See [TBD: This document].

1592 1593 1594 END 1596 15.7.2. Registration for urn:ietf:params:xml:ns:control 1598 This section registers a new XML namespace, as per the guidelines in 1599 RFC 3688 [RFC3688]. 1601 URI: urn:ietf:params:xml:ns:control 1603 Registrant Contact: IETF, ECRIT working group, , as 1604 delegated by the IESG . 1606 XML: 1608 BEGIN 1609 1610 1612 1613 1614 1616 Namespace for eCall Data: 1617 Control Block 1618 1619 1620

Namespace for eCall Data

1621

Control Block

1622

See [TBD: This document].

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