Internet DRAFT - draft-rosen-ecrit-ecall

draft-rosen-ecrit-ecall






ECRIT                                                           B. Rosen
Internet-Draft                                             NeuStar, Inc.
Intended status: Informational                             H. Tschofenig
Expires: January 13, 2014                         Nokia Siemens Networks
                                                              R. Gellens
                                                   QUALCOMM Incorporated
                                                           July 14, 2013

           Internet Protocol-based In-Vehicle Emergency Call
                     draft-rosen-ecrit-ecall-10.txt

Abstract

   This document describes how to re-use the emergency services
   mechanisms specified for the Session Initiation Protocol (SIP) to
   accomplishing emergency calling support in vehicles.  Profiling and
   simplifications are possible due to the nature of the functionality
   that is going to be provided in vehicles with the usage of Global
   Positioning System (GPS).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 13, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

Rosen, Tschofenig & GellExpires January 13, 2014                [Page 1]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Overview of Current Deployment Models  . . . . . . . . . .  3
     1.2.  Migration to IP-based Models . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Profile  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Service URN Registration . . . . . . . . . . . . . . . . .  9
     6.2.  MIME Content-type Registration for
           'application/emergencyCall.VEDS+xml' . . . . . . . . . . .  9
     6.3.  Registration of the 'VEDS' entry in the Emergency Call
           Additional Data registry . . . . . . . . . . . . . . . . . 10
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 11
   Appendix A. Matching Functionality with eCall Minimum Set of Data
               (MSD)  . . . . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

1.  Introduction

   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.

   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
   Points (PSAPs), 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 general term for such systems is Automatic Crash Notification
   (ACN).  ACN systems transmit some amount of data specific to the
   incident, referred to generally as "crash data."  While different
   systems transmit different amounts of crash data, standardized
   formats, structures, and mechanisms are needed to provide
   interoperability among systems and PSAPs.

   This document describes how existing IETF mechanisms are used to
   provide the realization of next-generation ACN in general, including
   European eCall.

   This document registers the 'application/emergencyCall.VEDS+xml' MIME
   content-type, and registers the 'VEDS' entry in the Emergency Call
   Additional Data registry.




