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