idnits 2.17.00 (12 Aug 2021) /tmp/idnits51158/draft-ietf-ecrit-ecall-15.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 9, 2016) is 2049 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: draft-ietf-ecrit-car-crash has been published as RFC 8148 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Core Technology Consulting 4 Intended status: Standards Track H. Tschofenig 5 Expires: April 12, 2017 Individual 6 October 9, 2016 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-15.txt 11 Abstract 13 This document describes how to use IP-based emergency services 14 mechanisms to support the next generation of the Pan European in- 15 vehicle emergency call service defined under the eSafety initiative 16 of the European Commission (generally referred to as "eCall"). eCall 17 is a standardized and mandated system for a special form of emergency 18 calls placed by vehicles, providing real-time communications and an 19 integrated set of related data. 21 This document also registers MIME Content Types and an Emergency Call 22 Additional Data Blocks for the eCall vehicle data and metadata/ 23 control data. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 12, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 63 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 10 68 9.1. The Control Block . . . . . . . . . . . . . . . . . . . . 12 69 9.1.1. The element . . . . . . . . . . . . . . . . . . 13 70 9.1.1.1. Attributes of the element . . . . . . . . . 13 71 9.1.1.2. Child Element of the element . . . . . . . 13 72 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14 73 9.1.2. The element . . . . . . . . . . . . . 15 74 9.1.2.1. Child Elements of the element . . 15 75 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15 76 9.1.3. The element . . . . . . . . . . . . . . . . 16 77 9.1.3.1. Attributes of the element . . . . . . . 16 78 9.1.3.2. Request Example . . . . . . . . . . . . . . . . . 18 79 10. The emergencyCallData.eCall.MSD INFO package . . . . . . . . 18 80 10.1. Overall Description . . . . . . . . . . . . . . . . . . 18 81 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . 19 82 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . 19 83 10.4. Info Package Parameters . . . . . . . . . . . . . . . . 19 84 10.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 19 85 10.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 20 86 10.7. Info Package Usage Restrictions . . . . . . . . . . . . 20 87 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 20 88 10.9. Info Package Security Considerations . . . . . . . . . . 20 89 10.10. Implementation Details . . . . . . . . . . . . . . . . . 20 90 10.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 91 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 94 14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 15.1. Service URN Registrations . . . . . . . . . . . . . . . 30 97 15.2. MIME Content-type Registration for 98 'application/emergencyCallData.eCall.MSD+per' . . . . . 31 99 15.3. MIME Content-type Registration for 100 'application/emergencyCallData.control+xml' . . . . . . 32 101 15.4. Registration of the 'eCall.MSD' entry in the Emergency 102 Call Additional Data Blocks registry . . . . . . . . . . 34 103 15.5. Registration of the 'control' entry in the Emergency 104 Call Additional Data Blocks registry . . . . . . . . . . 34 105 15.6. Registration of the emergencyCallData.eCall Info Package 34 106 15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34 107 15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34 108 15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35 109 15.8. Registry creation . . . . . . . . . . . . . . . . . . . 36 110 15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 36 111 15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 37 112 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 113 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 114 18. Changes from Previous Versions . . . . . . . . . . . . . . . 38 115 18.1. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 116 18.2. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 117 18.3. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 38 118 18.4. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 38 119 18.5. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 39 120 18.6. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 121 18.7. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 122 18.8. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40 123 18.9. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40 124 18.10. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40 125 18.11. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40 126 18.12. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40 127 18.13. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 128 18.14. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41 129 18.15. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41 130 18.16. Changes from draft-gellens-02 to -03 . . . . . . . . . . 41 131 18.17. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41 132 18.18. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42 133 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 134 19.1. Normative References . . . . . . . . . . . . . . . . . . 42 135 19.2. Informative references . . . . . . . . . . . . . . . . . 43 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 138 1. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 This document re-uses terminology defined in Section 3 of [RFC5012]. 146 Additionally, we use the following abbreviations: 148 +--------+----------------------------------------+ 149 | Term | Expansion | 150 +--------+----------------------------------------+ 151 | 3GPP | 3rd Generation Partnership Project | 152 | | | 153 | CEN | European Committee for Standardization | 154 | | | 155 | EENA | European Emergency Number Association | 156 | | | 157 | ESInet | Emergency Services IP network | 158 | | | 159 | IMS | IP Multimedia Subsystem | 160 | | | 161 | IVS | In-Vehicle System | 162 | | | 163 | MNO | Mobile Network Operator | 164 | | | 165 | MSD | Minimum Set of Data | 166 | | | 167 | PSAP | Public Safety Answering Point | 168 +--------+----------------------------------------+ 170 2. Document Scope 172 This document is focused on the signaling, data exchange, and 173 protocol needs of next-generation eCall (NG-eCall, also referred to 174 as packet-switched eCall or all-IP eCall) within the SIP framework 175 for emergency calls, as described in [RFC6443] and [RFC6881]. eCall 176 itself is specified by 3GPP and CEN and these specifications include 177 far greater scope than is covered here. 179 The eCall service operates over cellular wireless communication, but 180 this document does not address cellular-specific details, nor client 181 domain selection (e.g., circuit-switched versus packet-switched). 182 All such aspects are the purview of their respective standards 183 bodies. The scope of this document is limited to eCall operating 184 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 186 The technical contents of this document also provide a basis for 187 reuse and extension for other vehicle-initiated emergency call 188 systems. 190 Vehicles designed for multiple regions might need to support eCall 191 and other Advanced Automatic Crash Notification (AACN) systems, such 192 as described in [I-D.ietf-ecrit-car-crash]. 194 3. Introduction 196 Emergency calls made from vehicles (e.g., in the event of a crash) 197 assist in significantly reducing road deaths and injuries by allowing 198 emergency services to be aware of the incident, the state of the 199 vehicle, the location of the vehicle, and to have a voice channel 200 with the vehicle occupants. This enables a quick and appropriate 201 response. 203 The European Commission initiative of eCall was conceived in the late 204 1990s, and has evolved to a European Parliament decision requiring 205 the implementation of a compliant in-vehicle system (IVS) in new 206 vehicles and the deployment of eCall in the European Member States in 207 the very near future. Other regions are developing eCall-compatible 208 systems. 210 The pan-European eCall system provides a standardized and mandated 211 mechanism for emergency calls by vehicles. eCall establishes 212 procedures for such calls to be placed by in-vehicle systems, 213 recognized and processed by the mobile network, and routed to a 214 specialized PSAP where the vehicle data is available to assist the 215 call taker in assessing and responding to the situation. eCall 216 provides a standard set of vehicle, sensor (e.g., crash related), and 217 location data. 219 An eCall can be either user-initiated or automatically triggered. 220 Automatically triggered eCalls indicate a car crash or some other 221 serious incident. Manually triggered eCalls might be reports of 222 witnessed crashes or serious hazards. PSAPs might apply specific 223 operational handling to manual and automatic eCalls. 225 Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a 226 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the 227 call setup mark the call as an eCall, and further indicate if the 228 call was automatically or manually triggered. The call is routed to 229 an eCall-capable PSAP, a voice channel is established between the 230 vehicle and the PSAP, and an eCall in-band modem is used to carry a 231 defined set of vehicle, sensor (e.g., crash related), and location 232 data (the Minimum Set of Data or MSD) within the voice channel. The 233 same in-band mechanism is used for the PSAP to acknowledge successful 234 receipt of the MSD, and to request the vehicle to send a new MSD 235 (e.g., to check if the state of or location of the vehicle or its 236 occupants has changed). NG-eCall moves from circuit switched to all- 237 IP, and carries the vehicle data and eCall signaling as additional 238 data carried with the call. This document describes how IETF 239 mechanisms for IP-based emergency calls, including [RFC6443] and 240 [RFC7852] are used to provide the signaling and data exchange of the 241 next generation of pan-European eCall. 243 The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] 244 has published a Technical Report titled "Mobile Standards Group 245 (MSG); eCall for VoIP" [MSG_TR] that presents findings and 246 recommendations regarding support for eCall in an all-IP environment. 247 The recommendations include the use of 3GPP IMS emergency calling 248 with additional elements identifying the call as an eCall and as 249 carrying eCall data and with mechanisms for carrying the data and 250 eCall signaling. 3GPP IMS emergency services support multimedia, 251 providing the ability to carry voice, text, and video. This 252 capability is referred to within 3GPP as Multimedia Emergency 253 Services (MMES). 255 A transition period will exist during which time the various entities 256 involved in initiating and handling an eCall might support next- 257 generation eCall, legacy eCall, or both. The issues of migration and 258 co-existence during the transition period are outside the scope of 259 this document. 261 The MSD is carried in the MIME type 'application/ 262 emergencyCallData.eCall.MSD+per' and the metadata/control block is 263 carried in the MIME type 'application/emergencyCallData.control+xml' 264 (both of which are registered in Section 15) An INFO package is 265 defined (in Section 10) to enable these MIME types to be carried in 266 SIP INFO requests, per [RFC6086]. 268 4. eCall Requirements 270 eCall requirements are specified by CEN in [EN_16072] and by 3GPP in 271 [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle 272 data are contained in EN 15722 [msd]. 274 5. Vehicle Data 276 Pan-European eCall provides a standardized and mandated set of 277 vehicle related data, known as the Minimum Set of Data (MSD). The 278 European Committee for Standardization (CEN) has specified this data 279 in EN 15722 [msd], along with both ASN.1 and XML encodings. Both 280 circuit-switched eCall and this document use the ASN.1 PER encoding, 281 which is specified in Annex A of EN 15722 [msd] (the XML encoding 282 specified in Annex C is not used in this document). 284 This document registers the 'application/ 285 emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD 286 to be carried in SIP. As an ASN.1 PER encoded object, the data is 287 binary and transported using binary content transfer encoding within 288 SIP messages. This document also adds the 'eCall.MSD' entry to the 289 Emergency Call Additional Data Blocks registry to enable the MSD to 290 be recognized as such in a SIP-based eCall emergency call. (See 292 [RFC7852] for more information about the registry and how it is 293 used.) 295 See Section 6 for a discussion of how the MSD vehicle data is 296 conveyed in an NG-eCall. 298 6. Data Transport 300 [RFC7852] establishes a general mechanism for attaching blocks of 301 data to a SIP emergency call. This mechanism permits certain 302 emergency call MIME types to be attached to SIP messages. This 303 document makes use of that mechanism. This document also registers 304 an INFO package (in Section 10) to enable eCall related data blocks 305 to be carried in SIP INFO requests (per [RFC6086], new INFO usages 306 require the definition of an INFO package). 308 Note that if other data sets need to be transmitted in the future, 309 the appropriate signalling mechanism for such data needs to be 310 evaluated, including factors such as the size and frequency of such 311 data. 313 An In-Vehicle System (IVS) transmits an MSD (see Section 5) by 314 encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP 315 message as a MIME body part per [RFC7852]. The body part is 316 identified by its MIME content-type ('application/ 317 emergencyCallData.eCall.MSD+per') in the Content-Type header field of 318 the body part. The body part is assigned a unique identifier which 319 is listed in a Content-ID header field in the body part. The SIP 320 message is marked as containing the MSD by adding (or appending to) a 321 Call-Info header field at the top level of the SIP message. This 322 Call-Info header field contains a CID URL referencing the body part's 323 unique identifier, and a 'purpose' parameter identifying the data as 324 the eCall MSD per the Emergency Call Additional Data Blocks registry 325 entry; the 'purpose' parameter's value is 326 'emergencyCallData.eCall.MSD'. Per [RFC6086], an MSD is carried in a 327 SIP INFO request by using the INFO package defined in Section 10. 329 A PSAP or IVS transmits a metadata/control object (see Section 9) by 330 encoding it per the description in this document and attaching it to 331 a SIP message as a MIME body part per [RFC7852]. The body part is 332 identified by its MIME content-type ('application/ 333 emergencyCallData.control+xml') in the Content-Type header field of 334 the body part. The body part is assigned a unique identifier which 335 is listed in a Content-ID header field in the body part. The SIP 336 message is marked as containing the metadata/control object by adding 337 (or appending to) a Call-Info header field at the top level of the 338 SIP message. This Call-Info header field contains a CID URL 339 referencing the body part's unique identifier, and a 'purpose' 340 parameter identifying the data as an eCall metadata/control block per 341 the Emergency Call Additional Data Blocks registry entry; the 342 'purpose' parameter's value is 'emergencyCallData.control'. Per 343 [RFC6086], a metadata/control object is carried in a SIP INFO request 344 by using the INFO package defined in Section 10. 346 An MSD or a metadata/control block is always enclosed in a multipart 347 body part (even if it would otherwise be the only body part in the 348 SIP message). Note that in some cases there might be intermediate 349 multipart body parts between the top level multipart and the body 350 part containing the MSD or metadata/control object. 352 A body part containing an MSD or metadata/control object has a 353 Content-Disposition header field value containing "By-Reference". 355 An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to 356 the initial INVITE and optionally attaches a metadata/control object 357 informing the PSAP of its capabilities. The MSD body part (and 358 metadata/control and PIDF-LO body parts if included) have a Content- 359 Disposition header field with the value "By-Reference; 360 handling=optional". Specifying "handling=optional" prevents the 361 INVITE from being rejected if it is processed by a legacy element 362 (e.g., a gateway between SIP and circuit-switched environments) that 363 does not understand the MSD (or metadata/control object or PIDF-LO). 364 The PSAP creates a metadata/control object acknowledging receipt of 365 the MSD and attaches it to the SIP final response to the INVITE. A 366 metadata/control object is not attached to provisional (e.g., 180) 367 responses. 369 If the IVS receives an acknowledgment for an MSD containing 370 "received=false", this indicates that the PSAP was unable to properly 371 decode or process the MSD. The IVS action is not defined (e.g., it 372 might only log an error). Since the PSAP is able to request an 373 updated MSD during the call, if an initial MSD is unsatisfactory in 374 any way, the PSAP can choose to request another one. 376 A PSAP can request that the vehicle send an updated MSD during a 377 call. To do so, the PSAP creates a metadata/control object 378 requesting an MSD and attaches it to a SIP INFO request and sends it 379 within the dialog. The IVS then attaches an updated MSD to a SIP 380 INFO request and sends it within the dialog. If the IVS is unable to 381 send an MSD, it instead sends a metadata/control object acknowledging 382 the request with the 'success' parameter set to 'false' and a 383 'reason' parameter (and optionally a 'details' parameter) indicating 384 why the request could not be accomplished. Per [RFC6086], metadata/ 385 control objects and MSDs are sent using the INFO package defined in 386 Section 10 . In addition, to align with how an MSD or metadata/ 387 control block is transmitted in a SIP message other than an INFO 388 request, a Call-Info header field is included in the SIP INFO request 389 to reference the MSD or metadata/control block. See Section 10 for 390 information about the use of INFO requests to carry data within an 391 eCall. 393 The IVS is not expected to send an unsolicited MSD after the initial 394 INVITE. 396 Support for the data blocks defined in [RFC7852] is NOT REQUIRED for 397 conformance with this document. 399 7. Call Setup 401 In circuit-switched eCall, the IVS places a special form of a 112 402 emergency call which carries an eCall flag (indicating that the call 403 is an eCall and also if the call was manually or automatically 404 triggered); the mobile network operator (MNO) recognizes the eCall 405 flag and routes the call to an eCall-capable PSAP; vehicle data is 406 transmitted to the PSAP via the eCall in-band modem (in the voice 407 channel). 409 ///----\\\ 112 voice call with eCall flag +------+ 410 ||| IVS |||---------------------------------------->+ PSAP | 411 \\\----/// vehicle data via eCall in-band modem +------+ 413 Figure 1: circuit-switched eCall 415 For NG-eCall, the IVS establishes an emergency call using a Request- 416 URI indicating a manual or automatic eCall; the MNO (or ESInet) 417 recognizes the eCall URN and routes the call to an NG-eCall capable 418 PSAP; the PSAP interpets the vehicle data sent with the call and 419 makes it available to the call taker. 421 ///----\\\ IMS emergency call with eCall URN +------+ 422 IVS ----------------------------------------->+ PSAP | 423 \\\----/// vehicle data included in call setup +------+ 425 Figure 2: NG-eCall 427 See Section 6 for information on how the MSD is transported within an 428 NG-eCall. 430 This document registers new service URN children within the "sos" 431 subservice. These URNs provide the mechanism by which an eCall is 432 identified, and differentiate between manually and automatically 433 triggered eCalls (which might be subject to different treatment, 434 depending on policy). The two service URNs are: 436 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, 437 which requests resources associated with an emergency call placed by 438 an in-vehicle system, carrying a standardized set of data related to 439 the vehicle and incident. 441 Call routing is outside the scope of this document. 443 8. Test Calls 445 eCall requires the ability to place test calls (see [TS22.101] clause 446 10.7 and [EN_16062] clause 7.2.2). These are calls that are 447 recognized and treated to some extent as eCalls but are not given 448 emergency call treatment and are not handled by call takers. The 449 specific handling of test eCalls is not itself standardized; 450 typically, the test call facility allows the IVS or user to verify 451 that an eCall can be successfully established with voice 452 communication. The IVS might also be able to verify that the MSD was 453 successfully received. 455 A service URN starting with "test." indicates a test call. For 456 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 457 This functionality is defined in [RFC6881]. 459 This document registers "urn:service:test.sos.ecall" for eCall test 460 calls. 462 The CS-eCall test call facility is a non-emergency number so does not 463 get treated as an emergency call. For NG-eCall, MNOs, emergency 464 authorities, and PSAPs can determine how to treat a vehicle call 465 requesting the "test" service URN so that the desired functionality 466 is tested, but this is outside the scope of this document. 468 9. The Metadata/Control Object 470 eCall requires the ability for the PSAP to acknowledge successful 471 receipt of an MSD sent by the IVS, and for the PSAP to request that 472 the IVS send an MSD (e.g., the call taker can initiate a request for 473 a new MSD to see if there have been changes in the vehicle's state, 474 e.g., location, direction, number of fastened seatbelts). 476 This document defines a block of metadata/control data as an XML 477 structure containing elements used for eCall and other vehicle- 478 initiated emergency call systems (i.e., in other regions) and 479 extension points. (This metadata/control block is in effect a high- 480 level protocol between the PSAP and IVS.) When the PSAP sends a 481 metadata/control block in response to data sent by the IVS in a SIP 482 request other than INFO (e.g., the MSD in the initial INVITE), the 483 metadata/control block is sent in the SIP response to that request 484 (e.g., the response to the INVITE request). When the PSAP sends a 485 control block in other circumstances (e.g., mid-call), the control 486 block is transmitted from the PSAP to the IVS in a SIP INFO request 487 within the established dialog. The IVS sends the requested data (the 488 MSD) in a new INFO request (per [RFC6086]). This mechanism flexibly 489 allows the PSAP to send eCall-specific data to the IVS and the IVS to 490 respond. INFO requests are sent using an appropriate INFO Package. 491 See Section 6 for more information on attaching a metadata/control 492 block to a SIP message. See Section 10 for information about the use 493 of INFO requests to carry data within an eCall. 495 This mechanism requires 497 o An XML definition of the control object 498 o Extension points for use by eCall-like systems in other regions 499 o A MIME type registration for the control object (so it can be 500 carried in SIP messages and responses) 501 o An entry in the Emergency Call Additional Data Blocks registry so 502 that the control block can be recognized as emergency call 503 specific data within SIP messages 504 o An Info-Package registration per [RFC6086] permitting the 505 metadata/control block and the MSD within INFO requests 507 When the IVS includes an unsolicited MSD in a SIP request (e.g., the 508 initial INVITE), the PSAP sends a metadata/control block indicating 509 successful/unsuccessful receipt of the MSD in the SIP response to the 510 request. This also informs the IVS that an NG-eCall is in operation. 511 If the IVS receives a SIP response without the metadata/control 512 block, it indicates that the SIP dialog is not an NG-eCall (e.g., 513 some part of the call is being handled as a legacy call). When the 514 IVS sends a solicited MSD (e.g., in a SIP INFO request sent following 515 receipt of a SIP INFO request containing a metadata/control block 516 requesting an MSD), the PSAP does not send a metadata/control block 517 indicating successful or unsuccessful receipt of the MSD. (Normal 518 SIP retransmission handles non-receipt of requested data; if the IVS 519 sends a requested MSD in an INFO request and does not receive a SIP 520 status message for the INFO request, it resends it; if the PSAP 521 requests an MSD and does not receive a SIP status message for the 522 INFO request, it resends it.) If the IVS receives a request to send 523 an MSD but it is unable to do so for any reason, the IVS sends a 524 metadata/control object acknowledging the request and containing 525 "success=false" and "reason" set to an appropriate code. 527 This provides flexibility to handle various circumstances. For 528 example, if a PSAP is unable to accept an eCall (e.g., due to 529 overload or too many calls from the same location), it can reject the 530 INVITE. Since a metadata/control object is also included in the SIP 531 response that rejects the call, the IVS knows if the PSAP received 532 the MSD, and can inform the vehicle occupants that the PSAP 533 successfully received the vehicle location and information but can't 534 talk to the occupants at that time. Especially for SIP response 535 codes that indicate an inability to conduct a call (as opposed to a 536 technical inability to process the request), the IVS can also 537 determine that the call was successful on a technical level (e.g., 538 not helpful to retry as a CS-eCall). The SIP response codes 600 539 (Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when 540 the PSAP wants to reject a call but inform the vehicle occupants that 541 it is aware of the situation. (Note that there could be edge cases 542 where the PSAP response is not received by the IVS, e.g., if an 543 intermediary sends a CANCEL, and an error response is forwarded 544 towards the IVS before the error response from the PSAP is received, 545 the response will be dropped, but these are unlikely to occur here.) 547 The metadata/control block is carried in the MIME type 'application/ 548 emergencyCallData.control+xml'. 550 The metadata/control block is designed for use with pan-European 551 eCall and also eCall-like systems (i.e., in other regions), and has 552 extension points. Note that eCall-like systems might define their 553 own vehicle data blocks, and so might need to register a new INFO 554 package to accomodate the new data content type and the metadata/ 555 control object. 557 9.1. The Control Block 559 The control block is an XML data structure allowing for 560 acknowledgments, requests, and capabilities information. It is 561 carried in a body part with a specific MIME content type. Three 562 elements are defined for use within a control block: 564 ack Acknowledges receipt of data or a request. 566 capabilities Used in a control block sent from the IVS to the PSAP 567 (e.g., in the initial INVITE) to inform the PSAP of the 568 vehicle capabilities. Child elements contain all 569 actions and data types supported by the vehicle. It is 570 OPTIONAL for the IVS to send this block. Omitting the 571 block indicates that the IVS supports only the 572 mandatory functionality defined in this document. 574 request Used in a control block sent by the PSAP to the IVS, to 575 request the vehicle to perform an action. 577 The element indicates the object being acknowledged and reports 578 success or failure. 580 The element contains attributes to indicate the request and 581 to supply related information. The 'action' attribute is mandatory 582 and indicates the specific action. An IANA registry is created in 583 Section 15.8.1 to contain the allowed values. 585 The element has child elements to indicate 586 the actions supported by the IVS. 588 9.1.1. The element 590 The element acknowledges receipt of an eCall data object or 591 request. An element references the Content-ID of the object 592 being acknowledged. The PSAP MUST send an element 593 acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in 594 the INVITE); this element indicates if the PSAP considers the 595 MSD successfully received or not. An element is not sent for a 596 element. 598 The element has the following attributes: 600 9.1.1.1. Attributes of the element 602 The element has the following attributes: 604 Name: ref 605 Usage: Mandatory 606 Type: anyURI 607 Direction: Sent in either direction 608 Description: References the Content-ID of the body part being 609 acknowledged. 610 Example: 612 Name: received 613 Usage: Conditional: mandatory in an element sent by a PSAP 614 Type: Boolean 615 Direction: In this document, sent from the PSAP to the IVS 616 Description: Indicates if the referenced object was considered 617 successfully received or not. 618 Example: 620 9.1.1.2. Child Element of the element 622 For extensibility, the element has the following child element: 624 Name: actionResult 625 Usage: Optional 626 Direction: Sent from the IVS to the PSAP 627 Description: An element indicates the result of an 628 action (other than a successfully executed 'send-data' action). 629 The element contains an element for each 630 element that is not a successfully executed 'send-data' 631 action. The element has the following attributes: 633 Name: action 634 Usage: Mandatory 635 Type: token 636 Description: Contains the value of the 'action' attribute of the 637 element 639 Name: success 640 Usage: Mandatory 641 Type: Boolean 642 Description: Indicates if the action was successfully 643 accomplished 645 Name: reason 646 Usage: Conditional 647 Type: token 648 Description: Used when 'success' is "false", this attribute 649 contains a reason code for a failure. A registry for reason 650 codes is defined in Section 15.8.2. 652 Name: details 653 Usage: optional 654 Type: string 655 Description: Contains further explanation of the circumstances of 656 a success or failure. The contents are implementation-specific 657 and human-readable. 659 9.1.1.3. Ack Examples 660 661 667 669 671 Figure 3: Ack Example from PSAP to IVS 673 9.1.2. The element 675 The element is transmitted by the IVS to indicate to 676 the PSAP its capabilities. No attributes for this element are 677 currently defined. The following child elements are defined: 679 9.1.2.1. Child Elements of the element 681 The element has the following child elements: 683 Name: request 684 Usage: Mandatory 685 Description: The element contains a child 686 element per action supported by the vehicle. 688 Examples: 689 691 It is OPTIONAL for the IVS to support the element. If 692 the IVS does not send a element, this indicates that 693 the only action supported by the IVS is 'send-data' with 694 'datatype' set to 'eCall.MSD'. 696 9.1.2.2. Capabilities Example 697 698 703 704 705 707 709 Figure 4: Capabilities Example 711 9.1.3. The element 713 A element appears one or more times on its own or as a 714 child of a element. It allows the PSAP to request 715 that the IVS perform an action. The only action that MUST be 716 supported is to send an MSD. The following attributes and child 717 elements are defined: 719 9.1.3.1. Attributes of the element 721 The element has the following attributes: 723 Name: action 724 Usage: Mandatory 725 Type: token 726 Direction: Sent in either direction 727 Description: Identifies the action that the vehicle is requested to 728 perform (in a element within a element, 729 indicates an action that the vehicle is capable of performing). 730 An IANA registry is established in Section 15.8.1 to contain the 731 allowed values. 732 Example: action="send-data" 734 Name: msgid 735 Usage: Conditional 736 Type: int 737 Direction: Sent in either direction 738 Description: Defined for extensibility. 739 Example: msgid="3" 741 Name: persistance 742 Usage: Optional 743 Type: duration 744 Direction: Sent in either direction 745 Description: Defined for extensibility. Specifies how long to carry 746 on the specified action. If absent, the default is for the 747 duration of the call. 748 Example: persistance="PT1H" 750 Name: datatype 751 Usage: Conditional 752 Type: token 753 Direction: Sent in either direction 754 Description: Mandatory with a "send-data" action within a 755 element that is not within a element. Specifies 756 the data block that the IVS is requested to transmit, using the 757 same identifier as in the 'purpose' attribute set in a Call-Info 758 header field to point to the data block. Permitted values are 759 contained in the 'Emergency Call Data Types' IANA registry 760 established in [RFC7852]. Only the "eCall.MSD" value is mandatory 761 to support. 762 Example: datatype="eCall.MSD" 764 Name: supported-values 765 Usage: Conditional 766 Type: string 767 Direction: Sent from the IVS to the PSAP 768 Description: Defined for extensibility. Used in a element 769 that is a child of a element, this attribute lists 770 all supported values of the action type. Permitted values depend 771 on the action value. Multiple values are separated with a 772 semicolon. 774 Name: requested-state 775 Usage: Conditional 776 Type: token 777 Direction: Sent from the PSAP to the IVS 778 Description: Defined for extension. Indicates the requested state 779 of an element associated with the request type. Permitted values 780 depend on the request type. 782 Name: element-ID 783 Usage: Conditional 784 Type: token 785 Direction: Sent from the PSAP to the IVS 786 Description: Defined for extension. Identifies the element to be 787 acted on. Permitted values depend on the request type. 789 9.1.3.2. Request Example 791 792 798 800 802 Figure 5: Request Example 804 10. The emergencyCallData.eCall.MSD INFO package 806 This document registers the 'emergencyCallData.eCall.MSD' INFO 807 package. 809 Both endpoints (the IVS and the PSAP equipment) include 810 'emergencyCallData.eCall.MSD' in a Recv-Info header field per 811 [RFC6086] to indicate ability to receive INFO requests carrying data 812 as described here. 814 Support for the 'emergencyCallData.eCall.MSD' INFO package indicates 815 the ability to receive eCall related body parts as specified in [TBD: 816 THIS DOCUMENT]. 818 An INFO request message carrying body parts related to an emergency 819 call as described in [TBD: THIS DOCUMENT] has an Info-Package header 820 field set to 'emergencyCallData.eCall.MSD' per [RFC6086]. 822 The requirements of Section 10 of [RFC6086] are addressed in the 823 following sections. 825 10.1. Overall Description 827 This section describes "what type of information is carried in INFO 828 requests associated with the Info Package, and for what types of 829 applications and functionalities UAs can use the Info Package." 831 INFO requests associated with the emergencyCallData.eCall.MSD INFO 832 package carry data associated with emergency calls as defined in 833 [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency 834 calls established using SIP. The functionality is to carry vehicle 835 data and metadata/control information between vehicles and PSAPs. 836 Refer to [TBD: THIS DOCUMENT] for more information. 838 10.2. Applicability 840 This section describes "why the Info Package mechanism, rather than 841 some other mechanism, has been chosen for the specific use-case...." 843 The use of INFO is based on an analysis of the requirements against 844 the intent and effects of INFO versus other approaches (which 845 included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane 846 transport, and non-SIP protocols). In particular, the transport of 847 emergency call data blocks occurs within a SIP emergency dialog, per 848 Section 6, and is normally carried in the initial INVITE and its 849 response; the use of INFO only occurs when emergency-call-related 850 data needs to be sent mid-call. While MESSAGE could be used, it is 851 not tied to a SIP dialog as is INFO and thus might not be associated 852 with the dialog. SIP OPTIONS or re-INVITE could also be used, but is 853 seen as less clean than INFO. SUBSCRIBE/NOTIFY could be coerced into 854 service, but the semantics are not a good fit, e.g., the subscribe/ 855 notify mechanism provides one-way communication consisting of (often 856 multiple) notifications from notifier to subscriber indicating that 857 certain events in notifier have occurred, whereas what's needed here 858 is two-way communication of data related to the emergency dialog. 859 Use of the media plane mechanisms was discounted because the number 860 of messages needing to be exchanged in a dialog is normally zero or 861 very few, and the size of the data is likewise very small. The 862 overhead caused by user plane setup (e.g., to use MSRP as transport) 863 would be disproportionately large. 865 Based on the the analyses, the SIP INFO method was chosen to provide 866 for mid-call data transport. 868 10.3. Info Package Name 870 The info package name is emergencyCallData.eCall.MSD 872 10.4. Info Package Parameters 874 None 876 10.5. SIP Option-Tags 878 None 880 10.6. INFO Request Body Parts 882 The body for an emergencyCallData.eCall.MSD info package is a 883 multipart body. Zero or one application/ 884 emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or 885 more application/emergencyCallData.control+xml (containing a 886 metadata/control object) parts are permitted. Intermediate multipart 887 body parts MAY appear. 889 The body parts are sent per [RFC6086], and in addition, to align with 890 with how these body parts are sent in SIP messages other than INFO 891 requests, each associated body part is referenced by a Call-Info 892 header field at the top level of the SIP message. The body part has 893 a Content-Disposition header field set to "By-Reference". 895 See [TBD: THIS DOCUMENT] for more information. 897 10.7. Info Package Usage Restrictions 899 Usage is limited to vehicle-initiated emergency calls as defined in 900 [TBD: THIS DOCUMENT]. 902 10.8. Rate of INFO Requests 904 The rate of SIP INFO requests associated with the 905 emergencyCallData.eCall.MSD info package is normally quite low (most 906 dialogs are likely to contain zero INFO requests, while others can be 907 expected to carry an occasional request). 909 10.9. Info Package Security Considerations 911 The MIME content type registations for the data blocks that can be 912 carried using this INFO package contains a discussion of the security 913 and/or privacy considerations specific to that data block. The 914 "Security Considerations" and "Privacy Considerations" sections of 915 [TBD: THIS DOCUMENT] discuss security and privacy considerations of 916 the data carried in eCalls. 918 10.10. Implementation Details 920 See [TBD: THIS DOCUMENT] for protocol details. 922 10.11. Examples 924 See [TBD: THIS DOCUMENT] for protocol examples. 926 11. Examples 928 Figure 6 illustrates an eCall. The call uses the request URI 929 'urn:service:sos.ecall.automatic' service URN and is recognized as an 930 eCall, and further as one that was invoked automatically by the IVS 931 due to a crash or other serious incident. In this example, the 932 originating network routes the call to an ESInet which routes the 933 call to the appropriate NG-eCall capable PSAP. The emergency call is 934 received by the ESInet's Emergency Services Routing Proxy (ESRP), as 935 the entry point into the ESInet. The ESRP routes the call to a PSAP, 936 where it is received by a call taker. In deployments where there is 937 no ESInet, the originating network routes the call directly to the 938 appropriate NG-eCall capable PSAP, an illustration of which would be 939 identical to the one below except without an ESInet or ESRP. 941 +------------+ +---------------------------------------+ 942 | | | +-------+ | 943 | | | | PSAP2 | | 944 | | | +-------+ | 945 | | | | 946 | | | +------+ +-------+ | 947 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 948 | | | +------+ +-------+ | 949 | | | | 950 | | | +-------+ | 951 | | | | PSAP3 | | 952 | Originating| | +-------+ | 953 | Mobile | | | 954 | Network | | ESInet | 955 +------------+ +---------------------------------------+ 957 Figure 6: Example of NG-eCall Message Flow 959 Figure 7 illustrates an eCall call flow with a mid-call PSAP request 960 for an updated MSD. The call flow shows the IVS initiating an 961 emergency call, including the MSD in the INVITE. The PSAP includes 962 in the 200 OK response a metadata/control object acknowledging 963 receipt of the MSD. During the call, the PSAP sends a request for an 964 MSD in an INFO request. The IVS sends the requested MSD in a new 965 INFO request. 967 IVS PSAP 968 |(1) INVITE (eCall MSD) | 969 |------------------------------------------->| 970 | | 971 |(2) 200 OK (eCall metadata [ack MSD]) | 972 |<-------------------------------------------| 973 | | 974 |(3) start media stream(s) | 975 |............................................| 976 | | 977 |(4) INFO (eCall metadata [request MSD]) | 978 |<-------------------------------------------| 979 | | 980 |(5) 200 OK | 981 |------------------------------------------->| 982 | | 983 |(6) INFO (eCall MSD) | 984 |------------------------------------------->| 985 | | 986 |(7) 200 OK | 987 |<-------------------------------------------| 988 | | 989 |(8) BYE | 990 |<-------------------------------------------| 991 | | 992 |(9) end media streams | 993 |............................................| 994 | | 995 |(10) 200 OK | 996 |------------------------------------------->| 998 Figure 7: NG-eCall Call Flow Illustration 1000 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 1001 contains an MSD. For simplicity, the example does not show all SIP 1002 headers, nor the SDP contents, nor does it show any additional data 1003 blocks added by the IVS or the originating mobile network. Because 1004 the MSD is encoded in ASN.1 PER, which is a binary encoding, its 1005 contents cannot be included in a text document. 1007 INVITE urn:service:sos.ecall.automatic SIP/2.0 1008 To: urn:service:sos.ecall.automatic 1009 From: ;tag=9fxced76sl 1010 Call-ID: 3848276298220188511@atlanta.example.com 1011 Geolocation: 1012 Geolocation-Routing: no 1013 Call-Info: ; 1014 purpose=emergencyCallData.eCall.MSD 1015 Accept: application/sdp, application/pidf+xml, 1016 application/emergencyCallData.control+xml 1017 CSeq: 31862 INVITE 1018 Recv-Info: emergencyCallData.eCall.MSD 1019 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1020 SUBSCRIBE, NOTIFY, UPDATE 1021 Content-Type: multipart/mixed; boundary=boundary1 1022 Content-Length: ... 1024 --boundary1 1025 Content-Type: application/sdp 1027 ...Session Description Protocol (SDP) goes here... 1029 --boundary1 1030 Content-Type: application/emergencyCallData.eCall.MSD+per 1031 Content-ID: <1234567890@atlanta.example.com> 1032 Content-Disposition: by-reference;handling=optional 1034 ...MSD in ASN.1 PER encoding goes here... 1036 --boundary1-- 1038 Figure 8: SIP NG-eCall INVITE 1040 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1041 the INVITE of Figure 8, containing a control block acknowledging 1042 successful receipt of the eCall MSD. (For simplicity, the example 1043 does not show all SIP headers.) 1044 SIP/2.0 200 OK 1045 To: ;tag=9fxced76sl 1046 From: Exemplar PSAP 1047 Call-ID: 3848276298220188511@atlanta.example.com 1048 Call-Info: ; 1049 purpose=emergencyCallData.control 1050 Accept: application/sdp, application/pidf+xml, 1051 application/emergencyCallData.control+xml, 1052 application/emergencyCallData.eCall.MSD+per 1053 CSeq: 31862 INVITE 1054 Recv-Info: emergencyCallData.eCall.MSD 1055 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1056 SUBSCRIBE, NOTIFY, UPDATE 1057 Content-Type: multipart/mixed; boundary=boundaryX 1058 Content-Length: ... 1060 --boundaryX 1061 Content-Type: application/sdp 1063 ...Session Description Protocol (SDP) goes here... 1065 --boundaryX 1066 Content-Type: application/emergencyCallData.control+xml 1067 Content-ID: <2345678901@atlanta.example.com> 1068 Content-Disposition: by-reference 1070 1071 1077 1078 1080 --boundaryX-- 1082 Figure 9: 200 OK response to INVITE 1084 Figure 10 illustrates a SIP INFO request containing a metadata/ 1085 control block requesting an eCall MSD. (For simplicity, the example 1086 does not show all SIP headers.) 1087 INFO sip:+13145551111@example.com SIP/2.0 1088 To: ;tag=9fxced76sl 1089 From: Exemplar PSAP 1090 Call-ID: 3848276298220188511@atlanta.example.com 1091 Call-Info: ; 1092 purpose=emergencyCallData.control 1093 Accept: application/sdp, application/pidf+xml, 1094 application/emergencyCallData.control+xml, 1095 application/emergencyCallData.eCall.MSD+per 1096 CSeq: 41862 INFO 1097 Info-Package: emergencyCallData.eCall.MSD 1098 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1099 SUBSCRIBE, NOTIFY, UPDATE 1100 Content-Type: multipart/mixed; boundary=boundaryZZZ 1101 Content-Length: ... 1103 --boundaryZZZ 1104 Content-Disposition: by-reference 1105 Content-Type: application/emergencyCallData.control+xml 1106 Content-ID: <3456789012@atlanta.example.com> 1108 1109 1115 1117 1118 --boundaryZZZ-- 1120 Figure 10: INFO requesting MSD 1122 Figure 11 illustrates a SIP INFO request containing an MSD. For 1123 simplicity, the example does not show all SIP headers. Because the 1124 MSD is encoded in ASN.1 PER, which is a binary encoding, its contents 1125 cannot be included in a text document. 1127 INFO urn:service:sos.ecall.automatic SIP/2.0 1128 To: urn:service:sos.ecall.automatic 1129 From: ;tag=9fxced76sl 1130 Call-ID: 3848276298220188511@atlanta.example.com 1131 Call-Info: ; 1132 purpose=emergencyCallData.eCall.MSD 1133 Accept: application/sdp, application/pidf+xml, 1134 application/emergencyCallData.control+xml 1135 CSeq: 51862 INFO 1136 Info-Package: emergencyCallData.eCall.MSD 1137 Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 1138 SUBSCRIBE, NOTIFY, UPDATE 1139 Content-Type: multipart/mixed; boundary=boundaryLine 1140 Content-Length: ... 1142 --boundaryLine 1143 Content-Type: application/emergencyCallData.eCall.MSD+per 1144 Content-ID: <4567890123@atlanta.example.com> 1145 Content-Disposition: by-reference 1147 ...MSD in ASN.1 PER encoding goes here... 1149 --boundaryLine-- 1151 Figure 11: INFO containing MSD 1153 12. Security Considerations 1155 The security considerations described in [RFC5069] apply here. 1157 In addition to any network-provided location (which might be 1158 determined solely by the network, or in cooperation with or possibly 1159 entirely by the originating device), an eCall carries an IVS-supplied 1160 location within the MSD. This is likely to be useful to the PSAP, 1161 especially when no network-provided location is included, or when the 1162 two locations are independently determined. Even in situations where 1163 the network-supplied location is limited to the cell site, this can 1164 be useful as a sanity check on the device-supplied location contained 1165 in the MSD. 1167 The document [RFC7378] discusses trust issues regarding location 1168 provided by or determined in cooperation with end devices. 1170 Security considerations specific to the mechanism by which the PSAP 1171 sends acknowledgments and requests to the vehicle are discussed in 1172 the "Security Considerations" block of Section 15.3. 1174 Data received from external sources inherently carries implementation 1175 risks. For example, depending on the platform, buffer overflows can 1176 introduce remote code execution vulnerabilities, null characters can 1177 corrupt strings, numeric values used for internal calculations can 1178 result in underflow/overflow errors, malformed XML objects can expose 1179 parsing bugs, etc. Implementations need to be cognizant of the 1180 potential risks, observe best practices (which might include 1181 sufficiently capable static code analysis, fuzz testing, component 1182 isolation, avoiding use of unsafe coding techniques, third-party 1183 attack tests, signed software, over-the-air updates, etc.), and have 1184 multiple levels of protection. Implementors need to be aware that, 1185 potentially, the data objects described here and elsewhere might be 1186 malformed, might contain unexpected characters, excessively long 1187 attribute values, elements, etc. 1189 The security considerations discussed in [RFC7852] apply here (see 1190 especially the discussion of TLS, TLS versions, cypher suites, and 1191 PKI). 1193 When vehicle data or control/metadata is contained in a signed or 1194 encrypted body part, the enclosing multipart (e.g., multipart/signed 1195 or multipart/encrypted) has the same Content-ID as the enclosed data 1196 part. This allows an entity to identify and access the data blocks 1197 it is interested in without having to dive deeply into the message 1198 structure or decrypt parts it is not interested in. (The 'purpose' 1199 parameter in a Call-Info header field identifies the data and 1200 contains a CID URL pointing to the data block in the body, which has 1201 a matching Content-ID body part header field). 1203 13. Privacy Considerations 1205 The privacy considerations discussed in [RFC7852] apply here. The 1206 MSD carries some identifying and personal information (mostly about 1207 the vehicle and less about the owner), as well as location 1208 information, and so needs to be protected against unauthorized 1209 disclosure. Local regulations may impose additional privacy 1210 protection requirements. 1212 Privacy considerations specific to the data structure containing 1213 vehicle information are discussed in the "Security Considerations" 1214 block of Section 15.2. 1216 Privacy considerations specific to the mechanism by which the PSAP 1217 sends acknowledgments and requests to the vehicle are discussed in 1218 the "Security Considerations" block of Section 15.3. 1220 14. XML Schema 1222 This section defines an XML schema for the control block. The text 1223 description of the control block in Section 9.1 is normative and 1224 supersedes any conflicting aspect of this schema. 1226 1227 1229 1237 1240 1243 1244 1245 1246 1247 1249 1250 1251 1254 1255 1256 1257 1258 1260 1261 1262 1263 1264 1266 1267 1270 1273 1275 1276 conditionally 1277 mandatory when @success='false" 1278 to indicate reason code for a 1279 failure 1280 1281 1282 1284 1285 1286 1287 1290 1291 1294 1296 1297 1298 1299 1301 1302 1303 1304 1305 1309 1312 1313 1314 1316 1317 1319 1320 1321 1322 1323 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1339 1341 Figure 12: Control Block Schema 1343 15. IANA Considerations 1345 This document formalizes the "EmergencyCallData" media (MIME) subtype 1346 tree. This tree is used only for content associated with emergency 1347 communications. New subtypes in this tree can be registered by the 1348 IETF or by other standards organizations working with emergency 1349 communications, using the "Specification Required" rule, which 1350 implies expert review. The designated expert is the ECRIT working 1351 group. 1353 15.1. Service URN Registrations 1355 IANA is requested to register the URN 'urn:service:sos.ecall' under 1356 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1358 This service requests resources associated with an emergency call 1359 placed by an in-vehicle system, carrying a standardized set of data 1360 related to the vehicle and incident. Two sub-services are registered 1361 as well: 1363 urn:service:sos.ecall.manual 1365 Used with an eCall invoked due to manual interaction by a vehicle 1366 occupant. 1368 urn:service:sos.ecall.automatic 1370 Used with an eCall invoked automatically, for example, due to a 1371 crash or other serious incident. 1373 IANA is also requested to register the URN 1374 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1375 defined in Setcion 17.2 of [RFC6881]. 1377 15.2. MIME Content-type Registration for 'application/ 1378 emergencyCallData.eCall.MSD+per' 1380 IANA is requested to add application/emergencyCallData.eCall.MSD+per 1381 as a MIME content type, with a reference to this document, in 1382 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1383 RFC 7303 [RFC7303]. 1385 MIME media type name: application 1387 MIME subtype name: emergencyCallData.eCall.MSD+per 1389 Mandatory parameters: none 1391 Optional parameters: none 1393 Encoding scheme: binary 1395 Encoding considerations: Uses ASN.1 PER, which is a binary 1396 encoding; when transported in SIP, binary content transfer 1397 encoding is used. 1399 Security considerations: This content type is designed to carry 1400 vehicle and incident-related data during an emergency call. This 1401 data contains personal information including vehicle VIN, 1402 location, direction, etc. Appropriate precautions need to be 1403 taken to limit unauthorized access, inappropriate disclosure to 1404 third parties, and eavesdropping of this information. In general, 1405 it is acceptable for the data to be unprotected while briefly in 1406 transit within the Mobile Network Operator (MNO); the MNO is 1407 trusted to not permit the data to be accessed by third parties. 1408 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1410 Interoperability considerations: None 1411 Published specification: Annex A of EN 15722 [msd] 1413 Applications which use this media type: Pan-European eCall 1414 compliant systems 1416 Additional information: None 1418 Magic Number: None 1420 File Extension: None 1422 Macintosh file type code: 'BINA' 1424 Person and email address for further information: Randall Gellens, 1425 rg+ietf@randy.pensive.org 1427 Intended usage: LIMITED USE 1429 Author: The MSD specification was produced by the European 1430 Committee For Standardization (CEN). For contact information, 1431 please see . 1433 Change controller: The European Committee For Standardization 1434 (CEN) 1436 15.3. MIME Content-type Registration for 'application/ 1437 emergencyCallData.control+xml' 1439 IANA is requested to add application/emergencyCallData.control+xml as 1440 a MIME content type, with a reference to this document, in accordance 1441 to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 1442 [RFC7303]. 1444 MIME media type name: application 1446 MIME subtype name: emergencyCallData.control+xml 1448 Mandatory parameters: none 1450 Optional parameters: charset 1452 Indicates the character encoding of the XML content. 1454 Encoding considerations: Uses XML, which can employ 8-bit 1455 characters, depending on the character encoding used. See 1456 Section 3.2 of RFC 7303 [RFC7303]. 1458 Security considerations: 1460 This content type carries metadata and control information and 1461 requests, such as from a Public Safety Answering Point (PSAP) 1462 to an In-Vehicle System (IVS) during an emergency call. 1464 Metadata (such as an acknowledgment that data sent by the IVS 1465 to the PSAP was successfully received) has limited privacy and 1466 security implications. Control information (such as requests 1467 from the PSAP that the vehicle perform an action) has some 1468 privacy and security implications. The privacy concern arises 1469 from the ability to request the vehicle to transmit a data set, 1470 which as described in Section 15.2, can contain personal 1471 information. The security concern is the ability to request 1472 the vehicle to perform an action. Control information needs to 1473 originate only from a PSAP or other emergency services 1474 provider, and not be modified en-route. The level of integrity 1475 of the cellular network over which the emergency call is placed 1476 is a consideration: when the IVS initiates an eCall over a 1477 cellular network, in most cases it relies on the MNO to route 1478 the call to a PSAP. (Calls placed using other means, such as 1479 Wi-Fi or over-the-top services, generally incur somewhat higher 1480 levels of risk than calls placed "natively" using cellular 1481 networks.) A call-back from a PSAP merits additional 1482 consideration, since current mechanisms are not ideal for 1483 verifying that such a call is indeed a call-back from a PSAP in 1484 response to an emergency call placed by the IVS. See the 1485 discussion in Section 12 and the PSAP Callback document 1486 [RFC7090]. 1488 Sections 7 and Section 8 of [RFC7852] contain more discussion. 1490 Interoperability considerations: None 1492 Published specification: This document 1494 Applications which use this media type: Pan-European eCall 1495 compliant systems 1497 Additional information: None 1499 Magic Number: None 1501 File Extension: .xml 1503 Macintosh file type code: 'TEXT' 1505 Person and email address for further information: Randall Gellens, 1506 rg+ietf@randy.pensive.org 1507 Intended usage: LIMITED USE 1509 Author: The IETF ECRIT WG. 1511 Change controller: The IETF ECRIT WG. 1513 15.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1514 Additional Data Blocks registry 1516 This specification requests IANA to add the 'eCall.MSD' entry to the 1517 Emergency Call Additional Data Blocks registry, with a reference to 1518 this document. 1520 15.5. Registration of the 'control' entry in the Emergency Call 1521 Additional Data Blocks registry 1523 This specification requests IANA to add the 'control' entry to the 1524 Emergency Call Additional Data Blocks registry, with a reference to 1525 this document. 1527 15.6. Registration of the emergencyCallData.eCall Info Package 1529 IANA is requested to add emergencyCallData.eCall to the Info Packages 1530 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1531 reference to this document. 1533 15.7. URN Sub-Namespace Registration 1535 15.7.1. Registration for urn:ietf:params:xml:ns:eCall 1537 This section registers a new XML namespace, as per the guidelines in 1538 RFC 3688 [RFC3688]. 1540 URI: urn:ietf:params:xml:ns:eCall 1542 Registrant Contact: IETF, ECRIT working group, , as 1543 delegated by the IESG . 1545 XML: 1547 BEGIN 1548 1549 1551 1552 1553 1555 Namespace for eCall Data 1556 1557 1558

Namespace for eCall Data

1559

See [TBD: This document].

1560 1561 1562 END 1564 15.7.2. Registration for urn:ietf:params:xml:ns:control 1566 This section registers a new XML namespace, as per the guidelines in 1567 RFC 3688 [RFC3688]. 1569 URI: urn:ietf:params:xml:ns:control 1571 Registrant Contact: IETF, ECRIT working group, , as 1572 delegated by the IESG . 1574 XML: 1576 BEGIN 1577 1578 1580 1581 1582 1584 Namespace for eCall Data: 1585 Control Block 1586 1587 1588

Namespace for eCall Data

1589

Control Block

1590

See [TBD: This document].

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