One document matched: draft-rosen-ecrit-ecall-03.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5012 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml">
<!ENTITY I-D.ietf-ecrit-phonebcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
<!ENTITY I-D.ietf-sipcore-location-conveyance PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipcore-location-conveyance.xml">
<!ENTITY I-D.singh-geopriv-pidf-lo-dynamic PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.singh-geopriv-pidf-lo-dynamic.xml">
<!ENTITY RFC5491 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.xml">
<!ENTITY RFC3841 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3841.xml">
<!ENTITY RFC5069 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5069.xml">
<!ENTITY RFC5031 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY I-D.tschofenig-ecrit-trustworthy-location PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-ecrit-trustworthy-location.xml">
]>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="info" ipr="trust200902" docName="draft-rosen-ecrit-ecall-03.txt">
<front>
<title abbrev="In-Vehicle Emergency Call">Best Current Practice for IP-based In-Vehicle
Emergency Calls</title>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization>NeuStar, Inc. </organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region> PA </region>
<code>16046 </code>
<country>US </country>
</postal>
<phone> </phone>
<email>br@brianrosen.net
</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="U." surname="Dietz" fullname="Ulrich Dietz">
<organization>Vodafone</organization>
<address>
<postal>
<street>Chiemgaustrasse 116</street>
<city>Munich</city>
<code>81549</code>
<country>Germany</country>
</postal>
<email>Ulrich.Dietz@vodafone.com</email>
</address>
</author>
<date year="2010"/>
<area>Real-Time Applications and Infrastructure</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes how to use a subset of the IETF-based emergency call framework for
accomplishing emergency calling support in vehicles. Simplifications are possible due to the
nature of the functionality that is going to be provided in vehicles with the usage of GPS.
Additionally, further profiling needs to be done regarding the encoding of location
information.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Emergency calls made from vehicles can assist with the objective of significantly reducing
road deaths and injuries. Unfortunately, drivers often have a poor location-awareness,
especially on urban 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 trapped.</t>
<t>In Europe the European Commission has launched the eCall initiative that may best be
described as a user initiated or automatically triggered system to provide notifications to
Public Safety Answering Point's (PSAP), by means of cellular communications, that a vehicle
has crashed, and to provide geodetic location information and where possible a voice channel
to the PSAP. The current specifications being developed to offer the eCall solution are
defined to work with circuit switched telephony. This document details how the same
functionality can be accomplished using IP-based mechanisms. Since cellular systems are
being enhanced with IP-based infrastructure this document complements the ambiguous goal to
provide widespread availability of in-vehicular emergency services solutions.</t>
<t>This document is organized as follows: <xref target="terminology"/> defines the
terminology, <xref target="protocol-profile"/> illustrates the required protocol
functionality, <xref target="data-profile"/> indicates the required data that has to be
transmitted within a PIDF-LO and <xref target="example"/> shows an example message exchange.
This document concludes with the security considerations in <xref target="security"/> and
IANA considerations in <xref target="iana"/>.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/>. </t>
<t>This document re-uses a lot of the terminology defined in Section 3 of <xref
target="RFC5012"/>.</t>
</section>
<section anchor="protocol-profile" title="Protocol Profile">
<t>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 LIS.</t>
<t>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.</t>
<t>The following list provides information about the sections and requires of <xref
target="I-D.ietf-ecrit-phonebcp"/> that are relevant to this specification: <list
style="hanging">
<t hangText="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
<xref target="I-D.ietf-ecrit-phonebcp"/> are therefore irrelevant to this
specification, as they deal with identifying an emergency call based on dial strings. </t>
<t hangText="Location:">The encoding of the PIDF-LO <xref target="RFC4119"/> is described
in <xref target="data-profile"/>. 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 <xref target="I-D.ietf-ecrit-phonebcp"/>; 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 <xref target="I-D.ietf-ecrit-phonebcp"/> are not applicable
to this document. For location conveyance in SIP <xref
target="I-D.ietf-sipcore-location-conveyance"/> MUST be used. Further aspects that are not
relevant for this document are multiple locations (Section 6.9 of <xref
target="I-D.ietf-ecrit-phonebcp"/>), location validation (Section 6.10 of <xref
target="I-D.ietf-ecrit-phonebcp"/>), default location (Section 6.11 of <xref
target="I-D.ietf-ecrit-phonebcp"/>) </t>
<t hangText="LoST:">Emergency call routing support, for example utilizing LoST, is
provided by VSP. As such, the description in Section 8 of <xref
target="I-D.ietf-ecrit-phonebcp"/> is applicable to this document, except for
requirement SP-25 and SP-26 regarding legacy devices.</t>
<t hangText="Signaling of emergency calls:">Section 9 of <xref
target="I-D.ietf-ecrit-phonebcp"/> 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 <xref
target="I-D.ietf-ecrit-phonebcp"/> 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: <list style="numbers">
<t>The Request URI MUST be the service URN 'urn:service:ecall'. </t>
<t>The To header MUST be a service URN 'urn:service:ecall'. </t>
<t> The From header MUST be present and SHOULD be the AoR of the caller.</t>
<t>A Via header MUST be present.</t>
<t>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.</t>
<t>Other headers MAY be included as per normal SIP behavior. </t>
<t>A Supported header MUST be included with the 'geolocation' option tag <xref
target="I-D.ietf-sipcore-location-conveyance"/>. </t>
<t>The device MUST include location by-value into the call. </t>
<t>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.</t>
<t>If the device includes location-by-value, the UA MUST support multipart message
bodies, since SDP will likely be also in the INVITE.</t>
<t>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).</t>
<t>SIP Caller Preferences <xref target="RFC3841"/> 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. </t>
</list>
</t>
<t hangText="Call backs:"> The description in Section 10 of <xref
target="I-D.ietf-ecrit-phonebcp"/> is relevant for this document. </t>
<t hangText="Mid-call behavior:"> The description in Section 11 of <xref
target="I-D.ietf-ecrit-phonebcp"/> is fully applicable to this document. </t>
<t hangText="Call termination:">The description in Section 12 of <xref
target="I-D.ietf-ecrit-phonebcp"/> is fully applicable to this document. </t>
<t hangText="Disabling of features:"> The description in Section 13 of <xref
target="I-D.ietf-ecrit-phonebcp"/> is fully applicable to this document. </t>
<t hangText="Media:">Real-time text and video may be supported in devices some time in the future. If voice
calls are supported then the description in Section 14 is applicable to this document.</t>
<t hangText="Testing:"> The description in Section 15 of <xref
target="I-D.ietf-ecrit-phonebcp"/> is fully applicable to this document. </t>
</list>
</t>
</section>
<section anchor="data-profile" title="Data Profile">
<t> Due to the requirement for a built-in GPS receiver only geodetic location information will
be sent within an emergency call. Furthermore, the number of location shapes is is
restricted. Hence, the following location shapes of <xref
target="RFC5491"/> MUST be implemented: 2d and 3d Point (see
Section 5.2.1 of <xref target="RFC5491"/>), Circle (see Section
5.2.3 of <xref target="RFC5491"/>), and Ellipsoid (see Section
5.2.7 of <xref target="RFC5491"/>). The coordinate reference
systems (CRS) specified in <xref target="RFC5491"/> 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
<bearing> element specified in <xref
target="I-D.singh-geopriv-pidf-lo-dynamic"/> MUST be supported. </t>
</section>
<section anchor="example" title="Example">
<t>
<xref target="fig1"/> shows an emergency call placed from a vehicle whereby location
information information is directly attached to the SIP INVITE message itself. The call is
marked as an emergency call using the 'urn:service:ecall' service URN and the PSAP of the
VoIP provider determines which PSAP to contact based on the provided location information.
As shown in the figure, this route determination may be based on LoST. Then, the emergency
call continues towards the PSAP and in this example it hits the ESRP, as the entry point to
the PSAP operators emergency services network. Finally, the emergency call will be received
by a call taker and first reponders will be dispatched. </t>
<t>
<figure anchor="fig1" title="Example of In-Vehicular Emergency Call Message Flow">
<artwork><![CDATA[
+--------+
| LoST |
| Servers|
+--------+
^ +-------+
| | PSAP2 |
| +-------+
v
+-------+ +------+ +-------+
Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
]]></artwork>
</figure>
</t>
<t> The following example, in <xref target="fig2"/>, shows location information encoded in a
PIDF-LO that is being conveyed in such an emergency call.</t>
<t>
<figure anchor="fig2" title="Example of In-Vehicular Emergency Call Message Flow">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:vehicle-identification@example.com">
<device id="123">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
<gml:bearing>
<gml:DirectionVector>
<gml:vector> 270.0 -60.0</gml:vector>
</gml:DirectionVector>
</gml:bearing>
</gp:location-info>
<gp:usage-rules/>
<method>GPS</method>
</gp:geopriv>
</device>
</presence>
]]></artwork>
</figure>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document does not raise security considerations beyond those described in <xref
target="RFC5069"/>. As with emergency service systems with end host provided location
information there is the possibility that that location is incorrect, either intentially (in
case of an a denial of service attack against the emergency services infrastructure) or due
to a malfunctioning devices. The reader is referred to <xref
target="I-D.tschofenig-ecrit-trustworthy-location"/> for a discussion of some of these
vulnerabilities. </t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to register the URN 'urn:service:ecall' under the sub-services 'sos'
registry defined in Section 4.2 of <xref target="RFC5031"/>.</t>
<t>
<list style="hanging">
<t hangText="urn:service:ecall">This service identifier reaches a public safety answering
point (PSAP), which in turn dispatches aid appropriate to the emergency related to
accidents of vehicles. </t>
</list>
</t>
</section>
<section title="Acknowledgements">
<t>We would like to thank Michael Montag for his feedback.</t>
</section>
<section title="Open Issues">
<t>While working on this document a few aspects where discovered that require further
discussion:</t>
<t><list style="symbols">
<t>Today's work on the eCall system does not necessarily require a voice call to be
established; a voice call may be established whenever possible by the functionality
offered by the device. From a protocol mechanims, however, the design for establishing
an emergency call including voice and without voice support are somewhat different.
Further discussion on the design aspects are needed to align this aspect. </t>
<t>This document currently defines a new service URN to differentiate it from ordinary
calls as in-vehicular emergency calls are, in some countries, routed to different PSAPs
than regular emergency calls. More thoughts are needed to determine whether this is the
best approach. </t>
<t>The current version of the document assumes the usage of LoST at the VSP to perform
call routing of the in-vehicular emergency call. This is useful when there are no dial
strings need to be learned nor any other service URNs need to be discovered. Further
discussion is needed whether additional service URNs might be made available to the
vehicle, for example to request roadside assistance or similar services. In that case
the option might be provided to run LoST at the end host as well as on the VSP.</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC4119;
&RFC5491; &I-D.ietf-ecrit-phonebcp;
&I-D.ietf-sipcore-location-conveyance; &RFC3841; &I-D.singh-geopriv-pidf-lo-dynamic;
&RFC5031; </references>
<references title="Informative references"> &RFC5012; &RFC5069;
&I-D.tschofenig-ecrit-trustworthy-location; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 00:13:32 |