< draft-rosen-ecrit-ecall-06.txt   draft-rosen-ecrit-ecall-07.txt >
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: January 16, 2013 Nokia Siemens Networks Expires: August 25, 2013 Nokia Siemens Networks
July 15, 2012 February 21, 2013
Internet Protocol-based In-Vehicle Emergency Call Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-06.txt draft-rosen-ecrit-ecall-07.txt
Abstract Abstract
This document describes how to use a subset of the IETF-based This document describes how to use a subset of the IETF-based
emergency call framework for accomplishing emergency calling support emergency call framework for accomplishing emergency calling support
in vehicles. Simplifications are possible due to the nature of the in vehicles. Simplifications are possible due to the nature of the
functionality that is going to be provided in vehicles with the usage functionality that is going to be provided in vehicles with the usage
of GPS. Additionally, further profiling needs to be done regarding of GPS. Additionally, further profiling needs to be done regarding
the encoding of location information. the encoding of location information.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 16, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative references . . . . . . . . . . . . . . . . . . 12
10.2. Informative references . . . . . . . . . . . . . . . . . 15 Appendix A. Matching Functionality with eCall Minimum Set of
Data (MSD) . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Emergency calls made from vehicles can assist with the objective of Emergency calls made from vehicles can assist with the objective of
significantly reducing road deaths and injuries. Unfortunately, significantly reducing road deaths and injuries. Unfortunately,
drivers often have a poor location-awareness, especially on urban drivers often have a poor location-awareness, especially on urban
roads (also during night) and abroad. In the most crucial cases, the roads (also during night) and abroad. In the most crucial cases, the
victim(s) may not be able to call because they have been injured or victim(s) may not be able to call because they have been injured or
trapped. trapped.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
that may best be described as a user initiated or automatically that may best be described as a user initiated or automatically
triggered system to provide notifications to Public Safety Answering triggered system to provide notifications to Public Safety Answering
Point's (PSAP), by means of cellular communications, that a vehicle Point's (PSAP), by means of cellular communications, that a vehicle
has crashed, and to provide geodetic location information and where has crashed, and to provide geodetic location information and where
possible a voice channel to the PSAP. At the time of writing the possible a voice channel to the PSAP. At the time of writing the
suppor for eCall are focused on legacy technology. This document suppor for eCall are focused on legacy technology. This document
details how emergency calls triggered by vehicles can be accomplished details how emergency calls triggered by vehicles can be accomplished
in an Internet Protocol-based environment. in an Internet Protocol-based environment.
This document is organized as follows: Section 2 defines the This document is organized as follows: Section 2 defines the
terminology, Section 3 illustrates the required protocol terminology, Section 3 describes how the required functionality can
functionality, Section 4 indicates the required data that has to be be accomplished by combining several already existing standards, and
transmitted within a PIDF-LO and Section 5 shows an example message Section 4 shows an example message exchange. This document concludes
exchange. This document concludes with the security considerations with the security considerations in Section 5 and IANA considerations
in Section 6 and IANA considerations in Section 7. in Section 6.
2. Terminology 2. 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 [1]. document are to be interpreted as described in [1].
This document re-uses a lot of the terminology defined in Section 3 This document re-uses terminology defined in Section 3 of [10].
of [9].
3. Protocol Profile
The usage of in-vehicular emergency calls does not require the usage
of a Location Configuration Protocol since GPS is used. Furthermore,
since the GPS receiver is permanently turned on it can even provide
useful information in cases where the car entered a tunnel.
Consequently, there is no need to discover any Location Information
Server (LIS).
Since the emergency call within the car is either triggered by a
button or, in most cases, automatically thanks to sensors mounted in
the car there is no need to learn a dial string. This document
registers a separate Service URN, namely 'urn:service:ecall', used
specifically for emergency calls that are triggered by vehicles.
This URN comes with two sub-services to indicate how the emergency
call was triggered, namely 'automatic' for cases when the emergency
call was triggered due to a crash automatically without any user
involvement and 'manual' for cases where a driver or a passenger
triggered the emergency call. If the device initiating the emergency
call does not allow to differentiate these two cases then the Service
URN 'urn:service:ecall' is used.
The following list provides information about the sections and
requires of [2] that are relevant to this specification:
Identifying an emergency call: Emergency calls are detected at the
end point, i.e., by the vehicle, and the Service URN
'urn:service:ecall' MUST be implemented by the end point and
recognized by the VSP. The requirements listed in Section 5 of
[2] are therefore irrelevant to this specification, as they deal
with identifying an emergency call based on dial strings.
Location: The encoding of the PIDF-LO [3] is described in Section 4.
In an emergency, the end point adds the available location
information to the initial SIP INVITE emergency call message. In
special cases a location update may be provided, using the
procedure described in requirement ED-38 of Section 6.8 of [2];
all other aspects of Section 6.8 from that document are not
applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4,
6.4, 6.5 and 6.6 of [2] are not applicable to this document. For
location conveyance in SIP [4] MUST be used. Further aspects that
are not relevant for this document are multiple locations (Section
6.9 of [2]), location validation (Section 6.10 of [2]), default
location (Section 6.11 of [2])
LoST: Emergency call routing support, for example utilizing LoST, is
provided by VSP. As such, the description in Section 8 of [2] is
applicable to this document, except for requirement SP-25 and
SP-26 regarding legacy devices.
Signaling of emergency calls: Section 9 of [2] is applicable to this
document with the following exception: ED-60/AN-25 is not
applicable as HELD is not used. Video and real-time text may be
supported by end device in the future, although currently not
envisioned. The corresponding text paragraphs are relevant from
Section 9 of [2] when support is being provided. Additionally,
ED-62 dealing with "SIP signaling requirements for User Agents" is
simplified as follows. The initial SIP signaling method is an
INVITE request with the following setting:
1. The Request URI MUST be the service URN 'urn:service:ecall'
or one of the sub-services.
2. The To header MUST be a service URN
'urn:service:ecall.automatic' or one of the sub-services.
3. The From header MUST be present and SHOULD be the AoR of the
caller.
4. A Via header MUST be present.
5. A Contact header MUST be present which MUST be globally
routable to permit an immediate call-back to the specific
device which placed the emergency call.
6. Other headers MAY be included as per normal SIP behavior.
7. A Supported header MUST be included with the 'geolocation'
option tag [4].
8. The device MUST include location by-value into the call.
9. A normal SDP offer SHOULD be included in the INVITE. If
voice is supported the offer SHOULD include the G.711 codec,
if a voice channel can be established based on the equipment
in the car.
10. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in
the INVITE.
11. The UAC MUST include a "inserted-by=endpoint" header
parameter on all Geolocation headers. This informs
downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI).
12. SIP Caller Preferences [5] MAY be used to signal how the PSAP
should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint
to cause the PSAP to route the call to a call taker who
speaks the requested language. SIP Caller Preferences may
also be used to indicate a need to invoke a relay service for
communication with people with disabilities in the call.
Call backs: The description in Section 10 of [2] is relevant for
this document.
Mid-call behavior: The description in Section 11 of [2] is fully
applicable to this document.
Call termination: The description in Section 12 of [2] is fully
applicable to this document.
Disabling of features: The description in Section 13 of [2] is fully
applicable to this document.
Media: If hardware and software for real-time text, voice, and video
is available in the end device then the requirements regarding
multi-media support described in [2] are applicable.
Testing: The description in Section 15 of [2] is fully applicable to 3. Profile
this document.
4. Data Profile In the context of emergncy calls placed from a vehicle it is assumed
that the car is equipped with a built-in GPS receiver. For this
reason only geodetic location information will be sent within an
emergency call. The following location shapes MUST be implemented:
2d and 3d Point (see Section 5.2.1 of [2]), Circle (see Section 5.2.3
of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate
reference systems (CRS) specified in [2] are also mandatory for this
document. The <direction> element, as defined in [3] which indicates
the direction of travel of the vehicle, is important for dispatch and
hence it MUST be included in the PIDF-LO . The <heading> element
specified in [3] MUST be implemented and MAY be included.
Due to the requirement for a built-in GPS receiver only geodetic This specification also inherits the test call functionality from
location information will be sent within an emergency call. Section 15 of [4].
Furthermore, the number of location shapes is is restricted. Hence,
the following location shapes of [6] MUST be implemented: 2d and 3d
Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]),
and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference
systems (CRS) specified in [6] are also mandatory for this document.
Furthermore, the direction of travel of the vehicle is important for
dispatch and hence it MUST be included in the PIDF-LO. The <heading>
element specified in [7] MUST be supported.
5. Example 4. Example
Figure 1 shows an emergency call placed from a vehicle whereby Figure 1 shows an emergency call placed from a vehicle whereby
location information information is directly attached to the SIP location information information is directly attached to the SIP
INVITE message itself. The call is marked as an emergency call using INVITE message itself. The call is marked as an emergency call using
the 'urn:service:ecall.automatic' service URN and the PSAP of the the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the
VoIP provider determines which PSAP to contact based on the provided VoIP provider determines which PSAP to contact based on the provided
location information. As shown in the figure, this route location information. The emergency call continues towards the PSAP
determination may be based on LoST. Then, the emergency call and in this example it hits the ESRP, as the entry point to the PSAP
continues towards the PSAP and in this example it hits the ESRP, as operators emergency services network. Finally, the emergency call
the entry point to the PSAP operators emergency services network. will be received by a call taker and first reponders will be
Finally, the emergency call will be received by a call taker and dispatched.
first reponders will be dispatched.
+--------+ +--------+
| LoST | | LoST |
| Servers| | Server |
+--------+ +--------+
^ +-------+ ^ +-------+
| | PSAP2 | | | PSAP2 |
| +-------+ | +-------+
v v
+-------+ +------+ +-------+ +-------+ +------+ +-------+
Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+ +-------+ +------+ +-------+
+-------+ +-------+
| PSAP3 | | PSAP3 |
+-------+ +-------+
Figure 1: Example of In-Vehicular Emergency Call Message Flow Figure 1: Example of In-Vehicular Emergency Call Message Flow
The following example, in Figure 2, shows the SIP INVITE and location The example, shown in Figure 2, illustrates a SIP INVITE and location
information encoded in a PIDF-LO that is being conveyed in such an information encoded in a PIDF-LO that is being conveyed in such an
emergency call. emergency call.
INVITE urn:service:ecall.automatic SIP/2.0 INVITE urn:service:sos.ecall.automatic SIP/2.0
To: <sip:intermediate-psap@example.com> 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 Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@example.com> Geolocation: <cid:target123@example.com>
Geolocation-Routing: no Geolocation-Routing: no
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
skipping to change at page 10, line 16 skipping to change at page 7, line 16
Content-Type: application/sdp Content-Type: application/sdp
...Session Description Protocol (SDP) goes here ...Session Description Protocol (SDP) goes here
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic" xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="sip:+13145551111@example.com"> entity="sip:+13145551111@example.com">
<dm:device id="123"> <dm:device id="123">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos> <gml:pos>-34.407 150.883</gml:pos>
</gml:Point> </gml:Point>
<dyn:Dynamic> <dyn:Dynamic>
<dyn:heading>278</dyn:heading> <dyn:heading>278</dyn:heading>
<dyn:direction><dyn:direction>
</dyn:Dynamic> </dyn:Dynamic>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>gps</method> <method>gps</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2012-04-5T10:18:29Z</timestamp> <timestamp>2012-04-5T10:18:29Z</timestamp>
<dm:deviceID>vehicle-number</dm:deviceID> <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call
6. Security Considerations 5. Security Considerations
This document does not raise security considerations beyond those This document does not raise security considerations beyond those
described in [10]. As with emergency service systems with end host described in [11]. As with emergency service systems with end host
provided location information there is the possibility that that provided location information there is the possibility that that
location is incorrect, either intentially (in case of an a denial of location is incorrect, either intentially (in case of an a denial of
service attack against the emergency services infrastructure) or due service attack against the emergency services infrastructure) or due
to a malfunctioning devices. The reader is referred to [11] for a to a malfunctioning devices. The reader is referred to [12] for a
discussion of some of these vulnerabilities. discussion of some of these vulnerabilities.
7. IANA Considerations 6. IANA Considerations
IANA is requested to register the URN 'urn:service:ecall' under the IANA is requested to register the URN 'urn:service:sos.ecall' under
sub-services 'sos' registry defined in Section 4.2 of [8]. the sub-services 'sos' registry defined in Section 4.2 of [5].
This service identifier reaches a public safety answering point This service identifier reaches a public safety answering point
(PSAP), which in turn dispatches aid appropriate to the emergency (PSAP), which in turn dispatches aid appropriate to the emergency
related to accidents of vehicles. Two sub-services are registered as related to accidents of vehicles. Two sub-services are registered as
well, namely well, namely
urn:service:ecall.manual This service URN indicates that an eCall urn:service:sos.ecall.manual
had been triggered based on the manual interaction of the driver
or a passenger.
urn:service:ecall.automatic This service URN indicates that an eCall This service URN indicates that an eCall had been triggered based
had been triggered automatically, for example, due to a crash. No on the manual interaction of the driver or a passenger.
human involvement was detected.
8. Contributors urn:service:sos.ecall.automatic
This service URN indicates that an eCall had been triggered
automatically, for example, due to a crash. No human involvement
was detected.
7. Contributors
We would like to thank Ulrich Dietz for his help with earlier We would like to thank Ulrich Dietz for his help with earlier
versions of the document. versions of the document.
9. Acknowledgements 8. Acknowledgements
We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri,
Hellstroem for their feedback. and Gunnar Hellstroem for their feedback.
10. References 9. References
10.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosen, B. and J. Polk, "Best Current Practice for [2] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[3] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson,
"Dynamic Extensions to the Presence Information Data Format
Location Object (PIDF-LO)", RFC 5962, September 2010.
[4] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in progress), draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011. September 2011.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
[6] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy,
"Additional Data related to an Emergency Call",
draft-ietf-ecrit-additional-data-06 (work in progress),
February 2013.
[7] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[4] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for [8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", RFC 6442, December 2011. the Session Initiation Protocol", RFC 6442, December 2011.
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 9.2. Informative references
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson,
"Dynamic Extensions to the Presence Information Data Format
Location Object (PIDF-LO)", RFC 5962, September 2010.
[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
10.2. Informative references
[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [10] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012, Context Resolution with Internet Technologies", RFC 5012,
January 2008. January 2008.
[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, [11] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking "Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008. and Mapping", RFC 5069, January 2008.
[11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy [12] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy
Location Information", draft-ietf-ecrit-trustworthy-location-03 Location", draft-ietf-ecrit-trustworthy-location-04 (work in
(work in progress), April 2012. progress), October 2012.
[13] CEN, "Intelligent transport systems - eSafety - eCall minimum
set of data (MSD), EN 15722", June 2011.
[14] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals", RFC 4481, July 2006.
Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD)
[13] outlines a number of data elements that are transmitted in an
emergency call triggered by a vehicle. This list compares the eCall
minimum set of data with the functionality provided in this document.
Version of the MSD Format
Message Identifier: Every SIP INVITE message contains a Call-ID,
which is a globally unique identifier for this call.
Vehicle Type Encoding: [Editor's Note: Description to be added.].
Test Call Indication A service URN starting with "test." indicates a
request for an automated test. For example,
"urn:service:test.sos.ecall.automatic" indicates such a test
feature. This functionality is defined in [4].
Automatic Activation Indication: This document registers new service
URNs, which allow the differentiation between manually and
automatically triggered emergency calls. The two service URNs
are: urn:service:sos.ecall.automatic and
urn:service:sos.ecall.manual
Vehicle Identification: The PIDF data structure contains a deviceID
field that holds the Vehicle Identification Number (VIN).
Vehicle Propulsion Storage type: These parameters identify the type
of vehicle energy storage(s) present. [Editor's Note:
Description to be added.]
Timestamp of Incident Event: The PIDF-LO element contains the
timestamp when the PIDF-LO was created, which is at the time of
the incident.
Vehicle Location: The location of the vehicle is conveyed using the
PIDF location objection, as described in Section 3.
Vehicle Direction: The direction of the vehicle is part of location
information, as described in Section 3.
Recent Vehicle Location: With this optional functionality multiple
location objects may be required to be transported simultaneously.
This can be achieved using <timed-presence>, defined in RFC 4481
[14].
Number of Passengers: Minimum known number of fastened seatbelts.
[Editor's Note: Description to be added.]
Additional Data: [6] provides the ability to carry additional data
for an emergency call.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
US US
Phone: Phone:
 End of changes. 39 change blocks. 
209 lines changed or deleted 156 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/