[要約] RFC 8147は、次世代のパンヨーロッパeCallに関する要約であり、目的は車両事故時の緊急通報システムの改善と、ヨーロッパ全域での統一されたeCallサービスの実現です。
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リクエストで伝送できるようにする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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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の欧州委員会のイニシアチブは1990年代後半に発案され、新しい車両での準拠車載システム（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.
Pan-European 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.
Legacy eCallは、Global System for Mobilecommunications（GSM）（2G）またはUniversal Mobile Telecommunications System（3GPP [SDO-3GPP]およびEuropean Standardization for Standardization（CEN）[CEN]）によって標準化されています。 UMTS）（3G）。通話設定のフラグは、通話をeCallとしてマークし、さらに、通話が自動的に開始されたか手動で開始されたかを示します。通話はeCall対応のPSAPにルーティングされ、車両とPSAPの間で音声チャネルが確立されます。eCallインバンドモデムは、定義された車両、センサー（衝突関連など）のセットを伝送するために使用されます。音声チャネル内の位置データ（データの最小セットまたはMSD）。同じ帯域内メカニズムがPSAPに使用され、PSAPはMSDの正常な受信を確認し、車両に新しいMSDを送信するように要求します（たとえば、車両またはその乗員の状態または場所が変更されたかどうかを確認します）。 NG-eCallは、回線交換からオールIPに移行し、車両データとeCallシグナリングを、追加のデータとして通話とともに伝送します。このドキュメントでは、次世代の汎ヨーロッパeCallのシグナリングとデータ交換を提供するために、IPベースの緊急コール（[RFC6443]と[RFC7852]を含む）のIETFメカニズムがどのように使用されるかについて説明します。
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).
European Telecommunications Standards Institute（ETSI）[SDO-ETSI]は、「Mobile Standards Group（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、レガシー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車両データ（MSD）およびメタデータ/制御データのMIMEメディアタイプと緊急コールデータタイプ、およびこのデータをSIP INFOリクエストで伝送できるようにする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で登録されています）。 INFOパッケージが定義されている（
Section 14.9) to enable these MIME types to be carried in SIP INFO requests, per [RFC6086].
セクション14.9）[RFC6086]に従って、これらのMIMEタイプをSIP INFOリクエストで伝送できるようにする。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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：3rd Generation Partnership Project
CEN: European Committee for Standardization
CEN：欧州標準化委員会
EENA: European Emergency Number Association
EENA：欧州緊急番号協会
ESInet: Emergency Services IP network
ESInet：緊急サービスIPネットワーク
IMS: IP Multimedia Subsystem
IMS：IPマルチメディアサブシステム
IVS: In-Vehicle System
IVS：車載システム
MNO: Mobile Network Operator
MNO：モバイルネットワークオペレーター
MSD: Minimum Set of Data
MSD：データの最小セット
PSAP: Public Safety Answering Point
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またはall-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ベースの環境（3GPP IMS緊急通話[TS23.167]など）内で動作するeCallに限定されています。
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の要件は、[EN_16072]のCENおよび[TS22.101]の3GPP、セクション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は、最小データセット（MSD）として知られる、車両関連データ（VIN、車両タイプ、推進タイプ、現在およびオプションで以前の位置座標、および乗員数を含む）の標準化された必須のセットを提供します。 CENは、このデータをASN.1およびXMLエンコーディングの両方とともにEN 15722 [MSD]で指定しています。回線交換eCallとこのドキュメントは両方とも、EN 15722 [MSD]のAnnex Aで指定されているASN.1 PERエンコーディングを使用します（3GPP [SDO-3GPP]に従い、Annex 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 PERエンコードオブジェクトとして、データはバイナリであり、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.
MSD車両データがNG-eCallでどのように伝達されるかについては、セクション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緊急コール内でデータブロックを伝達するための一般的なメカニズムを確立します。このドキュメントでは、そのメカニズムを利用して、SIPメッセージ内に車両データ（MSD、セクション5を参照）およびメタデータ/制御情報（セクション9を参照）を含めます。
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).
このドキュメントでは、INFOパッケージ（セクション14.9）も登録して、eCall関連のデータブロックをSIP INFOリクエストで伝送できるようにします（[RFC6086]に従い、新しいINFOの使用にはINFOパッケージの定義が必要です）。
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.
IVSは、MSD（セクション5を参照）をEN 15722 [MSD]のAnnex Aに従ってエンコードし、[RFC7852]に従ってSIPメッセージ内にMIMEボディパートとして含めることで送信します。ボディパーツは、ボディパーツのContent-TypeヘッダーフィールドのMIMEメディアタイプ（application / EmergencyCallData.eCall.MSD）によって識別されます。ボディパーツには、ボディパーツのContent-IDヘッダーフィールドにリストされている一意の識別子が割り当てられます。 SIPメッセージは、SIPメッセージの最上位にCall-Infoヘッダーフィールドを追加（または追加）することにより、MSDを含むものとしてマークされます。このCall-Infoヘッダーフィールドには、ボディパーツの一意の識別子を参照するコンテンツ識別子（CID）URLと、「緊急呼び出しデータタイプ」レジストリのエントリごとにデータをeCall MSDとして識別する「目的」パラメーターが含まれます。 「目的」パラメーターの値は「EmergencyCallData.eCall.MSD」です。 [RFC6086]に従い、MSDはセクション14.9で定義されたINFOパッケージを使用してSIP INFOリクエストで伝送されます。
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を参照）を送信します。ボディパーツは、ボディパーツのContent-TypeヘッダーフィールドのMIMEメディアタイプ（application / EmergencyCallData.Control + xml）で識別されます。ボディパーツには一意の識別子が割り当てられており、ボディパーツのContent-IDヘッダーフィールドにリストされています。 SIPメッセージは、SIPメッセージのトップレベルにCall-Infoヘッダーフィールドを追加（または追加）することにより、メタデータ/コントロールオブジェクトを含むものとしてマークされます。このCall-Infoヘッダーフィールドには、ボディパーツの一意の識別子を参照するCID URLと、「緊急コールデータタイプ」レジストリのエントリごとにeCallメタデータ/制御ブロックとしてデータを識別する「目的」パラメーターが含まれます。 「目的」パラメーターの値は「EmergencyCallData.Control」です。 [RFC6086]に従い、メタデータ/コントロールオブジェクトは、セクション14.9で定義されたINFOパッケージを使用して、SIP INFOリクエストで伝送されます。
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またはメタデータ/コントロールオブジェクトを含むボディパーツには、「By-Reference」を含むContent-Dispositionヘッダーフィールド値があります。
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には、最初のINVITE内のボディパーツとしてMSDが含まれ、オプションでPSAPにその機能を別のボディパーツとして通知するメタデータ/コントロールオブジェクトも含まれます。 MSDボディパーツ（およびメタデータ/コントロールとプレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）ボディパーツ（含まれている場合））には、 "By-Reference; Handling = optional"という値のContent-Dispositionヘッダーフィールドがあります。 「handling = optional」を指定すると、MSD（またはメタデータ/コントロールオブジェクトまたはPIDF-を理解しないレガシー要素（SIPと回線交換環境の間のゲートウェイなど）によって処理された場合に、SIP INVITE要求が拒否されなくなります。 LO）。
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は、MSDの受信を確認するメタデータ/コントロールオブジェクトを作成し、[RFC7852]に従ってSIP INVITEリクエストに対するSIP最終応答内のボディパーツとしてそれを含めます。メタデータ/コントロールオブジェクトは、暫定（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は、MSDを確認するメタデータ/コントロールオブジェクトを含め、SIP応答コード600（Busy Everywhere）486を使用する最終応答内に「received = true」を含めることで、状況を認識していることを示しながら、コールを拒否できます。 [RFC7852]に従い、Busy Here）、または603（Decline）。
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 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.
PSAPは、通話中に更新されたMSDを送信することを車両に要求できます（たとえば、車両の状態が変化したと疑うPSAPの通話担当者から手動で要求された場合）。そのために、PSAPはMSDを要求するメタデータ/コントロールオブジェクトを作成し、ダイアログ内で送信されるSIP INFO要求にそれを含めます。その後、IVSは更新されたMSDをSIP INFO要求内に含め、ダイアログ内で送信します。 IVSがMSDを送信できない場合、代わりに、「成功」パラメータが「false」に設定された<actionResult>要素と「理由」パラメータ（およびオプションで「詳細」パラメータ）、リクエストを実行できなかった理由を示します。 [RFC6086]に従い、メタデータ/コントロールオブジェクトとMSDは、セクション14.9で定義されたINFOパッケージを使用して送信されます。さらに、MSDまたはメタデータ/制御ブロックがINFO要求以外のSIPメッセージで送信される方法に合わせるため、[SIP INFO要求にCall-Infoヘッダーフィールドが含まれており、MSDまたはメタデータ/制御ブロックを[ RFC7852]。 SIP INFOリクエストを使用してeCall内でデータを伝送する方法については、セクション14.9を参照してください。
The IVS is not expected to send an unsolicited MSD after the initial INVITE.
IVSは、最初のINVITEの後に非送信請求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 +------+
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を示すRequest-URIを使用して緊急コールを確立します。 MNO（またはESInet）がeCall URNを認識し、コールをNG-eCall対応のPSAPにルーティングします。また、PSAPは、呼び出しとともに送信された車両データを解釈し、呼び出し担当者が利用できるようにします。
///-----\\\ 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.
MSDがNG-eCall内で転送される方法については、セクション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 an in-vehicle system, carrying a standardized set of data related to the vehicle and incident. These are registered in Section 14.2.
このドキュメントは、「sos」サブサービス内に新しいサービスURN子を追加します。これらのURNは、eCallが識別され、手動でトリガーされたeCallと自動的にトリガーされたeCallを区別するメカニズムを提供します（ポリシーに応じて、異なる扱いを受ける場合があります）。 2つのサービスURNは、urn：service：sos.ecall.automaticとurn：service：sos.ecall.manualです。これらは、車載システムによって発信された緊急コールに関連するリソースを要求し、車両と事件。これらはセクション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」はそのようなテスト機能を示します。 「テスト」サービスURNは[RFC6881]で定義されています。
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.)
このドキュメントでは、メタデータ/制御データのブロックを、eCallおよびその他の関連する緊急通話システムと拡張ポイントに使用される要素を含むXML構造として定義します。 （このメタデータ/制御ブロックは、実質的には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 as such in a SIP-based eCall emergency call. (See [RFC7852] for more information about the registry and how it is used.)
このドキュメントでは、application / EmergencyCallData.Control + xml MIMEメディアタイプを登録して、メタデータ/コントロールデータをSIPで伝送できるようにします。また、このドキュメントでは、「Control」を「Emergency Call Data Types」レジストリに追加して、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が、INFO以外のSIP要求でIVSによって送信されたデータに応答してメタデータ/制御ブロックを送信する場合（たとえば、最初のINVITEのMSD）、その要求に対するSIP応答でメタデータ/制御ブロックが送信されます（たとえば、INVITE要求に対する応答）。 PSAPが他の状況（通話中など）で制御ブロックを送信すると、制御ブロックは確立されたダイアログ内のSIP INFO要求でPSAPからIVSに送信されます。 IVSは要求されたデータ（MSD）を（[RFC6086]に従って）新しいSIP INFO要求で送信します。このメカニズムにより、PSAPがeCall固有のデータをIVSに送信し、IVSが応答できるようになります。 SIP INFO要求は、適切なINFOパッケージを使用して送信されます。 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が非送信請求MSDをSIP要求（たとえば、最初のINVITE）に含めると、PSAPは、要求に対するSIP応答でのMSDの受信の成功/失敗を示すメタデータ/制御ブロックを送信します。これは、NG-eCallが動作していることもIVSに通知します。 IVSがメタデータ/制御ブロックなしでSIP最終応答を受信した場合、それはSIPダイアログがNG-eCallではないことを示します（たとえば、コールの一部がレガシーコールとして処理されています）。 IVSが送信請求MSDを送信するとき（たとえば、MSDを要求するメタデータ/制御ブロックを含むSIP INFO要求の受信後に送信されるSIP INFO要求で）、PSAPは、受信の成功または失敗を示すメタデータ/制御ブロックを送信しません。 MSD。 （通常のSIP再送信は、要求されたデータの非受信を処理します。[RFC6086]によると、SIP INFO要求に対する200 OK応答は、受信者がSIP INFO要求を正常に受信して受け入れたことだけを示し、ペイロードの受け入れ可能性。）IVSがMSDを送信するリクエストを受信したが、何らかの理由でそれを行うことができない場合、IVSは代わりに、リクエストを確認するメタデータ/コントロールオブジェクトを送信します。 "パラメータは" 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 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.)
これにより、さまざまな状況に柔軟に対応できます。たとえば、PSAPがeCallを受け入れることができない場合（たとえば、同じ場所からの過負荷または呼び出しが多すぎるため）、INVITEを拒否できます。コールを拒否するメタデータ/コントロールオブジェクトもSIP応答に含まれているため、IVSは、PSAPがMSDを受信したかどうかを認識し、PSAPが車両の位置と情報を正常に受信したが、その時の居住者。特に、（リクエストを処理する技術的な無力とは対照的に）コールを実行できないことを示すSIP応答コードの場合、IVSは、技術レベルでコールが成功したと判断することもできます（たとえば、回線交換時に再試行するのに役立ちません） ）。 （PSAP応答がIVSによって受信されないというエッジケースがあることに注意してください。たとえば、仲介者がCANCELを送信し、PSAPからのエラー応答が受信される前にエラー応答がIVSに転送された場合、応答はドロップされますが、これらはここでは発生しそうにありません。）
The metadata/control block is carried in the MIME type application/ EmergencyCallData.Control+xml.
メタデータ/制御ブロックは、MIMEタイプapplication / EmergencyCallData.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メディアタイプとメタデータ/コントロールオブジェクトに対応するために新しいINFOパッケージを登録する必要がある場合があることに注意してください。
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メディアタイプで身体の一部に入れて運ばれます。制御ブロック内で使用する3つの要素が定義されています。
ack Acknowledges receipt of data or a request.
ackデータまたは要求の受信を確認します。
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.
request 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>要素には、リクエストを示し、関連情報を提供するための属性が含まれています。 「アクション」属性は必須であり、特定のアクションを示します。セクション14.8.1で、許可された値を含むIANAレジストリが作成されます。
The <capabilities> element has child <request> elements to indicate the actions supported by the IVS.
<capabilities>要素には、IVSでサポートされるアクションを示す子<request>要素があります。
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.
<ack>要素は、eCallデータオブジェクトまたはリクエストの受信を確認します。 <ack>要素は、確認応答されるオブジェクトのContent-IDを参照します。 PSAPは、（たとえば、INVITEのIVSによって送信された）非送信請求MSDの受信を確認する<ack>要素を送信する必要があります。この<ack>要素は、PSAPがMSDを正常に受信したと見なすかどうかを示します。 <ack>要素は<capabilities>要素に送信されません。
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: 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>要素は、アクション（正常に実行された「send-data」アクション以外）の結果を示します。 <ack>要素には、正常に実行された「データ送信」アクションではない各<request>要素の<actionResult>要素が含まれています。 <actionResult>要素には次の属性があります。
Name: action Usage: Mandatory Type: token Description: Contains the value of the "action" attribute of the <request> element
名前：action使用法：必須タイプ：トークン説明：<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">
<ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.Control>
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に示します。この要素の属性は現在定義されていません。 1つの子要素が定義されています。
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>
<機能>
<request action="send-data" supported-values="eCall.MSD" />
</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>アクションが、 "datatype"が "eCall.MSD"に設定された "send-data"であることを示します。
<?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>
</EmergencyCallData.Control>
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>要素の子として1回以上出現します。これにより、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: 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" Name: persistence Usage: Optional Type: duration Direction: Sent in either direction
名前：int-id使用法：条件付きタイプ：unsignedInt方向：どちらの方向にも送信される説明：拡張性のために定義されています。それを利用する文書は、それがいつ必要とされ、どのように使用されるかを説明することが求められます。例：int-id = "3"名前：永続性使用法：オプションタイプ：期間方向：どちらの方向にも送信
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"
名前：データ型使用法：条件付きタイプ：トークン方向：どちらの方向にも送信される説明：<capabilities>要素内にない<request>要素内の「send-data」アクションで必須です。 IVSが送信を要求されるデータブロックを指定します。データブロックを指すようにCall-Infoヘッダーフィールドに設定された「purpose」属性と同じ識別子を使用します。許可される値は、[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.
名前：element-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">
<request action="send-data" datatype="eCall.MSD"/>
</EmergencyCallData.Control>
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サービスURNを使用し、eCallとして認識されます。さらに、クラッシュまたはその他の重大なインシデントのためにIVSによって自動的に呼び出されたものとして認識されます。この例では、発信元ネットワークが通話をESInetにルーティングし、ESInetが適切なNG-eCall対応のPSAPに通話をルーティングします。緊急コールは、ESInetへのエントリポイントとして、ESInetの緊急サービスルーティングプロキシ（ESRP）によって受信されます。 ESRPはコールをPSAPにルーティングし、そこでコールテイカーが受信します。 ESInetがない展開では、発信元のネットワークが適切なNG-eCall対応のPSAPに直接呼び出しをルーティングします。この図は、ESInetまたはESRPがないことを除いて、以下の図と同じです。
+-----------+ +----------------------------------------+
| | | +-------+ |
| | | | 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は、更新されたMSDに対する通話中のPSAP要求を使用したeCallコールフローを示しています。コールフローは、INVITEのMSDを含む、IVSが緊急コールを開始することを示しています。 PSAPは、200 OK応答に、MSDの受信を確認するメタデータ/コントロールオブジェクトを含めます。コール中に、PSAPはINFO要求でMSDの要求を送信します。 IVSは、要求されたMSDを新しいINFO要求で送信します。
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ヘッダー、Session Description Protocol（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: ...
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; border = boundary1 Content-Length：...
--boundary1
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here...
... Session Description Protocol（SDP）がここに入ります...
--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
...MSD in ASN.1 PER encoding goes here...
... ASN.1 PERエンコーディングのMSDがここに入ります...
--boundary1--
--boundary1--
Figure 8: SIP NG-eCall INVITE
図8：SIP NG-eCall INVITE
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は、eCall MSDの正常な受信を確認するメタデータ/制御ブロックを含む、図8のINVITE要求に対するSIP 200 OK応答を示しています。 （簡単にするために、この例ではすべての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 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; border = boundaryX Content-Length：...
--boundaryX
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here...
... Session Description Protocol（SDP）がここに入ります...
--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">
<ack received="true" ref="1234567890@atlanta.example.com"/>
</EmergencyCallData.Control>
--boundaryX--
--boundaryX--
Figure 9: 200 OK Response to INVITE
図9：INVITEに対する200 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は、eCall MSDを要求するメタデータ/制御ブロックを含むSIP INFO要求を示しています。 （簡単にするために、この例ではすべての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: ...
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; border = boundaryZZZ Content-Disposition：Info-Package Content-Length：...
--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">
<request action="send-data" datatype="eCall.MSD"/>
</EmergencyCallData.Control>
--boundaryZZZ--
Figure 10: INFO Requesting MSD
図10：MSDを要求するINFO
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 INFO要求を示しています。簡単にするために、この例ではすべての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: ...
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 ; border = boundaryLine Content-Disposition：Info-Package Content-Length：...
--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 PERエンコーディングのMSDがここに入ります...
--boundaryLine--
- 境界線 -
Figure 11: INFO Containing MSD
図11：MSDを含むINFO
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提供の場所を伝達します。これは、特にネットワーク提供のロケーションが含まれていない場合、または2つのロケーションが独立して決定されている場合に、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（Busy Everywhere）、486（Busy Here）、または603（Decline）応答を生成する可能性があることに注意してください。最初の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.
外部ソースから受信したデータには、本質的に実装リスクがあります。たとえば、プラットフォームによっては、バッファオーバーフローによってリモートコード実行の脆弱性が発生したり、null文字によって文字列が破損したり、内部計算に使用される数値によってアンダーフロー/オーバーフローエラーが発生したり、不正な形式の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.)
車両データまたはコントロール/メタデータが署名または暗号化されたボディパーツに含まれている場合、囲んでいるマルチパート（例：multipart / signedまたはmultipart / encrypted）は、囲まれたデータパーツと同じContent-IDを持ちます。これにより、エンティティは、関心のあるデータブロックを識別してアクセスすることができます。メッセージ構造を深く掘り下げたり、関心のない部分を復号化したりする必要はありません。（Call-Infoヘッダーフィールドの「purpose」パラメータは、データと本文のデータブロックを指すCID URLが含まれ、一致するContent-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">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<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: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: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="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: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.
このドキュメントは、「application / EmergencyCallData」をルートとする新しいメディアサブツリーである「EmergencyCallData」メディア（MIME）サブタイプツリーを確立します。このサブツリーは、緊急通信に関連するコンテンツにのみ使用されます。このサブツリーの新しいサブタイプは、[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は、URN urn：service：sos.ecallを[RFC5031]のセクション4.2で定義されている「 'sos' Sub-Services」レジストリに登録しています。
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:
このサービスは、車載システムによって行われた緊急通報に関連するリソースを要求し、車両とインシデントに関連する標準化されたデータのセットを伝送します。 「説明」レジストリフィールドは「車両起動の緊急通報」です。 2つのサブサービスも登録されています。
urn:service:sos.ecall.automatic
urn：service：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：service：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で定義されている「 'test' Sub-Services」レジストリの下にURN urn：service：test.sos.ecallを登録しています。このサービスは、車載システムによって行われたテスト（緊急ではない）呼び出しに関連するリソースを要求します。テストeCallリクエストURNの詳細については、セクション8を参照してください。
14.3. MIME Media Type Registration for application/ EmergencyCallData.eCall.MSD
14.3. application / 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]のガイドラインに従って、このドキュメントを参照し、MIMEメディアタイプとしてapplication / EmergencyCallData.eCall.MSDを追加しました。
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
詳細情報の人とメールアドレス：Randall Gellens、rg + 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. application / 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
オプションのパラメーター：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].
エンコードに関する考慮事項：使用する文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。 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.
セキュリティに関する考慮事項：このメディアタイプは、緊急通報中に、Public Safety Answering Point（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からのコールバックは、現在のメカニズムがこのようなコールが、IVSによって発信された緊急コールへの応答としてのPSAPからのコールバックであることを確認するのには理想的ではありません。セクション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ファイルタイプコード：TEXT
Person and email address for further information: Randall Gellens, rg+ietf@randy.pensive.org
詳細情報の人とメールアドレス：Randall Gellens、rg + 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」エントリを「緊急コールデータタイプ」レジストリに追加し、このドキュメントへの参照を追加しました。 「Data About」の値は「The Call」です。
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は、このドキュメントへの参照とともに、「緊急通報データタイプ」レジストリに「制御」エントリを追加しました。 「Data About」の値は「The Call」です。
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
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@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
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 |
+-----------+--------------------------------------+
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.
このドキュメントは、「actionCall」要素の「reason」属性の値を含む「Emergency Call Action Failure Reasons」と呼ばれる新しいサブレジストリを作成します。 [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. |
+------------------+------------------------------------------------+
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".
このドキュメントは、「Info Packages Registry」にEmergencyCallData.eCall.MSD INFOパッケージを登録します。
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を含めて、ここで説明するようにデータを運ぶINFO要求を受信する機能を示します。
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 INFOパッケージのサポートは、このドキュメントで指定されている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].
このドキュメントで説明されているように、緊急コールに関連するボディパーツを運ぶINFOリクエストメッセージには、[RFC6086]に従ってInfo-Packageヘッダーフィールドが「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.
このセクションでは、INFOパッケージに関連付けられているINFOリクエストで伝達される情報のタイプと、ユーザーエージェント（UA）がINFOパッケージを使用できるアプリケーションと機能のタイプについて説明します。
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 INFOパッケージに関連付けられているINFOリクエストは、このドキュメントで定義されているように、緊急コールに関連付けられているデータを伝送します。アプリケーションは、SIPを使用して確立された車両起動の緊急コールです。機能は、車両とPSAPの間で車両データとメタデータ/制御情報を運ぶことです。
This section describes why the INFO package mechanism, rather than some other mechanism, has been chosen for the specific use case.
このセクションでは、他のメカニズムではなくINFOパッケージメカニズムが特定のユースケースに選択された理由について説明します。
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 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メソッドの使用は、INFOメソッドと他のアプローチ（SIP MESSAGEメソッド、SIP OPTIONSメソッド、SIP re-INVITEメソッド、メディアプレーンを含む）の意図と効果に対する要件の分析に基づいています。トランスポート、および非SIPプロトコル）。特に、緊急コールデータブロックの転送は、セクション6に従ってSIP緊急ダイアログ内で行われ、通常、最初のINVITE要求と応答で伝送されます。 SIP INFOメソッドの使用は、緊急通話関連のデータを通話中に送信する必要がある場合にのみ発生します。 SIP MESSAGEメソッドは使用できますが、SIP INFOメソッドのようにSIPダイアログに関連付けられていないため、ダイアログに関連付けられていない場合があります。 SIP OPTIONSまたはre-INVITEメソッドも使用できますが、SIP INFOメソッドよりもクリーンではないと見なされます。 SIP SUBSCRIBE / NOTIFYメソッドは強制的にサービスに組み込むことができますが、セマンティクスは適切ではありません。たとえば、subscribe / notifyメカニズムは、notifierからサブスクライバーへの（多くの場合は複数の）通知からなる一方向通信を提供し、notifier内の特定のイベントを示しますここで必要なのは、緊急ダイアログに関連するデータの双方向通信です。ダイアログで交換する必要のあるメッセージの数は通常ゼロまたはごくわずかであり、データのサイズも同様に非常に小さいため、メディアプレーンメカニズムの使用は割り引かれました。ユーザープレーンのセットアップ（メッセージセッションリレープロトコル（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
INFOパッケージ名は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 INFOパッケージの本体は、ゼロまたは1つのapplication / EmergencyCallData.eCall.MSDパーツ（MSDを含む）と0以上のapplication / EmergencyCallData.Control + xml（メタデータ/コントロールオブジェクトを含む）パーツ。少なくとも1つのMSDまたはメタデータ/コントロールボディパーツが必要です。どちらも含まないINFOリクエストを受け取ったときの動作は未定義です。
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]に従って送信され、さらに、これらのボディパーツがINFOリクエスト以外のSIPメッセージで送信される方法に合わせて、関連する各ボディパーツは、最上位のCall-Infoヘッダーフィールドによって参照されます。 SIPメッセージ。ボディパーツのContent-Dispositionヘッダーフィールドは "By-Reference"に設定されています。
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パッケージに関連付けられたボディパーツのみを含む最も外側のマルチパートのContent-Disposition値は「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 INFOパッケージに関連付けられたSIP INFOリクエストのレートは通常非常に低くなります（ほとんどのダイアログINFOリクエストが含まれていない可能性がありますが、他のリクエストはときどきリクエストを運ぶ場合があります）。
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.
このINFOパッケージで使用するために指定された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 15722、2015年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。、「The IETF XML Registry」、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。、「緊急およびその他の既知のサービスのためのUniform Resource Name（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、「RFCで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.、Berger、E。、およびH. Kaplan、「Session Initiation Protocol（SIP）INFO Method and Package Framework」、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、「Media Type Specifications and Registration Procedures」、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]ローゼン、B。およびJ.ポーク、「緊急通話をサポートする通信サービスの現在のベストプラクティス」、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 Media Types」、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]欧州標準化委員会、「インテリジェントトランスポートシステム-eSafety-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]欧州標準化委員会、「インテリジェントトランスポートシステム-eSafety-汎ヨーロッパ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、「Mobile Standards Group（MSG）; eCall for VoIP」、ETSI TR 103 140 V1.1.1、2014年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、編、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、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、「Framework for Emergency Calling Using Internet Multimedia」、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、「Public Safety Answering Point（PSAP）Callback」、RFC 7090、DOI 10.17487 / RFC7090、2014年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、編集、「信頼できる場所」、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]「第3世代パートナーシッププロジェクト（3GPP）」、<http://www.3gpp.org/>。
[SDO-ETSI] "European Telecommunications Standards Institute (ETSI)", <http://www.etsi.org>.
[STO-ETSI] "欧州電気通信標準化機構（ETSI）"、
[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のフィードバックと提案に感謝します。 Rex Buddenberg、Lena Chaponniere、Alissa Cooper、Keith Drage、Stephen Edge、Wes George、Mirja Kuehlewind、Allison Mankin、Alexey Melnikov、Ivo Sedlacek、James Winterbottomのレビューとコメント。 Robert SparksとPaul KyzivatがSIPメカニズムを支援してくれました。マーク・ベイカーとネッド・フリードは、メディアのサブタイプ登録の問題に協力してくれました。このドキュメントの基になっている元のドキュメントを手伝ってくれたMichael Montag、Arnoud van Wijk、Gunnar Hellstrom、およびUlrich Dietzに感謝します。 Christer Holmbergは、彼の多くの詳細なレビューについて特別な言及に値します。
Contributors
貢献者
Brian Rosen was a co-author of the original document upon which this document is based.
ブライアンローゼンは、このドキュメントの基となった元のドキュメントの共著者でした。
Authors' Addresses
著者のアドレス
Randall Gellens Core Technology Consulting
Randall Gellensコアテクノロジーコンサルティング
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