Rosen, Tschofenig & GellExpires January 13, 2014                [Page 2]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   The Vehicle Emergency Data Set (VEDS) is an XML structure defined by
   the Association of Public-Safety Communications Officials (APCO) and
   the National Emergency Number Association (NENA). The 'application/
   emergencyCall.VEDS+xml' MIME content-type is used to identify it.
   The 'VEDS' entry in the Emergency Call Additional Data registry is
   used to construct a 'purpose' parameter value for conveying VEDS data
   in a Call-Info header.

   Circuit-switched eCall systems transmit crash data as a defined set,
   the Minimum Set of Data (MSD) [eCall-MSD].The MSD for circuit-
   switched eCall is a binary format defined by CEN, the European
   Committee for Standardization.  It is expected that CEN will choose
   to define the XML schema for the eCall MSD for use in next-generation
   systems.  Once this done, a MIME content-type (e.g., 'application/
   emergencyCall.eCall.MSD+xml') and Emergency Call Additional Data
   entry (e.g., 'eCall.MSD') need to be registered for the MSD. Note
   that Appendix Appendix A explains how the functionality available in
   IETF specifications maps to the functionality required for the MSD of
   the mobile circuit switched voice solution.

   CEN and/or other entities may define additional sets of data in the
   same manor: a standardized format, such as XML, is defined, and a
   MIME content-type and Emergency Call Additional Data entry
   registered.

   An In-Vehicle System (IVS) transmits crash data by encoding it in one
   of the standardized and registered formats (such as VEDS or
   eCall.MSD) and attaching it to an INVITE as a data block.  The block
   is identified by its MIME content-type, and pointed to by a CID URL
   in a Call-Info header with a 'purpose' parameter value corresponding
   to the block.

   The mechanisms described here can be used to deploy ACN systems in
   general including eCall by providing for emergency calls that are
   identifiable as ACN calls or specifically eCall calls and that carry
   one or more defined crash data objects.

1.1.  Overview of Current Deployment Models

   Current (circuit-switched or legacy) systems for placing emergency
   calls from vehicles, including automatic crash notification system,
   generally use one of three architectural models: Telematics Service
   Provider (TSP), direct, and paired handset.  These three models are
   illustrated below.

   In the TSP model the IVS transmits crash data to the TSP using
   proprietary means.  The TSP operator bridges in the PSAP and
   communicates location, crash, and other data to the call taker
   verbally (there is a three-way voice call between the vehicle, the
   TSP, and the PSAP).




Rosen, Tschofenig & GellExpires January 13, 2014                [Page 3]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


      ///----\\\  proprietary  +------+    911 trunk      +------+
     ||| IVS |||-------------->+ TSP  +------------------>+ PSAP |
      \\\----///  crash data   +------+                   +------+
   

   In the paired model the IVS uses a Bluetooth link to a previously-
   paired handset to establish an emergency call with the PSAP and then
   communicates location data to the PSAP via text-to-speech; crash data
   is not conveyed.

                    ++
      ///----\\\    ||    911 voice call via handset      +------+
     ||| IVS |||--->|+----------------------------------->+ PSAP |
      \\\----///    ++   location via text-to-speech      +------+
   

   In the direct model the IVS communicates crash data to the PSAP via
   the eCall in-band modem (in the voice call).

      ///----\\\      112/911 voice call via IVS          +------+
     ||| IVS  |||---------------------------------------->+ PSAP |
      \\\----///   crash data via eCall in-band modem     +------+
   

1.2.  Migration to IP-based Models

   The migration to next-generation (all-IP) would then look like as
   follows.

   In the TSP model The IVS transmits crash data to the TSP using either
   proprietary or standard means.  The TSP bridges in the PSAP and
   transmits crash and other data to the PSAP using IETF specifications.
   There is a three-way call between the vehicle, the TSP, and the PSAP.

               proprietary
   ///----\\\  or standard  +------+     standard       +------+
      IVS     ------------->+ TSP  +------------------->+ PSAP |
   \\\----///  crash data   +------+ crash + other data +------+

   In the paired model, the IVS uses a Bluetooth link to a previously-
   paired handset to establish an emergency call with the PSAP; it is
   not clear what facilities are or will be available for transmitting
   crash data.

                 ++
   ///----\\\    ||  IP-based Emergency Call           +------+
      IVS    --->|+----------------------------------->+ PSAP |
   \\\----///    ++                                    +------+

   In the direct model the IVS communicates crash data to PSAP using
   Internet protocols.



Rosen, Tschofenig & GellExpires January 13, 2014                [Page 4]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   ///----\\\          NG1-1-2/NG9-1-1 call            +------+
      IVS    ----------------------------------------->+ PSAP |
   \\\----///               crash data                 +------+

   This document is focused on the interface to the PSAP, that is, how
   an emergency call (including location and crash data) is setup and
   data is transmitted to the PSAP using existing IETF specifications.
   The goal is to re-use existing specifications rather than to invent
   new.  For the direct model (such as the European eCall), this is the
   end-to-end description.  For the TSP model, this describes the right-
   hand side, leaving the left-hand side up to the entities involved
   (e.g., IVS and TSP vendors) who are then free to use the same
   mechanism as for the right-hand side or not.

2.  Terminology

   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 [RFC2119].

   This document re-uses terminology defined in Section 3 of [RFC5012].

   Additionally, we use the following abbreviations:

   IVS: In-Vehicle System

   TSP: Telematics Service Provider

   MSD: Minimum Set of Data

   VEDS: Vehicle Emergency Data Set

   NENA: National Emergency Number Association

   APCO: Association of Public-Safety Communications Officials

   CEN: European Committee for Standardization

   ESInet: Emergency Services IP network

3.  Profile













Rosen, Tschofenig & GellExpires January 13, 2014                [Page 5]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   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 [RFC5491]), Circle (see Section
   5.2.3 of [RFC5491]), and Ellipsoid (see Section 5.2.7 of [RFC5491]).
   The coordinate reference systems (CRS) specified in [RFC5491] are
   also mandatory for this document.  The <direction> element, as
   defined in [RFC5962] 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 [RFC5962] MUST be
   implemented and MAY be included.

   This specification also inherits the ability to utilize test call
   functionality from Section 15 of [RFC6881].

