[要約] RFC 8864は、SDPを使用してデータチャネルを交渉するための標準を定義しています。このRFCの目的は、WebRTCなどのリアルタイムコミュニケーションアプリケーションでデータチャネルを効果的に交渉するための手順を提供することです。
Internet Engineering Task Force (IETF) K. Drage
Request for Comments: 8864 M. Makaraju
Category: Standards Track R. Ejzak
ISSN: 2070-1721 J. Marcon
Unaffiliated
R. Even, Ed.
January 2021
Negotiation Data Channels Using the Session Description Protocol (SDP)
セッション記述プロトコル（SDP）を使用したネゴシエーションデータチャネル
Abstract
概要
Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel.
データチャネル設定は、インバンドデータチャネル確立プロトコル（DCEP）または一部の帯域外非DCEPプロトコルのいずれかを使用して行うことができます。このドキュメントは、データチャネルを確立するための帯域外の非DCEPネゴシエーションを実現するためにSDP（セッション記述プロトコル）オファー/回答を使用する方法を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8864.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc8864で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Conventions
3. Terminology
4. Applicability Statement
5. SDP Data Channel Attributes
5.1. SDP DCMAP Attribute
5.1.1. DCMAP Attribute Syntax
5.1.2. 'dcmap-stream-id' Parameter
5.1.3. 'label' Parameter
5.1.4. 'subprotocol' Parameter
5.1.5. 'max-retr' Parameter
5.1.6. 'max-time' Parameter
5.1.7. 'ordered' Parameter
5.1.8. 'priority' Parameter
5.1.9. DCMAP Multiplexing Category
5.2. SDP DCSA Attribute
5.2.1. DCSA Attribute Syntax
5.2.2. DCSA Multiplexing Category
6. SDP Offer/Answer Procedures
6.1. Managing Stream Identifiers
6.2. Negotiating Data Channel Parameters
6.3. Generating the Initial Offer for a Data Channel
6.4. Generating the SDP Answer
6.5. Offerer Processing of the SDP Answer
6.6. Modifying the Session
6.6.1. Closing a Data Channel
6.7. Various SDP Offer/Answer Considerations
7. Examples
8. Security Considerations
9. IANA Considerations
9.1. Subprotocol Identifiers
9.2. New SDP Attributes
9.2.1. dcmap
9.2.2. dcsa
9.3. Registering Attributes for Use with Data Channels
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Generic Data Channel Negotiation Aspects when Not
Using DCEP
A.1. Stream Identifier Numbering
A.2. Generic Data Channel Negotiation Not Using DCEP
A.2.1. Overview
A.2.2. Opening a Data Channel
A.2.3. Closing a Data Channel
Acknowledgements
Contributors
Authors' Addresses
The concept of establishing a bidirectional data channel running on top of the Stream Control Transmission Protocol (SCTP) is discussed in [RFC8831], allowing applications to use data channels. An in-band Data Channel Establishment Protocol (DCEP) is described in [RFC8832]; however, other in-band or out-of-band protocols may be used for establishing data channels. Each data channel consists of paired SCTP streams sharing the same SCTP Stream Identifier. Data channels are created by endpoint applications using (1) the WebRTC API (Application Programming Interface) [WebRtcAPI] or (2) other protocols (e.g., Controlling Multiple Streams for Telepresence (CLUE) [RFC8850]). The protocols can be signaled by the data channel 'subprotocol' parameter, conceptually similar to a WebSocket subprotocol as described in [RFC6455]. However, apart from the "subprotocol" value transmitted to the peer, an endpoint application can agree on how to instantiate a given subprotocol on a data channel, and whether it is signaled in-band using DCEP or out-of-band using a non-DCEP protocol (or both).
ストリーム制御伝送プロトコル（SCTP）の上で実行されている双方向データチャネルを確立するという概念は[RFC8831]で説明されており、アプリケーションはデータチャネルを使用できるようにします。インバンドデータチャネル確立プロトコル（DCEP）は[RFC8832]に記載されている。しかしながら、データチャネルを確立するために他のインバンドまたはアウトオブバンドプロトコルを使用することができる。各データチャネルは、同じSCTPストリーム識別子を共有するペアリングされたSCTPストリームで構成されています。データチャネルは、（1）WebRTC API（Application Programming Interface）[WEBRTCAPI]または（2）他のプロトコル（例えば、TelePresence（Clue）[RFC8850]）を使用してエンドポイントアプリケーションによって作成されます。プロトコルは、[RFC6455]で説明されているように、データチャネル 'subprotocol'パラメータによってシグナリングすることができます。しかしながら、ピアに送信された「サブプロタコジ」値とは別に、エンドポイントアプリケーションは、データチャネル上の特定のサブプロトコルをインスタンス化する方法、およびそれが非帯域または非帯域を使用して非帯域内でシグナリングされているかどうかについてのエンドポイントアプリケーションが一致することができる。 -DCEPプロトコル（またはその両方）。
This document defines Session Description Protocol (SDP) offer/answer procedures [RFC3264] that enable out-of-band negotiation for establishing data channels for transport of well-defined subprotocols. These procedures are based on generic SDP offer/answer negotiation rules for SCTP-based media transport as specified in [RFC8841] for the SDP "m=" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.
このドキュメントでは、明確に定義されたサブプロトコルのトランスポートのためにデータチャネルを確立するための帯域外のネゴシエーションを可能にするセッション記述プロトコル（SDP）オファー/アンサープロシージャ[RFC3264]を定義します。これらの手順は、SDPの「M =」回線Proto値UDP / DTLS / SCTPおよびTCP / DTLS / SCTPの[RFC8841]で指定されているSCTPベースのメディアトランスポートの一般的なSDPオファー/アンサートランス化ルールに基づいています。
This document uses MSRP (the Message Session Relay Protocol) [RFC4975] and BFCP (the Binary Floor Control Protocol) [RFC8855] in several examples. It does not provide a complete specification of how to negotiate the use of a data channel to transport MSRP. Procedures specific to each subprotocol would have to be documented elsewhere. For MSRP, they are documented in [RFC8873]. The use of MSRP in some examples is only to show how the generic procedures described herein might apply to a specific subprotocol.
この文書では、いくつかの例では、MSRP（Message Session Relay Protocol）[RFC4975]とBFCP（BFC4975] [RFC8855]を使用しています。MSRPを転送するためのデータチャネルの使用をネゴシエートする方法を完全に指定していません。各サブプロトコルに固有の手順は他の場所に文書化されなければなりません。MSRPの場合、それらは[RFC8873]に文書化されています。いくつかの例でのMSRPの使用は、本明細書に記載されている一般的な手順が特定のサブプロトコルにどのように適用され得るかを示すためにのみ示されている。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
This document uses the following terms:
この文書は次の条件を使用しています。
Data channel: A WebRTC data channel as specified in [RFC8831].
データチャネル：[RFC8831]で指定されているWebRTCデータチャネル。
Data channel stack: An entity that, upon application request, runs the data channel protocol to keep track of states as well as the sending and receiving of data. If the application is a browser-based JavaScript application, then this stack resides in the browser. If the application is a native application, then this stack resides in the application and is accessible via some sort of API or APIs.
データチャネルスタック：アプリケーション要求時にデータチャネルプロトコルを実行して、データの送受信と同様に状態を追跡するためにデータチャネルプロトコルを実行するエンティティ。アプリケーションがブラウザベースのJavaScriptアプリケーションの場合、このスタックはブラウザにあります。アプリケーションがネイティブアプリケーションである場合、このスタックはアプリケーションにあり、ある種のAPIまたはAPIを介してアクセス可能です。
Data channel properties: Fixed properties assigned to a data channel at the time of its creation. Some of these properties determine the way the data channel stack transmits data on this channel (e.g., stream identifier, reliability, order of delivery).
データチャネルのプロパティ：作成時にデータチャネルに割り当てられた固定プロパティ。これらのプロパティのいくつかは、データチャネルスタックがこのチャネル上のデータを送信する方法（例えば、ストリーム識別子、信頼性、配信順）を決定する。
Data channel subprotocol: The application protocol that is transported over a single data channel. Data channel subprotocol messages are sent as data channel payload over an established data channel. An SDP offer/answer exchange can be used as specified in this document to negotiate the establishment of data channels, corresponding data channel properties, associated data channel subprotocols, and data channel subprotocol properties. In this case, the data channel subprotocols may be identified by the values of the 'subprotocol' parameters of the SDP "a=dcmap:" attribute as described in Section 5.1.4. Within this document, the term "data channel subprotocol" is often abbreviated as just "subprotocol".
データチャネルサブプロトコル：単一のデータチャネルを介して転送されるアプリケーションプロトコル。データチャネルサブプロトコルメッセージは、確立されたデータチャネル上でデータチャネルペイロードとして送信されます。データチャネルの確立、対応するデータチャネルプロパティ、関連データチャネルサブプロトコル、およびデータチャネルサブプロテクトコピープロパティの確立をネゴシエートするために、このドキュメントで指定されているようにSDPオファー/回答Exchangeを使用できます。この場合、データチャネルサブプロトコルは、セクション5.1.4で説明されているように、SDPの「A = DCMAP：」属性の「サブプロタ」パラメータの値によって識別され得る。この文書内では、「データチャネルサブプロトコル」という用語はしばしば「サブプロトコル」と略される。
DCEP: Data Channel Establishment Protocol, as defined in [RFC8832].
DCEP：[RFC8832]で定義されているように、データチャネル確立プロトコル。
In-band: Transmission through the peer-to-peer SCTP association.
帯域内：ピアツーピアSCTPアソシエーションを介した伝送。
Out-of-band: Transmission through the application signaling path.
帯域外：アプリケーションシグナリングパスを介した伝送。
Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDP offerer.
ピア：セッション内のエージェントの1つの観点から、そのピアは他のエージェントです。具体的には、SDPオファーの観点からは、ピアはSDP回答者です。SDP回答者の観点からは、ピアはSDPオファーです。
SCTP Stream Sequence Number (SSN): The SCTP Stream Sequence Number, as specified in [RFC4960].
SCTPストリームシーケンス番号（SSN）：[RFC4960]で指定されているSCTPストリームシーケンス番号。
Stream identifier: The identifier of the outbound and inbound SCTP streams composing a data channel.
ストリーム識別子：データチャネルを構成する発信SCTPストリームとインバウンドSCTPストリームの識別子。
The mechanism described in this document only applies to SDP [RFC8866] when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope for this document and is thus undefined.
この文書に記載されているメカニズムは、SDPオファー/アンサーメカニズム[RFC3264]と一緒に使用した場合にのみSDP [RFC8866]に適用されます。SDPの宣言的な使用法はこの文書に対して範囲外であり、したがって未定義です。
This section defines two new SDP media-level attributes that can be used together with the SDP Offer/Answer mechanism to negotiate data-channel-specific and subprotocol-specific parameters without the usage of DCEP [RFC8832]. The first attribute (Section 5.1) provides for negotiation of channel-specific parameters. The second attribute (Section 5.2) provides for negotiation of subprotocol-specific parameters.
このセクションでは、DCEP [RFC8832]を使用せずに、データチャネル固有およびサブプロタクシャルパラメータをネゴシエートするためのSDPオファー/アンサーメカニズムと一緒に使用できる2つの新しいSDPメディアレベル属性を定義します。最初の属性（セクション5.1）は、チャネル固有のパラメータのネゴシエーションを提供します。2番目の属性（セクション5.2）は、サブプロトコル固有のパラメータのネゴシエーションを提供します。
| Note: Appendix A provides information regarding how data
| channels work in general. In particular, it summarizes some
| key aspects that should be considered for the negotiation of
| data channels if DCEP is not used.
This section defines a new media-level attribute, "a=dcmap:", that defines the data channel parameters for each data channel to be negotiated.
このセクションでは、ネゴシエートする各データチャネルのデータチャネルパラメータを定義する新しいメディアレベルの属性 "A = DCMAP："を定義します。
This attribute is used to create bidirectional SCTP data channels having the same set of attributes. The data channel properties (reliable / partially reliable, ordered/unordered) need to be suitable per the subprotocol transport requirements.
この属性は、同じ属性セットを持つ双方向SCTPデータチャネルを作成するために使用されます。データチャネルのプロパティ（信頼性/部分的に信頼できる、注文/順序付けされていない）は、サブプロトコルのトランスポート要件に適している必要があります。
"a=dcmap:" is a media-level attribute having the following definition and ABNF (Augmented Backus-Naur Form) syntax [RFC5234].
「A = DCMAP：」は、以下の定義とABNF（拡張バックス - ナウルフォーム）構文[RFC5234]を持つメディアレベルの属性です。
+=================================+
| "a=dcmap:" Attribute |
+===================+=============+
| Name | dcmap |
+-------------------+-------------+
| Value | dcmap-value |
+-------------------+-------------+
| Usage Level | media |
+-------------------+-------------+
| Charset Dependent | No |
+-------------------+-------------+
Table 1: "a=dcmap:" Attribute Definition
表1： "A = DCMAP："属性定義
Formal syntax:
正式な構文：
dcmap-value = dcmap-stream-id
[ SP dcmap-opt *(";" dcmap-opt) ]
dcmap-opt = ordering-opt / subprotocol-opt / label-opt
/ maxretr-opt / maxtime-opt / priority-opt
; maxretr-opt and maxtime-opt are
; mutually exclusive
dcmap-stream-id = 1*5DIGIT
ordering-opt = "ordered=" ordering-value
ordering-value = "true" / "false"
subprotocol-opt = "subprotocol=" quoted-string
label-opt = "label=" quoted-string
maxretr-opt = "max-retr=" maxretr-value
maxretr-value = "0" / integer
; number of retransmissions,
; less than 2^32,
; derived from 'Reliability Parameter' [RFC8832]
maxtime-opt = "max-time=" maxtime-value
maxtime-value = "0" / integer
; milliseconds,
; less than 2^32,
; derived from 'Reliability Parameter' [RFC8832]
priority-opt = "priority=" priority-value
priority-value = "0" / integer
; unsigned integer value indicating the priority of
; the data channel,
; less than 2^16,
; derived from 'Priority' [RFC8832]
quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE
quoted-char = SP / quoted-visible
quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
escaped-char = "%" HEXDIG HEXDIG
DQUOTE = <from RFC 5234>
integer = <from RFC 8866>
Examples:
例：
a=dcmap:0
a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
| Note: The last example (a=dcmap:4) shows a 'label' parameter
| value that contains one nonprintable 'escaped-char' character
| (the tabulator character).
Within an "a=dcmap:" attribute line's 'dcmap-opt' value, only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be present. Both parameters MUST NOT be present.
「A = DCMAP：」属性回線の「dcmap-opt」値では、 'maxretr-opt'パラメータまたは1つの 'maxtime-opt'パラメータのみが存在する可能性があります。両方のパラメータが存在してはいけません。
The 'dcmap-stream-id' parameter indicates the SCTP stream identifier within the SCTP association used to form the data channel.
'dcmap-stream-id'パラメータは、データチャネルを形成するために使用されるSCTPアソシエーション内のSCTPストリーム識別子を示します。
The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [RFC8832]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string.
'label'パラメータはチャネルの名前を示します。これは、WEBRTC API [WEBRTCAPI]のコンテキストで、他のRTCDataChannelオブジェクトからのRTCDataChannelオブジェクトのコンテキストで使用できるラベルを表します。このパラメータは[RFC8832]で定義されている「Label」パラメータにマッピングされます。'label'パラメータはオプションです。存在しない場合、その値はデフォルトで空の文字列になります。
In order to communicate with the WebRTC API, the 'label' parameter should
WEBRTC APIと通信するために、 'Label'パラメータは
* Serialize the WebRTC label as a UTF-8 string [RFC3629].
* WebRTCラベルをUTF-8文字列としてシリアル化します[RFC3629]。
* Treat the UTF-8 serialization as a series of bytes.
* UTF-8シリアライゼーションを一連のバイトとして扱います。
* For each byte in the serialization,
* シリアル化の各バイトについて、
- If the byte can be expressed as a 'quoted-char', do so.
- バイトを 'quoted-char'として表現できる場合は、そうします。
- Otherwise, express the byte as an 'escaped-char'.
- それ以外の場合は、バイトを「エスケープ文字」として表します。
| Note: The empty string can also be explicitly used as a 'label'
| value, such that 'label=""' is equivalent to the 'label'
| parameter not being present at all. [RFC8832] allows the
| DATA_CHANNEL_OPEN message's 'Label' value to be an empty
| string.
The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in [RFC8832]. Section 9.1 specifies how values for new subprotocol parameters are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to an empty string.
'subprotocol'パラメータは、クライアントがチャネルを介して交換することを期待しているプロトコルを示します。このパラメータは[RFC8832]で定義されている「プロトコル」パラメータにマッピングされます。セクション9.1新しいサブプロトコルパラメータの値を登録する方法を指定します。'subprotocol'はオプションのパラメータです。'subprotocol'パラメータが存在しない場合、その値はデフォルトで空の文字列になります。
| Note: The empty string can also be explicitly used as a
| 'subprotocol' value, such that 'subprotocol=""' is equivalent
| to the 'subprotocol' parameter not being present at all.
| [RFC8832] allows the DATA_CHANNEL_OPEN message's 'Protocol'
| value to be an empty string.
This parameter indicates that the data channel is partially reliable. The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted. The 'max-retr' parameter is optional. If the 'max-retr' parameter and the 'max-time' parameter are not present, then reliable transmission is performed as specified in [RFC4960]. This parameter maps to the 'Number of RTX' parameter defined in [RFC8832].
このパラメータは、データチャネルが部分的に信頼できることを示します。'max-rr'パラメータは、ユーザーメッセージが再送信される最大回数を示します。'max-retr'パラメータはオプションです。'max-retr'パラメータと 'max-time'パラメータが存在しない場合は、[RFC4960]で指定されているように信頼できる送信が実行されます。このパラメータは[RFC8832]で定義されている「RTX」パラメータの数にマッピングされます。
This parameter indicates that the data channel is partially reliable. A user message will no longer be transmitted or retransmitted after a specified lifetime, given in milliseconds, in the 'max-time' parameter. The lifetime starts when providing the user message to the protocol stack. The 'max-time' parameter is optional. If the 'max-retr' parameter and the 'max-time' parameter are not present, then reliable transmission is performed as specified in [RFC4960]. This parameter maps to the 'Lifetime in ms' parameter defined in [RFC8832].
このパラメータは、データチャネルが部分的に信頼できることを示します。ユーザーメッセージは、「max-time」パラメータで、ミリ秒単位で指定された有効期間の後に送信または再送信されなくなります。有効期間は、プロトコルスタックにユーザーメッセージを提供するときに始まります。'max-time'パラメータはオプションです。'max-retr'パラメータと 'max-time'パラメータが存在しない場合は、[RFC4960]で指定されているように信頼できる送信が実行されます。このパラメータは[RFC8832]で定義されている「MS 'パラメータのLifeTimeにマッピングします。
The 'ordered' parameter with value "true" indicates that the receiver will dispatch DATA chunks in the data channel to the upper layer while preserving the order. The 'ordered' parameter is optional and takes two values -- "true" for ordered delivery and "false" for unordered delivery -- with "true" as the default value. Any other value is ignored, and the default "ordered=true" is assumed. In the absence of this parameter, "ordered=true" is assumed. This parameter maps to the ordered or unordered data channel types as defined in [RFC8832].
値 "true"の '順序付き'パラメータは、受信側が順序を保持しながらデータチャネル内のデータチャンクを上位層にディスパッチすることを示します。'ORDERED'パラメータはオプションで、順序付けられた配信の場合は「true」と順序付けられていない配信の場合は "false"を取ります - デフォルト値として "true"を使用します。他の値は無視され、デフォルトの "順序付け= true"が想定されます。このパラメータがない場合は、「順序付け= true」が想定されています。このパラメータは、[RFC8832]で定義されている順序付けられたまたは順序付けられていないデータチャネルタイプにマッピングされます。
The 'priority' parameter indicates the data channel's priority relative to the priorities of other data channels, which may additionally exist over the same SCTP association. The 'priority' parameter maps to the 'Priority' parameter defined in [RFC8832]. The 'priority' parameter is optional. In the absence of this parameter, "priority=256" is assumed.
'priority'パラメータは、他のデータチャネルの優先順位に対するデータチャネルの優先順位を示します。これは、同じSCTPアソシエーションにわたって追加的に存在する可能性があります。'priority'パラメータは、[RFC8832]で定義されている 'priority'パラメータにマッピングされます。'priority'パラメータはオプションです。このパラメータがない場合は、「優先順位= 256」が想定されています。
The multiplexing category [RFC8859] of the "a=dcmap:" attribute is SPECIAL.
"a = dcmap："属性の多重化カテゴリ[RFC8859]は特別です。
As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [RFC8841], no "a=dcmap:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of [RFC8841] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS association or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcmap:" attribute need to be defined as well -- for instance, in an extension of this specification.
単一のDTLSアソシエーションの上の複数のSCTP関連の使用法が[RFC8841]の範囲外であるため、UDP / DTLS / SCTPおよびTCP / DTLS / SCTPプロト値には、「A = DCMAP：」属性多重化規則が指定されていません。。[RFC8841]の将来の拡張子が、単一のDTLSアソシエーションの上に複数のSCTPアソシエーションの多重化を定義する場合、または1つのバンドルグループに複数のSCTPアソシエーションを追加する方法を定義してから、「A = DCMAP：」属性を多重化する必要があります。たとえば、この仕様の拡張機能で定義されます。
In the SDP media description, each data channel declaration MAY also be followed by other SDP attributes, which apply to the corresponding data channel and its subprotocol. Each of these attributes is represented by one new "a=dcsa:" attribute line that references another SDP attribute defined for use with this data channel's subprotocol. Instructions for registering attributes for use with a data channel are given in Section 9.3.
SDPメディアの説明では、各データチャネル宣言の後に続くことができます。その他のSDP属性は、対応するデータチャネルとそのサブプロトコルに適用されます。これらの各属性は、このデータチャネルのサブプロトコルで使用するために定義された別のSDP属性を参照する1つの新しい "A = DCSA："属性行によって表されます。データチャネルで使用するための属性を登録するための命令は、9.3節に示されています。
Each SDP attribute that is related to the subprotocol and that would normally be used to negotiate the subprotocol using the SDP offer/ answer mechanism is replaced with an attribute of the form "a=dcsa:stream-id original-attribute", where "dcsa" stands for "data channel subprotocol attribute", "stream-id" is the SCTP stream identifier assigned to this subprotocol instance, and "original-attribute" represents the contents of the subprotocol-related attribute to be included.
SDPオファー/回答メカニズムを使用してサブプロトコルをネゴショボートするためにサブプロトコルに関連する各SDP属性は、 "A = DCSA：stream-id属性 - 属性"という形式の属性に置き換えられます。「データチャネルサブプロトコル属性」は、このサブプロトコルインスタンスに割り当てられているSCTPストリーム識別子であり、含まれるSubProtocol関連属性の内容を表す。
The same syntax applies to any other SDP attribute required for negotiation of this instance of the subprotocol.
同じ構文は、サブプロトコルのこのインスタンスのネゴシエーションに必要な他のSDP属性に適用されます。
The detailed offer/answer procedures for the dcsa attribute are dependent on the associated subprotocol. If no offer/answer procedures exist for the subprotocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA (Internet Assigned Numbers Authority) registration procedures for the "WebSocket Subprotocol Name Registry" (Section 9.1) do not strictly require a specification of the offer/answer procedures for the subprotocol when used with dcsa. If the subprotocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the subprotocol has defined offer/answer procedures when used outside of dcsa but no specification exists for the offer/answer procedures for the subprotocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise-negotiable and applicable subprotocol parameters.
DCSA属性の詳細なオファー/回答手順は、関連付けられているサブプロトコルに依存します。DCSA属性の外部で使用されている場合は、サブプロトコルにオファー/アンサープロシージャが存在しない場合は、DCSAで使用するために指定は不要です。「WebSocket Subprotocol Name Registry」（セクション9.1）のIANA（Internet Assigned Numbers Authority）登録手順は、DCSAと共に使用されたときにサブプロトコルのオファー/アンサープロシージャの指定を厳密に必要としない。SubProtocolがDCSAの外部で使用された場合にオファー/アンサープロシージャを定義した場合、そのような仕様は相互運用性を確保するよう奨励されています。DCSAの外部で使用されている場合は、サブプロトコルがオファー/アンサープロシージャを定義したが、SubProtocolのオファー/アンサープロシージャーに指定されていない場合、DCSAと共に使用された場合、実装は、さもなければ交渉可能で該当するサブプロトコルパラメータのデフォルト値の使用を想定する必要があります。。
"a=dcsa:" is a media-level attribute having the following definition and ABNF (Augmented Backus-Naur Form) syntax [RFC5234].
「A = DCSA：」は、以下の定義とABNF（拡張バックスナウレーション）構文[RFC5234]を持つメディアレベルの属性です。
+================================+
| "a=dcsa:" Attribute |
+===================+============+
| Name | dcsa |
+-------------------+------------+
| Value | dcsa-value |
+-------------------+------------+
| Usage Level | media |
+-------------------+------------+
| Charset Dependent | No |
+-------------------+------------+
Table 2: "a=dcsa:" Attribute Definition
表2： "A = DCSA："属性の定義
Formal syntax:
正式な構文：
dcsa-value = stream-id SP attribute
stream-id = 1*5DIGIT
attribute = <from RFC 8866>
Example:
例：
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
a=dcsa:2 accept-types:text/plain
The reference to [RFC8866] defines where the attribute definition can be found; it does not provide any limitations on support of attributes defined in other documents in accordance with this attribute definition. However, not all SDP attributes are suitable as an "a=dcsa:" parameter. The registry of IANA SDP parameters contains the lists of IANA-registered session-level and media-level or media-level-only SDP attributes.
[RFC8866]への参照は、属性定義が見つかる場所を定義します。この属性定義に従って、他の文書で定義されている属性のサポートについての制限はありません。ただし、すべてのSDP属性が "a = dcsa："パラメータとして適しているわけではありません。IANA SDPパラメータのレジストリには、IANA登録済みセッションレベルとメディアレベルまたはメディアレベルのみのSDP属性のリストが含まれています。
Thus, in the example above, the original attribute line "a=accept-types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of the MSRP subprotocol being transported on the SCTP association using the data channel with stream id 2 accepts plaintext files.
したがって、上の例では、元の属性行 "A = appect-types：text / plain"は、属性行 "A = DCSA：2 accept-types：text / prepl"、このインスタンスを指定します。STREAD ID 2を使用してSCTPアソシエーションでMSRPサブプロタクトが転送されている場合は、平文ファイルを受け入れます。
As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answer negotiation, following the procedures defined in the subprotocol-specific documents.
データチャネル「A = DCMAP：」属性パラメータとは対照的に、これらのパラメータは、サブプロタクコル固有の文書で定義されている手順に従って、オファー/アンケートネゴシエーションの対象となる。
It is assumed that in general the usages of subprotocol-related media-level attributes are independent from the subprotocol's transport protocol. Such transport-protocol-independent subprotocol-related attributes are used in the same way as defined in the original subprotocol specification, also if the subprotocol is transported over a data channel and if the attribute is correspondingly embedded in an "a=dcsa:" attribute.
一般に、サブプロタコーション関連のメディアレベルの属性の使用は、サブプロトコルのトランスポートプロトコルとは独立していると仮定されています。そのようなトランスポートプロトコルに依存しないサブプロトコル関連の属性は、サブプロトコルがデータチャネルを介して転送され、属性が「A = DCSA：」属性に埋め込まれている場合も、元のサブプロトコル仕様で定義されているのと同じ方法で使用されます。。
There may be cases where the usage of a subprotocol-related media-level attribute depends on the subprotocol's transport protocol. In such cases, the subprotocol-related usage of the attribute is expected to be described for the data channel transport. A data-channel-specific usage of a subprotocol attribute is expected to be specified in the same document that registers the subprotocol's identifier for data channel usage as described in Section 9.1.
サブプロトコル関連のメディアレベル属性の使用法がサブプロトコルのトランスポートプロトコルに依存する場合があります。このような場合、属性のサブプロトコル関連の使用法はデータチャネルトランスポートについて説明されると予想される。SubProtocol属性のデータチャネル固有の使用法は、セクション9.1で説明されているように、サブプロトコルのデータチャネル使用率を登録するのと同じ文書で指定されると予想されます。
The multiplexing category of the "a=dcsa:" attribute is SPECIAL.
"A = DCSA："属性の多重化カテゴリは特別です。
As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [RFC8841], no "a=dcsa:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of [RFC8841] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS association or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcsa:" attribute need to be defined as well -- for instance, in an extension of this specification.
単一のDTLSアソシエーションの上の複数のSCTP関連の使用法が[RFC8841]の範囲外であるため、UDP / DTLS / SCTPおよびTCP / DTLS / SCTPプロトパ値には「A = DCSA：」属性多重化規則は指定されていません。。[RFC8841]の将来の拡張子が、単一のDTLSアソシエーションの上に複数のSCTPアソシエーションの多重化を定義するか、または1つのバンドルグループに複数のSCTPアソシエーションを追加する方法を定義してから、「A = DCSA：」属性の多重化規則を必要とします。たとえば、この仕様の拡張機能で定義されます。
This section defines how data channels can be negotiated using the SDP offer/answer mechanism. A given media description can describe multiple data channels (each represented by a separate SDP dcmap attribute) that can be created, modified, and closed using different offer/answer exchanges. The procedures in this section apply for a given data channel.
このセクションでは、SDPオファー/アンサーメカニズムを使用してデータチャネルをネゴシエートする方法を定義します。特定のメディアの説明は、さまざまなオファー/アンサーインターフェースを使用して作成、変更、および閉じることができる複数のデータチャネル（それぞれ別のSDP DCMAP属性で表される）を記述できます。このセクションの手順は、特定のデータチャネルに適用されます。
The generic offer/answer procedures for negotiating the SCTP association used to realize data channels are defined in [RFC8841]. This section only defines the data-channel-specific procedures.
データチャネルを実現するために使用されるSCTPアソシエーションをネゴシエーションするための一般的なオファー/回答手順は[RFC8841]で定義されています。このセクションでは、データチャネル固有の手順のみを定義します。
"Initial offer" refers to the offer in which a data channel is opened. It can be either the initial offer or a subsequent offer of the associated SDP session.
「初期オファー」とは、データチャネルが開かれるオファーを指します。それは、関連するSDPセッションの最初のオファーまたはその後のオファーのいずれかです。
The detailed offer/answer procedures for the dcsa attribute are dependent on the associated subprotocol; see Section 5.2.
DCSA属性の詳細なオファー/回答手順は、関連付けられているサブプロトコルに依存します。セクション5.2を参照してください。
In order to avoid SCTP Stream identifier collisions, in alignment with [RFC8832], the endpoint acting as a DTLS client (for the SCTP association used to realize data channels) MUST use even identifier values, and the endpoint acting as a DTLS server MUST use odd identifier values.
SCTPストリーム識別子の衝突を回避するために、[RFC8832]との配置では、DTLSクライアントとして機能するエンドポイント（データチャネルを実現するために使用されるSCTPアソシエーションの場合）では、識別子の値を使用し、DTLSサーバーとして機能するエンドポイントは使用する必要があります。奇数識別子値
SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers.
DCEPを使用してネゴシエートされたデータチャネルに関連するSCTPストリーム識別子は、SDPオファーや回答に含まれてはいけません。
The data channel types defined in [RFC8832] are mapped to the dcmap SDP attribute parameters in the following manner, where "ordered=true" is the default and may be omitted:
[RFC8832]で定義されているデータチャネルタイプは、次のようにDCMAP SDP属性パラメータにマッピングされます。ここで、 "ordered = true"はデフォルトでは省略される場合があります。
DATA_CHANNEL_RELIABLE ordered=true
DATA_CHANNEL_RELIANALED = TRUE
DATA_CHANNEL_RELIABLE_UNORDERED ordered=false
data_channel_reliable_undered ordered = false
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
ordered=true;max-retr=<number of retransmissions>
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
ordered=false;max-retr=<number of retransmissions>
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
ordered=true;max-time=<lifetime in milliseconds>
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
ordered=false;max-time=<lifetime in milliseconds>
By definition, 'max-retr' and 'max-time' are mutually exclusive, so both MUST NOT be present in the "a=dcmap:" attribute line. If an SDP offer contains both of these parameters, then the receiver of such an SDP offer MUST reject the SDP offer. If an SDP answer contains both of these parameters, then the offerer MUST treat the associated SDP offer/answer as failed.
定義によって、 'max-rr'と 'max-time'は相互に排他的なので、両方とも "a = dcmap："属性行に存在してはいけません。SDPオファーにこれらのパラメータの両方が含まれている場合、そのようなSDPオファーの受信者はSDPオファーを拒否しなければなりません。SDPの答えにこれらのパラメータの両方が含まれている場合、オファーは関連付けられたSDPオファー/答えを失敗したと扱う必要があります。
When an offerer sends an initial offer, in order to negotiate an SCTP stream for a data channel, the offerer
提供者が最初のオファーを送信するとき、データチャネルのSCTPストリームをネゴシエートするために、オファー
* SHALL include an SDP dcmap attribute (Sections 5.1 and 6.2) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel, and
* データチャネルを実現するために使用されるSCTPアソシエーションを表す「M =」セクションのデータチャネルに関連付けられたSDP DCMAP属性（セクション5.1および6.2）を含みます。
* MAY include one or more SDP dcsa attributes (Section 5.2) associated with the data channel. The value of the 'stream-id' part of each attribute SHALL match the 'dcmap-stream-id' value of the dcmap attribute.
* データチャネルに関連付けられている1つ以上のSDP DCSA属性（セクション5.2）を含み得る。各属性の 'stream-id'部分の値は、dcmap属性の 'dcmap-stream-id'値と一致するものとします。
When an answerer receives an offer that includes an "m=" section for an SCTP association, the offer describes an SCTP stream for a data channel, if the answerer accepts the data channel, it
回答者がSCTPアソシエーションについて「M =」セクションを含むオファーを受信すると、そのオファーはデータチャネルを受け入れると、データチャネルのためのSCTPストリームを記述します。
* SHALL include an SDP dcmap attribute (Sections 5.1 and 6.2) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel. The value of the 'dcmap-stream-id', 'max-retr', and 'max-time' values of the dcmap attribute SHALL be identical to the value used for the data channel in the offer, and
* データチャネルを実現するために使用されるSCTPアソシエーションを表す「M =」セクションのデータチャネルに関連付けられたSDP DCMAP属性（セクション5.1および6.2）を含みます。DCMAP属性の 'dcmap-stream-id'、 'max-rit'、および 'max-time'値の値は、オファーのデータチャネルに使用される値と同じでなければならない。
* MAY include one or more SDP dcsa attributes (Section 5.2) associated with the data channel.
* データチャネルに関連付けられている1つ以上のSDP DCSA属性（セクション5.2）を含み得る。
An offerer receiving an SDP answer performs the following:
SDP回答を受信したオファーは、次のようになります。
* It SHALL close any created data channels as described in Section 6.6.1 for which the expected "a=dcmap:" attributes are not present in the SDP answer. If the SDP answer has no "a=dcmap:" attributes, either the peer does not support "a=dcmap:" attributes or it rejected all the data channels. In either case, the offerer closes all the data channels offered by SDP that were open at the time of the offer. The DTLS association and SCTP association will still be set up. At this point, the offerer may use DCEP negotiation [RFC8832] to open data channels.
* 6.6.1項で説明されているデータチャネルを閉じます。これは、SDP回答に予想される "A = DCMAP："属性が存在しない。SDPの回答に "A = DCMAP："属性がない場合、ピアは "A = DCMAP："属性をサポートしていないか、すべてのデータチャネルを拒否しません。どちらの場合も、オファーはオファーの時点で開かれていたSDPが提供するすべてのデータチャネルを閉じます。DTLSアソシエーションとSCTPアソシエーションはまだ設定されます。この時点で、オファーはDCEPネゴシエーション[RFC8832]を使用してデータチャネルを開くことができます。
Each agent application MUST wait to send data until it has confirmation that the data channel at the peer is instantiated. For WebRTC, this is when both data channel stacks have channel parameters instantiated and occurs as follows:
各エージェントアプリケーションは、ピアのデータチャネルがインスタンス化されていることが確認されるまでデータを送信するのを待つ必要があります。WEBRTCの場合、これは両方のデータチャネルスタックにチャネルパラメータがインスタンス化され、次のように発生する場合です。
* At both peers when a data channel is created without a previously established SCTP association, as soon as the SCTP association is successfully established.
* SCTPアソシエーションが正常に確立されるとすぐに、データチャネルが以前に確立されたSCTPアソシエーションなしでデータチャネルが作成されたときに両方のピアで作成されます。
* At the agent receiving an SDP offer for which there is an established SCTP association, as soon as it creates the negotiated data channel based on information signaled in the SDP offer.
* SDPオファーでシグナリングされた情報に基づいてネゴシエートされたデータチャネルを作成するとすぐに確立されたSCTPアソシエーションがあるSDPオファーを受信するエージェントで。
* At the agent sending an SDP offer to create a new data channel for which there is an established SCTP association, when it receives the SDP answer confirming acceptance of the data channel or when it begins to receive data on the data channel from the peer, whichever occurs first.
* エージェントでは、SDPオファーを送信して、確立されたSCTPアソシエーションがある新しいデータチャネルを作成して、データチャネルの受け入れを確認するとき、またはピアからデータチャネル上のデータチャネル上のデータを受信し始めるときの新しいデータチャネルを作成します。最初に発生します。
When an offerer sends a subsequent offer that includes information for a previously negotiated data channel, unless the offerer intends to close the data channel (Section 6.6.1), the offerer SHALL include the previously negotiated SDP attributes and attribute values associated with the data channel. The answerer may reject the offer. The means for rejecting an offer are dependent on the higher-layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer [RFC3264].
オファーが以前にネゴシエートされたデータチャネルの情報を含む後続のオファーを送信するとき、オファーがデータチャネルを閉じることを意図していない限り（セクション6.6.1）、オファーは以前にネゴシエートされたSDP属性とデータチャネルに関連した属性値を含めるものとします。。回答者はオファーを拒否するかもしれません。オファーを拒否するための手段は、上位層のプロトコルに依存しています。オファー/回答交換はアトミックです。回答が拒否された場合、セッションはオファーの前の状態に戻ります[RFC3264]。
In order to close a data channel, the endpoint that wants to close the data channel SHALL send an SCTP SSN Reset message [RFC6525], following the procedure in Section 6.7 of [RFC8831]. In addition, if the closed data channel was negotiated using the offer/answer mechanism (Section 6.3), the endpoint that closed the data channel SHALL send a subsequent offer in which it does one of the following:
データチャネルを閉じるには、[RFC8831]の6.7項の手順に従って、データチャネルを閉じるエンドポイント[RFC6525]を送信します。さらに、閉鎖データチャネルがオファー/アンサーメカニズム（セクション6.3）を使用してネゴシエートされた場合、データチャネルを閉じたエンドポイントは次のいずれかのオファーを送信するものとします。
* Removes the SDP dcmap attribute and SDP dcsa attributes associated with the closed data channel. Once the endpoint receives a successful answer, the SCTP stream identifier value can later be used for a new data channel (negotiated using either SCTP or the offer/answer mechanism), or
* クローズドデータチャネルに関連付けられているSDP DCMAP属性とSDP DCSA属性を削除します。エンドポイントが成功した回答を受信すると、SCTPストリーム識別子の値は後で新しいデータチャネル（SCTPまたはオファー/アンサーメカニズムを使用してネゴシエートされた）に使用できます。
* After a reset has been performed, reuses the SCTP stream used for the closed data channel for a new data channel, following the procedure in Section 6.3. The offerer SHALL use a different SDP dcmap attribute value for the data channel using the same SCTP stream.
* リセットが実行された後、6.3の手順に従って、クローズドデータチャネルに使用されているSCTPストリームを新しいデータチャネルに再利用してください。オファーは、同じSCTPストリームを使用してデータチャネルに異なるSDP DCMAP属性値を使用しなければならない。
An SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" attributes:
SDPオファーまたは回答には、 "A = DCMAP："属性がありますが、 "A = DCSA："属性があります。
* This is considered an error case. In this case, the receiver of such an SDP offer or answer MUST discard the "a=dcsa:" attributes.
* これはエラーの場合と考えられています。この場合、そのようなSDPオファーまたは回答の受信機は、「A = DCSA：」属性を破棄しなければなりません。
An SDP offer or answer has an "a=dcsa:" attribute whose subprotocol attribute is unknown:
SDPオファーまたは回答には、subprotocol属性が不明の "a = dcsa："属性があります。
* The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa:" attribute line.
* そのようなSDPオファーまたは回答の受信者は、この全体の「A = DCSA：」属性回線を無視する必要があります。
An SDP offer or answer has an "a=dcsa:" attribute whose subprotocol attribute is known but whose subprotocol attribute semantic is not known for the data channel transport case:
SDPオファーまたは回答には、SUBPROTOCOL属性が既知であるが、SubProtocol属性セマンティックがデータチャネルトランスポートケースで知られていない「A = DCSA：」属性があります。
* The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa:" attribute line.
* そのようなSDPオファーまたは回答の受信者は、この全体の「A = DCSA：」属性回線を無視する必要があります。
Figure 1 shows an example of an SDP offer and answer where the SDP answerer rejects the data channel with stream id 0 either for explicit reasons or because it does not understand the "a=dcmap:" attribute. As a result, the offerer will close the data channel created with the SDP offer/answer negotiation option. The SCTP association will still be set up over DTLS. At this point, the offerer or the answerer may use DCEP negotiation to open data channels.
図1は、明示的な理由から、SDP回答者がストリームID 0を持つデータチャネルを拒否するSDPオファーと回答の例を示しています。その結果、提供者はSDPオファー/アンサートランス交渉オプションで作成されたデータチャネルを閉じます。SCTPアソシエーションは依然としてDTLSよりも設定されます。この時点で、オファーまたは回答者はDCEPネゴシエーションを使用してデータチャネルを開くことができます。
m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3
a=max-message-size:100000
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id:abc3de65cddef001be82
a=dcmap:0 subprotocol="bfcp";label="bfcp"
m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1
a=max-message-size:100000
a=sctp-port:5002
a=setup:passive
a=fingerprint:SHA-1 \
5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id:dcb3ae65cddef0532d42
Figure 1: Example 1
図1：例1
Figure 2 shows an example of an SDP offer and answer where the SDP offer contains data channels for BFCP and MSRP subprotocols. The SDP answer rejects BFCP and accepts MSRP. So, the offerer closes the data channel for BFCP, and both the offerer and the answerer may start using the MSRP data channel (after the SCTP association is set up). The data channel with stream id 0 is free and can be used for future DCEP or SDP offer/answer negotiation.
図2は、SDPオファーがBFCPおよびMSRPサブプロトコルのデータチャネルを含むSDPオファーと回答の例を示しています。SDP回答はBFCPを拒否し、MSRPを受け入れます。したがって、オファーはBFCPのデータチャネルを閉じ、オファーと回答者の両方がMSRPデータチャネルを使用し始めることがあります（SCTPアソシエーションが設定された後）。ストリームID 0を持つデータチャネルは無料で、将来のDCEPまたはSDPオファー/アンサートランスのネゴシエーションに使用できます。
m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
a=max-message-size:100000
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id:abc3de65cddef001be82
a=dcmap:0 subprotocol="bfcp";label="bfcp"
a=dcmap:2 subprotocol="msrp";label="msrp"
a=dcsa:2 accept-types:message/cpim text/plain
a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc
m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.2
a=max-message-size:100000
a=sctp-port:5002
a=setup:passive
a=fingerprint:SHA-1 \
5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id:dcb3ae65cddef0532d42
a=dcmap:2 subprotocol="msrp";label="msrp"
a=dcsa:2 accept-types:message/cpim text/plain
a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc
Figure 2: Example 2
図2：例2
The example in Figure 3 is a continuation of the example in Figure 2. The SDP offerer now removes the MSRP data channel with stream id 2 but opens a new MSRP data channel with stream id 4. The answerer accepts the entire offer. As a result, the offerer closes the previously negotiated MSRP-related data channel, and both the offerer and the answerer may start using the new MSRP-related data channel.
図3の例は、図2の例の継続です.SDPオファーは、Stream ID 2でMSRPデータチャネルを削除しますが、ストリームID 4を持つ新しいMSRPデータチャネルを開く。収答者はオファー全体を受け入れます。その結果、オファーは以前にネゴシエートされたMSRP関連データチャネルを閉じ、オファーと回答者の両方が新しいMSRP関連データチャネルを使用し始めることがあります。
m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
a=max-message-size:100000
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id:abc3de65cddef001be82
a=dcmap:4 subprotocol="msrp";label="msrp"
a=dcsa:4 accept-types:message/cpim text/plain
a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc
m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.2
a=max-message-size:100000
a=sctp-port:5002
a=setup:passive
a=fingerprint:SHA-1 \
5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id:dcb3ae65cddef0532d42
a=dcmap:4 subprotocol="msrp";label="msrp"
a=dcsa:4 accept-types:message/cpim text/plain
a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc
Figure 3: Example 3
図3：例3
This document specifies new SDP attributes used in the negotiation of data channel parameters.
このドキュメントは、データチャネルパラメータのネゴシエーションで使用される新しいSDP属性を指定します。
These parameters are negotiated as part of opening an SCTP channel over DTLS as specified in [RFC8841]. Each subprotocol may come with its own security considerations that need to be documented as part of the subprotocol definition. Otherwise, this document does not add any security considerations to those specified in [RFC8841].
これらのパラメータは、[RFC8841]で指定されているDTLSを介してSCTPチャネルを開く部分としてネゴシエートされます。各サブプロトコルには、サブプロトコルの定義の一部として文書化する必要がある独自のセキュリティ上の考慮事項が付属している場合があります。それ以外の場合、このドキュメントは[RFC8841]で指定されたものにセキュリティ上の考慮事項を追加しません。
Error cases such as the use of unknown parameter values or violations of the odd/even rule (Section 6.1) MUST be handled by closing the corresponding data channel.
不明なパラメータ値の使用や奇数/偶数ルールの違反などのエラーケース（セクション6.1）は、対応するデータチャネルを閉じることによって処理する必要があります。
Registration of new subprotocol identifiers is performed using the existing IANA "WebSocket Subprotocol Name Registry" table.
新しいサブプロトコル識別子の登録は、既存のIANA "WebSocketサブプロトコル名レジストリ"テーブルを使用して実行されます。
The following text has been added below the title of the table.
次のテキストがテーブルのタイトルの下に追加されました。
"This table also includes subprotocol identifiers specified for usage within a WebRTC data channel."
「この表には、WebRTCデータチャネル内の使用に指定されたサブプロトコル識別子も含まれています。
This document (RFC 8864) has been added to the "Reference" list for the registry.
この文書（RFC 8864）は、レジストリの「参照」リストに追加されました。
This document assigns no new values to this table.
この文書はこのテーブルに新しい値を割り当てません。
A subprotocol may simultaneously be defined for data channel transport and for WebSocket transport. In such a case, the "Subprotocol Definition" and "Reference" cells in the subprotocol's row of the IANA "WebSocket Subprotocol Name Registry" table should contain two entries. One entry in each of these cells should refer to the WebSocket-related subprotocol specification, and the other entry should refer to the data-channel-related subprotocol specification.
サブプロトコルは、データチャネルトランスポートおよびWebSocketトランスポートのために同時に定義されてもよい。そのような場合、IANA「WebSocketサブプロトコル名レジストリ」テーブルのサブプロトコルの行の「サブプロトコル定義」および「参照」セルには、2つのエントリを含める必要があります。これらの各セルの1つのエントリは、WebSocket関連のサブプロトコル仕様を参照しており、もう1つのエントリはデータチャネル関連のサブプロトコル仕様を参照する必要があります。
This document defines a new SDP media-level attribute, "a=dcmap:", as follows:
このドキュメントは、次のように、新しいSDPメディアレベルの属性「A = DCMAP：」を定義します。
+==================================================================+
| "a=dcmap:" |
+=====================+============================================+
| Contact name | IESG |
+---------------------+--------------------------------------------+
| Contact email | iesg@ietf.org |
+---------------------+--------------------------------------------+
| Attribute name | dcmap |
+---------------------+--------------------------------------------+
| Attribute syntax | As per Section 5.1.1 |
+---------------------+--------------------------------------------+
| Attribute semantics | As per Section 5.1.1 |
+---------------------+--------------------------------------------+
| Usage level | media |
+---------------------+--------------------------------------------+
| Charset dependent | No |
+---------------------+--------------------------------------------+
| Purpose | To define data-channel-specific parameters |
+---------------------+--------------------------------------------+
| Appropriate values | As per Section 5.1.1 |
+---------------------+--------------------------------------------+
| O/A procedures | SDP offer/answer procedures as per |
| | Section 6 |
+---------------------+--------------------------------------------+
| Mux category | SPECIAL. See Section 5.1.9 |
+---------------------+--------------------------------------------+
| Reference | RFC 8864 |
+---------------------+--------------------------------------------+
Table 3: New "a=dcmap:" Attribute
This document defines a new SDP media-level attribute, "a=dcsa:", as follows:
このドキュメントは、次のように、新しいSDPメディアレベルの属性 "A = DCSA："を定義します。
+=============================================================+
| "a=dcsa:" |
+=====================+=======================================+
| Contact name | IESG |
+---------------------+---------------------------------------+
| Contact email | iesg@ietf.org |
+---------------------+---------------------------------------+
| Attribute name | dcsa |
+---------------------+---------------------------------------+
| Attribute syntax | As per Section 5.2.1 |
+---------------------+---------------------------------------+
| Attribute semantics | As per Section 5.2.1 |
+---------------------+---------------------------------------+
| Usage level | media |
+---------------------+---------------------------------------+
| Charset dependent | No |
+---------------------+---------------------------------------+
| Purpose | To define attributes that are |
| | specific to data channel subprotocols |
+---------------------+---------------------------------------+
| Appropriate values | As per Section 5.2.1 |
+---------------------+---------------------------------------+
| O/A procedures | SDP offer/answer procedures as per |
| | Section 6 |
+---------------------+---------------------------------------+
| Mux category | SPECIAL. See Section 5.2.2 |
+---------------------+---------------------------------------+
| Reference | RFC 8864 |
+---------------------+---------------------------------------+
Table 4: New "a=dcsa:" Attribute
When a subprotocol is defined for use over data channels with the SDP offer/answer mechanism, any SDP attributes that may be negotiated using the "a=dcsa:" attribute MUST be added to the IANA "attribute-name registry (formerly "att-field")", as specified in [RFC8866], Section 8.2.4. This document specifies that new Usage Levels of the form "dcsa (foo)" (where "foo" is a placeholder for the subprotocol name) should be registered by documents that specify negotiation of particular subprotocols.
SDPオファー/アンサーメカニズムを使用してデータチャネルを介して使用するためにサブプロトコルが定義されている場合、「A = DCSA：」属性を使用してネゴシエートされる可能性のあるSDP属性は、IANA "属性名レジストリ（以前の" ATT-）に追加する必要があります。[RFC8866]で指定されているように、フィールド "）"、8.2.4。このドキュメントでは、「DCSA（foo）」（「foo」がサブプロトコル名のプレースホルダ）の新しい使用量レベルを指定します。特定のサブプロトコルのネゴシエーションを指定する文書によって登録する必要があります。
IANA has updated the "attribute-name (formerly "att-field")" registry to point to this document.
このドキュメントを指すために、IANAは「属性名（以前のatt-field」）」レジストリを更新しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.
[RFC6525] Stewart、R.、Tuexen、M.、およびP. Lei、「ストリーム制御伝送プロトコル（SCTP）ストリーム再構成」、RFC 6525、DOI 10.17487 / RFC6525、2012年2月、<https：///ww.rfc-editor.org/info/rfc6525>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S.、M.Tüxen、「Webrtcデータチャンネル」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https：//www.rfc-editor.org/info/RFC8831>。
[RFC8832] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832, January 2021, <https://www.rfc-editor.org/info/rfc8832>.
[RFC8832] Jesup、R.、Loreto、S.、およびM.Tüxen、「WebRTCデータチャネル設立プロトコル」、RFC 8832、DOI 10.17487 / RFC8832、2021年1月、<https：//www.rfc-editor.org/情報/ RFC8832>。
[RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport", RFC 8841, DOI 10.17487/RFC8841, January 2021, <https://www.rfc-editor.org/info/rfc8841>.
[RFC8841] Holmberg、C、Shpount、R.、Loreto、S.、およびG. Camarillo、「セッション説明プロトコル（SDP）ストリーム制御伝送プロトコル（SCTP）のための提供/回答手順データグラムトランスポート層セキュリティ（DTLS）輸送、RFC 8841、DOI 10.17487 / RFC8841、2021年1月、<https：//www.rfc-editor.org/info/rfc8841>。
[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
[RFC8859] Nandakumar、S。、「マルチプレクシング時のセッション記述プロトコル（SDP）属性のフレームワーク」、RFC 8859、DOI 10.17487 / RFC8859、2021年1月、<https：//www.rfc-editor.org/info/rfc8859>。
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.
[RFC8866] Begen、A.、Kyzivat、P.、Perkins、C、およびM.ハンドリー、「SDP：セッション記述プロトコル」、RFC 8866、DOI 10.17487 / RFC8866、2021年1月、<https：//www.rfc-editor.org/info/rfc8866>。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>.
[RFC4975]キャンベル、B.、ED。、Mahy、R.、Ed。、Jennings、Ed。、「メッセージセッションリレープロトコル（MSRP）」、RFC 4975、DOI 10.17487 / RFC4975、2007年9月、<https://www.rfc-editor.org/info/rfc4975>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I.およびA.Melnikov、「WebSocketプロトコル」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https：//www.rfc-editor.org/info/rfc6455>。
[RFC8850] Holmberg, C., "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10.17487/RFC8850, January 2021, <https://www.rfc-editor.org/info/rfc8850>.
[RFC8850] Holmberg、C、「テレプレゼンスのための複数のストリームの制御」、RFC 8850、DOI 10.17487 / RFC8850、1月2021年1月、<https：//www.rfc-editor.org/info/rfc8850>。
[RFC8855] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", RFC 8855, DOI 10.17487/RFC8855, January 2021, <https://www.rfc-editor.org/info/rfc8855>.
[RFC8855] Camarillo、G.、Drage、K.、Kristensen、T.、OTT、J.、およびC. Eckel、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 8855、DOI 10.17487 / RFC8855、2021年1月<https://www.rfc-editor.org/info/rfc8855>。
[RFC8873] Recio, JM., Ed. and C. Holmberg, "Message Session Relay Protocol (MSRP) over Data Channels", RFC 8873, DOI 10.17487/RFC8873, January 2021, <https://www.rfc-editor.org/info/rfc8873>.
[RFC8873] Recio、JM、ED。C. Holmberg、「メッセージセッションリレープロトコル（MSRP）、RFC 8873、DOI 10.17487 / RFC8873、2021年1月、<https：//www.rfc-editor.org/info/rfc8873>。
[T38] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, November 2015, <https://www.itu.int/rec/T-REC-T.38-201511-I/en>.
[T38]国際電気通信連合、「リアルタイムグループ3ファクシミリ通信の手順」、ITU-T勧告T.38、2015年11月、<https：//www.itu.int/rec/t-rec-T.38-201511-I / EN>。
[WebRtcAPI] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Proposed Recommendation, <https://www.w3.org/TR/webrtc/>.
[WEBRTCAPI]ジェニングニング、C、Boström、H.、およびJ-I。Bruaroey、 "WebRTC 1.0：ブラウザ間のリアルタイム通信"、W3Cは推奨事項、<https：//www.w3.org/tr/webrtc/>を提案しました。
Appendix A. Generic Data Channel Negotiation Aspects when Not Using DCEP
付録A DCEPを使用しない場合の一般的なデータチャネル交渉の側面
This appendix summarizes how data channels work in general and discusses some key aspects that should be considered for the out-of-band negotiation of data channels if DCEP is not used.
この付録では、データチャネルが一般的に機能する方法をまとめ、DCEPが使用されていない場合はデータチャネルの帯域外のネゴシエーションのために考慮されるべきいくつかの重要な側面について説明します。
A WebRTC application creates a data channel by providing a number of setup parameters (subprotocol, label, maximal number of retransmissions, maximal retransmission time, order of delivery, priority). The application also specifies whether it wants to make use of the negotiation using DCEP [RFC8832] or intends to negotiate data channels using the SDP offer/answer protocol.
WebRTCアプリケーションは、いくつかのセットアップパラメータ（サブプロトコル、ラベル、最大再送信数、最大再送時間、配信の順序、優先順位の順序）を提供することによってデータチャネルを作成します。このアプリケーションは、DCEP [RFC8832]を使用してネゴシエーションを利用したいか、またはSDPオファー/アンサープロトコルを使用してデータチャネルをネゴシエートすることを目的としているかどうかを指定します。
In any case, the SDP offer generated by the application is per [RFC8841]. In brief, it contains one "m=" line for the SCTP association on top of which the data channels will run:
いずれにせよ、アプリケーションによって生成されたSDPオファーは[RFC8841]ごとです。簡単に説明すると、データチャネルが実行される上にSCTPアソシエーションの場合は1つの「M =」回線が含まれています。
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
a=max-message-size:100000
a=sctp-port:5000
a=tls-id:abc3de65cddef001be82
a=setup:actpass
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
| Note: A WebRTC application will only use the "m=" line format
| "webrtc-datachannel" and will not use other formats in the "m="
| line for other protocols such as T.38 [T38]. [RFC8841]
| supports only one SCTP association to be established on top of
| a DTLS association.
| Note: The above SDP media description does not contain any | channel-specific information.
Independently from the requested type of negotiation, the application creating a data channel can either (1) pass the stream identifier to the data channel stack to assign to the data channel or (2) let the data channel stack pick one identifier from the unused ones.
要求されたタイプのネゴシエーションとは独立して、データチャネルを作成するアプリケーションは、データチャネルスタックにストリーム識別子をデータチャネルスタックに渡すことができ、または（2）データチャネルスタックが未使用のものから1つの識別子を選択できるようにすることができる。。
Moreover, to avoid glare situations [RFC3264], each endpoint can own an exclusive set of stream identifiers, in which case an endpoint can only create a data channel with a stream identifier it owns.
また、Gleareの状況を避けるために[RFC3264]、各エンドポイントはストリーム識別子の排他的なセットを所有することができます。その場合、エンドポイントはそれが所有するストリーム識別子を持つデータチャネルのみを作成できます。
Which set of stream identifiers is owned by which endpoint is determined by convention or other means.
どの一連のストリーム識別子が所有されているかが、条約またはその他の手段によって決定されるのか。
| Note: For data channels negotiated with DCEP, one endpoint owns
| by convention the even stream identifiers, whereas the other
| owns the odd stream identifiers, as defined in [RFC8832].
| Note: For data channels negotiated via a protocol other than | DCEP, no convention is defined by default.
DCEP negotiation only provides for negotiation of data channel transport parameters and does not provide for negotiation of subprotocol-specific parameters. Non-DCEP data channel negotiation can be defined to allow negotiation of parameters beyond those handled by DCEP, e.g., parameters specific to the subprotocol instantiated on a particular data channel.
DCEPネゴシエーションは、データチャネルトランスポートパラメータのネゴシエーションを提供し、サブプロトコル固有のパラメータのネゴシエーションを提供しません。非DCEPデータチャネルネゴシエーションは、DCEP、例えば特定のデータチャネルでインスタンス化されたサブプロタコーションに固有のパラメータを超えたパラメータのネゴシエーションを可能にするように定義することができる。
The following procedures are common to all methods of data channel negotiation not using DCEP, whether in-band (communicated using proprietary means on an already-established data channel) or out-of-band (using the SDP offer/answer mechanism or some other protocol associated with the signaling channel).
以下の手順では、帯域内（既存のデータチャネル上で独自の手段を使用しているか）（SDPオファー/アンサーメカニズムまたは他の何らかの使用を使用して）In-Band（専用の手段を使用して通信している）であろうとしているかどうか、DCEPを使用していないデータチャネルネゴシエーションのすべての方法は一般的です。シグナリングチャネルに関連するプロトコル）。
In the case of non-DCEP negotiation, the endpoint application has the option to fully control the stream identifier assignments. However, these assignments have to coexist with the assignments controlled by the data channel stack for data channels negotiated using DCEP (if any). It is the responsibility of the application to ensure consistent assignment of stream identifiers.
DCEPネゴシエーション以外の場合、エンドポイントアプリケーションはストリーム識別子の割り当てを完全に制御することができます。ただし、これらの割り当ては、DCEPを使用してネゴシエートされたデータチャネルのデータチャネルスタックによって制御されている割り当てと共存する必要があります（ある場合）。ストリーム識別子の一貫した割り当てを確実にするためのアプリケーションの責任です。
When the application requests that the creation of a new data channel be set up via non-DCEP negotiation, the data channel stack creates the data channel locally without sending any DATA_CHANNEL_OPEN messages in-band. However, even if the ICE (Interactive Connectivity Establishment), DTLS, and SCTP procedures were already successfully completed, the application can't send data on this data channel until the negotiation with the peer is complete. This is because the peer needs to be aware of and accept the usage of this data channel. The peer, after accepting the data channel offer, can start sending data immediately. This implies that the offerer may receive data channel subprotocol messages before the negotiation is complete, and the application should be ready to handle it.
アプリケーションが非DCEPネゴシエーションを介して新しいデータチャネルの作成を設定することを要求すると、データチャネルスタックはデータチャネルをローカルに帯域内に送信せずにローカルに作成します。ただし、ICE（Interactive Connectivity Interfactivition）、DTLS、およびSCTPプロシージャーがすでに正常に完了していても、ピアとのネゴシエーションが完了するまでこのデータチャネルのデータを送信することはできません。これは、ピアがこのデータチャネルの使用方法を認識して受け入れる必要があるためです。データチャネルオファーを受け入れた後、ピアはすぐにデータの送信を開始することができます。これは、オファーがネゴシエーションが完了する前にデータチャネルサブプロトコルメッセージを受信できることを意味し、アプリケーションはそれを処理する準備ができている必要があります。
If the peer rejects the data channel part of the offer, then it doesn't have to do anything, as the data channel was not created using the stack. The offerer, on the other hand, needs to close the data channel that was opened by invoking relevant data channel stack API procedures.
Peerがオファーのデータチャネル部分を拒否した場合、データチャネルがスタックを使用して作成されていないため、何もする必要はありません。一方、オファーは、関連するデータチャネルスタックAPIプロシージャを呼び出すことによって開かれたデータチャネルを閉じる必要があります。
It is also worth noting that a data channel stack implementation may not provide any APIs to create and close data channels; instead, the data channels may be used on the fly as needed, just by communicating via non-DCEP means or even by having some local configuration/ assumptions on both of the peers.
データチャネルスタック実装がデータチャネルを作成および閉じるAPIを提供しないことも注目する価値があります。代わりに、データチャネルは、非DCEPの手段を介して通信するだけで、または両方のピア上でいくつかのローカル構成/仮定を持つことによって、必要に応じてその場で使用することができます。
The application then negotiates the data channel properties and subprotocol properties with the peer's application using a mechanism different from DCEP.
次に、アプリケーションは、DCEPとは異なるメカニズムを使用して、ピアのアプリケーションとデータチャネルのプロパティとサブプロタコクトプロパティをネゴシエートします。
The peer then symmetrically creates a data channel with these negotiated data channel properties. This is the only way for the peer's data channel stack to know which properties to apply when transmitting data on this channel. The data channel stack must allow data channel creation with any nonconflicting stream identifier so that both peers can create the data channel with the same stream identifier.
その後、ピアはこれらのネゴシエートされたデータチャネルプロパティを持つデータチャネルを対称的に作成します。これは、このチャネル上のデータを送信するときにピアのデータチャネルスタックがどのプロパティを適用する唯一の方法です。データチャネルスタックは、両方のピアが同じストリーム識別子を持つデータチャネルを作成できるように、任意の非交換ストリーム識別子を使用してデータチャネルの作成を許可する必要があります。
When the application requests the closing of a data channel negotiated without DCEP, the data channel stack always performs an SCTP SSN Reset for this channel.
アプリケーションがDCEPなしでネゴシエートされたデータチャネルのクローズを要求すると、データチャネルスタックは常にこのチャネルのSCTP SSNリセットを実行します。
Depending upon the method used for non-DCEP negotiation and the subprotocol associated with the data channel, the closing of the data channel might also be signaled to the peer via SDP offer/answer negotiation.
非DCEPネゴシエーションとデータチャネルに関連付けられたサブプロトコルに使用される方法に応じて、データチャネルのクローズもSDPオファー/アンサートランスネゴシエーションを介してピアにシグナリングされる可能性があります。
Acknowledgements
謝辞
The authors wish to acknowledge the borrowing of ideas from other draft documents by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley, and Gavin Llewellyn. The authors also wish to thank Flemming Andreasen, Christian Groves, Gunnar Hellström, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, and Roman Shpount for their invaluable comments.
著者らは、Salvatore Loreto、Gonzalo Camarillo、Peter Dunkley、およびGavin Llewellynによって、他のドラフト文書からのアイデアの借入を認めたいと思います。著者らはまた、Flemming Andreasen、Christian Groves、GunnarHellStröm、Paul Kyzivat、Jonathan Lennox、Uwe Rauschenbach、そしてローマのShpountを貴重なコメントに感謝します。
Special thanks to Christer Holmberg for helping finish the document and cleaning up Section 6.
カリスターホルマグのおかげで、文書を仕上げ、セクション6を掃除します。
Contributors
貢献者
Juergen Stoetzer-Bradler made significant contributions to this document and should be considered a coauthor.
Juergen Stoetzer-Bradlerはこの文書に大きな貢献をし、共著者と見なすべきです。
Authors' Addresses
著者の住所
Keith Drage Unaffiliated
ファイトドレッジ
Email: drageke@ntlworld.com
Maridi R. Makaraju (Raju) Unaffiliated
Maridi R. Makaraju（raju）は
Email: mmraju@gmail.com
Richard Ejzak Unaffiliated
Richard Ejzakはその影響を受けません
Email: richard.ejzak@gmail.com
Jerome Marcon Unaffiliated
ジェロームマルコンは影響を受けません
Email: jeromee.marcon@free.fr
Roni Even (editor)
ロニ偶数（編集者）
Email: ron.even.tlv@gmail.com