summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8148.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8148.txt')
-rw-r--r--doc/rfc/rfc8148.txt2243
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]
+