4.  Example

   Figure 7 shows an emergency call placed from a vehicle whereby
   location information information is directly attached to the SIP
   INVITE message itself.  The call uses the request URI
   'urn:service:sos.ecall.automatic' service URN and is recognized as an
   emergency call because the request URI starts with 'urn:service:sos'.
   The VoIP provider routes the call to an Emergency services IP Network
   (ESInet), as for any emergency call.  The ESInet routes the call to
   an appropriate PSAP using location information and the fact that that
   it is an eCall carrying crash data.  (In deployments where there is
   no ESInet, the VoIP provider may route directly to an appropriate
   PSAP.) The emergency call continues towards the PSAP and in this
   example it hits the ESRP, as the entry point to the ESInet.  Finally,
   the emergency call will be received by a call taker and first
   reponders will be dispatched.

                  +--------+
                  | LoST   |
                  | Server | +-----------------------------------------+
                  +--------+ |                                         |
                      ^      |                  +-------+              |
                      |      |                  | PSAP2 |              |
                      |      |                  +-------+              |
                      v      |                                         |
                  +-------+  |  +------+     +-------+                 |
   Vehicle ------>| Proxy |--+->| ESRP |---->| PSAP1 |-----> Call-Taker|
                  +-------+  |  +------+     +-------+                 |
                             |                                         |
                             |                  +-------+              |
                             |                  | PSAP3 |              |
                             |                  +-------+              |
                             |                                         |
                             |                                         |




Rosen, Tschofenig & GellExpires January 13, 2014                [Page 6]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013

                             |                                         |
                             |                ESInet                   |
                             +-----------------------------------------+

   The example, shown in Figure 8, illustrates a SIP emergency call
   eCall INVITE that is being conveyed with location information encoded
   in a PIDF-LO and VEDS data.
















































Rosen, Tschofenig & GellExpires January 13, 2014                [Page 7]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


      INVITE urn:service:sos.ecall.automatic SIP/2.0
      To: urn:service:sos.ecall.automatic
      From: <sip:+13145551111@example.com>;tag=9fxced76sl
      Call-ID: 3848276298220188511@atlanta.example.com
      Geolocation: <cid:target123@example.com>
      Geolocation-Routing: no
      Call-Info: cid:1234567890@atlanta.example.com;
                 purpose=emergencyCallData.VEDS
      Accept: application/sdp, application/pidf+xml
      CSeq: 31862 INVITE
      Content-Type: multipart/mixed; boundary=boundary1
      Content-Length: ...
   
      --boundary1
   
      Content-Type: application/sdp
   
      ...Session Description Protocol (SDP) goes here
   
      --boundary1
   
   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
   <presence
          xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:gs="http://www.opengis.net/pidflo/1.0"
          entity="sip:+13145551111@example.com">
          <dm:device id="123">
              <gp:geopriv>
                  <gp:location-info>
                      <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                         <gml:pos>-34.407 150.883</gml:pos>
                      </gml:Point>
                       <dyn:Dynamic>
                          <dyn:heading>278</dyn:heading>
                          <dyn:direction><dyn:direction>
                       </dyn:Dynamic>
                  </gp:location-info>
                  <gp:usage-rules/>
                  <method>gps</method>
              </gp:geopriv>
              <timestamp>2012-04-5T10:18:29Z</timestamp>
              <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
          </dm:device>
   </presence>
   
       --boundary1
   

