Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 8147 Core Technology Consulting
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Individual
May 2017
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 8147 Core Technology Consulting
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Individual
May 2017
Next-Generation Pan-European eCall
下一代泛欧eCall
Abstract
摘要
This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in-vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.
本文件描述了如何使用基于IP的紧急服务机制来支持欧盟委员会eSafety倡议（通常称为“eCall”）下定义的下一代泛欧车载紧急呼叫服务。eCall是一个标准化的强制性系统，用于车辆发出的特殊形式的紧急呼叫，提供实时通信和一组集成的相关数据。
This document also registers MIME media types and an Emergency Call Data Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.
本文档还注册了eCall车辆数据和元数据/控制数据的MIME媒体类型和紧急呼叫数据类型，以及一个信息包，以便能够在SIP INFO请求中携带此数据。
Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.
尽管本规范旨在满足下一代泛欧eCall（NG eCall）的要求，但其一般规定使该技术可以重复使用或扩展，以适应不同司法管辖区的要求。
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/rfc8147.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8147.
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 . . . . . . . . . . . . . . . . . . . . . . . 6
4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 7
5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7
7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 11
9.1. The Control Block . . . . . . . . . . . . . . . . . . . . 13
9.1.1. The <ack> Element . . . . . . . . . . . . . . . . . . 14
9.1.1.1. Attributes of the <ack> Element . . . . . . . . . 14
9.1.1.2. Child Element of the <ack> Element . . . . . . . 15
9.1.1.3. Example of the <ack> Element . . . . . . . . . . 16
9.1.2. The <capabilities> Element . . . . . . . . . . . . . 16
9.1.2.1. Child Element of the <capabilities> Element . . . 16
9.1.2.2. Example of the <capabilities> Element . . . . . . 17
9.1.3. The <request> Element . . . . . . . . . . . . . . . . 17
9.1.3.1. Attributes of the <request> Element . . . . . . . 17
9.1.3.2. Child Element of the <request> Element . . . . . 19
9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14.1. The EmergencyCallData Media Subtree . . . . . . . . . . 30
14.2. Service URN Registrations . . . . . . . . . . . . . . . 31
14.3. MIME Media Type Registration for
application/EmergencyCallData.eCall.MSD . . . . . . . . 31
14.4. MIME Media Type Registration for
application/EmergencyCallData.Control+xml . . . . . . . 32
14.5. Registration of the "eCall.MSD" Entry in the Emergency
Call Data Types Registry . . . . . . . . . . . . . . . . 34
14.6. Registration of the "Control" Entry in the Emergency
Call Data Types Registry . . . . . . . . . . . . . . . . 34
14.7. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:control . . . . 34
14.8. Registry Creation . . . . . . . . . . . . . . . . . . . 35
14.8.1. Emergency Call Actions Registry . . . . . . . . . . 35
14.8.2. Emergency Call Action Failure Reasons Registry . . . 36
14.9. The EmergencyCallData.eCall.MSD INFO Package . . . . . . 37
14.9.1. Overall Description . . . . . . . . . . . . . . . . 37
14.9.2. Applicability . . . . . . . . . . . . . . . . . . . 37
14.9.3. INFO Package Name . . . . . . . . . . . . . . . . . 38
14.9.4. INFO Package Parameters . . . . . . . . . . . . . . 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 6
4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 7
5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 7
7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. The Metadata/Control Object . . . . . . . . . . . . . . . . . 11
9.1. The Control Block . . . . . . . . . . . . . . . . . . . . 13
9.1.1. The <ack> Element . . . . . . . . . . . . . . . . . . 14
9.1.1.1. Attributes of the <ack> Element . . . . . . . . . 14
9.1.1.2. Child Element of the <ack> Element . . . . . . . 15
9.1.1.3. Example of the <ack> Element . . . . . . . . . . 16
9.1.2. The <capabilities> Element . . . . . . . . . . . . . 16
9.1.2.1. Child Element of the <capabilities> Element . . . 16
9.1.2.2. Example of the <capabilities> Element . . . . . . 17
9.1.3. The <request> Element . . . . . . . . . . . . . . . . 17
9.1.3.1. Attributes of the <request> Element . . . . . . . 17
9.1.3.2. Child Element of the <request> Element . . . . . 19
9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14.1. The EmergencyCallData Media Subtree . . . . . . . . . . 30
14.2. Service URN Registrations . . . . . . . . . . . . . . . 31
14.3. MIME Media Type Registration for
application/EmergencyCallData.eCall.MSD . . . . . . . . 31
14.4. MIME Media Type Registration for
application/EmergencyCallData.Control+xml . . . . . . . 32
14.5. Registration of the "eCall.MSD" Entry in the Emergency
Call Data Types Registry . . . . . . . . . . . . . . . . 34
14.6. Registration of the "Control" Entry in the Emergency
Call Data Types Registry . . . . . . . . . . . . . . . . 34
14.7. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:control . . . . 34
14.8. Registry Creation . . . . . . . . . . . . . . . . . . . 35
14.8.1. Emergency Call Actions Registry . . . . . . . . . . 35
14.8.2. Emergency Call Action Failure Reasons Registry . . . 36
14.9. The EmergencyCallData.eCall.MSD INFO Package . . . . . . 37
14.9.1. Overall Description . . . . . . . . . . . . . . . . 37
14.9.2. Applicability . . . . . . . . . . . . . . . . . . . 37
14.9.3. INFO Package Name . . . . . . . . . . . . . . . . . 38
14.9.4. INFO Package Parameters . . . . . . . . . . . . . . 38
14.9.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 38
14.9.6. INFO Request Body Parts . . . . . . . . . . . . . . 38
14.9.7. INFO Package Usage Restrictions . . . . . . . . . . 39
14.9.8. Rate of INFO Requests . . . . . . . . . . . . . . . 39
14.9.9. INFO Package Security Considerations . . . . . . . . 39
14.9.10. Implementation Details . . . . . . . . . . . . . . . 39
14.9.11. Examples . . . . . . . . . . . . . . . . . . . . . . 39
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Normative References . . . . . . . . . . . . . . . . . . 40
15.2. Informative references . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
14.9.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . 38
14.9.6. INFO Request Body Parts . . . . . . . . . . . . . . 38
14.9.7. INFO Package Usage Restrictions . . . . . . . . . . 39
14.9.8. Rate of INFO Requests . . . . . . . . . . . . . . . 39
14.9.9. INFO Package Security Considerations . . . . . . . . 39
14.9.10. Implementation Details . . . . . . . . . . . . . . . 39
14.9.11. Examples . . . . . . . . . . . . . . . . . . . . . . 39
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Normative References . . . . . . . . . . . . . . . . . . 40
15.2. Informative references . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
Emergency calls made from vehicles (e.g., in the event of a crash) assist in significantly reducing road deaths and injuries by allowing emergency services to be aware of the incident, the state (condition) of the vehicle, and the location of the vehicle and to have a voice communications channel with the vehicle occupants. This enables a quick and appropriate response.
车辆发出的紧急呼叫（例如，在发生碰撞的情况下）有助于显著减少道路伤亡，因为紧急服务可以了解事故、车辆状态（状况）和车辆位置，并与车辆乘员建立语音通信渠道。这可以实现快速和适当的响应。
The European Commission initiative of eCall was conceived in the late 1990s and has evolved to a European Parliament decision requiring the implementation of a compliant in-vehicle system (IVS) in new vehicles and the deployment of eCall in the European Member States in the very near future. Other regions are developing eCall-compatible systems.
eCall的欧盟委员会倡议是在20世纪90年代末构思的，并已演变为欧洲议会的一项决定，要求在新车中实施符合要求的车载系统（IVS），并在不久的将来在欧洲成员国部署eCall。其他地区正在开发eCall兼容系统。
The Pan-European eCall system is a standardized and mandated mechanism for emergency calls by vehicles, providing a voice channel and transmission of data. eCall establishes procedures for such calls to be placed by in-vehicle systems, recognized and processed by the mobile network, and routed to a specialized Public Safety Answering Point (PSAP) where the vehicle data is available to assist the call taker in assessing and responding to the situation. eCall provides a standard set of vehicle, sensor (e.g., crash-related), and location data.
泛欧eCall系统是车辆紧急呼叫的标准化强制机制，提供语音通道和数据传输。eCall建立了由车载系统拨打、由移动网络识别和处理、并路由至专用公共安全应答点（PSAP）的呼叫程序，在该点上，车辆数据可用于协助呼叫接受者评估和响应情况。eCall提供了一套标准的车辆、传感器（如与碰撞相关的）和位置数据。
An eCall can be either user initiated or automatically triggered. Automatically triggered eCalls indicate a car crash or some other serious incident. Manually triggered eCalls might be reports of witnessed crashes or serious hazards, a request for medical assistance, etc. PSAPs might apply specific operational handling to manual and automatic eCalls.
eCall可以由用户启动，也可以自动触发。自动触发的eCall表示发生车祸或其他严重事件。手动触发的eCall可能是目击碰撞或严重危险的报告、医疗援助请求等。PSAP可能对手动和自动eCall应用特定的操作处理。
Legacy eCall is standardized (by 3GPP [SDO-3GPP] and the European Committee for Standardization (CEN) [CEN]) as a 3GPP circuit-switched call over Global System for Mobile communications (GSM) (2G) or Universal Mobile Telecommunications System (UMTS) (3G). Flags in the call setup mark the call as an eCall and further indicate if the call was automatically or manually triggered. The call is routed to an eCall-capable PSAP, a voice channel is established between the vehicle and the PSAP, and an eCall in-band modem is used to carry a defined set of vehicle, sensor (e.g., crash-related), and location data (the Minimum Set of Data or MSD) within the voice channel. The same in-band mechanism is used for the PSAP to acknowledge successful receipt of the MSD and to request the vehicle to send a new MSD (e.g., to check if the state of or location of the vehicle or its occupants has changed). NG-eCall moves from circuit switched to all-IP and carries the vehicle data and eCall signaling as additional data carried with the call. This document describes how IETF mechanisms for IP-based emergency calls (including [RFC6443] and [RFC7852]) are used to provide the signaling and data exchange of the next generation of Pan-European eCall.
传统eCall被标准化（由3GPP[SDO-3GPP]和欧洲标准化委员会（CEN）[CEN]）作为3GPP电路交换呼叫全球移动通信系统（GSM）（2G）或通用移动通信系统（UMTS）（3G）。呼叫设置中的标志将呼叫标记为eCall，并进一步指示呼叫是自动触发还是手动触发的。呼叫路由至支持eCall的PSAP，在车辆和PSAP之间建立语音通道，并使用eCall带内调制解调器在语音通道内传送一组已定义的车辆、传感器（如碰撞相关）和位置数据（最小数据集或MSD）。PSAP使用相同的带内机制确认已成功接收MSD，并请求车辆发送新MSD（例如，检查车辆或其乘员的状态或位置是否已更改）。NG eCall从电路切换到全IP，并将车辆数据和eCall信令作为附加数据随呼叫一起传输。本文件描述了基于IP的紧急呼叫（包括[RFC6443]和[RFC7852]）的IETF机制如何用于提供下一代泛欧eCall的信令和数据交换。
The European Telecommunications Standards Institute (ETSI) [SDO-ETSI] has published a Technical Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] that presents findings and recommendations regarding support for eCall in an all-IP environment. The recommendations include the use of 3GPP Internet Multimedia System (IMS) emergency calling with additional elements identifying the call as an eCall and as carrying eCall data and mechanisms for carrying the data and eCall signaling. 3GPP IMS emergency services support multimedia, providing the ability to carry voice, text, and video. This capability is referred to within 3GPP as Multimedia Emergency Services (MMES).
欧洲电信标准协会（ETSI）[SDO-ETSI]发布了一份题为“移动标准组（MSG）；eCall for VoIP”[MSG_TR]的技术报告，其中介绍了在全IP环境中支持eCall的调查结果和建议。建议包括使用3GPP互联网多媒体系统（IMS）紧急呼叫，以及识别呼叫为eCall和承载eCall数据的附加元件，以及用于承载数据和eCall信令的机制。3GPP IMS紧急服务支持多媒体，提供承载语音、文本和视频的能力。这种能力在3GPP中称为多媒体紧急服务（MMES）。
A transition period will exist during which time the various entities involved in initiating and handling an eCall might support NG-eCall, legacy eCall, or both. The issues of migration and co-existence during the transition period are outside the scope of this document.
将存在一个过渡期，在此期间，参与发起和处理eCall的各种实体可能支持NG eCall、legacy eCall或两者。过渡时期的移徙和共存问题不在本文件的范围之内。
This document indicates how to use IP-based emergency services mechanisms to support NG-eCall.
本文件说明了如何使用基于IP的应急服务机制来支持NG eCall。
This document also registers MIME media types and Emergency Call Data Types for the eCall vehicle data (MSD) and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.
本文件还注册了eCall vehicle Data（MSD）和元数据/控制数据的MIME媒体类型和紧急呼叫数据类型，以及支持在SIP INFO请求中携带此数据的信息包。
The MSD is carried in the MIME type application/ EmergencyCallData.eCall.MSD and the metadata/control block is carried in the MIME type application/EmergencyCallData.Control+xml (both of which are registered in Section 14). An INFO package is defined (in
MSD在MIME类型的application/EmergencyCallData.eCall.MSD中携带，元数据/控制块在MIME类型的application/EmergencyCallData.control+xml中携带（两者都在第14节中注册）。定义了一个信息包（在
Section 14.9) to enable these MIME types to be carried in SIP INFO requests, per [RFC6086].
根据[RFC6086]，第14.9节）允许在SIP信息请求中携带这些MIME类型。
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].
本文件重复使用[RFC5012]第3节中定义的术语。
Additionally, we use the following abbreviations:
此外，我们使用以下缩写：
3GPP: 3rd Generation Partnership Project
3GPP：第三代合作伙伴项目
CEN: European Committee for Standardization
欧洲标准化委员会
EENA: European Emergency Number Association
欧洲紧急号码协会
ESInet: Emergency Services IP network
紧急服务IP网络
IMS: IP Multimedia Subsystem
IP多媒体子系统
IVS: In-Vehicle System
IVS：车载系统
MNO: Mobile Network Operator
移动网络运营商
MSD: Minimum Set of Data
MSD：最小数据集
PSAP: Public Safety Answering Point
公共安全回答点
This document is focused on the signaling, data exchange, and protocol needs of NG-eCall (also referred to as packet-switched eCall or all-IP eCall) within the SIP framework for emergency calls (as described in [RFC6443] and [RFC6881]). eCall itself is specified by 3GPP and CEN, and these specifications include far greater scope than is covered here.
本文件主要关注紧急呼叫SIP框架内NG eCall（也称为分组交换eCall或全IP eCall）的信令、数据交换和协议需求（如[RFC6443]和[RFC6881]所述）。eCall本身是由3GPP和CEN指定的，这些规范包含的范围远远大于本文所涵盖的范围。
The eCall service operates over cellular wireless communication, but this document does not address cellular-specific details, nor client domain selection (e.g., circuit-switched versus packet-switched). All such aspects are the purview of their respective standards bodies. The scope of this document is limited to eCall operating within a SIP-based environment (e.g., 3GPP IMS Emergency Calling [TS23.167]).
eCall服务在蜂窝无线通信上运行，但本文档未涉及蜂窝特定细节，也未涉及客户端域选择（例如，电路交换与分组交换）。所有这些方面都属于各自标准机构的权限。本文档的范围仅限于在基于SIP的环境中运行的eCall（例如，3GPP IMS紧急呼叫[TS23.167]）。
Although this specification is designed to meet the requirements of Pan-European NG-eCall, it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions (see, e.g., [RFC8148]), and extension points are provided to facilitate this.
尽管本规范旨在满足泛欧NG eCall的要求，但其一般性规定使得该技术可以重复使用或扩展，以适应不同司法管辖区的要求（例如，参见[RFC8148]），并提供扩展点以促进这一点。
Note that vehicles designed for multiple regions might need to support eCall and other Advanced Automatic Crash Notification (AACN) systems (such as described in [RFC8148]), but this is out of scope of this document.
请注意，为多个地区设计的车辆可能需要支持eCall和其他高级自动碰撞通知（AACN）系统（如[RFC8148]中所述），但这超出了本文档的范围。
eCall requirements are specified by CEN in [EN_16072] and by 3GPP in [TS22.101], Section 10.7 and Annex A.27, and [TS24.229], Section 4.7.6. Requirements specific to vehicle data are contained in EN 15722 [MSD].
eCall要求由CEN在[EN_16072]中规定，3GPP在[TS22.101]第10.7节和附录A.27中规定，以及[TS24.229]第4.7.6节中规定。特定于车辆数据的要求包含在EN 15722[MSD]中。
Pan-European eCall provides a standardized and mandated set of vehicle-related data (including VIN, vehicle type, propulsion type, current and optionally previous location coordinates, and the number of occupants) known as the Minimum Set of Data (MSD). CEN has specified this data in EN 15722 [MSD], along with both ASN.1 and XML encodings. Both circuit-switched eCall and this document use the ASN.1 PER encoding, which is specified in Annex A of EN 15722 [MSD] (the XML encoding specified in Annex C is not used in this document, per 3GPP [SDO-3GPP]).
泛欧eCall提供了一套标准化和强制性的车辆相关数据（包括VIN、车辆类型、推进类型、当前和可选先前位置坐标以及乘员数量），称为最小数据集（MSD）。CEN已在EN 15722[MSD]中指定了该数据以及ASN.1和XML编码。电路交换eCall和本文件均使用EN 15722[MSD]附录A中规定的ASN.1编码（根据3GPP[SDO-3GPP]，本文件未使用附录C中规定的XML编码）。
This document registers the application/EmergencyCallData.eCall.MSD MIME media type to enable the MSD to be carried in SIP. As an ASN.1 PER-encoded object, the data is binary and transported using binary content transfer encoding within SIP messages. This document also adds "eCall.MSD" to the "Emergency Call Data Types" registry to enable the MSD to be recognized as such in a SIP-based eCall emergency call. (See [RFC7852] for more information about the registry and how it is used.)
本文档注册application/EmergencyCallData.eCall.MSD MIME媒体类型，以使MSD能够在SIP中携带。作为每个编码对象的ASN.1，数据是二进制的，并在SIP消息中使用二进制内容传输编码进行传输。本文档还将“eCall.MSD”添加到“紧急呼叫数据类型”注册表中，以便在基于SIP的eCall紧急呼叫中识别MSD。（有关注册表及其使用方式的更多信息，请参阅[RFC7852]）
See Section 6 for a discussion of how the MSD vehicle data is conveyed in an NG-eCall.
有关如何在NG eCall中传输MSD车辆数据的讨论，请参见第6节。
[RFC7852] establishes a general mechanism for conveying blocks of data within a SIP emergency call. This document makes use of that mechanism to include vehicle data (the MSD; see Section 5) and metadata/control information (see Section 9) within SIP messages.
[RFC7852]建立了在SIP紧急呼叫中传输数据块的通用机制。本文件利用该机制将车辆数据（MSD；见第5节）和元数据/控制信息（见第9节）包含在SIP消息中。
This document also registers an INFO package (in Section 14.9) to enable eCall-related data blocks to be carried in SIP INFO requests (per [RFC6086], new INFO usages require the definition of an INFO package).
本文件还注册了一个信息包（见第14.9节），以便在SIP信息请求中携带eCall相关数据块（根据[RFC6086]，新的信息使用需要定义信息包）。
Note that if other data sets need to be transmitted in the future, the appropriate signaling mechanism for such data needs to be evaluated, including factors such as the size and frequency of such data.
注意，如果将来需要传输其他数据集，则需要评估此类数据的适当信令机制，包括诸如此类数据的大小和频率等因素。
An IVS transmits an MSD (see Section 5) by encoding it per Annex A of EN 15722 [MSD] and including it as a MIME body part within a SIP message per [RFC7852]. The body part is identified by its MIME media type (application/EmergencyCallData.eCall.MSD) 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 MSD 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 the eCall MSD per the entry in the "Emergency Call Data Types" registry; the "purpose" parameter's value is "EmergencyCallData.eCall.MSD". Per [RFC6086], an MSD is carried in a SIP INFO request by using the INFO package defined in Section 14.9.
An IVS transmits an MSD (see Section 5) by encoding it per Annex A of EN 15722 [MSD] and including it as a MIME body part within a SIP message per [RFC7852]. The body part is identified by its MIME media type (application/EmergencyCallData.eCall.MSD) 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 MSD 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 the eCall MSD per the entry in the "Emergency Call Data Types" registry; the "purpose" parameter's value is "EmergencyCallData.eCall.MSD". Per [RFC6086], an MSD is carried in a SIP INFO request by using the INFO package defined in Section 14.9.translate error, please retry
A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and including it within 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, which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object 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 CID URL referencing the body part's unique identifier and a "purpose" parameter identifying the data as an eCall metadata/control block per the entry in the "Emergency Call Data Types" registry; the "purpose" parameter's value is "EmergencyCallData.Control". Per [RFC6086], a metadata/control object is carried in a SIP INFO request by using the INFO package defined in Section 14.9.
PSAP或IVS通过按照本文档中的描述对元数据/控制对象进行编码，并按照[RFC7852]将其作为MIME正文部分包含在SIP消息中，从而传输元数据/控制对象（参见第9节）。主体部分在主体部分的内容类型头字段中由其MIME媒体类型（application/emergencyccalldata.Control+xml）标识。为主体部件分配了唯一标识符，该标识符列在主体部件的内容ID标题字段中。通过在SIP消息的顶层添加（或附加）呼叫信息头字段，SIP消息被标记为包含元数据/控制对象。此呼叫信息标题字段包含一个引用身体部位唯一标识符的CID URL和一个“目的”参数，该参数根据“紧急呼叫数据类型”注册表中的条目将数据标识为eCall元数据/控制块；“purpose”参数的值是“EmergencyCallData.Control”。根据[RFC6086]，通过使用第14.9节中定义的信息包，在SIP信息请求中携带元数据/控制对象。
An MSD or a metadata/control block is always enclosed in a multipart body part (even if it would otherwise be the only body part in the SIP message).
MSD或元数据/控制块始终包含在多部分正文部分中（即使它是SIP消息中唯一的正文部分）。
A body part containing an MSD or metadata/control object has a Content-Disposition header field value containing "By-Reference".
包含MSD或元数据/控件对象的主体部分具有包含“按引用”的内容处置标头字段值。
An IVS initiating an NG-eCall includes an MSD as a body part within the initial INVITE and optionally also includes a metadata/control object informing the PSAP of its capabilities as another body part. The MSD body part (and metadata/control and Presence Information Data Format Location Object (PIDF-LO) body parts, if included) have a Content-Disposition header field with the value "By-Reference; handling=optional". Specifying "handling=optional" prevents the SIP INVITE request 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 MSD (or metadata/control object or PIDF-LO).
发起NG eCall的IVS包括一个MSD作为初始INVITE中的主体部分，还可以选择包括一个元数据/控制对象，通知PSAP其作为另一主体部分的能力。MSD正文部分（以及元数据/控制和状态信息数据格式位置对象（PIDF-LO）正文部分，如果包括）有一个值为“By Reference；handling=optional”的内容处置标题字段。如果SIP INVITE请求由不理解MSD（或元数据/控制对象或PIDF-LO）的遗留元素（例如，SIP和电路交换环境之间的网关）处理，则指定“handling=optional”可防止SIP INVITE请求被拒绝。
The PSAP creates a metadata/control object acknowledging receipt of the MSD and includes it as a body part within the SIP final response to the SIP INVITE request per [RFC7852]. A metadata/control object is not included in provisional (e.g., 180) responses.
PSAP根据[RFC7852]创建元数据/控制对象，确认收到MSD，并将其作为SIP最终响应的主体部分包含在SIP INVITE请求中。元数据/控制对象不包括在临时（例如180）响应中。
A PSAP is able to reject a call while indicating that it is aware of the situation by including a metadata/control object acknowledging the MSD and containing "received=true" within a final response using SIP response code 600 (Busy Everywhere), 486 (Busy Here), or 603 (Decline), per [RFC7852].
PSAP能够拒绝呼叫，同时根据[RFC7852]，通过使用SIP响应代码600（到处忙）、486（这里忙）或603（拒绝），在最终响应中包含确认MSD并包含“received=true”的元数据/控制对象，指示其了解情况。
If the IVS receives an acknowledgment for an MSD containing "received=false", this indicates that the PSAP was unable to properly decode or process the MSD. The IVS action is not defined (e.g., it might only log an error). Since the PSAP is able to request an updated MSD during the call, if an initial MSD is unsatisfactory in any way, the PSAP can choose to request another one.
如果IVS收到包含“received=false”的MSD确认，则表明PSAP无法正确解码或处理MSD。未定义IVS操作（例如，它可能只记录错误）。由于PSAP可以在呼叫期间请求更新的MSD，因此如果初始MSD在任何方面都不令人满意，PSAP可以选择请求另一个MSD。
A PSAP can request that the vehicle send an updated MSD during a call (e.g., upon manual request of the PSAP call taker who suspects the vehicle state may have changed). To do so, the PSAP creates a metadata/control object requesting an MSD and includes it within a SIP INFO request sent within the dialog. The IVS then includes an updated MSD within a SIP INFO request and sends it within the dialog. If the IVS is unable to send an MSD, it instead sends a metadata/ control object acknowledging the request, containing an <actionResult> element with a "success" parameter set to "false" and a "reason" parameter (and optionally a "details" parameter) indicating why the request could not be accomplished. Per [RFC6086], metadata/control objects and MSDs are sent using the INFO package defined in Section 14.9. In addition, to align with how an MSD or metadata/control block is transmitted in a SIP message other than an INFO request, a Call-Info header field is included in the SIP INFO
PSAP可以请求车辆在呼叫期间发送更新的MSD（例如，根据怀疑车辆状态可能已改变的PSAP呼叫接受者的手动请求）。为此，PSAP创建一个元数据/控制对象，请求MSD，并将其包含在对话框中发送的SIP INFO请求中。然后，IVS在SIP INFO请求中包含更新的MSD，并在对话框中发送。如果IVS无法发送MSD，它会发送一个元数据/控制对象来确认请求，其中包含一个<actionResult>元素，该元素的“success”参数设置为“false”，并包含一个“reason”参数（可选的还有一个“details”参数），指示请求无法完成的原因。根据[RFC6086]，元数据/控制对象和MSD使用第14.9节中定义的信息包发送。此外，为了与MSD或元数据/控制块在SIP消息（而非INFO请求）中的传输方式保持一致，SIP INFO中包括Call INFO header字段
request to reference the MSD or metadata/control block per [RFC7852]. See Section 14.9 for information about the use of SIP INFO requests to carry data within an eCall.
根据[RFC7852]请求参考MSD或元数据/控制块。有关使用SIP INFO请求在eCall中传输数据的信息，请参见第14.9节。
The IVS is not expected to send an unsolicited MSD after the initial INVITE.
初始邀请后，IVS不会主动发送MSD。
This document does not mandate support for the data blocks defined in [RFC7852].
本文件不强制要求支持[RFC7852]中定义的数据块。
In a circuit-switched eCall, the IVS places a special form of a 112 emergency call, which carries an eCall flag (indicating that the call is an eCall and also if the call was manually or automatically triggered); the mobile network operator (MNO) recognizes the eCall flag and routes the call to an eCall-capable PSAP, and vehicle data is transmitted to the PSAP via the eCall in-band modem (in the voice channel).
在电路交换eCall中，IVS放置一种特殊形式的112紧急呼叫，带有eCall标志（指示呼叫是eCall，以及呼叫是手动或自动触发的）；移动网络运营商（MNO）识别eCall标志并将呼叫路由到支持eCall的PSAP，车辆数据通过eCall带内调制解调器（在语音信道中）传输到PSAP。
///-----\\\ 112 voice call with eCall flag +------+
||| IVS |||---------------------------------------->| PSAP |
\\\-----/// vehicle data via eCall in-band modem +------+
///-----\\\ 112 voice call with eCall flag +------+
||| IVS |||---------------------------------------->| PSAP |
\\\-----/// vehicle data via eCall in-band modem +------+
Figure 1: Circuit-Switched eCall
图1：电路交换eCall
For NG-eCall, the IVS establishes an emergency call using a Request-URI indicating a manual or automatic eCall; the MNO (or ESInet) recognizes the eCall URN and routes the call to an NG-eCall-capable PSAP; and the PSAP interprets the vehicle data sent with the call and makes it available to the call taker.
对于NG eCall，IVS使用指示手动或自动eCall的请求URI建立紧急呼叫；MNO（或ESInet）识别eCall URN并将呼叫路由到支持NG eCall的PSAP；PSAP将解释随呼叫发送的车辆数据，并将其提供给呼叫接受者。
///-----\\\ IMS emergency call with eCall URN +------+
||| IVS |||---------------------------------------->| PSAP |
\\\-----/// vehicle data included in call setup +------+
///-----\\\ IMS emergency call with eCall URN +------+
||| IVS |||---------------------------------------->| PSAP |
\\\-----/// vehicle data included in call setup +------+
Figure 2: NG-eCall
图2:NG eCall
See Section 6 for information on how the MSD is transported within an NG-eCall.
有关如何在NG eCall内运输MSD的信息，请参见第6节。
This document adds new service URN children within the "sos" subservice. These URNs provide the mechanism by which an eCall is identified and differentiate between manually and automatically triggered eCalls (which might be subject to different treatment, depending on policy). The two service URNs are: urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual, which request resources associated with an emergency call placed by
本文档在“sos”子服务中添加了新的服务URN子服务。这些URN提供了识别eCall的机制，并区分手动和自动触发的eCall（根据策略，可能会受到不同的处理）。这两个服务urn是：urn:service:sos.ecall.automatic和urn:service:sos.ecall.manual，它们请求与用户发出的紧急呼叫相关的资源
an in-vehicle system, carrying a standardized set of data related to the vehicle and incident. These are registered in Section 14.2.
车载系统，携带与车辆和事件相关的标准化数据集。这些记录在第14.2节中。
Call routing is outside the scope of this document.
呼叫路由不在本文档的范围内。
eCall requires the ability to place test calls (see [TS22.101], clause 10.7 and [EN_16062], clause 7.2.2). These are calls that are recognized and treated to some extent as eCalls but are not given emergency call treatment and are not handled by call takers. The specific handling of test eCalls is outside the scope of this document; typically, the test call facility allows the IVS or user to verify that an eCall can be successfully established with voice communication. The IVS might also be able to verify that the MSD was successfully received.
eCall要求能够进行测试调用（见[TS22.101]第10.7条和[EN_16062]第7.2.2条）。这些电话在一定程度上被视为eCall，但未进行紧急呼叫处理，也未由呼叫接受者处理。测试eCall的具体处理不在本文件范围内；通常，测试呼叫设施允许IVS或用户验证是否可以通过语音通信成功建立eCall。IVS还可以验证MSD是否已成功接收。
A service URN starting with "test." indicates a test call. For eCall, "urn:service:test.sos.ecall" indicates such a test feature. The "test" service URN is defined in [RFC6881].
以“test.”开头的服务URN表示测试调用。对于eCall，“urn:service:test.sos.eCall”表示这样的测试功能。[RFC6881]中定义了“测试”服务URN。
This document specifies "urn:service:test.sos.ecall" for eCall test calls. This is registered in Section 14.2.
本文档为ecall测试调用指定了“urn:service:test.sos.ecall”。这在第14.2节中登记。
The circuit-switched eCall test call facility is a non-emergency number, so it does not get treated as an emergency call. For NG-eCall, MNOs, emergency authorities, and PSAPs can determine how to treat a vehicle call requesting the "test" service URN so that the desired functionality is tested, but this is outside the scope of this document.
电路交换eCall测试呼叫设施是一个非紧急号码，因此不会被视为紧急呼叫。对于NG eCall，MNO、应急机构和PSAP可以确定如何处理请求“测试”服务URN的车辆呼叫，以便测试所需的功能，但这超出了本文档的范围。
eCall requires the ability for the PSAP to acknowledge successful receipt of an MSD sent by the IVS and for the PSAP to request that the IVS send an MSD (e.g., the call taker can initiate a request for a new MSD to see if there have been changes in the vehicle's state, such as location, direction, or number of fastened seat belts).
eCall要求PSAP能够确认已成功接收IVS发送的MSD，并要求PSAP请求IVS发送MSD（例如，呼叫接线员可以发起新MSD请求，以查看车辆状态是否发生变化，如位置、方向或系好的安全带数量）。
This document defines a block of metadata/control data as an XML structure containing elements used for eCall and other related emergency call systems and extension points. (This metadata/control block is in effect a high-level protocol between the PSAP and IVS.)
本文档将元数据/控制数据块定义为XML结构，其中包含用于eCall和其他相关紧急呼叫系统和扩展点的元素。（此元数据/控制块实际上是PSAP和IVS之间的高级协议。）
This document registers the application/EmergencyCallData.Control+xml MIME media type to enable the metadata/control data to be carried in SIP. This document also adds "Control" to the "Emergency Call Data Types" registry to enable the metadata/control block to be recognized
本文档注册应用程序/EmergencyCallData.Control+xml MIME媒体类型，以便在SIP中携带元数据/控制数据。本文档还将“控制”添加到“紧急呼叫数据类型”注册表中，以便能够识别元数据/控制块
as such in a SIP-based eCall emergency call. (See [RFC7852] for more information about the registry and how it is used.)
因此，在基于SIP的eCall紧急呼叫中。（有关注册表及其使用方式的更多信息，请参阅[RFC7852]）
See Section 6 for a discussion of how the metadata/control data is conveyed in an NG-eCall.
有关如何在NG eCall中传输元数据/控制数据的讨论，请参见第6节。
When the PSAP sends a metadata/control block in response to data sent by the IVS in a SIP request other than INFO (e.g., the MSD in the initial INVITE), the metadata/control block is sent in the SIP response to that request (e.g., the response to the INVITE request). When the PSAP sends a control block in other circumstances (e.g., mid call), the control block is transmitted from the PSAP to the IVS in a SIP INFO request within the established dialog. The IVS sends the requested data (the MSD) in a new SIP INFO request (per [RFC6086]). This mechanism flexibly allows the PSAP to send eCall-specific data to the IVS and the IVS to respond. SIP INFO requests are sent using an appropriate INFO package. See Section 6 for more information on sending a metadata/control block within a SIP message. See Section 14.9 for information about the use of SIP INFO requests to carry data within an eCall.
当PSAP发送元数据/控制块以响应IVS在SIP请求（而非INFO）中发送的数据（例如，初始INVITE中的MSD）时，元数据/控制块将在SIP响应中发送到该请求（例如，对INVITE请求的响应）。当PSAP在其他情况下（例如，中间呼叫）发送控制块时，控制块在建立的对话框内以SIP信息请求的形式从PSAP发送到IVS。IVS在新的SIP信息请求（根据[RFC6086]）中发送请求的数据（MSD）。该机制灵活地允许PSAP向IVS发送eCall特定数据，并让IVS做出响应。SIP信息请求使用适当的信息包发送。有关在SIP消息中发送元数据/控制块的更多信息，请参见第6节。有关使用SIP INFO请求在eCall中传输数据的信息，请参见第14.9节。
When the IVS includes an unsolicited MSD in a SIP request (e.g., the initial INVITE), the PSAP sends a metadata/control block indicating successful/unsuccessful receipt of the MSD in the SIP response to the request. This also informs the IVS that an NG-eCall is in operation. If the IVS receives a SIP final response without the metadata/control block, it indicates that the SIP dialog is not an NG-eCall (e.g., some part of the call is being handled as a legacy call). When the IVS sends a solicited MSD (e.g., in a SIP INFO request sent following receipt of a SIP INFO request containing a metadata/control block requesting an MSD), the PSAP does not send a metadata/control block indicating successful or unsuccessful receipt of the MSD. (Normal SIP retransmission handles non-receipt of requested data; note that, per [RFC6086], a 200 OK response to a SIP INFO request indicates only that the receiver has successfully received and accepted the SIP INFO request, and it says nothing about the acceptability of the payload.) If the IVS receives a request to send an MSD but it is unable to do so for any reason, the IVS instead sends a metadata/control object acknowledging the request, containing an <actionResult> element with a "success" parameter set to "false" and a "reason" parameter (and optionally a "details" parameter) indicating why the request could not be accomplished.
当IVS在SIP请求（例如，初始邀请）中包括未经请求的MSD时，PSAP发送元数据/控制块，指示在对请求的SIP响应中成功/不成功地接收到MSD。这也会通知IVS NG eCall正在运行。如果IVS在没有元数据/控制块的情况下接收到SIP最终响应，则表明SIP对话框不是NG eCall（例如，呼叫的某些部分正在作为遗留呼叫处理）。当IVS发送请求的MSD时（例如，在收到包含请求MSD的元数据/控制块的SIP INFO请求后发送的SIP INFO请求中），PSAP不发送指示成功或不成功接收MSD的元数据/控制块。（正常SIP重传处理未接收到请求的数据；请注意，根据[RFC6086]，对SIP INFO请求的200 OK响应仅表示接收器已成功接收并接受SIP INFO请求，且未说明有效负载的可接受性。）如果IVS收到发送MSD的请求，但由于任何原因无法发送MSD，则IVS会发送一个元数据/控制对象来确认该请求，其中包含一个<actionResult>元素，该元素的“success”参数设置为“false”和一个“reason”参数（以及可选的“details”参数）说明无法完成请求的原因。
This provides flexibility to handle various circumstances. For example, if a PSAP is unable to accept an eCall (e.g., due to overload or too many calls from the same location), it can reject the INVITE. Since a metadata/control object is also included in the SIP response that rejects the call, the IVS knows if the PSAP received
这为处理各种情况提供了灵活性。例如，如果PSAP无法接受eCall（例如，由于过载或来自同一位置的呼叫过多），它可以拒绝邀请。由于拒绝呼叫的SIP响应中还包括元数据/控制对象，因此IVS知道PSAP是否收到
the MSD and can inform the vehicle occupants that the PSAP successfully received the vehicle location and information but can't talk to the occupants at that time. Especially for SIP response codes that indicate an inability to conduct a call (as opposed to a technical inability to process the request), the IVS can also determine that the call was successful on a technical level (e.g., not helpful to retry as circuit switched). (Note that there could be edge cases where the PSAP response is not received by the IVS, e.g., if an intermediary sends a CANCEL, and an error response is forwarded towards the IVS before the error response from the PSAP is received, the response will be dropped, but these are unlikely to occur here.)
MSD和可通知车辆乘员PSAP已成功接收车辆位置和信息，但此时无法与乘员通话。特别是对于指示无法进行呼叫的SIP响应代码（与无法处理请求的技术能力相反），IVS还可以确定呼叫在技术层面上成功（例如，在电路切换时重试没有帮助）。（请注意，可能存在IVS未接收到PSAP响应的边缘情况，例如，如果中介发送取消，并且在收到PSAP的错误响应之前将错误响应转发给IVS，则响应将被丢弃，但此处不太可能发生这种情况。）
The metadata/control block is carried in the MIME type application/ EmergencyCallData.Control+xml.
元数据/控制块包含在MIME类型的application/emergencyccalldata.control+xml中。
The metadata/control block is designed for use with Pan-European eCall and also eCall-like systems (i.e., in other regions), and it has extension points. Note that eCall-like systems might define their own vehicle data blocks and might need to register a new INFO package to accommodate the new data MIME media type and the metadata/ control object.
元数据/控制块设计用于泛欧eCall和类似eCall的系统（即，在其他地区），并具有扩展点。请注意，类似eCall的系统可能会定义自己的车辆数据块，并且可能需要注册新的信息包以适应新的数据MIME媒体类型和元数据/控制对象。
The control block is an XML data structure allowing for acknowledgments, requests, and capabilities information. It is carried in a body part with a specific MIME media type. Three elements are defined for use within a control block:
控制块是一种XML数据结构，允许确认、请求和功能信息。它在具有特定MIME媒体类型的主体部分中携带。在控制块中定义了三个元素：
ack Acknowledges receipt of data or a request.
确认收到数据或请求。
capabilities Used in a 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. It is OPTIONAL for the IVS to send this block. Omitting the block indicates that the IVS supports only the mandatory functionality defined in this document.
从IVS发送至PSAP的控制块中使用的功能（例如，在初始INVITE中），用于通知PSAP车辆功能。子元素包含车辆支持的所有操作和数据类型。IVS发送此块是可选的。省略该块表示IVS仅支持本文档中定义的强制功能。
request Used in a control block sent by the PSAP to the IVS to request the vehicle to perform an action.
PSAP发送至IVS的控制块中使用的请求，用于请求车辆执行操作。
The <ack> element indicates the object being acknowledged and reports success or failure.
<ack>元素表示正在确认的对象，并报告成功或失败。
The <request> element contains attributes to indicate the request and to supply related information. The "action" attribute is mandatory and indicates the specific action. An IANA registry is created in Section 14.8.1 to contain the allowed values.
<request>元素包含指示请求和提供相关信息的属性。“action”属性是必需的，表示具体的操作。IANA注册表在第14.8.1节中创建，以包含允许的值。
The <capabilities> element has child <request> elements to indicate the actions supported by the IVS.
<capabilities>元素有子<request>元素来指示IVS支持的操作。
The <ack> element acknowledges receipt of an eCall data object or request. An <ack> element references the Content-ID of the object being acknowledged. The PSAP MUST send an <ack> element acknowledging receipt of an unsolicited MSD (e.g., sent by the IVS in the INVITE); this <ack> element indicates if the PSAP considers the MSD successfully received or not. An <ack> element is not sent for a <capabilities> element.
元素确认收到eCall数据对象或请求。元素引用被确认对象的内容ID。PSAP必须发送一个<ack>元素，确认收到未经请求的MSD（例如，由INVITE中的IVS发送）；此<ack>元素表示PSAP是否认为MSD已成功接收。对于<capabilities>元素，不会发送<ack>元素。
The <ack> element has the following attributes:
<ack>元素具有以下属性：
Name: ref
Usage: Mandatory
Type: anyURI
Direction: Sent in either direction
Description: References the Content-ID of the body part being
acknowledged.
Example: <ack received="true"
ref="1234567890@atlanta.example.com"/>
Name: ref
Usage: Mandatory
Type: anyURI
Direction: Sent in either direction
Description: References the Content-ID of the body part being
acknowledged.
Example: <ack received="true"
ref="1234567890@atlanta.example.com"/>
Name: received
Usage: Conditional: mandatory in an <ack> element sent by a
PSAP
Type: boolean
Direction: In this document, sent from the PSAP to the IVS
Description: Indicates if the referenced object was considered
successfully received or not.
Example: <ack received="true"
ref="1234567890@atlanta.example.com"/>
Name: received
Usage: Conditional: mandatory in an <ack> element sent by a
PSAP
Type: boolean
Direction: In this document, sent from the PSAP to the IVS
Description: Indicates if the referenced object was considered
successfully received or not.
Example: <ack received="true"
ref="1234567890@atlanta.example.com"/>
For extensibility, the <ack> element has the following child element:
对于可扩展性，<ack>元素具有以下子元素：
Name: actionResult Usage: Optional Direction: Sent from the IVS to the PSAP Description: An <actionResult> element indicates the result of an action (other than a successfully executed "send-data" action). The <ack> element contains an <actionResult> element for each <request> element that is not a successfully executed "send-data" action. The <actionResult> element has the following attributes:
名称：actionResult用法：可选方向：从IVS发送到PSAP描述：<actionResult>元素表示操作的结果（成功执行的“发送数据”操作除外）。对于不是成功执行的“发送数据”操作的每个<request>元素，<ack>元素包含一个<actionResult>元素。<actionResult>元素具有以下属性：
Name: action Usage: Mandatory Type: token Description: Contains the value of the "action" attribute of the <request> element
Name:action用法：必填类型：token Description:包含<request>元素的“action”属性的值
Name: success Usage: Mandatory Type: boolean Description: Indicates if the action was successfully accomplished
名称：成功用法：强制类型：布尔描述：指示操作是否成功完成
Name: reason Usage: Conditional Type: token Description: Used when "success" is "false", this attribute contains a reason code for a failure. A registry for reason codes is defined in Section 14.8.2. The initial values are: damaged (required components are damaged), data-unsupported (the data item referenced in a "send-data" request is not supported), security-failure (the authenticity of the request or the authority of the requestor could not be verified), unable (a generic error for use when no other code is appropriate), and unsupported (the "action" value is not supported).
名称：原因用法：条件类型：令牌描述：当“成功”为“false”时使用，此属性包含失败的原因代码。第14.8.2节定义了原因代码的登记。初始值为：损坏（所需组件损坏）、不支持数据（不支持“发送数据”请求中引用的数据项）、安全故障（无法验证请求的真实性或请求者的权限）、无法（在没有其他代码时使用的一般错误）和不支持（不支持“操作”值）。
Name: details Usage: optional Type: string Description: Contains further explanation of the circumstances of a success or failure. The contents are implementation specific and human readable. This is intended for internal use and troubleshooting, not for display to vehicle occupants.
名称：详细信息用法：可选类型：字符串说明：包含对成功或失败情况的进一步解释。内容是特定于实现的，可读性强。这是为了内部使用和故障排除，而不是为了向车辆乘员显示。
<?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 received="true" ref="1234567890@atlanta.example.com"/>
<ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.Control>
</EmergencyCallData.Control>
Figure 3: <ack> Example from PSAP to IVS
Figure 3: <ack> Example from PSAP to IVS
The <capabilities> element is transmitted by the IVS to indicate its capabilities to the PSAP. No attributes for this element are currently defined. There is one child element defined.
<capabilities>元素由IVS传输，以向PSAP显示其能力。当前未定义此元素的属性。定义了一个子元素。
The <capabilities> element has the following child element:
<capabilities>元素具有以下子元素：
Name: request Usage: Mandatory Description: The <capabilities> element contains a <request> child element per action supported by the vehicle.
名称：请求用途：强制说明：<capabilities>元素包含车辆支持的每个操作的<request>子元素。
Example:
例子：
<capabilities>
<capabilities>
<request action="send-data" supported-values="eCall.MSD" />
<request action="send-data" supported-values="eCall.MSD" />
</capabilities>
</capabilities>
It is OPTIONAL for the IVS to support the <capabilities> element. If the IVS does not send a <capabilities> element, this indicates that the only <request> action supported by the IVS is "send-data" with "datatype" set to "eCall.MSD".
IVS支持<capabilities>元素是可选的。如果IVS不发送<capabilities>元素，则表明IVS支持的唯一<request>操作是“发送数据”，且“数据类型”设置为“eCall.MSD”。
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<capabilities>
<request action="send-data" supported-values="eCall.MSD"/>
</capabilities>
<capabilities>
<request action="send-data" supported-values="eCall.MSD"/>
</capabilities>
</EmergencyCallData.Control>
</EmergencyCallData.Control>
Figure 4: <capabilities> Element Example
Figure 4: <capabilities> Element Example
A <request> element appears one or more times on its own or as a child of a <capabilities> element. It allows the PSAP to request that the IVS perform an action. The only action that MUST be supported is to send an MSD. The attributes and child elements are defined as follows.
<request>元素本身或作为<capabilities>元素的子元素出现一次或多次。它允许PSAP请求IVS执行操作。必须支持的唯一操作是发送MSD。属性和子元素的定义如下。
The <request> element has the following attributes:
<request>元素具有以下属性：
Name: action
Usage: Mandatory
Type: token
Direction: Sent in either direction
Description: Identifies the action that the vehicle is requested to
perform (in a <request> element within a <capabilities> element;
indicates an action that the vehicle is capable of performing).
An IANA registry is established in Section 14.8.1 to contain the
allowed values.
Example: action="send-data"
Name: action
Usage: Mandatory
Type: token
Direction: Sent in either direction
Description: Identifies the action that the vehicle is requested to
perform (in a <request> element within a <capabilities> element;
indicates an action that the vehicle is capable of performing).
An IANA registry is established in Section 14.8.1 to contain the
allowed values.
Example: action="send-data"
Name: int-id Usage: Conditional Type: unsignedInt Direction: Sent in either direction Description: Defined for extensibility. Documents that make use of it are expected to explain when it is required and how it is used. Example: int-id="3"
名称：int-id用法：条件类型：unsignedInt方向：按任意方向发送描述：为扩展性定义。使用信息技术的文件应解释何时需要信息技术以及如何使用信息技术。示例：int id=“3”
Name: persistence Usage: Optional Type: duration Direction: Sent in either direction
名称：持久性用法：可选类型：持续时间方向：向任一方向发送
Description: Defined for extensibility. Specifies how long to carry on the specified action. If absent, the default is for the duration of the call. Example: persistence="PT1H"
描述：为扩展性定义。指定执行指定操作的时间。如果缺席，则默认为通话持续时间。示例：persistence=“PT1H”
Name: datatype Usage: Conditional Type: token Direction: Sent in either direction Description: Mandatory with a "send-data" action within a <request> element that is not within a <capabilities> element. Specifies the data block that the IVS is requested to transmit, using the same identifier as in the "purpose" attribute set in a Call-Info header field to point to the data block. Permitted values are contained in IANA's "Emergency Call Data Types" registry established in [RFC7852]. Only the "eCall.MSD" value is mandatory to support. Example: datatype="eCall.MSD"
名称：数据类型用法：条件类型：令牌方向：按任意方向发送描述：必须在<request>元素内执行“发送数据”操作，该元素不在<capabilities>元素内。指定请求IVS传输的数据块，使用与呼叫信息标头字段中设置的“目的”属性相同的标识符指向数据块。允许值包含在[RFC7852]中建立的IANA“紧急呼叫数据类型”注册表中。只有“eCall.MSD”值是必须支持的。示例：datatype=“eCall.MSD”
Name: supported-values Usage: Conditional Type: string Direction: Sent from the IVS to the PSAP Description: Defined for extensibility. Used in a <request> element that is a child of a <capability> element, this attribute lists all supported values of the action type. Permitted values depend on the action value. Multiple values are separated with a semicolon. White space is ignored. Documents that make use of it are expected to explain when it is required, the permitted values, and how it is used.
名称：支持的值用法：条件类型：字符串方向：从IVS发送到PSAP描述：为扩展性定义。在作为<capability>元素的子元素的<request>元素中使用，该属性列出了操作类型的所有支持值。允许值取决于动作值。多个值用分号分隔。空白被忽略。使用它的文件应解释何时需要它、允许值以及如何使用它。
Name: requested-state Usage: Conditional Type: token Direction: Sent from the PSAP to the IVS Description: Defined for extension. Indicates the requested state of an element associated with the request type. Permitted values depend on the request type. Documents that make use of it are expected to explain when it is required, the permitted values, and how it is used.
名称：请求状态用法：条件类型：令牌方向：从PSAP发送到IVS描述：为扩展定义。指示与请求类型关联的元素的请求状态。允许的值取决于请求类型。使用它的文件应解释何时需要它、允许值以及如何使用它。
Name: element-id Usage: Conditional Type: token Direction: Sent from the PSAP to the IVS Description: Defined for extension. Identifies the element to be acted on. Permitted values depend on the request type. Documents that make use of it are expected to explain when it is required, the permitted values, and how it is used.
名称：元素id用法：条件类型：令牌方向：从PSAP发送到IVS描述：为扩展定义。标识要对其执行操作的元素。允许的值取决于请求类型。使用它的文件应解释何时需要它、允许值以及如何使用它。
For extensibility, the <request> element has the following child element:
对于可扩展性，<request>元素具有以下子元素：
Name: text Usage: Optional Type: string Direction: Sent from the PSAP to the IVS Description: Defined for extension.
名称：文本用法：可选类型：字符串方向：从PSAP发送到IVS描述：为扩展定义。
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<request action="send-data" datatype="eCall.MSD"/>
<request action="send-data" datatype="eCall.MSD"/>
</EmergencyCallData.Control>
</EmergencyCallData.Control>
Figure 5: <request> Element Example
Figure 5: <request> Element Example
Figure 6 illustrates an eCall. The call uses the request URI urn:service:sos.ecall.automatic service URN and is recognized as an eCall, and further as one that was invoked automatically by the IVS due to a crash or other serious incident. In this example, the originating network routes the call to an ESInet, which routes the call to the appropriate NG-eCall-capable PSAP. The emergency call is received by the ESInet's Emergency Services Routing Proxy (ESRP), as the entry point into the ESInet. The ESRP routes the call to a PSAP, where it is received by a call taker. In deployments where there is no ESInet, the originating network routes the call directly to the appropriate NG-eCall-capable PSAP, an illustration of which would be identical to the one below except without an ESInet or ESRP.
图6显示了一个eCall。该调用使用请求URI urn:service:sos.ecall.automatic service urn，并被识别为ecall，进而被识别为因崩溃或其他严重事件而由IVS自动调用的调用。在此示例中，发起网络将呼叫路由到ESInet，ESInet将呼叫路由到适当的支持NG eCall的PSAP。紧急呼叫由ESInet的紧急服务路由代理（ESRP）接收，作为ESInet的入口点。ESRP将呼叫路由到PSAP，由呼叫接受者接收。在没有ESInet的部署中，发起网络将呼叫直接路由到适当的支持NG eCall的PSAP，其说明与下面的说明相同，除非没有ESInet或ESRP。
+-----------+ +----------------------------------------+
| | | +-------+ |
| | | | PSAP2 | |
| | | +-------+ |
| | | |
| | | +------+ +----------------------+ |
Vehicle-->| |--|-->| ESRP |-->| PSAP1 --> Call Taker | |
| | | +------+ +----------------------+ |
| | | |
| | | +-------+ |
| | | | PSAP3 | |
|Originating| | +-------+ |
| Mobile | | |
| Network | | ESInet |
+-----------+ +----------------------------------------+
+-----------+ +----------------------------------------+
| | | +-------+ |
| | | | PSAP2 | |
| | | +-------+ |
| | | |
| | | +------+ +----------------------+ |
Vehicle-->| |--|-->| ESRP |-->| PSAP1 --> Call Taker | |
| | | +------+ +----------------------+ |
| | | |
| | | +-------+ |
| | | | PSAP3 | |
|Originating| | +-------+ |
| Mobile | | |
| Network | | ESInet |
+-----------+ +----------------------------------------+
Figure 6: Example of NG-eCall Message Flow
图6:NG eCall消息流示例
Figure 7 illustrates an eCall call flow with a mid-call PSAP request for an updated MSD. The call flow shows the IVS initiating an emergency call, including the MSD in the INVITE. The PSAP includes in the 200 OK response a metadata/control object acknowledging receipt of the MSD. During the call, the PSAP sends a request for an MSD in an INFO request. The IVS sends the requested MSD in a new INFO request.
图7显示了一个eCall调用流，其中包含一个用于更新MSD的中间调用PSAP请求。呼叫流程显示发起紧急呼叫的IVS，包括INVITE中的MSD。PSAP在200OK响应中包含一个元数据/控制对象，用于确认收到MSD。在呼叫过程中，PSAP在INFO请求中发送MSD请求。IVS在新的信息请求中发送请求的MSD。
IVS PSAP
|(1) INVITE (eCall MSD) |
|------------------------------------------->|
| |
|(2) 200 OK (eCall metadata [ack MSD]) |
|<-------------------------------------------|
| |
|(3) start media stream(s) |
|............................................|
| |
|(4) INFO (eCall metadata [request MSD]) |
|<-------------------------------------------|
| |
|(5) 200 OK |
|------------------------------------------->|
| |
|(6) INFO (eCall MSD) |
|------------------------------------------->|
| |
|(7) 200 OK |
|<-------------------------------------------|
| |
|(8) BYE |
|<-------------------------------------------|
| |
|(9) end media streams |
|............................................|
| |
|(10) 200 OK |
|------------------------------------------->|
IVS PSAP
|(1) INVITE (eCall MSD) |
|------------------------------------------->|
| |
|(2) 200 OK (eCall metadata [ack MSD]) |
|<-------------------------------------------|
| |
|(3) start media stream(s) |
|............................................|
| |
|(4) INFO (eCall metadata [request MSD]) |
|<-------------------------------------------|
| |
|(5) 200 OK |
|------------------------------------------->|
| |
|(6) INFO (eCall MSD) |
|------------------------------------------->|
| |
|(7) 200 OK |
|<-------------------------------------------|
| |
|(8) BYE |
|<-------------------------------------------|
| |
|(9) end media streams |
|............................................|
| |
|(10) 200 OK |
|------------------------------------------->|
Figure 7: NG-eCall Call Flow Illustration
图7:NG eCall呼叫流程示意图
Figure 8 illustrates a SIP eCall INVITE request containing an MSD. For simplicity, the example does not show all SIP headers, nor the Session Description Protocol (SDP) contents, nor does it show any additional data blocks added by the IVS or the originating mobile network. Because the MSD is encoded in ASN.1 PER, which is a binary encoding, its contents cannot be included in a text document.
图8说明了包含MSD的SIP eCall INVITE请求。为简单起见，该示例不显示所有SIP报头、会话描述协议（SDP）内容，也不显示由IVS或原始移动网络添加的任何附加数据块。因为MSD是用ASN.1 PER编码的，这是一种二进制编码，所以它的内容不能包含在文本文档中。
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.eCall.MSD Accept: application/sdp, application/pidf+xml, application/EmergencyCallData.Control+xml CSeq: 31862 INVITE Recv-Info: EmergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
邀请urn:service:sos.ecall.automatic SIP/2.0至：urn:service:sos.ecall.automatic From:<SIP:+13145551111@example.com>;tag=9fxced76sl呼叫ID:3848276298220188511@atlanta.example.com地理位置：<cid:target123@example.com>地理位置路由：无呼叫信息：<cid:1234567890@atlanta.example.com>; purpose=EmergencyCallData.eCall.MSD接受：应用程序/sdp，应用程序/pidf+xml，应用程序/EmergencyCallData.Control+xml CSeq:31862邀请接收信息：EmergencyCallData.eCall.MSD允许：邀请，确认，重复，信息，选项，取消，引用，再见，订阅，通知，更新内容类型：多部分/混合；边界=边界1内容长度：。。。
--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@example.com>
Content-Disposition: by-reference;handling=optional
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@example.com>
Content-Disposition: by-reference;handling=optional
...PIDF-LO goes here...
…PIDF-LO在这里。。。
--boundary1
Content-Type: application/EmergencyCallData.eCall.MSD
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
--boundary1
Content-Type: application/EmergencyCallData.eCall.MSD
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
...MSD in ASN.1 PER encoding goes here...
…ASN.1中的MSD每个编码位于此处。。。
--boundary1--
--边界1--
Figure 8: SIP NG-eCall INVITE
图8:SIP NG eCall邀请
Continuing the example, Figure 9 illustrates a SIP 200 OK response to the INVITE request of Figure 8, containing a metadata/control block acknowledging successful receipt of the eCall MSD. (For simplicity, the example does not show all SIP headers.)
继续这个示例，图9展示了对图8的INVITE请求的SIP 200 OK响应，其中包含一个元数据/控制块，确认成功接收到eCall MSD。（为简单起见，本示例并不显示所有SIP头。）
SIP/2.0 200 OK To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 From: <sip:+13145551111@example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: <cid:2345678901@atlanta.example.com>; purpose=EmergencyCallData.Control Accept: application/sdp, application/pidf+xml, application/EmergencyCallData.Control+xml, application/EmergencyCallData.eCall.MSD CSeq: 31862 INVITE Recv-Info: EmergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=boundaryX Content-Length: ...
SIP/2.0 200正常到：urn:service:sos.ecall.automatic；tag=8gydfe65t0发件人：<sip:+13145551111@example.com>;tag=9fxced76sl呼叫ID:3848276298220188511@atlanta.example.com呼叫信息：<cid:2345678901@atlanta.example.com>; 目的=EmergencyCallData.Control接受：应用程序/sdp、应用程序/pidf+xml、应用程序/EmergencyCallData.Control+xml、应用程序/EmergencyCallData.eCall.MSD CSeq:31862邀请接收信息：EmergencyCallData.eCall.MSD允许：邀请、确认、重复、信息、选项、取消、引用、再见、订阅、通知、更新内容类型：多部分/混合；边界=边界X内容长度：。。。
--boundaryX
Content-Type: application/sdp
--boundaryX
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here...
…会话描述协议（SDP）位于此处。。。
--boundaryX
Content-Type: application/EmergencyCallData.Control+xml
Content-ID: <2345678901@atlanta.example.com>
Content-Disposition: by-reference
--boundaryX
Content-Type: application/EmergencyCallData.Control+xml
Content-ID: <2345678901@atlanta.example.com>
Content-Disposition: by-reference
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.Control>
<ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.Control>
--boundaryX--
--边界--
Figure 9: 200 OK Response to INVITE
图9:200对INVITE的OK响应
Figure 10 illustrates a SIP INFO request containing a metadata/ control block requesting an eCall MSD. (For simplicity, the example does not show all SIP headers.)
图10说明了包含元数据/控制块的SIP信息请求，该元数据/控制块请求eCall MSD。（为简单起见，本示例并不显示所有SIP头。）
INFO sip:+13145551111@example.com SIP/2.0 To: <sip:+13145551111@example.com>;tag=9fxced76sl From: Exemplar PSAP <urn:service:sos.ecall.automatic>;tag=8gydfe65t0 Call-ID: 3848276298220188511@atlanta.example.com Call-Info: <cid:3456789012@atlanta.example.com>; purpose=EmergencyCallData.Control CSeq: 41862 INFO Info-Package: EmergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=boundaryZZZ Content-Disposition: Info-Package Content-Length: ...
信息sip：+13145551111@example.comSIP/2.0至：<SIP:+13145551111@example.com>;tag=9fxced76sl From:exemplarpsap<urn:service:sos.ecall.automatic>；tag=8gydfe65t0呼叫ID:3848276298220188511@atlanta.example.com呼叫信息：<cid:3456789012@atlanta.example.com>; 目的=EmergencyCallData.Control CSeq:41862信息包：EmergencyCallData.eCall.MSD允许：邀请、确认、PRACK、信息、选项、取消、引用、再见、订阅、通知、更新内容类型：多部分/混合；边界=边界ZZZ内容处置：信息包内容长度：。。。
--boundaryZZZ
Content-Disposition: by-reference
Content-Type: application/EmergencyCallData.Control+xml
Content-ID: <3456789012@atlanta.example.com>
--boundaryZZZ
Content-Disposition: by-reference
Content-Type: application/EmergencyCallData.Control+xml
Content-ID: <3456789012@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control">
<request action="send-data" datatype="eCall.MSD"/>
<request action="send-data" datatype="eCall.MSD"/>
</EmergencyCallData.Control>
--boundaryZZZ--
</EmergencyCallData.Control>
--boundaryZZZ--
Figure 10: INFO Requesting MSD
图10：请求MSD的信息
Figure 11 illustrates a SIP INFO request containing an MSD. For simplicity, the example does not show all SIP headers. Because the MSD is encoded in ASN.1 PER, which is a binary encoding, its contents cannot be included in a text document.
图11说明了包含MSD的SIP信息请求。为简单起见，该示例并不显示所有SIP头。因为MSD是用ASN.1 PER编码的，这是一种二进制编码，所以它的内容不能包含在文本文档中。
INFO urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic;tag=8gydfe65t0 From: <sip:+13145551111@example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: <cid:4567890123@atlanta.example.com>; purpose=EmergencyCallData.eCall.MSD CSeq: 51862 INFO Info-Package: EmergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=boundaryLine Content-Disposition: Info-Package Content-Length: ...
信息urn:service:sos.ecall.automatic SIP/2.0至：urn:service:sos.ecall.automatic；tag=8gydfe65t0发件人：<sip:+13145551111@example.com>;tag=9fxced76sl呼叫ID:3848276298220188511@atlanta.example.com呼叫信息：<cid:4567890123@atlanta.example.com>; 目的=EmergencyCallData.eCall.MSD CSeq:51862信息包：EmergencyCallData.eCall.MSD允许：邀请、确认、恶作剧、信息、选项、取消、引用、再见、订阅、通知、更新内容类型：多部分/混合；边界=边界线内容处置：信息包内容长度：。。。
--boundaryLine
Content-Type: application/EmergencyCallData.eCall.MSD
Content-ID: <4567890123@atlanta.example.com>
Content-Disposition: by-reference
--boundaryLine
Content-Type: application/EmergencyCallData.eCall.MSD
Content-ID: <4567890123@atlanta.example.com>
Content-Disposition: by-reference
...MSD in ASN.1 PER encoding goes here...
…ASN.1中的MSD每个编码位于此处。。。
--boundaryLine--
--边界线--
Figure 11: INFO Containing MSD
图11：包含MSD的信息
The security considerations described in [RFC5069] (on marking and routing emergency calls) apply here.
[RFC5069]（关于标记和路由紧急呼叫）中描述的安全注意事项适用于此处。
In addition to any network-provided location (which might be determined solely by the network or in cooperation with or possibly entirely by the originating device), an eCall carries an IVS-supplied location within the MSD. This is likely to be useful to the PSAP, especially when no network-provided location is included, or when the two locations are independently determined. Even in situations where the network-supplied location is limited to the cell site, this can be useful as a sanity check on the device-supplied location contained in the MSD.
除了任何网络提供的位置（可能由网络单独确定，也可能由发起设备合作确定，也可能完全由发起设备确定），eCall在MSD中携带IVS提供的位置。这可能对PSAP有用，尤其是当不包括网络提供的位置时，或者当两个位置独立确定时。即使在网络提供的位置仅限于小区站点的情况下，这也可以作为MSD中包含的设备提供位置的健全性检查。
The document [RFC7378] discusses trust issues regarding location provided by or determined in cooperation with end devices.
文件[RFC7378]讨论了与终端设备提供的或与终端设备合作确定的位置有关的信任问题。
Security considerations specific to the mechanism by which the PSAP sends acknowledgments and requests to the vehicle are discussed in the "Security Considerations" block of Section 14.4. Note that an attacker that has access to and is capable of generating a response to the initial INVITE request could generate a 600 (Busy Everywhere), 486 (Busy Here), or 603 (Decline) response that includes a metadata/ control object containing a reference to the MSD in the initial INVITE and a "received=true" field, which could result in the IVS perceiving the PSAP to be overloaded and hence not attempting to reinitiate the call. The risk can be mitigated as discussed in the "Security Considerations" block of Section 14.4.
PSAP向车辆发送确认和请求的机制的特定安全注意事项在第14.4节的“安全注意事项”栏中讨论。请注意，有权访问并能够生成对初始INVITE请求的响应的攻击者可以生成600（到处忙）、486（这里忙）或603（拒绝）响应，其中包括元数据/控制对象，其中包含对初始INVITE中MSD的引用和“received=true”字段，这可能会导致IVS感知到PSAP过载，因此不会尝试重新初始化调用。如第14.4节“安全注意事项”部分所述，可以降低风险。
Data received from external sources inherently carries implementation risks. For example, depending on the platform, buffer overflows can introduce remote code execution vulnerabilities, null characters can corrupt strings, numeric values used for internal calculations can result in underflow/overflow errors, malformed XML objects can expose parsing bugs, etc. Implementations need to be cognizant of the potential risks, observe best practices (which might include sufficiently capable static code analysis, fuzz testing, component isolation, avoiding use of unsafe coding techniques, third-party attack tests, signed software, over-the-air updates, etc.), and have multiple levels of protection. Implementors need to be aware that, potentially, the data objects described here and elsewhere (including the MSD and metadata/control objects) might be malformed, contain unexpected characters, have excessively long attribute values and elements, etc.
从外部来源收到的数据本身就带有实施风险。例如，根据平台的不同，缓冲区溢出可能会引入远程代码执行漏洞，空字符可能会损坏字符串，用于内部计算的数值可能会导致下溢/溢出错误，格式错误的XML对象可能会暴露解析错误等。实现时需要认识到潜在的风险，遵守最佳实践（可能包括足够能力的静态代码分析、模糊测试、组件隔离、避免使用不安全的编码技术、第三方攻击测试、签名软件、空中更新等），并具有多级保护。实施者需要意识到，此处和其他地方描述的数据对象（包括MSD和元数据/控制对象）可能存在格式错误、包含意外字符、属性值和元素过长等问题。
The security considerations discussed in [RFC7852] apply here (see especially the discussion of Transport Layer Security (TLS), TLS versions, cipher suites, and PKI).
[RFC7852]中讨论的安全注意事项适用于此处（请特别参阅传输层安全性（TLS）、TLS版本、密码套件和PKI的讨论）。
When vehicle data or control/metadata 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 enclosed 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 contains a CID URL pointing to the data block in the body, which has a matching Content-ID body part header field.)
当车辆数据或控制/元数据包含在签名或加密的车身部件中时，封装的多部件（例如，多部件/签名或多部件/加密）与封装的数据部件具有相同的内容ID。这允许实体识别和访问它感兴趣的数据块，而不必深入研究消息结构或解密它不感兴趣的部分。（Call Info标头字段中的“purpose”参数标识数据，并包含指向正文中数据块的CID URL，该数据块具有匹配的内容ID正文部分标头字段。）
The privacy considerations discussed in [RFC7852] apply here. The MSD carries some identifying and personal information (mostly about the vehicle and less about the owner), as well as location information, so it needs to be protected against unauthorized disclosure. Local regulations may impose additional privacy protection requirements.
[RFC7852]中讨论的隐私注意事项适用于此处。MSD包含一些身份和个人信息（主要是关于车辆的信息，较少是关于车主的信息）以及位置信息，因此需要对其进行保护，以防止未经授权的泄露。当地法规可能会提出额外的隐私保护要求。
Privacy considerations specific to the data structure containing vehicle information are discussed in the "Security Considerations" block of Section 14.3.
第14.3节的“安全注意事项”部分讨论了特定于包含车辆信息的数据结构的隐私注意事项。
Privacy considerations specific to the mechanism by which the PSAP sends acknowledgments and requests to the vehicle are discussed in the "Security Considerations" block of Section 14.4.
PSAP向车辆发送确认和请求的机制的隐私注意事项在第14.4节的“安全注意事项”栏中讨论。
This section defines an XML schema for the control block. The text description of the control block in Section 9.1 is normative and supersedes any conflicting aspect of this schema.
本节定义了控制块的XML模式。第9.1节中控制块的文本描述是规范性的，并取代本模式的任何冲突方面。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:element name="EmergencyCallData.Control"
type="pi:controlType"/>
<xs:element name="EmergencyCallData.Control"
type="pi:controlType"/>
<xs:complexType name="controlType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="capabilities"
type="pi:capabilitiesType"/>
<xs:element name="request" type="pi:requestType"/>
<xs:element name="ack" type="pi:ackType"/>
<xs:complexType name="controlType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="capabilities"
type="pi:capabilitiesType"/>
<xs:element name="request" type="pi:requestType"/>
<xs:element name="ack" type="pi:ackType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ackType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="actionResult" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="action"
type="xs:token"
use="required"/>
<xs:attribute name="success"
type="xs:boolean"
use="required"/>
<xs:attribute name="reason"
type="xs:token">
<xs:annotation>
<xs:documentation>
conditionally mandatory
when @success="false"
to indicate reason code
for a failure
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="details"
type="xs:string"/>
<xs:anyAttribute
processContents="skip"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ref"
type="xs:anyURI"
use="required"/>
<xs:complexType name="ackType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="actionResult" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="action"
type="xs:token"
use="required"/>
<xs:attribute name="success"
type="xs:boolean"
use="required"/>
<xs:attribute name="reason"
type="xs:token">
<xs:annotation>
<xs:documentation>
conditionally mandatory
when @success="false"
to indicate reason code
for a failure
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="details"
type="xs:string"/>
<xs:anyAttribute
processContents="skip"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ref"
type="xs:anyURI"
use="required"/>
<xs:attribute name="received"
type="xs:boolean"/>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:attribute name="received"
type="xs:boolean"/>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="capabilitiesType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="request"
type="pi:requestType"
minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="capabilitiesType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="request"
type="pi:requestType"
minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="requestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="text" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:anyAttribute
namespace="##any"
processContents="skip"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="action" type="xs:token"
use="required"/>
<xs:complexType name="requestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="text" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:anyAttribute
namespace="##any"
processContents="skip"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="action" type="xs:token"
use="required"/>
<xs:attribute name="int-id" type="xs:unsignedInt"/>
<xs:attribute name="persistence"
type="xs:duration"/>
<xs:attribute name="datatype" type="xs:token"/>
<xs:attribute name="supported-values"
type="xs:string"/>
<xs:attribute name="element-id" type="xs:token"/>
<xs:attribute name="requested-state"
type="xs:token"/>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:attribute name="int-id" type="xs:unsignedInt"/>
<xs:attribute name="persistence"
type="xs:duration"/>
<xs:attribute name="datatype" type="xs:token"/>
<xs:attribute name="supported-values"
type="xs:string"/>
<xs:attribute name="element-id" type="xs:token"/>
<xs:attribute name="requested-state"
type="xs:token"/>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
</xs:schema>
Figure 12: Control Block Schema
图12：控制块模式
This document establishes the "EmergencyCallData" media (MIME) subtype tree, a new media subtree rooted at "application/ EmergencyCallData". This subtree is used only for content associated with emergency communications. New subtypes in this subtree follow the rules specified in Section 3.1 of [RFC6838], with the additional restriction that the standards-related organization MUST be responsible for some aspect of emergency communications.
本文档建立了“EmergencyCallData”媒体（MIME）子类型树，这是一个以“application/EmergencyCallData”为根的新媒体子树。此子树仅用于与紧急通信相关的内容。此子树中的新子类型遵循[RFC6838]第3.1节中规定的规则，另外还有一个限制，即与标准相关的组织必须负责紧急通信的某些方面。
This subtree initially contains the following subtypes (defined here or in [RFC7852]):
此子树最初包含以下子类型（在此处或[RFC7852]中定义）：
EmergencyCallData.Comment+xml EmergencyCallData.Control+xml EmergencyCallData.DeviceInfo+xml EmergencyCallData.eCall.MSD EmergencyCallData.ProviderInfo+xml EmergencyCallData.ServiceInfo+xml EmergencyCallData.SubscriberInfo+xml
EmergencyCallData.Comment+xml EmergencyCallData.Control+xml EmergencyCallData.DeviceInfo+xml EmergencyCallData.eCall.MSD EmergencyCallData.ProviderInfo+xml EmergencyCallData.ServiceInfo+xml EmergencyCallData.SubscriberInfo+xml
IANA has registered the URN urn:service:sos.ecall under the "'sos' Sub-Services" registry defined in Section 4.2 of [RFC5031].
IANA已在[RFC5031]第4.2节定义的“sos”子服务”注册表下注册了URN-URN:service:sos.ecall。
This service requests resources associated with an emergency call placed by an in-vehicle system, carrying a standardized set of data related to the vehicle and incident. The "Description" registry field is "Vehicle-initiated emergency calls". Two sub-services are registered as well:
此服务请求与车载系统发出的紧急呼叫相关的资源，该系统携带与车辆和事件相关的标准化数据集。“说明”注册表字段为“车辆启动紧急呼叫”。还注册了两个子服务：
urn:service:sos.ecall.automatic
urn：服务：sos.ecall.automatic
Used with an eCall invoked automatically, for example, due to a crash or other serious incident. The "Description" registry field is "Automatic vehicle-initiated emergency calls".
与自动调用的eCall一起使用，例如，由于崩溃或其他严重事件。“说明”注册表字段为“自动车辆启动紧急呼叫”。
urn:service:sos.ecall.manual
urn：服务：sos.ecall.manual
Used with an eCall invoked due to manual interaction by a vehicle occupant. The "Description" registry field is "Manual vehicle-initiated emergency calls".
与因车辆乘员手动交互而调用的eCall一起使用。“说明”注册表字段为“手动车辆启动紧急呼叫”。
IANA has also registered the URN urn:service:test.sos.ecall under the "'test' Sub-Services" registry defined in Section 17.2 of [RFC6881]. This service requests resources associated with a test (non-emergency) call placed by an in-vehicle system. See Section 8 for more information on the test eCall request URN.
IANA还在[RFC6881]第17.2节定义的“测试”子服务注册表下注册了URN-URN:service:test.sos.ecall。此服务请求与车载系统发出的测试（非紧急）呼叫相关的资源。有关测试eCall请求URN的更多信息，请参阅第8节。
14.3. MIME Media Type Registration for application/ EmergencyCallData.eCall.MSD
14.3. 应用程序/EmergencyCallData.eCall.MSD的MIME媒体类型注册
IANA has added application/EmergencyCallData.eCall.MSD as a MIME media type, with a reference to this document, in accordance with the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
IANA已根据RFC 6838[RFC6838]的程序和RFC 7303[RFC7303]中的指南，将application/emergencyccalldata.eCall.MSD添加为MIME媒体类型，并参考了本文档。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: EmergencyCallData.eCall.MSD
MIME子类型名称：EmergencyCallData.eCall.MSD
Mandatory parameters: none
强制参数：无
Optional parameters: none
可选参数：无
Encoding scheme: binary
编码方案：二进制
Encoding considerations: Uses ASN.1 PER, which is a binary encoding; when transported in SIP, binary content transfer encoding is used.
编码注意事项：使用ASN.1 PER，这是一种二进制编码；在SIP中传输时，使用二进制内容传输编码。
Security considerations: This media type is designed to carry vehicle and incident-related data during an emergency call. This data contains personal information including vehicle VIN, location, direction, etc. Appropriate precautions need to be taken to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. Sections 9 and 10 of [RFC7852] contain more discussion.
安全注意事项：此媒体类型旨在在紧急呼叫期间承载车辆和事件相关数据。此数据包含个人信息，包括车辆VIN、位置、方向等。需要采取适当的预防措施，以限制未经授权的访问、不适当地向第三方披露以及窃听此信息。[RFC7852]第9节和第10节包含更多讨论。
Interoperability considerations: None
互操作性注意事项：无
Published specification: Annex A of EN 15722 [MSD]
发布规范：EN 15722[MSD]附录A
Applications which use this media type: Pan-European eCall compliant systems
使用此介质类型的应用程序：泛欧洲eCall兼容系统
Additional information: None
其他信息：无
Magic Number: None
神奇数字：无
File Extension: None
文件扩展名：无
Macintosh file type code: BINA
Macintosh文件类型代码：BINA
Person and email address for further information: Randall Gellens, rg+ietf@randy.pensive.org
更多信息的人员和电子邮件地址：rg Randall Gellens+ietf@randy.pensive.org
Intended usage: LIMITED USE
预期用途：有限用途
Author: The MSD specification was produced by the European Committee For Standardization (CEN). For contact information, please see <http://www.cen.eu/cen/Pages/contactus.aspx>.
作者：MSD规范由欧洲标准化委员会（CEN）编制。有关联系信息，请参阅<http://www.cen.eu/cen/Pages/contactus.aspx>.
Change controller: The European Committee For Standardization (CEN)
变更控制者：欧洲标准化委员会（CEN）
14.4. MIME Media Type Registration for application/ EmergencyCallData.Control+xml
14.4. 应用程序/EmergencyCallData.Control+xml的MIME媒体类型注册
IANA has added application/EmergencyCallData.Control+xml as a MIME media type, with a reference to this document, in accordance to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
IANA根据RFC 6838[RFC6838]的程序和RFC 7303[RFC7303]中的指南，添加了application/EmergencyCallData.Control+xml作为MIME媒体类型，并参考了本文档。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: EmergencyCallData.Control+xml
MIME子类型名称：EmergencyCallData.Control+xml
Mandatory parameters: none
强制参数：无
Optional parameters: charset
可选参数：字符集
Indicates the character encoding of the XML content.
指示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 carries metadata and control information and requests, such as from a Public Safety Answering Point (PSAP) to an In-Vehicle System (IVS) during an emergency call.
安全注意事项：这种媒体类型携带元数据和控制信息以及请求，例如在紧急呼叫期间从公共安全应答点（PSAP）到车载系统（IVS）。
Metadata (such as an acknowledgment that data sent by the IVS to the PSAP was successfully received) has limited privacy and security implications. Control information (such as requests from the PSAP that the vehicle perform an action) has some privacy and security implications. The privacy concern arises from the ability to request the vehicle to transmit a data set, which as described in Section 14.3 can contain personal information. The security concern is the ability to request the vehicle to perform an action. Control information needs to originate only from a PSAP or other emergency services providers and not be modified en route. The level of integrity of the cellular network over which the emergency call is placed is a consideration: when the IVS initiates an eCall over a cellular network, in most cases it relies on the MNO to route the call to a PSAP. (Calls placed using other means, such as Wi-Fi or over-the-top services, generally incur somewhat higher levels of risk than calls placed "natively" using cellular networks.) A callback from a PSAP merits additional consideration, since current mechanisms are not ideal for verifying that such a call is indeed a callback from a PSAP in response to an emergency call placed by the IVS. See the discussion in Section 11 and the PSAP Callback document [RFC7090].
元数据（如确认IVS向PSAP发送的数据已成功接收）对隐私和安全的影响有限。控制信息（例如来自PSAP的车辆执行操作的请求）具有一些隐私和安全含义。隐私问题源于请求车辆传输数据集的能力，如第14.3节所述，该数据集可能包含个人信息。安全问题是请求车辆执行操作的能力。控制信息只需来自PSAP或其他应急服务提供商，不得在途中修改。紧急呼叫所在蜂窝网络的完整性水平是一个考虑因素：当IVS通过蜂窝网络发起eCall时，在大多数情况下，它依靠MNO将呼叫路由到PSAP。（使用其他方式（如Wi-Fi或无线上网服务）拨打的电话通常比使用蜂窝网络“本机”拨打的电话具有更高的风险水平。）来自PSAP的回拨需要额外考虑，因为目前的机制并不适合验证这样的呼叫是否确实是来自PSAP的回调，以响应IVS发出的紧急呼叫。请参阅第11节中的讨论和PSAP回调文档[RFC7090]。
Sections 7 and 8 of [RFC7852] contain more discussion.
[RFC7852]第7节和第8节包含更多讨论。
Interoperability considerations: None
互操作性注意事项：无
Published specification: This document
已发布规范：本文件
Applications which use this media type: Pan-European eCall compliant systems
使用此介质类型的应用程序：泛欧洲eCall兼容系统
Additional information: None
其他信息：无
Magic Number: None
神奇数字：无
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: TEXT
Macintosh文件类型代码：文本
Person and email address for further information: Randall Gellens, rg+ietf@randy.pensive.org
更多信息的人员和电子邮件地址：rg Randall Gellens+ietf@randy.pensive.org
Intended usage: LIMITED USE
预期用途：有限用途
Author: The IETF ECRIT working group
作者：IETF ECRIT工作组
Change controller: The IETF ECRIT working group
变更控制员：IETF ECRIT工作组
14.5. Registration of the "eCall.MSD" Entry in the Emergency Call Data Types Registry
14.5. 在紧急呼叫数据类型注册表中注册“eCall.MSD”条目
IANA has added the "eCall.MSD" entry to the "Emergency Call Data Types" registry, with a reference to this document; the "Data About" value is "The Call".
IANA已将“eCall.MSD”条目添加到“紧急呼叫数据类型”注册表中，并参考了本文件；“数据关于”值是“调用”。
14.6. Registration of the "Control" Entry in the Emergency Call Data Types Registry
14.6. 在紧急呼叫数据类型注册表中注册“控制”项
IANA has added the "Control" entry to the "Emergency Call Data Types" registry, with a reference to this document; the "Data About" value is "The Call".
IANA在“紧急呼叫数据类型”注册表中添加了“控制”项，并参考了本文件；“数据关于”值是“调用”。
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
本节根据RFC 3688[RFC3688]中的指南注册一个新的XML名称空间。
URI: urn:ietf:params:xml:ns:EmergencyCallData:control
URI: urn:ietf:params:xml:ns:EmergencyCallData:control
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@ietf.org>.
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Emergency Call Data Control Block</title>
</head>
<body>
<h1>Namespace for Emergency Call Data Control Block</h1>
<p>See RFC 8147</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Emergency Call Data Control Block</title>
</head>
<body>
<h1>Namespace for Emergency Call Data Control Block</h1>
<p>See RFC 8147</p>
</body>
</html>
END
This document creates a new registry called "Emergency Call Metadata/ Control Data". The following sub-registries are created for this registry.
本文档创建了一个名为“紧急呼叫元数据/控制数据”的新注册表。将为此注册表创建以下子注册表。
This document creates a new sub-registry called "Emergency Call Actions". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed action is within the purview of a vehicle, is sufficiently distinguishable from other actions, and is clearly and fully described. In most cases, a published and stable document is referenced for the description of the action.
本文档创建了一个名为“紧急呼叫操作”的新子注册表。根据[RFC5226]中的定义，该登记处按照“专家审查”规则运作。专家应确定提议的行动在车辆的权限范围内，与其他行动有足够的区别，并清楚、充分地描述。在大多数情况下，引用已发布且稳定的文档来描述操作。
The content of this registry includes:
本登记册的内容包括：
Name: The identifier to be used in the "action" attribute of a control <request> element.
名称：要在控件<request>元素的“action”属性中使用的标识符。
Description: A description of the action. In most cases, this will be a reference to a published and stable document. The description MUST specify if any attributes or child elements are optional or mandatory and describe the action to be taken by the vehicle.
描述：操作的描述。在大多数情况下，这将是对已发布且稳定的文档的引用。说明必须说明任何属性或子元素是可选的还是强制性的，并说明车辆将采取的措施。
The initial set of values is listed in Table 1.
表1列出了初始值集。
+-----------+--------------------------------------+
| Name | Description |
+-----------+--------------------------------------+
| send-data | See Section 9.1.3.1 of this document |
+-----------+--------------------------------------+
+-----------+--------------------------------------+
| Name | Description |
+-----------+--------------------------------------+
| send-data | See Section 9.1.3.1 of this document |
+-----------+--------------------------------------+
Table 1: Emergency Call Actions Registry Initial Values
表1：紧急呼叫操作注册表初始值
This document creates a new sub-registry called "Emergency Call Action Failure Reasons", which contains values for the "reason" attribute of the <actionResult> element. As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed reason is sufficiently distinguishable from other reasons and that the proposed description is understandable and correctly worded.
本文档创建了一个名为“紧急呼叫操作失败原因”的新子注册表，其中包含<actionResult>元素的“原因”属性的值。根据[RFC5226]中的定义，该登记处按照“专家审查”规则运作。专家应确定提议的理由与其他理由充分区分，并且提议的描述可以理解且措辞正确。
The content of this registry includes:
本登记册的内容包括：
ID: A short string identifying the reason, for use in the "reason" attribute of an <actionResult> element.
ID：标识原因的短字符串，用于<actionResult>元素的“reason”属性。
Description: A description of the reason.
描述：对原因的描述。
The initial set of values is listed in Table 2.
表2中列出了初始值集。
+------------------+------------------------------------------------+
| ID | Description |
+------------------+------------------------------------------------+
| damaged | Required components are damaged. |
| | |
| data-unsupported | The data item referenced in a "send-data" |
| | request is not supported. |
| | |
| security-failure | The authenticity of the request or the |
| | authority of the requestor could not be |
| | verified. |
| | |
| unable | The action could not be accomplished (a |
| | generic error for use when no other code is |
| | appropriate). |
| | |
| unsupported | The "action" value is not supported. |
+------------------+------------------------------------------------+
+------------------+------------------------------------------------+
| ID | Description |
+------------------+------------------------------------------------+
| damaged | Required components are damaged. |
| | |
| data-unsupported | The data item referenced in a "send-data" |
| | request is not supported. |
| | |
| security-failure | The authenticity of the request or the |
| | authority of the requestor could not be |
| | verified. |
| | |
| unable | The action could not be accomplished (a |
| | generic error for use when no other code is |
| | appropriate). |
| | |
| unsupported | The "action" value is not supported. |
+------------------+------------------------------------------------+
Table 2: Emergency Call Action Failure Reasons Registry Initial Values
表2：紧急呼叫操作失败原因注册表初始值
This document registers the EmergencyCallData.eCall.MSD INFO package in the "Info Packages Registry".
本文档在“信息包注册表”中注册EmergencyCallData.eCall.MSD信息包。
Both endpoints (the IVS and the PSAP equipment) include EmergencyCallData.eCall.MSD in a Recv-Info header field per [RFC6086] to indicate the ability to receive INFO requests carrying data as described here.
两个端点（IVS和PSAP设备）都按照[RFC6086]在Recv Info头字段中包含EmergencyCallData.eCall.MSD，以指示接收携带此处所述数据的信息请求的能力。
Support for the EmergencyCallData.eCall.MSD INFO package indicates the ability to receive eCall related body parts as specified in this document.
对EmergencyCallData.eCall.MSD信息包的支持表示能够接收本文档中指定的eCall相关身体部位。
An INFO request message carrying body parts related to an emergency call as described in this document has an Info-Package header field set to "EmergencyCallData.eCall.MSD" per [RFC6086].
如本文档所述，携带与紧急呼叫相关的身体部位的信息请求消息的信息包标题字段根据[RFC6086]设置为“EmergencyCallData.eCall.MSD”。
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）可以使用信息包的应用程序和功能类型。
INFO requests associated with the EmergencyCallData.eCall.MSD 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.eCall.MSD信息包关联的信息请求包含与本文档中定义的紧急呼叫相关的数据。该应用程序是使用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, the SIP OPTIONS method, the 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 6, and is normally carried in the initial INVITE request and response; the use of the SIP INFO method only occurs when emergency-call-related data needs to be sent mid call. While the SIP MESSAGE method could
SIP INFO方法的使用基于对INFO方法与其他方法（包括SIP消息方法、SIP选项方法、SIP重新邀请方法、媒体平面传输和非SIP协议）的意图和效果的需求分析。特别是，根据第6节，紧急呼叫数据块的传输发生在SIP紧急对话中，通常在初始INVITE请求和响应中进行；仅当紧急呼叫相关数据需要在呼叫中发送时，才使用SIP INFO方法。而SIP消息方法可以
be used, it is not tied to a SIP dialog as is the SIP INFO method and thus might not be associated with the dialog. Either SIP OPTIONS or re-INVITE methods could also be used, but they are seen as less clean than the SIP 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 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.
如果使用，它不会像SIP INFO方法那样绑定到SIP对话框，因此可能不会与该对话框关联。也可以使用SIP选项或REINVITE方法，但它们被视为不如SIP 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.eCall.MSD
信息包名称为EmergencyCallData.eCall.MSD
None
没有一个
None
没有一个
The body for an EmergencyCallData.eCall.MSD INFO package is a multipart (normally multipart/mixed) body containing zero or one application/EmergencyCallData.eCall.MSD parts (containing an MSD) and zero or more application/EmergencyCallData.Control+xml (containing a metadata/control object) parts. At least one MSD or metadata/control body part is expected; the behavior upon receiving an INFO request with neither is undefined.
EmergencyCallData.eCall.MSD信息包的主体是一个多部分（通常为多部分/混合）主体，包含零个或一个application/EmergencyCallData.eCall.MSD部分（包含MSD）和零个或多个application/EmergencyCallData.Control+xml（包含元数据/控件对象）部分。至少需要一个MSD或元数据/控制体部件；未定义在接收到信息请求时的行为。
The body parts are sent per [RFC6086], and in addition, to align with how these body parts are sent in SIP messages other than INFO requests, 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消息（而非信息请求）中的发送方式保持一致，SIP消息顶层的Call INFO header字段引用了每个关联的身体部位。正文部分的内容处置标题字段设置为“按引用”。
An MSD or metadata/control block 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".
MSD或元数据/控制块始终包含在多部分正文部分中（即使它是SIP消息中唯一的正文部分）。仅包含与信息包关联的身体部位的最外层多部分的内容处置值为“INFO package”。
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 for the PSAP to request the IVS to send an updated MSD and for the IVS to send a requested MSD. Because this is normally done only on manual request of the PSAP call taker (who suspects some aspect of the vehicle state has changed), the rate of SIP INFO requests associated with the EmergencyCallData.eCall.MSD INFO package is normally quite low (most dialogs are likely to contain zero INFO requests, while others might carry an occasional request).
SIP INFO请求在已建立的紧急呼叫对话框中使用，用于PSAP请求IVS发送更新的MSD，并用于IVS发送请求的MSD。由于这通常仅在PSAP呼叫接受者（怀疑车辆状态的某些方面已发生变化）的手动请求下进行，因此与EmergencyCallData.eCall.MSD信息包相关的SIP信息请求率通常非常低（大多数对话框可能不包含任何信息请求，而其他对话框可能偶尔包含请求）。
The MIME media type registrations specified for use with this INFO package (Sections 14.3 and 14.4) contain a discussion of the security and/or privacy considerations specific to that data block. See Sections 11 and 12 for a discussion of the security and privacy considerations of the data carried in eCalls.
指定用于此信息包的MIME媒体类型注册（第14.3节和第14.4节）包含对特定于该数据块的安全和/或隐私注意事项的讨论。有关eCall中所载数据的安全和隐私注意事项的讨论，请参见第11节和第12节。
See Sections 6 and 7 for protocol details.
协议详情见第6节和第7节。
See Section 10 for protocol examples.
协议示例见第10节。
[MSD] European Committee for Standardization, "Intelligent transport systems - eSafety - eCall minimum set of data (MSD)", Standard: CEN - EN 15722, April 2015.
[MSD]欧洲标准化委员会，“智能交通系统-eSafety-eCall最小数据集（MSD）”，标准：CEN-EN 15722015年4月。
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, DOI 10.17487/RFC5031, January 2008, <http://www.rfc-editor.org/info/rfc5031>.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，DOI 10.17487/RFC5031，2008年1月<http://www.rfc-editor.org/info/rfc5031>.
[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>.
[CEN] "European Committee for Standardization (CEN)", <http://www.cen.eu>.
[CEN]“欧洲标准化委员会（CEN）”<http://www.cen.eu>.
[EN_16062] European Committee for Standardization, "Intelligent transport systems - eSafety - eCall High Level Application Requirements (HLAP) Using GSM/UMTS Circuit Switched Networks", Standard: CEN - EN 16062, April 2015.
[EN_16062]欧洲标准化委员会，“智能运输系统-电子安全-使用GSM/UMTS电路交换网络的eCall高级应用要求（HLAP）”，标准：CEN-EN 16062，2015年4月。
[EN_16072] European Committee for Standardization, "Intelligent transport systems - eSafety - Pan-European eCall operating requirements", Standard: CEN - EN 16072, April 2015.
[EN_16072]欧洲标准化委员会，“智能交通系统-电子安全-泛欧eCall操作要求”，标准：CEN-EN 16072，2015年4月。
[MSG_TR] ETSI, "Mobile Standards Group (MSG); eCall for VoIP", ETSI TR 103 140 V1.1.1, April 2014.
[MSG_TR]ETSI，“移动标准集团（MSG）；eCall for VoIP”，ETSI TR 103 140 V1.1.12014年4月。
[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>.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. Patel, "Public Safety Answering Point (PSAP) Callback", RFC 7090, DOI 10.17487/RFC7090, April 2014, <http://www.rfc-editor.org/info/rfc7090>.
[RFC7090]Schulzrinne，H.，Tschofenig，H.，Holmberg，C.，和M.Patel，“公共安全应答点（PSAP）回调”，RFC 7090，DOI 10.17487/RFC70902014年4月<http://www.rfc-editor.org/info/rfc7090>.
[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>.
[RFC8148] Gellens, R., Rosen, B., and H. Tschofenig, "Next-Generation Vehicle-Initiated Emergency Calls", RFC 8148, DOI 10.17487/RFC8148, May 2017, <http://www.rfc-editor.org/info/rfc8148>.
[RFC8148]Gellens，R.，Rosen，B.，和H.Tschofenig，“下一代车辆启动紧急呼叫”，RFC 8148，DOI 10.17487/RFC8148，2017年5月<http://www.rfc-editor.org/info/rfc8148>.
[SDO-3GPP] "3rd Generation Partnership Project (3GPP)", <http://www.3gpp.org/>.
[SDO-3GPP]“第三代合作伙伴计划（3GPP）”<http://www.3gpp.org/>.
[SDO-ETSI] "European Telecommunications Standards Institute (ETSI)", <http://www.etsi.org>.
[SDO-ETSI]“欧洲电信标准协会（ETSI）”<http://www.etsi.org>.
[TS22.101] 3GPP, "Universal Mobile Telecommunications System (UMTS); Service aspects; Service principles", 3GPP TS 22.101, version 8.7.0, Release 8, January 2008.
[TS22.101]3GPP，“通用移动通信系统（UMTS）；服务方面；服务原则”，3GPP TS 22.101，8.7.0版，第8版，2008年1月。
[TS23.167] 3GPP, "IP Multimedia Subsystem (IMS) emergency sessions", 3GPP TS 23.167, version 9.6.0, Release 9, March 2011.
[TS23.167]3GPP，“IP多媒体子系统（IMS）紧急会话”，3GPP TS 23.167，9.6.0版，第9版，2011年3月。
[TS24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229, version 12.6.0, Release 12, October 2014.
[TS24.229]3GPP，“基于会话启动协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”，3GPP TS 24.229，版本12.6.0，版本12，2014年10月发布。
Acknowledgments
致谢
We would like to thank Bob Williams and Ban Al-Bakri for their feedback and suggestions; Rex Buddenberg, Lena Chaponniere, Alissa Cooper, Keith Drage, Stephen Edge, Wes George, Mirja Kuehlewind, Allison Mankin, Alexey Melnikov, Ivo Sedlacek, and James Winterbottom for their review and comments; Robert Sparks and Paul Kyzivat for their help with the SIP mechanisms; and Mark Baker and Ned Freed for their help with the media subtype registration issue. We would like to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and Ulrich Dietz for their help with the original document upon which this document is based. Christer Holmberg deserves special mention for his many detailed reviews.
我们要感谢Bob Williams和Ban Al-Bakri的反馈和建议；雷克斯·布登伯格、莉娜·查蓬涅尔、艾莉莎·库珀、基思·德拉奇、斯蒂芬·埃奇、韦斯·乔治、米佳·库勒温德、艾利森·曼金、亚历克赛·梅尔尼科夫、伊沃·塞德莱克和詹姆斯·温特巴顿，感谢他们的评论和评论；Robert Sparks和Paul Kyzivat对SIP机制的帮助；马克·贝克和内德在媒体子类型注册问题上给予了帮助。我们要感谢Michael Montag、Arnoud van Wijk、Gunnar Hellstrom和Ulrich Dietz对本文件所依据的原始文件的帮助。克里斯特·霍姆伯格的许多详细评论值得特别提及。
Contributors
贡献者
Brian Rosen was a co-author of the original document upon which this document is based.
Brian Rosen是本文件所依据的原始文件的共同作者。
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
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