< draft-ietf-ecrit-ecall-02.txt   draft-ietf-ecrit-ecall-03.txt >
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Qualcomm Technologies, Inc.
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: September 8, 2015 (no affiliation) Expires: January 5, 2016
March 7, 2015 July 4, 2015
Next-Generation Pan-European eCall Next-Generation Pan-European eCall
draft-ietf-ecrit-ecall-02.txt draft-ietf-ecrit-ecall-03.txt
Abstract Abstract
This document describes how to use IP-based emergency services This document describes how to use IP-based emergency services
mechanisms to support the next generation of the Pan European in- mechanisms to support the next generation of the Pan European in-
vehicle emergency call service defined under the eSafety initiative vehicle emergency call service defined under the eSafety initiative
of the European Commission (generally referred to as "eCall"). eCall of the European Commission (generally referred to as "eCall"). eCall
is a standardized and mandated system for a special form of emergency is a standardized and mandated system for a special form of emergency
calls placed by vehicles. eCall deployment is required in the very calls placed by vehicles. eCall deployment is required in the very
near future in European Union member states, and eCall (and eCall- near future in European Union member states, and eCall (and eCall-
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2015. This Internet-Draft will expire on January 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6
5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10
9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11
9.1.1. The 'ack' Element . . . . . . . . . . . . . . . . . . 12 9.1.1. The <ack> element . . . . . . . . . . . . . . . . . . 12
9.1.1.1. Attributes of the 'ack' Element . . . . . . . . . 13 9.1.1.1. Attributes of the <ack> element . . . . . . . . . 13
9.1.1.2. Child Elements of the 'ack' Element . . . . . . . 13 9.1.1.2. Child Elements of the <ack> element . . . . . . . 13
9.1.2. The 'capabilities' Element . . . . . . . . . . . . . 14 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14
9.1.2.1. Child Elements of the 'capabilities' Element . . 14 9.1.2. The <capabilities> element . . . . . . . . . . . . . 15
9.1.3. The 'request' Element . . . . . . . . . . . . . . . . 15 9.1.2.1. Child Elements of the <capabilities> element . . 15
9.1.3.1. Attributes of the 'request' Element . . . . . . . 15 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16
9.1.3.2. Child Elements of the 'request' Element . . . . . 16 9.1.3. The <request> element . . . . . . . . . . . . . . . . 16
9.2. The emergencyCallData.eCall INFO package . . . . . . . . 16 9.1.3.1. Attributes of the <request> element . . . . . . . 17
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1.3.2. Child Elements of the <request> element . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Service URN Registrations . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
13.1. Service URN Registrations . . . . . . . . . . . . . . . 29
13.2. MIME Content-type Registration for 13.2. MIME Content-type Registration for
'application/emergencyCallData.eCall.MSD+xml' . . . . . 21 'application/emergencyCallData.eCall.MSD+xml' . . . . . 30
13.3. MIME Content-type Registration for 13.3. MIME Content-type Registration for
'application/emergencyCallData.eCall.control+xml' . . . 22 'application/emergencyCallData.eCall.control+xml' . . . 31
13.4. Registration of the 'eCall.MSD' entry in the Emergency 13.4. Registration of the 'eCall.MSD' entry in the Emergency
Call Additional Data Blocks registry . . . . . . . . . . 24 Call Additional Data Blocks registry . . . . . . . . . . 32
13.5. Registration of the 'eCall.control' entry in the 13.5. Registration of the 'eCall.control' entry in the
Emergency Call Additional Data Blocks registry . . . . . 24 Emergency Call Additional Data Blocks registry . . . . . 33
13.6. Registration of the emergencyCallData.eCall Info Package 24 13.6. Registration of the emergencyCallData.eCall Info Package 33
13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 24 13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33
13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 24 13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33
13.7.2. Registration for 13.7.2. Registration for
urn:ietf:params:xml:ns:eCall:control . . . . . . . . 25 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34
13.8. Registry creation . . . . . . . . . . . . . . . . . . . 26 13.8. Registry creation . . . . . . . . . . . . . . . . . . . 34
13.8.1. eCall Control Action Registry . . . . . . . . . . . 26 13.8.1. eCall Control Action Registry . . . . . . . . . . . 34
13.8.2. eCall Static Message Registry . . . . . . . . . . . 27 13.8.2. eCall Static Message Registry . . . . . . . . . . . 35
13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 28 13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 36
13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 28 13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 37
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 13.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 38
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
16. Changes from Previous Versions . . . . . . . . . . . . . . . 30 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 30 16. Changes from Previous Versions . . . . . . . . . . . . . . . 39
16.2. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 30 16.1. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
16.3. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 30 16.2. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
16.4. Changes from draft-gellens-02 to -03 . . . . . . . . . . 31 16.3. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40
16.5. Changes from draft-gellens-01 to -02 . . . . . . . . . . 31 16.4. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 40
16.6. Changes from draft-gellens-00 to -01 . . . . . . . . . . 31 16.5. Changes from draft-gellens-02 to -03 . . . . . . . . . . 40
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 16.6. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
17.1. Normative References . . . . . . . . . . . . . . . . . . 31 16.7. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40
17.2. Informative references . . . . . . . . . . . . . . . . . 32 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 17.1. Normative References . . . . . . . . . . . . . . . . . . 41
17.2. Informative references . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document re-uses terminology defined in Section 3 of [RFC5012]. This document re-uses terminology defined in Section 3 of [RFC5012].
Additionally, we use the following abbreviations: Additionally, we use the following abbreviations:
skipping to change at page 7, line 49 skipping to change at page 7, line 49
Note that if additional data sets are defined and registered (e.g., Note that if additional data sets are defined and registered (e.g.,
in the future or in other regions) and transmitted using the same in the future or in other regions) and transmitted using the same
mechanisms, the size and frequency of transmission during a session mechanisms, the size and frequency of transmission during a session
needs to be evaluated to be sure it is appropriate to use the needs to be evaluated to be sure it is appropriate to use the
signaling channel. signaling channel.
6. Call Setup 6. Call Setup
In circuit-switched eCall, the IVS places a special form of a 112 In circuit-switched eCall, the IVS places a special form of a 112
emergency call which carries the 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 +------+
skipping to change at page 11, line 48 skipping to change at page 11, line 48
ack Used in a control block sent by either side. The PSAP ack Used in a control block sent by either side. The PSAP
uses this to acknowledge receipt of data set sent by uses this to acknowledge receipt of data set sent by
the IVS. The IVS uses this to acknowledge receipt of a the IVS. The IVS uses this to acknowledge receipt of a
request by the PSAP when that request would not request by the PSAP when that request would not
otherwise be acknowledged (if the PSAP requests the otherwise be acknowledged (if the PSAP requests the
vehicle to send data and the vehicle does so, the data vehicle to send data and the vehicle does so, the data
serves as a success acknowledgement). serves as a success acknowledgement).
capabilities: Used in a control block sent from the IVS to the PSAP capabilities: Used in a control block sent from the IVS to the PSAP
(in the initial INVITE or subsequently if desired) to (e.g., in the initial INVITE) to inform the PSAP of the
inform the PSAP of the vehicle capabilities. Child vehicle capabilities. Child elements contain all
elements contain all actions and data types supported actions and data types supported by the vehicle and all
by the vehicle . 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 the IVS, to
request the vehicle to perform an action. request the vehicle to perform an action.
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 Play and/or display static (pre-defined) message
o Speak/display dynamic text (text supplied in action) o Speak/display dynamic text (text supplied in action)
o Flash lights, honk horn 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, and The <ack> element indicates the object being acknowledged (i.e., a
reports success or failure. data object or a <request> element), and reports success or failure.
The 'capabilities' element has child 'request' elements to indicate The <capabilities> element has child <request> elements to indicate
the actions supported by the IVS. the actions supported by the IVS.
The 'request' element contains attributes to indicate the request and The <request> element contains attributes to indicate the request and
to supply any needed information, and MAY contain a 'text' child to supply any needed information, and MAY contain a <text> child
element to contain the text for a dynamic message. The 'action' element to contain the text for a dynamic message. The 'action'
attribute is mandatory and indicates the specific action. An IANA attribute is mandatory and indicates the specific action. An IANA
registry is established by this document in Section 13.8.1 to contain registry is created in Section 13.8.1 to contain the allowed values.
the allowed values.
New elements, child elements, and attributes can be defined with Extensibility: New elements, child elements, and attributes can be
their own sub-namespaces. IANA registries are used to specify the defined in new namespaces. IANA registries are used to specify the
permitted values of several elements and attributes. These permitted values of several elements and attributes. These
mechanisms allow for extension. mechanisms allow for extension.
The control block does not contain a 'request' action to play dynamic The control block does not contain a 'request' action to play dynamic
media (such as a pre-recorded audio message). The SIP re-INVITE media (such as a pre-recorded audio message). The SIP re-INVITE
mechanism can be used to establish a one-way media stream for this mechanism can be used to establish a one-way media stream for this
purpose. purpose.
9.1.1. The 'ack' Element 9.1.1. The <ack> element
The 'ack' element is transmitted by the PSAP to acknowledge receipt The <ack> element is transmitted by the PSAP to acknowledge receipt
of an eCall data object. An 'ack' element sent by a PSAP references of an eCall data object. An <ack> element sent by a PSAP references
the unique ID of the data object that was sent by the IVS, and the unique ID of the data object that was sent by the IVS, and
further indicates if the PSAP considers the receipt successful or further indicates if the PSAP considers the receipt successful or
not. The 'ack' element is also transmitted by the IVS to the PSAP to not. The <ack> element is also transmitted by the IVS to the PSAP to
acknowledge receipt of a 'request' element that requested the IVS to acknowledge receipt of a <request> element that requested the IVS to
perform an action other than transmitting a data object (e.g., a perform an action other than transmitting a data object (e.g., a
request to display a message would be acknowledged, but a request to request to display a message would be acknowledged, but a request to
transmit a data object would not result in a separate 'ack' element transmit a data object would not result in a separate <ack> element
being sent, since the data object itself serves as acknowledgment.) being sent, since the data object itself serves as acknowledgment.)
An 'ack' element sent by an IVS references the unique ID of the An <ack> element sent by an IVS references the unique ID of the
request being acknowledged, and further indicates whether the request request being acknowledged, indicates whether the request was
was successfully performed. 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 and child elements:
9.1.1.1. Attributes of the 'ack' Element 9.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 or control object being acknowledged.
Example: <ack received="yes" ref="1234567890@atlanta.example.com"/> Example: <ack received="yes" ref="1234567890@atlanta.example.com"/>
Name: rec Name: received
Usage: Mandatory 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 9.1.1.2. Child Elements of the <ack> element
The 'ack' element has the following child elements: The <ack> element has the following child elements:
Name: ActionResult Name: actionResult
Usage: Optional Usage: Optional
Description: An 'ActionResult' element indicates the result of an Description: An <actionResult> element indicates the result of an
action (other than a 'send-data' action). It has the following action (other than a 'send-data' action). It has the following
attributes: attributes:
Name: action Name: action
Usage: Mandatory Usage: Mandatory
Type: token Type: token
Description: Contains the value of the 'action' attribute of the Description: Contains the value of the 'action' attribute of the
'request' element <request> element
Name: success Name: success
Usage: Mandatory Usage: Mandatory
Type: Boolean Type: Boolean
Description: Indicates if the action was successfully Description: Indicates if the action was successfully
accomplished accomplished
Name: reason Name: reason
Usage: Conditional Usage: Conditional
Type: token Type: token
skipping to change at page 14, line 19 skipping to change at page 14, line 21
contains a reason code for a failure. A registry for reason contains a reason code for a failure. A registry for reason
codes is defined in Section 13.8.3. codes is defined in Section 13.8.3.
Name: details Name: details
Usage: optional Usage: optional
Type: string Type: string
Description: Contains further explanation of the circumstances of Description: Contains further explanation of the circumstances of
a success or failure. The contents are implementation-specific a success or failure. The contents are implementation-specific
and human-readable. and human-readable.
Example: <ActionResult action="msg-dynamic" success="true"/> Example: <actionResult action="msg-dynamic" success="true"/>
Example: <ActionResult action="lamp" success="false" reason="unable" Example: <actionResult action="lamp" success="false" reason="unable"
details="The requested lamp is inoperable"/> details="The requested lamp is inoperable"/>
9.1.2. The 'capabilities' Element 9.1.1.3. Ack Examples
The 'capabilities' element is transmitted by the IVS to indicate to <?xml version="1.0" encoding="UTF-8"?>
the PSAP its capabilities. No attributes are currently defined. The <EmergencyCallData.eCallControl
following child elements may be used: 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">
9.1.2.1. Child Elements of the 'capabilities' Element <ack received="true" ref="1234567890@atlanta.example.com"/>
The 'capabilities' element has the following child elements: </EmergencyCallData.eCallControl>
Figure 3: Ack Example from PSAP to IVS
<?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">
<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
the PSAP its capabilities. No attributes for this element are
currently defined. The following child elements are defined:
9.1.2.1. Child Elements of the <capabilities> element
The <capabilities> element has the following child elements:
Name: request Name: request
Usage: Mandatory Usage: Mandatory
Description: The 'capabilities' element contains a <request> child Description: The <capabilities> element contains a <request> child
element per action supported by the vehicle. Because support for element per action supported by the vehicle.
a 'send-data' action is REQUIRED, a <request> child element with a
"send-data" 'action' attribute is also REQUIRED. The 'supported- Because support for a 'send-data' action is REQUIRED, a <request>
datatype' attribute is REQUIRED in this <request> element and MUST child element with a "send-data" 'action' attribute is also
contain all eCall data blocks supported by the IVS. Currently, REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this
only the 'eCall.MSD' datatype is defined. All other actions are <request> element within a <capabilities> element, and MUST
OPTIONAL. If the "msg-static" action is supported, a <request> contain at a minimum the 'eCall.MSD' data block value; it SHOULD
child element with a "msg-static" 'action' attribute is sent, with contain all data blocks supported by the IVS.
a 'msgid' attribute set to the highest supported static message
supported by the vehicle. All other actions are OPTIONAL.
Examples: <request action="send-data" supported-datatype="eCall.MSD"
/> If the "msg-static" action is supported, a <request> child element
<request action="send-data" supported-datatype="eCall.MSD; VEDS; with a "msg-static" 'action' attribute is sent, with a 'msgid'
attribute set to the highest supported static message supported by
the vehicle.
If the "lamp" action is supported, a <request> child element with
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
element with an "enable-camera" 'action' is sent, with a
'supported-cameras' attribute set to all supported camera IDs.
Examples:
<request action="send-data" supported-datatypes="eCall.MSD" />
<request action="send-data" supported-datatypes="eCall.MSD; VEDS;
eCall.type2" /> eCall.type2" />
<request action="msg-dynamic"/> <request action="msg-dynamic"/>
<request action="msg.static" msgid="17" /> <request action="msg.static" msgid="17" />
9.1.3. The 'request' Element 9.1.2.2. Capabilities Example
A 'request' element appears one or more times on its own or as a <?xml version="1.0" encoding="UTF-8"?>
child of a 'capabilities' element. The following attributes and <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>
<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>
Figure 5: Capabilities Example
9.1.3. The <request> element
A <request> element appears one or more times on its own or as a
child of a <capabilities> element. The following attributes and
child elements may be used: child elements may be used:
9.1.3.1. Attributes of the 'request' Element 9.1.3.1. Attributes of the <request> element
The 'request' element has the following attributes: The <request> element has the following attributes:
Name: action Name: action
Usage: Mandatory Usage: Mandatory
Type: token Type: token
Description: Identifies the action that the vehicle is requested to Description: Identifies the action that the vehicle is requested to
perform. An IANA registry is established in Section 13.8.1 to perform. An IANA registry is established in Section 13.8.1 to
contain the allowed values. contain the allowed values.
Example: action="send-data" Example: action="send-data"
Name: msgid Name: msgid
skipping to change at page 15, line 51 skipping to change at page 17, line 45
Usage: Conditional Usage: Conditional
Type: token Type: token
Description: Mandatory with a "send-data" action. Specifies the Description: Mandatory with a "send-data" action. Specifies the
data block that the IVS is requested to transmit, using the same data block that the IVS is requested to transmit, using the same
identifier as in the 'purpose' attribute set in a Call-Info header identifier as in the 'purpose' attribute set in a Call-Info header
field to point to the data block. Permitted values are contained field to point to the data block. Permitted values are contained
in the 'Emergency Call Data Types' IANA registry established in in the 'Emergency Call Data Types' IANA registry established in
[additional-data-draft]. [additional-data-draft].
Example: datatype="eCall.MSD" Example: datatype="eCall.MSD"
Name: supported-datatype Name: supported-datatypes
Usage: Conditional Usage: Conditional
Type: token Type: string
Description: Used with a 'send-data' action in a 'request' element Description: Used with a 'send-data' action in a <request> element
that is a child of a 'capability' element, this attribute lists that is a child of a <capability> element, this attribute lists
all data blocks that the vehicle can transmit, using the same all data blocks that the vehicle can transmit, using the same
identifier as in the 'purpose' attribute in a Call-Info header identifier as in the 'purpose' attribute in a Call-Info header
field to point to the data block. Permitted values are contained field to point to the data block. Permitted values are contained
in the 'Emergency Call Data Types' IANA registry established in in the 'Emergency Call Data Types' IANA registry established in
[additional-data-draft]. Multiple values are separated with a [additional-data-draft]. Multiple values are separated with a
semicolon. semicolon.
Example: supported-datatype="eCall.MSD; VEDS; eCall.foo" Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo"
Name: lamp-ID
Usage: Conditional
Type: token
Description: Used with a 'lamp' action, indicates which lamps the
action affects. This document creates a registry of lamp-ID
tokens, in Section 13.8.4
Example: lamp-ID="hazard"
Name: lamp-action Name: lamp-action
Usage: Conditional Usage: Conditional
Type: enumeration Type: token
Description: Used with a 'lamp' action, indicates if the lamp should Description: Used with a 'lamp' action, indicates if the lamp should
be illuminated, turned off, or flashed. Permitted values are be illuminated, turned off, or flashed. Permitted values are
'on', 'off', and 'flash'. 'on', 'off', and 'flash'.
Example: lamp-action="flash" Example: lamp-action="flash"
9.1.3.2. Child Elements of the 'request' Element Name: lamp-ID
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 13.8.4
Example: lamp-ID="hazard"
The 'request' element has the following child elements: Name: supported-lamps
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 13.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
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 13.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
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 13.8.5). Multiple values are separated with a
semicolon.
Example: supported-cameras="backup; interior"
9.1.3.2. Child Elements of the <request> element
The <request> element has the following child elements:
Name: text Name: text
Usage: Conditional Usage: Conditional
Type: string Type: string
Description: Used within a <request action="msg-dynamic"> element to Description: Used within a <request action="msg-dynamic"> element to
contain the text to be displayed and/or spoken (via text-to- contain the text to be displayed and/or spoken (via text-to-
speech) for the vehicle occupants. speech) for the vehicle occupants.
Example: <text>Emergency authorities are aware of your incident and Example: <text>Emergency authorities are aware of your incident and
location. Due to a multi-vehicle incident in your area, no one is location. Due to a multi-vehicle incident in your area, no one is
able to speak with you right now. Please remain calm. We will able to speak with you right now. Please remain calm. We will
assist you soon.</text> assist you soon.</text>
9.1.3.3. Request Example
<?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">
<request action="send-data" datatype="eCall.MSD"/>
<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>
Figure 6: Request Example
9.2. The emergencyCallData.eCall INFO package 9.2. The emergencyCallData.eCall INFO package
This document registers the 'emergencyCallData.eCall' INFO package. This document registers the 'emergencyCallData.eCall' INFO package.
Both endpoints (the IVS and the PSAP equipment) set the Recv-Info Both endpoints (the IVS and the PSAP equipment) set the Recv-Info
header field to 'emergencyCallData.eCall' per [RFC6086] to indicate header field to 'emergencyCallData.eCall' per [RFC6086] to indicate
ability to receive INFO messages carrying eCall data or control ability to receive INFO messages carrying eCall data or control
blocks. blocks.
Support for the 'emergencyCallData.eCall' INFO package indicates the Support for the 'emergencyCallData.eCall' INFO package indicates the
ability to receive eCall data and control blocks, which are carried ability to receive eCall data and control blocks, which are carried
skipping to change at page 18, line 9 skipping to change at page 21, line 13
Call-Info header field containing a CID URL referencing the unique Call-Info header field containing a CID URL referencing the unique
identifier of the body part, and a 'purpose' parameter identifying identifier of the body part, and a 'purpose' parameter identifying
the block). When eCall data or control blocks are included in an the block). When eCall data or control blocks are included in an
INFO response message, this is done per [additional-data-draft] and INFO response message, this is done per [additional-data-draft] and
this document, and not under [RFC6086]; that is, they are included as this document, and not under [RFC6086]; that is, they are included as
emergency call additional data, not as an INFO package associated emergency call additional data, not as an INFO package associated
data. data.
10. Examples 10. Examples
Figure 3 shows an eCall. The call uses the request URI Figure 7 shows an eCall. The call uses the request URI
'urn:service:sos.ecall.automatic' service URN and is recognized as an 'urn:service:sos.ecall.automatic' service URN and is recognized as an
eCall, and further as one that was invoked automatically by the IVS eCall, and further as one that was invoked automatically by the IVS
due to a crash or other serious incident. In this example, the due to a crash or other serious incident. In this example, the
originating network routes the call to an ESInet (as for any originating network routes the call to an ESInet (as for any
emergency call in an environment with an ESInet). The ESInet routes emergency call in an environment with an ESInet). The ESInet routes
the call to the appropriate NG-eCall capable PSAP. The emergency the call to the appropriate NG-eCall capable PSAP. The emergency
call is received by the ESInet's Emergency Services Routing Proxy call is received by the ESInet's Emergency Services Routing Proxy
(ESRP), as the entry point into the ESInet. The ESRP routes the call (ESRP), as the entry point into the ESInet. The ESRP routes the call
to a PSAP, where it is received by a call taker. In deployments to a PSAP, where it is received by a call taker. In deployments
where there is no ESInet, the originating network routes the call where there is no ESInet, the originating network routes the call
skipping to change at page 18, line 38 skipping to change at page 21, line 42
Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker |
| | | +------+ +-------+ | | | | +------+ +-------+ |
| | | | | | | |
| | | +-------+ | | | | +-------+ |
| | | | PSAP3 | | | | | | PSAP3 | |
| Originating| | +-------+ | | Originating| | +-------+ |
| Mobile | | | | Mobile | | |
| Network | | ESInet | | Network | | ESInet |
+------------+ +---------------------------------------+ +------------+ +---------------------------------------+
Figure 3: Example of NG-eCall Message Flow Figure 7: Example of NG-eCall Message Flow
The example, shown in Figure 4, illustrates a SIP eCall INVITE that The example, shown in Figure 8, illustrates a SIP eCall INVITE that
contains an MSD. 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 INVITE urn:service:sos.ecall.automatic SIP/2.0
To: urn:service:sos.ecall.automatic To: urn:service:sos.ecall.automatic
From: <sip:+13145551111@example.com>;tag=9fxced76sl 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
<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>
<optionalAdditionalData>
<oid>1.2.125</oid>
<data>30304646</data>
</optionalAdditionalData>
</msd>
</ECallMessage>
--boundary1
Content-Type: application/emergencyCallData.eCall.control+xml
Content-ID: 2345678901@atlanta.example.com
<?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>
<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>
--boundary1--
Figure 8: SIP NG-eCall INVITE
Continuing the example, Figure 9 illustrates a SIP 200 OK response to
the INVITE of Figure 8, containing an eCall control block
acknowledging successful receipt of the eCall MSD. (For simplicity,
the example does not show all SIP headers.)
SIP/2.0 200 OK
To: <sip:+13145551111@example.com>;tag=9fxced76sl
From: Exemplar PSAP <urn:service:sos.ecall.automatic>
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@example.com> Call-Info: cid:2345678901@atlanta.example.com;
Geolocation-Routing: no purpose=emergencyCallData.eCall.control;
Call-Info: cid:1234567890@atlanta.example.com; Accept: application/sdp, application/pidf+xml,
purpose=emergencyCallData.eCall.MSD application/emergencyCallData.eCall.control,
Accept: application/sdp, application/pidf+xml application/emergencyCallData.eCall.MSD
CSeq: 31862 INVITE CSeq: 31862 INVITE
Recv-Info: emergencyCallData.eCall Recv-Info: emergencyCallData.eCall
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundaryX
Content-Length: ... Content-Length: ...
--boundary1 --boundaryX
Content-Type: application/sdp Content-Type: application/sdp
...Session Description Protocol (SDP) goes here ...Session Description Protocol (SDP) goes here...
--boundary1 --boundaryX
Content-Type: application/emergencyCallData.eCall.MSD+xml <?xml version="1.0" encoding="UTF-8"?>
Content-ID: 1234567890@atlanta.example.com <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">
...eCall MSD data object goes here <ack received="true" ref="1234567890@atlanta.example.com"/>
--boundary1-- </EmergencyCallData.eCallControl>
Figure 4: SIP NG-eCall INVITE --boundaryX
Figure 9: 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.
An eCall will carry two forms of location data: the network-provided An eCall will carry two forms of location data: the network-provided
location that is inherently part of IMS emergency calls (which might location that is inherently part of IMS emergency calls (which might
be determined solely by the network, or in cooperation with or be determined solely by the network, or in cooperation with or
possibly entirely by the originating device), and the IVS-supplied possibly entirely by the originating device), and the IVS-supplied
location within the MSD. This is likely to be useful to the PSAP, location within the MSD. This is likely to be useful to the PSAP,
skipping to change at page 20, line 21 skipping to change at page 26, line 28
trust issues in verifying that a call-back is indeed from a PSAP are trust issues in verifying that a call-back is indeed from a PSAP are
more complex (see the PSAP Callback document [RFC7090]). A further more complex (see the PSAP Callback document [RFC7090]). A further
safeguard (applicable regardless of which end initiated the call and safeguard (applicable regardless of which end initiated the call and
the means of the call) is for the PSAP or emergency service provider the means of the call) is for the PSAP or emergency service provider
to sign the body part using a certificate issued by a known emergency to sign the body part using a certificate issued by a known emergency
services certificate authority and for which the IVS can verify the services certificate authority and for which the IVS can verify the
root certificate. root certificate.
12. XML Schema 12. XML Schema
This section defines the XML schema of the eCall control block. This section defines the XML schema of the eCall control block. (The
schema for the MSD can be found in EN 15722 [msd].)
<?xml version="1.0" ?> <?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema
xmlns:tns="http://example.com/ct-required" targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/ct-required"> xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:eCall-control"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2005/05/xmlmime" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2005/05/xmlmime"/> schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
</xs:schema> <xs:element name="EmergencyCallData.eCallControl"
type="pi:eCallControlType"/>
Figure 5: eCall Control Block Schema <xs:complexType name="eCallControlType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="capabilities"
type="pi:capabilitiesType"/>
<xs:element name="request" type="pi:requestType"/>
<xs:element name="ack" type="pi:ackType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ackType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="actionResult" minOccurs="0">
<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"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ref"
type="xs:anyURI"
use="required"/>
<xs:attribute name="received"
type="xs:boolean"/>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</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:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
<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 name="datatype" type="xs:token"/>
<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:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Figure 10: eCall Control Block Schema
13. IANA Considerations 13. IANA Considerations
13.1. Service URN Registrations 13.1. Service URN Registrations
IANA is requested to register the URN 'urn:service:sos.ecall' under IANA is requested to register the URN 'urn:service:sos.ecall' under
the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].
This service identifies a type of emergency call (placed by a This service identifies a type of emergency call (placed by a
specialized in-vehicle system and a carrying standardized set of data specialized in-vehicle system and a carrying standardized set of data
skipping to change at page 25, line 5 skipping to change at page 33, line 32
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:eCall URI: urn:ietf:params:xml:ns:eCall
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>. delegated by the IESG <iesg@ietf.org>.
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Namespace for eCall Data</title> <title>Namespace for eCall Data</title>
</head> </head>
<body> <body>
<h1>Namespace for eCall Data <h1>Namespace for eCall Data</h1>
</h1> <p>See [TBD: This document].</p>
<p>See [TBD: This document].</p> </body>
</body> </html>
</html> END
END
13.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 13.7.2. Registration for urn:ietf:params:xml:ns:eCall:control
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:eCall:control URI: urn:ietf:params:xml:ns:eCall:control
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>. delegated by the IESG <iesg@ietf.org>.
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Namespace for eCall Data: <title>Namespace for eCall Data:
Control Block</title> Control Block</title>
</head> </head>
<body> <body>
<h1>Namespace for eCall Data <h1>Namespace for eCall Data</h1>
</h1> <h2>Control Block</h2>
<h2>Control Block</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
13.8. Registry creation 13.8. Registry creation
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.
skipping to change at page 26, line 43 skipping to change at page 35, line 8
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 actions 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 xxx of this document |
| | | | | |
| msg-static | Section xxx of this document | | msg-static | Section xxx of this document |
| | | | | |
| msg-dynamic | Section xxx of this document | | msg-dynamic | Section xxx of this document |
| | | | | |
| honk | Section xxx of this document | | honk | Section xxx of this document |
| | | | | |
| lamp | 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
13.8.2. eCall Static Message Registry 13.8.2. eCall Static Message Registry
This document creates a new sub-registry called "eCall Static Message This document creates a new sub-registry called "eCall Static Message
Registry". Because all compliant vehicles are expected to support Registry". Because all compliant vehicles are expected to support
all static messages translated into all languages supported by the all static messages translated into all languages supported by the
vehicle, it is important to limit the number of such messages. As vehicle, it is important to limit the number of such messages. As
defined in [RFC5226], this registry operates under "Publication defined in [RFC5226], this registry operates under "Publication
Required" rules, which require a stable, public document and imply Required" rules, which require a stable, public document and imply
expert review of the publication. The expert should determine that expert review of the publication. The expert should determine that
the document has been published by an appropriate emergency services the document has been published by an appropriate emergency services
organization (e.g., NENA, EENA, APCO) and that the proposed message organization (e.g., NENA, EENA, APCO) and that the proposed message
is sufficiently distinguishable from other messages. is sufficiently distinguishable from other messages.
The content of this registry includes: The content of this registry includes:
ID: An integer identifier to be used in the 'msgid' attribute of an ID: An integer identifier to be used in the 'msgid' attribute of an
eCall control 'request' element. eCall control <request> element.
Message: The text of the message. Messages are listed in the Message: The text of the message. Messages are listed in the
registry in English; vehicles are expected to implement registry in English; vehicles are expected to implement
translations into languages supported by the vehicle. translations into languages supported by the vehicle.
When new messages are added to the registry, the message text is When new messages are added to the registry, the message text is
determined by the registrant; IANA assigns the IDs. Each message is determined by the registrant; IANA assigns the IDs. Each message is
assigned a consecutive integer value as its ID. This allows an IVS assigned a consecutive integer value as its ID. This allows an IVS
to indicate by a single integer value that it supports all messages to indicate by a single integer value that it supports all messages
with that value or lower. with that value or lower.
The initial set of values is listed in Table 3. The initial set of values is listed in Table 3.
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
| ID | Message | | ID | Message |
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
| 1 | Emergency authorities are aware of your incident and | | 1 | Emergency authorities are aware of your incident and |
| | location. No one is free to speak with you right now. We | | | location, but are unable to speak with you right now. We |
| | will help you as soon as possible. | | | will help you as soon as possible. |
+----+--------------------------------------------------------------+ +----+--------------------------------------------------------------+
Table 3: eCall Static Message Registry Table 3: eCall Static Message Registry
13.8.3. eCall Reason Registry 13.8.3. eCall Reason Registry
This document creates a new sub-registry called "eCall Reason This document creates a new sub-registry called "eCall Reason
Registry" which contains values for the 'reason' attribute of the Registry" which contains values for the 'reason' attribute of the
'ActionResult' element. As defined in [RFC5226], this registry <actionResult> element. As defined in [RFC5226], this registry
operates under "Expert Review" rules. The expert should determine operates under "Expert Review" rules. The expert should determine
that the proposed reason is sufficiently distinguishable from other that the proposed reason is sufficiently distinguishable from other
reasons and that the proposed description is understandable and reasons and that the proposed description is understandable and
correctly worded. correctly worded.
The content of this registry includes: The content of this registry includes:
ID: A short string identifying the reason, for use in the 'reason' ID: A short string identifying the reason, for use in the 'reason'
attribute of an 'ActionResult' element. attribute of an <actionResult> element.
Description: A description of the reason. Description: A description of the reason.
The initial set of values is listed in Table 4. The initial set of values is listed in Table 4.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| ID | Description | | ID | Description |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| unsupported | The 'action' is not supported. | | unsupported | The 'action' is not supported. |
| | | | | |
| unable | The 'action' could not be accomplished. | | unable | The 'action' could not be accomplished. |
| | | | | |
| data-unsupported | The data item referenced in a 'send-data' | | data-unsupported | The data item referenced in a 'send-data' |
| | request is not supported. | | | request is not supported. |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 4: eCall Reason Registry Table 4: eCall Reason Registry
13.8.4. eCall Lamp ID Registry 13.8.4. eCall Lamp ID Registry
This document creates a new sub-registry called "eCall Lamp ID This document creates a new sub-registry called "eCall Lamp ID
Registry" to standardize the names of automotive lamps (lights). As Registry" to standardize the names of automotive lamps (lights). As
defined in [RFC5226], this registry operates under "Expert Review" defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should determine that the proposed lamp name is rules. The expert should determine that the proposed lamp name is
clearly understandable and is sufficiently distinguishable from other clearly understandable and is sufficiently distinguishable from other
lamp names. lamp names.
The content of this registry includes: The content of this registry includes:
Name: The identifier to be used in the 'lamp-ID' attribute of an Name: The identifier to be used in the 'lamp-ID' attribute of an
eCall control 'request' element. eCall control <request> element.
Description: A description of the lamp (light). Description: A description of the lamp (light).
The initial set of values is listed in Table 5. The initial set of values is listed in Table 5.
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
| Name | Description | | Name | Description |
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
| head | The main lamps used to light the road ahead | | head | The main lamps used to light the road ahead |
| | | | | |
skipping to change at page 29, line 42 skipping to change at page 38, line 31
| | | | | |
| turn-left | Left turn/directional lamps | | turn-left | Left turn/directional lamps |
| | | | | |
| turn-right | Right turn/directional lamps | | turn-right | Right turn/directional lamps |
| | | | | |
| hazard | Hazard/four-way lamps | | hazard | Hazard/four-way lamps |
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
Table 5: eCall Lamp ID Registry Initial Values Table 5: eCall Lamp ID Registry Initial Values
13.8.5. eCall Camera ID Registry
This document creates a new sub-registry called "eCall Camera ID
Registry" to standardize the names of automotive camera. As defined
in [RFC5226], this registry operates under "Expert Review" rules.
The expert should determine that the proposed camera name is clearly
understandable and is sufficiently distinguishable from other camera
names.
The content of this registry includes:
Name: The identifier to be used in the 'camera-ID' attribute of an
eCall control <request> element.
Description: A description of the camera.
The initial set of values is listed in Table 6.
+----------+--------------------------------------------------------+
| Name | Description |
+----------+--------------------------------------------------------+
| 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
14. Contributors 14. Contributors
Brian Rosen was a co-author of the original document upon which this Brian Rosen was a co-author of the original document upon which this
document is based. document is based.
15. Acknowledgements 15. Acknowledgements
We would like to thank Bob Williams and Ban Al-Bakri for their We would like to thank Bob Williams and Ban Al-Bakri for their
feedback and suggestions, and Keith Drage for his review comments. feedback and suggestions, and Keith Drage for his review comments.
We would like to thank Michael Montag, Arnoud van Wijk, Gunnar We would like to thank Michael Montag, Arnoud van Wijk, Gunnar
Hellstrom, and Ulrich Dietz for their help with the original document Hellstrom, and Ulrich Dietz for their help with the original document
upon which this document is based. upon which this document is based.
16. Changes from Previous Versions 16. Changes from Previous Versions
16.1. Changes from draft-ietf-01 to draft-ietf-02 16.1. Changes from draft-ietf-02 to draft-ietf-03
o Added request to enable cameras
o Improved examples and XML schema
o Clarifications and wording improvements
16.2. 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
16.2. Changes from draft-ietf-00 to draft-ietf-01 16.3. 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
16.3. Changes from draft-gellens-03 to draft-ietf-00 16.4. Changes from draft-gellens-03 to draft-ietf-00
o Renamed from draft-gellens- to draft-ietf-. o Renamed from draft-gellens- to draft-ietf-.
o Added mention of and reference to ETSI TR "Mobile Standards Group o Added mention of and reference to ETSI TR "Mobile Standards Group
(MSG); eCall for VoIP" (MSG); eCall for VoIP"
o Added text to Introduction regarding migration/co-existence being o Added text to Introduction regarding migration/co-existence being
out of scope out of scope
o Added mention in Security Considerations that even if the network- o Added mention in Security Considerations that even if the network-
supplied location is just the cell site, this can be useful as a supplied location is just the cell site, this can be useful as a
sanity check on the IVS-supplied location sanity check on the IVS-supplied location
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
16.4. Changes from draft-gellens-02 to -03 16.5. Changes from draft-gellens-02 to -03
o Clarifications and editorial improvements. o Clarifications and editorial improvements.
16.5. Changes from draft-gellens-01 to -02 16.6. Changes from draft-gellens-01 to -02
o Minor wording improvements o Minor wording improvements
o Removed ".automatic" and ".manual" from o Removed ".automatic" and ".manual" from
"urn:service:test.sos.ecall" registration and discussion text. "urn:service:test.sos.ecall" registration and discussion text.
16.6. Changes from draft-gellens-00 to -01 16.7. Changes from draft-gellens-00 to -01
o Now using 'EmergencyCallData' for purpose parameter values and o Now using 'EmergencyCallData' for purpose parameter values and
MIME subtypes, in accordance with changes to MIME subtypes, in accordance with changes to
[additional-data-draft] [additional-data-draft]
o Added reference to RFC 6443 o Added reference to RFC 6443
o Fixed bug that caused Figure captions to not appear o Fixed bug that caused Figure captions to not appear
17. References 17. References
17.1. Normative References 17.1. Normative References
[EN_16072] [EN_16072]
CEN, , "Intelligent transport systems - eSafety - Pan- CEN, , "Intelligent transport systems - eSafety - Pan-
European eCall operating requirements", December 2011. European eCall operating requirements", December 2011.
[I-D.ietf-ecrit-additional-data] [I-D.ietf-ecrit-additional-data]
Randy, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
Winterbottom, "Additional Data related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", draft-ietf-ecrit-additional-data-24 (work in Call", draft-ietf-ecrit-additional-data-30 (work in
progress), October 2014. progress), June 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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[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, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
skipping to change at page 34, line 4 skipping to change at page 43, line 27
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego 92651 San Diego 92651
US US
Email: rg+ietf@qti.qualcomm.com Email: rg+ietf@qti.qualcomm.com
Hannes Tschofenig Hannes Tschofenig
(no affiliation)
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. 96 change blocks. 
218 lines changed or deleted 628 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/