Rosen, Tschofenig & GellExpires January 13, 2014                [Page 8]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013

   Content-Type: application/emergencyCall.VEDS+xml
   Content-ID: 1234567890@atlanta.example.com
   
   ...eCall VEDS data object goes here
   
       --boundary1--

5.  Security Considerations

   This document does not raise security considerations beyond those
   described in [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 [I-D.ietf-
   ecrit-trustworthy-location] for a discussion of some of these
   vulnerabilities.

6.  IANA Considerations

6.1.  Service URN Registration

   IANA is requested to register the URN 'urn:service:sos.ecall' under
   the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].

   This service identifier reaches a public safety answering point
   (PSAP), which in turn dispatches aid appropriate to the emergency
   related to accidents of vehicles.  Two sub-services are registered as
   well, namely

   urn:service:sos.ecall.manual 

      This service URN indicates that an eCall had been triggered based
      on the manual interaction of the driver or a passenger.

   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.

6.2.  MIME Content-type Registration for 'application/
      emergencyCall.VEDS+xml'

   This specification requests the registration of a new MIME type
   according to the procedures of RFC 4288 [RFC4288] and guidelines in
   RFC 3023 [RFC3023].

      MIME media type name:  application

      MIME subtype name:  emergencyCall.VEDS+xml

      Mandatory parameters:  none


Rosen, Tschofenig & GellExpires January 13, 2014                [Page 9]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


      Optional parameters:  charset

      Indicates the character encoding of enclosed XML.

      Encoding considerations: Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See Section
      3.2 of RFC 3023 [RFC3023].

      Security considerations: This content type is designed to carry
      vehicle crash data during an emergency call.  This data may
      contains personal information including vehicle VIN, location,
      direction, etc.  appropriate precautions need to be taken to limit
      unauthorized access, inappropriate disclosure to third parties,
      and eavesdropping of this information.  Please refer to Section 7
      and Section 8 of [I-D.ietf-ecrit-additional-data] for more
      information.

      Interoperability considerations:  None

      Published specification: [TBD: This specification]

      Applications which use this media type: Emergency Services

      Additional information: None

      Magic Number:  None

      File Extension:  .xml

      Macintosh file type code:  'TEXT'

      Person and email address for further information: Hannes
      Tschofenig, Hannes.Tschofenig@gmx.net

      Intended usage:  LIMITED USE

      Author: This specification is a work item of the IETF ECRIT
      working group, with mailing list address <ecrit@ietf.org>.

      Change controller: The IESG <ietf@ietf.org>

6.3.  Registration of the 'VEDS' entry in the Emergency Call Additional
      Data registry

   This specification requests IANA to add the 'VEDS' entry to the
   Emergency Call Additional Data registry, with a reference to this
   document.  The Emergency Call Additional Data registry has been
   established by [I-D.ietf-ecrit-additional-data].

7.  Contributors

   We would like to thank Ulrich Dietz for his help with earlier
   versions of the document.

Rosen, Tschofenig & GellExpires January 13, 2014               [Page 10]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


8.  Acknowledgements

   We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri,
   and Gunnar Hellstroem for their feedback.

9.  References

9.1.  Normative References

   [10]       Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", RFC 5031,
              January 2008.

   [1]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2]        Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [3]        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.

   [4]        Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in Support of Emergency Calling",
              BCP 181, RFC 6881, March 2013.

   [5]        Polk, J., Rosen, B. and J. Peterson, "Location Conveyance
              for the Session Initiation Protocol", RFC 6442, December
              2011.

   [6]        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.

   [7]        Murata, M., St.  Laurent, S. and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [8]        Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, December 2005.

   [9]        Rosen, B., Tschofenig, H., Marshall, R. and R. Randy,
              "Additional Data related to an Emergency Call", Internet-
              Draft draft-ietf-ecrit-additional-data-09, May 2013.

