idnits 2.17.1 draft-ietf-ecrit-ecall-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (October 16, 2016) is 2748 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-12 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 19, 2017 Individual 6 October 16, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-17.txt 11 Abstract 13 This document describes how to use IP-based emergency services 14 mechanisms to support the next generation of the pan European in- 15 vehicle emergency call service defined under the eSafety initiative 16 of the European Commission (generally referred to as "eCall"). eCall 17 is a standardized and mandated system for a special form of emergency 18 calls placed by vehicles, providing real-time communications and an 19 integrated set of related data. 21 This document also registers MIME Content Types and an Emergency Call 22 Additional Data 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 19, 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 . . . . . . . . . . . . . . . . 20 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 Content-type Registration for 99 'application/emergencyCallData.eCall.MSD+per' . . . . . 31 100 15.3. MIME Content-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-16 to draft-ietf-17 . . . . . . 38 117 18.2. Changes from draft-ietf-15 to draft-ietf-16 . . . . . . 38 118 18.3. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 119 18.4. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 120 18.5. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 38 121 18.6. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 39 122 18.7. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39 123 18.8. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 124 18.9. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 125 18.10. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40 126 18.11. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40 127 18.12. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40 128 18.13. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40 129 18.14. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41 130 18.15. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41 131 18.16. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41 132 18.17. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41 133 18.18. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42 134 18.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42 135 18.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42 136 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 137 19.1. Normative References . . . . . . . . . . . . . . . . . . 42 138 19.2. Informative references . . . . . . . . . . . . . . . . . 43 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 141 1. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 This document re-uses terminology defined in Section 3 of [RFC5012]. 149 Additionally, we use the following abbreviations: 151 +--------+----------------------------------------+ 152 | Term | Expansion | 153 +--------+----------------------------------------+ 154 | 3GPP | 3rd Generation Partnership Project | 155 | | | 156 | CEN | European Committee for Standardization | 157 | | | 158 | EENA | European Emergency Number Association | 159 | | | 160 | ESInet | Emergency Services IP network | 161 | | | 162 | IMS | IP Multimedia Subsystem | 163 | | | 164 | IVS | In-Vehicle System | 165 | | | 166 | MNO | Mobile Network Operator | 167 | | | 168 | MSD | Minimum Set of Data | 169 | | | 170 | PSAP | Public Safety Answering Point | 171 +--------+----------------------------------------+ 173 2. Document Scope 175 This document is focused on the signaling, data exchange, and 176 protocol needs of next-generation eCall (NG-eCall, also referred to 177 as packet-switched eCall or all-IP eCall) within the SIP framework 178 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 179 itself is specified by 3GPP (3rd Generation Partnership Project) and 180 CEN (European Committee for Standardization) and these specifications 181 include far greater scope than is covered here. 183 The eCall service operates over cellular wireless communication, but 184 this document does not address cellular-specific details, nor client 185 domain selection (e.g., circuit-switched versus packet-switched). 186 All such aspects are the purview of their respective standards 187 bodies. The scope of this document is limited to eCall operating 188 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling 189 [TS23.167]). 191 The technical contents of this document also provide a basis for 192 reuse and extension for related emergency call systems (which is why 193 there are extension points), but such reuse is a topic for other 194 documents. 196 Note that vehicles designed for multiple regions might need to 197 support eCall and other Advanced Automatic Crash Notification (AACN) 198 systems (such as described in [I-D.ietf-ecrit-car-crash]), but this 199 is out of scope of this document. 201 3. Introduction 203 Emergency calls made from vehicles (e.g., in the event of a crash) 204 assist in significantly reducing road deaths and injuries by allowing 205 emergency services to be aware of the incident, the state of the 206 vehicle, the location of the vehicle, and to have a voice channel 207 with the vehicle occupants. This enables a quick and appropriate 208 response. 210 The European Commission initiative of eCall was conceived in the late 211 1990s, and has evolved to a European Parliament decision requiring 212 the implementation of a compliant in-vehicle system (IVS) in new 213 vehicles and the deployment of eCall in the European Member States in 214 the very near future. Other regions are developing eCall-compatible 215 systems. 217 The pan-European eCall system provides a standardized and mandated 218 mechanism for emergency calls by vehicles. eCall establishes 219 procedures for such calls to be placed by in-vehicle systems, 220 recognized and processed by the mobile network, and routed to a 221 specialized PSAP where the vehicle data is available to assist the 222 call taker in assessing and responding to the situation. eCall 223 provides a standard set of vehicle, sensor (e.g., crash related), and 224 location data. 226 An eCall can be either user-initiated or automatically triggered. 227 Automatically triggered eCalls indicate a car crash or some other 228 serious incident. Manually triggered eCalls might be reports of 229 witnessed crashes or serious hazards. PSAPs might apply specific 230 operational handling to manual and automatic eCalls. 232 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 233 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 234 call setup mark the call as an eCall, and further indicate if the 235 call was automatically or manually triggered. The call is routed to 236 an eCall-capable PSAP, a voice channel is established between the 237 vehicle and the PSAP, and an eCall in-band modem is used to carry a 238 defined set of vehicle, sensor (e.g., crash related), and location 239 data (the Minimum Set of Data or MSD) within the voice channel. The 240 same in-band mechanism is used for the PSAP to acknowledge successful 241 receipt of the MSD, and to request the vehicle to send a new MSD 242 (e.g., to check if the state of or location of the vehicle or its 243 occupants has changed). NG-eCall moves from circuit switched to all- 244 IP, and carries the vehicle data and eCall signaling as additional 245 data carried with the call. This document describes how IETF 246 mechanisms for IP-based emergency calls, including [RFC6443] and 247 [RFC7852] are used to provide the signaling and data exchange of the 248 next generation of pan-European eCall. 250 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 251 has published a Technical Report titled "Mobile Standards Group 252 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 253 recommendations regarding support for eCall in an all-IP environment. 254 The recommendations include the use of 3GPP IMS emergency calling 255 with additional elements identifying the call as an eCall and as 256 carrying eCall data and with mechanisms for carrying the data and 257 eCall signaling. 3GPP IMS emergency services support multimedia, 258 providing the ability to carry voice, text, and video. This 259 capability is referred to within 3GPP as Multimedia Emergency 260 Services (MMES). 262 A transition period will exist during which time the various entities 263 involved in initiating and handling an eCall might support next- 264 generation eCall, legacy eCall, or both. The issues of migration and 265 co-existence during the transition period are outside the scope of 266 this document. 268 This document indicates how to use IP-based emergency services 269 mechanisms to support next-generation eCall. 271 This document also registers MIME Content Types and an Emergency Call 272 Additional Data Block for the eCall vehicle data (MSD) and metadata/ 273 control data, and an INFO package to enable carrying this data in 274 INFO requests. 276 The MSD is carried in the MIME type 'application/ 277 emergencyCallData.eCall.MSD+per' and the metadata/control block is 278 carried in the MIME type 'application/emergencyCallData.control+xml' 279 (both of which are registered in Section 15) An INFO package is 280 defined (in Section 10) to enable these MIME types to be carried in 281 SIP INFO requests, per [RFC6086]. 283 4. eCall Requirements 285 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 286 [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle 287 data are contained in EN 15722 [msd]. 289 5. Vehicle Data 291 Pan-European eCall provides a standardized and mandated set of 292 vehicle related data, known as the Minimum Set of Data (MSD). The 293 European Committee for Standardization (CEN) has specified this data 294 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 295 circuit-switched eCall and this document use the ASN.1 PER encoding, 296 which is specified in Annex A of EN 15722 [msd] (the XML encoding 297 specified in Annex C is not used in this document). 299 This document registers the 'application/ 300 emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD 301 to be carried in SIP. As an ASN.1 PER encoded object, the data is 302 binary and transported using binary content transfer encoding within 303 SIP messages. This document also adds the 'eCall.MSD' entry to the 304 Emergency Call Additional Data Blocks registry to enable the MSD to 305 be recognized as such in a SIP-based eCall emergency call. (See 306 [RFC7852] for more information about the registry and how it is 307 used.) 309 See Section 6 for a discussion of how the MSD vehicle data is 310 conveyed in an NG-eCall. 312 6. Data Transport 314 [RFC7852] establishes a general mechanism for attaching blocks of 315 data to a SIP emergency call. This mechanism permits certain 316 emergency call MIME types to be attached to SIP messages. This 317 document makes use of that mechanism. This document also registers 318 an INFO package (in Section 10) to enable eCall related data blocks 319 to be carried in SIP INFO requests (per [RFC6086], new INFO usages 320 require the definition of an INFO package). 322 Note that if other data sets need to be transmitted in the future, 323 the appropriate signalling mechanism for such data needs to be 324 evaluated, including factors such as the size and frequency of such 325 data. 327 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 328 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 329 message as a MIME body part per [RFC7852]. The body part is 330 identified by its MIME content-type ('application/ 331 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 332 the body part. The body part is assigned a unique identifier which 333 is listed in a Content-ID header field in the body part. The SIP 334 message is marked as containing the MSD by adding (or appending to) a 335 Call-Info header field at the top level of the SIP message. This 336 Call-Info header field contains a CID URL referencing the body part's 337 unique identifier, and a 'purpose' parameter identifying the data as 338 the eCall MSD per the Emergency Call Additional Data Blocks registry 339 entry; the 'purpose' parameter's value is 340 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 341 SIP INFO request by using the INFO package defined in Section 10. 343 A PSAP or IVS transmits a metadata/control object (see Section 9) by 344 encoding it per the description in this document and attaching it to 345 a SIP message as a MIME body part per [RFC7852]. The body part is 346 identified by its MIME content-type ('application/ 347 emergencyCallData.control+xml') in the Content-Type header field of 348 the body part. The body part is assigned a unique identifier which 349 is listed in a Content-ID header field in the body part. The SIP 350 message is marked as containing the metadata/control object by adding 351 (or appending to) a Call-Info header field at the top level of the 352 SIP message. This Call-Info header field contains a CID URL 353 referencing the body part's unique identifier, and a 'purpose' 354 parameter identifying the data as an eCall metadata/control block per 355 the Emergency Call Additional Data Blocks registry entry; the 356 'purpose' parameter's value is 'emergencyCallData.control'. Per 357 [RFC6086], a metadata/control object is carried in a SIP INFO request 358 by using the INFO package defined in Section 10. 360 An MSD or a metadata/control block is always enclosed in a multipart 361 body part (even if it would otherwise be the only body part in the 362 SIP message), since as of the date of this document, the use of 363 Content-ID as a SIP header field is not defined (while it is defined 364 for use as a MIME header field). 366 A body part containing an MSD or metadata/control object has a 367 Content-Disposition header field value containing "By-Reference". 369 An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to 370 the initial INVITE and optionally attaches a metadata/control object 371 informing the PSAP of its capabilities. The MSD body part (and 372 metadata/control and PIDF-LO body parts if included) have a Content- 373 Disposition header field with the value "By-Reference; 374 handling=optional". Specifying "handling=optional" prevents the 375 INVITE from being rejected if it is processed by a legacy element 376 (e.g., a gateway between SIP and circuit-switched environments) that 377 does not understand the MSD (or metadata/control object or PIDF-LO). 378 The PSAP creates a metadata/control object acknowledging receipt of 379 the MSD and attaches it to the SIP final response to the INVITE. A 380 metadata/control object is not attached to provisional (e.g., 180) 381 responses. 383 A PSAP is able to reject a call while indicating that it is aware of 384 the situation by including a metadata/control object acknowledging 385 the MSD and containing "received=true" in a final response using SIP 386 response code 600 (Busy Everywhere), 486 (Busy Here), or 603 387 (Decline). 389 If the IVS receives an acknowledgment for an MSD containing 390 "received=false", this indicates that the PSAP was unable to properly 391 decode or process the MSD. The IVS action is not defined (e.g., it 392 might only log an error). Since the PSAP is able to request an 393 updated MSD during the call, if an initial MSD is unsatisfactory in 394 any way, the PSAP can choose to request another one. 396 A PSAP can request that the vehicle send an updated MSD during a 397 call. To do so, the PSAP creates a metadata/control object 398 requesting an MSD and attaches it to a SIP INFO request and sends it 399 within the dialog. The IVS then attaches an updated MSD to a SIP 400 INFO request and sends it within the dialog. If the IVS is unable to 401 send an MSD, it instead sends a metadata/control object acknowledging 402 the request with the 'success' parameter set to 'false' and a 403 'reason' parameter (and optionally a 'details' parameter) indicating 404 why the request could not be accomplished. Per [RFC6086], metadata/ 405 control objects and MSDs are sent using the INFO package defined in 406 Section 10 . In addition, to align with how an MSD or metadata/ 407 control block is transmitted in a SIP message other than an INFO 408 request, a Call-Info header field is included in the SIP INFO request 409 to reference the MSD or metadata/control block. See Section 10 for 410 information about the use of INFO requests to carry data within an 411 eCall. 413 The IVS is not expected to send an unsolicited MSD after the initial 414 INVITE. 416 Support for the data blocks defined in [RFC7852] is NOT REQUIRED for 417 conformance with this document. 419 7. Call Setup 421 In circuit-switched eCall, the IVS places a special form of a 112 422 emergency call which carries an eCall flag (indicating that the call 423 is an eCall and also if the call was manually or automatically 424 triggered); the mobile network operator (MNO) recognizes the eCall 425 flag and routes the call to an eCall-capable PSAP; vehicle data is 426 transmitted to the PSAP via the eCall in-band modem (in the voice 427 channel). 429 ///----\\\ 112 voice call with eCall flag +------+ 430 ||| IVS |||---------------------------------------->+ PSAP | 431 \\\----/// vehicle data via eCall in-band modem +------+ 433 Figure 1: circuit-switched eCall 435 For NG-eCall, the IVS establishes an emergency call using a Request- 436 URI indicating a manual or automatic eCall; the MNO (or ESInet) 437 recognizes the eCall URN and routes the call to an NG-eCall capable 438 PSAP; the PSAP interpets the vehicle data sent with the call and 439 makes it available to the call taker. 441 ///----\\\ IMS emergency call with eCall URN +------+ 442 IVS ----------------------------------------->+ PSAP | 443 \\\----/// vehicle data included in call setup +------+ 445 Figure 2: NG-eCall 447 See Section 6 for information on how the MSD is transported within an 448 NG-eCall. 450 This document registers new service URN children within the "sos" 451 subservice. These URNs provide the mechanism by which an eCall is 452 identified, and differentiate between manually and automatically 453 triggered eCalls (which might be subject to different treatment, 454 depending on policy). The two service URNs are: 455 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 456 which requests resources associated with an emergency call placed by 457 an in-vehicle system, carrying a standardized set of data related to 458 the vehicle and incident. 460 Call routing is outside the scope of this document. 462 8. Test Calls 464 eCall requires the ability to place test calls (see [TS22.101] clause 465 10.7 and [EN_16062] clause 7.2.2). These are calls that are 466 recognized and treated to some extent as eCalls but are not given 467 emergency call treatment and are not handled by call takers. The 468 specific handling of test eCalls is not itself standardized; 469 typically, the test call facility allows the IVS or user to verify 470 that an eCall can be successfully established with voice 471 communication. The IVS might also be able to verify that the MSD was 472 successfully received. 474 A service URN starting with "test." indicates a test call. For 475 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 476 This functionality is defined in [RFC6881]. 478 This document registers "urn:service:test.sos.ecall" for eCall test 479 calls. 481 The CS-eCall test call facility is a non-emergency number so does not 482 get treated as an emergency call. For NG-eCall, MNOs, emergency 483 authorities, and PSAPs can determine how to treat a vehicle call 484 requesting the "test" service URN so that the desired functionality 485 is tested, but this is outside the scope of this document. 487 9. The Metadata/Control Object 489 eCall requires the ability for the PSAP to acknowledge successful 490 receipt of an MSD sent by the IVS, and for the PSAP to request that 491 the IVS send an MSD (e.g., the call taker can initiate a request for 492 a new MSD to see if there have been changes in the vehicle's state, 493 e.g., location, direction, number of fastened seatbelts). 495 This document defines a block of metadata/control data as an XML 496 structure containing elements used for eCall and other related 497 emergency call systems and extension points. (This metadata/control 498 block is in effect a high-level protocol between the PSAP and IVS.) 499 When the PSAP sends a metadata/control block in response to data sent 500 by the IVS in a SIP request other than INFO (e.g., the MSD in the 501 initial INVITE), the metadata/control block is sent in the SIP 502 response to that request (e.g., the response to the INVITE request). 503 When the PSAP sends a control block in other circumstances (e.g., 504 mid-call), the control block is transmitted from the PSAP to the IVS 505 in a SIP INFO request within the established dialog. The IVS sends 506 the requested data (the MSD) in a new INFO request (per [RFC6086]). 507 This mechanism flexibly allows the PSAP to send eCall-specific data 508 to the IVS and the IVS to respond. INFO requests are sent using an 509 appropriate INFO Package. See Section 6 for more information on 510 attaching a metadata/control block to a SIP message. See Section 10 511 for information about the use of INFO requests to carry data within 512 an eCall. 514 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 515 initial INVITE), the PSAP sends a metadata/control block indicating 516 successful/unsuccessful receipt of the MSD in the SIP response to the 517 request. This also informs the IVS that an NG-eCall is in operation. 518 If the IVS receives a SIP response without the metadata/control 519 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 520 some part of the call is being handled as a legacy call). When the 521 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 522 receipt of a SIP INFO request containing a metadata/control block 523 requesting an MSD), the PSAP does not send a metadata/control block 524 indicating successful or unsuccessful receipt of the MSD. (Normal 525 SIP retransmission handles non-receipt of requested data; note that, 526 per [RFC6086], a 200 OK response to an INFO request indicates only 527 that the receiver has successfully received and accepted the INFO 528 request, it says nothing about the acceptability of the payload.) If 529 the IVS receives a request to send an MSD but it is unable to do so 530 for any reason, the IVS sends a metadata/control object acknowledging 531 the request and containing "success=false" and "reason" set to an 532 appropriate code. 534 This provides flexibility to handle various circumstances. For 535 example, if a PSAP is unable to accept an eCall (e.g., due to 536 overload or too many calls from the same location), it can reject the 537 INVITE. Since a metadata/control object is also included in the SIP 538 response that rejects the call, the IVS knows if the PSAP received 539 the MSD, and can inform the vehicle occupants that the PSAP 540 successfully received the vehicle location and information but can't 541 talk to the occupants at that time. Especially for SIP response 542 codes that indicate an inability to conduct a call (as opposed to a 543 technical inability to process the request), the IVS can also 544 determine that the call was successful on a technical level (e.g., 545 not helpful to retry as a CS-eCall). (Note that there could be edge 546 cases where the PSAP response is not received by the IVS, e.g., if an 547 intermediary sends a CANCEL, and an error response is forwarded 548 towards the IVS before the error response from the PSAP is received, 549 the response will be dropped, but these are unlikely to occur here.) 551 The metadata/control block is carried in the MIME type 'application/ 552 emergencyCallData.control+xml'. 554 The metadata/control block is designed for use with pan-European 555 eCall and also eCall-like systems (i.e., in other regions), and has 556 extension points. Note that eCall-like systems might define their 557 own vehicle data blocks, and so might need to register a new INFO 558 package to accomodate the new data content type and the metadata/ 559 control object. 561 9.1. The Control Block 563 The control block is an XML data structure allowing for 564 acknowledgments, requests, and capabilities information. It is 565 carried in a body part with a specific MIME content type. Three 566 elements are defined for use within a control block: 568 ack Acknowledges receipt of data or a request. 570 capabilities Used in a control block sent from the IVS to the PSAP 571 (e.g., in the initial INVITE) to inform the PSAP of the 572 vehicle capabilities. Child elements contain all 573 actions and data types supported by the vehicle. It is 574 OPTIONAL for the IVS to send this block. Omitting the 575 block indicates that the IVS supports only the 576 mandatory functionality defined in this document. 578 request Used in a control block sent by the PSAP to the IVS, to 579 request the vehicle to perform an action. 581 The element indicates the object being acknowledged and reports 582 success or failure. 584 The element contains attributes to indicate the request and 585 to supply related information. The 'action' attribute is mandatory 586 and indicates the specific action. An IANA registry is created in 587 Section 15.8.1 to contain the allowed values. 589 The element has child elements to indicate 590 the actions supported by the IVS. 592 9.1.1. The element 594 The element acknowledges receipt of an eCall data object or 595 request. An element references the Content-ID of the object 596 being acknowledged. The PSAP MUST send an element 597 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 598 the INVITE); this element indicates if the PSAP considers the 599 MSD successfully received or not. An element is not sent for a 600 element. 602 The element has the following attributes: 604 9.1.1.1. Attributes of the element 606 The element has the following attributes: 608 Name: ref 609 Usage: Mandatory 610 Type: anyURI 611 Direction: Sent in either direction 612 Description: References the Content-ID of the body part being 613 acknowledged. 614 Example: 616 Name: received 617 Usage: Conditional: mandatory in an element sent by a PSAP 618 Type: Boolean 619 Direction: In this document, sent from the PSAP to the IVS 620 Description: Indicates if the referenced object was considered 621 successfully received or not. 622 Example: 624 9.1.1.2. Child Element of the element 626 For extensibility, the element has the following child element: 628 Name: actionResult 629 Usage: Optional 630 Direction: Sent from the IVS to the PSAP 631 Description: An element indicates the result of an 632 action (other than a successfully executed 'send-data' action). 633 The element contains an element for each 634 element that is not a successfully executed 'send-data' 635 action. The element has the following attributes: 637 Name: action 638 Usage: Mandatory 639 Type: token 640 Description: Contains the value of the 'action' attribute of the 641 element 643 Name: success 644 Usage: Mandatory 645 Type: Boolean 646 Description: Indicates if the action was successfully 647 accomplished 649 Name: reason 650 Usage: Conditional 651 Type: token 652 Description: Used when 'success' is "false", this attribute 653 contains a reason code for a failure. A registry for reason 654 codes is defined in Section 15.8.2. 656 Name: details 657 Usage: optional 658 Type: string 659 Description: Contains further explanation of the circumstances of 660 a success or failure. The contents are implementation-specific 661 and human-readable. 663 9.1.1.3. Ack Examples 665 666 672 674 676 Figure 3: Ack Example from PSAP to IVS 678 9.1.2. The element 680 The element is transmitted by the IVS to indicate to 681 the PSAP its capabilities. No attributes for this element are 682 currently defined. The following child elements are defined: 684 9.1.2.1. Child Elements of the element 686 The element has the following child elements: 688 Name: request 689 Usage: Mandatory 690 Description: The element contains a child 691 element per action supported by the vehicle. 693 Examples: 694 696 It is OPTIONAL for the IVS to support the element. If 697 the IVS does not send a element, this indicates that 698 the only action supported by the IVS is 'send-data' with 699 'datatype' set to 'eCall.MSD'. 701 9.1.2.2. Capabilities Example 702 703 708 709 710 712 714 Figure 4: Capabilities Example 716 9.1.3. The element 718 A element appears one or more times on its own or as a 719 child of a element. It allows the PSAP to request 720 that the IVS perform an action. The only action that MUST be 721 supported is to send an MSD. The following attributes and child 722 elements are defined: 724 9.1.3.1. Attributes of the element 726 The element has the following attributes: 728 Name: action 729 Usage: Mandatory 730 Type: token 731 Direction: Sent in either direction 732 Description: Identifies the action that the vehicle is requested to 733 perform (in a element within a element, 734 indicates an action that the vehicle is capable of performing). 735 An IANA registry is established in Section 15.8.1 to contain the 736 allowed values. 737 Example: action="send-data" 739 Name: msgid 740 Usage: Conditional 741 Type: int 742 Direction: Sent in either direction 743 Description: Defined for extensibility. 744 Example: msgid="3" 746 Name: persistance 747 Usage: Optional 748 Type: duration 749 Direction: Sent in either direction 750 Description: Defined for extensibility. Specifies how long to carry 751 on the specified action. If absent, the default is for the 752 duration of the call. 753 Example: persistance="PT1H" 755 Name: datatype 756 Usage: Conditional 757 Type: token 758 Direction: Sent in either direction 759 Description: Mandatory with a "send-data" action within a 760 element that is not within a element. Specifies 761 the data block that the IVS is requested to transmit, using the 762 same identifier as in the 'purpose' attribute set in a Call-Info 763 header field to point to the data block. Permitted values are 764 contained in the 'Emergency Call Data Types' IANA registry 765 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 766 to support. 767 Example: datatype="eCall.MSD" 769 Name: supported-values 770 Usage: Conditional 771 Type: string 772 Direction: Sent from the IVS to the PSAP 773 Description: Defined for extensibility. Used in a element 774 that is a child of a element, this attribute lists 775 all supported values of the action type. Permitted values depend 776 on the action value. Multiple values are separated with a 777 semicolon. 779 Name: requested-state 780 Usage: Conditional 781 Type: token 782 Direction: Sent from the PSAP to the IVS 783 Description: Defined for extension. Indicates the requested state 784 of an element associated with the request type. Permitted values 785 depend on the request type. 787 Name: element-ID 788 Usage: Conditional 789 Type: token 790 Direction: Sent from the PSAP to the IVS 791 Description: Defined for extension. Identifies the element to be 792 acted on. Permitted values depend on the request type. 794 9.1.3.2. Request Example 796 797 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 body which MAY contain zero or one application/ 889 emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or 890 more application/emergencyCallData.control+xml (containing a 891 metadata/control object) parts. 893 The body parts are sent per [RFC6086], and in addition, to align with 894 with how these body parts are sent in SIP messages other than INFO 895 requests, each associated body part is referenced by a Call-Info 896 header field at the top level of the SIP message. The body part has 897 a Content-Disposition header field set to "By-Reference". 899 An MSD or metadata/control block is always enclosed in a multipart 900 body part (even if it would otherwise be the only body part in the 901 SIP message), since as of the date of this document, the use of 902 Content-ID as a SIP header field is not defined (while it is defined 903 for use as a MIME header field). The innermost multipart that 904 contains only body parts associated with the INFO package has a 905 Content-Disposition value of Info-Package. 907 See [TBD: THIS DOCUMENT] for more information. 909 10.7. Info Package Usage Restrictions 911 Usage is limited to vehicle-initiated emergency calls as defined in 912 [TBD: THIS DOCUMENT]. 914 10.8. Rate of INFO Requests 916 The rate of SIP INFO requests associated with the 917 emergencyCallData.eCall.MSD info package is normally quite low (most 918 dialogs are likely to contain zero INFO requests, while others can be 919 expected to carry an occasional request). 921 10.9. Info Package Security Considerations 923 The MIME content type registations for the data blocks that can be 924 carried using this INFO package contains a discussion of the security 925 and/or privacy considerations specific to that data block. The 926 "Security Considerations" and "Privacy Considerations" sections of 927 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 928 the data carried in eCalls. 930 10.10. Implementation Details 932 See [TBD: THIS DOCUMENT] for protocol details. 934 10.11. Examples 936 See [TBD: THIS DOCUMENT] for protocol examples. 938 11. Examples 940 Figure 6 illustrates an eCall. The call uses the request URI 941 'urn:service:sos.ecall.automatic' service URN and is recognized as an 942 eCall, and further as one that was invoked automatically by the IVS 943 due to a crash or other serious incident. In this example, the 944 originating network routes the call to an ESInet which routes the 945 call to the appropriate NG-eCall capable PSAP. The emergency call is 946 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 947 the entry point into the ESInet. The ESRP routes the call to a PSAP, 948 where it is received by a call taker. In deployments where there is 949 no ESInet, the originating network routes the call directly to the 950 appropriate NG-eCall capable PSAP, an illustration of which would be 951 identical to the one below except without an ESInet or ESRP. 953 +------------+ +---------------------------------------+ 954 | | | +-------+ | 955 | | | | PSAP2 | | 956 | | | +-------+ | 957 | | | | 958 | | | +------+ +-------+ | 959 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 960 | | | +------+ +-------+ | 961 | | | | 962 | | | +-------+ | 963 | | | | PSAP3 | | 964 | Originating| | +-------+ | 965 | Mobile | | | 966 | Network | | ESInet | 967 +------------+ +---------------------------------------+ 969 Figure 6: Example of NG-eCall Message Flow 971 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 972 for an updated MSD. The call flow shows the IVS initiating an 973 emergency call, including the MSD in the INVITE. The PSAP includes 974 in the 200 OK response a metadata/control object acknowledging 975 receipt of the MSD. During the call, the PSAP sends a request for an 976 MSD in an INFO request. The IVS sends the requested MSD in a new 977 INFO request. 979 IVS PSAP 980 |(1) INVITE (eCall MSD) | 981 |------------------------------------------->| 982 | | 983 |(2) 200 OK (eCall metadata [ack MSD]) | 984 |<-------------------------------------------| 985 | | 986 |(3) start media stream(s) | 987 |............................................| 988 | | 989 |(4) INFO (eCall metadata [request MSD]) | 990 |<-------------------------------------------| 991 | | 992 |(5) 200 OK | 993 |------------------------------------------->| 994 | | 995 |(6) INFO (eCall MSD) | 996 |------------------------------------------->| 997 | | 998 |(7) 200 OK | 999 |<-------------------------------------------| 1000 | | 1001 |(8) BYE | 1002 |<-------------------------------------------| 1003 | | 1004 |(9) end media streams | 1005 |............................................| 1006 | | 1007 |(10) 200 OK | 1008 |------------------------------------------->| 1010 Figure 7: NG-eCall Call Flow Illustration 1012 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 1013 contains an MSD. For simplicity, the example does not show all SIP 1014 headers, nor the SDP contents, nor does it show any additional data 1015 blocks added by the IVS or the originating mobile network. Because 1016 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 1017 contents cannot be included in a text document. 1019 INVITE urn:service:sos.ecall.automatic SIP/2.0 1020 To: urn:service:sos.ecall.automatic 1021 From: ;tag=9fxced76sl 1022 Call-ID: 3848276298220188511@atlanta.example.com 1023 Geolocation: 1024 Geolocation-Routing: no 1025 Call-Info: ; 1026 purpose=emergencyCallData.eCall.MSD 1027 Accept: application/sdp, application/pidf+xml, 1028 application/emergencyCallData.control+xml 1029 CSeq: 31862 INVITE 1030 Recv-Info: emergencyCallData.eCall.MSD 1031 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1032 SUBSCRIBE, NOTIFY, UPDATE 1033 Content-Type: multipart/mixed; boundary=boundary1 1034 Content-Length: ... 1036 --boundary1 1037 Content-Type: application/sdp 1039 ...Session Description Protocol (SDP) goes here... 1041 --boundary1 1042 Content-Type: application/emergencyCallData.eCall.MSD+per 1043 Content-ID: <1234567890@atlanta.example.com> 1044 Content-Disposition: by-reference;handling=optional 1046 ...MSD in ASN.1 PER encoding goes here... 1048 --boundary1-- 1050 Figure 8: SIP NG-eCall INVITE 1052 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1053 the INVITE of Figure 8, containing a control block acknowledging 1054 successful receipt of the eCall MSD. (For simplicity, the example 1055 does not show all SIP headers.) 1056 SIP/2.0 200 OK 1057 To: ;tag=9fxced76sl 1058 From: Exemplar PSAP 1059 Call-ID: 3848276298220188511@atlanta.example.com 1060 Call-Info: ; 1061 purpose=emergencyCallData.control 1062 Accept: application/sdp, application/pidf+xml, 1063 application/emergencyCallData.control+xml, 1064 application/emergencyCallData.eCall.MSD+per 1065 CSeq: 31862 INVITE 1066 Recv-Info: emergencyCallData.eCall.MSD 1067 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1068 SUBSCRIBE, NOTIFY, UPDATE 1069 Content-Type: multipart/mixed; boundary=boundaryX 1070 Content-Length: ... 1072 --boundaryX 1073 Content-Type: application/sdp 1075 ...Session Description Protocol (SDP) goes here... 1077 --boundaryX 1078 Content-Type: application/emergencyCallData.control+xml 1079 Content-ID: <2345678901@atlanta.example.com> 1080 Content-Disposition: by-reference 1082 1083 1089 1090 1092 --boundaryX-- 1094 Figure 9: 200 OK response to INVITE 1096 Figure 10 illustrates a SIP INFO request containing a metadata/ 1097 control block requesting an eCall MSD. (For simplicity, the example 1098 does not show all SIP headers.) 1099 INFO sip:+13145551111@example.com SIP/2.0 1100 To: ;tag=9fxced76sl 1101 From: Exemplar PSAP 1102 Call-ID: 3848276298220188511@atlanta.example.com 1103 Call-Info: ; 1104 purpose=emergencyCallData.control 1105 Accept: application/sdp, application/pidf+xml, 1106 application/emergencyCallData.control+xml, 1107 application/emergencyCallData.eCall.MSD+per 1108 CSeq: 41862 INFO 1109 Info-Package: emergencyCallData.eCall.MSD 1110 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1111 SUBSCRIBE, NOTIFY, UPDATE 1112 Content-Type: multipart/mixed; boundary=boundaryZZZ 1113 Content-Dispositio: Info-Package 1114 Content-Length: ... 1116 --boundaryZZZ 1117 Content-Disposition: by-reference 1118 Content-Type: application/emergencyCallData.control+xml 1119 Content-ID: <3456789012@atlanta.example.com> 1121 1122 1128 1130 1131 --boundaryZZZ-- 1133 Figure 10: INFO requesting MSD 1135 Figure 11 illustrates a SIP INFO request containing an MSD. For 1136 simplicity, the example does not show all SIP headers. Because the 1137 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1138 cannot be included in a text document. 1140 INFO urn:service:sos.ecall.automatic SIP/2.0 1141 To: urn:service:sos.ecall.automatic 1142 From: ;tag=9fxced76sl 1143 Call-ID: 3848276298220188511@atlanta.example.com 1144 Call-Info: ; 1145 purpose=emergencyCallData.eCall.MSD 1146 Accept: application/sdp, application/pidf+xml, 1147 application/emergencyCallData.control+xml 1148 CSeq: 51862 INFO 1149 Info-Package: emergencyCallData.eCall.MSD 1150 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1151 SUBSCRIBE, NOTIFY, UPDATE 1152 Content-Type: multipart/mixed; boundary=boundaryLine 1153 Content-Disposition: Info-Package 1154 Content-Length: ... 1156 --boundaryLine 1157 Content-Type: application/emergencyCallData.eCall.MSD+per 1158 Content-ID: <4567890123@atlanta.example.com> 1159 Content-Disposition: by-reference 1161 ...MSD in ASN.1 PER encoding goes here... 1163 --boundaryLine-- 1165 Figure 11: INFO containing MSD 1167 12. Security Considerations 1169 The security considerations described in [RFC5069] apply here. 1171 In addition to any network-provided location (which might be 1172 determined solely by the network, or in cooperation with or possibly 1173 entirely by the originating device), an eCall carries an IVS-supplied 1174 location within the MSD. This is likely to be useful to the PSAP, 1175 especially when no network-provided location is included, or when the 1176 two locations are independently determined. Even in situations where 1177 the network-supplied location is limited to the cell site, this can 1178 be useful as a sanity check on the device-supplied location contained 1179 in the MSD. 1181 The document [RFC7378] discusses trust issues regarding location 1182 provided by or determined in cooperation with end devices. 1184 Security considerations specific to the mechanism by which the PSAP 1185 sends acknowledgments and requests to the vehicle are discussed in 1186 the "Security Considerations" block of Section 15.3. 1188 Data received from external sources inherently carries implementation 1189 risks. For example, depending on the platform, buffer overflows can 1190 introduce remote code execution vulnerabilities, null characters can 1191 corrupt strings, numeric values used for internal calculations can 1192 result in underflow/overflow errors, malformed XML objects can expose 1193 parsing bugs, etc. Implementations need to be cognizant of the 1194 potential risks, observe best practices (which might include 1195 sufficiently capable static code analysis, fuzz testing, component 1196 isolation, avoiding use of unsafe coding techniques, third-party 1197 attack tests, signed software, over-the-air updates, etc.), and have 1198 multiple levels of protection. Implementors need to be aware that, 1199 potentially, the data objects described here and elsewhere might be 1200 malformed, might contain unexpected characters, excessively long 1201 attribute values, elements, etc. 1203 The security considerations discussed in [RFC7852] apply here (see 1204 especially the discussion of TLS, TLS versions, cypher suites, and 1205 PKI). 1207 When vehicle data or control/metadata is contained in a signed or 1208 encrypted body part, the enclosing multipart (e.g., multipart/signed 1209 or multipart/encrypted) has the same Content-ID as the enclosed data 1210 part. This allows an entity to identify and access the data blocks 1211 it is interested in without having to dive deeply into the message 1212 structure or decrypt parts it is not interested in. (The 'purpose' 1213 parameter in a Call-Info header field identifies the data and 1214 contains a CID URL pointing to the data block in the body, which has 1215 a matching Content-ID body part header field). 1217 13. Privacy Considerations 1219 The privacy considerations discussed in [RFC7852] apply here. The 1220 MSD carries some identifying and personal information (mostly about 1221 the vehicle and less about the owner), as well as location 1222 information, and so needs to be protected against unauthorized 1223 disclosure. Local regulations may impose additional privacy 1224 protection requirements. 1226 Privacy considerations specific to the data structure containing 1227 vehicle information are discussed in the "Security Considerations" 1228 block of Section 15.2. 1230 Privacy considerations specific to the mechanism by which the PSAP 1231 sends acknowledgments and requests to the vehicle are discussed in 1232 the "Security Considerations" block of Section 15.3. 1234 14. XML Schema 1236 This section defines an XML schema for the control block. The text 1237 description of the control block in Section 9.1 is normative and 1238 supersedes any conflicting aspect of this schema. 1240 1241 1243 1251 1254 1257 1258 1259 1260 1261 1263 1264 1265 1268 1269 1270 1271 1272 1274 1275 1276 1277 1278 1280 1281 1284 1287 1289 1290 conditionally 1291 mandatory when @success='false" 1292 to indicate reason code for a 1293 failure 1294 1295 1296 1298 1299 1300 1301 1304 1305 1308 1310 1311 1312 1313 1315 1316 1317 1318 1319 1323 1326 1327 1328 1330 1331 1333 1334 1335 1336 1337 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1355 Figure 12: Control Block Schema 1357 15. IANA Considerations 1359 This document formalizes the "EmergencyCallData" media (MIME) subtype 1360 tree. This tree is used only for content associated with emergency 1361 communications. New subtypes in this tree can be registered by the 1362 IETF or by other standards organizations working with emergency 1363 communications, using the "Specification Required" rule, which 1364 implies expert review. The designated expert is the ECRIT working 1365 group. 1367 15.1. Service URN Registrations 1369 IANA is requested to register the URN 'urn:service:sos.ecall' under 1370 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1372 This service requests resources associated with an emergency call 1373 placed by an in-vehicle system, carrying a standardized set of data 1374 related to the vehicle and incident. Two sub-services are registered 1375 as well: 1377 urn:service:sos.ecall.manual 1379 Used with an eCall invoked due to manual interaction by a vehicle 1380 occupant. 1382 urn:service:sos.ecall.automatic 1384 Used with an eCall invoked automatically, for example, due to a 1385 crash or other serious incident. 1387 IANA is also requested to register the URN 1388 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1389 defined in Setcion 17.2 of [RFC6881]. 1391 15.2. MIME Content-type Registration for 'application/ 1392 emergencyCallData.eCall.MSD+per' 1394 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1395 as a MIME content type, with a reference to this document, in 1396 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1397 RFC 7303 [RFC7303]. 1399 MIME media type name: application 1401 MIME subtype name: emergencyCallData.eCall.MSD+per 1403 Mandatory parameters: none 1405 Optional parameters: none 1407 Encoding scheme: binary 1409 Encoding considerations: Uses ASN.1 PER, which is a binary 1410 encoding; when transported in SIP, binary content transfer 1411 encoding is used. 1413 Security considerations: This content type is designed to carry 1414 vehicle and incident-related data during an emergency call. This 1415 data contains personal information including vehicle VIN, 1416 location, direction, etc. Appropriate precautions need to be 1417 taken to limit unauthorized access, inappropriate disclosure to 1418 third parties, and eavesdropping of this information. In general, 1419 it is acceptable for the data to be unprotected while briefly in 1420 transit within the Mobile Network Operator (MNO); the MNO is 1421 trusted to not permit the data to be accessed by third parties. 1422 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1424 Interoperability considerations: None 1425 Published specification: Annex A of EN 15722 [msd] 1427 Applications which use this media type: Pan-European eCall 1428 compliant systems 1430 Additional information: None 1432 Magic Number: None 1434 File Extension: None 1436 Macintosh file type code: 'BINA' 1438 Person and email address for further information: Randall Gellens, 1439 rg+ietf@randy.pensive.org 1441 Intended usage: LIMITED USE 1443 Author: The MSD specification was produced by the European 1444 Committee For Standardization (CEN). For contact information, 1445 please see . 1447 Change controller: The European Committee For Standardization 1448 (CEN) 1450 15.3. MIME Content-type Registration for 'application/ 1451 emergencyCallData.control+xml' 1453 IANA is requested to add application/emergencyCallData.control+xml as 1454 a MIME content type, with a reference to this document, in accordance 1455 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1456 [RFC7303]. 1458 MIME media type name: application 1460 MIME subtype name: emergencyCallData.control+xml 1462 Mandatory parameters: none 1464 Optional parameters: charset 1466 Indicates the character encoding of the XML content. 1468 Encoding considerations: Uses XML, which can employ 8-bit 1469 characters, depending on the character encoding used. See 1470 Section 3.2 of RFC 7303 [RFC7303]. 1472 Security considerations: 1474 This content type carries metadata and control information and 1475 requests, such as from a Public Safety Answering Point (PSAP) 1476 to an In-Vehicle System (IVS) during an emergency call. 1478 Metadata (such as an acknowledgment that data sent by the IVS 1479 to the PSAP was successfully received) has limited privacy and 1480 security implications. Control information (such as requests 1481 from the PSAP that the vehicle perform an action) has some 1482 privacy and security implications. The privacy concern arises 1483 from the ability to request the vehicle to transmit a data set, 1484 which as described in Section 15.2, can contain personal 1485 information. The security concern is the ability to request 1486 the vehicle to perform an action. Control information needs to 1487 originate only from a PSAP or other emergency services 1488 provider, and not be modified en-route. The level of integrity 1489 of the cellular network over which the emergency call is placed 1490 is a consideration: when the IVS initiates an eCall over a 1491 cellular network, in most cases it relies on the MNO to route 1492 the call to a PSAP. (Calls placed using other means, such as 1493 Wi-Fi or over-the-top services, generally incur somewhat higher 1494 levels of risk than calls placed "natively" using cellular 1495 networks.) A call-back from a PSAP merits additional 1496 consideration, since current mechanisms are not ideal for 1497 verifying that such a call is indeed a call-back from a PSAP in 1498 response to an emergency call placed by the IVS. See the 1499 discussion in Section 12 and the PSAP Callback document 1500 [RFC7090]. 1502 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1504 Interoperability considerations: None 1506 Published specification: This document 1508 Applications which use this media type: Pan-European eCall 1509 compliant systems 1511 Additional information: None 1513 Magic Number: None 1515 File Extension: .xml 1517 Macintosh file type code: 'TEXT' 1519 Person and email address for further information: Randall Gellens, 1520 rg+ietf@randy.pensive.org 1521 Intended usage: LIMITED USE 1523 Author: The IETF ECRIT WG. 1525 Change controller: The IETF ECRIT WG. 1527 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1528 Additional Data Blocks registry 1530 This specification requests IANA to add the 'eCall.MSD' entry to the 1531 Emergency Call Additional Data Blocks registry, with a reference to 1532 this document. 1534 15.5. Registration of the 'control' entry in the Emergency Call 1535 Additional Data Blocks registry 1537 This specification requests IANA to add the 'control' entry to the 1538 Emergency Call Additional Data Blocks registry, with a reference to 1539 this document. 1541 15.6. Registration of the emergencyCallData.eCall Info Package 1543 IANA is requested to add emergencyCallData.eCall to the Info Packages 1544 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1545 reference to this document. 1547 15.7. URN Sub-Namespace Registration 1549 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1551 This section registers a new XML namespace, as per the guidelines in 1552 RFC 3688 [RFC3688]. 1554 URI: urn:ietf:params:xml:ns:eCall 1556 Registrant Contact: IETF, ECRIT working group, , as 1557 delegated by the IESG . 1559 XML: 1561 BEGIN 1562 1563 1565 1566 1567 1569 Namespace for eCall Data 1570 1571 1572

Namespace for eCall Data

1573

See [TBD: This document].

1574 1575 1576 END 1578 15.7.2. Registration for urn:ietf:params:xml:ns:control 1580 This section registers a new XML namespace, as per the guidelines in 1581 RFC 3688 [RFC3688]. 1583 URI: urn:ietf:params:xml:ns:control 1585 Registrant Contact: IETF, ECRIT working group, , as 1586 delegated by the IESG . 1588 XML: 1590 BEGIN 1591 1592 1594 1595 1596 1598 Namespace for eCall Data: 1599 Control Block 1600 1601 1602

Namespace for eCall Data

1603

Control Block

1604

See [TBD: This document].

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