doc: Add RFC documents

1 files changed, 2243 insertions, 0 deletions

diff --git a/doc/rfc/rfc8148.txt b/doc/rfc/rfc8148.txt
new file mode 100644
index 0000000..3745b7a
--- /dev/null
+++ b/doc/rfc/rfc8148.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Gellens
+Request for Comments: 8148                    Core Technology Consulting
+Category: Standards Track                                       B. Rosen
+ISSN: 2070-1721                                            NeuStar, Inc.
+                                                           H. Tschofenig
+                                                              Individual
+                                                                May 2017
+
+
+           Next-Generation Vehicle-Initiated Emergency Calls
+
+Abstract
+
+   This document describes how to use IP-based emergency services
+   mechanisms to support the next generation of emergency calls placed
+   by vehicles (automatically in the event of a crash or serious
+   incident, or manually invoked by a vehicle occupant) and conveying
+   vehicle, sensor, and location data related to the crash or incident.
+   Such calls are often referred to as "Automatic Crash Notification"
+   (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
+   case of manual trigger.  The "Advanced" qualifier refers to the
+   ability to carry a richer set of data.
+
+   This document also registers a MIME media type and Emergency Call
+   Data Type for the vehicle, sensor, and location data (often referred
+   to as "crash data" even though there is not necessarily a crash) and
+   an INFO package to enable carrying this and related data in SIP INFO
+   requests.  An external specification for the data format, contents,
+   and structure is referenced in this document.
+
+   This document reuses the technical aspects of next-generation Pan-
+   European eCall (a mandated and standardized system for emergency
+   calls by in-vehicle systems (IVSs) within Europe and other regions).
+   However, this document specifies use of a different set of vehicle
+   (crash) data, specifically, the Vehicle Emergency Data Set (VEDS)
+   rather than the eCall Minimum Set of Data (MSD).  This document is an
+   extension of the IETF eCall document, with the primary differences
+   being that this document makes the MSD data set optional and VEDS
+   mandatory, and it adds attribute values to the metadata/control
+   object to permit greater functionality.  This document registers a
+   new INFO package (identical to that registered for eCall but with the
+   addition of the VEDS MIME type).  This document also describes legacy
+   (circuit-switched) ACN systems and their migration to next-generation
+   emergency calling, to provide background information and context.
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 1]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8148.
+
+Copyright Notice
+
+   Copyright (c) 2017 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 2]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   3.  Document Scope  . . . . . . . . . . . . . . . . . . . . . . .   8
+   4.  Overview of Legacy Deployment Models  . . . . . . . . . . . .   8
+   5.  Migration to Next Generation  . . . . . . . . . . . . . . . .  10
+   6.  Vehicle Data  . . . . . . . . . . . . . . . . . . . . . . . .  13
+   7.  Data Transport  . . . . . . . . . . . . . . . . . . . . . . .  14
+   8.  Call Setup  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+   9.  New Metadata/Control Values . . . . . . . . . . . . . . . . .  17
+     9.1.  New Values for the "action" Attribute . . . . . . . . . .  18
+     9.2.  Example <request> Element . . . . . . . . . . . . . . . .  19
+     9.3.  The <ack> Element . . . . . . . . . . . . . . . . . . . .  19
+     9.4.  The <capabilities> Element  . . . . . . . . . . . . . . .  20
+   10. Test Calls  . . . . . . . . . . . . . . . . . . . . . . . . .  21
+   11. Example Call Initiation . . . . . . . . . . . . . . . . . . .  22
+   12. Security Considerations . . . . . . . . . . . . . . . . . . .  27
+   13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  28
+   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
+     14.1.  MIME Media Type Registration for
+            application/EmergencyCall.VEDS+xml . . . . . . . . . . .  28
+     14.2.  Registration of the "VEDS" Entry in the Emergency Call
+            Data Types Registry  . . . . . . . . . . . . . . . . . .  30
+     14.3.  New Action Values  . . . . . . . . . . . . . . . . . . .  30
+     14.4.  Emergency Call Static Messages Registry  . . . . . . . .  31
+     14.5.  Emergency Call Vehicle Lamp IDs Registry . . . . . . . .  32
+     14.6.  Emergency Call Vehicle Camera IDs Registry . . . . . . .  33
+     14.7.  The EmergencyCallData.VEDS INFO Package  . . . . . . . .  35
+   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
+     15.1.  Normative References . . . . . . . . . . . . . . . . . .  38
+     15.2.  Informative references . . . . . . . . . . . . . . . . .  39
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 3]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+1.  Introduction
+
+   Emergency calls made by in-vehicle systems (e.g., automatically in
+   the event of a crash or serious incident or manually by a vehicle
+   occupant) assist in significantly reducing road deaths and injuries
+   by allowing emergency services to respond quickly and appropriately
+   to the specifics of the incident, often with better location
+   accuracy.
+
+   Drivers often have a poor location awareness, especially outside of
+   major cities, at night, and when away from home (especially abroad).
+   In the most crucial cases, the victim(s) might not be able to call
+   because they have been injured or trapped.
+
+   For more than two decades, some vehicles have been equipped with
+   telematics systems that, among other features, place an emergency
+   call automatically in the event of a crash or manually in response to
+   an emergency call button.  Such systems generally have on-board
+   location determination systems that make use of satellite-based
+   positioning technology, inertial sensors, gyroscopes, etc., which can
+   provide an accurate position for the vehicle.  Such built-in systems
+   can take advantage of the benefits of being integrated into a
+   vehicle, such as more power capacity, ability to have larger or
+   specialized antenna, ability to be engineered to avoid or minimize
+   degradation by vehicle glass coatings, interference from other
+   vehicle systems, etc.  Thus, the Public Safety Answering Point (PSAP)
+   can be provided with a good estimate of where the vehicle is during
+   an emergency.  Vehicle manufacturers are increasingly adopting such
+   systems, both for the safety benefits and for the additional features
+   and services they enable (e.g., remote engine diagnostics, remote
+   door unlock, stolen vehicle tracking and disabling, etc.).
+
+   A common term for such systems is Automatic Crash Notification (ACN)
+   or Advanced Automatic Crash Notification (AACN).  Sometimes the word
+   "Collision" is used instead of "Crash."  In this document, "ACN" is
+   used as a general term.  ACN systems transmit some amount of data
+   specific to the incident, referred to generally as "crash data" (the
+   term is commonly used even though there might not have been a crash).
+   While different systems transmit different amounts of crash data,
+   standardized formats, structures, and mechanisms are needed to
+   provide interoperability among systems and PSAPs.
+
+   As of the date of this document, currently deployed in-vehicle
+   telematics systems are circuit-switched and lack a standards-based
+   ability to convey crash data directly to the PSAP (generally relying
+   on either a human advisor or an automated text-to-speech system to
+   provide the PSAP call taker with some crash data orally, or in some
+   cases via a proprietary mechanism).  In most cases, the PSAP call
+
+
+
+Gellens, et al.              Standards Track                    [Page 4]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   taker needs to first realize that the call is related to a vehicle
+   incident, and then listen to the data and transcribe it.  Circuit-
+   switched ACN systems are referred to here as "CS-ACN".
+
+   The transition to next-generation emergency calling provides an
+   opportunity to vastly improve the scope, breadth, reliability, and
+   usefulness of crash data by transmitting a standardized set during
+   call setup; the data can be processed by the PSAP in an integrated,
+   automated way and made available to the call taker at call
+   presentation.  It also provides the ability for the call taker to
+   request that a vehicle take certain actions, such as flashing lights
+   or unlocking doors.  In addition, vehicle manufacturers are provided
+   an opportunity to take advantage of the same standardized mechanisms
+   for data transmission and request processing for internal use if they
+   wish (such as telemetry between the vehicle and a service center for
+   both emergency and non-emergency uses, including location-based
+   services, multimedia entertainment systems, remote door unlocking,
+   remote diagnostics, and roadside assistance applications).
+
+   Next-generation ACN provides an opportunity for such calls to be
+   recognized and processed as such during call setup, and routed to an
+   equipped PSAP where the vehicle data is available to assist the call
+   taker in assessing and responding to the situation.  Next-generation
+   (IP-based) ACN systems are referred to here as NG-ACN.
+
+   An ACN call can be initiated by a vehicle occupant or automatically
+   initiated by vehicle systems in the event of a serious incident.
+   (The "A" in "ACN" does stand for "Automatic", but the term is broadly
+   used to refer to the class of calls that are placed by an in-vehicle
+   system (IVS) or by Telematics Service Providers (TSPs) and that carry
+   incident-related data as well as voice.)  Automatically triggered
+   calls indicate a car crash or some other serious incident (e.g., a
+   fire).  Manually triggered calls include reports of observed crashes
+   or serious hazards (such as impaired drivers or roadway debris),
+   requests for medical assistance, etc.
+
+   The Association of Public-Safety Communications Officials (APCO) and
+   the National Emergency Number Association (NENA) have jointly
+   developed a standardized set of incident-related vehicle data for ACN
+   use, called the Vehicle Emergency Data Set (VEDS) [VEDS].  Such data
+   is often referred to as crash data although it is applicable in
+   incidents other than crashes.
+
+   This document describes how the IETF mechanisms for IP-based
+   emergency calls are used to provide the realization of next-
+   generation ACN.  Although this specification is designed with the
+   requirements for North America ACN in mind (and both APCO and NENA
+   are based in the U.S.), it is specified generically such that the
+
+
+
+Gellens, et al.              Standards Track                    [Page 5]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   technology can be reused or extended to suit requirements in other
+   regions.
+
+   This document reuses the technical aspects of next-generation Pan-
+   European eCall (a mandated and standardized system for emergency
+   calls by in-vehicle systems within Europe), as described in
+   [RFC8147].  However, this document specifies use of a different set
+   of vehicle (crash) data, specifically, VEDS rather than the eCall
+   Minimum Set of Data (MSD).  This document is an extension of
+   [RFC8147], with the differences being that this document makes the
+   MSD data set optional and VEDS mandatory, and it adds new attribute
+   values to the metadata/control object defined in that document.  This
+   document also registers a new INFO package (identical to that defined
+   in [RFC8147] with the addition of the VEDS MIME type).
+
+   This document registers the application/EmergencyCallData.VEDS+xml
+   MIME media type, the VEDS Emergency Call Data Type, and the
+   EmergencyCallData.VEDS INFO package to enable carrying this and
+   related data in SIP INFO requests.
+
+   Section 6 introduces VEDS.  Section 7 describes how VEDS data and
+   metadata/control blocks are transported within NG-ACN calls.
+   Section 8 describes how such calls are placed.
+
+   These mechanisms are used to place emergency calls that are
+   identifiable as ACN calls and that carry standardized crash data in
+   an interoperable way.
+
+   Calls by in-vehicle systems are placed using cellular networks, which
+   might ignore location information sent by an originating device in an
+   emergency call INVITE, instead substituting their own location
+   information (although often determined in cooperation with the
+   originating device).  Standardized crash data structures typically
+   include location as determined by the IVS.  A benefit of this is that
+   it allows the PSAP to see both the location as determined by the
+   cellular network and the location as determined by the IVS.
+
+   This specification inherits the ability to utilize test call
+   functionality from Section 15 of [RFC6881].
+
+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].
+
+
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 6]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   This document reuses terminology defined in Section 3 of [RFC5012].
+   Additionally, we use the following abbreviations:
+
+      3GPP:    3rd Generation Partnership Project
+
+      AACN:    Advanced Automatic Crash Notification
+
+      ACN:     Automatic Crash Notification
+
+      APCO:    Association of Public-Safety Communications Officials
+
+      EENA:    European Emergency Number Association
+
+      ESInet:  Emergency Services IP network
+
+      GNSS:    Global Navigation Satellite System (which includes
+               various systems such as the Global Positioning System or
+               GPS)
+
+      IVS:     In-Vehicle System
+
+      MNO:     Mobile Network Operator
+
+      MSD:     Minimum Set of Data
+
+      NENA:    National Emergency Number Association
+
+      NG:      Next Generation
+
+      POTS:    Plain Old Telephone Service (normal, circuit-switched
+               voice calls)
+
+      PSAP:    Public Safety Answering Point
+
+      TSP:     Telematics Service Provider
+
+      VEDS:    Vehicle Emergency Data Set
+
+   Because the endpoints of a next-generation ACN call are a PSAP and
+   either an IVS or a TSP, to avoid repetitively writing "IVS or TSP",
+   the term "IVS" is used to represent either an IVS or a TSP when
+   discussing signaling behavior (e.g., sending VEDS data, sending a SIP
+   INVITE request, receiving a SIP INFO request, etc.).
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 7]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+3.  Document Scope
+
+   This document is focused on how an ACN emergency call is set up and
+   incident-related data (including vehicle, sensor, and location data)
+   is transmitted to the PSAP using IETF specifications.  For the direct
+   model, this is the end-to-end description (between the vehicle and
+   the PSAP).  For the TSP model, this describes the call leg between
+   the TSP and the PSAP, leaving the call leg between the vehicle and
+   the TSP up to the entities involved (i.e., IVS and TSP vendors) who
+   are free to use the same mechanism for both legs, or not.
+
+   Note that Europe has a mandated and standardized system for emergency
+   calls by in-vehicle systems.  This Pan-European system is known as
+   "eCall" and is the subject of a separate document, [RFC8147], which
+   this document builds on.  Vehicles designed to operate in multiple
+   regions might need to support eCall as well as NG-ACN as described
+   here.  A vehicle IVS might determine whether to use eCall or ACN by
+   first determining the region or country in which it is located (e.g.,
+   from a GNSS location estimate and/or identity of or information from
+   an MNO).  If other regions adopt other data formats, a multi-region
+   vehicle might need to support those as well.  This document adopts
+   the call setup and other technical aspects of [RFC8147], which uses
+   [RFC7852]; this makes it straightforward to use a different data set
+   while keeping other technical aspects unchanged.  Hence, both next-
+   generation eCall (NG-eCall) and the NG-ACN mechanism described here
+   are compatible, differing primarily in the specific data block that
+   is sent (the eCall MSD in the case of NG-eCall and VEDS in this
+   document) and some additions to the metadata/control data block.  If
+   other regions adopt their own vehicle data sets, this can be
+   similarly accommodated without changing other technical aspects.
+   Note that any additional data formats require a new INFO package to
+   permit transport within SIP INFO requests.
+
+4.  Overview of Legacy Deployment Models
+
+   Legacy (circuit-switched) systems for placing emergency calls by
+   in-vehicle systems generally have some ability to convey at least
+   location and in some cases telematics data to the PSAP.  Most such
+   systems use one of three architectural models, which are described
+   here as: "TSP", "direct", and "paired".  These three models are
+   illustrated below.
+
+   In the TSP model, both emergency and routine TSP service calls are
+   placed to a TSP; a proprietary technique (e.g., a proprietary in-band
+   modem) is used for data transfer between the TSP and the vehicle.
+
+
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 8]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   In an emergency, typically a TSP agent verifies the emergency,
+   bridges in the PSAP, and communicates location, crash data (such as
+   impact severity and trauma prediction), and other data (such as the
+   vehicle description) to the PSAP call taker orally (in some cases, a
+   proprietary out-of-band interface is used).  Since the TSP knows the
+   location of the vehicle (from on-board GNSS and sensors), location-
+   based routing is usually used to route to the appropriate PSAP.  In
+   some cases, the TSP is able to transmit location automatically, using
+   similar techniques as for wireless calls.  A three-way voice call is
+   generally established between the vehicle, the TSP, and the PSAP,
+   allowing communication between the PSAP call taker, the TSP agent,
+   and the vehicle occupants (who might be unconscious).
+
+      ///----\\\  proprietary  +-----+  911 trunk or POTS   +------+
+     ||| IVS |||-------------->| TSP |--------------------->| PSAP |
+      \\\----///  crash data   +-----+  location via trunk  +------+
+
+                        Figure 1: Legacy TSP Model
+
+   In the paired model, the IVS uses a local link (typically Bluetooth
+   [Bluetooth]) with a previously paired handset to establish an
+   emergency call with the PSAP (by dialing a standard emergency number;
+   9-1-1 in North America) and then communicates location data to the
+   PSAP via text-to-speech; crash data might or might not be conveyed
+   also using text-to-speech.  Some such systems use an automated voice
+   prompt menu for the PSAP call taker (e.g., "this is an automatic
+   emergency call from a vehicle; press 1 to open a voice path to the
+   vehicle; press 2 to hear the location read out") to allow the call
+   taker to request location data via text-to-speech.
+
+      ///----\\\   +----+   911/etc. voice call via handset  +------+
+     ||| IVS |||-->| HS |----------------------------------->| PSAP |
+      \\\----///   +----+   location via text-to-speech      +------+
+
+   (Note: "HS" is handset.)
+
+                       Figure 2: Legacy Paired Model
+
+   In the direct model, the IVS directly places an emergency call with
+   the PSAP by dialing a standard emergency number (9-1-1 in North
+   America).  Such systems might communicate location data to the PSAP
+   via text-to-speech; crash data might or might not be conveyed using
+   text-to-speech.  Some such systems use an automated voice prompt menu
+   (e.g., "this is an automatic emergency call from a vehicle; press 1
+   to open a voice path to the vehicle; press 2 to hear the location
+   read out") to allow the call taker to request location data via
+   text-to-speech.
+
+
+
+
+Gellens, et al.              Standards Track                    [Page 9]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+      ///----\\\      911/etc. voice call via IVS         +------+
+     ||| IVS  |||---------------------------------------->| PSAP |
+      \\\----///     location via text-to-speech          +------+
+
+                       Figure 3: Legacy Direct Model
+
+5.  Migration to Next Generation
+
+   The migration of emergency calls placed by in-vehicle systems to
+   next-generation (all-IP) technology per this document provides a
+   standardized mechanism to identify such calls and to convey crash
+   data with the call setup, as well as enabling additional
+   communications modalities and enhanced functionality.  This allows
+   ACN calls and crash data to be automatically processed by the PSAP
+   and made available to the call taker in an integrated, automated way.
+   Because the crash data is carried in the initial SIP INVITE (per
+   [RFC7852]) the PSAP can present it to the call taker simultaneously
+   with the appearance of the call.  The PSAP can also process the data
+   to take other actions (e.g., if multiple calls from the same location
+   arrive when the PSAP is busy and a subset of them are NG-ACN calls, a
+   PSAP might choose to store the information and reject the calls,
+   since the IVS will receive confirmation that the information has been
+   successfully received; a PSAP could also choose to include a message
+   stating that it is aware of the incident and responders are on the
+   way, and a PSAP could call the vehicle back when a call taker is
+   available).
+
+   The migration of origination devices and networks, PSAPs, emergency
+   services networks, and other telephony environments to next
+   generation technology provides enhanced interoperability and
+   functionality, especially for emergency calls carrying additional
+   data such as vehicle crash data.  (In the U.S., a network
+   specifically for emergency responders is being developed.  This
+   network, FirstNet, will be next generation from the start, enhancing
+   the ability for data exchange between PSAPs and responders.)
+
+   NG-ACN calls can be recognized as such during call set-up; they can
+   be routed to a PSAP that is prepared both technically and
+   operationally to handle such calls, and the vehicle-determined
+   location and crash data can be processed automatically by the PSAP
+   and made available to the call taker simultaneously with the call
+   appearance.  Enhanced functionality includes the ability for the PSAP
+   call taker to request the vehicle to take an action, such as sending
+   an updated set of data, conveying a message to the occupants,
+   flashing lights, unlocking doors, etc.
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 10]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   Vehicle manufacturers using the TSP model can choose to take
+   advantage of the same mechanism to carry telematics data and requests
+   and responses between the vehicle and the TSP for both emergency and
+   non-emergency calls as are used for the interface with the PSAP.
+
+   An IVS establishes a next-generation emergency call (see [RFC6443]
+   and [RFC6881]) with an initial INVITE containing a Request-URI
+   indicating an ACN emergency call and Call-Info header fields
+   indicating that both vehicle crash and capabilities data are
+   included; the IVS typically does not perform routing or location
+   queries (relying on the MNO for this).
+
+   [RFC8147] registers new service URN children within the "sos"
+   subservice.  These URNs request NG-ACN resources and differentiate
+   between manually and automatically triggered NG-ACN calls (which
+   might be subject to different treatment depending on policy).  The
+   two service URNs registered in [RFC8147] are
+   "urn:service:sos.ecall.automatic" and "urn:service:sos.ecall.manual".
+   The same service URNs are used for ACN as for eCall since in any
+   region only one of these is supported, making a distinction
+   unnecessary.  (Further, PSAP equipment might support multiple data
+   formats, allowing a PSAP to handle a vehicle that erroneously sent
+   the wrong data object.)
+
+   Note that in North America, routing queries performed by clients
+   outside of an ESInet typically treat all sub-services of "sos"
+   identically to "sos" with no sub-service.  However, the Request-URI
+   header field retains the full sub-service; route and handling
+   decisions within an ESInet or PSAP can take the sub-service into
+   account.  For example, in a region with multiple cooperating PSAPs,
+   an NG-ACN call might be routed to a PSAP that is NG-ACN capable, or
+   one that specializes in vehicle-related incidents.
+
+   Migration of the three architectural models to next generation
+   (all-IP) is described below.
+
+   In the TSP model, the IVS transmits crash and location data to the
+   TSP either by reusing the mechanisms and data objects described in
+   this document or by using a proprietary mechanism.  In an emergency,
+   the TSP bridges in the PSAP, and the TSP transmits crash and other
+   data to the PSAP using the mechanisms and data objects described in
+   this document.  There is a three-way call between the vehicle, the
+   TSP, and the PSAP, allowing communication between the PSAP call
+   taker, the TSP agent, and the vehicle occupants (who might be
+   unconscious).  The TSP relays PSAP requests and vehicle responses.
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 11]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+                   proprietary
+     ///----\\\    or standard     +-----+     standard       +------+
+    ||| IVS |||------------------->| TSP |------------------->| PSAP |
+     \\\----///  crash+other data  +-----+  crash+other data  +------+
+
+                    Figure 4: Next-Generation TSP Model
+
+   The vehicle manufacturer and the TSP can choose to use the same
+   mechanisms and data objects on the left call leg in Figure 4 as on
+   the right.  (Note that the TSP model can be more difficult when the
+   vehicle is in a different country than the TSP (e.g., a US resident
+   driving in Canada) because of the additional complexity in choosing
+   the correct PSAP based on vehicle location performed by a TSP in a
+   different country.)
+
+   In the direct model, the IVS communicates crash data to the PSAP
+   directly using the mechanisms and data objects described in this
+   document.
+
+     ///----\\\           NG emergency call              +------+
+    ||| IVS |||----------------------------------------->| PSAP |
+     \\\----///          crash + other data              +------+
+
+                  Figure 5: Next-Generation Direct Model
+
+   In the paired model, the IVS uses a local link to a previously paired
+   handset to establish an emergency call with the PSAP; it is unclear
+   what facilities are or will be available for transmitting crash data
+   through the link to the handset for inclusion in an NG emergency call
+   and receiving additional data items from the response.  Hence,
+   manufacturers that use the paired model for legacy calls might choose
+   to adopt either the direct or TSP model for next-generation calls.
+
+      ///----\\\   (undefined)    +----+      standard        +------+
+     ||| IVS |||----------------->| HS |--------------------->| PSAP |
+      \\\----///   (undefined)    +----+  crash + other data  +------+
+
+                  Figure 6: Next-Generation Paired Model
+
+   Regardless of model, if the call is routed to a PSAP that is not
+   NG-ACN capable, the PSAP ignores (or does not receive) the vehicle
+   data.  This is detectable by the IVS or TSP when the status response
+   to the INVITE (e.g., 200 OK) lacks a metadata/control structure
+   acknowledging receipt of the data [RFC8147].  The IVS or TSP then
+   proceeds as it would for a CS-ACN call (e.g., oral conveyance of
+   data).
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 12]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+6.  Vehicle Data
+
+   APCO and NENA have jointly developed a standardized set of incident-
+   related vehicle data for ACN use, called the Vehicle Emergency Data
+   Set (VEDS) [VEDS].  Such data is often referred to as crash data
+   although it is applicable in incidents other than crashes.
+
+   VEDS provides a standard data set for the transmission, exchange, and
+   interpretation of vehicle-related data.  A standard data format
+   allows the data to be generated by an IVS or TSP and interpreted by
+   PSAPs, emergency responders, and medical facilities.  It includes
+   incident-related information such as airbag deployment, location and
+   compass orientation of the vehicle, spatial orientation of the
+   vehicle (e.g., upright, on a side, roof, or bumper), sensor data that
+   can indicate the potential severity of the crash and the likelihood
+   of severe injuries to the vehicle occupants, etc.  This data better
+   informs the PSAP and emergency responders as to the type of response
+   that might be needed.  Some of this information has been included in
+   U.S. government guidelines for field triage of injured patients
+   [triage-2008] [triage-2011].  These guidelines are designed to help
+   responders identify the potential existence of severe internal
+   injuries and to make critical decisions about how and where a patient
+   needs to be transported.
+
+   VEDS is an XML structure (see [VEDS]) transported in SIP using the
+   application/EmergencyCallData.VEDS+xml MIME media type.
+
+   If new data blocks are needed (e.g., in other regions or for enhanced
+   data), the steps required during standardization are briefly
+   summarized below:
+
+   o  A set of data is standardized by a Standards Development
+      Organization (SDO) or appropriate organization.
+
+   o  A MIME media type for the crash data set is registered with IANA
+
+      *  If the data is specifically for use in emergency calling, the
+         MIME media type is normally under the application type with a
+         subtype starting with EmergencyCallData.
+
+      *  If the data format is XML, then by convention the name has a
+         suffix of "+xml".
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 13]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   o  The item is registered in the "Emergency Call Data Types"
+      registry, as defined in Section 11.1.9 of [RFC7852].
+
+      *  For emergency-call-specific formats, the registered name is the
+         root of the MIME media type (not including the
+         EmergencyCallData prefix and any suffix such as "+xml") as
+         described in Section 4.1 of [RFC7852].
+
+   o  A new INFO package is registered that permits carrying the new
+      media type, the metadata/control object (defined in [RFC8147]),
+      and for compatibility, the MSD and VEDS objects, in SIP INFO
+      requests.
+
+7.  Data Transport
+
+   [RFC7852] establishes a general mechanism for including blocks of
+   data within a SIP emergency call.  This document makes use of that
+   mechanism.  This document also registers an INFO package (in
+   Section 14.7) to enable NG-ACN-related data blocks to be carried in
+   SIP INFO requests (per [RFC6086], new SIP INFO method usages require
+   the definition of an INFO package).
+
+   VEDS is an XML structure defined by APCO and NENA [VEDS].  It is
+   carried in a body part with MIME media type application/
+   EmergencyCallData.VEDS+xml.
+
+   An IVS transmits a VEDS data block (see [VEDS]) by including it as a
+   body part of a SIP message per [RFC7852].  The body part is
+   identified by its MIME media type (application/
+   EmergencyCallData.VEDS+xml) in the Content-Type header field of the
+   body part.  The body part is assigned a unique identifier that is
+   listed in a Content-ID header field in the body part.  The SIP
+   message is marked as containing the VEDS data by adding (or appending
+   to) a Call-Info header field at the top level of the SIP message.
+   This Call-Info header field contains a Content Identifier (CID) URL
+   referencing the body part's unique identifier and a "purpose"
+   parameter identifying the data as a VEDS data block per the
+   "Emergency Call Data Types" registry entry; the "purpose" parameter's
+   value is "EmergencyCallData.VEDS".  A VEDS data block is carried in a
+   SIP INFO request by using the INFO package defined in Section 14.7.
+
+   A PSAP or IVS transmits a metadata/control object (see [RFC8147]) by
+   including it in a SIP message as a MIME body part per [RFC7852].  The
+   body part is identified by its MIME media type (application/
+   EmergencyCallData.Control+xml) in the Content-Type header field of
+   the body part.  The body part is assigned a unique identifier that is
+   listed in a Content-ID header field in the body part.  The SIP
+   message is marked as containing the metadata/control block by adding
+
+
+
+Gellens, et al.              Standards Track                   [Page 14]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   (or appending to) a Call-Info header field at the top level of the
+   SIP message.  This Call-Info header field contains a CID URL
+   referencing the body part's unique identifier and a "purpose"
+   parameter identifying the data as a metadata/control block per the
+   "Emergency Call Data Types" registry entry; the "purpose" parameter's
+   value is "EmergencyCallData.Control".  A metadata/control object is
+   carried in a SIP INFO request by using the INFO package defined in
+   Section 14.7.
+
+   A body part containing a VEDS or metadata/control object has a
+   Content-Disposition header field value containing "By-Reference" and
+   is always enclosed in a multipart body part (even if it would
+   otherwise be the only body part in the SIP message).
+
+   An IVS initiating an NG-ACN call includes in the initial INVITE a
+   VEDS data block and a metadata/control object informing the PSAP of
+   its capabilities.  The VEDS and metadata/control body parts (and
+   Presence Information Data Format Location Object (PIDF-LO)) have a
+   Content-Disposition header field with the value "By-Reference;
+   handling=optional".  Specifying handling=optional prevents the INVITE
+   from being rejected if it is processed by a legacy element (e.g., a
+   gateway between SIP and circuit-switched environments) that does not
+   understand the VEDS or metadata/control (or PIDF-LO) objects.  The
+   PSAP creates a metadata/control object acknowledging receipt of the
+   VEDS data and includes it in the SIP final response to the INVITE.
+   The metadata/control object is not included in provisional (e.g.,
+   180) responses.
+
+   If the IVS receives an acknowledgment for a VEDS data object with
+   received=false, this indicates that the PSAP was unable to properly
+   decode or process the VEDS.  The IVS action is not defined (e.g., it
+   might only log an error).  Since the PSAP is able to request an
+   updated VEDS during the call, if an initial VEDS is unsatisfactory in
+   any way, the PSAP can choose to request another one.
+
+   A PSAP can request that the vehicle send an updated VEDS data block
+   during a call.  To do so, the PSAP creates a metadata/control object
+   requesting VEDS data and includes it as a body part of a SIP INFO
+   request sent within the dialog.  The IVS then includes an updated
+   VEDS data object as a body part of a SIP INFO request and sends it
+   within the dialog.  If the IVS is unable to send the VEDS for any
+   reason, it instead sends a metadata/control object containing an
+   <ack> element acknowledging the request and containing an
+   <actionResult> element with the "success" parameter set to "false"
+   and a "reason" parameter (and optionally a "details" parameter)
+   indicating why the request cannot be accomplished.  Per [RFC6086],
+   metadata/control objects and VEDS data are sent using the INFO
+   package defined in Section 14.7.  In addition, to align with the way
+
+
+
+Gellens, et al.              Standards Track                   [Page 15]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   a VEDS or metadata/control block is transmitted in a SIP message
+   other than a SIP INFO request, one or more Call-Info header fields
+   are included in the SIP INFO request referencing the VEDS or
+   metadata/control block.  See Section 14.7 for more information on the
+   use of SIP INFO requests within NG-ACN calls.
+
+   Any metadata/control object sent by a PSAP can request that the
+   vehicle perform an action (such as sending a data block, flashing
+   lights, providing a camera feed, etc.).  The IVS sends an
+   acknowledgment for any request other than a successfully executed
+   send-data action.  Multiple requests with the same "action:" value
+   MUST be sent in separate metadata/control body parts (to avoid any
+   ambiguity in the acknowledgment).  For each metadata/control block
+   received containing one or more <request> elements (except for
+   successfully executed send-data requests), the IVS sends a metadata/
+   control object containing an <ack> element acknowledging the received
+   metadata/control block, containing an <actionResult> element per
+   <request> element.
+
+   If the IVS is aware that VEDS data it sent previously has changed, it
+   MAY send an unsolicited VEDS in any convenient SIP message, including
+   a SIP INFO request during the call.  The PSAP sends an acknowledgment
+   for an unsolicited VEDS object; if the IVS sent the unsolicited VEDS
+   in a SIP INFO request, the acknowledgment is sent in a new SIP INFO
+   request; otherwise, it is sent in the reply to the SIP request
+   containing the VEDS.
+
+8.  Call Setup
+
+   An IVS initiating an NG-ACN call sends a SIP INVITE request using one
+   of the SOS sub-services "SOS.ecall.automatic" or "SOS.ecall.manual"
+   in the Request-URI.  This SIP INVITE request includes standard sets
+   of both crash and capabilities data as described in Section 7.
+
+   Entities along the path between the vehicle and the PSAP are able to
+   identify the call as an ACN call and handle it appropriately.  The
+   PSAP is able to identify the crash and capabilities data included in
+   the SIP INVITE request by examining the Call-Info header fields for
+   "purpose" parameters whose values start with EmergencyCallData.  The
+   PSAP is able to access the data it is capable of handling and is
+   interested in by checking the "purpose" parameter values.
+
+   This document extends [RFC8147] by reusing the call setup and other
+   normative requirements with the exception that in this document,
+   support for the eCall MSD is OPTIONAL and support for VEDS is
+   REQUIRED.  This document also adds new attribute values to the
+   metadata/control object defined in [RFC8147].
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 16]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+9.  New Metadata/Control Values
+
+   This document adds new attribute values to the metadata/control
+   structure defined in [RFC8147].
+
+   In addition to the base usage from the PSAP to the IVS to acknowledge
+   receipt of crash data, the <ack> element is also contained in a
+   metadata/control block sent by the IVS to the PSAP.  This is used by
+   the IVS to acknowledge receipt of a request by the PSAP and indicate
+   if the request was carried out when that request would not otherwise
+   be acknowledged (if the PSAP requests the vehicle to send data and
+   the vehicle does so, the data serves as a success acknowledgment);
+   see Section 8 for details.
+
+   The <capabilities> element is used in a metadata/control block sent
+   from the IVS to the PSAP (e.g., in the initial INVITE) to inform the
+   PSAP of the vehicle capabilities.  Child elements contain all actions
+   and data types supported by the vehicle and all available lamps
+   (lights) and cameras.
+
+   New request values are added to the <request> element to enable the
+   PSAP to request the vehicle to perform additional actions.
+
+   Mandatory Actions (the IVS and the PSAP MUST support):
+
+   o  Transmit data object (VEDS MUST be supported; MSD MAY be
+      supported)
+
+   Optional Actions (the IVS and the PSAP MAY support):
+
+   o  Display and/or play static (pre-defined) message
+   o  Display and/or speak dynamic text (text supplied in action)
+   o  Flash or turn on or off a lamp (light)
+   o  Honk horn
+   o  Lock or unlock doors
+   o  Enable a camera
+
+   The <ack> element indicates the object being acknowledged (i.e., a
+   data object or a metadata/control block containing <request>
+   elements) and reports success or failure.
+
+   The <capabilities> element has child <request> elements indicating
+   the actions (including data types, lamps (lights), and cameras)
+   supported by the IVS.
+
+   The <request> element contains attributes to indicate the request and
+   to supply any needed information, and it MAY contain a <text> child
+   element to contain the text for a dynamic message.  The "action"
+
+
+
+Gellens, et al.              Standards Track                   [Page 17]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   attribute is mandatory and indicates the specific action.  [RFC8147]
+   established an IANA registry to contain the allowed values; this
+   document adds new values to that registry in Table 1.
+
+9.1.  New Values for the "action" Attribute
+
+   The following new "action" values are defined:
+
+   msg-static:  displays or plays a pre-defined message (translated as
+      appropriate for the language of the vehicle's interface).  A
+      registry is created in Section 14.4 for messages and their IDs.
+      Vehicles include the highest registered message in their
+      <capabilities> element to indicate support for all messages up to
+      and including the indicated value.  A registry of message
+      identification values is defined in Section 14.4.  There is only
+      one static message initially defined (listed in Table 2).  Because
+      all compliant vehicles are expected to support all static messages
+      translated into all languages supported by the vehicle, it is
+      important to limit the number of such messages.  Therefore, this
+      registry operates under "Specification Required" rules as defined
+      in [RFC5226], which requires a stable, public document and implies
+      expert review of the publication.
+
+   msg-dynamic:  displays or speaks (via text-to-speech) a message
+      contained in a child <text> element within the request.
+
+   honk:  sounds the horn.
+
+   lamp:  flashes a lamp (light) or turns it on or off.  The lamp is
+      identified by a lamp ID token contained in an "element-id"
+      attribute of the request.  The desired state of the lamp is either
+      "on", "off", or "flash" as indicated in a "requested-state"
+      attribute.  The duration of the lamp's requested state is
+      specified in a "persistence" attribute.  A registry of lamp
+      identification values is defined in Section 14.5.  The initial
+      values (listed in Table 3) are head, interior, fog-front,
+      fog-rear, brake, brake-center, position-front, position-rear,
+      turn-left, turn-right, and hazard.
+
+   enable-camera:  adds a one-way media stream (established via SIP
+      re-INVITE sent by the vehicle) to enable the PSAP call taker to
+      view a feed from a camera.  A registry of camera identification
+      values is defined in Section 14.6.  The initial values (listed in
+      Table 4) are backup, left-rear, right-rear, forward, rear-wide,
+      lane, interior, night-front, night-rear, night-left, and night-
+      right.
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 18]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   door-lock:  locks or unlocks all door locks.  A "requested-state"
+      attribute contains either "locked" or "unlocked" to indicate if
+      the doors are to be locked or unlocked.
+
+   Note that there is no "request" action to play dynamic media (such as
+   an audio message).  The PSAP can send a SIP re-INVITE to establish a
+   one-way media stream for this purpose.
+
+9.2.  Example <request> Element
+
+       <?xml version="1.0" encoding="UTF-8"?>
+       <EmergencyCallData.Control
+           xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
+           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+
+       <request action="send-data" datatype="VEDS"/>
+       <request action="lamp" element-id="hazard"
+                requested-state="flash" persistence="PT1H"/>
+       <request action="msg-static" int-id="1"/>
+       <request action="msg-dynamic">
+           <text>Remain calm.  Help is on the way.</text>
+       </request>
+
+       </EmergencyCallData.Control>
+
+                        Figure 7: <request> Example
+
+9.3.  The <ack> Element
+
+   The <ack> element is transmitted by the PSAP to acknowledge
+   unsolicited data sent by the IVS and transmitted by the IVS to
+   acknowledge receipt of a <request> element other than a successfully
+   performed "send-data" request (e.g., a request to display a message
+   to the vehicle occupants is acknowledged, but a request to transmit
+   VEDS data is not, since the transmitted VEDS serves as
+   acknowledgment).  An <ack> element sent by an IVS references the
+   unique ID of the metadata/control object containing the request(s),
+   and for each request being acknowledged, it indicates whether the
+   request was successfully performed, and if not, it indicates why not.
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 19]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+9.3.1.  Examples of the <ack> Element
+
+       <?xml version="1.0" encoding="UTF-8"?>
+       <EmergencyCallData.Control
+           xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
+           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+
+       <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.Control>
+
+                 Figure 8: Example <ack> from IVS to PSAP
+
+9.4.  The <capabilities> Element
+
+   The <capabilities> element [RFC8147] is transmitted by the IVS to
+   indicate its capabilities to the PSAP.
+
+   The <capabilities> element contains a <request> child element per
+   action supported by the vehicle.  The vehicle MUST support sending
+   the VEDS data object and so includes at a minimum a <request> child
+   element with the "action" attribute set to "send-data" and the
+   "supported-values" attribute containing all data blocks supported by
+   the IVS, which MUST include "VEDS".  All other actions are OPTIONAL.
+
+   If the "msg-static" action is supported, a <request> child element
+   with the "action" attribute set to "msg-static" is included, with the
+   "int-id" attribute set to the highest supported static message
+   supported by the vehicle.  A registry is created in Section 14.4 to
+   map "int-id" values to static text messages.  By sending the highest
+   supported static message number in its <capabilities> element, the
+   vehicle indicates its support for all static messages in the registry
+   up to and including that value.
+
+   If the "lamp" action is supported, a <request> child element with the
+   "action" attribute set to "lamp" is included, with the "supported-
+   values" attribute set to all supported lamp IDs.  A registry is
+   created in Section 14.5 to contain lamp ID values.
+
+   If the "enable-camera" action is supported, a <request> child element
+   with the "action" attribute set to "enable-camera" is included, with
+   the "supported-values" attribute set to all supported camera IDs.  A
+   registry is created in Section 14.6 to contain camera ID values.
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 20]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+9.4.1.  Example <capabilities> Element
+
+       <?xml version="1.0" encoding="UTF-8"?>
+       <EmergencyCallData.Control
+           xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
+           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+
+       <capabilities>
+           <request action="send-data" supported-values="VEDS"/>
+           <request action="lamp"
+                    supported-values="head;interior;fog-front;
+                    fog-rear;brake;position-front;position-rear;
+                    turn-left;turn-right;hazard"/>
+           <request action="msg-static" int-id="3"/>
+           <request action="msg-dynamic"/>
+           <request action="honk"/>
+           <request action="enable-camera"
+                    supported-values="backup; interior"/>
+           <request action="door-lock"/>
+       </capabilities>
+
+       </EmergencyCallData.Control>
+
+                     Figure 9: <capabilities> Example
+
+10.  Test Calls
+
+   An NG-ACN test call is a call that is recognized and treated to some
+   extent as an NG-ACN call but is not given emergency call treatment
+   nor handled by a PSAP call taker.  The specific handling of test
+   NG-ACN calls is outside the scope of this document; typically, the
+   test call facility allows the IVS, user, or TSP to verify that an
+   NG-ACN call can be successfully established with voice and/or other
+   media communication.  The IVS might also be able to verify that the
+   crash data was successfully received.
+
+   This document builds on [RFC8147], which inherits the ability to
+   utilize test call functionality from Section 15 of [RFC6881].  A
+   service URN starting with "test." indicates a test call.  Per
+   [RFC8147], "urn:service:test.sos.ecall" is used for test NG-ACN
+   calls.
+
+   MNOs, emergency authorities, ESInets, and PSAPs handle a vehicle call
+   requesting the "test" service URN so that the desired functionality
+   is tested, but this is outside the scope of this document.  (One
+   possibility is that MNOs route such calls as non-emergency calls to
+   an ESInet, which routes them to a PSAP that supports NG-ACN calls;
+   the PSAP accepts test calls, sends a crash data acknowledgment, and
+
+
+
+Gellens, et al.              Standards Track                   [Page 21]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   plays an audio clip (for example, saying that the call reached an
+   appropriate PSAP and the vehicle data was successfully processed) in
+   addition to supporting media loopback per [RFC6881].)
+
+   Note that since test calls are placed using "test" as the parent
+   service URN and "sos" as a child, such calls are not treated as an
+   emergency call, so some functionality might not apply (such as
+   preemption or availability for devices lacking service
+   ("non-service-initialized" (NSI) devices) if those are available for
+   emergency calls).
+
+11.  Example Call Initiation
+
+   Figure 10 shows an NG-ACN call initiation.  The vehicle initiates an
+   NG-ACN call using an MNO.  The MNO routes the call to an ESInet, as
+   for any emergency call.  The ESInet routes the call to an appropriate
+   NG-ACN-capable PSAP (using location information and the fact that it
+   is an NG-ACN call).  The call is processed by the Emergency Services
+   Routing Proxy (ESRP), as the entry point to the ESInet.  The ESRP
+   routes the call to an appropriate NG-ACN-capable PSAP, where the call
+   is handled by a call taker.  (In deployments where there is no
+   ESInet, the MNO itself routes the call directly to an appropriate
+   NG-ACN-capable PSAP.)
+
+                               +---------------------------------------+
+                               |                                       |
+               +------------+  |                  +-------+            |
+               |            |  |                  | PSAP2 |            |
+               |            |  |                  +-------+            |
+               | Originating|  |                                       |
+               |   Mobile   |  |  +------+    +----------------------+ |
+     Vehicle-->|   Network  |--|->| ESRP |--->| PSAP1 --> Call Taker | |
+               |            |  |  +------+    +----------------------+ |
+               |            |  |                                       |
+               +------------+  |                  +-------+            |
+                               |                  | PSAP3 |            |
+                               |                  +-------+            |
+                               |                                       |
+                               |                                       |
+                               |                                       |
+                               |                ESInet                 |
+                               +---------------------------------------+
+
+                    Figure 10: Example Call Initiation
+
+   Figure 11 illustrates an example SIP emergency call INVITE request as
+   generated by the IVS.  It includes a PIDF-LO with vehicle-determined
+   location information, a VEDS block with crash data, and a metadata/
+
+
+
+Gellens, et al.              Standards Track                   [Page 22]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   control block with capabilities data.  The INVITE has a request URI
+   containing the urn:service:sos.ecall.automatic service URN.  For
+   brevity, the example VEDS block does not show VEDS location
+   information, although this is generally present.
+
+   The example VEDS data structure shows information about a crashed
+   vehicle.  The example communicates that the car is a model year 2015
+   Saab 9-5 (a car that does not exist).  The front airbag deployed as a
+   consequence of the crash.  The <VehicleBodyCategoryCode> indicates
+   that the crashed vehicle is a passenger car (the code is set to
+   "101") and that it is not a convertible (the <ConvertibleIndicator>
+   value is set to "false").
+
+   The <VehicleCrashPulse> element provides further information about
+   the crash, namely that the force of impact based on the change in
+   velocity over the duration of the crash pulse was 100 MPH.  The
+   principal direction of the force of the impact is set to "12" (which
+   refers to 12 o'clock, corresponding to a frontal collision).  This
+   value is in the <CrashPulsePrincipalDirectionOfForceValue> element.
+
+   The <CrashPulseRolloverQuarterTurnsValue> indicates the number of
+   quarter turns in concert with a rollover expressed as a number; in
+   our case 1.
+
+   No roll bar was deployed, as indicated in
+   <VehicleRollbarDeployedIndicator> being set to "false".
+
+   Next, there is information indicating seat belt and seat sensor data
+   for individual seat positions in the vehicle.  In our example,
+   information from the driver seat is available (value "1" in the
+   <VehicleSeatLocationCategoryCode> element) showing that the seat belt
+   was monitored (<VehicleSeatbeltMonitoredIndicator> element), the seat
+   belt was fastened (<VehicleSeatbeltFastenedIndicator> element), and
+   the seat sensor determined that the seat was occupied
+   (<VehicleSeatOccupiedIndicator> element).
+
+   The weight of the vehicle when empty is listed as 600 kilograms in
+   our example.
+
+   The <SevereInjuryIndicator> element is set to "true", indicating a
+   likelihood that a vehicle occupant has suffered a severe injury
+   requiring immediate trauma care.
+
+   Additional information is provided, including the presence of fuel
+   leakage (<FuelLeakingIndicator> element), an indication whether the
+   vehicle was subjected to multiple impacts (<MultipleImpactsIndicator>
+   element), the orientation of the vehicle at final rest
+   (<VehicleFinalRestOrientationCategoryCode> element), and an
+
+
+
+Gellens, et al.              Standards Track                   [Page 23]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   indication that no parts of the vehicle are currently detected as
+   being on fire (the <VehicleFireIndicator> element).
+
+     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
+     Call-Info: <cid:1234567892@atlanta.example.com>;
+                purpose=EmergencyCallData.Control
+     Accept: application/sdp, application/pidf+xml,
+             application/EmergencyCallData.Control+xml
+     Recv-Info: EmergencyCallData.eCall
+     Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
+            SUBSCRIBE, NOTIFY, UPDATE
+     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>
+      Content-Disposition: by-reference;handling=optional
+
+      <?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>
+
+
+
+Gellens, et al.              Standards Track                   [Page 24]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+                         <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
+      Content-Type: application/EmergencyCallData.VEDS+xml
+      Content-ID: <1234567890@atlanta.example.com>
+      Content-Disposition: by-reference;handling=optional
+
+      <?xml version="1.0" encoding="UTF-8"?>
+      <AutomatedCrashNotification xmlns="http://www.veds.org/acn/1.0"
+          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+
+      <Crash>
+          <CrashVehicle>
+              <ItemMakeName xmlns="http://niem.gov/niem/niem-core/2.0">
+                  Saab
+              </ItemMakeName>
+              <ItemModelName xmlns="http://niem.gov/niem/niem-core/2.0">
+                  9-5
+              </ItemModelName>
+              <ItemModelYearDate
+                  xmlns="http://niem.gov/niem/niem-core/2.0">
+                  2015
+              </ItemModelYearDate>
+              <Airbag>
+                  <AirbagCategoryCode>FRONT</AirbagCategoryCode>
+                  <AirbagDeployedIndicator>true
+                  </AirbagDeployedIndicator>
+              </Airbag>
+              <ConvertibleIndicator>false</ConvertibleIndicator>
+              <PowerSourceCategoryCode>MAIN</PowerSourceCategoryCode>
+              <VehicleBodyCategoryCode
+                  xmlns="http://niem.gov/niem/domains/jxdm/4.1">
+                  101
+              </VehicleBodyCategoryCode>
+              <VehicleCrashPulse>
+                  <CrashPulseChangeInVelocityMeasure>
+                      <MeasurePointValue
+                          xmlns="http://niem.gov/niem/niem-core/2.0">
+
+
+
+Gellens, et al.              Standards Track                   [Page 25]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+                          100
+                      </MeasurePointValue>
+                      <MeasureUnitText
+                          xmlns="http://niem.gov/niem/niem-core/2.0">
+                          MPH</MeasureUnitText>
+                   </CrashPulseChangeInVelocityMeasure>
+                          <CrashPulsePrincipalDirectionOfForceValue>12
+                          </CrashPulsePrincipalDirectionOfForceValue>
+                  <CrashPulseRolloverQuarterTurnsValue>1
+                  </CrashPulseRolloverQuarterTurnsValue>
+              </VehicleCrashPulse>
+              <VehicleRollbarDeployedIndicator>false
+              </VehicleRollbarDeployedIndicator>
+              <VehicleSeat>
+                  <VehicleSeatLocationCategoryCode>1
+                  </VehicleSeatLocationCategoryCode>
+                  <VehicleSeatOccupiedIndicator>true
+                  </VehicleSeatOccupiedIndicator>
+                  <VehicleSeatbeltFastenedIndicator>true
+                  </VehicleSeatbeltFastenedIndicator>
+                  <VehicleSeatbeltMonitoredIndicator>true
+                  </VehicleSeatbeltMonitoredIndicator>
+              </VehicleSeat>
+              <VehicleUnladenWeightMeasure
+                  xmlns="http://niem.gov/niem/niem-core/2.0">
+                  <MeasurePointValue
+                      xmlns="http://niem.gov/niem/niem-core/2.0">
+                      600
+                      </MeasurePointValue>
+                  <MeasureUnitText
+                      xmlns="http://niem.gov/niem/niem-core/2.0">
+                      kilogram
+                  </MeasureUnitText>
+              </VehicleUnladenWeightMeasure>
+          </CrashVehicle>
+          <FuelLeakingIndicator>true</FuelLeakingIndicator>
+          <MultipleImpactsIndicator>false</MultipleImpactsIndicator>
+          <SevereInjuryIndicator>true</SevereInjuryIndicator>
+          <VehicleFinalRestOrientationCategoryCode>Driver
+          </VehicleFinalRestOrientationCategoryCode>
+          <VehicleFireIndicator>false</VehicleFireIndicator>
+      </Crash>
+  </AutomatedCrashNotification>
+
+      --boundary1
+      Content-Type: application/EmergencyCallData.Control+xml
+      Content-ID: <1234567892@atlanta.example.com>
+      Content-Disposition: by-reference;handling=optional
+
+
+
+Gellens, et al.              Standards Track                   [Page 26]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+      <?xml version="1.0" encoding="UTF-8"?>
+      <EmergencyCallData.Control
+           xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
+           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+
+       <capabilities>
+           <request action="send-data" supported-datatypes="VEDS"/>
+           <request action="lamp"
+                    supported-values="head;interior;fog-front;fog-rear;
+                    brake;position-front;position-rear;turn-left;
+                    turn-right;hazard"/>
+           <request action="msg-static" int-id="3"/>
+           <request action="msg-dynamic"/>
+           <request action="honk"/>
+           <request action="enable-camera"
+                    supported-values="backup;interior"/>
+           <request action="door-lock"/>
+       </capabilities>
+
+      </EmergencyCallData.Control>
+
+      --boundary1--
+
+       Figure 11: SIP INVITE for a Vehicle-Initiated Emergency Call
+
+12.  Security Considerations
+
+   Since this document relies on [RFC8147] and [RFC7852], the security
+   considerations described in those specifications apply here.  The
+   security considerations of [RFC5069] apply as well.  Implementors are
+   cautioned to read and understand the discussion in those documents.
+
+   In emergency service systems where location data is supplied or
+   determined with the assistance of an end host, it is possible that
+   the location is incorrect, either intentionally (e.g., in a denial-
+   of-service attack against the emergency services infrastructure) or
+   due to a malfunctioning device.  The reader is referred to [RFC7378]
+   for a discussion of some of these vulnerabilities.
+
+   In addition to the security considerations discussion specific to the
+   metadata/control object in [RFC8147], note that vehicles MAY decline
+   to carry out any requested action (e.g., if the vehicle requires but
+   is unable to verify the certificate used to sign the request).  The
+   vehicle MAY use any value in the reason registry to indicate why it
+   did not take an action (e.g., the generic "unable" or the more
+   specific "security-failure").  Because some actions carry more
+   potential risk than others (e.g., unlocking a door versus flashing
+   lights), vehicle policy MAY decline to carry out some requests in
+
+
+
+Gellens, et al.              Standards Track                   [Page 27]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   some circumstances (e.g., decline a request to unlock doors, send an
+   updated VEDS, or enable a camera received in a vehicle-terminated
+   call while carrying out such requests received in a vehicle-initiated
+   emergency call).
+
+13.  Privacy Considerations
+
+   Since this document builds on [RFC8147], which itself builds on
+   [RFC7852], the data structures specified there, and the corresponding
+   privacy considerations discussed there, apply here as well.  The VEDS
+   data structure contains optional elements that can carry identifying
+   and personal information, both about the vehicle and about the owner,
+   as well as location information, so it needs to be protected against
+   unauthorized disclosure, as discussed in [RFC7852].  Local
+   regulations may impose additional privacy protection requirements.
+
+   The additional functionality enabled by this document, such as access
+   to vehicle camera streams, carries a burden of protection, so
+   implementations need to be careful that access is only provided
+   within the context of an emergency call or to an emergency services
+   provider (e.g., by verifying that the request for camera access is
+   signed by a certificate issued by an emergency services registrar).
+
+14.  IANA Considerations
+
+   This document registers the application/EmergencyCallData.VEDS+xml
+   MIME media type and adds "VEDS" to the "Emergency Call Data Types"
+   registry.  This document adds to and creates sub-registries in the
+   "Emergency Call Metadata/Control Data" registry created in [RFC8147].
+   In addition, this document registers a new INFO package.
+
+14.1.  MIME Media Type Registration for application/
+       EmergencyCall.VEDS+xml
+
+   IANA has registered a new MIME media type according to the procedures
+   of [RFC6838] and guidelines in [RFC7303].
+
+      MIME media type name:  application
+
+      MIME subtype name:  EmergencyCallData.VEDS+xml
+
+      Mandatory parameters:  none
+
+      Optional parameters:  charset
+         Indicates the character encoding of enclosed XML.
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 28]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+      Encoding considerations:
+         Uses XML, which can employ 8-bit characters, depending on the
+         character encoding used.  See Section 3.2 of RFC 7303
+         [RFC7303].
+
+      Security considerations:
+            This media type is designed to carry vehicle crash data
+            during an emergency call.
+
+            This data can contain 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 Sections 9 and 10 of [RFC7852]
+            for more information.
+
+            When this media type is contained in a signed or encrypted
+            body part, the enclosing multipart (e.g., multipart/signed
+            or multipart/encrypted) has the same Content-ID as the data
+            part.  This allows an entity to identify and access the data
+            blocks it is interested in without having to dive deeply
+            into the message structure or decrypt parts it is not
+            interested in.  (The "purpose" parameter in a Call-Info
+            header field identifies the data, and the CID URL points to
+            the data block in the body, which has a matching Content-ID
+            body part header field.)
+
+      Interoperability considerations:  None
+
+      Published specification:  [VEDS]
+
+      Applications which use this media type:  Emergency Services
+
+      Additional information:  None
+
+      Magic Number:  None
+
+      File Extension:  .xml
+
+      Macintosh file type code:  TEXT
+
+      Persons and email addresses for further information:
+         Randall Gellens, rg+ietf@randy.pensive.org;
+         Hannes Tschofenig, Hannes.Tschofenig@gmx.net
+
+      Intended usage:  LIMITED USE
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 29]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+      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>
+
+14.2.  Registration of the "VEDS" Entry in the Emergency Call Data Types
+       Registry
+
+   IANA has added "VEDS" to the "Emergency Call Data Types" registry,
+   with a reference to this document; the "Data About" value is "The
+   Call".  The "Emergency Call Data Types" registry was established by
+   [RFC7852].
+
+14.3.  New Action Values
+
+   This document adds new values for the "action" attribute of the
+   <request> element in the "Emergency Call Action" registry created by
+   [RFC8147].
+
+                +---------------+-------------------------+
+                |      Name     |       Description       |
+                +---------------+-------------------------+
+                |   msg-static  | Section 9.1 of RFC 8148 |
+                |               |                         |
+                |  msg-dynamic  | Section 9.1 of RFC 8148 |
+                |               |                         |
+                |      honk     | Section 9.1 of RFC 8148 |
+                |               |                         |
+                |      lamp     | Section 9.1 of RFC 8148 |
+                |               |                         |
+                | enable-camera | Section 9.1 of RFC 8148 |
+                |               |                         |
+                |   door-lock   | Section 9.1 of RFC 8148 |
+                +---------------+-------------------------+
+
+            Table 1: Emergency Call Action Registry New Values
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 30]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+14.4.  Emergency Call Static Messages Registry
+
+   This document creates a new sub-registry called "Emergency Call
+   Static Messages" in the "Emergency Call Metadata/Control Data"
+   registry established by [RFC8147].  Because compliant vehicles are
+   expected to support all static messages translated into all languages
+   supported by the vehicle, it is important to limit the number of such
+   messages.  As defined in [RFC5226], this registry operates under
+   "Specification Required", which requires a stable, public document
+   and implies expert review of the publication.  The expert should
+   determine that the document has been published by an appropriate
+   emergency services organization (e.g., NENA, EENA, or APCO) or by the
+   IETF with input from an emergency services organization, and that the
+   proposed message is sufficiently distinguishable from other messages.
+
+   The contents of this registry are:
+
+   ID:  An integer identifier to be used in the "int-id" attribute of a
+      metadata/control <request> element.
+
+   Message:  The text of the message.  Messages are listed in the
+      registry in English; vehicles are expected to implement
+      translations into languages supported by the vehicle.
+
+   When new messages are added to the registry, the message text is
+   determined by the registrant; IANA assigns the IDs.  Each message is
+   assigned a consecutive integer value as its ID.  This allows an IVS
+   to indicate by a single integer value that it supports all messages
+   with that value or lower.  The value 0 is reserved; usable messages
+   start with 1.
+
+   The initial set of values is listed in Table 2.
+
+   +----+--------------------------------------------------------------+
+   | ID | Message                                                      |
+   +----+--------------------------------------------------------------+
+   | 0  | Reserved                                                     |
+   |    |                                                              |
+   | 1  | Emergency services has received your information and         |
+   |    | location but cannot speak with you right now.  We will get   |
+   |    | help to you as soon as possible.                             |
+   +----+--------------------------------------------------------------+
+
+      Table 2: Emergency Call Static Messages Registry Initial Values
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 31]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+14.5.  Emergency Call Vehicle Lamp IDs Registry
+
+   This document creates a new sub-registry called "Emergency Call
+   Vehicle Lamp IDs" in the "Emergency Call Metadata/Control Data"
+   registry established by [RFC8147].  This new sub-registry uniquely
+   identifies the names of automotive lamps (lights).  As defined in
+   [RFC5226], this registry operates under "Expert Review" rules.  The
+   expert should determine that the proposed lamp name is clearly
+   understandable and is sufficiently distinguishable from other lamp
+   names.
+
+   The contents of this registry are:
+
+   Name:  The identifier to be used in the "element-id" attribute of a
+      metadata/control <request> element.
+
+   Description:  A description of the lamp (light).
+
+   The initial set of values is listed in Table 3.
+
+     +----------------+---------------------------------------------+
+     | Name           | Description                                 |
+     +----------------+---------------------------------------------+
+     | head           | The main lamps used to light the road ahead |
+     |                |                                             |
+     | interior       | Interior lamp, often at the top center      |
+     |                |                                             |
+     | fog-front      | Front fog lamps                             |
+     |                |                                             |
+     | fog-rear       | Rear fog lamps                              |
+     |                |                                             |
+     | brake          | Brake indicator lamps                       |
+     |                |                                             |
+     | brake-center   | Center high-mounted stop lamp               |
+     |                |                                             |
+     | position-front | Front position/parking/standing lamps       |
+     |                |                                             |
+     | position-rear  | Rear position/parking/standing lamps        |
+     |                |                                             |
+     | turn-left      | Left turn/directional lamps                 |
+     |                |                                             |
+     | turn-right     | Right turn/directional lamps                |
+     |                |                                             |
+     | hazard         | Hazard/four-way lamps                       |
+     +----------------+---------------------------------------------+
+
+          Table 3: Emergency Call Lamp ID Registry Initial Values
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 32]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+14.6.  Emergency Call Vehicle Camera IDs Registry
+
+   This document creates a new sub-registry called "Emergency Call
+   Vehicle Camera IDs" in the "Emergency Call Metadata/Control Data"
+   registry established by [RFC8147].  This new sub-registry uniquely
+   identifies automotive cameras.  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 contents of this registry are:
+
+   Name:  The identifier to be used in the "element-id" attribute of a
+      control <request> element.
+
+   Description:  A description of the camera.
+
+   The initial set of values is listed in Table 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 33]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   +-------------+-----------------------------------------------------+
+   | Name        | Description                                         |
+   +-------------+-----------------------------------------------------+
+   | backup      | Shows what is behind the vehicle, e.g., often used  |
+   |             | for driver display when the vehicle is in reverse.  |
+   |             | Also known as rearview, reverse, rear visibility,   |
+   |             | etc.                                                |
+   |             |                                                     |
+   | left-rear   | Shows view to the left and behind (e.g., left-side  |
+   |             | rearview mirror or blind spot view)                 |
+   |             |                                                     |
+   | right-rear  | Shows view to the right and behind (e.g., right-    |
+   |             | side rearview mirror or blind spot view)            |
+   |             |                                                     |
+   | forward     | Shows what is in front of the vehicle               |
+   |             |                                                     |
+   | rear-wide   | Shows what is behind the vehicle (e.g., used by     |
+   |             | rear-collision detection systems), separate from    |
+   |             | backup view                                         |
+   |             |                                                     |
+   | lane        | Used by systems to identify road lane and/or        |
+   |             | monitor the vehicle's position within lane          |
+   |             |                                                     |
+   | interior    | Shows the interior (e.g., driver)                   |
+   |             |                                                     |
+   | night-front | Night-vision view of what is in front of the        |
+   |             | vehicle                                             |
+   |             |                                                     |
+   | night-rear  | Night-vision view of what is behind the vehicle     |
+   |             |                                                     |
+   | night-left  | Night-vision view of what is to the left of the     |
+   |             | vehicle                                             |
+   |             |                                                     |
+   | night-right | Night-vision view of what is to the right of the    |
+   |             | vehicle                                             |
+   +-------------+-----------------------------------------------------+
+
+    Table 4: Emergency Call Vehicle Camera IDs Registry Initial Values
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 34]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+14.7.  The EmergencyCallData.VEDS INFO Package
+
+   This document registers the EmergencyCallData.VEDS INFO package in
+   the "Info Packages Registry".
+
+   Both endpoints (the IVS and the PSAP equipment) include
+   "EmergencyCallData.VEDS" in a Recv-Info header field per [RFC6086] to
+   indicate the ability to receive SIP INFO messages carrying data as
+   described here.
+
+   Support for the EmergencyCallData.VEDS INFO package indicates the
+   ability to receive NG-ACN-related body parts as specified in this
+   document.
+
+   A SIP INFO request message carrying data related to an emergency call
+   as described in this document has an Info-Package header field set to
+   "EmergencyCallData.VEDS" per [RFC6086].
+
+   The requirements of Section 10 of [RFC6086] are addressed in the
+   following sections.
+
+14.7.1.  Overall Description
+
+   This section describes what type of information is carried in INFO
+   requests associated with the INFO package and for what types of
+   applications and functionalities User Agents (UAs) can use the INFO
+   package.
+
+   SIP INFO requests associated with the EmergencyCallData.VEDS INFO
+   package carry data associated with emergency calls as defined in this
+   document.  The application is vehicle-initiated emergency calls
+   established using SIP.  The functionality is to carry vehicle data
+   and metadata/control information between vehicles and PSAPs.
+
+14.7.2.  Applicability
+
+   This section describes why the INFO package mechanism, rather than
+   some other mechanism, has been chosen for the specific use case.
+
+   The use of the SIP INFO method is based on an analysis of the
+   requirements against the intent and effects of the INFO method versus
+   other approaches (which included the SIP MESSAGE method, SIP OPTIONS
+   method, SIP re-INVITE method, media-plane transport, and non-SIP
+   protocols).  In particular, the transport of emergency call data
+   blocks occurs within a SIP emergency dialog, per Section 7, and is
+   normally carried in the initial INVITE request and its response; the
+   use of the INFO method only occurs when emergency-call-related data
+   needs to be sent mid call.  While the SIP MESSAGE method could be
+
+
+
+Gellens, et al.              Standards Track                   [Page 35]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   used, it is not tied to a SIP dialog as is the INFO method and thus
+   might not be associated with the dialog.  Both the SIP OPTIONS or
+   re-INVITE methods could also be used, but they are seen as less clean
+   than the INFO method.  The SIP SUBSCRIBE/NOTIFY method could be
+   coerced into service, but the semantics are not a good fit, e.g., the
+   subscribe/notify mechanism provides one-way communication consisting
+   of (often multiple) notifications from notifier to subscriber
+   indicating that certain events in the notifier have occurred, whereas
+   what's needed here is two-way communication of data related to the
+   emergency dialog.  Use of media-plane mechanisms was discounted
+   because the number of messages needing to be exchanged in a dialog is
+   normally zero or very few, and the size of the data is likewise very
+   small.  The overhead caused by user-plane setup (e.g., to use the
+   Message Session Relay Protocol (MSRP) as transport) would be
+   disproportionately large.
+
+   Based on the analyses, the SIP INFO method was chosen to provide for
+   mid-call data transport.
+
+14.7.3.  INFO Package Name
+
+   The INFO package name is EmergencyCallData.VEDS.
+
+14.7.4.  INFO Package Parameters
+
+   None
+
+14.7.5.  SIP Option-Tags
+
+   None
+
+14.7.6.  INFO Request Body Parts
+
+   The body of an EmergencyCallData.VEDS INFO package is a multipart
+   body containing zero or one application/EmergencyCallData.VEDS+xml
+   parts (containing a VEDS data block), zero or more application/
+   EmergencyCallData.Control+xml (containing a metadata/control object)
+   parts, and zero or one application/EmergencyCallData.eCall.MSD parts
+   (containing an MSD).  At least one VEDS, MSD, or metadata/control
+   body part is expected; the behavior upon receiving a SIP INFO request
+   with none is undefined.
+
+   The body parts are sent per [RFC6086]; in addition, to align with how
+   these body parts are sent in non-INFO messages, each associated body
+   part is referenced by a Call-Info header field at the top level of
+   the SIP message.  The body part has a Content-Disposition header
+   field set to "By-Reference".
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 36]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+   A VEDS, metadata/control block, or MSD is always enclosed in a
+   multipart body part (even if it would otherwise be the only body part
+   in the SIP message).  The outermost multipart that contains only body
+   parts associated with the INFO package has a Content-Disposition
+   value of "Info-Package".
+
+   Service providers in the call path are not expected to add Additional
+   Data [RFC7852] to SIP INFO requests (as they would to an initial
+   INVITE request).
+
+14.7.7.  INFO Package Usage Restrictions
+
+   Usage is limited to vehicle-initiated emergency calls as defined in
+   this document.
+
+14.7.8.  Rate of INFO Requests
+
+   The SIP INFO request is used within an established emergency call
+   dialog to send requests, updated data, or an acknowledgment.  Because
+   requests are normally sent only on manual action of the PSAP call
+   taker (who suspects some aspect of the vehicle state has changed) and
+   updated data is sent only when an aspect of previously sent data has
+   changed, the rate of SIP INFO requests associated with the
+   EmergencyCallData.VEDS INFO package is normally quite low (most
+   dialogs are likely to contain zero SIP INFO requests, while others
+   can be expected to carry an occasional request).
+
+14.7.9.  INFO Package Security Considerations
+
+   The MIME media type registrations for the data blocks that can be
+   carried using this INFO package contains a discussion of the security
+   and/or privacy considerations specific to that data block.  See
+   Sections 12 and 13 for information on the security and privacy
+   considerations of the data carried in vehicle-initiated emergency
+   calls.
+
+14.7.10.  Implementation Details
+
+   See Sections 7 and 8 for protocol details.
+
+14.7.11.  Examples
+
+   See Section 11 for protocol examples.
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 37]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6086]  Holmberg, C., Burger, E., and H. Kaplan, "Session
+              Initiation Protocol (SIP) INFO Method and Package
+              Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
+              <http://www.rfc-editor.org/info/rfc6086>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <http://www.rfc-editor.org/info/rfc6838>.
+
+   [RFC6881]  Rosen, B. and J. Polk, "Best Current Practice for
+              Communications Services in Support of Emergency Calling",
+              BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
+              <http://www.rfc-editor.org/info/rfc6881>.
+
+   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
+              DOI 10.17487/RFC7303, July 2014,
+              <http://www.rfc-editor.org/info/rfc7303>.
+
+   [RFC7852]  Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
+              J. Winterbottom, "Additional Data Related to an Emergency
+              Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
+              <http://www.rfc-editor.org/info/rfc7852>.
+
+   [RFC8147]  Gellens, R. and H. Tschofenig, "Next-Generation Pan-
+              European eCall", RFC 8147, DOI 10.17487/RFC8147, May 2017,
+              <http://www.rfc-editor.org/info/rfc8147>.
+
+   [VEDS]     APCO International, "Vehicular Emergency Data Set (VEDS)",
+              Version 3.0, Prepared by the Advanced Automatic Crash
+              Notification (AACN) Joint APCO/NENA Data Standardization
+              Working Group, February 2012, <https://www.apcointl.org/
+              resources/telematics/aacn-and-veds.html>.
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 38]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+15.2.  Informative references
+
+   [Bluetooth]
+              Bluetooth Special Interest Group (SIG), "Bluetooth
+              Specifications", <https://www.bluetooth.com/
+              specifications>.
+
+   [RFC5012]  Schulzrinne, H. and R. Marshall, Ed., "Requirements for
+              Emergency Context Resolution with Internet Technologies",
+              RFC 5012, DOI 10.17487/RFC5012, January 2008,
+              <http://www.rfc-editor.org/info/rfc5012>.
+
+   [RFC5069]  Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
+              Shanmugam, "Security Threats and Requirements for
+              Emergency Call Marking and Mapping", RFC 5069,
+              DOI 10.17487/RFC5069, January 2008,
+              <http://www.rfc-editor.org/info/rfc5069>.
+
+   [RFC6443]  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
+              "Framework for Emergency Calling Using Internet
+              Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
+              2011, <http://www.rfc-editor.org/info/rfc6443>.
+
+   [RFC7378]  Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
+              "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
+              December 2014, <http://www.rfc-editor.org/info/rfc7378>.
+
+   [triage-2008]
+              National Center for Injury Prevention and Control,
+              "Recommendations from the Expert Panel: Advanced Automatic
+              Collision Notification and Triage of the Injured Patient",
+              Centers for Disease Control and Prevention, 2008,
+              <https://stacks.cdc.gov/view/cdc/5304/>.
+
+   [triage-2011]
+              National Center for Injury Prevention and Control,
+              "Guidelines for Field Triage of Injured Patients:
+              Recommendations of the National Expert Panel on Field
+              Triage", Centers for Disease Control and Prevention,
+              January 2012, <https://www.cdc.gov/mmwr/preview/mmwrhtml/
+              rr6101a1.htm>.
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 39]
+
+RFC 8148            Vehicle-Initiated Emergency Calls           May 2017
+
+
+Acknowledgments
+
+   We would like to thank Lena Chaponniere, Alissa Cooper, Stephen Edge,
+   Christer Holmberg, Allison Mankin, and Dan Romascanu for their review
+   and suggestions; Robert Sparks and Paul Kyzivat for their help with
+   the SIP mechanisms; Michael Montag, Arnoud van Wijk, Ban Al-Bakri,
+   Wes George, Gunnar Hellstrom, and Rex Buddenberg for their feedback;
+   and Ulrich Dietz for his help with preliminary draft versions of the
+   original document that later evolved into this document.
+
+Authors' Addresses
+
+   Randall Gellens
+   Core Technology Consulting
+
+   Email: rg+ietf@coretechnologyconsulting.com
+   URI:   http://www.coretechnologyconsulting.com
+
+
+   Brian Rosen
+   NeuStar, Inc.
+   470 Conrad Dr
+   Mars, PA  16046
+   United States of America
+
+   Email: br@brianrosen.net
+
+
+   Hannes Tschofenig
+   Individual
+
+   Email: Hannes.Tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et al.              Standards Track                   [Page 40]
+