< draft-ietf-ecrit-car-crash-20.txt   draft-ietf-ecrit-car-crash-21.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: June 18, 2017 NeuStar, Inc. Expires: July 15, 2017 NeuStar, Inc.
H. Tschofenig H. Tschofenig
Individual Individual
December 15, 2016 January 11, 2017
Next-Generation Vehicle-Initiated Emergency Calls Next-Generation Vehicle-Initiated Emergency Calls
draft-ietf-ecrit-car-crash-20.txt draft-ietf-ecrit-car-crash-21.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 1, line 37 skipping to change at page 1, line 37
Additional Data Block for the vehicle, sensor, and location data Additional Data Block for the vehicle, sensor, and location data
(often referred to as "crash data" even though there is not (often referred to as "crash data" even though there is not
necessarily a crash) and a SIP INFO package to enable carrying this necessarily a crash) and a SIP INFO package to enable carrying this
and related data in SIP INFO requests. An external specification for and related data in SIP INFO requests. An external specification for
the data format, contents, and structure are referenced in this the data format, contents, and structure are referenced in this
document. document.
This document reuses the technical aspects of next-generation pan- This document reuses the technical aspects of next-generation pan-
European eCall (a mandated and standardized system for emergency European eCall (a mandated and standardized system for emergency
calls by in-vehicle systems within Europe and other regions). calls by in-vehicle systems within Europe and other regions).
However, this document specifies a different set of vehicle (crash) However, this document specifies use of a different set of vehicle
data, specifically, the Vehicle Emergency Data Set (VEDS) rather than (crash) data, specifically, the Vehicle Emergency Data Set (VEDS)
the eCall Minimum Set of Data (MSD). This document is an extension rather than the eCall Minimum Set of Data (MSD). This document is an
of the eCall document, with the primary differences being that this extension of the IETF eCall document, with the primary differences
document makes the MSD data set optional and VEDS mandatory, and adds being that this document makes the MSD data set optional and VEDS
attribute values to the metadata/control object to permit greater mandatory, and adds attribute values to the metadata/control object
functionality. This document registers a new SIP INFO package to permit greater functionality. This document registers a new SIP
(identical to that registered for eCall but with the addition of the INFO package (identical to that registered for eCall but with the
VEDS MIME type). This document also describes legacy (circuit- addition of the VEDS MIME type). This document also describes legacy
switched) ACN systems and their migration to next-generation (circuit-switched) ACN systems and their migration to next-generation
emergency calling, to provide background information and context. emergency calling, to provide background information and context.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 18, 2017. This Internet-Draft will expire on July 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 28 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 28
14.2. Registration of the 'VEDS' entry in the Emergency Call 14.2. Registration of the 'VEDS' entry in the Emergency Call
Data Types registry . . . . . . . . . . . . . . . . . . 30 Data Types registry . . . . . . . . . . . . . . . . . . 30
14.3. New Action Values . . . . . . . . . . . . . . . . . . . 30 14.3. New Action Values . . . . . . . . . . . . . . . . . . . 30
14.4. Emergency Call Static Message Registry . . . . . . . . . 30 14.4. Emergency Call Static Message Registry . . . . . . . . . 30
14.5. Emergency Call Vehicle Lamp ID Registry . . . . . . . . 31 14.5. Emergency Call Vehicle Lamp ID Registry . . . . . . . . 31
14.6. Lamp State Registry . . . . . . . . . . . . . . . . . . 32 14.6. Lamp State Registry . . . . . . . . . . . . . . . . . . 32
14.7. Emergency Call Vehicle Camera ID Registry . . . . . . . 33 14.7. Emergency Call Vehicle Camera ID Registry . . . . . . . 33
14.8. The emergencyCallData.eCall.VEDS SIP INFO package . . . 34 14.8. The emergencyCallData.eCall.VEDS SIP INFO package . . . 34
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
16. Changes from Previous Versions . . . . . . . . . . . . . . . 37 16. Changes from Previous Versions . . . . . . . . . . . . . . . 38
16.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 37 16.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 38
16.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 16.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38
16.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 16.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38
16.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 16.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38
16.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 16.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38
16.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 16.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38
16.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 16.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38
16.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 16.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
16.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 16.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39
16.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 16.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39
16.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 16.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39
16.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 16.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39
16.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 16.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39
16.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 16.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
16.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 16.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40
16.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 16.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40
16.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 16.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40
16.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 16.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40
16.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 16.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
16.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 16.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
17.1. Normative References . . . . . . . . . . . . . . . . . . 40 17.1. Normative References . . . . . . . . . . . . . . . . . . 41
17.2. Informative references . . . . . . . . . . . . . . . . . 41 17.2. Informative references . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 6, line 42 skipping to change at page 6, line 42
emergency calls are used to provide the realization of next- emergency calls are used to provide the realization of next-
generation ACN. Although this specification is designed with the generation ACN. Although this specification is designed with the
requirements for North America ACN in mind (and both APCO and NENA requirements for North America ACN in mind (and both APCO and NENA
are based in the U.S.), it is specified generically such that the are based in the U.S.), it is specified generically such that the
technology can be re-used or extended to suit requirements in other technology can be re-used or extended to suit requirements in other
regions. regions.
This document reuses the technical aspects of next-generation pan- This document reuses the technical aspects of next-generation pan-
European eCall (a mandated and standardized system for emergency European eCall (a mandated and standardized system for emergency
calls by in-vehicle systems within Europe), as described in calls by in-vehicle systems within Europe), as described in
[I-D.ietf-ecrit-ecall]. However, this document specifies a different [I-D.ietf-ecrit-ecall]. However, this document specifies use of a
set of vehicle (crash) data, specifically, the Vehicle Emergency Data different set of vehicle (crash) data, specifically, the Vehicle
Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data
document is an extension of [I-D.ietf-ecrit-ecall], with the (MSD). This document is an extension of [I-D.ietf-ecrit-ecall], with
differences being that this document makes the MSD data set optional the differences being that this document makes the MSD data set
and VEDS mandatory, and adds new attribute values to the metadata/ optional and VEDS mandatory, and adds new attribute values to the
control object defined in that document. This document also metadata/control object defined in that document. This document also
registers a new SIP INFO package (identical to that defined in registers a new SIP INFO package (identical to that defined in
[I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type). [I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type).
This document registers the 'application/EmergencyCallData.VEDS+xml' This document registers the 'application/EmergencyCallData.VEDS+xml'
MIME media type, registers the 'VEDS' entry in the Emergency Call MIME media type, registers the 'VEDS' entry in the Emergency Call
Data Types registry, and registers a SIP INFO package to enable Data Types registry, and registers a SIP INFO package to enable
carrying this and related data in SIP INFO requests. carrying this and related data in SIP INFO requests.
Section 6 introduces VEDS. Section 7 describes how VEDS data and Section 6 introduces VEDS. Section 7 describes how VEDS data and
metadata/control blocks are transported within NG-ACN calls. metadata/control blocks are transported within NG-ACN calls.
skipping to change at page 8, line 49 skipping to change at page 8, line 49
between the vehicle, the TSP, and the PSAP, allowing communication between the vehicle, the TSP, and the PSAP, allowing communication
between the PSAP call taker, the TSP call taker, and the vehicle between the PSAP call taker, the TSP call taker, and the vehicle
occupants (who might be unconscious). occupants (who might be unconscious).
///----\\\ proprietary +------+ 911 trunk or POTS +------+ ///----\\\ proprietary +------+ 911 trunk or POTS +------+
||| IVS |||-------------->+ TSP +------------------->+ PSAP | ||| IVS |||-------------->+ TSP +------------------->+ PSAP |
\\\----/// crash data +------+ location via trunk +------+ \\\----/// crash data +------+ location via trunk +------+
Figure 1: Legacy TSP Model. Figure 1: Legacy TSP Model.
In the paired model, the IVS uses a Bluetooth link with a previously- In the paired model, the IVS uses a local link (typically Bluetooth
paired handset to establish an emergency call with the PSAP (by [Bluetooth]) with a previously-paired handset to establish an
dialing a standard emergency number; 9-1-1 in North America), and emergency call with the PSAP (by dialing a standard emergency number;
then communicates location data to the PSAP via text-to-speech; crash 9-1-1 in North America), and then communicates location data to the
data might or might not be conveyed also using text-to-speech. Some PSAP via text-to-speech; crash data might or might not be conveyed
such systems use an automated voice prompt menu for the PSAP call also using text-to-speech. Some such systems use an automated voice
taker (e.g., "this is an automatic emergency call from a vehicle; prompt menu for the PSAP call taker (e.g., "this is an automatic
press 1 to open a voice path to the vehicle; press 2 to hear the emergency call from a vehicle; press 1 to open a voice path to the
location read out") to allow the call taker to request location data vehicle; press 2 to hear the location read out") to allow the call
via text-to-speech. taker to request location data via text-to-speech.
+---+ +---+
///----\\\ | H | 911/etc voice call via handset +------+ ///----\\\ | H | 911/etc voice call via handset +------+
||| IVS |||-->| S +----------------------------------->+ PSAP | ||| IVS |||-->| S +----------------------------------->+ PSAP |
\\\----/// +---+ location via text-to-speech +------+ \\\----/// +---+ location via text-to-speech +------+
Figure 2: Legacy Paired Model Figure 2: Legacy Paired Model
In the direct model, the IVS directly places an emergency call with In the direct model, the IVS directly places an emergency call with
the PSAP by dialing a standard emergency number (9-1-1 in North the PSAP by dialing a standard emergency number (9-1-1 in North
skipping to change at page 13, line 28 skipping to change at page 13, line 28
subtype starting with 'EmergencyCallData.' subtype starting with 'EmergencyCallData.'
* If the data format is XML, then by convention the name has a * If the data format is XML, then by convention the name has a
suffix of '+xml' suffix of '+xml'
o The item is registered in the Emergency Call Data Types registry, o The item is registered in the Emergency Call Data Types registry,
as defined in Section 11.1.9 of [RFC7852] as defined in Section 11.1.9 of [RFC7852]
* For emergency-call-specific formats, the registered name is the * For emergency-call-specific formats, the registered name is the
root of the MIME media type (not including the root of the MIME media type (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') as 'EmergencyCallData' prefix and any suffix such as '+xml') as
described in Section 4.1 of [RFC7852]. described in Section 4.1 of [RFC7852].
o A new SIP INFO package is registered that permits carrying the the o A new SIP INFO package is registered that permits carrying the new
new media type, the metadata/control object (defined in media type, the metadata/control object (defined in
[I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS [I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS
objects, in SIP INFO requests. objects, in SIP INFO requests.
7. Data Transport 7. Data Transport
[RFC7852] establishes a general mechanism for including blocks of [RFC7852] establishes a general mechanism for including blocks of
data within a SIP emergency call. This document makes use of that data within a SIP emergency call. This document makes use of that
mechanism. This document also registers a SIP INFO package (in mechanism. This document also registers a SIP INFO package (in
Section 14.8) to enable NG-ACN related data blocks to be carried in Section 14.8) to enable NG-ACN related data blocks to be carried in
SIP INFO requests (per [RFC6086], new SIP INFO method usages require SIP INFO requests (per [RFC6086], new SIP INFO method usages require
skipping to change at page 18, line 31 skipping to change at page 18, line 31
rear, brake, brake-center, position-front, position-rear, turn- rear, brake, brake-center, position-front, position-rear, turn-
left, turn-right, and hazard. A registry of lamp states is left, turn-right, and hazard. A registry of lamp states is
defined in Section 14.6. The initial values (listed in Table 5) defined in Section 14.6. The initial values (listed in Table 5)
are "on", "off", and "flash". are "on", "off", and "flash".
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 registry of camera identification values a feed from a camera. A registry of camera identification values
is defined in Section 14.7. The initial values (listed in is defined in Section 14.7. The initial values (listed in
Table 6) are backup, left-rear, right-rear, forward, rear-wide, Table 6) are backup, left-rear, right-rear, forward, rear-wide,
lane, interior, and night-front. lane, interior, night-front, night-rear, night-left, and night-
right.
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.control <EmergencyCallData.control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData: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">
skipping to change at page 31, line 23 skipping to change at page 31, line 23
determined by the registrant; IANA assigns the IDs. Each message is determined by the registrant; IANA assigns the IDs. Each message is
assigned a consecutive integer value as its ID. This allows an IVS assigned a consecutive integer value as its ID. This allows an IVS
to indicate by a single integer value that it supports all messages to indicate by a single integer value that it supports all messages
with that value or lower. with that value or lower.
The initial set of values is listed in Table 3. The initial set of values is listed in Table 3.
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
| ID | Message | | ID | Message |
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
| 1 | Emergency services has noted your information and location, | | 1 | Emergency services has received your information and |
| | but cannot speak with you right now. We will help you as | | | location, but cannot speak with you right now. We will get |
| | soon as possible. | | | help to you as soon as possible. |
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
Table 3: Emergency Call Static Message Registry Initial Values Table 3: Emergency Call Static Message Registry Initial Values
14.5. Emergency Call Vehicle Lamp ID Registry 14.5. Emergency Call Vehicle Lamp ID Registry
This document creates a new sub-registry called "Emergency Call This document creates a new sub-registry called "Emergency Call
Vehicle Lamp ID" in the "Emergency Call Metadata/Control Data" Vehicle Lamp ID" in the "Emergency Call Metadata/Control Data"
registry established by [I-D.ietf-ecrit-ecall]. This new sub- registry established by [I-D.ietf-ecrit-ecall]. This new sub-
registry uniquely identifies the names of automotive lamps (lights). registry uniquely identifies the names of automotive lamps (lights).
skipping to change at page 34, line 32 skipping to change at page 34, line 32
| | collision detection systems), separate from backup | | | collision detection systems), separate from backup |
| | view | | | view |
| | | | | |
| lane | Used by systems to identify road lane and/or | | lane | Used by systems to identify road lane and/or |
| | monitor vehicle's position within lane | | | monitor vehicle's position within lane |
| | | | | |
| 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 |
| | |
| night-rear | Night-vision view of what is behind the vehicle |
| | |
| night-left | Night-vision view of what is to the left of the |
| | vehicle |
| | |
| night-right | Night-vision view of what is to the right of the |
| | vehicle |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
Table 6: Emergency Call Vehicle Camera ID Registry Initial Values Table 6: Emergency Call Vehicle Camera ID Registry Initial Values
14.8. The emergencyCallData.eCall.VEDS SIP INFO package 14.8. The emergencyCallData.eCall.VEDS SIP INFO package
This document registers the 'emergencyCallData.eCall.VEDS' SIP INFO This document registers the 'emergencyCallData.eCall.VEDS' SIP INFO
package. package.
Both endpoints (the IVS and the PSAP equipment) include Both endpoints (the IVS and the PSAP equipment) include
skipping to change at page 35, line 45 skipping to change at page 36, line 4
needs to be sent mid-call. While the SIP MESSAGE method could be needs to be sent mid-call. While the SIP MESSAGE method could be
used, it is not tied to a SIP dialog as is the INFO method and thus used, it is not tied to a SIP dialog as is the INFO method and thus
might not be associated with the dialog. Both the SIP OPTIONS or re- might not be associated with the dialog. Both the SIP OPTIONS or re-
INVITE methods could also be used, but is seen as less clean than the INVITE methods could also be used, but is seen as less clean than the
INFO method. The SIP SUBSCRIBE/NOTIFY method could be coerced into INFO method. The SIP SUBSCRIBE/NOTIFY method could be coerced into
service, but the semantics are not a good fit, e.g., the subscribe/ service, but the semantics are not a good fit, e.g., the subscribe/
notify mechanism provides one-way communication consisting of (often notify mechanism provides one-way communication consisting of (often
multiple) notifications from notifier to subscriber indicating that multiple) notifications from notifier to subscriber indicating that
certain events in notifier have occurred, whereas what's needed here certain events in notifier have occurred, whereas what's needed here
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 analyses, the SIP INFO method was chosen to provide for
for mid-call data transport. mid-call data transport.
14.8.3. Info Package Name 14.8.3. Info Package Name
The SIP INFO package name is emergencyCallData.eCall.VEDS The SIP INFO package name is emergencyCallData.eCall.VEDS
14.8.4. Info Package Parameters 14.8.4. Info Package Parameters
None None
14.8.5. SIP Option-Tags 14.8.5. SIP Option-Tags
skipping to change at page 37, line 38 skipping to change at page 37, line 45
See [TBD: THIS DOCUMENT] for protocol details. See [TBD: THIS DOCUMENT] for protocol details.
14.8.11. Examples 14.8.11. Examples
See [TBD: THIS DOCUMENT] for protocol examples. See [TBD: THIS DOCUMENT] for protocol examples.
15. Acknowledgements 15. Acknowledgements
We would like to thank Lena Chaponniere, Alissa Cooper, Stephen Edge, We would like to thank Lena Chaponniere, Alissa Cooper, Stephen Edge,
Christer Holmberg, and Allison Mankin for their review and Christer Holmberg, Allison Mankin, and Dan Romascanu for their review
suggestions; Robert Sparks and Paul Kyzivat for their help with the and suggestions; Robert Sparks and Paul Kyzivat for their help with
SIP mechanisms; Michael Montag, Arnoud van Wijk, Ban Al-Bakri, Wes the SIP mechanisms; Michael Montag, Arnoud van Wijk, Ban Al-Bakri,
George, Gunnar Hellstrom, and Rex Buddenberg for their feedback; and Wes George, Gunnar Hellstrom, and Rex Buddenberg for their feedback;
Ulrich Dietz for his help with earlier versions of the original and Ulrich Dietz for his help with earlier versions of the original
version of this document. version of this document.
16. Changes from Previous Versions 16. Changes from Previous Versions
RFC Editor: Please remove this section prior to publication.
16.1. Changes from draft-ietf-18 to draft-ietf-19 16.1. Changes from draft-ietf-18 to draft-ietf-19
o Fixed various nits o Fixed various nits
16.2. Changes from draft-ietf-17 to draft-ietf-18 16.2. Changes from draft-ietf-17 to draft-ietf-18
o Added additional text to "Rate of Info Requests" o Added additional text to "Rate of Info Requests"
o Further corrected "content type" to "media type" o Further corrected "content type" to "media type"
16.3. Changes from draft-ietf-16 to draft-ietf-17 16.3. Changes from draft-ietf-16 to draft-ietf-17
skipping to change at page 40, line 44 skipping to change at page 41, line 4
[RFC7852] [RFC7852]
16.20. Changes from draft-gellens-00 to -01 16.20. 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
17. References 17. References
17.1. Normative References 17.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-20 (work in European eCall", draft-ietf-ecrit-ecall-21 (work in
progress), November 2016. progress), December 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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
skipping to change at page 41, line 47 skipping to change at page 42, line 7
<http://www.rfc-editor.org/info/rfc7852>. <http://www.rfc-editor.org/info/rfc7852>.
[VEDS] Advanced Automatic Crash Notification (AACN) Joint APCO/ [VEDS] Advanced Automatic Crash Notification (AACN) Joint APCO/
NENA Data Standardization Workgroup, , "Vehicular NENA Data Standardization Workgroup, , "Vehicular
Emergency Data Set (VEDS) version 3", July 2012, Emergency Data Set (VEDS) version 3", July 2012,
<https://www.apcointl.org/resources/telematics/aacn-and- <https://www.apcointl.org/resources/telematics/aacn-and-
veds.html>. veds.html>.
17.2. Informative references 17.2. Informative references
[Bluetooth]
Bluetooth Special Interest Group, , "Bluetooth
Specifications", <https://https://www.bluetooth.com/
specifications>.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, DOI 10.17487/RFC5012, January 2008, RFC 5012, DOI 10.17487/RFC5012, January 2008,
<http://www.rfc-editor.org/info/rfc5012>. <http://www.rfc-editor.org/info/rfc5012>.
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, Emergency Call Marking and Mapping", RFC 5069,
DOI 10.17487/RFC5069, January 2008, DOI 10.17487/RFC5069, January 2008,
<http://www.rfc-editor.org/info/rfc5069>. <http://www.rfc-editor.org/info/rfc5069>.
 End of changes. 22 change blocks. 
54 lines changed or deleted 70 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/