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
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.
本文档描述了如何使用基于IP的紧急服务机制来支持车辆发出的下一代紧急呼叫（在发生碰撞或严重事故时自动发出，或由车辆乘员手动发出），并传送与碰撞或事故相关的车辆、传感器和位置数据。这种调用通常被称为“自动崩溃通知”（ACN）或“高级自动崩溃通知”（AACN），即使在手动触发的情况下也是如此。“高级”限定词指的是承载更丰富数据集的能力。
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.
本文档还注册了车辆、传感器和位置数据的MIME媒体类型和紧急呼叫数据类型（通常称为“碰撞数据”，即使不一定发生碰撞）和信息包，以便能够在SIP信息请求中携带此数据和相关数据。本文件中引用了数据格式、内容和结构的外部规范。
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.
本文件重复使用了下一代泛欧eCall（欧洲和其他地区的车载系统（IVSs）紧急呼叫授权标准化系统）的技术方面。但是，本文件规定使用不同的车辆（碰撞）数据集，特别是车辆应急数据集（VEDS），而不是eCall最小数据集（MSD）。本文档是IETF eCall文档的扩展，主要区别在于本文档使MSD数据集成为可选的，而VEDS是强制性的，并且它将属性值添加到元数据/控制对象以允许更大的功能。本文档注册了一个新的信息包（与为eCall注册的信息包相同，但添加了VEDS MIME类型）。本文档还描述了传统（电路交换）ACN系统及其到下一代紧急呼叫的迁移，以提供背景信息和上下文。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.).
二十多年来，一些车辆配备了远程通信系统，该系统除其他功能外，还具有在发生碰撞时自动拨打紧急电话或手动响应紧急呼叫按钮的功能。此类系统通常具有车载定位系统，该系统利用基于卫星的定位技术、惯性传感器、陀螺仪等，可为车辆提供准确的位置。此类内置系统可以利用集成到车辆中的优点，例如更大的功率容量、具有更大或专用天线的能力、设计用于避免或最小化车辆玻璃涂层退化的能力、来自其他车辆系统的干扰等。因此，公共安全应答点（PSAP）可以很好地估计车辆在紧急情况下的位置。车辆制造商越来越多地采用此类系统，既有利于安全，也有利于其提供的附加功能和服务（例如，远程发动机诊断、远程车门解锁、被盗车辆跟踪和禁用等）。
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.
此类系统的通用术语是自动崩溃通知（ACN）或高级自动崩溃通知（AACN）。有时使用“碰撞”一词代替“碰撞”。在本文档中，“ACN”是一个通用术语。ACN系统传输特定于事件的一定数量的数据，通常称为“碰撞数据”（该术语常用，即使可能没有碰撞）。虽然不同的系统传输不同数量的碰撞数据，但需要标准化的格式、结构和机制来提供系统和PSAP之间的互操作性。
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
截至本文件发布之日，当前部署的车载远程通信系统为电路交换系统，缺乏将碰撞数据直接传输至PSAP的基于标准的能力（通常依靠人工顾问或自动文本语音转换系统向PSAP呼叫接受者口头或在某些情况下通过专有机制提供一些碰撞数据）。在大多数情况下，PSAP呼叫
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".
接受者需要首先意识到呼叫与车辆事故有关，然后收听数据并进行转录。电路交换ACN系统在这里称为“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).
向下一代紧急呼叫的过渡提供了一个机会，通过在呼叫设置过程中传输标准化的数据集，极大地提高了碰撞数据的范围、广度、可靠性和有用性；PSAP可以以集成、自动化的方式处理数据，并在通话演示时提供给接听电话的人。它还为呼叫接受者提供了请求车辆采取某些行动的能力，例如闪光灯或解锁车门。此外，如果车辆制造商愿意，他们还可以利用相同的标准化机制进行数据传输和请求处理，以供内部使用（例如用于紧急和非紧急用途的车辆和服务中心之间的遥测，包括基于位置的服务、多媒体娱乐系统、远程车门解锁、远程诊断和路边救援应用）。
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.
下一代ACN提供了这样一个机会，即在呼叫设置过程中识别和处理此类呼叫，并将其路由到配备的PSAP，在该PSAP中，车辆数据可用于协助呼叫接受者评估和响应情况。下一代（基于IP的）ACN系统在这里称为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.
ACN呼叫可由车辆乘员发起，或在发生严重事故时由车辆系统自动发起。（ACN中的“A”代表“自动”，但该术语广泛用于指由车载系统（IVS）或远程通信服务提供商（TSP）拨打的电话类别，这些电话包含与事故相关的数据和语音。）自动触发的电话表示车祸或其他严重事故（例如火灾）。手动触发的呼叫包括观察到的碰撞或严重危险（如受损驾驶员或道路碎片）的报告、医疗援助请求等。
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.
公共安全通信官员协会（APCO）和国家应急号码协会（NENA）联合开发了一套标准化的事故相关车辆数据，供ACN使用，称为车辆应急数据集（VEDS）[VEDS]。此类数据通常称为碰撞数据，尽管它适用于碰撞以外的事件。
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
本文档描述了基于IP的紧急呼叫的IETF机制如何用于实现下一代ACN。尽管本规范的设计考虑了北美ACN的要求（且APCO和NENA均位于美国），但一般规定如下：
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).
本文件重复使用了[RFC8147]中所述的下一代泛欧eCall（欧洲境内车载系统紧急呼叫的强制性标准化系统）的技术方面。但是，本文件规定使用不同的车辆（碰撞）数据集，特别是VEDS，而不是eCall最小数据集（MSD）。本文档是[RFC8147]的扩展，不同之处在于本文档使MSD数据集成为可选的，而VEDS是必需的，并且它向该文档中定义的元数据/控件对象添加了新的属性值。本文档还注册了一个新的信息包（与[RFC8147]中定义的相同，添加了VEDS MIME类型）。
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.
本文档注册应用程序/EmergencyCallData.VEDS+xml MIME媒体类型、VEDS紧急呼叫数据类型和EmergencyCallData.VEDS信息包，以便在SIP信息请求中携带此数据和相关数据。
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.
第6节介绍了吠陀。第7节描述了如何在NG-ACN调用中传输VEDS数据和元数据/控制块。第8节描述了如何拨打此类电话。
These mechanisms are used to place emergency calls that are identifiable as ACN calls and that carry standardized crash data in an interoperable way.
这些机制用于拨打可识别为ACN呼叫的紧急呼叫，并以可互操作的方式携带标准化的崩溃数据。
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.
车载系统的呼叫使用蜂窝网络进行，蜂窝网络可能会忽略发端设备在紧急呼叫邀请中发送的位置信息，而代之以其自身的位置信息（尽管通常与发端设备协作确定）。标准化碰撞数据结构通常包括由IVS确定的位置。这样做的一个好处是，它允许PSAP同时查看由蜂窝网络确定的位置和由IVS确定的位置。
This specification inherits the ability to utilize test call functionality from Section 15 of [RFC6881].
本规范继承了[RFC6881]第15节中使用测试调用功能的功能。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document reuses terminology defined in Section 3 of [RFC5012]. Additionally, we use the following abbreviations:
本文件重复使用[RFC5012]第3节中定义的术语。此外，我们使用以下缩写：
3GPP: 3rd Generation Partnership Project
3GPP：第三代合作伙伴项目
AACN: Advanced Automatic Crash Notification
AACN：高级自动崩溃通知
ACN: Automatic Crash Notification
自动崩溃通知
APCO: Association of Public-Safety Communications Officials
APCO：公共安全通信官员协会
EENA: European Emergency Number Association
欧洲紧急号码协会
ESInet: Emergency Services IP network
紧急服务IP网络
GNSS: Global Navigation Satellite System (which includes various systems such as the Global Positioning System or GPS)
全球导航卫星系统：全球导航卫星系统（包括各种系统，如全球定位系统或全球定位系统）
IVS: In-Vehicle System
IVS：车载系统
MNO: Mobile Network Operator
移动网络运营商
MSD: Minimum Set of Data
MSD：最小数据集
NENA: National Emergency Number Association
国家紧急号码协会
NG: Next Generation
吴：下一代
POTS: Plain Old Telephone Service (normal, circuit-switched voice calls)
POTS：普通老式电话服务（普通电路交换语音呼叫）
PSAP: Public Safety Answering Point
公共安全回答点
TSP: Telematics Service Provider
TSP：远程通信服务提供商
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.).
由于下一代ACN呼叫的端点是PSAP和IVS或TSP，为了避免重复写入“IVS或TSP”，在讨论信令行为（例如，发送VEDS数据、发送SIP INVITE请求、接收SIP INFO请求等）时，术语“IVS”用于表示IVS或TSP。
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.
本文档重点介绍如何建立ACN紧急呼叫，以及如何使用IETF规范将事件相关数据（包括车辆、传感器和位置数据）传输至PSAP。对于直接车型，这是端到端的描述（在车辆和PSAP之间）。对于TSP模型，这描述了TSP和PSAP之间的呼叫分支，将车辆和TSP之间的呼叫分支留给相关实体（即IVS和TSP供应商），它们可以自由地对两个分支使用相同的机制，也可以不使用。
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.
请注意，欧洲有一个强制性和标准化的车载系统紧急呼叫系统。该泛欧系统被称为“eCall”，是单独文件[RFC8147]的主题，本文件以该文件为基础。设计用于在多个地区运行的车辆可能需要支持eCall以及此处所述的NG-ACN。车辆IVS可通过首先确定其所在的地区或国家（例如，根据GNSS位置估计和/或MNO的身份或信息）来确定是否使用eCall或ACN。如果其他地区采用其他数据格式，则多地区车辆可能也需要支持这些格式。本文件采用[RFC8147]的呼叫设置和其他技术方面，使用[RFC7852]；这使得在保持其他技术方面不变的情况下使用不同的数据集变得简单。因此，这里描述的下一代eCall（NG eCall）和NG-ACN机制都是兼容的，主要不同于发送的特定数据块（本文档中NG eCall和VEDS的eCall MSD）和元数据/控制数据块的一些附加内容。如果其他地区采用他们自己的车辆数据集，这可以在不改变其他技术方面的情况下进行类似调整。请注意，任何其他数据格式都需要一个新的INFO包，以允许在SIP INFO请求中进行传输。
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.
用于通过车载系统拨打紧急呼叫的传统（电路交换）系统通常具有将至少位置和某些情况下的远程通信数据传送到PSAP的一些能力。大多数这样的系统使用三种体系结构模型中的一种，这里描述为：“TSP”、“direct”和“paired”。这三个模型如下所示。
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.
在TSP模型中，紧急和常规TSP服务调用都放置在TSP中；TSP和车辆之间的数据传输使用专有技术（例如，专有带内调制解调器）。
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).
在紧急情况下，TSP代理通常会验证紧急情况，在PSAP中架桥，并将位置、碰撞数据（如碰撞严重程度和创伤预测）和其他数据（如车辆描述）口头传达给PSAP呼叫接受者（在某些情况下，使用专有的带外接口）。由于TSP知道车辆的位置（来自车载GNSS和传感器），因此通常使用基于位置的路由来路由到适当的PSAP。在某些情况下，TSP能够使用与无线呼叫类似的技术自动传输位置信息。通常在车辆、TSP和PSAP之间建立三向语音呼叫，允许PSAP呼叫接受者、TSP代理和车辆乘员（可能无意识）之间进行通信。
///----\\\ proprietary +-----+ 911 trunk or POTS +------+
||| IVS |||-------------->| TSP |--------------------->| PSAP |
\\\----/// crash data +-----+ location via trunk +------+
///----\\\ proprietary +-----+ 911 trunk or POTS +------+
||| IVS |||-------------->| TSP |--------------------->| PSAP |
\\\----/// crash data +-----+ location via trunk +------+
Figure 1: Legacy TSP Model
图1：遗留TSP模型
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.
在配对模式中，IVS使用本地链路（通常为蓝牙[蓝牙]）与先前配对的手机建立与PSAP的紧急呼叫（通过拨打标准紧急号码；在北美为9-1-1），然后通过文本到语音向PSAP传送位置数据；崩溃数据可能会也可能不会通过文本到语音的方式传输。一些此类系统使用PSAP呼叫接受者的自动语音提示菜单（例如，“这是一个来自车辆的自动紧急呼叫；按1打开车辆的语音路径；按2听到位置读数”），以允许呼叫接受者通过文本到语音请求位置数据。
///----\\\ +----+ 911/etc. voice call via handset +------+
||| IVS |||-->| HS |----------------------------------->| PSAP |
\\\----/// +----+ location via text-to-speech +------+
///----\\\ +----+ 911/etc. voice call via handset +------+
||| IVS |||-->| HS |----------------------------------->| PSAP |
\\\----/// +----+ location via text-to-speech +------+
(Note: "HS" is handset.)
（注：“HS”为手机。）
Figure 2: Legacy Paired Model
图2：遗留配对模型
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.
在直接模式中，IVS通过拨打标准紧急电话号码（北美为9-1-1），直接向PSAP拨打紧急电话。此类系统可通过文本到语音向PSAP传送位置数据；崩溃数据可能会也可能不会使用文本到语音传输。一些此类系统使用自动语音提示菜单（例如，“这是一个来自车辆的自动紧急呼叫；按1键打开车辆的语音路径；按2键听到位置读数”），以允许接听电话的人通过文本到语音请求位置数据。
///----\\\ 911/etc. voice call via IVS +------+
||| IVS |||---------------------------------------->| PSAP |
\\\----/// location via text-to-speech +------+
///----\\\ 911/etc. voice call via IVS +------+
||| IVS |||---------------------------------------->| PSAP |
\\\----/// location via text-to-speech +------+
Figure 3: Legacy Direct Model
图3：遗留直接模型
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).
根据本文件，将车内系统发出的紧急呼叫迁移到下一代（全IP）技术提供了一种标准化的机制，用于识别此类呼叫，并通过呼叫设置传送碰撞数据，以及启用其他通信模式和增强功能。这允许PSAP自动处理ACN呼叫和崩溃数据，并以集成、自动化的方式提供给呼叫接受者。因为崩溃数据是在初始SIP INVITE（根据[RFC7852]）中携带的，所以PSAP可以在出现呼叫的同时将其呈现给呼叫接受者。PSAP还可以处理数据以采取其他操作（例如，如果来自同一位置的多个呼叫在PSAP忙时到达，并且其中一个子集是NG-ACN呼叫，则PSAP可能会选择存储信息并拒绝呼叫，因为IVS将收到信息已成功接收的确认；PSAP也可以选择包含一条消息，说明其已意识到事件和响应者正在路上，PSAP可以在有接线员的情况下给车辆回电话）。
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.)
将始发设备和网络、PSAP、紧急服务网络和其他电话环境迁移到下一代技术提供了增强的互操作性和功能，特别是对于承载额外数据（如车辆碰撞数据）的紧急呼叫。（在美国，正在开发一个专门用于应急响应者的网络。该网络名为FirstNet，从一开始就是下一代网络，增强了PSAP和响应者之间的数据交换能力。）
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.
NG-ACN呼叫可在呼叫设置期间识别；它们可以路由到PSAP，该PSAP在技术上和操作上都准备好处理此类呼叫，并且PSAP可以自动处理车辆确定的位置和碰撞数据，并在呼叫出现的同时提供给呼叫接受者。增强的功能包括PSAP呼叫接受者请求车辆采取行动的能力，例如发送更新的数据集、向乘客传达信息、闪光灯、车门解锁等。
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.
使用TSP模型的车辆制造商可以选择利用与PSAP接口相同的机制，在车辆和TSP之间传输紧急和非紧急呼叫的远程通信数据、请求和响应。
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).
IVS建立下一代紧急呼叫（参见[RFC6443]和[RFC6881]），初始INVITE包含指示ACN紧急呼叫的请求URI和指示包括车辆碰撞和能力数据的呼叫信息头字段；IVS通常不执行路由或位置查询（这取决于MNO）。
[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.)
[RFC8147]在“sos”子服务中注册新的服务URN子服务。这些URN请求NG-ACN资源，并区分手动和自动触发的NG-ACN调用（根据策略可能会受到不同的处理）。[RFC8147]中注册的两个服务urn是“urn:service:sos.ecall.automatic”和“urn:service:sos.ecall.manual”。ACN使用的服务URN与eCall使用的服务URN相同，因为在任何地区都只支持其中一个，因此没有必要进行区分。（此外，PSAP设备可能支持多种数据格式，允许PSAP处理错误发送错误数据对象的车辆。）
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.
请注意，在北美，由ESInet之外的客户端执行的路由查询通常将“sos”的所有子服务等同于“sos”，而不处理任何子服务。然而，请求URI报头字段保留完整的子服务；ESInet或PSAP中的路由和处理决策可以考虑子服务。例如，在具有多个合作PSAP的区域中，NG-ACN呼叫可能被路由到支持NG-ACN的PSAP，或专门处理车辆相关事件的PSAP。
Migration of the three architectural models to next generation (all-IP) is described below.
下面描述了三种体系结构模型到下一代（全IP）的迁移。
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.
在TSP模型中，IVS通过重用本文档中描述的机制和数据对象或使用专有机制，向TSP传输碰撞和位置数据。在紧急情况下，TSP桥接PSAP，TSP使用本文档中描述的机制和数据对象向PSAP传输崩溃和其他数据。车辆、TSP和PSAP之间有一个三路呼叫，允许PSAP呼叫接受者、TSP代理和车辆乘员（可能无意识）之间进行通信。TSP中继PSAP请求和车辆响应。
proprietary
///----\\\ or standard +-----+ standard +------+
||| IVS |||------------------->| TSP |------------------->| PSAP |
\\\----/// crash+other data +-----+ crash+other data +------+
proprietary
///----\\\ or standard +-----+ standard +------+
||| IVS |||------------------->| TSP |------------------->| PSAP |
\\\----/// crash+other data +-----+ crash+other data +------+
Figure 4: Next-Generation TSP Model
图4：下一代TSP模型
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.)
车辆制造商和TSP可以选择使用图4中左侧调用段与右侧调用段相同的机制和数据对象。（请注意，当车辆位于与TSP不同的国家时（例如，美国居民在加拿大驾驶），TSP模型可能会更加困难，因为根据TSP在不同国家执行的车辆位置选择正确的PSAP会更加复杂。）
In the direct model, the IVS communicates crash data to the PSAP directly using the mechanisms and data objects described in this document.
在直接模型中，IVS使用本文档中描述的机制和数据对象直接将崩溃数据传送给PSAP。
///----\\\ NG emergency call +------+
||| IVS |||----------------------------------------->| PSAP |
\\\----/// crash + other data +------+
///----\\\ NG emergency call +------+
||| IVS |||----------------------------------------->| PSAP |
\\\----/// crash + other data +------+
Figure 5: Next-Generation Direct Model
图5：下一代直接模型
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.
在配对模型中，IVS使用到先前配对的手机的本地链路来建立与PSAP的紧急呼叫；目前尚不清楚有哪些设施可用于或将有哪些设施可用于通过手机链路传输碰撞数据，以包括在NG紧急呼叫中，并从响应中接收额外的数据项。因此，对传统呼叫使用配对模型的制造商可能会选择对下一代呼叫采用直接或TSP模型。
///----\\\ (undefined) +----+ standard +------+
||| IVS |||----------------->| HS |--------------------->| PSAP |
\\\----/// (undefined) +----+ crash + other data +------+
///----\\\ (undefined) +----+ standard +------+
||| IVS |||----------------->| HS |--------------------->| PSAP |
\\\----/// (undefined) +----+ crash + other data +------+
Figure 6: Next-Generation Paired Model
图6：下一代配对模型
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).
无论何种型号，如果呼叫路由到不支持NG-ACN的PSAP，则PSAP将忽略（或不接收）车辆数据。当对INVITE的状态响应（例如，200 OK）缺少确认收到数据的元数据/控制结构时，IVS或TSP可以检测到这一点[RFC8147]。然后，IVS或TSP继续进行CS-ACN呼叫（例如，口头传输数据）。
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.
APCO和NENA联合开发了一套标准化的事故相关车辆数据，供ACN使用，称为车辆应急数据集（VEDS）[VEDS]。此类数据通常称为碰撞数据，尽管它适用于碰撞以外的事件。
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为车辆相关数据的传输、交换和解释提供了标准数据集。标准数据格式允许IVS或TSP生成数据，并由PSAP、应急响应人员和医疗机构进行解释。它包括与事故相关的信息，如安全气囊展开、车辆的位置和指南针方向、车辆的空间方向（例如，直立、侧面、车顶或保险杠）、可指示碰撞潜在严重性和车辆乘员严重受伤可能性的传感器数据，这些数据可以更好地通知PSAP和应急响应者可能需要的响应类型。其中一些信息已包含在《美国政府受伤患者现场分流指南》[triage-2008][triage-2011]中。这些指南旨在帮助响应者识别严重内伤的潜在存在，并就如何以及在何处运送患者做出关键决定。
VEDS is an XML structure (see [VEDS]) transported in SIP using the application/EmergencyCallData.VEDS+xml MIME media type.
VEDS是一种XML结构（参见[VEDS]），使用application/emergencyccalldata.VEDS+XMLMIME媒体类型在SIP中传输。
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 一组数据由标准开发组织（SDO）或适当的组织进行标准化。
o A MIME media type for the crash data set is registered with IANA
o 崩溃数据集的MIME媒体类型已向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.
* 如果数据专门用于紧急调用，MIME媒体类型通常位于应用程序类型下，子类型以EmergencyCallData开头。
* If the data format is XML, then by convention the name has a suffix of "+xml".
* 如果数据格式为XML，则按照惯例，名称的后缀为“+XML”。
o The item is registered in the "Emergency Call Data Types" registry, as defined in Section 11.1.9 of [RFC7852].
o 根据[RFC7852]第11.1.9节的定义，该项目在“紧急呼叫数据类型”注册表中注册。
* 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].
* 对于紧急呼叫特定格式，注册名称是[RFC7852]第4.1节所述MIME媒体类型的根（不包括紧急呼叫数据前缀和任何后缀，如“+xml”）。
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.
o 注册了一个新的信息包，该信息包允许在SIP信息请求中携带新媒体类型、元数据/控制对象（在[RFC8147]中定义）以及MSD和VEDS对象，以实现兼容性。
[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).
[RFC7852]建立了一种通用机制，用于在SIP紧急呼叫中包含数据块。本文件利用了这一机制。本文件还注册了一个信息包（见第14.7节），以使NG ACN相关数据块能够在SIP信息请求中携带（根据[RFC6086]，新的SIP信息方法使用需要定义信息包）。
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.
VEDS是由APCO和NENA[VEDS]定义的XML结构。它包含在MIME媒体类型application/emergencyccalldata.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.
IVS通过按照[RFC7852]将其作为SIP消息的主体部分来传输VEDS数据块（参见[VEDS]）。主体部分通过主体部分的内容类型头字段中的MIME媒体类型（application/emergencyccalldata.VEDS+xml）来标识。为身体部位分配了唯一标识符，该标识符列在身体部位的内容ID标题字段中。通过在SIP消息的顶层添加（或附加）呼叫信息头字段，SIP消息被标记为包含VEDS数据。此呼叫信息标头字段包含引用身体部位唯一标识符的内容标识符（CID）URL和根据“紧急呼叫数据类型”注册表项将数据标识为VEDS数据块的“目的”参数；“purpose”参数的值是“EmergencyCallData.VEDS”。通过使用第14.7节中定义的信息包，在SIP信息请求中携带VEDS数据块。
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
PSAP或IVS通过按照[RFC7852]将元数据/控制对象作为MIME主体部分包含在SIP消息中来传输元数据/控制对象（请参见[RFC8147]）。主体部分在主体部分的内容类型头字段中由其MIME媒体类型（application/emergencyccalldata.Control+xml）标识。为身体部位分配了唯一标识符，该标识符列在身体部位的内容ID标题字段中。SIP消息通过添加
(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.
（或附加到）SIP消息顶层的呼叫信息头字段。此Call Info header字段包含引用身体部位唯一标识符的CID URL和“purpose”参数，该参数根据“Emergency Call data Types”（紧急呼叫数据类型）注册表项将数据标识为元数据/控制块；“purpose”参数的值是“EmergencyCallData.Control”。通过使用第14.7节中定义的信息包，在SIP信息请求中携带元数据/控制对象。
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).
包含VEDS或元数据/控制对象的正文部分具有包含“按引用”的内容处置标头字段值，并且始终包含在多部分正文部分中（即使它是SIP消息中唯一的正文部分）。
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.
发起NG-ACN呼叫的IVS在初始INVITE中包括一个VEDS数据块和一个元数据/控制对象，用于通知PSAP其能力。VED和元数据/控制主体部件（以及状态信息数据格式位置对象（PIDF-LO））具有一个值为“By Reference；handling=optional”的内容处置标题字段。指定handling=optional可防止由不理解VEDS或元数据/控制（或PIDF-LO）对象的遗留元素（例如，SIP和电路交换环境之间的网关）处理的INVITE被拒绝。PSAP创建一个元数据/控制对象，确认收到了VEDS数据，并将其包含在对INVITE的SIP最终响应中。元数据/控制对象不包括在临时（例如180）响应中。
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.
如果IVS接收到VEDS数据对象的确认，且received=false，则表明PSAP无法正确解码或处理VEDS。未定义IVS操作（例如，它可能只记录错误）。由于PSAP能够在呼叫期间请求更新的VEDS，如果初始VEDS在任何方面都不令人满意，PSAP可以选择请求另一个。
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
PSAP可以请求车辆在呼叫期间发送更新的VEDS数据块。为此，PSAP创建一个元数据/控制对象，请求VEDS数据，并将其作为对话框中发送的SIP信息请求的主体部分。然后，IVS将更新后的VEDS数据对象作为SIP信息请求的主体部分，并在对话框中发送。如果IVS因任何原因无法发送VEDS，它将发送一个元数据/控制对象，该对象包含一个<ack>元素，确认请求，并包含一个<actionResult>元素，其中“success”参数设置为“false”和“reason”参数（以及可选的“details”参数）说明无法完成请求的原因。根据[RFC6086]，使用第14.7节中定义的信息包发送元数据/控制对象和视频数据。除此之外，要与方式保持一致
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.
在SIP消息中传输VEDS或元数据/控制块而不是SIP信息请求，一个或多个呼叫信息报头字段包括在SIP信息请求中，该SIP信息请求引用VEDS或元数据/控制块。有关在NG-ACN呼叫中使用SIP信息请求的更多信息，请参见第14.7节。
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.
PSAP发送的任何元数据/控制对象都可以请求车辆执行操作（例如发送数据块、闪烁灯光、提供摄像头馈送等）。IVS发送除成功执行的发送数据操作之外的任何请求的确认。具有相同“action:”值的多个请求必须在单独的元数据/控制主体部分中发送（以避免确认中的任何歧义）。对于接收到的包含一个或多个<request>元素（成功执行的发送数据请求除外）的每个元数据/控制块，IVS发送包含<ack>元素的元数据/控制对象，确认接收到的元数据/控制块，每个<request>元素包含一个<actionResult>元素。
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.
如果IVS意识到它先前发送的VEDS数据已经改变，它可以在任何方便的SIP消息中发送未经请求的VEDS，包括呼叫期间的SIP信息请求。PSAP发送对未经请求的VEDS对象的确认；如果IVS在SIP信息请求中发送未经请求的VED，则在新的SIP信息请求中发送确认；否则，它将在对包含VED的SIP请求的回复中发送。
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.
发起NG-ACN呼叫的IVS使用请求URI中的SOS子服务“SOS.ecall.automatic”或“SOS.ecall.manual”发送SIP INVITE请求。此SIP INVITE请求包括第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.
车辆和PSAP之间路径上的实体能够将呼叫识别为ACN呼叫并适当处理。PSAP能够识别SIP INVITE请求中包含的崩溃和能力数据，方法是检查Call Info报头字段中的“purpose”参数，这些参数的值以EmergencyCallData开头。PSAP能够通过检查“目的”参数值来访问其能够处理和感兴趣的数据。
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].
本文档通过重用呼叫设置和其他规范性要求扩展了[RFC8147]，但本文档中对eCall MSD的支持是可选的，对VEDS的支持是必需的。本文档还向[RFC8147]中定义的元数据/控件对象添加了新的属性值。
This document adds new attribute values to the metadata/control structure defined in [RFC8147].
本文档向[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.
除了从PSAP到IVS确认接收到崩溃数据的基本用法外，<ack>元素还包含在IVS发送到PSAP的元数据/控制块中。IVS将其用于确认收到PSAP的请求，并指示该请求是否在该请求未被确认的情况下执行（如果PSAP请求车辆发送数据，且车辆发送数据，则该数据作为成功确认）；详情见第8节。
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.
<capabilities>元素用于从IVS发送到PSAP的元数据/控制块中（例如，在初始INVITE中），以通知PSAP车辆能力。子元素包含车辆和所有可用灯（灯）和摄像头支持的所有动作和数据类型。
New request values are added to the <request> element to enable the PSAP to request the vehicle to perform additional actions.
将新的请求值添加到<request>元素中，以使PSAP能够请求车辆执行其他操作。
Mandatory Actions (the IVS and the PSAP MUST support):
强制措施（IVS和PSAP必须支持）：
o Transmit data object (VEDS MUST be supported; MSD MAY be supported)
o 传输数据对象（必须支持VED；可能支持MSD）
Optional Actions (the IVS and the PSAP MAY support):
可选操作（IVS和PSAP可能支持）：
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
o 显示和/或播放静态（预定义）信息o显示和/或说出动态文本（活动中提供的文本）o闪烁或打开或关闭灯（灯）o按喇叭o锁定或解锁车门o启用摄像头
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.
<ack>元素表示正在确认的对象（即，包含<request>元素的数据对象或元数据/控制块），并报告成功或失败。
The <capabilities> element has child <request> elements indicating the actions (including data types, lamps (lights), and cameras) supported by the IVS.
<capabilities>元素具有子<request>元素，指示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"
<request>元素包含指示请求和提供任何所需信息的属性，它可能包含一个子元素<text>来包含动态消息的文本。“行动”
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.
属性是必需的，指示特定操作。[RFC8147]建立了IANA注册表以包含允许的值；本文档向表1中的注册表添加新值。
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 static：显示或播放预定义消息（根据车辆界面语言进行适当翻译）。第14.4节为消息及其ID创建了一个注册表。车辆在其<capabilities>元素中包含最高注册信息，以表示支持所有信息，包括指示值。第14.4节定义了消息标识值的注册表。最初只定义了一条静态消息（见表2）。由于所有符合要求的车辆都应支持所有翻译成车辆支持的所有语言的静态消息，因此限制此类消息的数量非常重要。因此，该登记处按照[RFC5226]中定义的“规范要求”规则运作，这需要一份稳定的公开文件，并意味着对出版物进行专家审查。
msg-dynamic: displays or speaks (via text-to-speech) a message contained in a child <text> element within the request.
msg dynamic：显示或说出（通过文本到语音）请求中子<text>元素中包含的消息。
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.
灯：使灯（灯）闪烁或打开或关闭。lamp由请求的“元素ID”属性中包含的lamp ID令牌标识。灯的所需状态为“打开”、“关闭”或“闪烁”，如“请求状态”属性中所示。灯请求状态的持续时间在“持久性”属性中指定。第14.5节规定了灯具识别值的登记。初始值（在表3中列出）为车头、车内、前雾、后雾、制动器、制动中心、前位、后位、左转、右转和危险。
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.
启用摄像头：添加单向媒体流（通过车辆发送的SIP重新邀请建立），以使PSAP呼叫接受者能够查看摄像头提供的提要。第14.6节定义了摄像机识别值的注册。初始值（在表4中列出）为备用、左后、右后、前、后宽、车道、车内、夜间前、夜间后、夜间左和夜间右。
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.
请注意，没有播放动态媒体（如音频消息）的“请求”操作。PSAP可以发送SIP重新邀请以为此目的建立单向媒体流。
<?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">
<?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>
<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>
</EmergencyCallData.Control>
Figure 7: <request> Example
Figure 7: <request> Example
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.
<ack>元素由PSAP发送以确认IVS发送的未经请求的数据，并由IVS发送以确认收到除成功执行的“发送数据”请求之外的<request>元素（例如，向车辆乘员显示消息的请求已确认，但发送VEDS数据的请求未确认，因为发送的VEDS用作确认）。IVS发送的<ack>元素引用包含请求的元数据/控制对象的唯一ID，对于每个被确认的请求，它指示请求是否已成功执行，如果未成功，则指示原因。
<?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">
<?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>
<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>
</EmergencyCallData.Control>
Figure 8: Example <ack> from IVS to PSAP
Figure 8: Example <ack> from IVS to PSAP
The <capabilities> element [RFC8147] is transmitted by the IVS to indicate its capabilities to the PSAP.
<capabilities>元素[RFC8147]由IVS传输，以向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.
<capabilities>元素包含车辆支持的每个操作的<request>子元素。车辆必须支持发送VEDS数据对象，因此至少包括一个<request>子元素，其“action”属性设置为“send data”，且“supported values”属性包含IVS支持的所有数据块，其中必须包括“VEDS”。所有其他操作都是可选的。
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.
如果支持“msg static”操作，则包含一个<request>子元素，其“action”属性设置为“msg static”，“int id”属性设置为车辆支持的最高支持静态消息。在第14.4节中创建了一个注册表，将“int id”值映射到静态文本消息。通过在其<capabilities>元素中发送最高支持的静态消息编号，车辆表明其支持注册表中的所有静态消息，包括该值。
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.
如果支持“lamp”操作，则包含一个<request>子元素，该子元素的“action”属性设置为“lamp”，而“supported values”属性设置为所有支持的lamp ID。第14.5节中创建了一个注册表，以包含灯ID值。
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.
如果支持“启用摄影机”操作，则包含一个<request>子元素，该元素的“action”属性设置为“enable camera”，而“supported values”属性设置为所有支持的摄影机ID。第14.6节中创建了一个注册表，其中包含摄像机ID值。
<?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">
<?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>
<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>
</EmergencyCallData.Control>
Figure 9: <capabilities> Example
Figure 9: <capabilities> Example
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.
NG-ACN测试呼叫是一种在某种程度上被识别和处理为NG-ACN呼叫的呼叫，但未给予紧急呼叫处理，也未由PSAP呼叫接受者处理。测试NG-ACN呼叫的具体处理不在本文件范围内；通常，测试呼叫设施允许IVS、用户或TSP验证NG-ACN呼叫是否可以通过语音和/或其他媒体通信成功建立。IVS还可以验证是否成功接收到碰撞数据。
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.
本文档以[RFC8147]为基础，它继承了[RFC6881]第15节中使用测试调用功能的功能。以“test.”开头的服务URN表示测试调用。根据[RFC8147]，“urn:service:test.sos.ecall”用于测试NG-ACN调用。
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
MNO、应急机构、ESInets和PSAP处理请求“测试”服务URN的车辆呼叫，以便测试所需的功能，但这不在本文档的范围内。（一种可能性是，MNO将此类呼叫作为非紧急呼叫路由到ESInet，ESInet将其路由到支持NG-ACN呼叫的PSAP；PSAP接受测试呼叫，发送崩溃数据确认，以及
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].)
除了根据[RFC6881]支持媒体环回外，还播放音频剪辑（例如，说呼叫到达了适当的PSAP，车辆数据已成功处理）
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).
请注意，由于测试调用是使用“测试”作为父服务URN和“sos”作为子服务URN进行的，因此此类调用不会被视为紧急调用，因此某些功能可能不适用（例如，对于缺少服务的设备（“非服务初始化”（NSI）设备），如果这些设备可用于紧急调用）。
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.)
图10显示了NG-ACN呼叫启动。车辆使用MNO发起NG-ACN呼叫。与任何紧急呼叫一样，MNO将呼叫路由到ESInet。ESInet将呼叫路由到适当的支持NG-ACN的PSAP（使用位置信息和它是NG-ACN呼叫的事实）。呼叫由紧急服务路由代理（ESRP）处理，作为ESInet的入口点。ESRP将呼叫路由到适当的支持NG ACN的PSAP，由呼叫接受者处理呼叫。（在没有ESInet的部署中，MNO本身会将呼叫直接路由到适当的支持NG ACN的PSAP。）
+---------------------------------------+
| |
+------------+ | +-------+ |
| | | | PSAP2 | |
| | | +-------+ |
| Originating| | |
| Mobile | | +------+ +----------------------+ |
Vehicle-->| Network |--|->| ESRP |--->| PSAP1 --> Call Taker | |
| | | +------+ +----------------------+ |
| | | |
+------------+ | +-------+ |
| | PSAP3 | |
| +-------+ |
| |
| |
| |
| ESInet |
+---------------------------------------+
+---------------------------------------+
| |
+------------+ | +-------+ |
| | | | PSAP2 | |
| | | +-------+ |
| Originating| | |
| Mobile | | +------+ +----------------------+ |
Vehicle-->| Network |--|->| ESRP |--->| PSAP1 --> Call Taker | |
| | | +------+ +----------------------+ |
| | | |
+------------+ | +-------+ |
| | PSAP3 | |
| +-------+ |
| |
| |
| |
| ESInet |
+---------------------------------------+
Figure 10: Example Call Initiation
图10：调用启动示例
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/
图11展示了一个由IVS生成的SIP紧急呼叫邀请请求示例。它包括具有车辆确定位置信息的PIDF-LO、具有碰撞数据的VEDS块和元数据/
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.
具有数据功能的控制块。INVITE有一个包含urn:service:sos.ecall.automatic service urn的请求URI。为简洁起见，示例VEDS块不显示VEDS位置信息，尽管通常会显示。
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").
示例VEDS数据结构显示了关于坠毁车辆的信息。该示例说明该车为2015年款萨博9-5（不存在）。碰撞导致前安全气囊展开。<VehicleBodyCategoryCode>表示碰撞车辆为乘用车（代码设置为“101”）且不是敞篷车（<ConvertibleIndicator>值设置为“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.
<VehicleCrashPulse>元素提供了有关碰撞的进一步信息，即基于碰撞脉冲持续时间内速度变化的碰撞力为100 MPH。碰撞力的主方向设置为“12”（指12点钟，对应于正面碰撞）。此值位于<CrashPulsePrincipalDirectionOfForceValue>元素中。
The <CrashPulseRolloverQuarterTurnsValue> indicates the number of quarter turns in concert with a rollover expressed as a number; in our case 1.
<CrashPulseRolloverQuarterTurnsValue>表示与以数字表示的侧翻一致的四分之一圈数；在我们的案例1中。
No roll bar was deployed, as indicated in <VehicleRollbarDeployedIndicator> being set to "false".
未展开防滚翻杆，如<VehiclerRollbardeployedIndicator>设置为“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).
接下来，将显示指示车辆中各个座椅位置的安全带和座椅传感器数据的信息。在我们的示例中，来自驾驶员座椅的信息（<VehicleSeatLocationCategoryCode>元素中的值“1”）显示安全带受到监控（<VehicleSeatbeltMonitoredIndicator>元素），安全带已系紧（<VehicleSeatBeltFasteedIndicator>元素），并且座椅传感器确定座椅已被占用（<VehicleSeatOccupiedIndicator>元素）。
The weight of the vehicle when empty is listed as 600 kilograms in our example.
在我们的示例中，车辆空载时的重量列为600千克。
The <SevereInjuryIndicator> element is set to "true", indicating a likelihood that a vehicle occupant has suffered a severe injury requiring immediate trauma care.
<SevereInjuryIndicator>元素设置为“true”，表示车辆乘员可能遭受严重伤害，需要立即进行创伤护理。
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
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
indication that no parts of the vehicle are currently detected as being on fire (the <VehicleFireIndicator> element).
表示当前未检测到车辆部件着火的指示（<VehicleFireIndicator>元素）。
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: ...
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
--boundary1
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here
…会话描述协议（SDP）位于此处
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
--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>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="sip:+13145551111@example.com">
<dm:device id="123">
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
<dyn:Dynamic>
<dyn:heading>278</dyn:heading>
<dyn:direction></dyn:direction>
</dyn:Dynamic>
</gp:location-info>
<gp:usage-rules/>
<method>gps</method>
</gp:geopriv>
<timestamp>2012-04-5T10:18:29Z</timestamp>
<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
</dm:device>
</presence>
<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
--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">
<?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">
<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">
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>
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
--boundary1
Content-Type: application/EmergencyCallData.Control+xml
Content-ID: <1234567892@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?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">
<?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>
<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>
</EmergencyCallData.Control>
--boundary1--
--边界1--
Figure 11: SIP INVITE for a Vehicle-Initiated Emergency Call
图11：车辆启动紧急呼叫的SIP邀请
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.
由于本文档依赖于[RFC8147]和[RFC7852]，因此这些规范中描述的安全注意事项适用于此处。[RFC5069]的安全注意事项也适用。提醒实施者阅读并理解这些文档中的讨论。
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.
在紧急服务系统中，如果位置数据是在终端主机的协助下提供或确定的，则可能是故意（例如，在针对紧急服务基础设施的拒绝服务攻击中）或由于设备故障而导致位置不正确。读者可参考[RFC7378]了解其中一些漏洞的讨论。
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
除了[RFC8147]中针对元数据/控制对象的安全注意事项讨论外，请注意，车辆可能会拒绝执行任何请求的操作（例如，如果车辆需要但无法验证用于签署请求的证书）。车辆可使用原因注册表中的任何值来说明其未采取行动的原因（例如，通用“无法”或更具体的“安全故障”）。由于某些行动比其他行动具有更多的潜在风险（例如，解锁车门与闪光灯），车辆政策可能会拒绝执行某些请求
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).
某些情况（例如，在执行车辆启动的紧急呼叫中收到的此类请求时，拒绝解锁车门的请求、发送更新的VEDS或启用车辆终止呼叫中接收到的摄像头）。
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.
由于本文档以[RFC8147]为基础，而[RFC8147]本身以[RFC7852]为基础，因此此处指定的数据结构以及此处讨论的相应隐私注意事项也适用于此处。VEDS数据结构包含可选元素，可携带识别信息和个人信息，包括有关车辆和车主的信息以及位置信息，因此需要对其进行保护，防止未经授权的泄露，如[RFC7852]所述。当地法规可能会提出额外的隐私保护要求。
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).
本文档启用的附加功能（如访问车辆摄像头流）带来了保护负担，因此实施时需要小心，仅在紧急呼叫或紧急服务提供商的情况下提供访问（例如，通过验证摄像头访问请求是否由应急服务登记员签发的证书签署）。
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.
本文档注册application/EmergencyCallData.VEDS+XMLMIME媒体类型，并将“VEDS”添加到“紧急呼叫数据类型”注册表中。本文档在[RFC8147]中创建的“紧急呼叫元数据/控制数据”注册表中添加并创建子注册表。此外，本文档还注册了一个新的信息包。
14.1. MIME Media Type Registration for application/ EmergencyCall.VEDS+xml
14.1. 应用程序/emergencyccall.VEDS+xml的MIME媒体类型注册
IANA has registered a new MIME media type according to the procedures of [RFC6838] and guidelines in [RFC7303].
IANA已根据[RFC6838]的程序和[RFC7303]中的指南注册了新的MIME媒体类型。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: EmergencyCallData.VEDS+xml
MIME子类型名称：EmergencyCallData.VEDS+xml
Mandatory parameters: none
强制参数：无
Optional parameters: charset Indicates the character encoding of enclosed XML.
可选参数：字符集表示封闭XML的字符编码。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See Section 3.2 of RFC 7303 [RFC7303].
编码注意事项：使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 7303[RFC7303]第3.2节。
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.
这些数据可能包含个人信息，包括车辆VIN、位置、方向等。需要采取适当的预防措施，以限制未经授权的访问、不适当地向第三方披露以及窃听这些信息。有关更多信息，请参阅[RFC7852]第9节和第10节。
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.)
当此媒体类型包含在签名或加密的主体部分中时，封装的多部分（例如，多部分/签名或多部分/加密）与数据部分具有相同的内容ID。这允许实体识别和访问它感兴趣的数据块，而不必深入研究消息结构或解密它不感兴趣的部分。（Call Info标头字段中的“purpose”参数标识数据，CID URL指向正文中的数据块，该数据块具有匹配的内容ID正文部分标头字段。）
Interoperability considerations: None
互操作性注意事项：无
Published specification: [VEDS]
已发布规范：[VEDS]
Applications which use this media type: Emergency Services
使用此媒体类型的应用程序：紧急服务
Additional information: None
其他信息：无
Magic Number: None
神奇数字：无
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: TEXT
Macintosh文件类型代码：文本
Persons and email addresses for further information:
Randall Gellens, rg+ietf@randy.pensive.org;
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Persons and email addresses for further information:
Randall Gellens, rg+ietf@randy.pensive.org;
Hannes Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE
预期用途：有限用途
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
作者：本规范是IETF ECRIT工作组的一个工作项，具有邮件列表地址<ecrit@ietf.org>.
Change controller: The IESG <ietf@ietf.org>
Change controller: The IESG <ietf@ietf.org>
14.2. Registration of the "VEDS" Entry in the Emergency Call Data Types Registry
14.2. 在紧急呼叫数据类型注册表中注册“VEDS”条目
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].
IANA已将“VEDS”添加到“紧急呼叫数据类型”注册表中，并参考了本文件；“数据关于”值是“调用”。[RFC7852]建立了“紧急呼叫数据类型”注册表。
This document adds new values for the "action" attribute of the <request> element in the "Emergency Call Action" registry created by [RFC8147].
本文档为[RFC8147]创建的“紧急呼叫操作”注册表中<request>元素的“action”属性添加了新值。
+---------------+-------------------------+
| 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 |
+---------------+-------------------------+
+---------------+-------------------------+
| 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
表1：紧急呼叫操作注册表新值
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.
本文档在[RFC8147]建立的“紧急呼叫元数据/控制数据”注册表中创建了一个名为“紧急呼叫静态消息”的新子注册表。由于合规车辆预计将支持翻译成车辆支持的所有语言的所有静态消息，因此限制此类消息的数量非常重要。如[RFC5226]中所定义，该注册中心在“所需规范”下运行，该规范要求一份稳定的公共文件，并意味着对出版物进行专家审查。专家应确定该文件已由适当的应急服务组织（如NENA、EENA或APCO）或IETF发布，并由应急服务组织提供输入，且建议的信息与其他信息充分区分。
The contents of this registry are:
本登记册的内容包括：
ID: An integer identifier to be used in the "int-id" attribute of a metadata/control <request> element.
ID：在元数据/控件<request>元素的“int ID”属性中使用的整数标识符。
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.
当新消息添加到注册表时，消息文本由注册人确定；IANA分配ID。每个消息都分配了一个连续的整数值作为其ID。这允许IVS通过单个整数值指示它支持所有具有该值或更低值的消息。保留值0；可用消息以1开头。
The initial set of values is listed in Table 2.
表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. |
+----+--------------------------------------------------------------+
+----+--------------------------------------------------------------+
| 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
表2：紧急呼叫静态消息注册表初始值
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.
本文件在[RFC8147]建立的“紧急呼叫元数据/控制数据”注册表中创建了一个名为“紧急呼叫车辆灯ID”的新子注册表。这个新的子注册表唯一标识了汽车车灯（车灯）的名称。根据[RFC5226]中的定义，该登记处按照“专家审查”规则运作。专家应确定建议的灯具名称清晰易懂，并与其他灯具名称充分区分。
The contents of this registry are:
本登记册的内容包括：
Name: The identifier to be used in the "element-id" attribute of a metadata/control <request> element.
名称：元数据/控件<request>元素的“元素id”属性中使用的标识符。
Description: A description of the lamp (light).
说明：灯（灯）的说明。
The initial set of values is listed in Table 3.
表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 |
+----------------+---------------------------------------------+
+----------------+---------------------------------------------+
| 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
表3：紧急呼叫灯ID注册表初始值
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.
本文件在[RFC8147]建立的“紧急呼叫元数据/控制数据”注册表中创建了一个名为“紧急呼叫车辆摄像头ID”的新子注册表。这个新的子注册表唯一标识汽车摄像头。根据[RFC5226]中的定义，该登记处按照“专家审查”规则运作。专家应确定建议的摄像机名称清晰易懂，并与其他摄像机名称充分区分。
The contents of this registry are:
本登记册的内容包括：
Name: The identifier to be used in the "element-id" attribute of a control <request> element.
名称：控件<request>元素的“元素id”属性中使用的标识符。
Description: A description of the camera.
描述：摄像机的描述。
The initial set of values is listed in Table 4.
表4列出了初始值集。
+-------------+-----------------------------------------------------+
| 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 |
+-------------+-----------------------------------------------------+
+-------------+-----------------------------------------------------+
| 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
Table 4: Emergency Call Vehicle Camera IDs Registry Initial Valuestranslate error, please retry
This document registers the EmergencyCallData.VEDS INFO package in the "Info Packages Registry".
本文档在“信息包注册表”中注册EmergencyCallData.VEDS信息包。
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.
两个端点（IVS和PSAP设备）都按照[RFC6086]在Recv信息头字段中包含“EmergencyCallData.VEDS”，以指示接收承载此处所述数据的SIP信息消息的能力。
Support for the EmergencyCallData.VEDS INFO package indicates the ability to receive NG-ACN-related body parts as specified in this document.
对EmergencyCallData.VEDS信息包的支持表明能够接收本文件中规定的与NG ACN相关的身体部位。
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].
根据[RFC6086]，承载与本文档所述紧急呼叫相关数据的SIP信息请求消息的信息包头字段设置为“EmergencyCallData.VEDS”。
The requirements of Section 10 of [RFC6086] are addressed in the following sections.
[RFC6086]第10节的要求在以下章节中说明。
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.
本节介绍与信息包相关联的信息请求中携带的信息类型，以及用户代理（UAs）可以使用信息包的应用程序和功能类型。
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.
与EmergencyCallData.VEDS信息包相关的SIP信息请求包含与本文档中定义的紧急呼叫相关的数据。该应用程序是使用SIP建立的车辆启动紧急呼叫。该功能用于在车辆和PSAP之间传输车辆数据和元数据/控制信息。
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
SIP INFO方法的使用基于对INFO方法与其他方法（包括SIP消息方法、SIP选项方法、SIP重新邀请方法、媒体平面传输和非SIP协议）的意图和效果的需求分析。特别是，根据第7节，紧急呼叫数据块的传输发生在SIP紧急对话中，通常在初始INVITE请求及其响应中进行；仅当紧急呼叫相关数据需要在呼叫中发送时，才会使用INFO方法。而SIP消息方法可以是
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.
使用时，它不会像INFO方法那样绑定到SIP对话框，因此可能不会与该对话框关联。也可以使用SIP选项或REINVITE方法，但它们被视为不如INFO方法干净。SIP SUBSCRIBE/NOTIFY方法可以强制进入服务，但语义不太合适，例如，SUBSCRIBE/NOTIFY机制提供单向通信，包括从通知程序到订阅者的（通常是多个）通知，指示通知程序中发生了某些事件，然而，这里需要的是与紧急对话框相关的数据的双向通信。媒体平面机制的使用被打折了，因为对话框中需要交换的消息数量通常为零或很少，并且数据的大小也非常小。用户平面设置（例如，使用消息会话中继协议（MSRP）作为传输）所造成的开销将不成比例地大。
Based on the analyses, the SIP INFO method was chosen to provide for mid-call data transport.
基于这些分析，选择SIP INFO方法来提供中间呼叫数据传输。
The INFO package name is EmergencyCallData.VEDS.
信息包名称为EmergencyCallData.VEDS。
None
没有一个
None
没有一个
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.
EmergencyCallData.VEDS信息包的主体是一个多部分主体，包含零个或一个应用程序/EmergencyCallData.VEDS+xml部分（包含一个VEDS数据块）、零个或多个应用程序/EmergencyCallData.Control+xml部分（包含元数据/控制对象）以及零个或一个应用程序/EmergencyCallData.eCall.MSD部分（包含MSD）。预期至少有一个VEDS、MSD或元数据/控制主体部分；未定义接收SIP INFO请求时的行为。
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".
根据[RFC6086]发送车身部件；此外，为了与这些正文部分在非信息消息中的发送方式保持一致，SIP消息顶层的Call INFO header字段引用了每个关联的正文部分。正文部分的内容处置标题字段设置为“按引用”。
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".
VEDS、元数据/控制块或MSD始终包含在多部分正文部分中（即使它是SIP消息中唯一的正文部分）。仅包含与信息包关联的身体部位的最外层多部分的内容处置值为“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).
呼叫路径中的服务提供商不希望向SIP INFO请求添加额外的数据[RFC7852]（与初始INVITE请求一样）。
Usage is limited to vehicle-initiated emergency calls as defined in this document.
使用仅限于本文件中定义的车辆启动的紧急呼叫。
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).
SIP INFO请求在已建立的紧急呼叫对话框中用于发送请求、更新数据或确认。由于请求通常仅在PSAP呼叫接受者（怀疑车辆状态的某些方面已更改）手动操作时发送，并且更新的数据仅在先前发送的数据的某个方面已更改时发送，因此与EmergencyCallData.VEDS信息包相关联的SIP信息请求的速率通常非常低（大多数对话框可能不包含SIP信息请求，而其他对话框可能偶尔包含一个请求）。
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.
使用此信息包可以携带的数据块的MIME媒体类型注册包含对特定于该数据块的安全和/或隐私注意事项的讨论。有关车辆启动紧急呼叫中所携带数据的安全和隐私注意事项的信息，请参见第12节和第13节。
See Sections 7 and 8 for protocol details.
协议详情见第7节和第8节。
See Section 11 for protocol examples.
协议示例见第11节。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<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>.
[RFC6086]Holmberg，C.，Burger，E.，和H.Kaplan，“会话启动协议（SIP）信息方法和包框架”，RFC 6086，DOI 10.17487/RFC6086，2011年1月<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>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<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>.
[RFC6881]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务最佳现行实践”，BCP 181，RFC 6881，DOI 10.17487/RFC6881，2013年3月<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>.
[RFC7303]Thompson，H.和C.Lilley，“XML媒体类型”，RFC 7303，DOI 10.17487/RFC7303，2014年7月<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>.
[RFC7852]Gellens，R.，Rosen，B.，Tschofenig，H.，Marshall，R.，和J.Winterbottom，“与紧急呼叫相关的附加数据”，RFC 7852，DOI 10.17487/RFC7852，2016年7月<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>.
[RFC8147]Gellens，R.和H.Tschofenig，“下一代泛欧eCall”，RFC 8147，DOI 10.17487/RFC8147，2017年5月<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>.
[VEDS]APCO国际，“车辆应急数据集（VEDS）”，版本3.0，由高级自动碰撞通知（AACN）APCO/NENA联合数据标准化工作组编制，2012年2月<https://www.apcointl.org/ 参考资料/telematics/aacn和veds.html>。
[Bluetooth] Bluetooth Special Interest Group (SIG), "Bluetooth Specifications", <https://www.bluetooth.com/ specifications>.
[蓝牙]蓝牙特别兴趣小组（SIG），“蓝牙规范”<https://www.bluetooth.com/ 规格>。
[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>.
[RFC5012]Schulzrinne，H.和R.Marshall，Ed.，“利用互联网技术解决紧急情况的要求”，RFC 5012，DOI 10.17487/RFC5012，2008年1月<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>.
[RFC5069]Taylor，T.，Ed.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，DOI 10.17487/RFC5069，2008年1月<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>.
[RFC6443]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，RFC 6443，DOI 10.17487/RFC6443，2011年12月<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>.
[RFC7378]Tschofenig，H.，Schulzrinne，H.，和B.Aboba，Ed.，“值得信赖的位置”，RFC 7378，DOI 10.17487/RFC7378，2014年12月<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-2008]国家伤害预防和控制中心，“专家小组的建议：高级自动碰撞通知和受伤患者的分类”，疾病控制和预防中心，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>.
[triage-2011]国家伤害预防和控制中心，“受伤患者现场分流指南：国家现场分流专家组的建议”，疾病控制和预防中心，2012年1月<https://www.cdc.gov/mmwr/preview/mmwrhtml/ rr6101a1.htm>。
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.
我们要感谢莉娜·查蓬涅尔、艾莉莎·库珀、斯蒂芬·埃奇、克里斯特·霍姆伯格、艾莉森·曼金和丹·罗马斯坎努的评论和建议；Robert Sparks和Paul Kyzivat对SIP机制的帮助；Michael Montag、Arnoud van Wijk、Ban Al-Bakri、Wes George、Gunnar Hellstrom和Rex Buddenberg的反馈；以及Ulrich Dietz对原始文件初稿的帮助，该初稿后来演变为本文件。
Authors' Addresses
作者地址
Randall Gellens Core Technology Consulting
Randall Gellens核心技术咨询公司
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com
Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 United States of America
Brian Rosen NeuStar，Inc.美国宾夕法尼亚州康拉德·马尔斯博士，邮编：16046
Email: br@brianrosen.net
Email: br@brianrosen.net
Hannes Tschofenig Individual
Hannes Tschofenig个人
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at