idnits 2.17.1 draft-ietf-ecrit-ecall-19.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 18, 2016) is 2747 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: A later version (-23) exists of draft-ietf-ecrit-car-crash-16 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 21, 2017 Individual 6 October 18, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-19.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 21, 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 . . . . . . . . . . . . . . . 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-18 to draft-ietf-19 . . . . . . 38 117 18.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 118 18.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 119 18.4. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 38 120 18.5. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 39 121 18.6. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 39 122 18.7. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 39 123 18.8. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 39 124 18.9. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39 125 18.10. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 40 126 18.11. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 40 127 18.12. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40 128 18.13. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 41 129 18.14. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 41 130 18.15. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 41 131 18.16. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41 132 18.17. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41 133 18.18. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 42 134 18.19. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 42 135 18.20. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42 136 18.21. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42 137 18.22. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42 138 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 139 19.1. Normative References . . . . . . . . . . . . . . . . . . 43 140 19.2. Informative references . . . . . . . . . . . . . . . . . 44 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 143 1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 This document re-uses terminology defined in Section 3 of [RFC5012]. 151 Additionally, we use the following abbreviations: 153 +--------+----------------------------------------+ 154 | Term | Expansion | 155 +--------+----------------------------------------+ 156 | 3GPP | 3rd Generation Partnership Project | 157 | | | 158 | CEN | European Committee for Standardization | 159 | | | 160 | EENA | European Emergency Number Association | 161 | | | 162 | ESInet | Emergency Services IP network | 163 | | | 164 | IMS | IP Multimedia Subsystem | 165 | | | 166 | IVS | In-Vehicle System | 167 | | | 168 | MNO | Mobile Network Operator | 169 | | | 170 | MSD | Minimum Set of Data | 171 | | | 172 | PSAP | Public Safety Answering Point | 173 +--------+----------------------------------------+ 175 2. Document Scope 177 This document is focused on the signaling, data exchange, and 178 protocol needs of next-generation eCall (NG-eCall, also referred to 179 as packet-switched eCall or all-IP eCall) within the SIP framework 180 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 181 itself is specified by 3GPP (3rd Generation Partnership Project) and 182 CEN (European Committee for Standardization) and these specifications 183 include far greater scope than is covered here. 185 The eCall service operates over cellular wireless communication, but 186 this document does not address cellular-specific details, nor client 187 domain selection (e.g., circuit-switched versus packet-switched). 188 All such aspects are the purview of their respective standards 189 bodies. The scope of this document is limited to eCall operating 190 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling 191 [TS23.167]). 193 The technical contents of this document also provide a basis for 194 reuse and extension for related emergency call systems (which is why 195 there are extension points), but such reuse is a topic for other 196 documents. 198 Note that vehicles designed for multiple regions might need to 199 support eCall and other Advanced Automatic Crash Notification (AACN) 200 systems (such as described in [I-D.ietf-ecrit-car-crash]), but this 201 is out of scope of this document. 203 3. Introduction 205 Emergency calls made from vehicles (e.g., in the event of a crash) 206 assist in significantly reducing road deaths and injuries by allowing 207 emergency services to be aware of the incident, the state of the 208 vehicle, the location of the vehicle, and to have a voice channel 209 with the vehicle occupants. This enables a quick and appropriate 210 response. 212 The European Commission initiative of eCall was conceived in the late 213 1990s, and has evolved to a European Parliament decision requiring 214 the implementation of a compliant in-vehicle system (IVS) in new 215 vehicles and the deployment of eCall in the European Member States in 216 the very near future. Other regions are developing eCall-compatible 217 systems. 219 The pan-European eCall system provides a standardized and mandated 220 mechanism for emergency calls by vehicles. eCall establishes 221 procedures for such calls to be placed by in-vehicle systems, 222 recognized and processed by the mobile network, and routed to a 223 specialized PSAP where the vehicle data is available to assist the 224 call taker in assessing and responding to the situation. eCall 225 provides a standard set of vehicle, sensor (e.g., crash related), and 226 location data. 228 An eCall can be either user-initiated or automatically triggered. 229 Automatically triggered eCalls indicate a car crash or some other 230 serious incident. Manually triggered eCalls might be reports of 231 witnessed crashes or serious hazards. PSAPs might apply specific 232 operational handling to manual and automatic eCalls. 234 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 235 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 236 call setup mark the call as an eCall, and further indicate if the 237 call was automatically or manually triggered. The call is routed to 238 an eCall-capable PSAP, a voice channel is established between the 239 vehicle and the PSAP, and an eCall in-band modem is used to carry a 240 defined set of vehicle, sensor (e.g., crash related), and location 241 data (the Minimum Set of Data or MSD) within the voice channel. The 242 same in-band mechanism is used for the PSAP to acknowledge successful 243 receipt of the MSD, and to request the vehicle to send a new MSD 244 (e.g., to check if the state of or location of the vehicle or its 245 occupants has changed). NG-eCall moves from circuit switched to all- 246 IP, and carries the vehicle data and eCall signaling as additional 247 data carried with the call. This document describes how IETF 248 mechanisms for IP-based emergency calls, including [RFC6443] and 249 [RFC7852] are used to provide the signaling and data exchange of the 250 next generation of pan-European eCall. 252 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 253 has published a Technical Report titled "Mobile Standards Group 254 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 255 recommendations regarding support for eCall in an all-IP environment. 256 The recommendations include the use of 3GPP IMS emergency calling 257 with additional elements identifying the call as an eCall and as 258 carrying eCall data and with mechanisms for carrying the data and 259 eCall signaling. 3GPP IMS emergency services support multimedia, 260 providing the ability to carry voice, text, and video. This 261 capability is referred to within 3GPP as Multimedia Emergency 262 Services (MMES). 264 A transition period will exist during which time the various entities 265 involved in initiating and handling an eCall might support next- 266 generation eCall, legacy eCall, or both. The issues of migration and 267 co-existence during the transition period are outside the scope of 268 this document. 270 This document indicates how to use IP-based emergency services 271 mechanisms to support next-generation eCall. 273 This document also registers MIME media types and an Emergency Call 274 Additional Data Block for the eCall vehicle data (MSD) and metadata/ 275 control data, and an INFO package to enable carrying this data in 276 INFO requests. 278 The MSD is carried in the MIME type 'application/ 279 emergencyCallData.eCall.MSD+per' and the metadata/control block is 280 carried in the MIME type 'application/emergencyCallData.control+xml' 281 (both of which are registered in Section 15) An INFO package is 282 defined (in Section 10) to enable these MIME types to be carried in 283 SIP INFO requests, per [RFC6086]. 285 4. eCall Requirements 287 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 288 [TS22.101] clauses 10.7 and A.27 and [TS24.229] section 4.7.6. 289 Requirements specific to vehicle data are contained in EN 15722 290 [msd]. 292 5. Vehicle Data 294 Pan-European eCall provides a standardized and mandated set of 295 vehicle related data, known as the Minimum Set of Data (MSD). The 296 European Committee for Standardization (CEN) has specified this data 297 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 298 circuit-switched eCall and this document use the ASN.1 PER encoding, 299 which is specified in Annex A of EN 15722 [msd] (the XML encoding 300 specified in Annex C is not used in this document). 302 This document registers the 'application/ 303 emergencyCallData.eCall.MSD+per' MIME media type to enable the MSD to 304 be carried in SIP. As an ASN.1 PER encoded object, the data is 305 binary and transported using binary content transfer encoding within 306 SIP messages. This document also adds the 'eCall.MSD' entry to the 307 Emergency Call Additional Data Blocks registry to enable the MSD to 308 be recognized as such in a SIP-based eCall emergency call. (See 309 [RFC7852] for more information about the registry and how it is 310 used.) 312 See Section 6 for a discussion of how the MSD vehicle data is 313 conveyed in an NG-eCall. 315 6. Data Transport 317 [RFC7852] establishes a general mechanism for attaching blocks of 318 data to a SIP emergency call. This mechanism permits certain 319 emergency call MIME types to be attached to SIP messages. This 320 document makes use of that mechanism. This document also registers 321 an INFO package (in Section 10) to enable eCall related data blocks 322 to be carried in SIP INFO requests (per [RFC6086], new INFO usages 323 require the definition of an INFO package). 325 Note that if other data sets need to be transmitted in the future, 326 the appropriate signalling mechanism for such data needs to be 327 evaluated, including factors such as the size and frequency of such 328 data. 330 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 331 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 332 message as a MIME body part per [RFC7852]. The body part is 333 identified by its MIME media type ('application/ 334 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 335 the body part. The body part is assigned a unique identifier which 336 is listed in a Content-ID header field in the body part. The SIP 337 message is marked as containing the MSD by adding (or appending to) a 338 Call-Info header field at the top level of the SIP message. This 339 Call-Info header field contains a CID URL referencing the body part's 340 unique identifier, and a 'purpose' parameter identifying the data as 341 the eCall MSD per the Emergency Call Additional Data Blocks registry 342 entry; the 'purpose' parameter's value is 343 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 344 SIP INFO request by using the INFO package defined in Section 10. 346 A PSAP or IVS transmits a metadata/control object (see Section 9) by 347 encoding it per the description in this document and attaching it to 348 a SIP message as a MIME body part per [RFC7852]. The body part is 349 identified by its MIME media type ('application/ 350 emergencyCallData.control+xml') in the Content-Type header field of 351 the body part. The body part is assigned a unique identifier which 352 is listed in a Content-ID header field in the body part. The SIP 353 message is marked as containing the metadata/control object by adding 354 (or appending to) a Call-Info header field at the top level of the 355 SIP message. This Call-Info header field contains a CID URL 356 referencing the body part's unique identifier, and a 'purpose' 357 parameter identifying the data as an eCall metadata/control block per 358 the Emergency Call Additional Data Blocks registry entry; the 359 'purpose' parameter's value is 'emergencyCallData.control'. Per 360 [RFC6086], a metadata/control object is carried in a SIP INFO request 361 by using the INFO package defined in Section 10. 363 An MSD or a metadata/control block is always enclosed in a multipart 364 (normally multipart/mixed) body part (even if it would otherwise be 365 the only body part in the SIP message), since as of the date of this 366 document, the use of Content-ID as a SIP header field is not defined 367 (while it is defined for use as a MIME header field). 369 A body part containing an MSD or metadata/control object has a 370 Content-Disposition header field value containing "By-Reference". 372 An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to 373 the initial INVITE and optionally attaches a metadata/control object 374 informing the PSAP of its capabilities. The MSD body part (and 375 metadata/control and PIDF-LO body parts if included) have a Content- 376 Disposition header field with the value "By-Reference; 377 handling=optional". Specifying "handling=optional" prevents the 378 INVITE from being rejected if it is processed by a legacy element 379 (e.g., a gateway between SIP and circuit-switched environments) that 380 does not understand the MSD (or metadata/control object or PIDF-LO). 382 The PSAP creates a metadata/control object acknowledging receipt of 383 the MSD and attaches it to the SIP final response to the INVITE. A 384 metadata/control object is not attached to provisional (e.g., 180) 385 responses. 387 A PSAP is able to reject a call while indicating that it is aware of 388 the situation by including a metadata/control object acknowledging 389 the MSD and containing "received=true" in a final response using SIP 390 response code 600 (Busy Everywhere), 486 (Busy Here), or 603 391 (Decline). 393 If the IVS receives an acknowledgment for an MSD containing 394 "received=false", this indicates that the PSAP was unable to properly 395 decode or process the MSD. The IVS action is not defined (e.g., it 396 might only log an error). Since the PSAP is able to request an 397 updated MSD during the call, if an initial MSD is unsatisfactory in 398 any way, the PSAP can choose to request another one. 400 A PSAP can request that the vehicle send an updated MSD during a call 401 (e.g., upon manual request of the PSAP call taker who suspects 402 vehicle state may have changed.) To do so, the PSAP creates a 403 metadata/control object requesting an MSD and attaches it to a SIP 404 INFO request and sends it within the dialog. The IVS then attaches 405 an updated MSD to a SIP INFO request and sends it within the dialog. 406 If the IVS is unable to send an MSD, it instead sends a metadata/ 407 control object acknowledging the request with the 'success' parameter 408 set to 'false' and a 'reason' parameter (and optionally a 'details' 409 parameter) indicating why the request could not be accomplished. Per 410 [RFC6086], metadata/control objects and MSDs are sent using the INFO 411 package defined in Section 10 . In addition, to align with how an 412 MSD or metadata/control block is transmitted in a SIP message other 413 than an INFO request, a Call-Info header field is included in the SIP 414 INFO request to reference the MSD or metadata/control block. See 415 Section 10 for information about the use of INFO requests to carry 416 data within an eCall. 418 The IVS is not expected to send an unsolicited MSD after the initial 419 INVITE. 421 Support for the data blocks defined in [RFC7852] is NOT REQUIRED for 422 conformance with this document. 424 7. Call Setup 426 In circuit-switched eCall, the IVS places a special form of a 112 427 emergency call which carries an eCall flag (indicating that the call 428 is an eCall and also if the call was manually or automatically 429 triggered); the mobile network operator (MNO) recognizes the eCall 430 flag and routes the call to an eCall-capable PSAP; vehicle data is 431 transmitted to the PSAP via the eCall in-band modem (in the voice 432 channel). 434 ///----\\\ 112 voice call with eCall flag +------+ 435 ||| IVS |||---------------------------------------->+ PSAP | 436 \\\----/// vehicle data via eCall in-band modem +------+ 438 Figure 1: circuit-switched eCall 440 For NG-eCall, the IVS establishes an emergency call using a Request- 441 URI indicating a manual or automatic eCall; the MNO (or ESInet) 442 recognizes the eCall URN and routes the call to an NG-eCall capable 443 PSAP; the PSAP interpets the vehicle data sent with the call and 444 makes it available to the call taker. 446 ///----\\\ IMS emergency call with eCall URN +------+ 447 IVS ----------------------------------------->+ PSAP | 448 \\\----/// vehicle data included in call setup +------+ 450 Figure 2: NG-eCall 452 See Section 6 for information on how the MSD is transported within an 453 NG-eCall. 455 This document registers new service URN children within the "sos" 456 subservice. These URNs provide the mechanism by which an eCall is 457 identified, and differentiate between manually and automatically 458 triggered eCalls (which might be subject to different treatment, 459 depending on policy). The two service URNs are: 460 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 461 which requests resources associated with an emergency call placed by 462 an in-vehicle system, carrying a standardized set of data related to 463 the vehicle and incident. 465 Call routing is outside the scope of this document. 467 8. Test Calls 469 eCall requires the ability to place test calls (see [TS22.101] clause 470 10.7 and [EN_16062] clause 7.2.2). These are calls that are 471 recognized and treated to some extent as eCalls but are not given 472 emergency call treatment and are not handled by call takers. The 473 specific handling of test eCalls is not itself standardized; 474 typically, the test call facility allows the IVS or user to verify 475 that an eCall can be successfully established with voice 476 communication. The IVS might also be able to verify that the MSD was 477 successfully received. 479 A service URN starting with "test." indicates a test call. For 480 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 481 This functionality is defined in [RFC6881]. 483 This document registers "urn:service:test.sos.ecall" for eCall test 484 calls. 486 The CS-eCall test call facility is a non-emergency number so does not 487 get treated as an emergency call. For NG-eCall, MNOs, emergency 488 authorities, and PSAPs can determine how to treat a vehicle call 489 requesting the "test" service URN so that the desired functionality 490 is tested, but this is outside the scope of this document. 492 9. The Metadata/Control Object 494 eCall requires the ability for the PSAP to acknowledge successful 495 receipt of an MSD sent by the IVS, and for the PSAP to request that 496 the IVS send an MSD (e.g., the call taker can initiate a request for 497 a new MSD to see if there have been changes in the vehicle's state, 498 e.g., location, direction, number of fastened seatbelts). 500 This document defines a block of metadata/control data as an XML 501 structure containing elements used for eCall and other related 502 emergency call systems and extension points. (This metadata/control 503 block is in effect a high-level protocol between the PSAP and IVS.) 504 When the PSAP sends a metadata/control block in response to data sent 505 by the IVS in a SIP request other than INFO (e.g., the MSD in the 506 initial INVITE), the metadata/control block is sent in the SIP 507 response to that request (e.g., the response to the INVITE request). 508 When the PSAP sends a control block in other circumstances (e.g., 509 mid-call), the control block is transmitted from the PSAP to the IVS 510 in a SIP INFO request within the established dialog. The IVS sends 511 the requested data (the MSD) in a new INFO request (per [RFC6086]). 512 This mechanism flexibly allows the PSAP to send eCall-specific data 513 to the IVS and the IVS to respond. INFO requests are sent using an 514 appropriate INFO Package. See Section 6 for more information on 515 attaching a metadata/control block to a SIP message. See Section 10 516 for information about the use of INFO requests to carry data within 517 an eCall. 519 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 520 initial INVITE), the PSAP sends a metadata/control block indicating 521 successful/unsuccessful receipt of the MSD in the SIP response to the 522 request. This also informs the IVS that an NG-eCall is in operation. 523 If the IVS receives a SIP final response without the metadata/control 524 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 525 some part of the call is being handled as a legacy call). When the 526 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 527 receipt of a SIP INFO request containing a metadata/control block 528 requesting an MSD), the PSAP does not send a metadata/control block 529 indicating successful or unsuccessful receipt of the MSD. (Normal 530 SIP retransmission handles non-receipt of requested data; note that, 531 per [RFC6086], a 200 OK response to an INFO request indicates only 532 that the receiver has successfully received and accepted the INFO 533 request, it says nothing about the acceptability of the payload.) If 534 the IVS receives a request to send an MSD but it is unable to do so 535 for any reason, the IVS sends a metadata/control object acknowledging 536 the request and containing "success=false" and "reason" set to an 537 appropriate code. 539 This provides flexibility to handle various circumstances. For 540 example, if a PSAP is unable to accept an eCall (e.g., due to 541 overload or too many calls from the same location), it can reject the 542 INVITE. Since a metadata/control object is also included in the SIP 543 response that rejects the call, the IVS knows if the PSAP received 544 the MSD, and can inform the vehicle occupants that the PSAP 545 successfully received the vehicle location and information but can't 546 talk to the occupants at that time. Especially for SIP response 547 codes that indicate an inability to conduct a call (as opposed to a 548 technical inability to process the request), the IVS can also 549 determine that the call was successful on a technical level (e.g., 550 not helpful to retry as a CS-eCall). (Note that there could be edge 551 cases where the PSAP response is not received by the IVS, e.g., if an 552 intermediary sends a CANCEL, and an error response is forwarded 553 towards the IVS before the error response from the PSAP is received, 554 the response will be dropped, but these are unlikely to occur here.) 556 The metadata/control block is carried in the MIME type 'application/ 557 emergencyCallData.control+xml'. 559 The metadata/control block is designed for use with pan-European 560 eCall and also eCall-like systems (i.e., in other regions), and has 561 extension points. Note that eCall-like systems might define their 562 own vehicle data blocks, and so might need to register a new INFO 563 package to accomodate the new data MIME media type and the metadata/ 564 control object. 566 9.1. The Control Block 568 The control block is an XML data structure allowing for 569 acknowledgments, requests, and capabilities information. It is 570 carried in a body part with a specific MIME media type. Three 571 elements are defined for use within a control block: 573 ack Acknowledges receipt of data or a request. 575 capabilities Used in a control block sent from the IVS to the PSAP 576 (e.g., in the initial INVITE) to inform the PSAP of the 577 vehicle capabilities. Child elements contain all 578 actions and data types supported by the vehicle. It is 579 OPTIONAL for the IVS to send this block. Omitting the 580 block indicates that the IVS supports only the 581 mandatory functionality defined in this document. 583 request Used in a control block sent by the PSAP to the IVS, to 584 request the vehicle to perform an action. 586 The element indicates the object being acknowledged and reports 587 success or failure. 589 The element contains attributes to indicate the request and 590 to supply related information. The 'action' attribute is mandatory 591 and indicates the specific action. An IANA registry is created in 592 Section 15.8.1 to contain the allowed values. 594 The element has child elements to indicate 595 the actions supported by the IVS. 597 9.1.1. The element 599 The element acknowledges receipt of an eCall data object or 600 request. An element references the Content-ID of the object 601 being acknowledged. The PSAP MUST send an element 602 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 603 the INVITE); this element indicates if the PSAP considers the 604 MSD successfully received or not. An element is not sent for a 605 element. 607 The element has the following attributes: 609 9.1.1.1. Attributes of the element 611 The element has the following attributes: 613 Name: ref 614 Usage: Mandatory 615 Type: anyURI 616 Direction: Sent in either direction 617 Description: References the Content-ID of the body part being 618 acknowledged. 619 Example: 620 Name: received 621 Usage: Conditional: mandatory in an element sent by a PSAP 622 Type: Boolean 623 Direction: In this document, sent from the PSAP to the IVS 624 Description: Indicates if the referenced object was considered 625 successfully received or not. 626 Example: 628 9.1.1.2. Child Element of the element 630 For extensibility, the element has the following child element: 632 Name: actionResult 633 Usage: Optional 634 Direction: Sent from the IVS to the PSAP 635 Description: An element indicates the result of an 636 action (other than a successfully executed 'send-data' action). 637 The element contains an element for each 638 element that is not a successfully executed 'send-data' 639 action. The element has the following attributes: 641 Name: action 642 Usage: Mandatory 643 Type: token 644 Description: Contains the value of the 'action' attribute of the 645 element 647 Name: success 648 Usage: Mandatory 649 Type: Boolean 650 Description: Indicates if the action was successfully 651 accomplished 653 Name: reason 654 Usage: Conditional 655 Type: token 656 Description: Used when 'success' is "false", this attribute 657 contains a reason code for a failure. A registry for reason 658 codes is defined in Section 15.8.2. 660 Name: details 661 Usage: optional 662 Type: string 663 Description: Contains further explanation of the circumstances of 664 a success or failure. The contents are implementation-specific 665 and human-readable. 667 9.1.1.3. Ack Examples 669 670 674 676 678 Figure 3: Ack Example from PSAP to IVS 680 9.1.2. The element 682 The element is transmitted by the IVS to indicate to 683 the PSAP its capabilities. No attributes for this element are 684 currently defined. The following child elements are defined: 686 9.1.2.1. Child Elements of the element 688 The element has the following child elements: 690 Name: request 691 Usage: Mandatory 692 Description: The element contains a child 693 element per action supported by the vehicle. 695 Examples: 696 698 It is OPTIONAL for the IVS to support the element. If 699 the IVS does not send a element, this indicates that 700 the only action supported by the IVS is 'send-data' with 701 'datatype' set to 'eCall.MSD'. 703 9.1.2.2. Capabilities Example 704 705 709 710 711 713 715 Figure 4: Capabilities Example 717 9.1.3. The element 719 A element appears one or more times on its own or as a 720 child of a element. It allows the PSAP to request 721 that the IVS perform an action. The only action that MUST be 722 supported is to send an MSD. The following attributes and child 723 elements are defined: 725 9.1.3.1. Attributes of the element 727 The element has the following attributes: 729 Name: action 730 Usage: Mandatory 731 Type: token 732 Direction: Sent in either direction 733 Description: Identifies the action that the vehicle is requested to 734 perform (in a element within a element, 735 indicates an action that the vehicle is capable of performing). 736 An IANA registry is established in Section 15.8.1 to contain the 737 allowed values. 738 Example: action="send-data" 740 Name: msgid 741 Usage: Conditional 742 Type: int 743 Direction: Sent in either direction 744 Description: Defined for extensibility. 745 Example: msgid="3" 747 Name: persistance 748 Usage: Optional 749 Type: duration 750 Direction: Sent in either direction 751 Description: Defined for extensibility. Specifies how long to carry 752 on the specified action. If absent, the default is for the 753 duration of the call. 754 Example: persistance="PT1H" 756 Name: datatype 757 Usage: Conditional 758 Type: token 759 Direction: Sent in either direction 760 Description: Mandatory with a "send-data" action within a 761 element that is not within a element. Specifies 762 the data block that the IVS is requested to transmit, using the 763 same identifier as in the 'purpose' attribute set in a Call-Info 764 header field to point to the data block. Permitted values are 765 contained in the 'Emergency Call Data Types' IANA registry 766 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 767 to support. 768 Example: datatype="eCall.MSD" 770 Name: supported-values 771 Usage: Conditional 772 Type: string 773 Direction: Sent from the IVS to the PSAP 774 Description: Defined for extensibility. Used in a element 775 that is a child of a element, this attribute lists 776 all supported values of the action type. Permitted values depend 777 on the action value. Multiple values are separated with a 778 semicolon. 780 Name: requested-state 781 Usage: Conditional 782 Type: token 783 Direction: Sent from the PSAP to the IVS 784 Description: Defined for extension. Indicates the requested state 785 of an element associated with the request type. Permitted values 786 depend on the request type. 788 Name: element-ID 789 Usage: Conditional 790 Type: token 791 Direction: Sent from the PSAP to the IVS 792 Description: Defined for extension. Identifies the element to be 793 acted on. Permitted values depend on the request type. 795 9.1.3.2. Request Example 797 798 802 804 806 Figure 5: Request Example 808 10. The emergencyCallData.eCall.MSD INFO package 810 This document registers the 'emergencyCallData.eCall.MSD' INFO 811 package. 813 Both endpoints (the IVS and the PSAP equipment) include 814 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 815 [RFC6086] to indicate ability to receive INFO requests carrying data 816 as described here. 818 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 819 the ability to receive eCall related body parts as specified in [TBD: 820 THIS DOCUMENT]. 822 An INFO request message carrying body parts related to an emergency 823 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 824 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 826 The requirements of Section 10 of [RFC6086] are addressed in the 827 following sections. 829 10.1. Overall Description 831 This section describes "what type of information is carried in INFO 832 requests associated with the Info Package, and for what types of 833 applications and functionalities UAs can use the Info Package." 835 INFO requests associated with the emergencyCallData.eCall.MSD INFO 836 package carry data associated with emergency calls as defined in 837 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 838 calls established using SIP. The functionality is to carry vehicle 839 data and metadata/control information between vehicles and PSAPs. 840 Refer to [TBD: THIS DOCUMENT] for more information. 842 10.2. Applicability 844 This section describes "why the Info Package mechanism, rather than 845 some other mechanism, has been chosen for the specific use-case...." 847 The use of INFO is based on an analysis of the requirements against 848 the intent and effects of INFO versus other approaches (which 849 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 850 transport, and non-SIP protocols). In particular, the transport of 851 emergency call data blocks occurs within a SIP emergency dialog, per 852 Section 6, and is normally carried in the initial INVITE and its 853 response; the use of INFO only occurs when emergency-call-related 854 data needs to be sent mid-call. While MESSAGE could be used, it is 855 not tied to a SIP dialog as is INFO and thus might not be associated 856 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 857 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 858 service, but the semantics are not a good fit, e.g., the subscribe/ 859 notify mechanism provides one-way communication consisting of (often 860 multiple) notifications from notifier to subscriber indicating that 861 certain events in notifier have occurred, whereas what's needed here 862 is two-way communication of data related to the emergency dialog. 863 Use of the media plane mechanisms was discounted because the number 864 of messages needing to be exchanged in a dialog is normally zero or 865 very few, and the size of the data is likewise very small. The 866 overhead caused by user plane setup (e.g., to use MSRP as transport) 867 would be disproportionately large. 869 Based on the the analyses, the SIP INFO method was chosen to provide 870 for mid-call data transport. 872 10.3. Info Package Name 874 The info package name is emergencyCallData.eCall.MSD 876 10.4. Info Package Parameters 878 None 880 10.5. SIP Option-Tags 882 None 884 10.6. INFO Request Body Parts 886 The body for an emergencyCallData.eCall.MSD info package is a 887 multipart (normally multipart/mixed) body containing zero or one 888 application/emergencyCallData.eCall.MSD+per part (containing an MSD) 889 and zero or more application/emergencyCallData.control+xml 890 (containing a metadata/control object) parts. At least one MSD or 891 metadata/control body part is expected; the behavior upon receiving 892 an INFO request with neither is undefined. 894 The body parts are sent per [RFC6086], and in addition, to align with 895 with how these body parts are sent in SIP messages other than INFO 896 requests, each associated body part is referenced by a Call-Info 897 header field at the top level of the SIP message. The body part has 898 a Content-Disposition header field set to "By-Reference". 900 An MSD or metadata/control block is always enclosed in a multipart 901 body part (even if it would otherwise be the only body part in the 902 SIP message), since as of the date of this document, the use of 903 Content-ID as a SIP header field is not defined (while it is defined 904 for use as a MIME header field). The innermost multipart that 905 contains only body parts associated with the INFO package has a 906 Content-Disposition value of Info-Package. 908 See [TBD: THIS DOCUMENT] for more information. 910 10.7. Info Package Usage Restrictions 912 Usage is limited to vehicle-initiated emergency calls as defined in 913 [TBD: THIS DOCUMENT]. 915 10.8. Rate of INFO Requests 917 The SIP INFO request is used within an established emergency call 918 dialog for the PSAP to request the IVS to send an updated MSD, and 919 for the IVS to send a requested MSD. Because this is normally done 920 only on manual request of the PSAP call taker (who suspects some 921 aspect of the vehicle state has changed), the rate of SIP INFO 922 requests associated with the emergencyCallData.eCall.MSD info package 923 is normally quite low (most dialogs are likely to contain zero INFO 924 requests, while others might carry an occasional request). 926 10.9. Info Package Security Considerations 928 The MIME media type registations for the data blocks that can be 929 carried using this INFO package contains a discussion of the security 930 and/or privacy considerations specific to that data block. The 931 "Security Considerations" and "Privacy Considerations" sections of 932 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 933 the data carried in eCalls. 935 10.10. Implementation Details 937 See [TBD: THIS DOCUMENT] for protocol details. 939 10.11. Examples 941 See [TBD: THIS DOCUMENT] for protocol examples. 943 11. Examples 945 Figure 6 illustrates an eCall. The call uses the request URI 946 'urn:service:sos.ecall.automatic' service URN and is recognized as an 947 eCall, and further as one that was invoked automatically by the IVS 948 due to a crash or other serious incident. In this example, the 949 originating network routes the call to an ESInet which routes the 950 call to the appropriate NG-eCall capable PSAP. The emergency call is 951 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 952 the entry point into the ESInet. The ESRP routes the call to a PSAP, 953 where it is received by a call taker. In deployments where there is 954 no ESInet, the originating network routes the call directly to the 955 appropriate NG-eCall capable PSAP, an illustration of which would be 956 identical to the one below except without an ESInet or ESRP. 958 +------------+ +---------------------------------------+ 959 | | | +-------+ | 960 | | | | PSAP2 | | 961 | | | +-------+ | 962 | | | | 963 | | | +------+ +-------+ | 964 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 965 | | | +------+ +-------+ | 966 | | | | 967 | | | +-------+ | 968 | | | | PSAP3 | | 969 | Originating| | +-------+ | 970 | Mobile | | | 971 | Network | | ESInet | 972 +------------+ +---------------------------------------+ 974 Figure 6: Example of NG-eCall Message Flow 976 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 977 for an updated MSD. The call flow shows the IVS initiating an 978 emergency call, including the MSD in the INVITE. The PSAP includes 979 in the 200 OK response a metadata/control object acknowledging 980 receipt of the MSD. During the call, the PSAP sends a request for an 981 MSD in an INFO request. The IVS sends the requested MSD in a new 982 INFO request. 984 IVS PSAP 985 |(1) INVITE (eCall MSD) | 986 |------------------------------------------->| 987 | | 988 |(2) 200 OK (eCall metadata [ack MSD]) | 989 |<-------------------------------------------| 990 | | 991 |(3) start media stream(s) | 992 |............................................| 993 | | 994 |(4) INFO (eCall metadata [request MSD]) | 995 |<-------------------------------------------| 996 | | 997 |(5) 200 OK | 998 |------------------------------------------->| 999 | | 1000 |(6) INFO (eCall MSD) | 1001 |------------------------------------------->| 1002 | | 1003 |(7) 200 OK | 1004 |<-------------------------------------------| 1005 | | 1006 |(8) BYE | 1007 |<-------------------------------------------| 1008 | | 1009 |(9) end media streams | 1010 |............................................| 1011 | | 1012 |(10) 200 OK | 1013 |------------------------------------------->| 1015 Figure 7: NG-eCall Call Flow Illustration 1017 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 1018 contains an MSD. For simplicity, the example does not show all SIP 1019 headers, nor the SDP contents, nor does it show any additional data 1020 blocks added by the IVS or the originating mobile network. Because 1021 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 1022 contents cannot be included in a text document. 1024 INVITE urn:service:sos.ecall.automatic SIP/2.0 1025 To: urn:service:sos.ecall.automatic 1026 From: ;tag=9fxced76sl 1027 Call-ID: 3848276298220188511@atlanta.example.com 1028 Geolocation: 1029 Geolocation-Routing: no 1030 Call-Info: ; 1031 purpose=emergencyCallData.eCall.MSD 1032 Accept: application/sdp, application/pidf+xml, 1033 application/emergencyCallData.control+xml 1034 CSeq: 31862 INVITE 1035 Recv-Info: emergencyCallData.eCall.MSD 1036 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1037 SUBSCRIBE, NOTIFY, UPDATE 1038 Content-Type: multipart/mixed; boundary=boundary1 1039 Content-Length: ... 1041 --boundary1 1042 Content-Type: application/sdp 1044 ...Session Description Protocol (SDP) goes here... 1046 --boundary1 1047 Content-Type: application/pidf+xml 1048 Content-ID: 1049 Content-Disposition: by-reference;handling=optional 1051 ...PIDF-LO goes in here 1053 --boundary1 1054 Content-Type: application/emergencyCallData.eCall.MSD+per 1055 Content-ID: <1234567890@atlanta.example.com> 1056 Content-Disposition: by-reference;handling=optional 1058 ...MSD in ASN.1 PER encoding goes here... 1060 --boundary1-- 1062 Figure 8: SIP NG-eCall INVITE 1064 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1065 the INVITE of Figure 8, containing a control block acknowledging 1066 successful receipt of the eCall MSD. (For simplicity, the example 1067 does not show all SIP headers.) 1068 SIP/2.0 200 OK 1069 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1070 From: ;tag=9fxced76sl 1071 Call-ID: 3848276298220188511@atlanta.example.com 1072 Call-Info: ; 1073 purpose=emergencyCallData.control 1074 Accept: application/sdp, application/pidf+xml, 1075 application/emergencyCallData.control+xml, 1076 application/emergencyCallData.eCall.MSD+per 1077 CSeq: 31862 INVITE 1078 Recv-Info: emergencyCallData.eCall.MSD 1079 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1080 SUBSCRIBE, NOTIFY, UPDATE 1081 Content-Type: multipart/mixed; boundary=boundaryX 1082 Content-Length: ... 1084 --boundaryX 1085 Content-Type: application/sdp 1087 ...Session Description Protocol (SDP) goes here... 1089 --boundaryX 1090 Content-Type: application/emergencyCallData.control+xml 1091 Content-ID: <2345678901@atlanta.example.com> 1092 Content-Disposition: by-reference 1094 1095 1099 1100 1102 --boundaryX-- 1104 Figure 9: 200 OK response to INVITE 1106 Figure 10 illustrates a SIP INFO request containing a metadata/ 1107 control block requesting an eCall MSD. (For simplicity, the example 1108 does not show all SIP headers.) 1109 INFO sip:+13145551111@example.com SIP/2.0 1110 To: ;tag=9fxced76sl 1111 From: Exemplar PSAP ;tag=8gydfe65t0 1112 Call-ID: 3848276298220188511@atlanta.example.com 1113 Call-Info: ; 1114 purpose=emergencyCallData.control 1115 CSeq: 41862 INFO 1116 Info-Package: emergencyCallData.eCall.MSD 1117 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1118 SUBSCRIBE, NOTIFY, UPDATE 1119 Content-Type: multipart/mixed; boundary=boundaryZZZ 1120 Content-Dispositio: Info-Package 1121 Content-Length: ... 1123 --boundaryZZZ 1124 Content-Disposition: by-reference 1125 Content-Type: application/emergencyCallData.control+xml 1126 Content-ID: <3456789012@atlanta.example.com> 1128 1129 1133 1135 1136 --boundaryZZZ-- 1138 Figure 10: INFO requesting MSD 1140 Figure 11 illustrates a SIP INFO request containing an MSD. For 1141 simplicity, the example does not show all SIP headers. Because the 1142 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1143 cannot be included in a text document. 1145 INFO urn:service:sos.ecall.automatic SIP/2.0 1146 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 1147 From: ;tag=9fxced76sl 1148 Call-ID: 3848276298220188511@atlanta.example.com 1149 Call-Info: ; 1150 purpose=emergencyCallData.eCall.MSD 1151 CSeq: 51862 INFO 1152 Info-Package: emergencyCallData.eCall.MSD 1153 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1154 SUBSCRIBE, NOTIFY, UPDATE 1155 Content-Type: multipart/mixed; boundary=boundaryLine 1156 Content-Disposition: Info-Package 1157 Content-Length: ... 1159 --boundaryLine 1160 Content-Type: application/emergencyCallData.eCall.MSD+per 1161 Content-ID: <4567890123@atlanta.example.com> 1162 Content-Disposition: by-reference 1164 ...MSD in ASN.1 PER encoding goes here... 1166 --boundaryLine-- 1168 Figure 11: INFO containing MSD 1170 12. Security Considerations 1172 The security considerations described in [RFC5069] apply here. 1174 In addition to any network-provided location (which might be 1175 determined solely by the network, or in cooperation with or possibly 1176 entirely by the originating device), an eCall carries an IVS-supplied 1177 location within the MSD. This is likely to be useful to the PSAP, 1178 especially when no network-provided location is included, or when the 1179 two locations are independently determined. Even in situations where 1180 the network-supplied location is limited to the cell site, this can 1181 be useful as a sanity check on the device-supplied location contained 1182 in the MSD. 1184 The document [RFC7378] discusses trust issues regarding location 1185 provided by or determined in cooperation with end devices. 1187 Security considerations specific to the mechanism by which the PSAP 1188 sends acknowledgments and requests to the vehicle are discussed in 1189 the "Security Considerations" block of Section 15.3. Note that an 1190 attacker that has access to and is capable of generating a response 1191 to the initial INVITE request could generate a 600 (Busy Everywhere), 1192 486 (Busy Here), or 603 (Decline) response that includes a metadata/ 1193 control object containing a reference to the MSD in the initial 1194 INVITE and a "received=true" field, which could result in the IVS 1195 perceiving the PSAP to be overloaded and hence not attempting to 1196 reinitiate the call. The risk can be mitigated as discussed in the 1197 "Security Considerations" block of Section 15.3. 1199 Data received from external sources inherently carries implementation 1200 risks. For example, depending on the platform, buffer overflows can 1201 introduce remote code execution vulnerabilities, null characters can 1202 corrupt strings, numeric values used for internal calculations can 1203 result in underflow/overflow errors, malformed XML objects can expose 1204 parsing bugs, etc. Implementations need to be cognizant of the 1205 potential risks, observe best practices (which might include 1206 sufficiently capable static code analysis, fuzz testing, component 1207 isolation, avoiding use of unsafe coding techniques, third-party 1208 attack tests, signed software, over-the-air updates, etc.), and have 1209 multiple levels of protection. Implementors need to be aware that, 1210 potentially, the data objects described here and elsewhere might be 1211 malformed, might contain unexpected characters, excessively long 1212 attribute values, elements, etc. 1214 The security considerations discussed in [RFC7852] apply here (see 1215 especially the discussion of TLS, TLS versions, cypher suites, and 1216 PKI). 1218 When vehicle data or control/metadata is contained in a signed or 1219 encrypted body part, the enclosing multipart (e.g., multipart/signed 1220 or multipart/encrypted) has the same Content-ID as the enclosed data 1221 part. This allows an entity to identify and access the data blocks 1222 it is interested in without having to dive deeply into the message 1223 structure or decrypt parts it is not interested in. (The 'purpose' 1224 parameter in a Call-Info header field identifies the data and 1225 contains a CID URL pointing to the data block in the body, which has 1226 a matching Content-ID body part header field). 1228 13. Privacy Considerations 1230 The privacy considerations discussed in [RFC7852] apply here. The 1231 MSD carries some identifying and personal information (mostly about 1232 the vehicle and less about the owner), as well as location 1233 information, and so needs to be protected against unauthorized 1234 disclosure. Local regulations may impose additional privacy 1235 protection requirements. 1237 Privacy considerations specific to the data structure containing 1238 vehicle information are discussed in the "Security Considerations" 1239 block of Section 15.2. 1241 Privacy considerations specific to the mechanism by which the PSAP 1242 sends acknowledgments and requests to the vehicle are discussed in 1243 the "Security Considerations" block of Section 15.3. 1245 14. XML Schema 1247 This section defines an XML schema for the control block. The text 1248 description of the control block in Section 9.1 is normative and 1249 supersedes any conflicting aspect of this schema. 1251 1252 1254 1262 1264 1267 1268 1269 1270 1271 1273 1274 1275 1278 1279 1280 1281 1282 1284 1285 1286 1287 1288 1290 1291 1294 1297 1299 1300 conditionally 1301 mandatory when @success='false" 1302 to indicate reason code for a 1303 failure 1304 1305 1306 1308 1309 1310 1311 1314 1315 1318 1320 1321 1322 1323 1325 1326 1327 1328 1329 1333 1337 1338 1339 1340 1341 1343 1344 1345 1346 1347 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1363 1365 Figure 12: Control Block Schema 1367 15. IANA Considerations 1369 This document formalizes the "EmergencyCallData" media (MIME) subtype 1370 tree. This tree is used only for content associated with emergency 1371 communications. New subtypes in this tree can be registered by the 1372 IETF or by other standards organizations working with emergency 1373 communications, using the "Specification Required" rule, which 1374 implies expert review. The designated expert is the ECRIT working 1375 group. 1377 15.1. Service URN Registrations 1379 IANA is requested to register the URN 'urn:service:sos.ecall' under 1380 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1382 This service requests resources associated with an emergency call 1383 placed by an in-vehicle system, carrying a standardized set of data 1384 related to the vehicle and incident. Two sub-services are registered 1385 as well: 1387 urn:service:sos.ecall.manual 1389 Used with an eCall invoked due to manual interaction by a vehicle 1390 occupant. 1392 urn:service:sos.ecall.automatic 1394 Used with an eCall invoked automatically, for example, due to a 1395 crash or other serious incident. 1397 IANA is also requested to register the URN 1398 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1399 defined in Setcion 17.2 of [RFC6881]. 1401 15.2. MIME Media Type Registration for 'application/ 1402 emergencyCallData.eCall.MSD+per' 1404 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1405 as a MIME media type, with a reference to this document, in 1406 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1407 RFC 7303 [RFC7303]. 1409 MIME media type name: application 1411 MIME subtype name: emergencyCallData.eCall.MSD+per 1413 Mandatory parameters: none 1415 Optional parameters: none 1417 Encoding scheme: binary 1419 Encoding considerations: Uses ASN.1 PER, which is a binary 1420 encoding; when transported in SIP, binary content transfer 1421 encoding is used. 1423 Security considerations: This media type is designed to carry 1424 vehicle and incident-related data during an emergency call. This 1425 data contains personal information including vehicle VIN, 1426 location, direction, etc. Appropriate precautions need to be 1427 taken to limit unauthorized access, inappropriate disclosure to 1428 third parties, and eavesdropping of this information. In general, 1429 it is acceptable for the data to be unprotected while briefly in 1430 transit within the Mobile Network Operator (MNO); the MNO is 1431 trusted to not permit the data to be accessed by third parties. 1432 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1434 Interoperability considerations: None 1436 Published specification: Annex A of EN 15722 [msd] 1438 Applications which use this media type: Pan-European eCall 1439 compliant systems 1441 Additional information: None 1443 Magic Number: None 1445 File Extension: None 1447 Macintosh file type code: 'BINA' 1449 Person and email address for further information: Randall Gellens, 1450 rg+ietf@randy.pensive.org 1452 Intended usage: LIMITED USE 1454 Author: The MSD specification was produced by the European 1455 Committee For Standardization (CEN). For contact information, 1456 please see . 1458 Change controller: The European Committee For Standardization 1459 (CEN) 1461 15.3. MIME Media Type Registration for 'application/ 1462 emergencyCallData.control+xml' 1464 IANA is requested to add application/emergencyCallData.control+xml as 1465 a MIME media type, with a reference to this document, in accordance 1466 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1467 [RFC7303]. 1469 MIME media type name: application 1471 MIME subtype name: emergencyCallData.control+xml 1473 Mandatory parameters: none 1475 Optional parameters: charset 1477 Indicates the character encoding of the XML content. 1479 Encoding considerations: Uses XML, which can employ 8-bit 1480 characters, depending on the character encoding used. See 1481 Section 3.2 of RFC 7303 [RFC7303]. 1483 Security considerations: 1485 This media type carries metadata and control information and 1486 requests, such as from a Public Safety Answering Point (PSAP) 1487 to an In-Vehicle System (IVS) during an emergency call. 1489 Metadata (such as an acknowledgment that data sent by the IVS 1490 to the PSAP was successfully received) has limited privacy and 1491 security implications. Control information (such as requests 1492 from the PSAP that the vehicle perform an action) has some 1493 privacy and security implications. The privacy concern arises 1494 from the ability to request the vehicle to transmit a data set, 1495 which as described in Section 15.2, can contain personal 1496 information. The security concern is the ability to request 1497 the vehicle to perform an action. Control information needs to 1498 originate only from a PSAP or other emergency services 1499 provider, and not be modified en-route. The level of integrity 1500 of the cellular network over which the emergency call is placed 1501 is a consideration: when the IVS initiates an eCall over a 1502 cellular network, in most cases it relies on the MNO to route 1503 the call to a PSAP. (Calls placed using other means, such as 1504 Wi-Fi or over-the-top services, generally incur somewhat higher 1505 levels of risk than calls placed "natively" using cellular 1506 networks.) A call-back from a PSAP merits additional 1507 consideration, since current mechanisms are not ideal for 1508 verifying that such a call is indeed a call-back from a PSAP in 1509 response to an emergency call placed by the IVS. See the 1510 discussion in Section 12 and the PSAP Callback document 1511 [RFC7090]. 1513 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1515 Interoperability considerations: None 1517 Published specification: This document 1519 Applications which use this media type: Pan-European eCall 1520 compliant systems 1522 Additional information: None 1524 Magic Number: None 1526 File Extension: .xml 1527 Macintosh file type code: 'TEXT' 1529 Person and email address for further information: Randall Gellens, 1530 rg+ietf@randy.pensive.org 1532 Intended usage: LIMITED USE 1534 Author: The IETF ECRIT WG. 1536 Change controller: The IETF ECRIT WG. 1538 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1539 Additional Data Blocks registry 1541 This specification requests IANA to add the 'eCall.MSD' entry to the 1542 Emergency Call Additional Data Blocks registry, with a reference to 1543 this document. 1545 15.5. Registration of the 'control' entry in the Emergency Call 1546 Additional Data Blocks registry 1548 This specification requests IANA to add the 'control' entry to the 1549 Emergency Call Additional Data Blocks registry, with a reference to 1550 this document. 1552 15.6. Registration of the emergencyCallData.eCall Info Package 1554 IANA is requested to add emergencyCallData.eCall to the Info Packages 1555 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1556 reference to this document. 1558 15.7. URN Sub-Namespace Registration 1560 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1562 This section registers a new XML namespace, as per the guidelines in 1563 RFC 3688 [RFC3688]. 1565 URI: urn:ietf:params:xml:ns:eCall 1567 Registrant Contact: IETF, ECRIT working group, , as 1568 delegated by the IESG . 1570 XML: 1572 BEGIN 1573 1574 1576 1577 1578 1580 Namespace for eCall Data 1581 1582 1583

Namespace for eCall Data

1584

See [TBD: This document].

1585 1586 1587 END 1589 15.7.2. Registration for urn:ietf:params:xml:ns:control 1591 This section registers a new XML namespace, as per the guidelines in 1592 RFC 3688 [RFC3688]. 1594 URI: urn:ietf:params:xml:ns:control 1596 Registrant Contact: IETF, ECRIT working group, , as 1597 delegated by the IESG . 1599 XML: 1601 BEGIN 1602 1603 1605 1606 1607 1609 Namespace for eCall Data: 1610 Control Block 1611 1612 1613

Namespace for eCall Data

1614

Control Block

1615

See [TBD: This document].

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