< draft-ietf-ecrit-ecall-07.txt   draft-ietf-ecrit-ecall-08.txt >
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Consultant
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: August 22, 2016 (Individual) Expires: January 2, 2017 Individual
February 19, 2016 July 1, 2016
Next-Generation Pan-European eCall Next-Generation Pan-European eCall
draft-ietf-ecrit-ecall-07.txt draft-ietf-ecrit-ecall-08.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, providing real-time communications and an
near future in European Union member states, and eCall (and eCall- integrated set of related data.
compatible systems) are also being deployed in other regions. eCall
provides an integrated voice path and a standardized set of vehicle,
sensor (e.g., crash related), and location data. An eCall is
recognized and handled as a specialized form of emergency call and is
routed to a specialized eCall-capable Public Safety Answering Point
(PSAP) capable of processing the vehicle data and trained in handling
emergency calls from vehicles.
Currently, eCall functions over circuit-switched cellular telephony;
work on next-generation eCall (NG-eCall, sometimes called packet-
switched eCall or PS-eCall) is now in process, and this document
assists in that work by describing how to support eCall within the
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 and metadata/
control data.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2016. This Internet-Draft will expire on January 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6
5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Call Routing . . . . . . . . . . . . . . . . . . . . . . 8
8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 9 8. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 9
9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 10 8.1. The eCall Control Block . . . . . . . . . . . . . . . . . 10
9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12 8.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 11
9.1.1.1. Attributes of the <ack> element . . . . . . . . . 12 8.1.1.1. Attributes of the <ack> element . . . . . . . . . 11
9.1.1.2. Child Elements of the <ack> element . . . . . . . 12 8.1.1.2. Child Elements of the <ack> element . . . . . . . 12
9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 13 8.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 12
9.1.2. The <capabilities> element . . . . . . . . . . . . . 14 8.1.2. The <request> element . . . . . . . . . . . . . . . . 12
9.1.2.1. Child Elements of the <capabilities> element . . 14 8.1.2.1. Attributes of the <request> element . . . . . . . 12
9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 15 8.1.2.2. Request Example . . . . . . . . . . . . . . . . . 13
9.1.3. The <request> element . . . . . . . . . . . . . . . . 16 9. The emergencyCallData.eCall INFO package . . . . . . . . . . 13
9.1.3.1. Attributes of the <request> element . . . . . . . 16 9.1. INFO Package Requirements . . . . . . . . . . . . . . . . 13
9.1.3.2. Child Elements of the <request> element . . . . . 18 9.1.1. Overall Description . . . . . . . . . . . . . . . . . 14
9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19 9.1.2. Applicability . . . . . . . . . . . . . . . . . . . . 14
9.2. The emergencyCallData.eCall INFO package . . . . . . . . 19 9.1.3. Info Package Name . . . . . . . . . . . . . . . . . . 15
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1.4. Info Package Parameters . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9.1.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . 15
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 9.1.6. INFO Message Body Parts . . . . . . . . . . . . . . . 15
13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1.7. Info Package Usage Restrictions . . . . . . . . . . . 15
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9.1.8. Rate of INFO Requests . . . . . . . . . . . . . . . . 15
14.1. Service URN Registrations . . . . . . . . . . . . . . . 29 9.1.9. Info Package Security Considerations . . . . . . . . 15
9.1.10. Implementation Details . . . . . . . . . . . . . . . 16
9.1.11. Examples . . . . . . . . . . . . . . . . . . . . . . 16
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
14.1. Service URN Registrations . . . . . . . . . . . . . . . 22
14.2. MIME Content-type Registration for 14.2. MIME Content-type Registration for
'application/emergencyCallData.eCall.MSD+xml' . . . . . 30 'application/emergencyCallData.eCall.MSD+per' . . . . . 23
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' . . . 24
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 . . . . . . . . . . 26
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 . . . . . 26
14.6. Registration of the emergencyCallData.eCall Info Package 33 14.6. Registration of the emergencyCallData.eCall Info Package 26
14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33 14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 26
14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33 14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 26
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 . . . . . . . . 27
14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 14.8. Registry creation . . . . . . . . . . . . . . . . . . . 28
14.8.1. eCall Control Action Registry . . . . . . . . . . . 35 14.8.1. eCall Control Action Registry . . . . . . . . . . . 28
14.8.2. eCall Static Message Registry . . . . . . . . . . . 36 14.8.2. eCall Control Extension Registry . . . . . . . . . . 29
14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 38 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 39 17. Changes from Previous Versions . . . . . . . . . . . . . . . 30
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 17.1. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 30
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 17.2. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 30
17. Changes from Previous Versions . . . . . . . . . . . . . . . 39 17.3. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 30
17.1. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40 17.4. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 31
17.2. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40 17.5. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 31
17.3. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40 17.6. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 31
17.4. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40 17.7. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 31
17.5. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 17.8. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 31
17.6. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41 17.9. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 32
17.7. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41 17.10. Changes from draft-gellens-02 to -03 . . . . . . . . . . 32
17.8. Changes from draft-gellens-02 to -03 . . . . . . . . . . 41 17.11. Changes from draft-gellens-01 to -02 . . . . . . . . . . 32
17.9. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41 17.12. Changes from draft-gellens-00 to -01 . . . . . . . . . . 32
17.10. Changes from draft-gellens-00 to -01 . . . . . . . . . . 41 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 18.1. Normative References . . . . . . . . . . . . . . . . . . 32
18.1. Normative References . . . . . . . . . . . . . . . . . . 42 18.2. Informative references . . . . . . . . . . . . . . . . . 34
18.2. Informative references . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 | IP 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
as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP
framework for emergency calls, as described in [RFC6443] and framework for emergency calls, as described in [RFC6443] and
[RFC6881]. eCall itself is specified by 3GPP and CEN and these [RFC6881]. eCall itself is specified by 3GPP and CEN and these
skipping to change at page 5, line 7 skipping to change at page 5, line 16
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 a compliant in-vehicle system (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
the very near future. eCall (and eCall-compatible systems) are also the very near future. Other regions are developing eCall-compatible
being adopted in other regions. systems.
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 mobile network, and routed to a
PSAP where the vehicle data is available to assist the call taker in specialized PSAP where the vehicle data is available to assist the
assessing and responding to the situation. eCall provides a standard call taker in assessing and responding to the situation. eCall
set of vehicle, sensor (e.g., crash related), and location data. provides a standard set of vehicle, sensor (e.g., crash related), and
location data.
An eCall can be either user-initiated or automatically triggered. An eCall can 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 and carry a greater presumption of risk of injury. serious incident. Manually triggered eCalls might be reports of
Manually triggered eCalls might be reports of serious hazards and are witnessed crashes or serious hazards. PSAPs might apply specific
likely to require a different response than an automatically operational handling to manual and automatic eCalls.
triggered eCall. Manually triggered eCalls are also more likely to
be false (e.g., accidental) calls and so might be subject to
different operational handling by the PSAP.
Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) Legacy eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) as a
as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in the
the call setup mark the call as an eCall, and further indicate if 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
receipt of the MSD, and to request the vehicle to send a new MSD receipt of the MSD, and to request the vehicle to send a new MSD
(e.g., to check if the state of or location of the vehicle or its (e.g., to check if the state of or location of the vehicle or its
occupants has changed). Work on next-generation eCall (NG-eCall, occupants has changed). NG-eCall moves from circuit switched to all-
also referred to as packet-switched eCall or PS eCall) is now in IP, and carries the vehicle data and other eCall-specific data as
process. As part of this work, the European Telecommunications additional data carried with the call. This document describes how
Standards Institute (ETSI) [SDO-ETSI] has published a Technical IETF mechanisms for IP-based emergency calls, including [RFC6443] and
Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] [I-D.ietf-ecrit-additional-data] are used to provide the signaling
that presents findings and recommendations regarding support for and data exchange of the next generation of pan-European eCall.
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
as additional data associated with the call. This document describes
how IETF mechanisms for IP-based emergency calls, including [RFC6443]
and [I-D.ietf-ecrit-additional-data] are used to provide the
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 European Telecommunications Standards Institute (ETSI) [SDO-ETSI]
calling with additional elements identifying the call as an eCall and has published a Technical Report titled "Mobile Standards Group
as carrying eCall data and with mechanisms for carrying the data. (MSG); eCall for VoIP" [MSG_TR] that presents findings and
3GPP IMS emergency services support multimedia, providing the ability recommendations regarding support for eCall in an all-IP environment.
to carry voice, text, and video. This capability is referred to The recommendations include the use of 3GPP IMS emergency calling
within 3GPP as Multimedia Emergency Services (MMES). with additional elements identifying the call as an eCall and as
carrying eCall data and with mechanisms for carrying the data and
eCall-specific signaling. 3GPP IMS emergency services support
multimedia, providing the ability to carry voice, text, and video.
This capability is referred to 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. The issues of migration and
might last several years or longer. The issue of migration/co- co-existence during the transition period is outside the scope of
existence during the transition period is very important but is this document.
outside the scope of this document. The ETSI TR "Mobile Standards
Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in
Clause 7.
4. eCall Requirements 4. eCall Requirements
Overall eCall requirements are specified by CEN in [EN_16072] and by eCall requirements are specified by CEN in [EN_16072] and by 3GPP in
3GPP in [TS22.101] clauses 10.7 and A.27. Requirements specific to [TS22.101] clauses 10.7 and A.27. Requirements specific to vehicle
vehicle data are contained in EN 15722 [msd]. For convenience, the data are contained in EN 15722 [msd].
requirements most applicable to the limited scope of this document
are summarized very briefly below.
eCall requires:
o The call be recognized as an eCall (which is inherently an
emergency call)
o The call setup indicates if the call was manually or automatically
triggered
o A voice channel between the vehicle and the PSAP
o Carrying the MSD intrinsically with the call (the MSD needs to be
available to the same call-taker as the voice)
o The ability for the PSAP to acknowledge receipt of the MSD
o The ability for the PSAP to request that the vehicle generate and
transmit a new MSD
o The ability of the PSAP to be able to re-contact the occupants of
vehicle after the initial eCall is concluded
o The ability to perform a test call (which can be routed to a PSAP
but is not treated as an emergency call and not handled by a call
taker)
It is recognized that NG-eCall offers many potential enhancements,
although these are not required by current EU regulations. For
convenience, the enhancements most applicable to the limited scope of
this document are summarized very briefly below.
NG-eCall is expected to offer:
o The ability to carry more data (e.g., an enhanced MSD or an MSD
plus additional sets of data)
o The ability to handle video
o The ability to handle text
o The ability for the PSAP to access vehicle components (e.g., an
onboard camera (such as rear facing or blind-spot cameras) for a
visual assessment of the crash site situation)
o The ability for the PSAP to request the vehicle to take actions
(e.g., sound the horn, disable the ignition, lock/unlock doors)
o The ability to avoid audio muting of the voice channel (because
the MSD is not transferred using an in-band modem)
5. Vehicle Data 5. Vehicle Data
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]. Both circuit-switched eCall and this document use the
encoding is better suited for use in SIP messages and is used in this ASN.1 PER encoding, which is specified in Annex A of EN 15722 [msd]
document. (The ASN.1 encoding is specified in Annex A of EN 15722 (the XML encoding specified in Annex C is not used in this document).
[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
[I-D.ietf-ecrit-additional-data] establishes a general mechanism for [I-D.ietf-ecrit-additional-data] establishes a general mechanism for
attaching blocks of data to a SIP emergency call. This document attaching blocks of data to a SIP emergency call. This document
makes use of that mechanism to carry the eCall MSD in a SIP emergency makes use of that mechanism to carry the eCall MSD in a SIP emergency
call. 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+per' 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. As an ASN.1 PER encoded object, the data is
to the Emergency Call Additional Data Blocks registry (established by binary and transported using binary content transfer encoding within
SIP messages. This document also adds the 'eCall.MSD' entry to the
Emergency Call Additional Data Blocks registry (established by
[I-D.ietf-ecrit-additional-data]) to enable the MSD to be recognized [I-D.ietf-ecrit-additional-data]) to enable the MSD to be recognized
as such 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 dialog
needs to be evaluated to be sure it is appropriate to use the need 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
emergency call which carries an eCall flag (indicating that the call emergency call which carries an 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).
///----\\\ 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) initiating an NG-eCall transmits the MSD
in accordance with [I-D.ietf-ecrit-additional-data] 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 Annex A 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+per') 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
entry; the 'purpose' parameter's value is 'emergencyCallData.' and entry; the 'purpose' parameter's value is 'emergencyCallData.' plus
the root of the MIME type (not including the 'emergencyCallData' the root of the MIME type (not including the 'emergencyCallData.'
prefix and any suffix such as '+xml' (e.g., prefix and any suffix such as '+per', so in this case,
'purpose=emergencyCallData.eCall.MSD'). 'purpose=emergencyCallData.eCall.MSD'.
For NG-eCall, the IVS establishes an emergency call using the 3GPP For NG-eCall, the IVS establishes an emergency call using a Request-
IMS solution with a Request-URI indicating an eCall type of emergency URI indicating a manual or automatic eCall; the MNO (or ESInet)
call and with vehicle data attached; the MNO or ESInet recognizes the recognizes the eCall URN and routes the call to an NG-eCall capable
eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP PSAP; the PSAP interpets the vehicle data sent with the call and
interpets the vehicle data sent with the call and makes it available makes it available to the call taker.
to the call taker.
///----\\\ IMS emergency call with eCall URN +------+ ///----\\\ IMS emergency call with eCall URN +------+
IVS ----------------------------------------->+ PSAP | IVS ----------------------------------------->+ PSAP |
\\\----/// vehicle data included in call setup +------+ \\\----/// vehicle data included in call setup +------+
Figure 2: NG-eCall Figure 2: NG-eCall
This document registers new service URN children within the "sos" This document registers new service URN children within the "sos"
subservice. These URNs provide the mechanism by which an eCall is subservice. These URNs provide the mechanism by which an eCall is
identified, and differentiate between manually and automatically identified, and differentiate between manually and automatically
triggered eCalls (which can be subject to different treatment, triggered eCalls (which might be subject to different treatment,
depending on policy). The two service URNs are: depending on policy). The two service URNs are:
urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual
7. Call Routing 6.1. Call Routing
The routing rules for eCalls are likely to differ from those of other The routing applied to eCalls might differ from those of other
emergency calls because eCalls are special types of emergency calls emergency calls, as eCalls are intended to be handled by PSAPs that
(with implications for the types of response required) and need to be support eCall. In regions without ESInets, typically the emergency
handled by specially designated PSAPs. In an environment that uses services authorities and the originating network determine how such
ESInets, the originating network passes all types of emergency calls calls are routed. In a region that uses ESInets, the originating
to an ESInet (which have a request URI containing the "SOS" service network passes all types of emergency calls to an ESInet (calls which
URN). The ESInet is then responsible for routing such calls to the have a request URI containing the "SOS" service URN). The ESInet is
appropriate PSAP. In an environment without an ESInet, the emergency then responsible for routing such calls to the appropriate PSAP.
services authorities and the originating network jointly determine
how such calls are routed.
8. Test Calls 7. Test Calls
eCall requires the ability to place test calls. These are calls that eCall requires the ability to place test calls. These are calls that
are recognized and treated to some extent as eCalls but are not given are recognized and treated to some extent as eCalls but are not given
emergency call treatment and are not handled by call takers. The emergency call treatment and are not handled by call takers. The
test call facility allows the IVS or user to verify that an eCall can specific handling of test eCalls is not itself standardized;
be successfully established with voice communication. The IVS can typically, the test call facility allows the IVS or user to verify
also verify that the MSD was successfully received. that an eCall can be successfully established with voice
communication. The IVS might also be able to verify that the MSD was
successfully received.
A service URN starting with "test." indicates a test call. For A service URN starting with "test." indicates a test call. For
eCall, "urn:service:test.sos.ecall" indicates such a test feature. eCall, "urn:service:test.sos.ecall" indicates such a test feature.
This functionality is defined in [RFC6881]. This functionality is defined in [RFC6881].
This document registers "urn:service:test.sos.ecall" for eCall test This document registers "urn:service:test.sos.ecall" for eCall test
calls. calls.
the current eCall test call facility is a non-emergency number so The CS-eCall test call facility is a non-emergency number so does not
does not get treated as an emergency call. MNOs can treat a vehicle get treated as an emergency call. For NG-eCall, MNOs, emergency
call in the "test" service URN in a way that tests as much authorities, and PSAPs can determine how to treat a vehicle call
functionality as desired, but this is outside the scope of this requesting the "test" service URN so that the desired functionality
document. is tested, but this is outside the scope of this document. (One
possibility is that MNOs route such calls as non-emergency calls to a
PSAPs that have the ability to process NG-eCalls SHOULD accept test PSAP that supports NG-eCall; the PSAP accepts test calls, sends an
calls and send an acknowledgment if the MSD was successfully MSD acknowledgment, and plays an audio clip (for example, saying that
received, per this document. Such PSAPs MAY also play an audio clip the call reached an eCall PSAP) in addition to supporting media
(for example, saying that the call reached a PSAP) in addition to loopback per [RFC6881]).
supporting media loopback per [RFC6881].
9. eCall-Specific Control/Metadata 8. eCall-Specific Control/Metadata
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 there have been changes in the vehicle's state,
Future enhancements are desired to enable the PSAP to send other e.g., location, direction, number of fastened seatbelts).
requests to the vehicle, such as locking or unlocking doors, sounding
the horn, flashing the lights, starting a video stream from on-board
cameras (such as rear focus or blind-spot), etc.
The mechanism established in [I-D.ietf-ecrit-additional-data], used The mechanism established in [I-D.ietf-ecrit-additional-data], used
in Section 5 of this document to carry the MSD from the IVS to the in Section 5 of this document to carry the MSD from the IVS to the
PSAP, is also used to carry a block of control data from the PSAP to PSAP, is also used to carry a block of metadata/control data from the
the IVS. This eCall control block (sometimes referred to as eCall PSAP to the IVS. This eCall control block (sometimes referred to as
metadata) is an XML structure containing eCall-specific elements. eCall metadata) is an XML structure containing eCall-specific
When the PSAP needs to send an eCall control block that is in elements. When the PSAP needs to send an eCall control block that is
response to the MSD or other data sent by the IVS in a SIP request, in response to data sent by the IVS in a SIP request (e.g., the MSD
the control block can be sent in the SIP response to that request in the initial INVITE), the control block can be sent in the SIP
(e.g., the INVITE). When the PSAP needs to send an eCall control response to that request (e.g., the response to the INVITE request).
block that is not an immediate response to an MSD or other data sent When the PSAP needs to send an eCall control block in other
by the IVS, the control block can be transmitted from the PSAP to the circumstances (e.g., mid-call), the control block can be transmitted
IVS in a SIP INFO message within the established session. The IVS from the PSAP to the IVS in a SIP INFO request within the established
can then send any requested data (such as a new MSD) in the reply to dialog. The IVS sends the requested data (the MSD) in a new INFO
the INFO message. This mechanism flexibly allows the PSAP to send request. This mechanism flexibly allows the PSAP to send eCall-
eCall-specific data to the IVS and the IVS to respond. If control specific data to the IVS and the IVS to respond.
data sent in a response message requests the IVS to send a new MSD or
other data block, or to perform an action other than sending data,
the IVS can send the requested data or an acknowledgment regarding
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, attributes, and
control object definition (e.g., permitting additional elements to values can be added to the control object definition
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 [I-D.ietf-ecrit-additional-data]) so that the (established by [I-D.ietf-ecrit-additional-data]) so that the
control block can be recognized as emergency call specific data control block can be recognized as emergency call specific data
within the SIP messages within SIP messages
o An Info-Package registration per [RFC6086] permitting the control o An Info-Package registration per [RFC6086] permitting data blocks
block within Info messages registered in the Emergency Call Additional Data Blocks sub-
registry (established by [I-D.ietf-ecrit-additional-data]) within
Info messages
9.1. The eCall Control Block When the IVS includes an unsolicited MSD in a SIP request (e.g., the
initial INVITE), the PSAP sends a metadata/control block indicating
successful/unsuccessful receipt of the MSD in the SIP response to the
request. This also informs the IVS that an NG-eCall is in operation.
If the IVS receives a SIP response without the metadata/control
block, it indicates that the SIP dialog is not an NG-eCall. When the
IVS sends a solicited MSD (e.g., in a SIP INFO request sent following
receipt of a SIP INFO request containing a metadata/control block
requesting an MSD), the PSAP does not send a metadata/control block
indicating successful or unsuccessful receipt of the MSD. (Normal
SIP retransmission handles non-receipt of requested data; if the IVS
sends a requested MSD in an INFO request and does not receive a SIP
status message for the INFO request, it resends it; if the PSAP
requests an MSD and does not receive a SIP status message for the
INFO request, it resends it.)
This provides flexibility to handle various circumstances. For
example, if a PSAP is unable to accept an eCall (e.g., due to
overload or too many calls from the same location), it can reject the
INVITE. Since a metadata/control object is also included in the SIP
response that rejects the call, the IVS knows if the PSAP received
the MSD, and can inform the occupants that the PSAP successfully
received the vehicle location and information but can't talk to the
occupants at that time. Especially for SIP response codes that
indicate an inability to conduct a call (as opposed to a technical
inability to process the request), the IVS can also determine that
the call was successful on a technical level (e.g., not necessary to
retry as a CS-eCall). The SIP response code 600 (Busy Everywhere)
can be used to indicate this. Other SIP response codes that can be
interpreted in this way include 480 (Temporarily Unavailable), 486
(Busy Here), and 603 (Decline).
8.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 and requests. It is carried in a SIP body part with
carried in a SIP body part with a specific MIME content type. Three a specific MIME content type. It can be extended via an IANA
registry to add additional elements, attributes, and values. Two
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 the PSAP to acknowledge
uses this to acknowledge receipt of a data set sent by receipt of a data set sent by the IVS.
the IVS. The IVS uses this to acknowledge receipt of a
request by the PSAP when that request would not
otherwise be acknowledged (if the PSAP requests the
vehicle to send data and the vehicle does so, the data
serves as a success acknowledgement).
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
vehicle capabilities. Child elements contain all
actions and data types supported by the vehicle and all
available lamps (lights) and cameras.
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 request the
request the vehicle to perform an action. vehicle to perform an action. The only action defined
in this document is a request for the IVS to send an
MSD.
Mandatory Actions (the IVS and the PSAP MUST support): Mandatory Actions (the IVS and the PSAP MUST support):
o Transmit data object o Transmit data object
Optional Actions (the IVS and the PSAP MAY support): Optional Actions (the IVS and the PSAP MAY support):
o Play and/or display static (pre-defined) message o None
o Speak/display dynamic text (text supplied in action)
o Flash or turn on or off a lamp (light)
o Honk horn
o Enable a camera
The <ack> element indicates the object being acknowledged (i.e., a
data object or a <request> element), and reports success or failure.
The <capabilities> element has child <request> elements to indicate The <ack> element indicates the object being acknowledged (e.g., the
the actions supported by the IVS. MSD), and reports success or failure.
The <request> element contains attributes to indicate the request and The <request> element contains attributes to indicate the request and
to supply any needed information, and MAY contain a <text> child to supply related information. The 'action' attribute is mandatory
element to contain the text for a dynamic message. The 'action' and indicates the specific action. An IANA registry is created in
attribute is mandatory and indicates the specific action. An IANA Section 14.8.1 to contain the allowed values.
registry is created in Section 14.8.1 to contain the allowed values.
Extensibility: New elements, child elements, and attributes can be
defined in new namespaces. IANA registries are used to specify the
permitted values of several elements and attributes. These
mechanisms allow for extension.
There is no 'request' action to play dynamic media (such as a pre- Extensibility: New elements, child elements, attributes of new and
recorded audio message). The SIP re-INVITE mechanism can be used to existing elements, and values for new and existing attributes can be
establish a one-way media stream for this purpose. added in the IANA registry created in Section 14.8.2. The registry
permits implementors to see what has been added, with a reference to
the defining document. (Implementations are not expected to
dynamically check the registry.) Implementations MUST ignore
unsupported elements, attributes, and values.
9.1.1. The <ack> element 8.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.
acknowledge receipt of a <request> element that requested the IVS to
perform an action other than transmitting a data object (e.g., a
request to display a message would be acknowledged, but a request to
transmit a data object would not result in a separate <ack> element
being sent, since the data object itself serves as acknowledgment.)
An <ack> element sent by an IVS references the unique ID of the
request being acknowledged, indicates whether the request was
successfully performed, and if not, optionally includes an
explanation.
The <ack> element has the following attributes and child elements: The <ack> element has the following attributes:
9.1.1.1. Attributes of the <ack> element 8.1.1.1. Attributes of the <ack> element
The <ack> element has the following attributes: The <ack> element has the following attributes:
Name: ref Name: ref
Usage: Mandatory Usage: Mandatory
Type: anyURI Type: anyURI
Description: References the Content-ID of the body part that Description: References the Content-ID of the body part that
contained the data object or control object being acknowledged. contained the data object being acknowledged.
Example: <ack received="yes" ref="1234567890@atlanta.example.com"/> Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>
Name: received Name: received
Usage: Conditional: mandatory in an >ack< element sent by a PSAP; Usage: Conditional: mandatory in an >ack< element sent by a PSAP
not applicable in an >ack< element sent by an IVS
Type: Boolean Type: Boolean
Description: Indicates if the referenced object was successfully Description: Indicates if the referenced object was successfully
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 8.1.1.2. Child Elements of the <ack> element
The <ack> element has the following child elements:
Name: actionResult
Usage: Optional
Description: An <actionResult> element indicates the result of an
action (other than a 'send-data' action). When an <ack> element
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
Usage: Mandatory
Type: token
Description: Contains the value of the 'action' attribute of the
<request> element
Name: success
Usage: Mandatory
Type: Boolean
Description: Indicates if the action was successfully
accomplished
Name: reason
Usage: Conditional
Type: token
Description: Used when 'success' is "False", this attribute
contains a reason code for a failure. A registry for reason
codes is defined in Section 14.8.3.
Name: details
Usage: optional
Type: string
Description: Contains further explanation of the circumstances of
a success or failure. The contents are implementation-specific
and human-readable.
Example: <actionResult action="msg-dynamic" success="true"/> The <ack> element has no child elements
Example: <actionResult action="lamp" success="false" reason="unable" 8.1.1.3. Ack Examples
details="The requested lamp is inoperable"/>
9.1.1.3. Ack Examples
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl <EmergencyCallData.eCall.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData: xsi:schemaLocation=
eCall-control"> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
<ack received="true" ref="1234567890@atlanta.example.com"/> <ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.eCallControl> </EmergencyCallData.eCall.Control>
Figure 3: Ack Example from PSAP to IVS Figure 3: Ack Example from PSAP to IVS
<?xml version="1.0" encoding="UTF-8"?> 8.1.2. The <request> element
<EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:
eCall-control">
<ack ref="1234567890@atlanta.example.com">
<actionResult action="msg-dynamic" success="true"/>
<actionResult action="lamp" success="false" reason="unable"
details="The requested lamp is inoperable"/>
</ack>
</EmergencyCallData.eCallControl>
Figure 4: Ack Example from IVS to PSAP
9.1.2. The <capabilities> element
The <capabilities> element is transmitted by the IVS to indicate to A <request> element allows the PSAP to request that the IVS send an
the PSAP its capabilities. No attributes for this element are MSD. The following attributes are defined:
currently defined. The following child elements are defined:
9.1.2.1. Child Elements of the <capabilities> element 8.1.2.1. Attributes of the <request> element
The <capabilities> element has the following child elements: The <request> element has the following attributes:
Name: request Name: action
Usage: Mandatory Usage: Mandatory
Description: The <capabilities> element contains a <request> child Type: token
element per action supported by the vehicle. Description: Identifies the action that the vehicle is requested to
perform. An IANA registry is established in Section 14.8.1 to
contain the allowed values.
Example: action="send-data"
Because support for a 'send-data' action is REQUIRED, a <request> Name: datatype
child element with a "send-data" 'action' attribute is also Usage: Conditional
REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this Type: token
<request> element within a <capabilities> element, and MUST Description: Mandatory with a "send-data" action. Specifies the
contain at a minimum the 'eCall.MSD' data block value; it SHOULD data block that the IVS is requested to transmit, using the same
contain all data blocks supported by the IVS. identifier as in the 'purpose' attribute set in a Call-Info header
field to point to the data block. Permitted values are contained
in the 'Emergency Call Data Types' IANA registry established in
[I-D.ietf-ecrit-additional-data].
Example: datatype="eCall.MSD"
All other actions are OPTIONAL. 8.1.2.2. Request Example
If the "msg-static" action is supported, a <request> child element <?xml version="1.0" encoding="UTF-8"?>
with a "msg-static" 'action' attribute is sent, with a 'msgid' <EmergencyCallData.eCall.Control
attribute set to the highest supported static message supported by xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
the vehicle. A registry is created in Section 14.8.2 to map xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
'msgid' values to static text messages. By sending the highest xsi:schemaLocation=
supported static message number in its <capabilities> element, the "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
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 <request action="send-data" datatype="eCall.MSD"/>
a "lamp" 'action' is sent, with a 'supported-lamps' attribute set
to all supported lamp IDs.
If the "enable-camera" action is supported, a <request> child </EmergencyCallData.eCall.Control>
element with an "enable-camera" 'action' is sent, with a
'supported-cameras' attribute set to all supported camera IDs.
Examples: Figure 4: Request Example
<request action="send-data" supported-datatypes="eCall.MSD" />
<request action="send-data" supported-datatypes="eCall.MSD; VEDS;
eCall.type2" />
<request action="msg-dynamic"/>
<request action="msg.static" msgid="17" />
9.1.2.2. Capabilities Example 9. The emergencyCallData.eCall INFO package
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:
eCall-control">
<capabilities> This document registers the 'emergencyCallData.eCall' INFO package.
<request action="send-data" supported-datatypes="eCall.MSD"/>
<request action="lamp"
supported-lamps="head;interior;fog-front;fog-rear;brake;
position-front;position-rear;turn-left;turn-right;hazard"/>
<request action="msg-static" msgid="3"/>
<request action="msg-dynamic"/>
<request action="honk"/>
<request action="enable-camera" supported-cameras="backup; interior"/>
</capabilities>
</EmergencyCallData.eCallControl> Both endpoints (the IVS and the PSAP equipment) include
'emergencyCallData.eCall' in a Recv-Info header field per [RFC6086]
to indicate ability to receive INFO messages carrying data as
described here.
Figure 5: Capabilities Example Support for the 'emergencyCallData.eCall' INFO package indicates the
ability to receive body parts registered in the 'Emergency Call Data
Types' IANA registry established in [I-D.ietf-ecrit-additional-data].
9.1.3. The <request> element An INFO request message carrying data related to an emergency call
has an Info-Package header field set to 'emergencyCallData.eCall' per
[RFC6086]. Per [I-D.ietf-ecrit-additional-data], the INFO request
message contains one or more Call-Info header fields containing a CID
URL referencing the unique identifier of a body part, and a 'purpose'
parameter identifying the data. Because the data is being carried in
an INFO request message, the body part also carries a Content-
Disposition header field set to "Info-Package".
A <request> element appears one or more times on its own or as a 9.1. INFO Package Requirements
child of a <capabilities> element. The following attributes and
child elements are defined:
9.1.3.1. Attributes of the <request> element The requirements of Section 10 of [RFC6086] are addressed in the
following sections.
The <request> element has the following attributes: 9.1.1. Overall Description
Name: action This section describes "what type of information is carried in INFO
Usage: Mandatory requests associated with the Info Package, and for what types of
Type: token applications and functionalities UAs can use the Info Package."
Description: Identifies the action that the vehicle is requested to
perform. An IANA registry is established in Section 14.8.1 to
contain the allowed values.
Example: action="send-data"
Name: msgid INFO requests associated with the emergencyCallData.eCall INFO
Usage: Conditional package carry data associated with emergency calls as registered in
Type: int the 'Emergency Call Data Types' IANA registry established in
Description: Mandatory with a "msg-static" action. Indicates the [I-D.ietf-ecrit-additional-data]. The application is emergency calls
identifier of the static message to be displayed and/or spoken for established using SIP. The functionality is to carry data, metadata,
the vehicle occupants. This document established an IANA registry and control information (requests) between vehicles and PSAPs. Refer
for messages and their IDs, in Section 14.8.2 to [TBD: THIS DOCUMENT] for more information.
Example: msgid="3" 9.1.2. Applicability
Name: persistance This section describes "why the Info Package mechanism, rather than
Usage: Optional some other mechanism, has been chosen for the specific use-case...."
Type: duration
Description: Specifies how long to carry on the specified action,
for example, how long to continue honking or flashing. If absent,
the default is indefinitely.
Example: persistance="PT1H"
Name: datatype The use of INFO is based on an analysis of the requirements against
Usage: Conditional the intent and effects of INFO versus other approaches (which
Type: token included SIP MESSAGE, SIP OPTIONS, SIP re-INVITE, media plane
Description: Mandatory with a "send-data" action. Specifies the transport, and non-SIP protocols). In particular, the transport of
data block that the IVS is requested to transmit, using the same emergency call data blocks occurs within a SIP emergency dialog,
identifier as in the 'purpose' attribute set in a Call-Info header using the mechanism established in [I-D.ietf-ecrit-additional-data],
field to point to the data block. Permitted values are contained and is normally carried in the initial INVITE and its response; the
in the 'Emergency Call Data Types' IANA registry established in use of INFO only occurs when emergency-call-related data needs to be
[I-D.ietf-ecrit-additional-data]. sent mid-call. While MESSAGE could be used, it is not tied to a SIP
Example: datatype="eCall.MSD" dialog as is INFO and thus might not be associated with the dialog.
SIP OPTIONS or re-INVITE could also be used, but is seen as less
clean than INFO. SUBSCRIBE/NOTIFY could be coerced into service, but
the semantics are not a good fit, e.g., the subscribe/notify
mechanism provides one-way communication consisting of (often
multiple) notifications from notifier to subscriber indicating that
certain events in notifier have occurred, whereas what's needed here
is two-way communication of data related to the emergency dialog.
Use of the media plane mechanisms was discounted because the number
of messages needing to be exchanged in a dialog is normally zero or
very few, and the size of the data is likewise very small. The
overhead caused by user plane setup (e.g., to use MSRP as transport)
would be disproportionately large, and further, a high-level
application protocol identifying the specific data block being sent
within the media plane (as provided by the Call-Info header field
parameters and MIME body part content type within INFO) would need to
be defined.
Name: supported-datatypes Based on the the analyses, the SIP INFO method was chosen to provide
Usage: Conditional for mid-call data transport.
Type: string
Description: Used with a 'send-data' action in a <request> element
that is a child of a <capability> element, this attribute lists
all data blocks that the vehicle can transmit, using the same
identifier as in the 'purpose' attribute in a Call-Info header
field to point to the data block. Permitted values are contained
in the 'Emergency Call Data Types' IANA registry established in
[I-D.ietf-ecrit-additional-data]. Multiple values are separated
with a semicolon.
Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo"
Name: lamp-action 9.1.3. Info Package Name
Usage: Conditional
Type: token
Description: Used with a 'lamp' action, indicates if the lamp is to
be illuminated, turned off, or flashed. Permitted values are
'on', 'off', and 'flash'.
Example: lamp-action="flash"
Name: lamp-ID The info package name is emergencyCallData.eCall.
Usage: Conditional
Type: token
Description: Used with a 'lamp' action, indicates which lamp the
action affects. Permitted values are contained in the registry of
lamp-ID tokens created in Section 14.8.4
Example: lamp-ID="hazard" 9.1.4. Info Package Parameters
Name: supported-lamps None.
Usage: Conditional
Type: string
Description: Used with a 'lamp' action in a <request> element that
is a child of a <capability> element, this attribute lists all
supported lamps, using values in the registry of lamp-ID tokens
created in Section 14.8.4. Multiple values are separated with a
semicolon.
Example: supported-lamps="head; interior; fog-front; fog-rear;
brake; position-front; position-rear; turn-left; turn-right;
hazard"
Name: camera-ID 9.1.5. SIP Option-Tags
Usage: Conditional
Type: token
Description: Used with an 'enable-camera' action, indicates which
camera to enable. Permitted values are contained in the registry
of camera-ID tokens created in Section 14.8.5. When a vehicle
camera is enabled, the IVS sends a re-INVITE to negotiate a one-
way media stream for the camera.
Example: camera-ID="backup"
Name: supported-cameras None.
Usage: Conditional
Type: string
Description: Used with an 'enable-camera' action in a <request>
element that is a child of a <capability> element, this attribute
lists all cameras that the vehicle supports (can add as a video
feed in the current session), using the same identifiers as are
used in the 'camera-ID' attribute (contained in the camera ID
registry in Section 14.8.5). Multiple values are separated with a
semicolon.
Example: supported-cameras="backup; interior"
9.1.3.2. Child Elements of the <request> element 9.1.6. INFO Message Body Parts
The <request> element has the following child elements: Only those body parts registered in the 'Emergency Call Data Types'
IANA registry established in [I-D.ietf-ecrit-additional-data] are
associated with this INFO package.
Name: text When more than one body part is included, they are enclosed in a
Usage: Conditional multipart body part (e.g., multipart/mixed). When a body part is
Type: string digitally signed or encrypted, it is enclosed in an appropriate body
Description: Used within a <request action="msg-dynamic"> element to part (e.g., multipart/signed or multipart/encrypted).
contain the text to be displayed and/or spoken (via text-to-
speech) for the vehicle occupants.
Example: <text>Emergency authorities are aware of your incident and
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
assist you soon.</text>
9.1.3.3. Request Example The Content-Disposition value of a message body part associated with
the emergencyCallData.eCall info package is "info-package".
<?xml version="1.0" encoding="UTF-8"?> 9.1.7. Info Package Usage Restrictions
<EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:
eCall-control">
<request action="send-data" datatype="eCall.MSD"/> None.
<request action="lamp" lamp-id="hazard"
lamp-action="flash" persistance="PT1H"/>
<request action="msg-static" msgid="1"/>
<request action="msg-dynamic">
<text>Remain calm. Help is on the way.</text>
</request>
</EmergencyCallData.eCallControl> 9.1.8. Rate of INFO Requests
Figure 6: Request Example The rate of SIP INFO requests associated with the
emergencyCallData.eCall info package is expected to be quite low
(most dialogs are likely to contain zero INFO requests, while others
can be expected to carry occasional requests).
9.2. The emergencyCallData.eCall INFO package 9.1.9. Info Package Security Considerations
This document registers the 'emergencyCallData.eCall' INFO package. The MIME content type registation for each data block registered in
Both endpoints (the IVS and the PSAP equipment) set the Recv-Info the 'Emergency Call Data Types' IANA registry established in
header field to 'emergencyCallData.eCall' per [RFC6086] to indicate [I-D.ietf-ecrit-additional-data] contains a discussion of the
ability to receive INFO messages carrying eCall data or control security and/or privacy considerations specific to that data block.
blocks. The "Security Considerations" and "Privacy Considerations" sections
of [TBD: THIS DOCUMENT] discuss security and privacy considerations
of the data carried in eCealls.
Support for the 'emergencyCallData.eCall' INFO package indicates the 9.1.10. Implementation Details
ability to receive eCall data and control blocks, which are carried
in a body part whose subtype starts with 'emergencyCallData.eCall.'.
At present there is only one defined eCall data block, which has the
'application/emergencyCallData.eCall.MSD+xml' MIME type, and one
eCall control block, which has the 'application/
emergencyCallData.eCall.control+xml' MIME type. The eCall control
block includes the ability for the IVS to indicate its capabilities,
so in the event additional eCall blocks are defined, the IVS can
indicate which it supports.
The use of INFO is based on an analysis of the requirements against See [TBD: THIS DOCUMENT] for protocol details.
the intent and effects of INFO versus other approaches (such as SIP
MESSAGE, media plane, or non-SIP protocols). In particular, the
transport of eCall data and control blocks is done only during an
emergency session established with SIP, using the mechanism
established in [I-D.ietf-ecrit-additional-data], and is normally
carried in the initial INVITE and its response; the use of INFO only
occurs when a data block or request needs to be sent subsequently
during the call. While MESSAGE could be used, it is not tied to a
SIP session as is INFO. REINVITE could also be used, but is normally
used to modify the session. SUBSCRIBE/NOTIFY could be coerced into
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 9.1.11. Examples
an Info-Package header field set to 'emergencyCallData.eCall' per
[RFC6086]. The INFO request message is marked as containing the
eCall data or control block by a Call-Info header field containing a
CID URL referencing the unique identifier of the body part containing
the eCall data or control, and a 'purpose' parameter identifying the
block. Because the eCall data or control block is being carried in
an INFO request message, the body part also carries a Content-
Disposition header field set to "Info-Package".
Per [I-D.ietf-ecrit-additional-data], emergency call related See [TBD: THIS DOCUMENT] for protocol examples.
additional data MAY be included in any SIP request or response
message that can contain a body. Hence, notwithstanding
Section 4.3.2. of [RFC6086], INFO response messages MAY contain eCall
data or control blocks, provided they are included as described in
this document (with a Call-Info header field containing a CID URL
referencing the unique identifier of the body part, and a 'purpose'
parameter identifying the block). When eCall data or control blocks
are included in an INFO response message, this is done per
[I-D.ietf-ecrit-additional-data] and this document, and not under
[RFC6086]; that is, they are included as emergency call additional
data, not as an INFO package associated data.
10. Examples 10. Examples
Figure 7 shows an eCall. The call uses the request URI Figure 5 illustrates 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 which routes the
emergency call in an environment with an ESInet). The ESInet routes call to the appropriate NG-eCall capable PSAP. The emergency call is
the call to the appropriate NG-eCall capable PSAP. The emergency received by the ESInet's Emergency Services Routing Proxy (ESRP), as
call is received by the ESInet's Emergency Services Routing Proxy the entry point into the ESInet. The ESRP routes the call to a PSAP,
(ESRP), as the entry point into the ESInet. The ESRP routes the call where it is received by a call taker. In deployments where there is
to a PSAP, where it is received by a call taker. In deployments no ESInet, the originating network routes the call directly to the
where there is no ESInet, the originating network routes the call appropriate NG-eCall capable PSAP, an illustration of which would be
directly to the appropriate NG-eCall capable PSAP. identical to the one below except without an ESInet or ESRP.
+------------+ +---------------------------------------+ +------------+ +---------------------------------------+
| | | +-------+ | | | | +-------+ |
| | | | PSAP2 | | | | | | PSAP2 | |
| | | +-------+ | | | | +-------+ |
| | | | | | | |
| | | +------+ +-------+ | | | | +------+ +-------+ |
Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker |
| | | +------+ +-------+ | | | | +------+ +-------+ |
| | | | | | | |
| | | +-------+ | | | | +-------+ |
| | | | PSAP3 | | | | | | PSAP3 | |
| Originating| | +-------+ | | Originating| | +-------+ |
| Mobile | | | | Mobile | | |
| Network | | ESInet | | Network | | ESInet |
+------------+ +---------------------------------------+ +------------+ +---------------------------------------+
Figure 7: Example of NG-eCall Message Flow Figure 5: Example of NG-eCall Message Flow
The example, shown in Figure 8, illustrates a SIP eCall INVITE that
contains an MSD and an eCall control block with vehicle capabilities.
For simplicity, the example does not show all SIP headers, nor does
it show the additional data blocks added by the IVS and the
originating mobile network.
INVITE urn:service:sos.ecall.automatic SIP/2.0
To: urn:service:sos.ecall.automatic
From: <sip:+13145551111@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@example.com>
Geolocation-Routing: no
Call-Info: cid:1234567890@atlanta.example.com;
purpose=emergencyCallData.eCall.MSD;
cid:2345678901@atlanta.example.com;
purpose=emergencyCallData.eCall.control;
Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.eCall.control
CSeq: 31862 INVITE
Recv-Info: emergencyCallData.eCall
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here...
--boundary1
Content-Type: application/emergencyCallData.eCall.MSD+xml
Content-ID: 1234567890@atlanta.example.com
Content-Disposition: by-reference;handling=optional
<ECallMessage>
<id>1</id>
<msd>
<msdStructure>
<messageIdentifier>1</messageIdentifier>
<control>
<automaticActivation> <true/> </automaticActivation>
<testCall> <false/> </testCall>
<positionCanBeTrusted> <true/> </positionCanBeTrusted>
<vehicleType> <passengerVehicleClassM1/> </vehicleType>
</control>
<vehicleIdentificationNumber>
<isowmi>WMI</isowmi>
<isovds>VDSVDS</isovds>
<isovisModelyear>Y</isovisModelyear>
<isovisSeqPlant>A123456</isovisSeqPlant>
</vehicleIdentificationNumber>
<vehiclePropulsionStorageType>
<gasolineTankPresent> <true/> </gasolineTankPresent>
<electricEnergyStorage> <true/> </electricEnergyStorage>
</vehiclePropulsionStorageType>
<timestamp>123456789</timestamp>
<vehicleLocation>
<positionLatitude>173881200</positionLatitude>
<positionLongitude>41822520</positionLongitude>
</vehicleLocation>
<vehicleDirection>14</vehicleDirection>
<recentVehicleLocationN1>
<latitudeDelta>10</latitudeDelta>
<longitudeDelta>-10</longitudeDelta>
</recentVehicleLocationN1>
<recentVehicleLocationN2>
<latitudeDelta>10</latitudeDelta>
<longitudeDelta>-20</longitudeDelta>
</recentVehicleLocationN2>
<numberOfPassengers>2</numberOfPassengers>
</msdStructure> The example, shown in Figure 6, illustrates a SIP eCall INVITE that
contains an MSD. For simplicity, the example does not show all SIP
headers, nor the SDP contents, nor does it show any additional data
blocks added by the IVS or the originating mobile network. Because
the MSD is encoded in ASN.1 PER, which is a binary encoding, its
contents cannot be included in a text document.
<optionalAdditionalData> INVITE urn:service:sos.ecall.automatic SIP/2.0
<oid>1.2.125</oid> To: urn:service:sos.ecall.automatic
<data>30304646</data> From: <sip:+13145551111@example.com>;tag=9fxced76sl
</optionalAdditionalData> Call-ID: 3848276298220188511@atlanta.example.com
</msd> Geolocation: <cid:target123@example.com>
</ECallMessage> Geolocation-Routing: no
Call-Info: cid:1234567890@atlanta.example.com;
purpose=emergencyCallData.eCall.MSD;
cid:2345678901@atlanta.example.com;
purpose=emergencyCallData.eCall.control;
Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.eCall.control+xml
CSeq: 31862 INVITE
Recv-Info: emergencyCallData.eCall
Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
SUBSCRIBE, NOTIFY, UPDATE
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1 --boundary1
Content-Type: application/emergencyCallData.eCall.control+xml Content-Type: application/sdp
Content-ID: 2345678901@atlanta.example.com
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> ...Session Description Protocol (SDP) goes here...
<EmergencyCallData.eCallControl
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:
eCall-control">
<capabilities> --boundary1
<request action="send-data" supported-datatypes="eCall.MSD"/> Content-Type: application/emergencyCallData.eCall.MSD+per
<request action="lamp" Content-ID: 1234567890@atlanta.example.com
supported-lamps="head;interior;fog-front;fog-rear; Content-Disposition: by-reference;handling=optional
brake;position-front;position-rear;turn-left; Content-Transfer-Encoding: binary
turn-right;hazard"/>
<request action="msg-static" msgid="3"/>
<request action="msg-dynamic"/>
<request action="honk"/>
<request action="enable-camera"
supported-cameras="backup; interior"/>
</capabilities>
</EmergencyCallData.eCallControl> ...MSD in ASN.1 PER encoding goes here...
--boundary1-- --boundary1--
Figure 8: SIP NG-eCall INVITE Figure 6: SIP NG-eCall INVITE
Continuing the example, Figure 9 illustrates a SIP 200 OK response to Continuing the example, Figure 7 illustrates a SIP 200 OK response to
the INVITE of Figure 8, containing an eCall control block the INVITE of Figure 6, containing an eCall control block
acknowledging successful receipt of the eCall MSD. (For simplicity, acknowledging successful receipt of the eCall MSD. (For simplicity,
the example does not show all SIP headers.) the example does not show all SIP headers.)
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:+13145551111@example.com>;tag=9fxced76sl To: <sip:+13145551111@example.com>;tag=9fxced76sl
From: Exemplar PSAP <urn:service:sos.ecall.automatic> From: Exemplar PSAP <urn:service:sos.ecall.automatic>
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Call-Info: cid:2345678901@atlanta.example.com; Call-Info: cid:2345678901@atlanta.example.com;
purpose=emergencyCallData.eCall.control; purpose=emergencyCallData.eCall.control;
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.eCall.control, application/emergencyCallData.eCall.control+xml,
application/emergencyCallData.eCall.MSD application/emergencyCallData.eCall.MSD+per
CSeq: 31862 INVITE CSeq: 31862 INVITE
Recv-Info: emergencyCallData.eCall Recv-Info: emergencyCallData.eCall
Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
SUBSCRIBE, NOTIFY, UPDATE
Content-Type: multipart/mixed; boundary=boundaryX Content-Type: multipart/mixed; boundary=boundaryX
Content-Length: ... Content-Length: ...
--boundaryX --boundaryX
Content-Type: application/sdp Content-Type: application/sdp
...Session Description Protocol (SDP) goes here... ...Session Description Protocol (SDP) goes here...
--boundaryX --boundaryX
Content-Type: application/EmergencyCallData:eCall-control+xml Content-Type: application/EmergencyCallData.eCall.control+xml
Content-ID: 2345678901@atlanta.example.com Content-ID: 2345678901@atlanta.example.com
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl <EmergencyCallData.eCall.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData: xsi:schemaLocation=
eCall-control"> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">
<ack received="true" ref="1234567890@atlanta.example.com"/> <ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.eCallControl> </EmergencyCallData.eCall.Control>
--boundaryX-- --boundaryX--
Figure 9: 200 OK response to INVITE Figure 7: 200 OK response to INVITE
11. Security Considerations 11. Security Considerations
The security considerations described in [RFC5069] apply here. The security considerations described in [RFC5069] apply here.
In addition to any network-provided location that is inherently In addition to any network-provided location (which might be
permitted for IMS emergency calls (which might be determined solely determined solely by the network, or in cooperation with or possibly
by the network, or in cooperation with or possibly entirely by the entirely by the originating device), an eCall carries an IVS-supplied
originating device), an eCall carries an IVS-supplied location within location within the MSD. This is likely to be useful to the PSAP,
the MSD. This is likely to be useful to the PSAP, especially when especially when no network-provided location is included, or when the
the two locations are independently determined. Even in situations two locations are independently determined. Even in situations where
where the network-supplied location is limited to the cell site, this the network-supplied location is limited to the cell site, this can
can be useful as a sanity check on the device-supplied location be useful as a sanity check on the device-supplied location contained
contained in the MSD. 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.
Security considerations specific to the mechanism by which the PSAP Security considerations specific to the mechanism by which the PSAP
sends acknowledgments and requests to the vehicle are discussed in sends acknowledgments and requests to the vehicle are discussed in
the "Security Considerations" block of Section 14.3. In addition to the "Security Considerations" block of Section 14.3.
that discussion, it's important to note that vehicles MAY decline to
carry out any requested action, e.g., if the vehicle is unable to
verify the certificate used to sign the request. The vehicle MAY use
any value in the reason registry in Section 14.8.3 to indicate why it
did not take an action (e.g., the generic "unable" or the more
specific "security-failure").
Data received from external sources inherently carries implementation Data received from external sources inherently carries implementation
risks including buffer overflows, which in many platforms can risks. For example, depending on the platform, buffer overflows can
introduce remote code execution vulnerabilities; null characters can introduce remote code execution vulnerabilities, null characters can
corrupt strings, numeric values used for internal calculations can corrupt strings, numeric values used for internal calculations can
result in underflow/overflow errors; malformed XML objects can expose result in underflow/overflow errors, malformed XML objects can expose
parsing bugs, etc. Implementations need to be cognizant of the parsing bugs, etc. Implementations need to be cognizant of the
potential risks, observe best practices (e.g., good quality static potential risks, observe best practices (which might include
code analysis, fuzz testing, component isolation, avoiding use of sufficiently capable static code analysis, fuzz testing, component
unsafe coding techniques, third-party attack tests, signed software, isolation, avoiding use of unsafe coding techniques, third-party
over-the-air updates, etc.), and have multiple levels of protection. attack tests, signed software, over-the-air updates, etc.), and have
Implementors need to be aware that, potentially, the data objects multiple levels of protection. Implementors need to be aware that,
described here and elsewhere might be malformed, might contain potentially, the data objects described here and elsewhere might be
unexpected characters, excessively long attribute values, elements, malformed, might contain unexpected characters, excessively long
etc. (This applies across the board, not just to the 'text' attribute values, elements, etc.
attribute of a <request> element.)
Since this document depends on [I-D.ietf-ecrit-additional-data], the Since this document depends on [I-D.ietf-ecrit-additional-data], the
security considerations discussed there apply here (see especially security considerations discussed there apply here (see especially
the discussion of TLS, TLS versions, cypher suites, and PKI). the discussion of TLS, TLS versions, cypher suites, and PKI).
When vehicle data or control/metadata is contained in a signed or When vehicle data or control/metadata is contained in a signed or
encrypted body part, the enclosing multipart (e.g., multipart/signed encrypted body part, the enclosing multipart (e.g., multipart/signed
or multipart/encrypted) has the same Content-ID as the data part. or multipart/encrypted) has the same Content-ID as the enclosed data
This allows an entity to identify and access the data blocks it is part. This allows an entity to identify and access the data blocks
interested in without having to dive deeply into the message it is interested in without having to dive deeply into the message
structure or decrypt parts it is not interested in. (The 'purpose' structure or decrypt parts it is not interested in. (The 'purpose'
parameter in a Call-Info header field identifies the data, and the parameter in a Call-Info header field identifies the data and
CID URL points to the data block in the body, which has a matching contains a CID URL pointing to the data block in the body, which has
Content-ID body part header field). a matching Content-ID body part header field).
12. Privacy Considerations 12. Privacy Considerations
Since this document builds on [I-D.ietf-ecrit-additional-data], the Since this document builds on [I-D.ietf-ecrit-additional-data], the
data 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.
this document, such as access to vehicle camera streams, carries a
burden of protection and so implementations need to be careful that
access is only provided within the context of an emergency call and
to an emergency services provider, for example, by verifying that the
request for camera access is signed by a certificate issued by an
emergency services registrar.
Privacy considerations specific to the data structure containing Privacy considerations specific to the data structure containing
vehicle information are discussed in the "Security Considerations" vehicle information are discussed in the "Security Considerations"
block of Section 14.2. block of Section 14.2.
Privacy considerations specific to the mechanism by which the PSAP Privacy considerations specific to the mechanism by which the PSAP
sends acknowledgments and requests to the vehicle are discussed in sends acknowledgments and requests to the vehicle are discussed in
the "Security Considerations" block of Section 14.3. 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 an XML schema for the eCall control block. The
schema for the MSD can be found in EN 15722 [msd].) text description of the eCall control block in Section 8.1 is
normative and supersedes any conflicting aspect of this schema.
<?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"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control" xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2009/01/xml.xsd"/> schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
<xs:element name="EmergencyCallData.eCallControl" <xs:element name="EmergencyCallData.eCall.Control"
type="pi:eCallControlType"/> type="pi:eCallControlType"/>
<xs:simpleType name="iana-token">
<xs:annotation>
<xs:documentation>Permitted values specified in IANA
registries</xs:documentation>
</xs:annotation>
</xs:simpleType>
<xs:complexType name="eCallControlType"> <xs:complexType name="eCallControlType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice> <xs:choice>
<xs:element name="capabilities"
type="pi:capabilitiesType"/>
<xs:element name="request" type="pi:requestType"/> <xs:element name="request" type="pi:requestType"/>
<xs:element name="ack" type="pi:ackType"/> <xs:element name="ack" type="pi:ackType"/>
<xs:element type="cx:iana-token"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</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"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="action"
type="xs:token"
use="required"/>
<xs:attribute name="success"
type="xs:boolean"
use="required"/>
<xs:attribute name="reason"
type="xs:token">
<xs:annotation>
<xs:documentation>conditionally
mandatory when @success='false"
to indicate reason code for a
failure </xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="details"
type="xs:string"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:attribute type="cx:iana-token"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="ref" <xs:attribute name="ref"
type="xs:anyURI" type="xs:anyURI"
use="required"/> use="required"/>
<xs:attribute name="received" <xs:attribute name="received"
type="xs:boolean"/> type="xs:boolean"/>
<xs:anyAttribute/> <xs:anyAttribute/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="capabilitiesType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="request"
type="pi:requestType"
minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="requestType"> <xs:complexType name="requestType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element type="cx:iana-token"/>
</xs:choice> </xs:choice>
<xs:attribute name="action" type="xs:token" use="required"/> <xs:attribute name="action" type="xs:token" use="required"/>
<xs:attribute name="msgid" type="xs:unsignedInt"/>
<xs:attribute name="persistence" type="xs:duration"/> <xs:attribute type="cx:iana-token" minOccurs="0"
<xs:attribute name="datatype" type="xs:token"/> maxOccurs="unbounded"/>
<xs:attribute name="supported-datatypes" type="xs:string"/>
<xs:attribute name="lamp-id" type="xs:token"/>
<xs:attribute name="lamp-action">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value=""/>
<xs:pattern value=""/>
<xs:enumeration value="on"/>
<xs:enumeration value="off"/>
<xs:enumeration value="flash"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="supported-lamps" type="xs:string"/>
<xs:attribute name="camera-id" type="xs:token"/>
<xs:attribute name="supported-cameras" type="xs:string"/>
<xs:anyAttribute/> <xs:anyAttribute/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 10: eCall Control Block Schema Figure 8: eCall Control Block Schema
14. IANA Considerations 14. IANA Considerations
14.1. Service URN Registrations 14.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].
This service identifies a type of emergency call (placed by a This service requests resources associated with an emergency call
specialized in-vehicle system and a carrying standardized set of data placed by an in-vehicle system, carrying a standardized set of data
related to the vehicle and crash or incident, and is needed to direct related to the vehicle and incident. Two sub-services are registered
the call to a specialized public safety answering point (PSAP) with as well:
technical and operational capabilities to handle such calls. Two
sub-services are registered as well, namely
urn:service:sos.ecall.manual urn:service:sos.ecall.manual
This service URN indicates that an eCall had been triggered based Used with an eCall invoked due to manual interaction by a vehicle
on the manual interaction of the driver or a passenger. occupant.
urn:service:sos.ecall.automatic urn:service:sos.ecall.automatic
This service URN indicates that an eCall had been triggered Used with an eCall invoked automatically, for example, due to a
automatically, for example, due to a crash or other serious crash or other serious incident.
incident (e.g., fire).
IANA is also requested to register the URN IANA is also requested to register the URN
'urn:service:test.sos.ecall' under the sub-service 'test' registry 'urn:service:test.sos.ecall' under the sub-service 'test' registry
defined in Setcion 17.2 of [RFC6881]. defined in Setcion 17.2 of [RFC6881].
14.2. MIME Content-type Registration for 'application/ 14.2. MIME Content-type Registration for 'application/
emergencyCallData.eCall.MSD+xml' emergencyCallData.eCall.MSD+per'
IANA is requested to add application/emergencyCallData.eCall.MSD+xml IANA is requested to add application/emergencyCallData.eCall.MSD+per
as a MIME content type, with a reference to this document, in as a MIME content type, with a reference to this document, in
accordance to the procedures of RFC 6838 [RFC6838] and guidelines in accordance to the procedures of RFC 6838 [RFC6838] and guidelines in
RFC 7303 [RFC7303]. RFC 7303 [RFC7303].
MIME media type name: application MIME media type name: application
MIME subtype name: emergencyCallData.eCall.MSD+xml MIME subtype name: emergencyCallData.eCall.MSD+per
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: none
Indicates the character encoding of the XML content. Encoding scheme: binary
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses ASN.1 PER, which is a binary
characters, depending on the character encoding used. See encoding; when transported in SIP, binary content transfer
Section 3.2 of RFC 7303 [RFC7303]. encoding is used.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
vehicle and incident-related data during an emergency call. This vehicle and incident-related data during an emergency call. This
data contains personal information including vehicle VIN, data contains personal information including vehicle VIN,
location, direction, etc. Appropriate precautions need to be location, direction, etc. Appropriate precautions need to be
taken to limit unauthorized access, inappropriate disclosure to taken to limit unauthorized access, inappropriate disclosure to
third parties, and eavesdropping of this information. In general, third parties, and eavesdropping of this information. In general,
it is permissible for the data to be unprotected while briefly in it is acceptable for the data to be unprotected while briefly in
transit within the Mobile Network Operator (MNO); the MNO is transit within the Mobile Network Operator (MNO); the MNO is
trusted to not permit the data to be accessed by third parties. trusted to not permit the data to be accessed by third parties.
Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data]
contain more discussion. contain more discussion.
Interoperability considerations: None Interoperability considerations: None
Published specification: Annex C of EN 15722 [msd] Published specification: Annex A 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
Magic Number: None Magic Number: None
File Extension: .xml File Extension: None
Macintosh file type code: 'TEXT' Macintosh file type code: 'BINA'
Person and email address for further information: Hannes Person and email address for further information: Randall Gellens,
Tschofenig, Hannes.Tschofenig@gmx.net rg+ietf@randy.pensive.org
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: This specification was produced by the European Committee Author: The MSD specification was produced by the European
For Standardization (CEN). For contact information, please see Committee For Standardization (CEN). For contact information,
<http://www.cen.eu/cen/Pages/contactus.aspx>. please see <http://www.cen.eu/cen/Pages/contactus.aspx>.
Change controller: The European Committee For Standardization Change controller: The European Committee For Standardization
(CEN) (CEN)
14.3. MIME Content-type Registration for 'application/ 14.3. MIME Content-type Registration for 'application/
emergencyCallData.eCall.control+xml' emergencyCallData.eCall.control+xml'
IANA is requested to add application/ IANA is requested to add application/
emergencyCallData.eCall.control+xml as a MIME content type, with a emergencyCallData.eCall.control+xml as a MIME content type, with a
reference to this document, in accordance to the procedures of RFC reference to this document, in accordance to the procedures of RFC
skipping to change at page 31, line 41 skipping to change at page 24, line 41
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: Security considerations:
This content type carries metadata and control information and This content type carries metadata and control information and
requests, primarily from a Public Safety Answering Point (PSAP) requests, such as from a Public Safety Answering Point (PSAP)
to an In-Vehicle System (IVS) during an emergency call, and to an In-Vehicle System (IVS) during an emergency call.
also capabilities from the IVS to the PSAP.
Metadata (such as an acknowledgment that data sent by the IVS Metadata (such as an acknowledgment that data sent by the IVS
to the PSAP was successfully received) has limited privacy and to the PSAP was successfully received) has limited privacy and
security implications. Control information (such as requests security implications. Control information (such as requests
from the PSAP that the vehicle perform an action) has some from the PSAP that the vehicle perform an action) has some
privacy and important security implications. The privacy privacy and security implications. The privacy concern arises
concern arises from the ability to request the vehicle to from the ability to request the vehicle to transmit a data set,
transmit a data set, which as described in Section 14.2, can which as described in Section 14.2, can contain personal
contain personal information. The security concern is the information. The security concern is the ability to request
ability to request the vehicle to perform an action. It is the vehicle to perform an action. Control information needs to
important that control information originate only from a PSAP originate only from a PSAP or other emergency services
or other emergency services provider, and not be modified en- provider, and not be modified en-route. The level of integrity
route. The level of integrity of the cellular network over of the cellular network over which the emergency call is placed
which the emergency call is placed is important: when the IVS is a consideration: when the IVS initiates an eCall over a
initiates an eCall over a cellular network, it relies on the cellular network, in most cases it relies on the MNO to route
MNO to route the call to a PSAP. (Calls placed using other the call to a PSAP. (Calls placed using other means, such as
means, such as Wi-Fi or over-the-top services, generally incur Wi-Fi or over-the-top services, generally incur somewhat higher
higher levels of risk than calls placed over cellular levels of risk than calls placed "natively" using cellular
networks.) A call-back from a PSAP incurs additional risk, networks.) A call-back from a PSAP merits additional
since the current mechanisms are not ideal for verifying that consideration, since current mechanisms are not ideal for
such a call is indeed a call-back from a PSAP in response to an verifying that such a call is indeed a call-back from a PSAP in
emergency call placed by the IVS. See the discussion in response to an emergency call placed by the IVS. See the
Section 11 and the PSAP Callback document [RFC7090]. One discussion in Section 11 and the PSAP Callback document
safeguard, applicable regardless of which end initiated the [RFC7090]. One potential safeguard, applicable regardless of
call and the means of the call, is for the PSAP or emergency which end initiated the call and the means of the call, is for
service provider to sign the body part using a certificate the PSAP or emergency service provider to sign the body part
issued by a known emergency services certificate authority and using a certificate issued by a known emergency services
for which the IVS can verify the root certificate. certificate authority and for which the IVS can verify the root
certificate; however, this depends on deployed key
infrastructure including a recognized certificate authority,
certificate revocation mechanisms, etc.
Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data]
contain more discussion. contain more discussion.
Interoperability considerations: None Interoperability considerations: None
Published specification: Annex C of EN 15722 [msd] Published specification: This document
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@randy.pensive.org
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
skipping to change at page 35, line 35 skipping to change at page 28, line 35
This document creates a new registry called 'eCall Control Data'. This document creates a new registry called 'eCall Control Data'.
The following sub-registries are created for this registry. The following sub-registries are created for this registry.
14.8.1. eCall Control Action Registry 14.8.1. eCall Control Action Registry
This document creates a new sub-registry called "eCall Control Action This document creates a new sub-registry called "eCall Control Action
Registry". As defined in [RFC5226], this registry operates under Registry". As defined in [RFC5226], this registry operates under
"Expert Review" rules. The expert should determine that the proposed "Expert Review" rules. The expert should determine that the proposed
action is within the purview of a vehicle, is sufficiently action is within the purview of a vehicle, is sufficiently
distinguishable from other actions, and the actions is clearly and distinguishable from other actions, and the action is clearly and
fully described. In most cases, a published and stable document is fully described. In most cases, a published and stable document is
referenced for the description of the action. referenced for the description of the action.
The content of this registry includes: The content of this registry includes:
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 2. The initial set of values is listed in Table 2.
+---------------+------------------------------+ +-----------+------------------------------------------+
| Name | Description | | Name | Description |
+---------------+------------------------------+ +-----------+------------------------------------------+
| send-data | Section xxx of this document | | send-data | Section Section 8.1.2.1 of this document |
| | | +-----------+------------------------------------------+
| msg-static | Section xxx of this document |
| | |
| msg-dynamic | Section xxx of this document |
| | |
| honk | Section xxx of this document |
| | |
| lamp | Section xxx of this document |
| | |
| enable-camera | Section xxx of this document |
+---------------+------------------------------+
Table 2: eCall Control Action Registry Initial Values Table 2: eCall Control Action Registry Initial Values
14.8.2. eCall Static Message Registry 14.8.2. eCall Control Extension Registry
This document creates a new sub-registry called "eCall Static Message
Registry". Because all compliant vehicles are expected to support
all static messages translated into all languages supported by the
vehicle, it is important to limit the number of such messages. As
defined in [RFC5226], this registry operates under "Publication
Required" rules, which require a stable, public document and imply
expert review of the publication. The expert should determine that
the document has been published by an appropriate emergency services
organization (e.g., NENA, EENA, APCO) and that the proposed message
is sufficiently distinguishable from other messages.
The content of this registry includes:
ID: An integer identifier to be used in the 'msgid' attribute of an
eCall control <request> element.
Message: The text of the message. Messages are listed in the
registry in English; vehicles are expected to implement
translations into languages supported by the vehicle.
When new messages are added to the registry, the message text is
determined by the registrant; IANA assigns the IDs. Each message is
assigned a consecutive integer value as its ID. This allows an IVS
to indicate by a single integer value that it supports all messages
with that value or lower.
The initial set of values is listed in Table 3.
+----+--------------------------------------------------------------+
| ID | Message |
+----+--------------------------------------------------------------+
| 1 | Emergency authorities are aware of your incident and |
| | location, but are unable to speak with you right now. We |
| | will help you as soon as possible. |
+----+--------------------------------------------------------------+
Table 3: eCall Static Message Registry
14.8.3. eCall Reason Registry
This document creates a new sub-registry called "eCall Reason
Registry" which contains values for the 'reason' attribute of the
<actionResult> element. As defined in [RFC5226], this registry
operates under "Expert Review" rules. The expert should determine
that the proposed reason is sufficiently distinguishable from other
reasons and that the proposed description is understandable and
correctly worded.
The content of this registry includes:
ID: A short string identifying the reason, for use in the 'reason'
attribute of an <actionResult> element.
Description: A description of the reason.
The initial set of values is listed in Table 4.
+------------------+------------------------------------------------+
| ID | Description |
+------------------+------------------------------------------------+
| unsupported | The 'action' is not supported. |
| | |
| unable | The 'action' could not be accomplished. |
| | |
| data-unsupported | The data item referenced in a 'send-data' |
| | 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
14.8.4. eCall Lamp ID Registry
This document creates a new sub-registry called "eCall Lamp ID
Registry" to standardize the names of automotive lamps (lights). As
defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should determine that the proposed lamp name is
clearly understandable and is sufficiently distinguishable from other
lamp names.
The content of this registry includes:
Name: The identifier to be used in the 'lamp-ID' attribute of an
eCall control <request> element.
Description: A description of the lamp (light).
The initial set of values is listed in Table 5.
+----------------+---------------------------------------------+
| Name | Description |
+----------------+---------------------------------------------+
| head | The main lamps used to light the road ahead |
| | |
| interior | Interior lamp, often at the top center |
| | |
| fog-front | Front fog lamps |
| | |
| fog-rear | Rear fog lamps |
| | |
| brake | Brake indicator lamps |
| | |
| position-front | Front position/parking/standing lamps |
| | |
| position-rear | Rear position/parking/standing lamps |
| | |
| turn-left | Left turn/directional lamps |
| | |
| turn-right | Right turn/directional lamps |
| | |
| hazard | Hazard/four-way lamps |
+----------------+---------------------------------------------+
Table 5: eCall Lamp ID Registry Initial Values
14.8.5. eCall Camera ID Registry
This document creates a new sub-registry called "eCall Camera ID This document creates a new sub-registry called "eCall Control
Registry" to standardize the names of automotive camera. As defined Extension Registry". This registry contains elements, attributes,
in [RFC5226], this registry operates under "Expert Review" rules. and values for the eCall metadata/control object. As defined in
The expert should determine that the proposed camera name is clearly [RFC5226], this registry operates under "Expert Review" rules. The
understandable and is sufficiently distinguishable from other camera expert should determine that the proposed elements, attributes, and/
names. or values are within the purview of a vehicle, are sufficiently
distinguishable, and clearly and fully described. In most cases, a
published and stable document is referenced for the description of
each element, attribute, or value. New values MUST indicate for
which attributes or elements they are appropriate. New attributes
MUST indicate in which elements they can appear and to which values
that can be set. New elements MUST indicate if they can appear as
child elements within other elements, and if so which elements, and/
or if they can appear at the top level of an eCall metadata/control
object. New elements MUST also describe which attributes and/or sub-
elements they can contain and which are optional and which are
mandatory. Note that this mechanism allows new items to be added
while maintaining compatibility with existing implementations, since
unrecognized items are ignored.
The content of this registry includes: The content of this registry includes:
Name: The identifier to be used in the 'camera-ID' attribute of an Type: 'Element', 'Attribute', or 'Value'.
eCall control <request> element.
Description: A description of the camera.
The initial set of values is listed in Table 6.
+----------+--------------------------------------------------------+ Name: The name of the new element or attribute. Not used for new
| Name | Description | values.
+----------+--------------------------------------------------------+
| backup | Shows what is behind the vehicle. Also known as |
| | rearview, reverse, etc. |
| | |
| interior | Shows the interior (driver) |
+----------+--------------------------------------------------------+
Table 6: eCall Camera ID Registry Initial Values Description: A description of the element, attribute, or value. In
most cases this will be a reference to a published and stable
document.
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, James Winterbottom, Wes feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith
George, and Rex Buddenberg for their review and comments. We would Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and
like to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and James Winterbottom for their review and comments; Robert Sparks and
Paul Kyzivat for their help with the SIP mechanisms. We would like
to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and
Ulrich Dietz for their help with the original document upon which Ulrich Dietz for their help with the original document upon which
this document is based. this document is based.
17. Changes from Previous Versions 17. Changes from Previous Versions
17.1. Changes from draft-ietf-05 to draft-ietf-06
17.1. Changes from draft-ietf-07 to draft-ietf-08
o eCall MSD now encoded as ASN.1 PER, using binary content transfer
encoding
o Added text to point out aspects of call handling and metadata/
control usage, such as use in rejected calls, call-backs, and
solicited MSDs
o Revised use of INFO to require that when a request for an MSD is
sent in INFO, the MSD sent in response is in its own INFO, not the
response to the requesting INFO
o Added material to INFO package registation to comply with
Section 10 of [RFC6086]
o Moved material not required by 3GPP into
[I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/
control elements, attributes, and values
o Revised test call wording to clarify that specific handling is out
of scope
o Revised wording throughout the document to simplify
o Moved new Section Section 6.1 to be a subsection of Section 6
o Moved new Section Section 9 to be a main section instead of a
subsection of Section 8
o Revised SIP INFO usage and package registration per advice from
Robert Sparks and Paul Kyzivat
17.2. Changes from draft-ietf-06 to draft-ietf-07
o Fixed typo in Acknowledgements
17.3. Changes from draft-ietf-05 to draft-ietf-06
o Added additional security and privacy clarifications regarding o Added additional security and privacy clarifications regarding
signed and encrypted data signed and encrypted data
o Additional security and privacy text o Additional security and privacy text
o Deleted informative section on ESINets as unnecessary. o Deleted informative section on ESINets as unnecessary.
17.2. Changes from draft-ietf-04 to draft-ietf-05 17.4. Changes from draft-ietf-04 to draft-ietf-05
o Reworked the security and privacy considerations material in the o Reworked the security and privacy considerations material in the
document as a whole and in the MIME registation sections of the document as a whole and in the MIME registation sections of the
MSD and control objects MSD and control objects
o Clarified that the <actionResult> element can appear multiple o Clarified that the <actionResult> element can appear multiple
times within an <ack> element times within an <ack> element
o Fixed IMS definition o Fixed IMS definition
o Added clarifying text for the 'msgid' attribute o Added clarifying text for the 'msgid' attribute
17.3. Changes from draft-ietf-03 to draft-ietf-04 17.5. Changes from draft-ietf-03 to draft-ietf-04
o Added Privacy Considerations section o Added Privacy Considerations section
o Reworded most uses of non-normative "may", "should", "must", and o Reworded most uses of non-normative "may", "should", "must", and
"recommended." "recommended."
o Fixed nits in examples o Fixed nits in examples
17.4. Changes from draft-ietf-02 to draft-ietf-03 17.6. 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.5. Changes from draft-ietf-01 to draft-ietf-02 17.7. 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.6. Changes from draft-ietf-00 to draft-ietf-01 17.8. 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.7. Changes from draft-gellens-03 to draft-ietf-00 17.9. 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.8. Changes from draft-gellens-02 to -03 17.10. Changes from draft-gellens-02 to -03
o Clarifications and editorial improvements. o Clarifications and editorial improvements.
17.9. Changes from draft-gellens-01 to -02 17.11. 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.10. Changes from draft-gellens-00 to -01 17.12. 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
[I-D.ietf-ecrit-additional-data] [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, EN 16072", April
2015.
[I-D.ietf-ecrit-additional-data] [I-D.ietf-ecrit-additional-data]
Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", draft-ietf-ecrit-additional-data-37 (work in Call", draft-ietf-ecrit-additional-data-38 (work in
progress), October 2015. progress), April 2016.
[msd] CEN, , "Intelligent transport systems -- eSafety -- eCall
minimum set of data (MSD), EN 15722", April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, DOI Emergency and Other Well-Known Services", RFC 5031,
10.17487/RFC5031, January 2008, DOI 10.17487/RFC5031, January 2008,
<http://www.rfc-editor.org/info/rfc5031>. <http://www.rfc-editor.org/info/rfc5031>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet "Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, DOI 10.17487/RFC6443, December Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <http://www.rfc-editor.org/info/rfc6443>. 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13,
6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>. <http://www.rfc-editor.org/info/rfc6838>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<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, , "3GPP TS 22.101: Technical Specification Group
Aspects; Service aspects; Service principles", . Services and System Aspects; Service aspects; Service
principles".
[msd] CEN, , "Intelligent transport systems -- eSafety -- eCall
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] [I-D.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-03 (work in progress), July 2015. ecrit-car-crash-07 (work in progress), February 2016.
[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.
Shanmugam, "Security Threats and Requirements for Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, DOI Emergency Call Marking and Mapping", RFC 5069,
10.17487/RFC5069, January 2008, DOI 10.17487/RFC5069, January 2008,
<http://www.rfc-editor.org/info/rfc5069>. <http://www.rfc-editor.org/info/rfc5069>.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
<http://www.rfc-editor.org/info/rfc6086>. <http://www.rfc-editor.org/info/rfc6086>.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
Patel, "Public Safety Answering Point (PSAP) Callback", Patel, "Public Safety Answering Point (PSAP) Callback",
RFC 7090, DOI 10.17487/RFC7090, April 2014, RFC 7090, DOI 10.17487/RFC7090, April 2014,
skipping to change at page 44, line 20 skipping to change at page 35, line 8
"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>.
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
Qualcomm Technologies, Inc. Consultant
5775 Morehouse Drive 6755 Mira Mesa Blvd 123-151
San Diego 92651 San Diego 92121
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. 207 change blocks. 
1077 lines changed or deleted 653 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/