< draft-ietf-ecrit-car-crash-09.txt   draft-ietf-ecrit-car-crash-10.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: February 2, 2017 NeuStar, Inc. Expires: March 25, 2017 NeuStar, Inc.
H. Tschofenig H. Tschofenig
Individual Individual
August 1, 2016 September 21, 2016
Next-Generation Vehicle-Initiated Emergency Calls Next-Generation Vehicle-Initiated Emergency Calls
draft-ietf-ecrit-car-crash-09.txt draft-ietf-ecrit-car-crash-10.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 February 2, 2017. This Internet-Draft will expire on March 25, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 9
5. Migration to Next-Generation . . . . . . . . . . . . . . . . 10 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 10
6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13
7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16
9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 16 9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17
9.1. New values for the 'action' attribute' . . . . . . . . . 17 9.1. New values for the 'action' attribute' . . . . . . . . . 18
9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 18 9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19
9.3. The <ack> element . . . . . . . . . . . . . . . . . . . . 18 9.3. The <ack> element . . . . . . . . . . . . . . . . . . . . 19
9.4. The <capabilities> element . . . . . . . . . . . . . . . 19 9.4. The <capabilities> element . . . . . . . . . . . . . . . 20
10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 21 11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22
11.1. INFO Package Requirements . . . . . . . . . . . . . . . 22 11.1. Overall Description . . . . . . . . . . . . . . . . . . 22
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 11.4. Info Package Parameters . . . . . . . . . . . . . . . . 23
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 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 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 15.2. Registration of the 'VEDS' entry in the Emergency Call
Additional Data registry . . . . . . . . . . . . . . . . 31 Additional Data registry . . . . . . . . . . . . . . . . 33
15.3. New Action Values . . . . . . . . . . . . . . . . . . . 32 15.3. New Action Values . . . . . . . . . . . . . . . . . . . 33
15.4. Static Message Registry . . . . . . . . . . . . . . . . 32 15.4. Static Message Registry . . . . . . . . . . . . . . . . 34
15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 33 15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35
15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 34 15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
17. Changes from Previous Versions . . . . . . . . . . . . . . . 35 17. Changes from Previous Versions . . . . . . . . . . . . . . . 37
17.1. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 35 17.1. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 37
17.2. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 36 17.2. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38
17.3. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 36 17.3. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38
17.4. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 36 17.4. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38
17.5. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 36 17.5. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38
17.6. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 36 17.6. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38
17.7. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 36 17.7. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38
17.8. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 36 17.8. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 38
17.9. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 37 17.9. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
17.10. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 37 17.10. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39
17.11. Changes from draft-gellens-01 to -02 . . . . . . . . . . 37 17.11. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39
17.12. Changes from draft-gellens-00 to -01 . . . . . . . . . . 37 17.12. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 17.13. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39
18.1. Normative References . . . . . . . . . . . . . . . . . . 37 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.2. Informative references . . . . . . . . . . . . . . . . . 39 18.1. Normative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 18.2. Informative references . . . . . . . . . . . . . . . . . 41
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].
Additionally, we use the following abbreviations: Additionally, we use the following abbreviations:
skipping to change at page 7, line 38 skipping to change at page 7, line 50
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 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 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 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 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 might ignore location information sent by an originating device in an
emergency call INVITE, instead attaching their own location emergency call INVITE, instead attaching their own location
information (often determined in cooperation with the originating information (often determined in cooperation with the originating
device). Standardized crash data structures often include location device). Standardized crash data structures often include location
as determined by the IVS. A benefit of this is that it allows the 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 PSAP to see both the location as determined by the cellular network
(often in cooperation with the originating device) and the location (often in cooperation with the originating device) and the location
as determined by the IVS. as determined by the IVS.
This specification inherits the ability to utilize test call This specification inherits the ability to utilize test call
skipping to change at page 13, line 25 skipping to change at page 13, line 30
to the INVITE (e.., 200 OK) lacks an eCall control structure to the INVITE (e.., 200 OK) lacks an eCall control structure
acknowledging receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or 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 TSP then proceeds as it would for a CS-ACN call (e.g., verbal
conveyance of data) conveyance of 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. 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]) 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'. 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 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.eCall.control+xml') in
the Content-Type header field of the body part. The body part is 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 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'. '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 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 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
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 A PSAP can request that the vehicle send an updated VEDS data block
during a call. The PSAP creates a metadata/control object requesting during a call. To do so, the PSAP creates a metadata/control object
the VEDS data and attaches it to a SIP INFO message which it sends requesting VEDS data and attaches it to a SIP INFO message which it
within the dialog. The IVS then attaches an updated VEDS data to a sends within the dialog. The IVS then attaches an updated VEDS data
SIP INFO message and sends it within the dialog. The metadata/ object to a SIP INFO message and sends it within the dialog. The
control object and the VEDS are attached to an INFO message in the metadata/control object and the VEDS data are both associated with
same way they are attached to other messages (such as the INVITE and the INFO package registered by this document (in Section 11), and
the reply to the INVITE as discussed above). INFO messages are sent hence sent per [RFC6086]. In addition, to align with the way a VEDS
using an appropriate INFO Package. See Section 11 for more 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. information.
When data is being carried in an INFO request message, the body part If the IVS is aware that the VEDS data it sent previously has
also carries a Content-Disposition header field set to "Info- changed, it MAY send an unsolicited MSD (in any convenient SIP
Package". 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 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 15, line 52 skipping to change at page 16, line 36
metadata/control object defined in [I-D.ietf-ecrit-ecall]. metadata/control object defined in [I-D.ietf-ecrit-ecall].
8. Call Routing 8. Call Routing
An Emergency Services IP Network (ESInet) is a network operated by or An Emergency Services IP Network (ESInet) is a network operated by or
on behalf of emergency services authorities. It handles emergency on behalf of emergency services authorities. It handles emergency
call routing and processing before delivery to a PSAP. In the 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 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 architecture adopted by EENA, each PSAP is connected to one or more
ESInets. Each originating network is also 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 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 separation between the responsibilities of the originating network
and that of the emergency services network, and provides greater and that of the emergency services network, and provides greater
flexibility and control over processing of emergency calls by the flexibility and control over processing of emergency calls by the
emergency services authorities and PSAPs. This makes it easier to emergency services authorities and PSAPs. This can make it easier to
react quickly to unusual situations that require changes in how react quickly to situations that require changes in how emergency
emergency calls are routed or handled (e.g., a natural disaster calls are routed or handled (e.g., a natural disaster closes a PSAP),
closes a PSAP), as well as ease in making long-term changes that as well as ease in making long-term changes that affect such routing
affect such routing (e.g., cooperative agreements to specially handle (e.g., cooperative agreements to specially handle calls requiring
calls requiring translation or relay services). translation or relay services).
In an environment that uses ESInets, the originating network need In an environment that uses ESInets, the originating network might
only detect that the service URN of an emergency call is or starts pass all types of emergency calls to an ESInet (all calls with a
with "sos", passing all types of emergency calls to an ESInet. The service URN of or starting with "sos"). The ESInet then routs such
ESInet is then responsible for routing such calls to an appropriate calls to an appropriate PSAP. In an environment without an ESInet,
PSAP. In an environment without an ESInet, the emergency services the emergency services authorities and the originating carriers
authorities and the originating carriers determine how such calls are determine how such calls are routed.
routed.
9. New Metadata/Control Values 9. New Metadata/Control Values
This document adds new attribute values to the metadata/control This document adds new attribute values to the metadata/control
structure defined in [I-D.ietf-ecrit-ecall]. structure defined in [I-D.ietf-ecrit-ecall].
In addition to the base usage from the PSAP to the IVS to In addition to the base usage from the PSAP to the IVS to
acknowledge receipt of crash data, the <ack> element is also acknowledge receipt of crash data, the <ack> element is also
contained in a metadata/control block sent by the IVS to the PSAP. 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 This is used by the IVS to acknowledge receipt of a request by the
skipping to change at page 21, line 43 skipping to change at page 22, line 28
This document registers the 'emergencyCallData.eCall.VEDS' INFO This document registers the 'emergencyCallData.eCall.VEDS' INFO
package. package.
Both endpoints (the IVS and the PSAP equipment) include Both endpoints (the IVS and the PSAP equipment) include
'emergencyCallData.eCall.VEDS' in a Recv-Info header field per 'emergencyCallData.eCall.VEDS' in a Recv-Info header field per
[RFC6086] to indicate ability to receive INFO messages carrying data [RFC6086] to indicate ability to receive INFO messages carrying data
as described here. as described here.
Support for the 'emergencyCallData.eCall.VEDS' INFO package indicates Support for the 'emergencyCallData.eCall.VEDS' INFO package indicates
the ability to receive the VEDS body part as specified in [TBD: THIS the ability to receive NG-ACN related body parts as specified in
DOCUMENT] and the metadata/control body part as specified in [TBD: THIS DOCUMENT].
[I-D.ietf-ecrit-ecall].
An INFO request message carrying data related to an emergency call as An INFO request message carrying data related to an emergency call as
described in [TBD: THIS DOCUMENT] has an Info-Package header field described in [TBD: THIS DOCUMENT] has an Info-Package header field
set to 'emergencyCallData.eCall.VEDS' per [RFC6086]. set to 'emergencyCallData.eCall.VEDS' per [RFC6086].
11.1. INFO Package Requirements
The requirements of Section 10 of [RFC6086] are addressed in the The requirements of Section 10 of [RFC6086] are addressed in the
following sections. following sections.
11.1.1. Overall Description 11.1. Overall Description
This section describes "what type of information is carried in INFO This section describes "what type of information is carried in INFO
requests associated with the Info Package, and for what types of requests associated with the Info Package, and for what types of
applications and functionalities UAs can use the Info Package." applications and functionalities UAs can use the Info Package."
INFO requests associated with the emergencyCallData.eCall.VEDS INFO INFO requests associated with the emergencyCallData.eCall.VEDS INFO
package carry data associated with emergency calls as defined in package carry data associated with emergency calls as defined in
[TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency [TBD: THIS DOCUMENT]. The application is vehicle-initiated emergency
calls established using SIP. The functionality is to carry vehicle calls established using SIP. The functionality is to carry vehicle
data and metadata/control information between vehicles and PSAPs. data and metadata/control information between vehicles and PSAPs.
Refer to [TBD: THIS DOCUMENT] for more information. 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 This section describes "why the Info Package mechanism, rather than
some other mechanism, has been chosen for the specific use-case...." 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 use of INFO is based on an analysis of the requirements against
the intent and effects of INFO versus other approaches (which the intent and effects of INFO versus other approaches (which
included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane
transport, and non-SIP protocols). In particular, the transport of transport, and non-SIP protocols). In particular, the transport of
emergency call data blocks occurs within a SIP emergency dialog, per emergency call data blocks occurs within a SIP emergency dialog, per
Section 6, and is normally carried in the initial INVITE and its Section 6, and is normally carried in the initial INVITE and its
skipping to change at page 23, line 5 skipping to change at page 23, line 35
is two-way communication of data related to the emergency dialog. is two-way communication of data related to the emergency dialog.
Use of the media plane mechanisms was discounted because the number Use of the media plane mechanisms was discounted because the number
of messages needing to be exchanged in a dialog is normally zero or 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 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) overhead caused by user plane setup (e.g., to use MSRP as transport)
would be disproportionately large. would be disproportionately large.
Based on the the analyses, the SIP INFO method was chosen to provide Based on the the analyses, the SIP INFO method was chosen to provide
for mid-call data transport. for mid-call data transport.
11.1.3. Info Package Name 11.3. Info Package Name
The info package name is emergencyCallData.eCall.VEDS The info package name is emergencyCallData.eCall.VEDS
11.1.4. Info Package Parameters 11.4. Info Package Parameters
None None
11.1.5. SIP Option-Tags 11.5. SIP Option-Tags
None None
11.1.6. INFO Message Body Parts 11.6. INFO Message Body Parts
The 'application/emergencyCallData.eCall.VEDS+xml' and 'application/ The body for an emergencyCallData.eCall.VEDS info package is:
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.
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 Usage is limited to vehicle-initiated emergency calls as defined in
[TBD: THIS DOCUMENT]. [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 The rate of SIP INFO requests associated with the
emergencyCallData.eCall.VEDS info package is normally quite low (most emergencyCallData.eCall.VEDS info package is normally quite low (most
dialogs are likely to contain zero INFO requests, while others can be dialogs are likely to contain zero INFO requests, while others can be
expected to carry an occasional request). 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 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 and/or privacy considerations specific to that data block. The
"Security Considerations" and "Privacy Considerations" sections of "Security Considerations" and "Privacy Considerations" sections of
[TBD: THIS DOCUMENT] discuss security and privacy considerations of [TBD: THIS DOCUMENT] discuss security and privacy considerations of
the data carried in vehicle-initiated emergency calls as described in the data carried in vehicle-initiated emergency calls as described in
that document. that document.
11.1.10. Implementation Details 11.10. Implementation Details
See [TBD: THIS DOCUMENT] for protocol details. See [TBD: THIS DOCUMENT] for protocol details.
11.1.11. Examples 11.11. Examples
See [TBD: THIS DOCUMENT] for protocol examples. See [TBD: THIS DOCUMENT] for protocol examples.
12. Example 12. Example
Figure 10 shows an NG-ACN call routing. The mobile network operator Figure 10 shows an NG-ACN call routing. The mobile network operator
(MNO) routes the call to an Emergency services IP Network (ESInet), (MNO) routes the call to an Emergency services IP Network (ESInet),
as for any emergency call. The ESInet routes the call to an as for any emergency call. The ESInet routes the call to an
appropriate NG-ACN-capable PSAP (using location information and the 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 fact that that it is an NG-ACN call). The call is processed by the
skipping to change at page 25, line 51 skipping to change at page 27, line 35
('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.ecall.control
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.eCall.control+xml application/emergencyCallData.eCall.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-Transfer-Encoding: binary
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...Session Description Protocol (SDP) goes here ...Session Description Protocol (SDP) goes here
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
<?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"
skipping to change at page 27, line 4 skipping to change at page 28, line 37
<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
skipping to change at page 28, line 38 skipping to change at page 30, line 24
<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.ecall.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:eCall: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:
eCall:control"> eCall:control">
<capabilities> <capabilities>
skipping to change at page 35, line 45 skipping to change at page 37, line 45
16. Acknowledgements 16. Acknowledgements
We would like to thank Christer Holmberg for his suggestions; Michael We would like to thank Christer Holmberg for his suggestions; Michael
Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom,
and Rex Buddenberg for their feedback; and Ulrich Dietz for his help and Rex Buddenberg for their feedback; and Ulrich Dietz for his help
with earlier versions of the original version of this document. 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-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 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.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 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.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 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 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.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 o Reworded security text in main document and in MIME registration
for the VEDS object 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 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.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 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 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.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 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.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 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.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 o Fixed case of 'EmergencyCallData', in accordance with changes to
[RFC7852] [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 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
[I-D.ietf-ecrit-ecall] [I-D.ietf-ecrit-ecall]
Gellens, R. and H. Tschofenig, "Next-Generation Pan- Gellens, R. and H. Tschofenig, "Next-Generation Pan-
European eCall", draft-ietf-ecrit-ecall-10 (work in European eCall", draft-ietf-ecrit-ecall-11 (work in
progress), July 2016. progress), August 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
<http://www.rfc-editor.org/info/rfc3023>. <http://www.rfc-editor.org/info/rfc3023>.
 End of changes. 57 change blocks. 
118 lines changed or deleted 193 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/