--- 1/draft-ietf-ecrit-car-crash-21.txt 2017-01-19 03:13:08.494765411 -0800 +++ 2/draft-ietf-ecrit-car-crash-22.txt 2017-01-19 03:13:08.578767415 -0800 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen -Expires: July 15, 2017 NeuStar, Inc. +Expires: July 22, 2017 NeuStar, Inc. H. Tschofenig Individual - January 11, 2017 + January 18, 2017 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-21.txt + draft-ietf-ecrit-car-crash-22.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 @@ -53,21 +53,21 @@ 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 July 15, 2017. + This Internet-Draft will expire on July 22, 2017. Copyright Notice Copyright (c) 2017 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 @@ -97,49 +97,48 @@ 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14.1. MIME Media Type Registration for 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 28 14.2. Registration of the 'VEDS' entry in the Emergency Call Data Types registry . . . . . . . . . . . . . . . . . . 30 14.3. New Action Values . . . . . . . . . . . . . . . . . . . 30 14.4. Emergency Call Static Message Registry . . . . . . . . . 30 14.5. Emergency Call Vehicle Lamp ID Registry . . . . . . . . 31 - 14.6. Lamp State Registry . . . . . . . . . . . . . . . . . . 32 - 14.7. Emergency Call Vehicle Camera ID Registry . . . . . . . 33 - 14.8. The emergencyCallData.eCall.VEDS SIP INFO package . . . 34 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 - 16. Changes from Previous Versions . . . . . . . . . . . . . . . 38 - 16.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 38 - 16.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 - 16.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 - 16.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 - 16.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 - 16.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 - 16.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 - 16.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 - 16.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 - 16.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 - 16.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 - 16.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 - 16.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 - 16.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 - 16.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40 - 16.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 - 16.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 - 16.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 - 16.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 - 16.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 41 - 17.2. Informative references . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 + 14.6. Emergency Call Vehicle Camera ID Registry . . . . . . . 32 + 14.7. The emergencyCallData.eCall.VEDS SIP INFO package . . . 33 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + 16. Changes from Previous Versions . . . . . . . . . . . . . . . 37 + 16.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 37 + 16.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 37 + 16.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 37 + 16.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 37 + 16.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 37 + 16.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 37 + 16.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 37 + 16.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 37 + 16.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 + 16.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 + 16.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38 + 16.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 + 16.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38 + 16.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38 + 16.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 + 16.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 + 16.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 + 16.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39 + 16.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 + 16.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 17.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: @@ -597,21 +596,21 @@ o A new SIP INFO package is registered that permits carrying the new media type, the metadata/control object (defined in [I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS objects, in SIP INFO requests. 7. Data Transport [RFC7852] establishes a general mechanism for including blocks of data within a SIP emergency call. This document makes use of that mechanism. This document also registers a SIP INFO package (in - Section 14.8) to enable NG-ACN related data blocks to be carried in + Section 14.7) to enable NG-ACN related data blocks to be carried in SIP INFO requests (per [RFC6086], new SIP INFO method usages require the definition of a SIP INFO package). The Vehicle Emergency Data Set (VEDS) is an XML structure defined by the Association of Public-Safety Communications Officials (APCO) and the National Emergency Number Association (NENA) [VEDS]. It is carried in a body part with MIME media type 'application/ EmergencyCallData.VEDS+xml'. An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS]) @@ -620,38 +619,38 @@ emergencyCallData.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 Types registry entry; the 'purpose' parameter's value is 'emergencyCallData.VEDS'. A VEDS data block is carried in a SIP INFO - request by using the SIP INFO package defined in Section 14.8. + request by using the SIP INFO package defined in Section 14.7. A PSAP or IVS transmits a metadata/control object (see [I-D.ietf-ecrit-ecall]) by including it in a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME media type ('application/emergencyCallData.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 Types registry entry; the 'purpose' parameter's value is 'emergencyCallData.control'. A metadata/control object is carried in a SIP INFO request by using the SIP INFO package defined in - Section 14.8. + Section 14.7. A body part containing a VEDS or metadata/control object has a Content-Disposition header field value containing "By-Reference" and is always enclosed in a multipart body part (even if it would otherwise be the only body part in the SIP message), since as of the date of this document, the use of Content-ID as a SIP header field is not defined (while it is defined for use as a MIME header field). An In-Vehicle System (IVS) initiating an NG-ACN call includes in the initial INVITE a VEDS data block and a metadata/control object @@ -676,25 +675,25 @@ 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 includes it as a body part of a SIP INFO request sent within the dialog. The IVS then includes an updated VEDS data object as a body part of a SIP INFO request and sends it within the dialog. If the IVS is unable to send the VEDS, it instead sends a metadata/control object acknowledging the request with the 'success' parameter set to 'false' and a 'reason' parameter (and optionally a 'details' parameter) indicating why the request cannot be accomplished. Per [RFC6086], metadata/control objects and VEDS - data are sent using the SIP INFO package defined in Section 14.8. In + data are sent using the SIP INFO package defined in Section 14.7. In addition, to align with the way a VEDS or metadata/control block is transmitted in a SIP message other than a SIP INFO request, one or more Call-Info header fields are included in the SIP INFO request - referencing the VEDS or metadata/control block. See Section 14.8 for + referencing the VEDS or metadata/control block. See Section 14.7 for more information on the use of SIP INFO requests within NG-ACN calls. Any metadata/control object sent by a PSAP can request that the vehicle perform an action (such as sending a data block, flashing lights, providing a camera feed, etc.) The vehicle sends an acknowledgement for any request other than a successfully executed send-data action. Multiple requests with the same 'action' value MUST be sent in separate body parts (to avoid any ambiguity in the acknowledgement). @@ -753,20 +752,21 @@ o Transmit data object (VEDS MUST be supported; MSD MAY be supported) Optional Actions (the IVS and the PSAP MAY support): o Play and/or display static (pre-defined) message o Speak/display dynamic text (text supplied in action) o Flash or turn on or off a lamp (light) o Honk horn + o Lock or unlock doors o Enable a camera The element indicates the object being acknowledged (i.e., a data object or a metadata/control block containing elements), and reports success or failure. The element has child elements indicating the actions supported by the IVS. The element contains attributes to indicate the request and to supply any needed information, and MAY contain a child @@ -813,39 +813,41 @@ in [RFC5226], which require a stable, public document and implies expert review of the publication. msg-dynamic displays or speaks (via text-to-speech) a dynamic message contained in a child element within the request. honk sounds the horn. lamp turns a lamp (light) on, off, or flashes. The lamp is identified by a lamp ID token contained in an "element-id" - attribute of the request. The desired state of the lamp is - indicated by a lamp state token contained in a "requested-state" + attribute of the request. The desired state of the lamp is either + "on", "off", or "flash" as indicated in a "requested-state" attribute. The duration of the lamp's requested state is specified in a "persistence" attribute. A registry of lamp identification values is defined in Section 14.5. The initial values (listed in Table 4) are head, interior, fog-front, fog- rear, brake, brake-center, position-front, position-rear, turn- - left, turn-right, and hazard. A registry of lamp states is - defined in Section 14.6. The initial values (listed in Table 5) - are "on", "off", and "flash". + left, turn-right, and hazard. enable-camera adds a one-way media stream (established via SIP re- INVITE sent by the vehicle) to enable the PSAP call taker to view a feed from a camera. A registry of camera identification values - is defined in Section 14.7. The initial values (listed in - Table 6) are backup, left-rear, right-rear, forward, rear-wide, + is defined in Section 14.6. The initial values (listed in + Table 5) are backup, left-rear, right-rear, forward, rear-wide, lane, interior, night-front, night-rear, night-left, and night- right. + door-lock locks or unlocks all door locks. A "requested-state" + attribute contains either "locked" or "unlocked" to indicate if + the doors are to be locked or unlocked. + Note that there is no 'request' action to play dynamic media (such as an audio message). The PSAP can send a SIP re-INVITE to establish a one-way media stream for this purpose. 9.2. Request Example @@ -914,40 +916,41 @@ up to and including that value. If the "lamp" action is supported, a child element with the 'action' attribute set to "lamp" is included, with the 'supported- values' attribute set to all supported lamp IDs. A registry is created in Section 14.5 to contain lamp ID values. If the "enable-camera" action is supported, a child element with the 'action' attribute set to "enable-camera" is included, with the 'supported-values' attribute set to all supported camera IDs. A - registry is created in Section 14.7 to contain camera ID values. + registry is created in Section 14.6 to contain camera ID values. 9.4.1. Capabilities Example + Figure 9: Capabilities Example 10. Test Calls An NG-ACN test call is a call that is recognized and treated to some extent as an NG-ACN call but not given emergency call treatment and @@ -1217,20 +1220,21 @@ + --boundary1-- Figure 11: SIP INVITE for a Vehicle-Initated Emergency Call 12. Security Considerations @@ -1370,20 +1374,22 @@ +---------------+-------------------------------------+ | msg-static | Section 9.1 of [TBD: THIS DOCUMENT] | | | | | msg-dynamic | Section 9.1 of [TBD: THIS DOCUMENT] | | | | | honk | Section 9.1 of [TBD: THIS DOCUMENT] | | | | | lamp | Section 9.1 of [TBD: THIS DOCUMENT] | | | | | enable-camera | Section 9.1 of [TBD: THIS DOCUMENT] | + | | | + | door-lock | Section 9.1 of [TBD: THIS DOCUMENT] | +---------------+-------------------------------------+ Table 2: Emergency Call Action Registry New Values 14.4. Emergency Call Static Message Registry This document creates a new sub-registry called "Emergency Call Static Message" in the "Emergency Call Metadata/Control Data" registry established by [I-D.ietf-ecrit-ecall]. Because all compliant vehicles are expected to support all static messages @@ -1465,71 +1471,39 @@ | | | | turn-left | Left turn/directional lamps | | | | | turn-right | Right turn/directional lamps | | | | | hazard | Hazard/four-way lamps | +----------------+---------------------------------------------+ Table 4: Emergency Call Lamp ID Registry Initial Values -14.6. Lamp State Registry - - This document creates a new sub-registry called "Lamp State" in the - "Emergency Call Metadata/Control Data" registry established by - [I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies - the states that lamps (lights) can be placed into. As defined in - [RFC5226], this registry operates under "Expert Review" rules. The - expert should determine that the proposed lamp state is clearly - understandable and is sufficiently distinguishable from other lamp - states. - - The contents of this registry are: - - Name: The identifier to be used in the 'requested-state' attribute - of a metadata/control element. - - Description: A description of state of a lamp (light). - - The initial set of values is listed in Table 5. - - +-------+----------------------------------------+ - | Name | Description | - +-------+----------------------------------------+ - | on | The lamp is on (illuminated) | - | | | - | off | The lamp is off (extinguished) | - | | | - | flash | The lamp alternates between on and off | - +-------+----------------------------------------+ - - Table 5: Lamp State Registry Initial Values - -14.7. Emergency Call Vehicle Camera ID Registry +14.6. Emergency Call Vehicle Camera ID Registry This document creates a new sub-registry called "Emergency Call Vehicle Camera ID" in the "Emergency Call Metadata/Control Data" registry established by [I-D.ietf-ecrit-ecall]. This new sub- registry uniquely identifies automotive cameras. As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed camera name is clearly understandable and is sufficiently distinguishable from other camera names. The contents of this registry are: Name: The identifier to be used in the 'element-id' attribute of a control element. Description: A description of the camera. - The initial set of values is listed in Table 6. + The initial set of values is listed in Table 5. +-------------+-----------------------------------------------------+ | Name | Description | +-------------+-----------------------------------------------------+ | backup | Shows what is behind the vehicle, e.g., often used | | | for driver display when the vehicle is in reverse. | | | Also known as rearview, reverse, rear visibility, | | | etc. | | | | | left-rear | Shows view to the left and behind (e.g., left side | @@ -1554,58 +1528,58 @@ | | | | night-rear | Night-vision view of what is behind the vehicle | | | | | night-left | Night-vision view of what is to the left of the | | | vehicle | | | | | night-right | Night-vision view of what is to the right of the | | | vehicle | +-------------+-----------------------------------------------------+ - Table 6: Emergency Call Vehicle Camera ID Registry Initial Values + Table 5: Emergency Call Vehicle Camera ID Registry Initial Values -14.8. The emergencyCallData.eCall.VEDS SIP INFO package +14.7. The emergencyCallData.eCall.VEDS SIP INFO package This document registers the 'emergencyCallData.eCall.VEDS' SIP 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 SIP INFO messages carrying data as described here. Support for the 'emergencyCallData.eCall.VEDS' SIP INFO package indicates the ability to receive NG-ACN related body parts as specified in [TBD: THIS DOCUMENT]. A SIP 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]. The requirements of Section 10 of [RFC6086] are addressed in the following sections. -14.8.1. Overall Description +14.7.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." SIP INFO requests associated with the emergencyCallData.eCall.VEDS SIP 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. -14.8.2. Applicability +14.7.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 the SIP INFO method is based on an analysis of the requirements against the intent and effects of the INFO method versus other approaches (which included the SIP MESSAGE method, SIP OPTIONS method, SIP re-INVITE method, media plane transport, and non-SIP protocols). In particular, the transport of emergency call data blocks occurs within a SIP emergency dialog, per Section 7, and is @@ -1624,33 +1598,33 @@ 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 analyses, the SIP INFO method was chosen to provide for mid-call data transport. -14.8.3. Info Package Name +14.7.3. Info Package Name The SIP INFO package name is emergencyCallData.eCall.VEDS -14.8.4. Info Package Parameters +14.7.4. Info Package Parameters None -14.8.5. SIP Option-Tags +14.7.5. SIP Option-Tags None -14.8.6. INFO Request Body Parts +14.7.6. INFO Request Body Parts The body of an emergencyCallData.eCall.VEDS SIP INFO package is a multipart body which MAY contain zero or one application/ emergencyCallData.eCall.VEDS+xml (containing a VEDS data block) part, zero or more application/emergencyCallData.control+xml (containing a metadata/control object) parts, and zero or one application/ emergencyCallData.eCall.MSD+per (containing an MSD) part. At least one VEDS, MSD, or metadata/control body part is expected; the behavior upon receiving a SIP INFO request with none is undefined. @@ -1666,52 +1640,52 @@ Content-ID as a SIP header field is not defined (while it is defined for use as a MIME header field). The innermost multipart that contains only body parts associated with the SIP INFO package has a Content-Disposition value of Info-Package. Service providers are not expected to add [RFC7852] Additional Data to SIP INFO requests. See [TBD: THIS DOCUMENT] for more information. -14.8.7. Info Package Usage Restrictions +14.7.7. Info Package Usage Restrictions Usage is limited to vehicle-initiated emergency calls as defined in [TBD: THIS DOCUMENT]. -14.8.8. Rate of INFO Requests +14.7.8. Rate of INFO Requests The SIP INFO request is used within an established emergency call dialog for the PSAP to request the IVS to send an updated data set, and for the IVS to send the requested data set. Because this is normally done only on manual request of the PSAP call taker (who suspects some aspect of the vehicle state has changed), the rate of SIP INFO requests associated with the emergencyCallData.eCall.VEDS SIP INFO package is normally quite low (most dialogs are likely to contain zero SIP INFO requests, while others can be expected to carry an occasional request). -14.8.9. Info Package Security Considerations +14.7.9. Info Package Security Considerations The MIME media type registations for the data blocks that can be carried using this SIP 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. -14.8.10. Implementation Details +14.7.10. Implementation Details See [TBD: THIS DOCUMENT] for protocol details. -14.8.11. Examples +14.7.11. Examples See [TBD: THIS DOCUMENT] for protocol examples. 15. Acknowledgements We would like to thank Lena Chaponniere, Alissa Cooper, Stephen Edge, Christer Holmberg, Allison Mankin, and Dan Romascanu for their review and suggestions; Robert Sparks and Paul Kyzivat for their help with the SIP mechanisms; Michael Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex Buddenberg for their feedback;