< draft-ietf-ecrit-ecall-04.txt   draft-ietf-ecrit-ecall-05.txt >
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Qualcomm Technologies, Inc.
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: April 20, 2016 (Individual) Expires: May 8, 2016 (Individual)
October 18, 2015 November 5, 2015
Next-Generation Pan-European eCall Next-Generation Pan-European eCall
draft-ietf-ecrit-ecall-04.txt draft-ietf-ecrit-ecall-05.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 the Pan European in- mechanisms to support the next generation of the Pan European in-
vehicle emergency call service defined under the eSafety initiative vehicle emergency call service defined under the eSafety initiative
of the European Commission (generally referred to as "eCall"). eCall of the European Commission (generally referred to as "eCall"). eCall
is a standardized and mandated system for a special form of emergency is a standardized and mandated system for a special form of emergency
calls placed by vehicles. eCall deployment is required in the very calls placed by vehicles. eCall deployment is required in the very
near future in European Union member states, and eCall (and eCall- near future in European Union member states, and eCall (and eCall-
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 April 20, 2016. This Internet-Draft will expire on May 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 44 skipping to change at page 2, line 44
8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10
9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11
9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12 9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12
9.1.1.1. Attributes of the <ack> element . . . . . . . . . 13 9.1.1.1. Attributes of the <ack> element . . . . . . . . . 13
9.1.1.2. Child Elements of the <ack> element . . . . . . . 13 9.1.1.2. Child Elements of the <ack> element . . . . . . . 13
9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14
9.1.2. The <capabilities> element . . . . . . . . . . . . . 15 9.1.2. The <capabilities> element . . . . . . . . . . . . . 15
9.1.2.1. Child Elements of the <capabilities> element . . 15 9.1.2.1. Child Elements of the <capabilities> element . . 15
9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16
9.1.3. The <request> element . . . . . . . . . . . . . . . . 16 9.1.3. The <request> element . . . . . . . . . . . . . . . . 17
9.1.3.1. Attributes of the <request> element . . . . . . . 17 9.1.3.1. Attributes of the <request> element . . . . . . . 17
9.1.3.2. Child Elements of the <request> element . . . . . 19 9.1.3.2. Child Elements of the <request> element . . . . . 19
9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19 9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19
9.2. The emergencyCallData.eCall INFO package . . . . . . . . 20 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 20
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14.1. Service URN Registrations . . . . . . . . . . . . . . . 29 14.1. Service URN Registrations . . . . . . . . . . . . . . . 30
14.2. MIME Content-type Registration for 14.2. MIME Content-type Registration for
'application/emergencyCallData.eCall.MSD+xml' . . . . . 30 'application/emergencyCallData.eCall.MSD+xml' . . . . . 30
14.3. MIME Content-type Registration for 14.3. MIME Content-type Registration for
'application/emergencyCallData.eCall.control+xml' . . . 31 'application/emergencyCallData.eCall.control+xml' . . . 32
14.4. Registration of the 'eCall.MSD' entry in the Emergency 14.4. Registration of the 'eCall.MSD' entry in the Emergency
Call Additional Data Blocks registry . . . . . . . . . . 33 Call Additional Data Blocks registry . . . . . . . . . . 33
14.5. Registration of the 'eCall.control' entry in the 14.5. Registration of the 'eCall.control' entry in the
Emergency Call Additional Data Blocks registry . . . . . 33 Emergency Call Additional Data Blocks registry . . . . . 34
14.6. Registration of the emergencyCallData.eCall Info Package 33 14.6. Registration of the emergencyCallData.eCall Info Package 34
14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33 14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34
14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33 14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34
14.7.2. Registration for 14.7.2. Registration for
urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 35
14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35
14.8.1. eCall Control Action Registry . . . . . . . . . . . 35 14.8.1. eCall Control Action Registry . . . . . . . . . . . 35
14.8.2. eCall Static Message Registry . . . . . . . . . . . 36 14.8.2. eCall Static Message Registry . . . . . . . . . . . 36
14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37 14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37
14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 37 14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 38
14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 38 14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 39
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
17. Changes from Previous Versions . . . . . . . . . . . . . . . 39 17. Changes from Previous Versions . . . . . . . . . . . . . . . 40
17.1. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 17.1. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40
17.2. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 17.2. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40
17.3. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 17.3. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 41
17.4. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 40 17.4. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 41
17.5. Changes from draft-gellens-02 to -03 . . . . . . . . . . 40 17.5. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41
17.6. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 17.6. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41
17.7. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 17.7. Changes from draft-gellens-02 to -03 . . . . . . . . . . 42
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 17.8. Changes from draft-gellens-01 to -02 . . . . . . . . . . 42
18.1. Normative References . . . . . . . . . . . . . . . . . . 41 17.9. Changes from draft-gellens-00 to -01 . . . . . . . . . . 42
18.2. Informative references . . . . . . . . . . . . . . . . . 42 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 18.1. Normative References . . . . . . . . . . . . . . . . . . 42
18.2. Informative references . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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:
+--------+----------------------------------------+ +--------+----------------------------------------+
| Term | Expansion | | Term | Expansion |
+--------+----------------------------------------+ +--------+----------------------------------------+
| 3GPP | 3rd Generation Partnership Project | | 3GPP | 3rd Generation Partnership Project |
| CEN | European Committee for Standardization | | CEN | European Committee for Standardization |
| EENA | European Emergency Number Association | | EENA | European Emergency Number Association |
| ESInet | Emergency Services IP network | | ESInet | Emergency Services IP network |
| IMS | Internet Multimedia Subsystem | | IMS | IP Multimedia Subsystem |
| IVS | In-Vehicle System | | IVS | In-Vehicle System |
| MNO | Mobile Network Operator | | MNO | Mobile Network Operator |
| MSD | Minimum Set of Data | | MSD | Minimum Set of Data |
| PSAP | Public Safety Answering Point | | PSAP | Public Safety Answering Point |
+--------+----------------------------------------+ +--------+----------------------------------------+
2. Document Scope 2. Document Scope
This document is limited to the signaling, data exchange, and This document is limited to the signaling, data exchange, and
protocol needs of next-generation eCall (NG-eCall, also referred to protocol needs of next-generation eCall (NG-eCall, also referred to
skipping to change at page 4, line 41 skipping to change at page 4, line 41
All such aspects are the purview of their respective standards All such aspects are the purview of their respective standards
bodies. The scope of this document is limited to eCall operating bodies. The scope of this document is limited to eCall operating
within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). within a SIP-based environment (e.g., 3GPP IMS Emergency Calling).
The technical contents of this document can be suitable for use in The technical contents of this document can be suitable for use in
other vehicle-initiated emergency call systems, but this is out of other vehicle-initiated emergency call systems, but this is out of
scope for this document. scope for this document.
Vehicles designed for multiple regions might need to support eCall Vehicles designed for multiple regions might need to support eCall
and other Advanced Automatic Crash Notification (AACN) systems, such and other Advanced Automatic Crash Notification (AACN) systems, such
as described in [draft-ietf-ecrit-car-crash]. That system is as described in [I-D.ietf-ecrit-car-crash]. That system is
compatible with eCall, differing primarily in the specific data set compatible with eCall, differing primarily in the specific data set
that is sent. that is sent.
3. Introduction 3. Introduction
Emergency calls made from vehicles (e.g., in the event of a crash) Emergency calls made from vehicles (e.g., in the event of a crash)
assist in significantly reducing road deaths and injuries by allowing assist in significantly reducing road deaths and injuries by allowing
emergency services to be aware of the incident, the state of the emergency services to be aware of the incident, the state of the
vehicle, the location of the vehicle, and to have a voice channel vehicle, the location of the vehicle, and to have a voice channel
with the vehicle occupants. This enables a quick and appropriate with the vehicle occupants. This enables a quick and appropriate
skipping to change at page 5, line 50 skipping to change at page 5, line 50
occupants has changed). Work on next-generation eCall (NG-eCall, occupants has changed). Work on next-generation eCall (NG-eCall,
also referred to as packet-switched eCall or PS eCall) is now in also referred to as packet-switched eCall or PS eCall) is now in
process. As part of this work, the European Telecommunications process. As part of this work, the European Telecommunications
Standards Institute (ETSI) [SDO-ETSI] has published a Technical Standards Institute (ETSI) [SDO-ETSI] has published a Technical
Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR]
that presents findings and recommendations regarding support for that presents findings and recommendations regarding support for
eCall in an all-IP environment. NG-eCall moves from circuit switched eCall in an all-IP environment. NG-eCall moves from circuit switched
to all-IP, and carries the vehicle data and other eCall-specific data to all-IP, and carries the vehicle data and other eCall-specific data
as additional data associated with the call. This document describes as additional data associated with the call. This document describes
how IETF mechanisms for IP-based emergency calls, including [RFC6443] how IETF mechanisms for IP-based emergency calls, including [RFC6443]
and [additional-data-draft] are used to provide the signaling and and [I-D.ietf-ecrit-additional-data] are used to provide the
data exchange of the next generation of pan-European eCall. signaling and data exchange of the next generation of pan-European
eCall.
The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency
calling with additional elements identifying the call as an eCall and calling with additional elements identifying the call as an eCall and
as carrying eCall data and with mechanisms for carrying the data. as carrying eCall data and with mechanisms for carrying the data.
3GPP IMS emergency services support multimedia, providing the ability 3GPP IMS emergency services support multimedia, providing the ability
to carry voice, text, and video. This capability is referred to to carry voice, text, and video. This capability is referred to
within 3GPP as Multimedia Emergency Services (MMES). within 3GPP as Multimedia Emergency Services (MMES).
A transition period will exist during which time the various entities A transition period will exist during which time the various entities
involved in initiating and handling an eCall might support next- involved in initiating and handling an eCall might support next-
skipping to change at page 7, line 29 skipping to change at page 7, line 29
Pan-European eCall provides a standardized and mandated set of Pan-European eCall provides a standardized and mandated set of
vehicle related data, known as the Minimum Set of Data (MSD). The vehicle related data, known as the Minimum Set of Data (MSD). The
European Committee for Standardization (CEN) has specified this data European Committee for Standardization (CEN) has specified this data
in EN 15722 [msd], along with both ASN.1 and XML encodings for the in EN 15722 [msd], along with both ASN.1 and XML encodings for the
MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML
encoding is better suited for use in SIP messages and is used in this encoding is better suited for use in SIP messages and is used in this
document. (The ASN.1 encoding is specified in Annex A of EN 15722 document. (The ASN.1 encoding is specified in Annex A of EN 15722
[msd], while the XML encoding is specified in Annex C.) [msd], while the XML encoding is specified in Annex C.)
The "Additional Data related to an Emergency Call" document The "Additional Data related to an Emergency Call" document
[additional-data-draft] establishes a general mechanism for attaching [I-D.ietf-ecrit-additional-data] establishes a general mechanism for
blocks of data to a SIP emergency call. This document makes use of attaching blocks of data to a SIP emergency call. This document
that mechanism to carry the eCall MSD in a SIP emergency call. makes use of that mechanism to carry the eCall MSD in a SIP emergency
call.
This document registers the 'application/ This document registers the 'application/
emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD
to be carried in SIP. This document also adds the 'eCall.MSD' entry to be carried in SIP. This document also adds the 'eCall.MSD' entry
to the Emergency Call Additional Data Blocks registry (established by to the Emergency Call Additional Data Blocks registry (established by
[additional-data-draft]) to enable the MSD to be recognized as such [I-D.ietf-ecrit-additional-data]) to enable the MSD to be recognized
in a SIP-based eCall emergency call. as such in a SIP-based eCall emergency call.
Note that if additional data sets are defined and registered (e.g., Note that if additional data sets are defined and registered (e.g.,
in the future or in other regions) and transmitted using the same in the future or in other regions) and transmitted using the same
mechanisms, the size and frequency of transmission during a session mechanisms, the size and frequency of transmission during a session
needs to be evaluated to be sure it is appropriate to use the needs to be evaluated to be sure it is appropriate to use the
signaling channel. signaling channel.
6. Call Setup 6. Call Setup
In circuit-switched eCall, the IVS places a special form of a 112 In circuit-switched eCall, the IVS places a special form of a 112
skipping to change at page 8, line 14 skipping to change at page 8, line 15
transmitted to the PSAP via the eCall in-band modem (in the voice transmitted to the PSAP via the eCall in-band modem (in the voice
channel). channel).
///----\\\ 112 voice call with eCall flag +------+ ///----\\\ 112 voice call with eCall flag +------+
||| IVS |||---------------------------------------->+ PSAP | ||| IVS |||---------------------------------------->+ PSAP |
\\\----/// vehicle data via eCall in-band modem +------+ \\\----/// vehicle data via eCall in-band modem +------+
Figure 1: circuit-switched eCall Figure 1: circuit-switched eCall
An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD
in accordance with [additional-data-draft] by encoding it as in accordance with [I-D.ietf-ecrit-additional-data] by encoding it as
specified (per Appendix C of EN 15722 [msd]) and attaching it to an specified (per Appendix C of EN 15722 [msd]) and attaching it to an
INVITE as a MIME body part. The body part is identified by its MIME INVITE as a MIME body part. The body part is identified by its MIME
content-type ('application/emergencyCallData.eCall.MSD+xml') in the content-type ('application/emergencyCallData.eCall.MSD+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 INVITE is marked as containing the MSD field in the body part. The INVITE is marked as containing the MSD
by adding (or appending to) a Call-Info header field at the top level by adding (or appending to) a Call-Info header field at the top level
of the INVITE. This Call-Info header field contains a CID URL of the INVITE. This Call-Info header field contains a CID URL
referencing the body part's unique identifier, and a 'purpose' referencing the body part's unique identifier, and a 'purpose'
parameter identifying the data as the eCall MSD per the registry parameter identifying the data as the eCall MSD per the registry
skipping to change at page 10, line 44 skipping to change at page 10, line 44
eCall requires the ability for the PSAP to acknowledge successful eCall requires the ability for the PSAP to acknowledge successful
receipt of an MSD sent by the IVS, and for the PSAP to request that receipt of an MSD sent by the IVS, and for the PSAP to request that
the IVS send an MSD (e.g., the call taker can initiate a request for the IVS send an MSD (e.g., the call taker can initiate a request for
a new MSD to see if the vehicle's state or location has changed). a new MSD to see if the vehicle's state or location has changed).
Future enhancements are desired to enable the PSAP to send other Future enhancements are desired to enable the PSAP to send other
requests to the vehicle, such as locking or unlocking doors, sounding requests to the vehicle, such as locking or unlocking doors, sounding
the horn, flashing the lights, starting a video stream from on-board the horn, flashing the lights, starting a video stream from on-board
cameras (such as rear focus or blind-spot), etc. cameras (such as rear focus or blind-spot), etc.
The mechanism established in [additional-data-draft], used in The mechanism established in [I-D.ietf-ecrit-additional-data], used
Section 5 of this document to carry the MSD from the IVS to the PSAP, in Section 5 of this document to carry the MSD from the IVS to the
is also used to carry a block of control data from the PSAP to the PSAP, is also used to carry a block of control data from the PSAP to
IVS. This eCall control block (sometimes referred to as eCall the IVS. This eCall control block (sometimes referred to as eCall
metadata) is an XML structure containing eCall-specific elements. metadata) is an XML structure containing eCall-specific elements.
When the PSAP needs to send an eCall control block that is in When the PSAP needs to send an eCall control block that is in
response to the MSD or other data sent by the IVS in a SIP request, response to the MSD or other data sent by the IVS in a SIP request,
the control block can be sent in the SIP response to that request the control block can be sent in the SIP response to that request
(e.g., the INVITE). When the PSAP needs to send an eCall control (e.g., the INVITE). When the PSAP needs to send an eCall control
block that is not an immediate response to an MSD or other data sent block that is not an immediate response to an MSD or other data sent
by the IVS, the control block can be transmitted from the PSAP to the by the IVS, the control block can be transmitted from the PSAP to the
IVS in a SIP INFO message within the established session. The IVS IVS in a SIP INFO message within the established session. The IVS
can then send any requested data (such as a new MSD) in the reply to can then send any requested data (such as a new MSD) in the reply to
the INFO message. This mechanism flexibly allows the PSAP to send the INFO message. This mechanism flexibly allows the PSAP to send
skipping to change at page 11, line 26 skipping to change at page 11, line 26
This mechanism requires This mechanism requires
o An XML definition of the eCall control object o An XML definition of the eCall control object
o An extension mechanism by which new elements can be added to the o An extension mechanism by which new elements can be added to the
control object definition (e.g., permitting additional elements to control object definition (e.g., permitting additional elements to
be included by adding their namespace) be included by adding their namespace)
o A MIME type registration for the control object (so it can be o A MIME type registration for the control object (so it can be
carried in SIP messages and responses) carried in SIP messages and responses)
o An entry in the Emergency Call Additional Data Blocks sub-registry o An entry in the Emergency Call Additional Data Blocks sub-registry
(established by [additional-data-draft]) so that the control block (established by [I-D.ietf-ecrit-additional-data]) so that the
can be recognized as emergency call specific data within the SIP control block can be recognized as emergency call specific data
messages within the SIP messages
o An Info-Package registration per [RFC6086] permitting the control o An Info-Package registration per [RFC6086] permitting the control
block within Info messages block within Info messages
9.1. The eCall Control Block 9.1. The eCall Control Block
The eCall control block is an XML data structure allowing for The eCall control block is an XML data structure allowing for
acknowledgments, requests, and capabilities information. It is acknowledgments, requests, and capabilities information. It is
carried in a SIP body part with a specific MIME content type. Three carried in a SIP body part with a specific MIME content type. Three
top-level elements are defined for use within an eCall control block: top-level elements are defined for use within an eCall control block:
ack Used in a control block sent by either side. The PSAP ack Used in a control block sent by either side. The PSAP
uses this to acknowledge receipt of data set sent by uses this to acknowledge receipt of a data set sent by
the IVS. The IVS uses this to acknowledge receipt of a the IVS. The IVS uses this to acknowledge receipt of a
request by the PSAP when that request would not request by the PSAP when that request would not
otherwise be acknowledged (if the PSAP requests the otherwise be acknowledged (if the PSAP requests the
vehicle to send data and the vehicle does so, the data vehicle to send data and the vehicle does so, the data
serves as a success acknowledgement). serves as a success acknowledgement).
capabilities: Used in a control block sent from the IVS to the PSAP capabilities: Used in a control block sent from the IVS to the PSAP
(e.g., in the initial INVITE) to inform the PSAP of the (e.g., in the initial INVITE) to inform the PSAP of the
vehicle capabilities. Child elements contain all vehicle capabilities. Child elements contain all
actions and data types supported by the vehicle and all actions and data types supported by the vehicle and all
skipping to change at page 13, line 37 skipping to change at page 13, line 37
received or not received or not
Example: <ack received="yes" ref="1234567890@atlanta.example.com"/> Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>
9.1.1.2. Child Elements of the <ack> element 9.1.1.2. Child Elements of the <ack> element
The <ack> element has the following child elements: The <ack> element has the following child elements:
Name: actionResult Name: actionResult
Usage: Optional Usage: Optional
Description: An <actionResult> element indicates the result of an Description: An <actionResult> element indicates the result of an
action (other than a 'send-data' action). It has the following action (other than a 'send-data' action). When an <ack> element
attributes: is in response to a control object with multiple <request>
elements (that are not 'send-data' actions), the <ack> element
contains an <actionResult> element for each. The <actionResult>
element has the following attributes:
Name: action Name: action
Usage: Mandatory Usage: Mandatory
Type: token Type: token
Description: Contains the value of the 'action' attribute of the Description: Contains the value of the 'action' attribute of the
<request> element <request> element
Name: success Name: success
Usage: Mandatory Usage: Mandatory
Type: Boolean Type: Boolean
skipping to change at page 15, line 49 skipping to change at page 15, line 49
REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this
<request> element within a <capabilities> element, and MUST <request> element within a <capabilities> element, and MUST
contain at a minimum the 'eCall.MSD' data block value; it SHOULD contain at a minimum the 'eCall.MSD' data block value; it SHOULD
contain all data blocks supported by the IVS. contain all data blocks supported by the IVS.
All other actions are OPTIONAL. All other actions are OPTIONAL.
If the "msg-static" action is supported, a <request> child element If the "msg-static" action is supported, a <request> child element
with a "msg-static" 'action' attribute is sent, with a 'msgid' with a "msg-static" 'action' attribute is sent, with a 'msgid'
attribute set to the highest supported static message supported by attribute set to the highest supported static message supported by
the vehicle. the vehicle. A registry is created in Section 14.8.2 to map
'msgid' values to static text messages. By sending the highest
supported static message number in its <capabilities> element, the
vehicle indicates its support for all static messages in the
registry up to and including that value.
If the "lamp" action is supported, a <request> child element with If the "lamp" action is supported, a <request> child element with
a "lamp" 'action' is sent, with a 'supported-lamps' attribute set a "lamp" 'action' is sent, with a 'supported-lamps' attribute set
to all supported lamp IDs. to all supported lamp IDs.
If the "enable-camera" action is supported, a <request> child If the "enable-camera" action is supported, a <request> child
element with an "enable-camera" 'action' is sent, with a element with an "enable-camera" 'action' is sent, with a
'supported-cameras' attribute set to all supported camera IDs. 'supported-cameras' attribute set to all supported camera IDs.
Examples: Examples:
skipping to change at page 17, line 42 skipping to change at page 17, line 48
Example: persistance="PT1H" Example: persistance="PT1H"
Name: datatype Name: datatype
Usage: Conditional Usage: Conditional
Type: token Type: token
Description: Mandatory with a "send-data" action. Specifies the Description: Mandatory with a "send-data" action. Specifies the
data block that the IVS is requested to transmit, using the same data block that the IVS is requested to transmit, using the same
identifier as in the 'purpose' attribute set in a Call-Info header identifier as in the 'purpose' attribute set in a Call-Info header
field to point to the data block. Permitted values are contained field to point to the data block. Permitted values are contained
in the 'Emergency Call Data Types' IANA registry established in in the 'Emergency Call Data Types' IANA registry established in
[additional-data-draft]. [I-D.ietf-ecrit-additional-data].
Example: datatype="eCall.MSD" Example: datatype="eCall.MSD"
Name: supported-datatypes Name: supported-datatypes
Usage: Conditional Usage: Conditional
Type: string Type: string
Description: Used with a 'send-data' action in a <request> element Description: Used with a 'send-data' action in a <request> element
that is a child of a <capability> element, this attribute lists that is a child of a <capability> element, this attribute lists
all data blocks that the vehicle can transmit, using the same all data blocks that the vehicle can transmit, using the same
identifier as in the 'purpose' attribute in a Call-Info header identifier as in the 'purpose' attribute in a Call-Info header
field to point to the data block. Permitted values are contained field to point to the data block. Permitted values are contained
in the 'Emergency Call Data Types' IANA registry established in in the 'Emergency Call Data Types' IANA registry established in
[additional-data-draft]. Multiple values are separated with a [I-D.ietf-ecrit-additional-data]. Multiple values are separated
semicolon. with a semicolon.
Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo" Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo"
Name: lamp-action Name: lamp-action
Usage: Conditional Usage: Conditional
Type: token Type: token
Description: Used with a 'lamp' action, indicates if the lamp is to Description: Used with a 'lamp' action, indicates if the lamp is to
be illuminated, turned off, or flashed. Permitted values are be illuminated, turned off, or flashed. Permitted values are
'on', 'off', and 'flash'. 'on', 'off', and 'flash'.
Example: lamp-action="flash" Example: lamp-action="flash"
skipping to change at page 20, line 29 skipping to change at page 20, line 47
emergencyCallData.eCall.control+xml' MIME type. The eCall control emergencyCallData.eCall.control+xml' MIME type. The eCall control
block includes the ability for the IVS to indicate its capabilities, block includes the ability for the IVS to indicate its capabilities,
so in the event additional eCall blocks are defined, the IVS can so in the event additional eCall blocks are defined, the IVS can
indicate which it supports. indicate which it supports.
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 (such as SIP the intent and effects of INFO versus other approaches (such as SIP
MESSAGE, media plane, or non-SIP protocols). In particular, the MESSAGE, media plane, or non-SIP protocols). In particular, the
transport of eCall data and control blocks is done only during an transport of eCall data and control blocks is done only during an
emergency session established with SIP, using the mechanism emergency session established with SIP, using the mechanism
established in [additional-data-draft], and is normally carried in established in [I-D.ietf-ecrit-additional-data], and is normally
the initial INVITE and its response; the use of INFO only occurs when carried in the initial INVITE and its response; the use of INFO only
a data block or request needs to be sent subsequently during the occurs when a data block or request needs to be sent subsequently
call. While MESSAGE could be used, it is not tied to a SIP session during the call. While MESSAGE could be used, it is not tied to a
as is INFO. REINVITE could also be used, but is normally used to SIP session as is INFO. REINVITE could also be used, but is normally
modify the session. SUBSCRIBE/NOTIFY could be coerced into service, used to modify the session. SUBSCRIBE/NOTIFY could be coerced into
but the semantics are not a clean fit. Hence, INFO is appropriate. service, but the semantics are not a clean fit. Hence, INFO is
appropriate.
An INFO request message carrying an eCall data or control block has An INFO request message carrying an eCall data or control block has
an Info-Package header field set to 'emergencyCallData.eCall' per an Info-Package header field set to 'emergencyCallData.eCall' per
[RFC6086]. The INFO request message is marked as containing the [RFC6086]. The INFO request message is marked as containing the
eCall data or control block by a Call-Info header field containing a eCall data or control block by a Call-Info header field containing a
CID URL referencing the unique identifier of the body part containing CID URL referencing the unique identifier of the body part containing
the eCall data or control, and a 'purpose' parameter identifying the the eCall data or control, and a 'purpose' parameter identifying the
block. Because the eCall data or control block is being carried in block. Because the eCall data or control block is being carried in
an INFO request message, the body part also carries a Content- an INFO request message, the body part also carries a Content-
Disposition header field set to "Info-Package". Disposition header field set to "Info-Package".
Per [additional-data-draft], emergency call related additional data Per [I-D.ietf-ecrit-additional-data], emergency call related
MAY be included in any SIP request or response message that can additional data MAY be included in any SIP request or response
contain a body. Hence, notwithstanding Section 4.3.2. of [RFC6086], message that can contain a body. Hence, notwithstanding
INFO response messages MAY contain eCall data or control blocks, Section 4.3.2. of [RFC6086], INFO response messages MAY contain eCall
provided they are included as described in this document (with a data or control blocks, provided they are included as described in
Call-Info header field containing a CID URL referencing the unique this document (with a Call-Info header field containing a CID URL
identifier of the body part, and a 'purpose' parameter identifying referencing the unique identifier of the body part, and a 'purpose'
the block). When eCall data or control blocks are included in an parameter identifying the block). When eCall data or control blocks
INFO response message, this is done per [additional-data-draft] and are included in an INFO response message, this is done per
this document, and not under [RFC6086]; that is, they are included as [I-D.ietf-ecrit-additional-data] and this document, and not under
emergency call additional data, not as an INFO package associated [RFC6086]; that is, they are included as emergency call additional
data. data, not as an INFO package associated data.
10. Examples 10. Examples
Figure 7 shows an eCall. The call uses the request URI Figure 7 shows an eCall. The call uses the request URI
'urn:service:sos.ecall.automatic' service URN and is recognized as an 'urn:service:sos.ecall.automatic' service URN and is recognized as an
eCall, and further as one that was invoked automatically by the IVS eCall, and further as one that was invoked automatically by the IVS
due to a crash or other serious incident. In this example, the due to a crash or other serious incident. In this example, the
originating network routes the call to an ESInet (as for any originating network routes the call to an ESInet (as for any
emergency call in an environment with an ESInet). The ESInet routes emergency call in an environment with an ESInet). The ESInet routes
the call to the appropriate NG-eCall capable PSAP. The emergency the call to the appropriate NG-eCall capable PSAP. The emergency
skipping to change at page 26, line 13 skipping to change at page 26, line 13
originating device), an eCall carries an IVS-supplied location within originating device), an eCall carries an IVS-supplied location within
the MSD. This is likely to be useful to the PSAP, especially when the MSD. This is likely to be useful to the PSAP, especially when
the two locations are independently determined. Even in situations the two locations are independently determined. Even in situations
where the network-supplied location is limited to the cell site, this where the network-supplied location is limited to the cell site, this
can be useful as a sanity check on the device-supplied location can be useful as a sanity check on the device-supplied location
contained in the MSD. contained in the MSD.
The document [RFC7378] discusses trust issues regarding location The document [RFC7378] discusses trust issues regarding location
provided by or determined in cooperation with end devices. provided by or determined in cooperation with end devices.
The mechanism by which the PSAP sends acknowledgments and requests to Security considerations specific to the mechanism by which the PSAP
the vehicle requires authenticity considerations; when the PSAP sends acknowledgments and requests to the vehicle are discussed in
request is received within a session initiated by the vehicle as an the "Security Considerations" block of Section 14.3. In addition to
eCall emergency call placed over a cellular network, there is a that discussion, it's important to note that vehicles MAY decline to
higher degree of trust that the source is indeed a PSAP. If the PSAP carry out any requested action, e.g., if the vehicle is unable to
request is received in other situations, such as a call-back, the verify the certificate used to sign the request. The vehicle MAY use
trust issues in verifying that a call-back is indeed from a PSAP are any value in the reason registry in Section 14.8.3 to indicate why it
more complex (see the PSAP Callback document [RFC7090]). A further did not take an action (e.g., the generic "unable" or the more
safeguard (applicable regardless of which end initiated the call and specific "security-failure").
the means of the call) is for the PSAP or emergency service provider
to sign the body part using a certificate issued by a known emergency Data received from external sources inherently carries implementation
services certificate authority and for which the IVS can verify the risks including buffer overflows, which in many platforms can
root certificate. introduce remote code execution vulnerabilities; null characters can
corrupt strings, numeric values used for internal calculations can
result in underflow/overflow errors; malformed XML objects can expose
parsing bugs, etc. Implementations need to be cognizant of the
potential risks, observe best practices (e.g., good quality static
code analysis, fuzz testing, component isolation, avoiding use of
unsafe coding techniques, third-party attack tests, signed software,
over-the-air updates, etc.), and have multiple levels of protection.
Implementors need to be aware that, potentially, the data objects
described here and elsewhere might be malformed, might contain
unexpected characters, excessively long attribute values, elements,
etc. (This applies across the board, not just to the 'text'
attribute of a <request> element.)
Since this document depends on [I-D.ietf-ecrit-additional-data], the
security considerations discussed there apply here (see especially
the discussion of TLS, TLS versions, cypher suites, and PKI).
12. Privacy Considerations 12. Privacy Considerations
Since this document builds on [additional-data-draft], the data Since this document builds on [I-D.ietf-ecrit-additional-data], the
structures specified there, and the corresponding privacy data structures specified there, and the corresponding privacy
considerations discussed there, apply here as well. The MSD carries considerations discussed there, apply here as well. The MSD carries
some additional identifying and personal information (mostly about some additional identifying and personal information (mostly about
the vehicle and less about the owner), as well as location the vehicle and less about the owner), as well as location
information, and so needs to be protected against unauthorized information, and so needs to be protected against unauthorized
disclosure. Local regulations may impose additional privacy disclosure. Local regulations may impose additional privacy
protection requirements. The additional functionality enabled by protection requirements. The additional functionality enabled by
this document, such as access to vehicle camera streams, carries a this document, such as access to vehicle camera streams, carries a
burden of protection and so implementations need to be careful that burden of protection and so implementations need to be careful that
access is only provided within the context of an emergency call and access is only provided within the context of an emergency call and
to an emergency services provider, for example, within a vehicle- to an emergency services provider, for example, by verifying that the
initiated emergency call or by verifying that the request for camera request for camera access is signed by a certificate issued by an
access is signed by a certificate issued by an emergency services emergency services registrar.
registrar.
Privacy considerations specific to the data structure containing
vehicle information are discussed in the "Security Considerations"
block of Section 14.2.
Privacy considerations specific to the mechanism by which the PSAP
sends acknowledgments and requests to the vehicle are discussed in
the "Security Considerations" block of Section 14.3.
13. XML Schema 13. XML Schema
This section defines the XML schema of the eCall control block. (The This section defines the XML schema of the eCall control block. (The
schema for the MSD can be found in EN 15722 [msd].) schema for the MSD can be found in EN 15722 [msd].)
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control" targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
skipping to change at page 27, line 39 skipping to change at page 28, line 15
</xs:choice> </xs:choice>
<xs:anyAttribute/> <xs:anyAttribute/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="ackType"> <xs:complexType name="ackType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded"> <xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="actionResult" minOccurs="0"> <xs:element name="actionResult" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:attribute name="action" <xs:attribute name="action"
type="xs:token" type="xs:token"
use="required"/> use="required"/>
<xs:attribute name="success" <xs:attribute name="success"
type="xs:boolean" type="xs:boolean"
use="required"/> use="required"/>
<xs:attribute name="reason" <xs:attribute name="reason"
type="xs:token"> type="xs:token">
<xs:annotation> <xs:annotation>
skipping to change at page 32, line 5 skipping to change at page 32, line 27
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of the XML content. Indicates the character encoding of the XML content.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
Section 3.2 of RFC 7303 [RFC7303]. Section 3.2 of RFC 7303 [RFC7303].
Security considerations: This content type carries metadata and Security considerations:
control information and requests, primarily from a Public Safety
Answering Point (PSAP) to an In-Vehicle System (IVS) during an This content type carries metadata and control information and
emergency call, and also capabilities from the IVS to the PSAP. requests, primarily from a Public Safety Answering Point (PSAP)
Metadata (such as an acknowledgment that data sent by the IVS to to an In-Vehicle System (IVS) during an emergency call, and
the PSAP was successfully received) has limited privacy and also capabilities from the IVS to the PSAP.
security implications. Control information (such as requests from
the PSAP that the vehicle perform an action) has some privacy and Metadata (such as an acknowledgment that data sent by the IVS
important security implications. The privacy concern arises from to the PSAP was successfully received) has limited privacy and
the ability to request the vehicle to transmit a data set, which security implications. Control information (such as requests
as described in Section 14.2, can contain personal information. from the PSAP that the vehicle perform an action) has some
The security implication is the ability to request the vehicle to privacy and important security implications. The privacy
perform an action. It is important that control information concern arises from the ability to request the vehicle to
originate only from a PSAP or other emergency services provider, transmit a data set, which as described in Section 14.2, can
and not from an impostor. The first safeguard for this is the contain personal information. The security concern is the
security of the cellular network over which the emergency call was ability to request the vehicle to perform an action. It is
placed. In particular, when the IVS initiates an eCall over a important that control information originate only from a PSAP
cellular network, the MNO routes the call to a PSAP. (Calls or other emergency services provider, and not be modified en-
placed using other means, such as Wi-Fi or over-the-top services, route. The level of integrity of the cellular network over
do not carry the same degree of trust.) Calls received by the which the emergency call is placed is important: when the IVS
IVS, such as a call-back from a PSAP, also do not carry the same initiates an eCall over a cellular network, it relies on the
degree of trust, since the current mechanisms are not ideal for MNO to route the call to a PSAP. (Calls placed using other
verifying that such a call is indeed from a PSAP in response to an means, such as Wi-Fi or over-the-top services, generally incur
emergency call placed by the IVS. See the discussion in higher levels of risk than calls placed over cellular
Section 11 and the PSAP Callback document [RFC7090]. A further networks.) A call-back from a PSAP incurs additional risk,
safeguard, and one applicable regardless of which end initiated since the current mechanisms are not ideal for verifying that
the call and the means of the call, is for the PSAP or emergency such a call is indeed a call-back from a PSAP in response to an
service provider to sign the body part using a certificate issued emergency call placed by the IVS. See the discussion in
by a known emergency services certificate authority and for which Section 11 and the PSAP Callback document [RFC7090]. One
the IVS can verify the root certificate. Sections 7 and Section 8 safeguard, applicable regardless of which end initiated the
of [I-D.ietf-ecrit-additional-data] contain more discussion. call and the means of the call, is for the PSAP or emergency
service provider to sign the body part using a certificate
issued by a known emergency services certificate authority and
for which the IVS can verify the root certificate.
Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data]
contain more discussion.
Interoperability considerations: None Interoperability considerations: None
Published specification: Annex C of EN 15722 [msd] Published specification: Annex C of EN 15722 [msd]
Applications which use this media type: Pan-European eCall Applications which use this media type: Pan-European eCall
compliant systems compliant systems
Additional information: None Additional information: None
skipping to change at page 33, line 4 skipping to change at page 33, line 30
Applications which use this media type: Pan-European eCall Applications which use this media type: Pan-European eCall
compliant systems compliant systems
Additional information: None Additional information: None
Magic Number: None Magic Number: None
File Extension: .xml File Extension: .xml
Macintosh file type code: 'TEXT' Macintosh file type code: 'TEXT'
Person and email address for further information: Randall Gellens, Person and email address for further information: Randall Gellens,
rg+ietf@qti.qualcomm.com rg+ietf@qti.qualcomm.com
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: The IETF ECRIT WG. Author: The IETF ECRIT WG.
Change controller: The IETF ECRIT WG. Change controller: The IETF ECRIT WG.
14.4. Registration of the 'eCall.MSD' entry in the Emergency Call 14.4. Registration of the 'eCall.MSD' entry in the Emergency Call
Additional Data Blocks registry Additional Data Blocks registry
This specification requests IANA to add the 'eCall.MSD' entry to the This specification requests IANA to add the 'eCall.MSD' entry to the
Emergency Call Additional Data Blocks registry (established by Emergency Call Additional Data Blocks registry (established by
[additional-data-draft]), with a reference to this document. [I-D.ietf-ecrit-additional-data]), with a reference to this document.
14.5. Registration of the 'eCall.control' entry in the Emergency Call 14.5. Registration of the 'eCall.control' entry in the Emergency Call
Additional Data Blocks registry Additional Data Blocks registry
This specification requests IANA to add the 'eCall.control' entry to This specification requests IANA to add the 'eCall.control' entry to
the Emergency Call Additional Data Blocks registry (established by the Emergency Call Additional Data Blocks registry (established by
[additional-data-draft]), with a reference to this document. [I-D.ietf-ecrit-additional-data]), with a reference to this document.
14.6. Registration of the emergencyCallData.eCall Info Package 14.6. Registration of the emergencyCallData.eCall Info Package
IANA is requested to add emergencyCallData.eCall to the Info Packages IANA is requested to add emergencyCallData.eCall to the Info Packages
Registry under "Session Initiation Protocol (SIP) Parameters", with a Registry under "Session Initiation Protocol (SIP) Parameters", with a
reference to this document. reference to this document.
14.7. URN Sub-Namespace Registration 14.7. URN Sub-Namespace Registration
14.7.1. Registration for urn:ietf:params:xml:ns:eCall 14.7.1. Registration for urn:ietf:params:xml:ns:eCall
skipping to change at page 37, line 43 skipping to change at page 38, line 14
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| ID | Description | | ID | Description |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| unsupported | The 'action' is not supported. | | unsupported | The 'action' is not supported. |
| | | | | |
| unable | The 'action' could not be accomplished. | | unable | The 'action' could not be accomplished. |
| | | | | |
| data-unsupported | The data item referenced in a 'send-data' | | data-unsupported | The data item referenced in a 'send-data' |
| | request is not supported. | | | request is not supported. |
| | |
| security-failure | The authenticity of the request or the |
| | authority of the requestor could not be |
| | verified. |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 4: eCall Reason Registry Table 4: eCall Reason Registry
14.8.4. eCall Lamp ID Registry 14.8.4. eCall Lamp ID Registry
This document creates a new sub-registry called "eCall Lamp ID This document creates a new sub-registry called "eCall Lamp ID
Registry" to standardize the names of automotive lamps (lights). As Registry" to standardize the names of automotive lamps (lights). As
defined in [RFC5226], this registry operates under "Expert Review" defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should determine that the proposed lamp name is rules. The expert should determine that the proposed lamp name is
skipping to change at page 39, line 31 skipping to change at page 40, line 24
Table 6: eCall Camera ID Registry Initial Values Table 6: eCall Camera ID Registry Initial Values
15. Contributors 15. Contributors
Brian Rosen was a co-author of the original document upon which this Brian Rosen was a co-author of the original document upon which this
document is based. document is based.
16. Acknowledgements 16. Acknowledgements
We would like to thank Bob Williams and Ban Al-Bakri for their We would like to thank Bob Williams and Ban Al-Bakri for their
feedback and suggestions, and Keith Drage for his review comments. feedback and suggestions, and Keith Drage, James Winterbottom, and
We would like to thank Michael Montag, Arnoud van Wijk, Gunnar Wes George for their review and comments. We would like to thank
Hellstrom, and Ulrich Dietz for their help with the original document Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and Ulrich Dietz
upon which this document is based. for their help with the original document upon which this document is
based.
17. Changes from Previous Versions 17. Changes from Previous Versions
17.1. Changes from draft-ietf-02 to draft-ietf-03 17.1. Changes from draft-ietf-04 to draft-ietf-05
o Reworked the security and privacy considerations material in the
document as a whole and in the MIME registation sections of the
MSD and control objects
o Clarified that the <actionResult> element can appear multiple
times within an <ack> element
o Fixed IMS definition
o Added clarifying text for the 'msgid' attribute
17.2. Changes from draft-ietf-03 to draft-ietf-04
o Added Privacy Considerations section
o Reworded most uses of non-normative "may", "should", "must", and
"recommended."
o Fixed nits in examples
17.3. Changes from draft-ietf-02 to draft-ietf-03
o Added request to enable cameras o Added request to enable cameras
o Improved examples and XML schema o Improved examples and XML schema
o Clarifications and wording improvements o Clarifications and wording improvements
17.2. Changes from draft-ietf-01 to draft-ietf-02 17.4. Changes from draft-ietf-01 to draft-ietf-02
o Added clarifying text reinforcing that the data exchange is for o Added clarifying text reinforcing that the data exchange is for
small blocks of data infrequently transmitted small blocks of data infrequently transmitted
o Clarified that dynamic media is conveyed using SIP re-INVITE to o Clarified that dynamic media is conveyed using SIP re-INVITE to
establish a one-way media stream establish a one-way media stream
o Clarified that the scope is the needs of eCall within the SIP o Clarified that the scope is the needs of eCall within the SIP
emergency call environment emergency call environment
o Added informative statement that the document may be suitable for o Added informative statement that the document may be suitable for
reuse by other ACN systems reuse by other ACN systems
o Clarified that normative language for the control block applies to o Clarified that normative language for the control block applies to
both IVS and PSAP both IVS and PSAP
o Removed 'ref', 'supported-mime', and <media> elements o Removed 'ref', 'supported-mime', and <media> elements
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
17.3. Changes from draft-ietf-00 to draft-ietf-01 17.5. 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 in addition to eCall crash notification specifications in addition to eCall
o Added details of the eCall metadata and control functionality o Added details of the eCall metadata and control functionality
o Added IANA registration for the MIME content type for the eCall o Added IANA registration for the MIME content type for the eCall
control object control object
o Added IANA registries for protocol elements and tokens used in the o Added IANA registries for protocol elements and tokens used in the
eCall control object eCall control object
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
17.4. Changes from draft-gellens-03 to draft-ietf-00 17.6. Changes from draft-gellens-03 to draft-ietf-00
o Renamed from draft-gellens- to draft-ietf-. o Renamed from draft-gellens- to draft-ietf-.
o Added mention of and reference to ETSI TR "Mobile Standards Group o Added mention of and reference to ETSI TR "Mobile Standards Group
(MSG); eCall for VoIP" (MSG); eCall for VoIP"
o Added text to Introduction regarding migration/co-existence being o Added text to Introduction regarding migration/co-existence being
out of scope out of scope
o Added mention in Security Considerations that even if the network- o Added mention in Security Considerations that even if the network-
supplied location is just the cell site, this can be useful as a supplied location is just the cell site, this can be useful as a
sanity check on the IVS-supplied location sanity check on the IVS-supplied location
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
17.5. Changes from draft-gellens-02 to -03 17.7. Changes from draft-gellens-02 to -03
o Clarifications and editorial improvements. o Clarifications and editorial improvements.
17.6. Changes from draft-gellens-01 to -02 17.8. Changes from draft-gellens-01 to -02
o Minor wording improvements o Minor wording improvements
o Removed ".automatic" and ".manual" from o Removed ".automatic" and ".manual" from
"urn:service:test.sos.ecall" registration and discussion text. "urn:service:test.sos.ecall" registration and discussion text.
17.7. Changes from draft-gellens-00 to -01 17.9. 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 MIME subtypes, in accordance with changes to
[additional-data-draft] [I-D.ietf-ecrit-additional-data]
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
[EN_16072] [EN_16072]
CEN, , "Intelligent transport systems - eSafety - Pan- CEN, , "Intelligent transport systems - eSafety - Pan-
European eCall operating requirements", December 2011. European eCall operating requirements", December 2011.
skipping to change at page 42, line 18 skipping to change at page 43, line 33
<http://www.rfc-editor.org/info/rfc6881>. <http://www.rfc-editor.org/info/rfc6881>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, DOI 10.17487/RFC7303, July 2014,
<http://www.rfc-editor.org/info/rfc7303>. <http://www.rfc-editor.org/info/rfc7303>.
[TS22.101] [TS22.101]
3GPP, , "Technical Specification Group Services and System 3GPP, , "Technical Specification Group Services and System
Aspects; Service aspects; Service principles", . Aspects; Service aspects; Service principles", .
[additional-data-draft]
Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and
J. Winterbottom, "Additional Data related to an Emergency
Call", draft-ietf-ecrit-additional-data-11 (work in
progress), July 2013.
[msd] CEN, , "Intelligent transport systems -- eSafety -- eCall [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall
minimum set of data (MSD), EN 15722", June 2011. minimum set of data (MSD), EN 15722", June 2011.
18.2. Informative references 18.2. Informative references
[CEN] "European Committee for Standardization", [CEN] "European Committee for Standardization",
<http://www.cen.eu>. <http://www.cen.eu>.
[I-D.ietf-ecrit-car-crash]
Gellens, R., Rosen, B., and H. Tschofenig, "Next-
Generation Vehicle-Initiated Emergency Calls", draft-ietf-
ecrit-car-crash-03 (work in progress), July 2015.
[MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for
VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04),
April 2014. April 2014.
[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.
skipping to change at page 43, line 22 skipping to change at page 44, line 38
December 2014, <http://www.rfc-editor.org/info/rfc7378>. December 2014, <http://www.rfc-editor.org/info/rfc7378>.
[SDO-3GPP] [SDO-3GPP]
"3d Generation Partnership Project", "3d Generation Partnership Project",
<http://www.3gpp.org/>. <http://www.3gpp.org/>.
[SDO-ETSI] [SDO-ETSI]
"European Telecommunications Standards Institute (ETSI)", "European Telecommunications Standards Institute (ETSI)",
<http://www.etsi.org>. <http://www.etsi.org>.
[draft-ietf-ecrit-car-crash]
Gellens, R., Rosen, B., and H. Tschofenig, "Next-
Generation Vehicle-Initiated Emergency Calls", draft-ietf-
ecrit-car-crash (work in progress), March 2015.
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego 92651 San Diego 92651
US US
Email: rg+ietf@randy.pensive.org Email: rg+ietf@randy.pensive.org
Hannes Tschofenig Hannes Tschofenig
(Individual) (Individual)
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 47 change blocks. 
151 lines changed or deleted 208 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/