< draft-ietf-ecrit-car-crash-10.txt   draft-ietf-ecrit-car-crash-11.txt >
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Core Technology Consulting Internet-Draft Core Technology Consulting
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: March 25, 2017 NeuStar, Inc. Expires: March 26, 2017 NeuStar, Inc.
H. Tschofenig H. Tschofenig
Individual Individual
September 21, 2016 September 22, 2016
Next-Generation Vehicle-Initiated Emergency Calls Next-Generation Vehicle-Initiated Emergency Calls
draft-ietf-ecrit-car-crash-10.txt draft-ietf-ecrit-car-crash-11.txt
Abstract Abstract
This document describes how to use IP-based emergency services This document describes how to use IP-based emergency services
mechanisms to support the next generation of emergency calls placed mechanisms to support the next generation of emergency calls placed
by vehicles (automatically in the event of a crash or serious by vehicles (automatically in the event of a crash or serious
incident, or manually invoked by a vehicle occupant) and conveying incident, or manually invoked by a vehicle occupant) and conveying
vehicle, sensor, and location data related to the crash or incident. vehicle, sensor, and location data related to the crash or incident.
Such calls are often referred to as "Automatic Crash Notification" Such calls are often referred to as "Automatic Crash Notification"
(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2017. This Internet-Draft will expire on March 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 3, line 5
6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13
7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16
9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17 9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17
9.1. New values for the 'action' attribute' . . . . . . . . . 18 9.1. New values for the 'action' attribute' . . . . . . . . . 18
9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19 9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19
9.3. The <ack> element . . . . . . . . . . . . . . . . . . . . 19 9.3. The <ack> element . . . . . . . . . . . . . . . . . . . . 19
9.4. The <capabilities> element . . . . . . . . . . . . . . . 20 9.4. The <capabilities> element . . . . . . . . . . . . . . . 20
10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22 11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22
11.1. Overall Description . . . . . . . . . . . . . . . . . . 22 11.1. Overall Description . . . . . . . . . . . . . . . . . . 23
11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23 11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23
11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23 11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23
11.4. Info Package Parameters . . . . . . . . . . . . . . . . 23 11.4. Info Package Parameters . . . . . . . . . . . . . . . . 24
11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23 11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24
11.6. INFO Message Body Parts . . . . . . . . . . . . . . . . 23 11.6. INFO Message Body Parts . . . . . . . . . . . . . . . . 24
11.7. Info Package Usage Restrictions . . . . . . . . . . . . 24 11.7. Info Package Usage Restrictions . . . . . . . . . . . . 25
11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24 11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25
11.9. Info Package Security Considerations . . . . . . . . . . 25 11.9. Info Package Security Considerations . . . . . . . . . . 25
11.10. Implementation Details . . . . . . . . . . . . . . . . . 25 11.10. Implementation Details . . . . . . . . . . . . . . . . . 25
11.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 11.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15.1. MIME Content-type Registration for 15.1. MIME Content-type Registration for
'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32
15.2. Registration of the 'VEDS' entry in the Emergency Call 15.2. Registration of the 'VEDS' entry in the Emergency Call
Additional Data registry . . . . . . . . . . . . . . . . 33 Additional Data registry . . . . . . . . . . . . . . . . 33
15.3. New Action Values . . . . . . . . . . . . . . . . . . . 33 15.3. New Action Values . . . . . . . . . . . . . . . . . . . 33
15.4. Static Message Registry . . . . . . . . . . . . . . . . 34 15.4. Static Message Registry . . . . . . . . . . . . . . . . 34
15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35 15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35
15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36 15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
17. Changes from Previous Versions . . . . . . . . . . . . . . . 37 17. Changes from Previous Versions . . . . . . . . . . . . . . . 37
17.1. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 37 17.1. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 37
17.2. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 17.2. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
17.3. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 17.3. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38
17.4. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38 17.4. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38
17.5. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 17.5. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38
17.6. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38 17.6. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38
17.7. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38 17.7. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38
17.8. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 38 17.8. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
17.9. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 17.9. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
17.10. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 17.10. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
17.11. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39 17.11. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39
17.12. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 17.12. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39
17.13. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39 17.13. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 17.14. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39
18.1. Normative References . . . . . . . . . . . . . . . . . . 39 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
18.1. Normative References . . . . . . . . . . . . . . . . . . 40
18.2. Informative references . . . . . . . . . . . . . . . . . 41 18.2. Informative references . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document re-uses terminology defined in Section 3 of [RFC5012]. This document re-uses terminology defined in Section 3 of [RFC5012].
skipping to change at page 7, line 48 skipping to change at page 7, line 48
'Application' media type) with a sub-type starting with 'Application' media type) with a sub-type starting with
'EmergencyCallData.' 'EmergencyCallData.'
o An entry for the block is added to the Emergency Call Additional o An entry for the block is added to the Emergency Call Additional
Data Blocks sub-registry (established by [RFC7852]); the registry Data Blocks sub-registry (established by [RFC7852]); the registry
entry is the root of the MIME sub-type (not including the entry is the root of the MIME sub-type (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') 'EmergencyCallData' prefix and any suffix such as '+xml')
o A new INFO package is registered that permits carrying the new o A new INFO package is registered that permits carrying the new
content type and the metadata/control object (defined in content type and the metadata/control object (defined in
[I-D.ietf-ecrit-ecall]) in INFO messages. [I-D.ietf-ecrit-ecall]) in INFO requests.
Section 6 describes how VEDS 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 transported within NG-ACN calls. Section 7 describes how such calls
are placed. are placed.
These mechanisms are thus used to place emergency calls that are These mechanisms are thus used to place emergency calls that are
identifiable as ACN calls and that carry standardized crash data in identifiable as ACN calls and that carry standardized crash data in
an interoperable way. an interoperable way.
Calls by in-vehicle systems are placed using cellular networks, which Calls by in-vehicle systems are placed using cellular networks, which
skipping to change at page 9, line 6 skipping to change at page 9, line 6
technical aspects of [I-D.ietf-ecrit-ecall], which uses [RFC7852]; technical aspects of [I-D.ietf-ecrit-ecall], which uses [RFC7852];
this makes it straightforward to use a different data set while this makes it straightforward to use a different data set while
keeping other technical aspects unchanged. Hence, both NG-eCall and keeping other technical aspects unchanged. Hence, both NG-eCall and
the NG-ACN mechanism described here are compatible, differing the NG-ACN mechanism described here are compatible, differing
primarily in the specific data block that is sent (the eCall MSD in primarily in the specific data block that is sent (the eCall MSD in
the case of NG-eCall, and the APCO/NENA VEDS used in this document), the case of NG-eCall, and the APCO/NENA VEDS used in this document),
and some additions to the metadata/control data block. If other and some additions to the metadata/control data block. If other
regions adopt their own vehicle data sets, this can be similarly regions adopt their own vehicle data sets, this can be similarly
accomodated without changing other technical aspects. Note that any accomodated without changing other technical aspects. Note that any
additional data blocks require a new INFO package to permit transport additional data blocks require a new INFO package to permit transport
within INFO messages. within INFO requests.
4. Overview of Legacy Deployment Models 4. Overview of Legacy Deployment Models
Legacy (circuit-switched) systems for placing emergency calls by in- Legacy (circuit-switched) systems for placing emergency calls by in-
vehicle systems generally have some ability to convey at least vehicle systems generally have some ability to convey at least
location and in some cases telematics data to the PSAP. Most such location and in some cases telematics data to the PSAP. Most such
systems use one of three architectural models, which are described systems use one of three architectural models, which are described
here as: "Telematics Service Provider" (TSP), "direct", and "paired". here as: "Telematics Service Provider" (TSP), "direct", and "paired".
These three models are illustrated below. These three models are illustrated below.
skipping to change at page 13, line 20 skipping to change at page 13, line 20
+---+ +---+
///----\\\ (undefined) | H | standard +------+ ///----\\\ (undefined) | H | standard +------+
||| IVS |||------------------>| S +------------------->+ PSAP | ||| IVS |||------------------>| S +------------------->+ PSAP |
\\\----/// (undefined) +---+ crash + other data +------+ \\\----/// (undefined) +---+ crash + other data +------+
Figure 6: Next-Generation Paired Model Figure 6: Next-Generation Paired Model
If the call is routed to a PSAP that is not capable of processing the If the call is routed to a PSAP that is not capable of processing the
vehicle data, the PSAP ignores (or does not receive) the vehicle vehicle data, the PSAP ignores (or does not receive) the vehicle
data. This is detectable by the IVS or TSP when the status response data. This is detectable by the IVS or TSP when the status response
to the INVITE (e.., 200 OK) lacks an eCall control structure to the INVITE (e.., 200 OK) lacks a control structure acknowledging
acknowledging receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or TSP then
TSP then proceeds as it would for a CS-ACN call (e.g., verbal proceeds as it would for a CS-ACN call (e.g., verbal conveyance of
conveyance of data) data)
6. Data Transport 6. Data Transport
[RFC7852] establishes a general mechanism for attaching blocks of [RFC7852] establishes a general mechanism for attaching blocks of
data to a SIP emergency call. This mechanism permits certain data to a SIP emergency call. This mechanism permits certain
emergency call MIME types to be attached to SIP messages. This emergency call MIME types to be attached to SIP messages. This
document makes use of that mechanism. This document also registers document makes use of that mechanism. This document also registers
an INFO package (in Section 11) to enable NG-ACN related data blocks an INFO package (in Section 11) to enable NG-ACN related data blocks
to be carried in INFO messages. to be carried in SIP INFO requests (per [RFC6086], new INFO usages
require the definition of an INFO package).
An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS]) 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]. 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/ The body part is identified by its MIME content-type ('application/
emergencyCallData.eCall.VEDS+xml') in the Content-Type header field emergencyCallData.eCall.VEDS+xml') in the Content-Type header field
of the body part. The body part is assigned a unique identifier 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 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 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 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 message. This Call-Info header field contains a CID URL referencing
the body part's unique identifier, and a 'purpose' parameter the body part's unique identifier, and a 'purpose' parameter
identifying the data as a VEDS data block per the Emergency Call identifying the data as a VEDS data block per the Emergency Call
Additional Data Blocks registry entry; the 'purpose' parameter's Additional Data Blocks registry entry; the 'purpose' parameter's
value is 'emergencyCallData.VEDS'. The body part has a Content- value is 'emergencyCallData.VEDS'. A VEDS data block is carried in a
Disposition header field value of "By-Reference; handling=optional". SIP INFO request by using the INFO package defined in Section 11.
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 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 [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 body part per [RFC7852]. The body part is identified by its MIME
content-type ('application/emergencyCallData.eCall.control+xml') in content-type ('application/emergencyCallData.control+xml') in the
the Content-Type header field of the body part. The body part is Content-Type header field of the body part. The body part is
assigned a unique identifier which is listed in a Content-ID header 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 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 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 at the top level of the SIP message. This Call-Info header
field contains a CID URL referencing the body part's unique field contains a CID URL referencing the body part's unique
identifier, and a 'purpose' parameter identifying the data as a identifier, and a 'purpose' parameter identifying the data as a
metadata/control block per the Emergency Call Additional Data Blocks metadata/control block per the Emergency Call Additional Data Blocks
registry entry; the 'purpose' parameter's value is registry entry; the 'purpose' parameter's value is
'emergencyCallData.eCall.control'. The body part has a Content- 'emergencyCallData.control'. A metadata/control object is carried in
Disposition header field value of "By-Reference; handling=optional". a SIP INFO request by using the INFO package defined in Section 11.
A metadata/control object is carried in an INFO message by using the
INFO package registration (defined in Section 11). As is necessary with message bodies, if a VEDS or a metadata/control
block is sent in the same message with another body part, a
multipart/mixed body part encloses all body parts. In some cases,
there are intermediate multipart body parts between the top level
multipart/mixed and the body part containing the VEDS or metadata/
control object.
A body part containing a VEDS or metadata/control object has a
Content-Disposition header field value containing "By-Reference"
unless it is the only body part in a SIP INFO request, in which case,
per [RFC6086], "INFO-Package" is used.
An In-Vehicle System (IVS) initiating an NG-ACN call includes in the An In-Vehicle System (IVS) initiating an NG-ACN call includes in the
initial INVITE a VEDS data block and a metadata/control object initial INVITE a VEDS data block and a metadata/control object
informing the PSAP of its capabilities. The PSAP creates a metadata/ informing the PSAP of its capabilities. The VEDS and metadata/
control body parts (and PIDF-LO) have a Content-Disposition header
field with the value "By-Reference; handling=optional". Specifying
handling=optional prevents the INVITE from being rejected if it is
processed by a legacy element (e.g., a gateway between SIP and
circuit-switched environments) that does not understand the VEDS or
metadata/control (or PIDF-LO) objects. The PSAP creates a metadata/
control object acknowledging receipt of the VEDS data and includes it control object acknowledging receipt of the VEDS data and includes it
in the SIP final response to the INVITE. in the SIP final response to the INVITE. The metadata/control object
is not attached to provisional (e.g., 180) responses.
If the IVS receives an acknowledgment for a VEDS data object with
received=false, it indicates some fault with the transfer of the
VEDS, the VEDS content, or the PSAP's ability to properly receive,
decode and act on the VEDS. The IVS action is not defined (e.g., it
might only log an error). Since the PSAP is able to request an
updated VEDS during the call, if an initial VEDS is unsatisfactory in
any way, the PSAP can choose to request another one.
A PSAP can request that the vehicle send an updated VEDS data block 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 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 requesting VEDS data and attaches it to a SIP INFO request and sends
sends within the dialog. The IVS then attaches an updated VEDS data it within the dialog. The IVS then attaches an updated VEDS data
object to a SIP INFO message and sends it within the dialog. The object to a SIP INFO request and sends it within the dialog. If the
metadata/control object and the VEDS data are both associated with IVS is unable to send the VEDS, it instead sends a metadata/control
the INFO package registered by this document (in Section 11), and object acknowledging the request with the 'success' parameter set to
hence sent per [RFC6086]. In addition, to align with the way a VEDS 'false' and a 'reason' parameter (and optionally a 'details'
or metadata/control block is transmitted in a non-INFO message, one parameter) indicating why the request cannot be accomplished. Per
or more Call-Info header fields are included in the INFO message to [RFC6086], metadata/control objects and VEDS data are sent using the
reference the VEDS or metadata/control block. If the body part INFO package defined in Section 11. In addition, to align with the
containing the VEDS or metadata/control block is the only body part way a VEDS or metadata/control block is transmitted in a SIP message
in the INFO, it has a Content-Disposition header field value of other than an INFO request, one or more Call-Info header fields are
"Info-Package; handling=optional". If it is contained within a included in the SIP INFO request to reference the VEDS or metadata/
multipart body part, it has a Content-Disposition header field value control block. See Section 11 for more information on the use of
of "By-Reference; handling=optional". See Section 11 for more INFO requests within NG-ACN calls.
information.
If the IVS is aware that the VEDS data it sent previously has If the IVS is aware that VEDS data it sent previously has changed, it
changed, it MAY send an unsolicited MSD (in any convenient SIP MAY send an unsolicited VEDS (in any convenient SIP message,
message, including an INFO) during the call. The PSAP sends an including an INFO request) during the call. The PSAP sends an
acknowledgment of an unsolicited VEDS object (if the IVS sent the acknowledgment of an unsolicited VEDS object (if the IVS sent the
unsolicited VEDS in an INFO, the acknowledgment is sent in a new unsolicited VEDS in an INFO request, the acknowledgment is sent in a
INFO, otherwise it is sent in the response to the message containing new INFO request, otherwise it is sent in the response to the message
the VEDS). 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 7. Call Setup
A next-generation In-Vehicle System (IVS) initiates an NG-ACN call A next-generation In-Vehicle System (IVS) initiates an NG-ACN call
with a SIP INVITE using one of the SOS sub-services with a SIP INVITE using one of the SOS sub-services
"SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI, "SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI,
standard sets of crash data and capabilities data encoded in standard sets of crash data and capabilities data encoded in
standardized and registered formats, attached as additional data standardized and registered formats, attached as additional data
blocks as specified in Section 4.1 of [RFC7852]. As described in blocks as specified in Section 4.1 of [RFC7852]. As described in
that document, each data block is identified by its MIME content- that document, each data block is identified by its MIME content-
skipping to change at page 19, line 7 skipping to change at page 19, line 26
enable-camera adds a one-way media stream (established via SIP re- 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 INVITE sent by the vehicle) to enable the PSAP call taker to view
a feed from a camera. a feed from a camera.
Note that there is no 'request' action to play dynamic media (such as 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 an audio message). The PSAP can send a SIP re-INVITE to establish a
one-way media stream for this purpose. one-way media stream for this purpose.
9.2. Request Example 9.2. Request Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl <EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData: xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
eCall:control">
<request action="send-data" datatype="VEDS"/> <request action="send-data" datatype="VEDS"/>
<request action="lamp" lamp-id="hazard" <request action="lamp" lamp-id="hazard"
lamp-action="flash" persistance="PT1H"/> lamp-action="flash" persistance="PT1H"/>
<request action="msg-static" msgid="1"/> <request action="msg-static" msgid="1"/>
<request action="msg-dynamic"> <request action="msg-dynamic">
<text>Remain calm. Help is on the way.</text> <text>Remain calm. Help is on the way.</text>
</request> </request>
</EmergencyCallData.eCallControl> </EmergencyCallData.eCallControl>
Figure 7: Request Example Figure 7: Request Example
9.3. The <ack> element 9.3. The <ack> element
In [I-D.ietf-ecrit-ecall], the <ack> element is transmitted by the In [I-D.ietf-ecrit-ecall], the <ack> element is transmitted by the
PSAP to acknowledge the MSD. Here, the <ack> element is also PSAP to acknowledge the MSD. Here, the <ack> element is also
transmitted by the PSAP to acknowledge the VEDS data and by the IVS transmitted by the PSAP to acknowledge the VEDS data and by the IVS
to acknowledge receipt of a <request> element that requested the IVS to acknowledge receipt of a <request> element that requested the IVS
to perform an action other than transmitting a data object (e.g., a to perform an action other than transmitting a data object (e.g., a
request to display a message would be acknowledged, but a request to request to display a message would be acknowledged, but a request to
transmit VEDS data would not result in a separate <ack> element being transmit VEDS data would not result in a separate <ack> element being
sent, since the data object itself serves as acknowledgment.) An sent, since the data object itself serves as acknowledgment.) An
<ack> element sent by an IVS references the unique ID of the <ack> element sent by an IVS references the unique ID of the
metadata/control object containing the request(s) and indicates metadata/control object containing the request(s) and indicates
whether the request was successfully performed, and if not, whether the request was successfully performed, and if not,
optionally includes an explanation. optionally includes an explanation.
9.3.1. Ack Examples 9.3.1. Ack Examples
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:
eCall:control">
<ack ref="1234567890@atlanta.example.com"> <?xml version="1.0" encoding="UTF-8"?>
<actionResult action="msg-dynamic" success="true"/> <EmergencyCallData.eCallControl
<actionResult action="lamp" success="false" reason="unable" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
details="The requested lamp is inoperable"/> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
</ack> xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
</EmergencyCallData.eCallControl> <ack ref="1234567890@atlanta.example.com">
<actionResult action="msg-dynamic" success="true"/>
<actionResult action="lamp" success="false" reason="unable"
details="The requested lamp is inoperable"/>
</ack>
</EmergencyCallData.eCallControl>
Figure 8: Ack Example from IVS to PSAP Figure 8: Ack Example from IVS to PSAP
9.4. The <capabilities> element 9.4. The <capabilities> element
The <capabilities> element ([I-D.ietf-ecrit-ecall]) is transmitted by The <capabilities> element ([I-D.ietf-ecrit-ecall]) is transmitted by
the IVS to indicate its capabilities to the PSAP. the IVS to indicate its capabilities to the PSAP.
The <capabilities> element contains a <request> child element per The <capabilities> element contains a <request> child element per
action supported by the vehicle. The vehicle MUST support sending action supported by the vehicle. The vehicle MUST support sending
skipping to change at page 21, line 9 skipping to change at page 21, line 21
If the "enable-camera" action is supported, a <request> child element If the "enable-camera" action is supported, a <request> child element
with the 'action' attribute set to "enable-camera" is included, with with the 'action' attribute set to "enable-camera" is included, with
the 'supported-values' attribute set to all supported camera IDs. A the 'supported-values' attribute set to all supported camera IDs. A
registry is created in Section 15.6 to contain camera ID values. registry is created in Section 15.6 to contain camera ID values.
9.4.1. Capabilities Example 9.4.1. Capabilities Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl <EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData: xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
eCall:control">
<capabilities> <capabilities>
<request action="send-data" supported-values="VEDS"/> <request action="send-data" supported-values="VEDS"/>
<request action="lamp" <request action="lamp"
supported-values="head;interior;fog-front;fog-rear;brake; supported-values="head;interior;fog-front;fog-rear;brake;
position-front;position-rear;turn-left;turn-right;hazard"/> position-front;position-rear;turn-left;turn-right;hazard"/>
<request action="msg-static" msgid="3"/> <request action="msg-static" msgid="3"/>
<request action="msg-dynamic"/> <request action="msg-dynamic"/>
<request action="honk"/> <request action="honk"/>
<request action="enable-camera" supported-values="backup; interior"/> <request action="enable-camera" supported-values="backup; interior"/>
skipping to change at page 24, line 5 skipping to change at page 24, line 20
None None
11.6. INFO Message Body Parts 11.6. INFO Message Body Parts
The body for an emergencyCallData.eCall.VEDS info package is: The body for an emergencyCallData.eCall.VEDS info package is:
o an application/emergencyCallData.eCall.VEDS+xml (containing a VEDS o an application/emergencyCallData.eCall.VEDS+xml (containing a VEDS
data block), or data block), or
o an application/emergencyCallData.eCall.control+xml (containing a o an application/emergencyCallData.control+xml (containing a
metadata/control object), or metadata/control object), or
o an application/emergencyCallData.eCall.MSD+per (containing an o an application/emergencyCallData.eCall.MSD+per (containing an
MSD), or MSD), or
o a multipart body containing: o a multipart body containing:
* zero or one application/emergencyCallData.eCall.VEDS+xml part * zero or one application/emergencyCallData.eCall.VEDS+xml part
(containing a VEDS data block), (containing a VEDS data block),
* zero or more application/emergencyCallData.eCall.control+xml * zero or more application/emergencyCallData.control+xml
(containing a metadata/control object), (containing a metadata/control object),
* zero or one application/emergencyCallData.eCall.MSD+per part * zero or one application/emergencyCallData.eCall.MSD+per part
(containing an MSD), (containing an MSD),
The body parts are sent per [RFC6086], and in addition, to align with 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 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 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 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- part, it has a Content-Disposition header field value of "INFO-
Package; handling=optional". If the body part is contained within a Package". If the body part is contained within a multipart, it has a
multipart body part, it has a Content-Disposition header field value Content-Disposition header field value of "By-Reference".
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 Service providers are not expected to attach [RFC7852] Additional
Data to an INFO request. Data to an INFO request.
See [TBD: THIS DOCUMENT] for more information. See [TBD: THIS DOCUMENT] for more information.
11.7. Info Package Usage Restrictions 11.7. Info Package Usage Restrictions
Usage is limited to vehicle-initiated emergency calls as defined in Usage is limited to vehicle-initiated emergency calls as defined in
[TBD: THIS DOCUMENT]. [TBD: THIS DOCUMENT].
skipping to change at page 27, line 29 skipping to change at page 27, line 29
In addition to the information about the vehicle, further indications In addition to the information about the vehicle, further indications
are provided, namely the presence of fuel leakage are provided, namely the presence of fuel leakage
('FuelLeakingIndicator' element), an indication whether the vehicle ('FuelLeakingIndicator' element), an indication whether the vehicle
was subjected to multiple impacts ('MultipleImpactsIndicator' was subjected to multiple impacts ('MultipleImpactsIndicator'
element), the orientation of the vehicle at final rest element), the orientation of the vehicle at final rest
('VehicleFinalRestOrientationCategoryCode' element) and an indication ('VehicleFinalRestOrientationCategoryCode' element) and an indication
that there are no parts of the vehicle on fire (the that there are no parts of the vehicle on fire (the
'VehicleFireIndicator' element). 'VehicleFireIndicator' element).
INVITE urn:service:sos.ecall.automatic SIP/2.0 INVITE urn:service:sos.ecall.automatic SIP/2.0
To: urn:service:sos.ecall.automatic To: urn:service:sos.ecall.automatic
From: <sip:+13145551111@example.com>;tag=9fxced76sl From: <sip:+13145551111@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@example.com> Geolocation: <cid:target123@example.com>
Geolocation-Routing: no Geolocation-Routing: no
Call-Info: <cid:1234567890@atlanta.example.com>; Call-Info: <cid:1234567890@atlanta.example.com>;
purpose=EmergencyCallData.VEDS purpose=EmergencyCallData.VEDS
Call-Info: <cid:1234567892@atlanta.example.com>; Call-Info: <cid:1234567892@atlanta.example.com>;
purpose=EmergencyCallData.ecall.control purpose=emergencyCallData.control
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.eCall.control+xml application/emergencyCallData.control+xml
Recv-Info: emergencyCallData.eCall Recv-Info: emergencyCallData.eCall
Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
SUBSCRIBE, NOTIFY, UPDATE SUBSCRIBE, NOTIFY, UPDATE
CSeq: 31862 INVITE CSeq: 31862 INVITE
Content-Disposition: info-package Content-Type: multipart/mixed; boundary=boundary1
Content-Transfer-Encoding: binary Content-Length: ...
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...Session Description Protocol (SDP) goes here
--boundary1 ...Session Description Protocol (SDP) goes here
Content-Type: application/pidf+xml --boundary1
Content-ID: <target123@atlanta.example.com> Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic" xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="sip:+13145551111@example.com"> entity="sip:+13145551111@example.com">
<dm:device id="123"> <dm:device id="123">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos> <gml:pos>-34.407 150.883</gml:pos>
</gml:Point> </gml:Point>
<dyn:Dynamic> <dyn:Dynamic>
<dyn:heading>278</dyn:heading> <dyn:heading>278</dyn:heading>
<dyn:direction><dyn:direction> <dyn:direction><dyn:direction>
</dyn:Dynamic> </dyn:Dynamic>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>gps</method> <method>gps</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2012-04-5T10:18:29Z</timestamp> <timestamp>2012-04-5T10:18:29Z</timestamp>
<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID> <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.VEDS+xml Content-Type: application/EmergencyCallData.VEDS+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<AutomatedCrashNotification xmlns="http://www.veds.org/acn/1.0" <AutomatedCrashNotification xmlns="http://www.veds.org/acn/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Crash> <Crash>
<CrashVehicle> <CrashVehicle>
<ItemMakeName xmlns="http://niem.gov/niem/niem-core/2.0"> <ItemMakeName xmlns="http://niem.gov/niem/niem-core/2.0">
Saab Saab
</ItemMakeName> </ItemMakeName>
<ItemModelName xmlns="http://niem.gov/niem/niem-core/2.0"> <ItemModelName xmlns="http://niem.gov/niem/niem-core/2.0">
9-5 9-5
</ItemModelName> </ItemModelName>
<ItemModelYearDate <ItemModelYearDate
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
2015 2015
</ItemModelYearDate> </ItemModelYearDate>
<Airbag> <Airbag>
<AirbagCategoryCode>FRONT</AirbagCategoryCode> <AirbagCategoryCode>FRONT</AirbagCategoryCode>
<AirbagDeployedIndicator>true <AirbagDeployedIndicator>true
</AirbagDeployedIndicator> </AirbagDeployedIndicator>
</Airbag> </Airbag>
<ConvertibleIndicator>false</ConvertibleIndicator> <ConvertibleIndicator>false</ConvertibleIndicator>
<PowerSourceCategoryCode>MAIN</PowerSourceCategoryCode> <PowerSourceCategoryCode>MAIN</PowerSourceCategoryCode>
<VehicleBodyCategoryCode <VehicleBodyCategoryCode
xmlns="http://niem.gov/niem/domains/jxdm/4.1"> xmlns="http://niem.gov/niem/domains/jxdm/4.1">
101 101
</VehicleBodyCategoryCode> </VehicleBodyCategoryCode>
<VehicleCrashPulse> <VehicleCrashPulse>
<CrashPulseChangeInVelocityMeasure> <CrashPulseChangeInVelocityMeasure>
<MeasurePointValue <MeasurePointValue
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
100 100
</MeasurePointValue> </MeasurePointValue>
<MeasureUnitText <MeasureUnitText
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
MPH</MeasureUnitText> MPH</MeasureUnitText>
</CrashPulseChangeInVelocityMeasure> </CrashPulseChangeInVelocityMeasure>
<CrashPulsePrincipalDirectionOfForceValue>12 <CrashPulsePrincipalDirectionOfForceValue>12
</CrashPulsePrincipalDirectionOfForceValue> </CrashPulsePrincipalDirectionOfForceValue>
<CrashPulseRolloverQuarterTurnsValue>1 <CrashPulseRolloverQuarterTurnsValue>1
</CrashPulseRolloverQuarterTurnsValue> </CrashPulseRolloverQuarterTurnsValue>
</VehicleCrashPulse> </VehicleCrashPulse>
<VehicleRollbarDeployedIndicator>false <VehicleRollbarDeployedIndicator>false
</VehicleRollbarDeployedIndicator> </VehicleRollbarDeployedIndicator>
<VehicleSeat> <VehicleSeat>
<VehicleSeatLocationCategoryCode>1 <VehicleSeatLocationCategoryCode>1
</VehicleSeatLocationCategoryCode> </VehicleSeatLocationCategoryCode>
<VehicleSeatOccupiedIndicator>true <VehicleSeatOccupiedIndicator>true
</VehicleSeatOccupiedIndicator> </VehicleSeatOccupiedIndicator>
<VehicleSeatbeltFastenedIndicator>true <VehicleSeatbeltFastenedIndicator>true
</VehicleSeatbeltFastenedIndicator> </VehicleSeatbeltFastenedIndicator>
<VehicleSeatbeltMonitoredIndicator>true <VehicleSeatbeltMonitoredIndicator>true
</VehicleSeatbeltMonitoredIndicator> </VehicleSeatbeltMonitoredIndicator>
</VehicleSeat> </VehicleSeat>
<VehicleUnladenWeightMeasure <VehicleUnladenWeightMeasure
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
<MeasurePointValue <MeasurePointValue
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
600 600
</MeasurePointValue> </MeasurePointValue>
<MeasureUnitText <MeasureUnitText
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
kilogram kilogram
</MeasureUnitText> </MeasureUnitText>
</VehicleUnladenWeightMeasure> </VehicleUnladenWeightMeasure>
</CrashVehicle> </CrashVehicle>
<FuelLeakingIndicator>true</FuelLeakingIndicator> <FuelLeakingIndicator>true</FuelLeakingIndicator>
<MultipleImpactsIndicator>false</MultipleImpactsIndicator> <MultipleImpactsIndicator>false</MultipleImpactsIndicator>
<SevereInjuryIndicator>true</SevereInjuryIndicator> <SevereInjuryIndicator>true</SevereInjuryIndicator>
<VehicleFinalRestOrientationCategoryCode>Driver <VehicleFinalRestOrientationCategoryCode>Driver
</VehicleFinalRestOrientationCategoryCode> </VehicleFinalRestOrientationCategoryCode>
<VehicleFireIndicator>false</VehicleFireIndicator> <VehicleFireIndicator>false</VehicleFireIndicator>
</Crash> </Crash>
</AutomatedCrashNotification> </AutomatedCrashNotification>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.ecall.control+xml Content-Type: application/emergencyCallData.control+xml
Content-ID: <1234567892@atlanta.example.com> Content-ID: <1234567892@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl <EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData: xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
eCall:control">
<capabilities> <capabilities>
<request action="send-data" supported-datatypes="VEDS"/> <request action="send-data" supported-datatypes="VEDS"/>
<request action="lamp" <request action="lamp"
supported-values="head;interior;fog-front;fog-rear; supported-values="head;interior;fog-front;fog-rear;
brake;position-front;position-rear;turn-left; brake;position-front;position-rear;turn-left;
turn-right;hazard"/> turn-right;hazard"/>
<request action="msg-static" msgid="3"/> <request action="msg-static" msgid="3"/>
<request action="msg-dynamic"/> <request action="msg-dynamic"/>
<request action="honk"/> <request action="honk"/>
<request action="enable-camera" <request action="enable-camera"
supported-values="backup; interior"/> supported-values="backup; interior"/>
</capabilities> </capabilities>
</EmergencyCallData.eCallControl> </EmergencyCallData.eCallControl>
--boundary1-- --boundary1--
Figure 11: SIP INVITE indicating a Vehicule-Initated Emergency Call Figure 11: SIP INVITE for a Vehicle-Initated Emergency Call
13. Security Considerations 13. Security Considerations
Since this document relies on [I-D.ietf-ecrit-ecall] and [RFC7852], Since this document relies on [I-D.ietf-ecrit-ecall] and [RFC7852],
the security considerations described there and in [RFC5069] apply the security considerations described there and in [RFC5069] apply
here. Implementors are cautioned to read and understand the here. Implementors are cautioned to read and understand the
discussion in those documents. discussion in those documents.
As with emergency service systems where location data is supplied or As with emergency service systems where location data is supplied or
determined with the assistance of an end host, there is the determined with the assistance of an end host, there is the
skipping to change at page 36, line 45 skipping to change at page 36, line 45
This document creates a new sub-registry called "Camera ID Registry" This document creates a new sub-registry called "Camera ID Registry"
in the "Metadata/Control Data" registry established by in the "Metadata/Control Data" registry established by
[I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies [I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies
automotive cameras. As defined in [RFC5226], this registry operates automotive cameras. As defined in [RFC5226], this registry operates
under "Expert Review" rules. The expert should determine that the under "Expert Review" rules. The expert should determine that the
proposed camera name is clearly understandable and is sufficiently proposed camera name is clearly understandable and is sufficiently
distinguishable from other camera names. distinguishable from other camera names.
The contents of this registry are: The contents of this registry are:
Name: The identifier to be used in the 'camera-ID' attribute of an Name: The identifier to be used in the 'camera-ID' attribute of a
eCall control <request> element. control <request> element.
Description: A description of the camera. Description: A description of the camera.
The initial set of values is listed in Table 5. The initial set of values is listed in Table 5.
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Name | Description | | Name | Description |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| backup | Shows what is behind the vehicle, e.g., often used | | backup | Shows what is behind the vehicle, e.g., often used |
| | for driver display when the vehicle is in reverse. | | | for driver display when the vehicle is in reverse. |
skipping to change at page 37, line 38 skipping to change at page 37, line 38
| interior | Shows the interior (e.g., driver) | | interior | Shows the interior (e.g., driver) |
| | | | | |
| night-front | Night-vision view of what is in front of the | | night-front | Night-vision view of what is in front of the |
| | vehicle | | | vehicle |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
Table 5: Camera ID Registry Initial Values Table 5: Camera ID Registry Initial Values
16. Acknowledgements 16. Acknowledgements
We would like to thank Christer Holmberg for his suggestions; Michael We would like to thank Lena Chaponniere, Stephen Edge, and Christer
Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, Holmberg for their review and suggestions; Robert Sparks and Paul
and Rex Buddenberg for their feedback; and Ulrich Dietz for his help Kyzivat for their help with the SIP mechanisms; Michael Montag,
with earlier versions of the original version of this document. 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. Changes from Previous Versions
17.1. Changes from draft-ietf-09 to draft-ietf-10 17.1. Changes from draft-ietf-10 to draft-ietf-11
o Clarifications suggested by Christer
o Corrections to Content-Disposition text and examples as suggested
by Paul Kyzivat
o Clarifications to Content-Disposition text and examples to clarify
that handling=optional is only used in the initial INVITE
17.2. Changes from draft-ietf-09 to draft-ietf-10
o Fixed errors in examples found by Dale in eCall draft o Fixed errors in examples found by Dale in eCall draft
o Removed enclosing sub-section of INFO package registration section o Removed enclosing sub-section of INFO package registration section
o Added text per Christer and Dale's suggestions that the MSD and 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 metadata/control blocks are sent in INFO with a Call-Info header
field referencing them field referencing them
o Other text changes per comments received from Christer and Ivo o Other text changes per comments received from Christer and Ivo
against eCall draft. against eCall draft.
17.2. Changes from draft-ietf-08 to draft-ietf-09 17.3. Changes from draft-ietf-08 to draft-ietf-09
o Added INFO package registration for eCall.VEDS o Added INFO package registration for eCall.VEDS
o Moved <capabilities> element and other extension points back to o Moved <capabilities> element and other extension points back to
eCall document so that extension points are in base spec (and also eCall document so that extension points are in base spec (and also
to get XML schema to compile) to get XML schema to compile)
o Text changes for clarification. o Text changes for clarification.
17.3. Changes from draft-ietf-07 to draft-ietf-08 17.4. Changes from draft-ietf-07 to draft-ietf-08
o Moved much of the metadata/control object from o Moved much of the metadata/control object from
[I-D.ietf-ecrit-ecall] to this document as extensions [I-D.ietf-ecrit-ecall] to this document as extensions
o Editorial clarifications and simplifications o Editorial clarifications and simplifications
o Moved "Call Routing" to be a subsection of "Call Setup" o Moved "Call Routing" to be a subsection of "Call Setup"
o Deleted "Profile" section and moved some of its text into o Deleted "Profile" section and moved some of its text into
"Introduction" "Introduction"
17.4. Changes from draft-ietf-06 to draft-ietf-07 17.5. Changes from draft-ietf-06 to draft-ietf-07
o Minor editorial changes o Minor editorial changes
17.5. Changes from draft-ietf-05 to draft-ietf-06 17.6. Changes from draft-ietf-05 to draft-ietf-06
o Added clarifying text regarding signed and encrypted data o Added clarifying text regarding signed and encrypted data
o Additional informative text in "Migration to Next-Generation" o Additional informative text in "Migration to Next-Generation"
section section
o Additional clarifying text regarding security and privacy. o Additional clarifying text regarding security and privacy.
17.6. Changes from draft-ietf-04 to draft-ietf-05 17.7. Changes from draft-ietf-04 to draft-ietf-05
o Reworded security text in main document and in MIME registration o Reworded security text in main document and in MIME registration
for the VEDS object for the VEDS object
17.7. Changes from draft-ietf-03 to draft-ietf-04 17.8. Changes from draft-ietf-03 to draft-ietf-04
o Added example VEDS object o Added example VEDS object
o Additional clarifications and corrections o Additional clarifications and corrections
o Removed references from Abstract o Removed references from Abstract
o Moved Document Scope section to follow Introduction o Moved Document Scope section to follow Introduction
17.8. Changes from draft-ietf-02 to draft-ietf-03 17.9. Changes from draft-ietf-02 to draft-ietf-03
o Additional clarifications and corrections o Additional clarifications and corrections
17.9. Changes from draft-ietf-01 to draft-ietf-02 17.10. Changes from draft-ietf-01 to draft-ietf-02
o This document now refers to [I-D.ietf-ecrit-ecall] for technical o This document now refers to [I-D.ietf-ecrit-ecall] for technical
aspects including the service URN; this document no longer aspects including the service URN; this document no longer
proposes a unique service URN for non-eCall NG-ACN calls; the same 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 service URN is now used for all NG-ACN calls including NG-eCall
and non-eCall and non-eCall
o Added discussion of an NG-ACN call placed to a PSAP that doesn't o Added discussion of an NG-ACN call placed to a PSAP that doesn't
support it support it
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
17.10. Changes from draft-ietf-00 to draft-ietf-01 17.11. Changes from draft-ietf-00 to draft-ietf-01
o Added further discussion of test calls o Added further discussion of test calls
o Added further clarification to the document scope o Added further clarification to the document scope
o Mentioned that multi-region vehicles may need to support other o Mentioned that multi-region vehicles may need to support other
crash notification specifications such as eCall crash notification specifications such as eCall
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
17.11. Changes from draft-gellens-02 to draft-ietf-00 17.12. Changes from draft-gellens-02 to draft-ietf-00
o Renamed from draft-gellens- to draft-ietf- o Renamed from draft-gellens- to draft-ietf-
o Added text to Introduction to clarify that during a CS ACN, the 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 PSAP call taker usually needs to listen to the data and transcribe
it it
17.12. Changes from draft-gellens-01 to -02 17.13. Changes from draft-gellens-01 to -02
o Fixed case of 'EmergencyCallData', in accordance with changes to o Fixed case of 'EmergencyCallData', in accordance with changes to
[RFC7852] [RFC7852]
17.13. Changes from draft-gellens-00 to -01 17.14. Changes from draft-gellens-00 to -01
o Now using 'EmergencyCallData' for purpose parameter values and o Now using 'EmergencyCallData' for purpose parameter values and
MIME subtypes, in accordance with changes to [RFC7852] MIME subtypes, in accordance with changes to [RFC7852]
o Added reference to RFC 6443 o Added reference to RFC 6443
o Fixed bug that caused Figure captions to not appear o Fixed bug that caused Figure captions to not appear
18. References 18. References
18.1. Normative References 18.1. Normative References
 End of changes. 59 change blocks. 
279 lines changed or deleted 303 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/