--- 1/draft-ietf-ecrit-car-crash-09.txt 2016-09-21 17:16:02.780742317 -0700 +++ 2/draft-ietf-ecrit-car-crash-10.txt 2016-09-21 17:16:02.864744735 -0700 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen -Expires: February 2, 2017 NeuStar, Inc. +Expires: March 25, 2017 NeuStar, Inc. H. Tschofenig Individual - August 1, 2016 + September 21, 2016 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-09.txt + draft-ietf-ecrit-car-crash-10.txt Abstract This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the @@ -51,85 +51,96 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 2, 2017. + This Internet-Draft will expire on March 25, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8 + 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 9 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 10 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 16 - 9.1. New values for the 'action' attribute' . . . . . . . . . 17 - 9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 18 - 9.3. The element . . . . . . . . . . . . . . . . . . . . 18 - 9.4. The element . . . . . . . . . . . . . . . 19 - 10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 21 - 11.1. INFO Package Requirements . . . . . . . . . . . . . . . 22 - 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 - 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 + 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17 + 9.1. New values for the 'action' attribute' . . . . . . . . . 18 + 9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19 + 9.3. The element . . . . . . . . . . . . . . . . . . . . 19 + 9.4. The element . . . . . . . . . . . . . . . 20 + 10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22 + 11.1. Overall Description . . . . . . . . . . . . . . . . . . 22 + 11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23 + 11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23 + 11.4. Info Package Parameters . . . . . . . . . . . . . . . . 23 + 11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23 + 11.6. INFO Message Body Parts . . . . . . . . . . . . . . . . 23 + 11.7. Info Package Usage Restrictions . . . . . . . . . . . . 24 + 11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24 + 11.9. Info Package Security Considerations . . . . . . . . . . 25 + 11.10. Implementation Details . . . . . . . . . . . . . . . . . 25 + 11.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.1. MIME Content-type Registration for - 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 30 + 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32 15.2. Registration of the 'VEDS' entry in the Emergency Call - Additional Data registry . . . . . . . . . . . . . . . . 31 - 15.3. New Action Values . . . . . . . . . . . . . . . . . . . 32 - 15.4. Static Message Registry . . . . . . . . . . . . . . . . 32 - 15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 33 - 15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 34 - 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 - 17. Changes from Previous Versions . . . . . . . . . . . . . . . 35 - 17.1. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 35 - 17.2. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 36 - 17.3. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 36 - 17.4. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 36 - 17.5. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 36 - 17.6. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 36 - 17.7. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 36 - 17.8. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 36 - 17.9. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 37 - 17.10. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 37 - 17.11. Changes from draft-gellens-01 to -02 . . . . . . . . . . 37 - 17.12. Changes from draft-gellens-00 to -01 . . . . . . . . . . 37 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 18.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 18.2. Informative references . . . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + Additional Data registry . . . . . . . . . . . . . . . . 33 + 15.3. New Action Values . . . . . . . . . . . . . . . . . . . 33 + 15.4. Static Message Registry . . . . . . . . . . . . . . . . 34 + 15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35 + 15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36 + 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 + 17. Changes from Previous Versions . . . . . . . . . . . . . . . 37 + 17.1. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 37 + 17.2. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 + 17.3. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 + 17.4. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38 + 17.5. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 + 17.6. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38 + 17.7. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38 + 17.8. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 38 + 17.9. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 + 17.10. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 + 17.11. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39 + 17.12. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 + 17.13. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 18.2. Informative references . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document re-uses terminology defined in Section 3 of [RFC5012]. Additionally, we use the following abbreviations: @@ -306,29 +317,29 @@ o An entry for the block is added to the Emergency Call Additional Data Blocks sub-registry (established by [RFC7852]); the registry entry is the root of the MIME sub-type (not including the 'EmergencyCallData' prefix and any suffix such as '+xml') o A new INFO package is registered that permits carrying the new content type and the metadata/control object (defined in [I-D.ietf-ecrit-ecall]) in INFO messages. - Section 6 describes how VEDA data and metadata/control are + Section 6 describes how VEDS data and metadata/control are transported within NG-ACN calls. Section 7 describes how such calls - are places. + are placed. These mechanisms are thus used to place emergency calls that are identifiable as ACN calls and that carry standardized crash data in an interoperable way. - Calls by in-vehicle systems are placed via cellular networks, which + Calls by in-vehicle systems are placed using cellular networks, which might ignore location information sent by an originating device in an emergency call INVITE, instead attaching their own location information (often determined in cooperation with the originating device). Standardized crash data structures often include location as determined by the IVS. A benefit of this is that it allows the PSAP to see both the location as determined by the cellular network (often in cooperation with the originating device) and the location as determined by the IVS. This specification inherits the ability to utilize test call @@ -574,71 +586,94 @@ to the INVITE (e.., 200 OK) lacks an eCall control structure acknowledging receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or TSP then proceeds as it would for a CS-ACN call (e.g., verbal conveyance of data) 6. Data Transport [RFC7852] establishes a general mechanism for attaching blocks of data to a SIP emergency call. This mechanism permits certain emergency call MIME types to be attached to SIP messages. This - document makes use of that mechanism. + document makes use of that mechanism. This document also registers + an INFO package (in Section 11) to enable NG-ACN related data blocks + to be carried in INFO messages. An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS]) by attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.VEDS+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the VEDS data by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as a VEDS data block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's - value is 'emergencyCallData.VEDS'. + value is 'emergencyCallData.VEDS'. The body part has a Content- + Disposition header field value of "By-Reference; handling=optional". + A VEDS data block is carried in an INFO message by using the INFO + package registration (defined in Section 11). A PSAP or IVS transmits a metadata/control object (see [I-D.ietf-ecrit-ecall]) by attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control block by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as a metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is - 'emergencyCallData.eCall.control'. + 'emergencyCallData.eCall.control'. The body part has a Content- + Disposition header field value of "By-Reference; handling=optional". + A metadata/control object is carried in an INFO message by using the + INFO package registration (defined in Section 11). An In-Vehicle System (IVS) initiating an NG-ACN call includes in the initial INVITE a VEDS data block and a metadata/control object informing the PSAP of its capabilities. The PSAP creates a metadata/ control object acknowledging receipt of the VEDS data and includes it - to the SIP response to the INVITE. + in the SIP final response to the INVITE. - A PSAP can request the vehicle to send an updated VEDS data block - during a call. The PSAP creates a metadata/control object requesting - the VEDS data and attaches it to a SIP INFO message which it sends - within the dialog. The IVS then attaches an updated VEDS data to a - SIP INFO message and sends it within the dialog. The metadata/ - control object and the VEDS are attached to an INFO message in the - same way they are attached to other messages (such as the INVITE and - the reply to the INVITE as discussed above). INFO messages are sent - using an appropriate INFO Package. See Section 11 for more + A PSAP can request that the vehicle send an updated VEDS data block + during a call. To do so, the PSAP creates a metadata/control object + requesting VEDS data and attaches it to a SIP INFO message which it + sends within the dialog. The IVS then attaches an updated VEDS data + object to a SIP INFO message and sends it within the dialog. The + metadata/control object and the VEDS data are both associated with + the INFO package registered by this document (in Section 11), and + hence sent per [RFC6086]. In addition, to align with the way a VEDS + or metadata/control block is transmitted in a non-INFO message, one + or more Call-Info header fields are included in the INFO message to + reference the VEDS or metadata/control block. If the body part + containing the VEDS or metadata/control block is the only body part + in the INFO, it has a Content-Disposition header field value of + "Info-Package; handling=optional". If it is contained within a + multipart body part, it has a Content-Disposition header field value + of "By-Reference; handling=optional". See Section 11 for more information. - When data is being carried in an INFO request message, the body part - also carries a Content-Disposition header field set to "Info- - Package". + If the IVS is aware that the VEDS data it sent previously has + changed, it MAY send an unsolicited MSD (in any convenient SIP + message, including an INFO) during the call. The PSAP sends an + acknowledgment of an unsolicited VEDS object (if the IVS sent the + unsolicited VEDS in an INFO, the acknowledgment is sent in a new + INFO, otherwise it is sent in the response to the message containing + the VEDS). + + Indicating "handling=optional" in the Content-Disposition header + field value protects the body part from being discarded by + intermediate entities that do not support it. 7. Call Setup A next-generation In-Vehicle System (IVS) initiates an NG-ACN call with a SIP INVITE using one of the SOS sub-services "SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI, standard sets of crash data and capabilities data encoded in standardized and registered formats, attached as additional data blocks as specified in Section 4.1 of [RFC7852]. As described in that document, each data block is identified by its MIME content- @@ -698,40 +733,39 @@ metadata/control object defined in [I-D.ietf-ecrit-ecall]. 8. Call Routing An Emergency Services IP Network (ESInet) is a network operated by or on behalf of emergency services authorities. It handles emergency call routing and processing before delivery to a PSAP. In the NG9-1-1 architecture adopted by NENA as well as the NG1-1-2 architecture adopted by EENA, each PSAP is connected to one or more ESInets. Each originating network is also connected to one or more - ESInets. The ESInets maintain policy-based routing rules which + ESInets. The ESInets maintain policy-based routing rules that control the routing and processing of emergency calls. The - centralization of such rules within ESInets provides for a cleaner + centralization of such rules within ESInets allows for a cleaner separation between the responsibilities of the originating network and that of the emergency services network, and provides greater flexibility and control over processing of emergency calls by the - emergency services authorities and PSAPs. This makes it easier to - react quickly to unusual situations that require changes in how - emergency calls are routed or handled (e.g., a natural disaster - closes a PSAP), as well as ease in making long-term changes that - affect such routing (e.g., cooperative agreements to specially handle - calls requiring translation or relay services). + emergency services authorities and PSAPs. This can make it easier to + react quickly to situations that require changes in how emergency + calls are routed or handled (e.g., a natural disaster closes a PSAP), + as well as ease in making long-term changes that affect such routing + (e.g., cooperative agreements to specially handle calls requiring + translation or relay services). - In an environment that uses ESInets, the originating network need - only detect that the service URN of an emergency call is or starts - with "sos", passing all types of emergency calls to an ESInet. The - ESInet is then responsible for routing such calls to an appropriate - PSAP. In an environment without an ESInet, the emergency services - authorities and the originating carriers determine how such calls are - routed. + In an environment that uses ESInets, the originating network might + pass all types of emergency calls to an ESInet (all calls with a + service URN of or starting with "sos"). The ESInet then routs such + calls to an appropriate PSAP. In an environment without an ESInet, + the emergency services authorities and the originating carriers + determine how such calls are routed. 9. New Metadata/Control Values This document adds new attribute values to the metadata/control structure defined in [I-D.ietf-ecrit-ecall]. In addition to the base usage from the PSAP to the IVS to acknowledge receipt of crash data, the element is also contained in a metadata/control block sent by the IVS to the PSAP. This is used by the IVS to acknowledge receipt of a request by the @@ -969,47 +1001,44 @@ This document registers the 'emergencyCallData.eCall.VEDS' INFO package. Both endpoints (the IVS and the PSAP equipment) include 'emergencyCallData.eCall.VEDS' in a Recv-Info header field per [RFC6086] to indicate ability to receive INFO messages carrying data as described here. Support for the 'emergencyCallData.eCall.VEDS' INFO package indicates - the ability to receive the VEDS body part as specified in [TBD: THIS - DOCUMENT] and the metadata/control body part as specified in - [I-D.ietf-ecrit-ecall]. + the ability to receive NG-ACN related body parts as specified in + [TBD: THIS DOCUMENT]. An INFO request message carrying data related to an emergency call as described in [TBD: THIS DOCUMENT] has an Info-Package header field set to 'emergencyCallData.eCall.VEDS' per [RFC6086]. -11.1. INFO Package Requirements - The requirements of Section 10 of [RFC6086] are addressed in the following sections. -11.1.1. Overall Description +11.1. Overall Description This section describes "what type of information is carried in INFO requests associated with the Info Package, and for what types of applications and functionalities UAs can use the Info Package." INFO requests associated with the emergencyCallData.eCall.VEDS INFO package carry data associated with emergency calls as defined in [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency calls established using SIP. The functionality is to carry vehicle data and metadata/control information between vehicles and PSAPs. Refer to [TBD: THIS DOCUMENT] for more information. -11.1.2. Applicability +11.2. Applicability This section describes "why the Info Package mechanism, rather than some other mechanism, has been chosen for the specific use-case...." The use of INFO is based on an analysis of the requirements against the intent and effects of INFO versus other approaches (which included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane transport, and non-SIP protocols). In particular, the transport of emergency call data blocks occurs within a SIP emergency dialog, per Section 6, and is normally carried in the initial INVITE and its @@ -1025,66 +1054,98 @@ is two-way communication of data related to the emergency dialog. Use of the media plane mechanisms was discounted because the number of messages needing to be exchanged in a dialog is normally zero or very few, and the size of the data is likewise very small. The overhead caused by user plane setup (e.g., to use MSRP as transport) would be disproportionately large. Based on the the analyses, the SIP INFO method was chosen to provide for mid-call data transport. -11.1.3. Info Package Name +11.3. Info Package Name The info package name is emergencyCallData.eCall.VEDS -11.1.4. Info Package Parameters +11.4. Info Package Parameters None -11.1.5. SIP Option-Tags +11.5. SIP Option-Tags None -11.1.6. INFO Message Body Parts +11.6. INFO Message Body Parts - The 'application/emergencyCallData.eCall.VEDS+xml' and 'application/ - emergencyCallData.eCall.control+xml' MIME types are associated with - this INFO package. See [TBD: THIS DOCUMENT] and - [I-D.ietf-ecrit-ecall] for more information. + The body for an emergencyCallData.eCall.VEDS info package is: -11.1.7. Info Package Usage Restrictions + o an application/emergencyCallData.eCall.VEDS+xml (containing a VEDS + data block), or + + o an application/emergencyCallData.eCall.control+xml (containing a + metadata/control object), or + + o an application/emergencyCallData.eCall.MSD+per (containing an + MSD), or + + o a multipart body containing: + + * zero or one application/emergencyCallData.eCall.VEDS+xml part + (containing a VEDS data block), + + * zero or more application/emergencyCallData.eCall.control+xml + (containing a metadata/control object), + + * zero or one application/emergencyCallData.eCall.MSD+per part + (containing an MSD), + + The body parts are sent per [RFC6086], and in addition, to align with + with how these body parts are sent in non-INFO messages, each + associated body part is referenced by a Call-Info header field at the + top level of the SIP message. If the body part is the only body + part, it has a Content-Disposition header field value of "INFO- + Package; handling=optional". If the body part is contained within a + multipart body part, it has a Content-Disposition header field value + of "By-Reference; handling=optional" (the top-level multipart body + part has "INFO-Package" in its Content-Disposition value). + + Service providers are not expected to attach [RFC7852] Additional + Data to an INFO request. + + See [TBD: THIS DOCUMENT] for more information. + +11.7. Info Package Usage Restrictions Usage is limited to vehicle-initiated emergency calls as defined in [TBD: THIS DOCUMENT]. -11.1.8. Rate of INFO Requests +11.8. Rate of INFO Requests The rate of SIP INFO requests associated with the emergencyCallData.eCall.VEDS info package is normally quite low (most dialogs are likely to contain zero INFO requests, while others can be expected to carry an occasional request). -11.1.9. Info Package Security Considerations +11.9. Info Package Security Considerations The MIME content type registations for the data blocks that can be - carried using this IFO package contains a discussion of the security + carried using this INFO package contains a discussion of the security and/or privacy considerations specific to that data block. The "Security Considerations" and "Privacy Considerations" sections of [TBD: THIS DOCUMENT] discuss security and privacy considerations of the data carried in vehicle-initiated emergency calls as described in that document. -11.1.10. Implementation Details +11.10. Implementation Details See [TBD: THIS DOCUMENT] for protocol details. -11.1.11. Examples +11.11. Examples See [TBD: THIS DOCUMENT] for protocol examples. 12. Example Figure 10 shows an NG-ACN call routing. The mobile network operator (MNO) routes the call to an Emergency services IP Network (ESInet), as for any emergency call. The ESInet routes the call to an appropriate NG-ACN-capable PSAP (using location information and the fact that that it is an NG-ACN call). The call is processed by the @@ -1165,36 +1225,37 @@ ('VehicleFinalRestOrientationCategoryCode' element) and an indication that there are no parts of the vehicle on fire (the 'VehicleFireIndicator' element). INVITE urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: Geolocation-Routing: no - Call-Info: cid:1234567890@atlanta.example.com; + Call-Info: ; purpose=EmergencyCallData.VEDS - Call-Info: cid:1234567892@atlanta.example.com; + Call-Info: ; purpose=EmergencyCallData.ecall.control Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml Recv-Info: emergencyCallData.eCall Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE CSeq: 31862 INVITE + Content-Disposition: info-package + Content-Transfer-Encoding: binary Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp - ...Session Description Protocol (SDP) goes here --boundary1 Content-Type: application/pidf+xml Content-ID: gps 2012-04-5T10:18:29Z 1M8GDM9A_KP042788 + --boundary1 Content-Type: application/EmergencyCallData.VEDS+xml - Content-ID: 1234567890@atlanta.example.com + Content-ID: <1234567890@atlanta.example.com> Content-Disposition: by-reference;handling=optional Saab @@ -1296,21 +1358,21 @@ false true Driver false --boundary1 Content-Type: application/EmergencyCallData.ecall.control+xml - Content-ID: 1234567892@atlanta.example.com + Content-ID: <1234567892@atlanta.example.com> Content-Disposition: by-reference;handling=optional @@ -1624,110 +1683,121 @@ 16. Acknowledgements We would like to thank Christer Holmberg for his suggestions; Michael Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex Buddenberg for their feedback; and Ulrich Dietz for his help with earlier versions of the original version of this document. 17. Changes from Previous Versions -17.1. Changes from draft-ietf-08 to draft-ietf-09 +17.1. Changes from draft-ietf-09 to draft-ietf-10 + + o Fixed errors in examples found by Dale in eCall draft + o Removed enclosing sub-section of INFO package registration section + o Added text per Christer and Dale's suggestions that the MSD and + metadata/control blocks are sent in INFO with a Call-Info header + field referencing them + + o Other text changes per comments received from Christer and Ivo + against eCall draft. + +17.2. Changes from draft-ietf-08 to draft-ietf-09 o Added INFO package registration for eCall.VEDS o Moved element and other extension points back to eCall document so that extension points are in base spec (and also to get XML schema to compile) o Text changes for clarification. -17.2. Changes from draft-ietf-07 to draft-ietf-08 +17.3. Changes from draft-ietf-07 to draft-ietf-08 o Moved much of the metadata/control object from [I-D.ietf-ecrit-ecall] to this document as extensions o Editorial clarifications and simplifications o Moved "Call Routing" to be a subsection of "Call Setup" o Deleted "Profile" section and moved some of its text into "Introduction" -17.3. Changes from draft-ietf-06 to draft-ietf-07 +17.4. Changes from draft-ietf-06 to draft-ietf-07 o Minor editorial changes -17.4. Changes from draft-ietf-05 to draft-ietf-06 +17.5. Changes from draft-ietf-05 to draft-ietf-06 o Added clarifying text regarding signed and encrypted data o Additional informative text in "Migration to Next-Generation" section o Additional clarifying text regarding security and privacy. -17.5. Changes from draft-ietf-04 to draft-ietf-05 +17.6. Changes from draft-ietf-04 to draft-ietf-05 o Reworded security text in main document and in MIME registration for the VEDS object -17.6. Changes from draft-ietf-03 to draft-ietf-04 +17.7. Changes from draft-ietf-03 to draft-ietf-04 o Added example VEDS object o Additional clarifications and corrections o Removed references from Abstract o Moved Document Scope section to follow Introduction -17.7. Changes from draft-ietf-02 to draft-ietf-03 +17.8. Changes from draft-ietf-02 to draft-ietf-03 o Additional clarifications and corrections -17.8. Changes from draft-ietf-01 to draft-ietf-02 +17.9. Changes from draft-ietf-01 to draft-ietf-02 o This document now refers to [I-D.ietf-ecrit-ecall] for technical aspects including the service URN; this document no longer proposes a unique service URN for non-eCall NG-ACN calls; the same service URN is now used for all NG-ACN calls including NG-eCall and non-eCall o Added discussion of an NG-ACN call placed to a PSAP that doesn't support it o Minor wording improvements and clarifications -17.9. Changes from draft-ietf-00 to draft-ietf-01 +17.10. Changes from draft-ietf-00 to draft-ietf-01 o Added further discussion of test calls o Added further clarification to the document scope o Mentioned that multi-region vehicles may need to support other crash notification specifications such as eCall o Minor wording improvements and clarifications -17.10. Changes from draft-gellens-02 to draft-ietf-00 +17.11. Changes from draft-gellens-02 to draft-ietf-00 o Renamed from draft-gellens- to draft-ietf- o Added text to Introduction to clarify that during a CS ACN, the PSAP call taker usually needs to listen to the data and transcribe it -17.11. Changes from draft-gellens-01 to -02 +17.12. Changes from draft-gellens-01 to -02 o Fixed case of 'EmergencyCallData', in accordance with changes to [RFC7852] -17.12. Changes from draft-gellens-00 to -01 +17.13. Changes from draft-gellens-00 to -01 o Now using 'EmergencyCallData' for purpose parameter values and MIME subtypes, in accordance with changes to [RFC7852] o Added reference to RFC 6443 o Fixed bug that caused Figure captions to not appear 18. References 18.1. Normative References [I-D.ietf-ecrit-ecall] Gellens, R. and H. Tschofenig, "Next-Generation Pan- - European eCall", draft-ietf-ecrit-ecall-10 (work in - progress), July 2016. + European eCall", draft-ietf-ecrit-ecall-11 (work in + progress), August 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, .