< draft-ietf-ecrit-ecall-01.txt   draft-ietf-ecrit-ecall-02.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 29, 2015 (no affiliation) Expires: September 8, 2015 (no affiliation)
October 26, 2014 March 7, 2015
Next-Generation Pan-European eCall Next-Generation Pan-European eCall
draft-ietf-ecrit-ecall-01.txt draft-ietf-ecrit-ecall-02.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 by 2015 in calls placed by vehicles. eCall deployment is required in the very
European Union member states, and eCall (and eCall-compatible near future in European Union member states, and eCall (and eCall-
systems) are also being deployed in other regions. eCall provides an compatible systems) are also being deployed in other regions. eCall
integrated voice path and a standardized set of vehicle, sensor provides an integrated voice path and a standardized set of vehicle,
(e.g., crash related), and location data. An eCall is recognized and sensor (e.g., crash related), and location data. An eCall is
handled as a specialized form of emergency call and is routed to a recognized and handled as a specialized form of emergency call and is
specialized eCall-capable Public Safety Answering Point (PSAP) routed to a specialized eCall-capable Public Safety Answering Point
capable of processing the vehicle data and trained in handling (PSAP) capable of processing the vehicle data and trained in handling
emergency calls from vehicles. emergency calls from vehicles.
Currently, eCall functions over circuit-switched cellular telephony; Currently, eCall functions over circuit-switched cellular telephony;
work on next-generation eCall (NG-eCall, sometimes called packet- work on next-generation eCall (NG-eCall, sometimes called packet-
switched eCall or PS-eCall) is now in process, and this document switched eCall or PS-eCall) is now in process, and this document
assists in that work by describing how to support eCall within the assists in that work by describing how to support eCall within the
IP-based emergency services infrastructure. IP-based emergency services infrastructure.
This document also registers a MIME Content Type and an Emergency This document also registers a MIME Content Type and an Emergency
Call Additional Data Block for the eCall vehicle data. Call Additional Data Block for the eCall vehicle data.
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 29, 2015. This Internet-Draft will expire on September 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6
5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . 12 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.2. The 'capabilities' Element . . . . . . . . . . . . . 13 9.1.2. The 'capabilities' Element . . . . . . . . . . . . . 14
9.1.2.1. Child Elements of the 'capabilities' Element . . 14 9.1.2.1. Child Elements of the 'capabilities' Element . . 14
9.1.3. The 'request' Element . . . . . . . . . . . . . . . . 14 9.1.3. The 'request' Element . . . . . . . . . . . . . . . . 15
9.1.3.1. Attributes of the 'request' Element . . . . . . . 14 9.1.3.1. Attributes of the 'request' Element . . . . . . . 15
9.1.3.2. Child Elements of the 'request' Element . . . . . 16 9.1.3.2. Child Elements of the 'request' Element . . . . . 16
9.2. The emergencyCallData.eCall INFO package . . . . . . . . 17 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 16
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13.1. Service URN Registrations . . . . . . . . . . . . . . . 22 13.1. Service URN Registrations . . . . . . . . . . . . . . . 20
13.2. MIME Content-type Registration for 13.2. MIME Content-type Registration for
'application/emergencyCallData.eCall.MSD+xml' . . . . . 22 'application/emergencyCallData.eCall.MSD+xml' . . . . . 21
13.3. MIME Content-type Registration for 13.3. MIME Content-type Registration for
'application/emergencyCallData.eCall.control+xml' . . . 24 'application/emergencyCallData.eCall.control+xml' . . . 22
13.4. Registration of the 'eCall.MSD' entry in the Emergency 13.4. Registration of the 'eCall.MSD' entry in the Emergency
Call Additional Data Blocks registry . . . . . . . . . . 25 Call Additional Data Blocks registry . . . . . . . . . . 24
13.5. Registration of the 'eCall.control' entry in the 13.5. Registration of the 'eCall.control' entry in the
Emergency Call Additional Data Blocks registry . . . . . 25 Emergency Call Additional Data Blocks registry . . . . . 24
13.6. Registration of the emergencyCallData.eCall Info Package 26 13.6. Registration of the emergencyCallData.eCall Info Package 24
13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 26 13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 24
13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 26 13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 24
13.7.2. Registration for 13.7.2. Registration for
urn:ietf:params:xml:ns:eCall:control . . . . . . . . 26 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 25
13.8. Registry creation . . . . . . . . . . . . . . . . . . . 27 13.8. Registry creation . . . . . . . . . . . . . . . . . . . 26
13.8.1. eCall Control Action Registry . . . . . . . . . . . 27 13.8.1. eCall Control Action Registry . . . . . . . . . . . 26
13.8.2. eCall Static Message Registry . . . . . . . . . . . 28 13.8.2. eCall Static Message Registry . . . . . . . . . . . 27
13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 29 13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 28
13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 30 13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 28
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
16. Changes from Previous Versions . . . . . . . . . . . . . . . 31 16. Changes from Previous Versions . . . . . . . . . . . . . . . 30
16.1. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 31 16.1. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 30
16.2. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 32 16.2. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 30
16.3. Changes from draft-gellens-02 to -03 . . . . . . . . . . 32 16.3. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 30
16.4. Changes from draft-gellens-01 to -02 . . . . . . . . . . 32 16.4. Changes from draft-gellens-02 to -03 . . . . . . . . . . 31
16.5. Changes from draft-gellens-00 to -01 . . . . . . . . . . 32 16.5. Changes from draft-gellens-01 to -02 . . . . . . . . . . 31
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 16.6. Changes from draft-gellens-00 to -01 . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 33 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.2. Informative references . . . . . . . . . . . . . . . . . 34 17.1. Normative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 17.2. Informative references . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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:
3GPP: 3rd Generation Partnership Project +--------+----------------------------------------+
CEN: European Committee for Standardization | Term | Expansion |
EENA: European Emergency Number Association +--------+----------------------------------------+
ESInet: Emergency Services IP network | 3GPP | 3rd Generation Partnership Project |
IMS: Internet Multimedia Subsystem | CEN | European Committee for Standardization |
IVS: In-Vehicle System | EENA | European Emergency Number Association |
MNO: Mobile Network Operator | ESInet | Emergency Services IP network |
MSD: Minimum Set of Data | IMS | Internet Multimedia Subsystem |
PSAP: Public Safety Answering Point | IVS | In-Vehicle System |
| MNO | Mobile Network Operator |
| MSD | Minimum Set of Data |
| 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
as packet-switched eCall (PS-eCall) and all-IP eCall). eCall itself as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP
is specified by 3GPP and CEN and these specifications include far framework for emergency calls, as described in [RFC6443] and
greater scope than is covered here. [RFC6881]. eCall itself is specified by 3GPP and CEN and these
specifications include far greater scope than is covered here.
The eCall service operates over cellular wireless communication, but The eCall service operates over cellular wireless communication, but
this document does not address cellular-specific details, nor client this document does not address cellular-specific details, nor client
domain selection (e.g., circuit-switched versus packet-switched). domain selection (e.g., circuit-switched versus packet-switched).
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, such as 3GPP IMS Emergency Calling. within a SIP-based environment (e.g., 3GPP IMS Emergency Calling).
The technical contents of this document may be suitable for use in
other vehicle-initiated emergency call systems, but this is out of
scope for this document.
Vehicles designed for multiple regions may need to support eCall and Vehicles designed for multiple regions may need to support eCall and
other Advanced Automatic Crash Notification systems, such as other Advanced Automatic Crash Notification systems, such as
described in [draft-ietf-ecrit-car-crash]. That system is compatible described in [draft-ietf-ecrit-car-crash]. That system is compatible
with eCall in most respects, differing primarily in the Request-URI with eCall, differing primarily in the specific data set that is
and the specific data block that is sent. 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
response. response.
The European Commission initiative of eCall was conceived in the late The European Commission initiative of eCall was conceived in the late
1990s, and has evolved to a European Parliament decision requiring 1990s, and has evolved to a European Parliament decision requiring
the implementation of compliant in-vehicle systems (IVS) in new the implementation of compliant in-vehicle systems (IVS) in new
vehicles and the deployment of eCall in the European Member States in vehicles and the deployment of eCall in the European Member States in
2015. eCall (and eCall-compatible systems) are also being adopted in the very near future. eCall (and eCall-compatible systems) are also
other regions. being adopted in other regions.
The pan-European eCall system provides a standardized and mandated The pan-European eCall system provides a standardized and mandated
mechanism for emergency calls by vehicles. eCall establishes mechanism for emergency calls by vehicles. eCall establishes
procedures for such calls to be placed by in-vehicle systems, procedures for such calls to be placed by in-vehicle systems,
recognized and processed by the network, and routed to a specialized recognized and processed by the network, and routed to a specialized
PSAP where the vehicle data is available to assist the call taker in PSAP where the vehicle data is available to assist the call taker in
assessing and responding to the situation. eCall provides a standard assessing and responding to the situation. eCall provides a standard
set of vehicle, sensor (e.g., crash related), and location data. set of vehicle, sensor (e.g., crash related), and location data.
An eCall may be either user-initiated or automatically triggered. An eCall may be either user-initiated or automatically triggered.
Automatically triggered eCalls indicate a car crash or some other Automatically triggered eCalls indicate a car crash or some other
serious incident (e.g., a fire) and carry a greater presumption of serious incident and carry a greater presumption of risk of injury.
risk of injury. Manually triggered eCalls may be reports of serious Manually triggered eCalls may be reports of serious hazards and are
hazards and are likely to require a different response than an likely to require a different response than an automatically
automatically triggered eCall. Manually triggered eCalls are also triggered eCall. Manually triggered eCalls are also more likely to
more likely to be false (e.g., accidental) calls and may thus be be false (e.g., accidental) calls and may thus be subject to
subject to different handling by the PSAP. different handling by the PSAP.
Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN])
as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in
the call setup mark the call as an eCall, and further indicate if the the call setup mark the call as an eCall, and further indicate if the
call was automatically or manually triggered. The call is routed to call was automatically or manually triggered. The call is routed to
an eCall-capable PSAP, a voice channel is established between the an eCall-capable PSAP, a voice channel is established between the
vehicle and the PSAP, and an eCall in-band modem is used to carry a vehicle and the PSAP, and an eCall in-band modem is used to carry a
defined set of vehicle, sensor (e.g., crash related), and location defined set of vehicle, sensor (e.g., crash related), and location
data (the Minimum Set of Data or MSD) within the voice channel. The data (the Minimum Set of Data or MSD) within the voice channel. The
same in-band mechanism is used for the PSAP to acknowledge successful same in-band mechanism is used for the PSAP to acknowledge successful
skipping to change at page 5, line 38 skipping to change at page 6, line 5
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 [additional-data-draft] are used to provide the signaling and
data exchange of the next generation of pan-European eCall. data exchange of the next generation of pan-European eCall.
NG-eCall is a 3GPP IMS emergency call with additional elements The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency
identifying the call as an eCall and as carrying eCall data and with calling with additional elements identifying the call as an eCall and
mechanisms for carrying the data. 3GPP IMS emergency services as carrying eCall data and with mechanisms for carrying the data.
support multimedia, providing the ability to carry voice, text, and 3GPP IMS emergency services support multimedia, providing the ability
video. This capability is referred to within 3GPP as Multimedia to carry voice, text, and video. This capability is referred to
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-
generation eCall, legacy eCall, or both. This transition period generation eCall, legacy eCall, or both. This transition period
might last several years or longer. The issue of migration/co- might last several years or longer. The issue of migration/co-
existence during the transition period is very important but is existence during the transition period is very important but is
outside the scope of this document. The ETSI TR "Mobile Standards outside the scope of this document. The ETSI TR "Mobile Standards
Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in
Clause 7. Clause 7.
4. eCall Requirements 4. eCall Requirements
Overall eCall requirements are specified by by by CEN in [EN_16072] Overall eCall requirements are specified by CEN in [EN_16072] and by
and by 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements specific to
specific to vehicle data are contained in EN 15722 [msd]. For vehicle data are contained in EN 15722 [msd]. For convenience, the
convenience, the requirements most applicable to the limited scope of requirements most applicable to the limited scope of this document
this document are summarized very briefly below. are summarized very briefly below.
eCall requires: eCall requires:
o The call be recognized as an eCall (which is inherently an o The call be recognized as an eCall (which is inherently an
emergency call) emergency call)
o The call setup indicates if the call was manually or automatically o The call setup indicates if the call was manually or automatically
triggered triggered
o A voice channel between the vehicle and the PSAP o A voice channel between the vehicle and the PSAP
o Carrying the MSD intrinsically with the call (the MSD needs to be o Carrying the MSD intrinsically with the call (the MSD needs to be
available to the same call-taker as the voice) available to the same call-taker as the voice)
skipping to change at page 7, line 28 skipping to change at page 7, line 40
blocks of data to a SIP emergency call. This document makes use of blocks of data to a SIP emergency call. This document makes use of
that mechanism to carry the eCall MSD in a SIP emergency call. 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 [additional-data-draft]) to enable the MSD to be recognized as such
in a SIP-based eCall emergency call. in a SIP-based eCall emergency call.
Note that if additional data sets are defined and registered (e.g.,
in the future or in other regions) and transmitted using the same
mechanisms, the size and frequency of transmission during a session
needs to be evaluated to be sure it is appropriate to use the
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
emergency call which carries the eCall flag (indicating that the call emergency call which carries the eCall flag (indicating that the call
is an eCall and also if the call was manually or automatically is an eCall and also if the call was manually or automatically
triggered); the mobile network operator (MNO) recognizes the eCall triggered); the mobile network operator (MNO) recognizes the eCall
flag and routes the call to an eCall-capable PSAP; vehicle data is flag and routes the call to an eCall-capable PSAP; vehicle data is
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).
skipping to change at page 10, line 38 skipping to change at page 11, line 11
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
eCall-specific data to the IVS and the IVS to respond. If control eCall-specific data to the IVS and the IVS to respond. If control
data sent in a response message requests the IVS to send a new MSD or data sent in a response message requests the IVS to send a new MSD or
other data block, the IVS can do so in an INFO message within the other data block, or to perform an action other than sending data,
session (it could also use re-INVITE but that is unnecessary when no the IVS can send the requested data or an acknowledgment regarding
aspect of the session or media is changing). the action in an INFO message within the session (it could also use
re-INVITE but that is unnecessary when no aspect of the session or
media is changing).
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
skipping to change at page 11, line 33 skipping to change at page 12, line 8
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
(in the initial INVITE or subsequently if desired) to (in the initial INVITE or subsequently if desired) to
inform the PSAP of the vehicle capabilities. Child inform the PSAP of the vehicle capabilities. Child
elements contain all actions and data types supported elements contain all actions and data types supported
by the vehicle . by the vehicle .
request Used in a control block sent by the PSAP to the IVS, to request Used in a control block sent by the PSAP to the IVS, to
request the vehicle to perform an action. request the vehicle to perform an action.
Mandatory Actions (the IVS MUST support): Mandatory Actions (the IVS and the PSAP MUST support):
o Transmit data object o Transmit data object
Optional Actions (the IVS 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 Play dynamic audio (media supplied in SIP body part or in action)
o Flash lights, honk horn o Flash lights, honk horn
The 'ack' element indicates the object being acknowledged, and The 'ack' element indicates the object being acknowledged, and
reports success or failure. reports success or failure.
The 'capabilities' element has child 'request' elements to indicate The 'capabilities' element has child 'request' elements to indicate
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 child elements to supply any needed information, and MAY contain a 'text' child
'text' and 'media' to contain the text or media for a dynamic element to contain the text for a dynamic message. The 'action'
message. The 'action' attribute is mandatory and indicates the attribute is mandatory and indicates the specific action. An IANA
specific action. An IANA registry is established by this document in registry is established by this document in Section 13.8.1 to contain
Section 13.8.1 to contain the allowed values. the allowed values.
New elements, child elements, and attributes can be defined with New elements, child elements, and attributes can be defined with
their own sub-namespaces. IANA registries are used to specify the their own sub-namespaces. IANA registries are used to specify the
permitted values of several elements and attributes. These permitted values of several elements and attributes. These
mechanisms allow for extension. mechanisms allow for extension.
The control block does not contain a 'request' action to play dynamic
media (such as a pre-recorded audio message). The SIP re-INVITE
mechanism can be used to establish a one-way media stream for this
purpose.
9.1.1. The 'ack' Element 9.1.1. The 'ack' Element
The 'ack' element is transmitted by the PSAP to acknowledge receipt The 'ack' element is transmitted by the PSAP to acknowledge receipt
of an eCall data object. An 'ack' element sent by a PSAP references of an eCall data object. An 'ack' element sent by a PSAP references
the unique ID of the data object that was sent by the IVS, and the unique ID of the data object that was sent by the IVS, and
further indicates if the PSAP considers the receipt successful or further indicates if the PSAP considers the receipt successful or
not. The 'ack' element is also transmitted by the IVS to the PSAP to not. The 'ack' element is also transmitted by the IVS to the PSAP to
acknowledge receipt of a 'request' element that requested the IVS to acknowledge receipt of a 'request' element that requested the IVS to
perform an action other than transmitting a data object (e.g., a perform an action other than transmitting a data object (e.g., a
request to display a message would be acknowledged, but a request to request to display a message would be acknowledged, but a request to
skipping to change at page 14, line 18 skipping to change at page 14, line 43
Name: request Name: request
Usage: Mandatory Usage: Mandatory
Description: The 'capabilities' element contains a <request> child Description: The 'capabilities' element contains a <request> child
element per action supported by the vehicle. Because support for element per action supported by the vehicle. Because support for
a 'send-data' action is REQUIRED, a <request> child element with a a 'send-data' action is REQUIRED, a <request> child element with a
"send-data" 'action' attribute is also REQUIRED. The 'supported- "send-data" 'action' attribute is also REQUIRED. The 'supported-
datatype' attribute is REQUIRED in this <request> element and MUST datatype' attribute is REQUIRED in this <request> element and MUST
contain all eCall data blocks supported by the IVS. Currently, contain all eCall data blocks supported by the IVS. Currently,
only the 'eCall.MSD' datatype is defined. All other actions are only the 'eCall.MSD' datatype is defined. All other actions are
OPTIONAL. If the "play-audio" action is supported, a <request> OPTIONAL. If the "msg-static" action is supported, a <request>
child element with a "play-audio" 'action' attribute is sent, with child element with a "msg-static" 'action' attribute is sent, with
a 'supported-mime' attribute set to all MIME content types a 'msgid' attribute set to the highest supported static message
supported by the vehicle. If the "msg-static" action is supported by the vehicle.
supported, a <request> child element with a "msg-static" 'action' Examples: <request action="send-data" supported-datatype="eCall.MSD"
attribute is sent, with a 'msgid' attribute set to the highest />
supported static message supported by the vehicle.
Examples: <request action="play-audio" supported-mime="audio/3gpp;
audio/3gpp2; audio/amr; audio/evrc"/>
<request action="send-data" supported-datatype="eCall.MSD" />
<request action="send-data" supported-datatype="eCall.MSD; VEDS; <request action="send-data" supported-datatype="eCall.MSD; VEDS;
eCall.type2" /> eCall.type2" />
<request action="msg-dynamic"/> <request action="msg-dynamic"/>
<request action="msg.static" msgid="17" /> <request action="msg.static" msgid="17" />
9.1.3. The 'request' Element 9.1.3. The 'request' Element
A 'request' element appears one or more times on its own or as a A 'request' element appears one or more times on its own or as a
child of a 'capabilities' element. The following attributes and child of a 'capabilities' element. The following attributes and
child elements may be used: child elements may be used:
skipping to change at page 15, line 30 skipping to change at page 15, line 51
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]. [additional-data-draft].
Example: datatype="eCall.MSD" Example: datatype="eCall.MSD"
Name: ref
Usage: Conditional
Type: URI
Description: Mandatory with a "play-audio" action. References the
audio media to be played. A CID is used to reference an audio
body part contained in the same SIP message. An external URL
(e.g., HTTP) is used to reference external content. Note that
external references might not be accessible by the vehicle due to
a variety of transient or permanent conditions.
Example: ref="cid:5432154321@example.gov"
Name: supported-mime
Usage: Conditional
Type: token
Description: Used with a 'play-audio' action in a 'request' element
that is a child of a 'capability' element, this attribute lists
all MIME content types/subtypes that the vehicle can render.
Multiple values are separated with a semicolon.
Example: supported-mime="audio/3gpp; audio/3gpp2; audio/amr; audio/
evrc"
Name: supported-datatype Name: supported-datatype
Usage: Conditional Usage: Conditional
Type: token Type: token
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 [additional-data-draft]. Multiple values are separated with a
skipping to change at page 16, line 47 skipping to change at page 16, line 46
Usage: Conditional Usage: Conditional
Type: string Type: string
Description: Used within a <request action="msg-dynamic"> element to Description: Used within a <request action="msg-dynamic"> element to
contain the text to be displayed and/or spoken (via text-to- contain the text to be displayed and/or spoken (via text-to-
speech) for the vehicle occupants. speech) for the vehicle occupants.
Example: <text>Emergency authorities are aware of your incident and Example: <text>Emergency authorities are aware of your incident and
location. Due to a multi-vehicle incident in your area, no one is location. Due to a multi-vehicle incident in your area, no one is
able to speak with you right now. Please remain calm. We will able to speak with you right now. Please remain calm. We will
assist you soon.</text> assist you soon.</text>
Name: media
Usage: Optional
Type: base64Binary
Attribute: xmime:contentType (mandatory; contains the MIME content
type of the media)
Description: MAY be used within a <request action="play-dynamic">
element to contain the media to be rendered for the vehicle
occupants. (The media may also be located in its own body part
and referenced by a CID URL, or may be external and referenced
with an external URL.)
Example: <media>Rk9STQAABeZBSUZGQ09NTQAAABIAAgAAAW4AEEANrEQAAAAAAABT
U05EAAAFwAAA
AAAAAAAAAAAAABHqEeoiISIhL1ovWjiPOI89Gz0bPK48rjdmN2YtxC3EIJ0gnRET
ERMAagBq7/3v/eEd4R3U7dTtzGTMZMghyCHIaMhozSPNI9XY1djh0uHS8ALwAv88
/zwOSQ5JG/Yb9icwJzAvFC8UMxkzGTLxMvEuuS65JtEm0RvtG+0O/g7+AQoBCvND
80PmtOa03F3cXdUL1QvRR9FH0VbRVtUa1RrcQ9xD5ifmJ/H48fj+uv66C10LXRbi
FuIgayBrJzAnMCq4KrgqwirCJ2MnYyDpIOkX5hfmDSENIQF4AXj15fXl60zrTOKG
4obcQ9xD2PPY89jV2NXb1dvV4bThtOno6ejzvPO8/mT+ZAj9CP0SuRK5Gs4aziCY
IJgjsyOzI+Uj5SE0ITQb4xvjFHMUcwt1C3UBugG6+AT4BO8Q7xDnoeeh4kXiRd9e
317fId8h4YbhhuZU5lTtGu0a9Un1Sf4y/jIHGwcbD08PTxYnFicbHxsfHdUd1R4a
Hhob+xv7F6EXoRF4EXgKAgoCAdgB2Pmz+bPyK/Ir697r3udG50bkvuS+5G3kbeZP
5k/qQepB79rv2vap9qn+Hv4eBZIFkgyADIASTxJPFowWjBjsGOwZQhlCF5IXkhQE
FAQO6g7qCLcItwHnAef7DvsO9Lf0t+9c71zrb+tv6TfpN+jd6N3qX+pf7ZPtk/I6
8jr34Pfg/h7+HgRgBGAKNAo0Dx0PHRK+Er4U0hTSFTIVMhPcE9wQ9RD1DL0MvQeT
B5MB4gHi/Cj8KPbL9svyRPJE7uju6Oz87Pzsl+yX7crtyvBn8Gf0P/Q/+PT49P4o
/igDZQNlCE0ITQx7DHsPlA+UEWQRZBHCEcIQuBC4DlgOWArfCt8GkwaTAc4Bzv0E
/QT4gfiB9Kj0qPHL8cvwIPAg77vvu/Cn8Kfyy/LL9fn1+fnh+eH+PP48AqICogbG
BsYKTQpNDPQM9A6BDoEO5Q7lDhIOEgwmDCYJRAlEBbEFsQG6Abr9r/2v+eb55vap
9qn0NfQ18rvyu/Jd8l3zFvMW9NX01fdx93H6tPq0/lX+VQIFAgUFfgV+CH8IfwrB
CsEMGwwbDHsMewvaC9oKQwpDB+MH4wTtBO0BnAGc/jz+PPsI+wj4SvhK9jX2NfTu
9O70lfSV9SH1IfaQ9pD4ufi5+237bf5z/nMBiAGIBHoEegcCBwII7gjuChsKGwp2
CnYJ+An4CK0IrQa7BrsEQgRCAX0Bff6r/qv7+vv6+aT5pPfg9+D2xvbG9m32bfba
9tr4BPgE+cz5zPwJ/An+kv6SASgBKAOhA6EFxQXFB2oHaghwCHAIwQjBCGEIYQdW
B1YFuwW7A6sDqwFfAV/+//7//L/8v/rD+sP5P/k/+E/4T/f59/n4T/hP+T/5P/q5
+rn8lvyW/rX+tQDeAN4C8gLyBMAEwAYkBiQHBwcHB1YHVgcMBwwGNAY0BN4E3gMt
Ay0BPAE8/0H/Qf1Z/Vn7tPu0+mn6afmV+ZX5SvlK+Yv5i/pK+kr7gfuB/Q79Dv7T
/tMAoQChAmACYAPoA+gFGwUbBd4F3gYkBiQF7QXtBT0FPQQkBCQCuwK7AR4BHv94
/3j93P3c/HP8c/tZ+1n6pfql+mT6ZPqR+pH7Mfsx/C38Lf14/Xj+8f7xAHQAdAHs
AewDNwM3BDgEOATjBOMFJQUlBP0E/QRwBHADgwODAlsCWwEBAQH/oP+g/kb+Rv0Y
/Rj8KPwo+4v7i/tK+0r7bftt+/D78PzE/MT90v3S/wn/CQBRAFEBjQGNAqcCpwOD
A4MEFQQVBEwETAQuBC4DugO6AwEDAQIFAgUA6ADo/7//v/6c/pz9m/2b/M78zvxL
/Ev8DvwO/Cj8KPyR/JH9O/07/iP+I/8n/ycAMgAyATwBPAIuAi4C6ALoA2UDZQOc
A5wDgwODAygDKAKNAo0BugG6AM4Azv/Y/9j+4v7i</media>
9.2. The emergencyCallData.eCall INFO package 9.2. The emergencyCallData.eCall INFO package
This document registers the 'emergencyCallData.eCall' INFO package. This document registers the 'emergencyCallData.eCall' INFO package.
Both endpoints (the IVS and the PSAP equipment) set the Recv-Info Both endpoints (the IVS and the PSAP equipment) set the Recv-Info
header field to 'emergencyCallData.eCall' per [RFC6086] to indicate header field to 'emergencyCallData.eCall' per [RFC6086] to indicate
ability to receive INFO messages carrying eCall data or control ability to receive INFO messages carrying eCall data or control
blocks. blocks.
Support for the 'emergencyCallData.eCall' INFO package indicates the Support for the 'emergencyCallData.eCall' INFO package indicates the
ability to receive eCall data and control blocks, which are carried ability to receive eCall data and control blocks, which are carried
skipping to change at page 18, line 40 skipping to change at page 17, line 42
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 [additional-data-draft], emergency call related additional data
MAY be included in any SIP message. Hence, notwithstanding MAY be included in any SIP request or response message that may
Section 4.3.2. of [RFC6086], INFO response messages MAY contain eCall contain a body. Hence, notwithstanding Section 4.3.2. of [RFC6086],
data or control blocks, provided they are included as described in INFO response messages MAY contain eCall data or control blocks,
this document (with a Call-Info header field containing a CID URL provided they are included as described in this document (with a
referencing the unique identifier of the body part, and a 'purpose' Call-Info header field containing a CID URL referencing the unique
parameter identifying the block). When eCall data or control blocks identifier of the body part, and a 'purpose' parameter identifying
are included in an INFO response message, this is done per the block). When eCall data or control blocks are included in an
[additional-data-draft] and this document, and not under [RFC6086]; INFO response message, this is done per [additional-data-draft] and
that is, they are included as emergency call additional data, not as this document, and not under [RFC6086]; that is, they are included as
an INFO package associated data. emergency call additional data, not as an INFO package associated
data.
10. Examples 10. Examples
Figure 3 shows an eCall. The call uses the request URI Figure 3 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 21, line 32 skipping to change at page 20, line 32
<?xml version="1.0" ?> <?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://example.com/ct-required" xmlns:tns="http://example.com/ct-required"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
targetNamespace="http://example.com/ct-required"> targetNamespace="http://example.com/ct-required">
<xs:import namespace="http://www.w3.org/2005/05/xmlmime" <xs:import namespace="http://www.w3.org/2005/05/xmlmime"
schemaLocation="http://www.w3.org/2005/05/xmlmime"/> schemaLocation="http://www.w3.org/2005/05/xmlmime"/>
<!-- This element has binary content and requires the
xmime:contentType attribute which indicates the
content-type of the binary element -->
<xs:element name="media">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary" >
<xs:attribute ref="xmime:contentType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema> </xs:schema>
Figure 5: eCall Control Block Schema Figure 5: eCall Control Block Schema
13. IANA Considerations 13. IANA Considerations
13.1. Service URN Registrations 13.1. Service URN Registrations
IANA is requested to register the URN 'urn:service:sos.ecall' under IANA is requested to register the URN 'urn:service:sos.ecall' under
the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].
skipping to change at page 28, line 11 skipping to change at page 26, line 51
Name: The identifier to be used in the 'action' attribute of an Name: The identifier to be used in the 'action' attribute of an
eCall control 'request' element. eCall control 'request' element.
Description: A description of the action. In most cases this will Description: A description of the action. In most cases this will
be a reference to a published and stable document. The be a reference to a published and stable document. The
description MUST specify if any attributes or child elements are description MUST specify if any attributes or child elements are
optional or mandatory, and describe the action to be taken by the optional or mandatory, and describe the action to be taken by the
vehicle. vehicle.
The initial set of values is listed in Table 1. The initial set of values is listed in Table 2.
+-------------+------------------------------+ +-------------+------------------------------+
| Name | Description | | Name | Description |
+-------------+------------------------------+ +-------------+------------------------------+
| send-data | Section xxx of this document | | send-data | Section xxx of this document |
| | | | | |
| msg-static | Section xxx of this document | | msg-static | Section xxx of this document |
| | | | | |
| msg-dynamic | Section xxx of this document | | msg-dynamic | Section xxx of this document |
| | | | | |
| play-audio | Section xxx of this document |
| | |
| honk | Section xxx of this document | | honk | Section xxx of this document |
| | | | | |
| lamp | Section xxx of this document | | lamp | Section xxx of this document |
+-------------+------------------------------+ +-------------+------------------------------+
Table 1: eCall Control Action Registry Initial Values Table 2: eCall Control Action Registry Initial Values
13.8.2. eCall Static Message Registry 13.8.2. eCall Static Message Registry
This document creates a new sub-registry called "eCall Static Message This document creates a new sub-registry called "eCall Static Message
Registry". Because all compliant vehicles are expected to support Registry". Because all compliant vehicles are expected to support
all static messages translated into all languages supported by the all static messages translated into all languages supported by the
vehicle, it is important to limit the number of such messages. As vehicle, it is important to limit the number of such messages. As
defined in [RFC5226], this registry operates under "Publication defined in [RFC5226], this registry operates under "Publication
Required" rules, which require a stable, public document and imply Required" rules, which require a stable, public document and imply
expert review of the publication. The expert should determine that expert review of the publication. The expert should determine that
skipping to change at page 29, line 11 skipping to change at page 27, line 49
Message: The text of the message. Messages are listed in the Message: The text of the message. Messages are listed in the
registry in English; vehicles are expected to implement registry in English; vehicles are expected to implement
translations into languages supported by the vehicle. translations into languages supported by the vehicle.
When new messages are added to the registry, the message text is When new messages are added to the registry, the message text is
determined by the registrant; IANA assigns the IDs. Each message is determined by the registrant; IANA assigns the IDs. Each message is
assigned a consecutive integer value as its ID. This allows an IVS assigned a consecutive integer value as its ID. This allows an IVS
to indicate by a single integer value that it supports all messages to indicate by a single integer value that it supports all messages
with that value or lower. with that value or lower.
The initial set of values is listed in Table 2. The initial set of values is listed in Table 3.
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
| ID | Message | | ID | Message |
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
| 1 | Emergency authorities are aware of your incident and | | 1 | Emergency authorities are aware of your incident and |
| | location. No one is free to speak with you right now. We | | | location. No one is free to speak with you right now. We |
| | will help you as soon as possible. | | | will help you as soon as possible. |
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
Table 2: eCall Static Message Registry Table 3: eCall Static Message Registry
13.8.3. eCall Reason Registry 13.8.3. eCall Reason Registry
This document creates a new sub-registry called "eCall Reason This document creates a new sub-registry called "eCall Reason
Registry" which contains values for the 'reason' attribute of the Registry" which contains values for the 'reason' attribute of the
'ActionResult' element. As defined in [RFC5226], this registry 'ActionResult' element. As defined in [RFC5226], this registry
operates under "Expert Review" rules. The expert should determine operates under "Expert Review" rules. The expert should determine
that the proposed reason is sufficiently distinguishable from other that the proposed reason is sufficiently distinguishable from other
reasons and that the proposed description is understandable and reasons and that the proposed description is understandable and
correctly worded. correctly worded.
The content of this registry includes: The content of this registry includes:
ID: A short string identifying the reason, for use in the 'reason' ID: A short string identifying the reason, for use in the 'reason'
attribute of an 'ActionResult' element. attribute of an 'ActionResult' element.
Description: A description of the reason. Description: A description of the reason.
The initial set of values is listed in Table 3. The initial set of values is listed in Table 4.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| 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. |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 3: eCall Reason Registry Table 4: eCall Reason Registry
13.8.4. eCall Lamp ID Registry 13.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
clearly understandable and is sufficiently distinguishable from other clearly understandable and is sufficiently distinguishable from other
lamp names. lamp names.
The content of this registry includes: The content of this registry includes:
Name: The identifier to be used in the 'lamp-ID' attribute of an Name: The identifier to be used in the 'lamp-ID' attribute of an
eCall control 'request' element. eCall control 'request' element.
Description: A description of the lamp (light). Description: A description of the lamp (light).
The initial set of values is listed in Table 4. The initial set of values is listed in Table 5.
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
| Name | Description | | Name | Description |
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
| head | The main lamps used to light the road ahead | | head | The main lamps used to light the road ahead |
| | | | | |
| interior | Interior lamp, often at the top center | | interior | Interior lamp, often at the top center |
| | | | | |
| fog-front | Front fog lamps | | fog-front | Front fog lamps |
| | | | | |
| fog-rear | Rear fog lamps | | fog-rear | Rear fog lamps |
| | | | | |
| brake | Brake indicator lamps | | brake | Brake indicator lamps |
| | | | | |
| position-front | Front position/parking/standing lamps | | position-front | Front position/parking/standing lamps |
| | | | | |
| position-rear | Rear position/parking/standing lamps | | position-rear | Rear position/parking/standing lamps |
| | | | | |
| 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: eCall Lamp ID Registry Initial Values Table 5: eCall Lamp ID Registry Initial Values
14. Contributors 14. 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.
15. Acknowledgements 15. 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 for his review comments.
We would like to thank Michael Montag, Arnoud van Wijk, Gunnar We would like to thank Michael Montag, Arnoud van Wijk, Gunnar
Hellstrom, and Ulrich Dietz for their help with the original document Hellstrom, and Ulrich Dietz for their help with the original document
upon which this document is based. upon which this document is based.
16. Changes from Previous Versions 16. Changes from Previous Versions
16.1. Changes from draft-ietf-00 to draft-ietf-01 16.1. Changes from draft-ietf-01 to draft-ietf-02
o Added further discussion of test calls o Added clarifying text reinforcing that the data exchange is for
small blocks of data infrequently transmitted
o Clarified that dynamic media is conveyed using SIP re-INVITE to
establish a one-way media stream
o Clarified that the scope is the needs of eCall within the SIP
emergency call environment
o Added informative statement that the document may be suitable for
reuse by other ACN systems
o Clarified that normative language for the control block applies to
both IVS and PSAP
o Removed 'ref', 'supported-mime', and 'media' elements
o Minor wording improvements and clarifications
16.2. Changes from draft-ietf-00 to draft-ietf-01
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
16.2. Changes from draft-gellens-03 to draft-ietf-00 16.3. 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
16.3. Changes from draft-gellens-02 to -03 16.4. Changes from draft-gellens-02 to -03
o Clarifications and editorial improvements. o Clarifications and editorial improvements.
16.4. Changes from draft-gellens-01 to -02 16.5. 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.
16.5. Changes from draft-gellens-00 to -01 16.6. 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] [additional-data-draft]
o Added reference to RFC 6443 o Added reference to RFC 6443
o Fixed bug that caused Figure captions to not appear o Fixed bug that caused Figure captions to not appear
17. References 17. References
17.1. Normative References 17.1. Normative References
[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 35, line 16 skipping to change at page 33, line 38
"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] [draft-ietf-ecrit-car-crash]
Gellens, R., Rosen, B., and H. Tschofenig, "Next- Gellens, R., Rosen, B., and H. Tschofenig, "Next-
Generation Vehicle-Initiated Emergency Calls", draft-ietf- Generation Vehicle-Initiated Emergency Calls", draft-ietf-
ecrit-car-crash (work in progress), October 2014. 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@qti.qualcomm.com Email: rg+ietf@qti.qualcomm.com
 End of changes. 73 change blocks. 
234 lines changed or deleted 175 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/