9.2.  Informative references

   [1]        Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              RFC 5012, January 2008.


Rosen, Tschofenig & GellExpires January 13, 2014               [Page 11]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   [2]        Taylor, T., Tschofenig, H., Schulzrinne, H. and M.
              Shanmugam, "Security Threats and Requirements for
              Emergency Call Marking and Mapping", RFC 5069, January
              2008.

   [3]        Tschofenig, H., Schulzrinne, H. and B. Aboba, "Trustworthy
              Location", Internet-Draft draft-ietf-ecrit-trustworthy-
              location-05, March 2013.

   [4]        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.

   [5]        CEN, , "Intelligent transport systems - eSafety - eCall
              minimum set of data (MSD), EN 15722", June 2011.

Appendix A.  Matching Functionality with eCall Minimum Set of Data (MSD)

   [eCall-MSD] outlines a number of data elements that are transmitted
   in an emergency call triggered by a vehicle.  Note that the work on
   eCall for mobile circuit switched voice is constrained in a number of
   ways since legacy eCall uses an inband voice modem for backwards
   compatibility with the already deployed cellular infrastructure to
   transmit data from a vehicle to a PSAP. Since the functionality in
   this document is based on the Session Initiation Protocol (SIP) these
   limitations do not exist.  As such, it is not useful to transmit the
   MSD inband in the voice channel but to rather use the SIP mechanisms
   standardized for emergency call handling.  Any voice, video, or real-
   text communication will be negotiated using the Session Description
   Protocol (SDP), as shown in Figure 8, and the actual media stream
   will then take place in RTP packets.  For transmitting location
   information an XML-based data structure had been defined, the so-
   called Presence Information Data Format Location Object (PIDF-LO).

   The following list compares the eCall minimum set of data with the
   functionality provided in this document.

   Version of the MSD Format: Conveying information in a SIP-based
      emergency call is accomplished by using XML payloads and XML
      provides namespace declarations that allow a receipient of that
      information to distinguish different versions and additional
      extensions.  For example, if additional data about a vehicle is
      defined and can be transmitted by vehicle then a respective
      extension can be defined for use inside a previously-defined XML
      structure.  One or more top-level structures can be transmitted
      using the mechanism defined in [I-D.ietf-ecrit-additional-data].
      Selecting the appropriate extension point depends on the type of
      extension envisioned.

   Message Identifier: Every SIP INVITE message contains a Call-ID,
      which is a globally unique identifier for this call.


Rosen, Tschofenig & GellExpires January 13, 2014               [Page 12]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   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 [RFC6881].

   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).

   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 object, 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
      [RFC4481].

   Additional Data: [I-D.ietf-ecrit-additional-data] provides the
      ability to carry additional data for an emergency call.

   While most fields have an equivalent already in the corresponding SIP
   emergency signaling payloads there are currently no fields defined in
   [I-D.ietf-ecrit-additional-data] that allow information about the
   "Vehicle Type Encoding", "Number of Passengers", and "Vehicle
   Propulsion Storage type" to be conveyed.  Extensions for those fields
   will have to be defined.

Authors' Addresses

   Brian Rosen
   NeuStar, Inc.
   470 Conrad Dr
   Mars, PA  16046
   US
   
   Email: br@brianrosen.net






Rosen, Tschofenig & GellExpires January 13, 2014               [Page 13]

Internet-Draft     IP-based In-Vehicle Emergency Call          July 2013


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo, 02600
   Finland
   
   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


   Randall Gellens
   QUALCOMM Incorporated
   5775 Morehouse Drive
   San Diego, 92651
   US
   
   Email: rg+ietf@qualcomm.com



































Rosen, Tschofenig & GellExpires January 13, 2014               [Page 14]