[要約] RFC 8865は、WebRTCデータチャンネルを介したリアルタイムテキスト会話のためのT.140規格を定義しています。このRFCの目的は、WebRTCを使用してリアルタイムテキスト通信を可能にし、アクセシビリティやコミュニケーションの向上を促進することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8865 Ericsson
Updates: 8373 G. Hellström
Category: Standards Track Gunnar Hellström Accessible Communication
ISSN: 2070-1721 January 2021
T.140 Real-Time Text Conversation over WebRTC Data Channels
T.140 WEBRTCデータチャネル上のリアルタイムテキスト会話
Abstract
概要
This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updates RFC 8373 to specify its use with WebRTC data channels.
このドキュメントは、マルチメディアアプリケーションテキスト会話のITU-Tプロトコル（勧告ITU-T T.140）を使用して、リアルタイムテキストのトランスポートメカニズムとしてWebリアルタイム通信（WebRTC）データチャネルをどのように使用できるかを指定します（勧告ITU-T T.140）、およびセッション記述プロトコル（SDP）オファー/回答メカニズムは、T.140データチャネルと呼ばれるそのようなデータチャネルをネゴシエートするために使用することができる。この文書は、WEBRTCデータチャネルでの使用を指定するためにRFC 8373を更新します。
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/rfc8865.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8865で取得できます。
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. WebRTC Data Channel Considerations
4. SDP Considerations
4.1. Use of the 'dcmap' Attribute
4.2. Use of the 'dcsa' Attribute
4.2.1. Maximum Character Transmission Rate
4.2.2. Real-Time Text Conversation Languages
4.2.3. Real-Time Text Direction
4.3. Examples
5. T.140 Considerations
5.1. Session-Layer Functions
5.2. Data Encoding and Sending
5.3. Data Buffering
5.4. Loss of T140blocks
5.5. Multi-party Considerations
6. Gateway Considerations
7. Update to RFC 8373
8. Security Considerations
9. IANA Considerations
9.1. Subprotocol Identifier "t140"
9.2. SDP 'fmtp' Attribute
9.3. SDP Language Attributes
9.4. SDP Media Direction Attributes
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
The ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) [T140] defines a protocol for text conversation, also known as real-time text. The transport used for IP networks is the "RTP Payload for Text Conversation" mechanism [RFC4103], based on the Real-time Transport Protocol (RTP) [RFC3550].
マルチメディアアプリケーションのテキスト会話のITU-Tプロトコル（推奨ITU-T T.140）[T140]は、リアルタイムテキストとも呼ばれ、テキスト会話用のプロトコルを定義します。IPネットワークに使用されるトランスポートは、リアルタイムトランスポートプロトコル（RTP）[RFC3550]に基づく「テキスト会話のためのRTPペイロード」メカニズム[RFC4103]です。
This document specifies how a Web Real-Time Communication (WebRTC) data channel [RFC8831] can be used as a transport mechanism for T.140 and how the Session Description Protocol (SDP) offer/answer mechanism for data channels [RFC8864] can be used to negotiate such a data channel.
このドキュメントは、Webリアルタイム通信（WebRTC）データチャネル[RFC8831]をT.140のトランスポートメカニズムとして使用できる方法と、データチャネルのセッション記述プロトコル（SDP）オファー/アンサーメカニズム[RFC8864]をどのように使用できるかを示します。そのようなデータチャネルをネゴシエートするために使用されます。
In this document, a T.140 data channel refers to a WebRTC data channel for which the instantiated subprotocol is "t140" and where the channel is negotiated using the SDP offer/answer mechanism [RFC8864].
この文書では、T.140データチャネルとは、インスタンス化されたサブプロトコルが「T140」であり、チャネルがSDPオファー/アンサーメカニズム[RFC8864]を使用してネゴシエートされるWEBRTCデータチャネルを指す。
| NOTE: The decision to transport real-time text using a WebRTC
| data channel instead of using RTP-based transport [RFC4103] is
| motivated by use case "U-C 5: Real-time text chat during an
| audio and/or video call with an individual or with multiple
| people in a conference"; see Section 3.2 of [RFC8831].
The brief notation "T.140" is used as a name for the text conversation protocol according to [T140].
「T.140」は、[T140]のテキスト会話プロトコルの名前として使用されます。
Real-time text is intended to be entered by human users via a keyboard, handwriting recognition, voice recognition, or any other input method. The rate of character entry is usually at a level of a few characters per second or less.
リアルタイムテキストは、キーボード、手書き認識、音声認識、またはその他の入力方法を介して人間のユーザーによって入力されることを目的としています。文字エントリのレートは通常、毎秒数文字以下のレベルです。
Section 3 defines the generic data channel properties for a T.140 data channel, and Section 4 defines how they are conveyed in an SDP 'dcmap' attribute. While this document defines how to negotiate a T.140 data channel using the SDP offer/answer mechanism [RFC8864], the generic T.140 and gateway considerations defined in Sections 3, 5, and 6 of this document can also be applied when a T.140 data channel is established using another mechanism (e.g., the mechanism defined in [RFC8832]). Section 5 of [RFC8864] defines the mapping between the SDP 'dcmap' attribute parameters and the protocol parameters used in [RFC8832].
セクション3は、T.140データチャネルの一般的なデータチャネルプロパティを定義し、セクション4はSDP 'DCMAP'属性でどのように伝達されるかを定義します。この文書は、SDPオファー/アンサーメカニズム[RFC8864]を使用してT.140データチャネルをネゴシエートする方法を定義しています。T.140データチャネルは別のメカニズム（[RFC8832]で定義されているメカニズム）を使用して確立されます。[RFC8864]のセクション5は、SDP 'DCMAP'属性パラメータと[RFC8832]で使用されるプロトコルパラメータの間のマッピングを定義します。
This document updates [RFC8373] by defining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for the "application/webrtc-datachannel" media type.
このドキュメントは、SDP 'HLANG-SEND'属性と 'hlang-recv'属性が "application / webrtc-datachannel"メディアタイプにどのように使用されるかを定義することによって、[RFC8373]を更新します。
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]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The following WebRTC data channel property values [RFC8831] apply to a T.140 data channel:
以下のWebRTCデータチャネルプロパティ値[RFC8831]は、T.140データチャネルに適用されます。
+--------------------------+-----------------+
| Subprotocol Identifier | t140 |
+--------------------------+-----------------+
| Transmission reliability | reliable |
+--------------------------+-----------------+
| Transmission order | in-order |
+--------------------------+-----------------+
| Label | See Section 4.1 |
+--------------------------+-----------------+
Table 1
表1
| NOTE: T.140 requires the transport channel to provide
| transmission of real-time text without duplication and in
| original order. Therefore, T.140 does not specify reliable and
| ordered transmission of T.140 data on the application layer.
| Instead, when RTP-based transport is used, the RTP sequence
| number is used to detect packet loss and out-of-order packets,
| and a redundancy mechanism is used to achieve reliable delivery
| of T.140 data. By using the WebRTC data channel's reliable and
| in-order transmission features [RFC8831] for the T.140 data
| channel, there is no need for a redundancy mechanism or a
| mechanism to detect data loss and out-of-order delivery at the
| application level. The latency characteristics of the T.140
| data channel are also regarded as sufficient to meet the
| application requirements of T.140.
The generic SDP considerations, including the SDP offer/answer procedures [RFC3264], for negotiating a WebRTC data channel are defined in [RFC8864]. This section, and its subsections, define the SDP considerations that are specific to a T.140 data channel, identified by the 'subprotocol' attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute.
WebRTCデータチャネルを交渉するためのSDPオファー/アンサープロシージャ[RFC3264]を含む一般的なSDPの考慮事項は、[RFC8864]で定義されています。このセクションとそのサブセクションは、 'subprotocol'属性パラメータによって "dcmap '属性"で "t140"パラメータ値で識別される、T.140データチャネルに固有のSDPの考慮事項を定義します。
An offerer and answerer MUST, in each offer and answer, include an SDP 'dcmap' attribute [RFC8864] in the SDP media description ("m=" section) [RFC4566] describing the Stream Control Transmission Protocol (SCTP) association [RFC4960] used to realize the T.140 data channel.
提供者と回答者は、各オファーと回答で、SDPの「DCMAP」属性[RFC8864]を含める必要があります（ "M ="セクション）[RFC4566]ストリーム制御伝送プロトコル（SCTP）アソシエーション[RFC4960]T.140データチャネルを実現するために使用されます。
The offerer and answerer MUST include the 'subprotocol' attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute.
オファーと回答者は、 'subprotocol'属性パラメータを 'dcmap'属性に "T140"パラメータ値を含める必要があります。
The offerer and answerer MAY include the 'priority' attribute parameter and the 'label' attribute parameter in the 'dcmap' attribute value, as specified in [RFC8864].
オファーと回答者は、[RFC8864]で指定されているように、 'Priority'属性パラメータと 'DCMAP'属性値の 'label'属性パラメータを含めることができます。
| NOTE: As specified in [RFC8831], when a data channel is
| negotiated using the mechanism defined in [RFC8832], the
| 'label' attribute parameter value has to be the same in both
| directions. That rule also applies to data channels negotiated
| using the mechanism defined in this document.
The offerer and answerer MUST NOT include the 'max-retr' or 'max-time' attribute parameter in the 'dcmap' attribute. If either of those attribute parameters is received in an offer, the answerer MUST reject the offer. If either of those attribute parameters is received in an answer, the offerer MUST NOT accept the answer. Instead, the answerer MUST take appropriate actions, e.g., by sending a new offer without a T.140 data channel or by terminating the session.
オファーと回答者は、 'max-rr'または 'max-time'属性パラメータを 'dcmap'属性に含めてはいけません。これらの属性パラメータのいずれかがオファーで受信された場合、回答者はオファーを拒否しなければなりません。これらの属性パラメータのいずれかが答えで受信された場合、オファーは答えを受け入れてはいけません。代わりに、回答者は、例えばT.140データチャネルなしで、またはセッションを終了することによって、新しいオファーを送信することによって適切な行動をとる必要があります。
If the 'ordered' attribute parameter is included in the 'dcmap' attribute, it MUST be assigned the value 'true'.
'順序付けられた'属性パラメータが 'dcmap'属性に含まれている場合は、値 'true'を割り当てる必要があります。
Below is an example of the 'dcmap' attribute for a T.140 data channel with stream id=3 and without any label:
以下は、ストリームID = 3を持つT.140データチャネルの「DCMAP」属性の例です。
a=dcmap:3 subprotocol="t140"
An offerer and answerer can, in each offer and answer, include one or more SDP 'dcsa' attributes [RFC8864] in the "m=" section describing the SCTP association used to realize the T.140 data channel.
オファーと回答者は、各オファーと回答で、T.140データチャネルを実現するために使用されるSCTPアソシエーションを説明する「M =」のセクションの1つ以上のSDP 'DCSA'属性[RFC8864]を含めることができます。
If an offerer or answerer receives a 'dcsa' attribute that contains an SDP attribute whose usage has not been defined for a T.140 data channel, the offerer or answerer should ignore the 'dcsa' attribute, following the rules in Section 6.7 of [RFC8864].
オファーまたは回答者がT.140データチャネルに対して使用されていないSDP属性を含む「DCSA」属性を受信した場合、オファーまたは回答者は「DCSA」属性を無視する必要があります。RFC8864]。
A 'dcsa' attribute can contain the SDP 'fmtp' attribute, which is used to indicate a maximum character transmission rate [RFC4103]. The 'cps' attribute parameter is used to indicate the maximum character transmission rate that the endpoint that includes the attribute is able to receive, and the value is used as a mean value in characters per second over any 10-second interval.
'DCSA'属性には、最大文字伝送レート[RFC4103]を示すために使用されるSDP 'fmtp'属性を含めることができます。'CPS'属性パラメータは、属性を含むエンドポイントが受信できる最大文字伝送レートを示すために使用され、値は10秒間隔で毎秒1秒あたりの文字の平均値として使用されます。
If the 'fmtp' attribute is included, the 'format' attribute parameter value MUST be set to 't140'.
'fmtp'属性が含まれている場合は、 'format'属性パラメータ値を 't140'に設定する必要があります。
If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of 30 applies [RFC4103].
'CPS'属性パラメータを含む 'fmtp'属性が含まれていない場合、デフォルト値30は[RFC4103]を適用します。
The offerer and answerer MAY modify the 'cps' attribute parameter value in subsequent offers and answers.
オファーと回答者は、その後のオファーと回答で「CPS」属性パラメータ値を変更することがあります。
This document does not define any other usage of the 'fmtp' attribute for a T.140 channel. If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that is not set according to the procedure above, the offerer or answerer MUST ignore the 'dcsa' attribute.
この文書は、T.140チャネルの「fmtp」属性の他の使用方法を定義しません。上記の手順に従って設定されていない「FMTP」属性を含む「DCSA」属性を受信した場合、オファーまたは回答者は 'DCSA'属性を無視する必要があります。
| NOTE: The 'cps' attribute parameter is especially useful when a
| T.140 data channel endpoint is acting as a gateway (Section 6)
| and is interworking with a T.140 transport mechanism that has
| restrictions on how many characters can be sent per second.
If an endpoint receives text at a higher rate than it can handle, e.g., because the sending endpoint does not support the 'cps' attribute parameter, it SHOULD either (1) indicate to the sending endpoint that it is not willing to receive more text, using the direction attributes (Section 4.2.3) or (2) use a flow-control mechanism to reduce the rate. However, in certain applications, e.g., emergency services, it is important to regain human interaction as soon as possible, and it might therefore be more appropriate to simply discard the received overflow, insert a mark for loss [T140ad1], and continue to process the received text as soon as possible.
エンドポイントが処理することができるよりも高いレートでテキストを受信できる場合、例えば、送信エンドポイントは 'CPS'属性パラメータがサポートされていないため、（1）のどちらか（1）を送信しても、より多くのテキストを受信しても構わないことを示す必要があります。、方向属性（セクション4.2.3）または（2）を使用して、レートを短縮するためにフロー制御メカニズムを使用します。しかしながら、例えば緊急サービス、例えば緊急サービスでは、人間の相互作用をできるだけ早く取り戻すことが重要であり、したがって受信したオーバーフローを捨て、損失のためのマークを挿入し、そして処理を続けることがより適切であるかもしれない。できるだけ早く受信したテキスト。
| NOTE: At the time of writing this specification, the
| standardized API for WebRTC data channels does not support flow
| control. Should such support be available at some point, a
| receiving endpoint might use it in order to slow down the rate
| of text received from the sending endpoint.
'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes [RFC8373] to negotiate the language to be used for the real-time text conversation.
「DCSA」属性には、リアルタイムテキスト会話に使用される言語をネゴシエートするためのSDP 'HLANG-SEND'と 'HLANG-RECV'属性[RFC8373]を含めることができます。
For a T.140 data channel, the modality is "written" [RFC8373].
T.140データチャネルの場合、モダリティは「書かれた」[RFC8373]です。
'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendrecv', and 'inactive' attributes [RFC4566] to negotiate the direction in which text can be transmitted in a real-time text conversation.
'DCSA'属性には、SDP 'SendOnly'、 'Revonly'、 'SendRecv'、および 'Inactive'属性[RFC4566]を、テキストをリアルタイムのテキスト会話で送信できる方向をネゴシエートできます。
| NOTE: A WebRTC data channel is always bidirectional. The usage
| of the 'dcsa' attribute only affects the direction in which
| implementations are allowed to transmit text on a T.140 data
| channel.
The offer/answer rules for the direction attributes are based on the rules for unicast streams defined in [RFC3264], as described below. Note that the rules only apply to the direction attributes.
方向属性のオファー/回答規則は、後述のように[RFC3264]で定義されているユニキャストストリームの規則に基づいています。規則は方向属性にのみ適用されることに注意してください。
Session-level direction attributes [RFC4566] have no impact on a T.140 data channel.
セッションレベルの方向属性[RFC4566]は、T.140データチャネルに影響を与えません。
If the offerer wishes to both send and receive text on a T.140 data channel, it SHOULD mark the data channel as sendrecv with a 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does not explicitly mark the data channel, an implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default.
オファーがT.140データチャネルでテキストを送受信することを望んでいる場合は、「DCSA」属性内の「sendRecv」属性を使用してデータチャネルをsendRecvとしてマークする必要があります。オファーがデータチャネルを明示的にマークしない場合、 'DCSA'属性内の暗黙の 'sendRecv'属性がデフォルトで適用されます。
If the offerer wishes to only send text on a T.140 data channel, it MUST mark the data channel as sendonly with a 'sendonly' attribute inside a 'dcsa' attribute.
オファーがT.140データチャネルにテキストのみを送信したい場合は、「DCSA」属性内の「sendonly」属性を使用してデータチャネルをSendOnlyとしてマークする必要があります。
If the offerer wishes to only receive text on a T.140 data channel, it MUST mark the data channel as recvonly with a 'recvonly' attribute inside a 'dcsa' attribute.
申し出がT.140データチャネルでのみテキストのみを受信したい場合は、「DCSA」属性内の「Revonly」属性を使用してデータチャネルをRecvonlyとしてマークする必要があります。
If the offerer wishes to neither send nor receive text on a T.140 data channel, it MUST mark the data channel as inactive with an 'inactive' attribute inside a 'dcsa' attribute.
申し出がT.140データチャネルで送信されても受信しない場合は、「DCSA」属性内の「非アクティブ」属性を使用してデータチャネルを非アクティブにマークする必要があります。
If the offerer has marked a data channel as sendrecv (or if the offerer did not explicitly mark the data channel) or recvonly, it MUST be prepared to receive T.140 data as soon as the state of the T.140 data channel allows it.
オファーがSendRecvとしてデータチャネルをマークした場合（またはオファーが明示的にデータチャネルを明示的にマークしなかった場合）、またはRevonlyにマークされている場合は、T.140データチャネルの状態が許容されるとすぐにT.140データを受信するように準備する必要があります。。
When the answerer accepts an offer and marks the direction of the text in the corresponding answer, the direction is based on the marking (or the lack of explicit marking) in the offer.
回答者がオファーを受け入れて対応する答えでテキストの方向をマークすると、その方向はオファーのマーキング（または明示的なマーキングの欠如）に基づいています。
If the offerer either explicitly marked the data channel as sendrecv or did not mark the data channel, the answerer SHOULD mark the data channel as sendrecv, sendonly, recvonly, or inactive with a 'sendrecv', 'sendonly', 'recvonly', or 'inactive' attribute, respectively, inside a 'dcsa' attribute. If the answerer does not explicitly mark the data channel, an implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default.
オファーがData ChannelをSendRecvとして明示的にマークしたりデータチャネルをマークしなかった場合、回答者はデータチャネルをSendRecv、SendOnly、Revonly、またはInactive、またはInactive、または非アクティブにマークする必要があります。'DCSA'属性内の「非アクティブ」属性。回答者がデータチャネルを明示的にマークしない場合、「DCSA」属性内の暗黙の 'sendRecv'属性がデフォルトで適用されます。
If the offerer marked the data channel as sendonly, the answerer MUST mark the data channel as recvonly or inactive with a 'recvonly' or 'inactive' attribute, respectively, inside a 'dcsa' attribute.
オファーがデータチャネルをSendOnlyとしてマークした場合、回答者はデータチャネルを「DCSA」属性内で「Recvonly」または 'inactive'属性を使用して、それぞれRevonlyまたは非アクティブなものとしてマークを付けなければなりません。
If the offerer marked the data channel as recvonly, the answerer MUST mark the data channel as sendonly or inactive with a 'sendonly' or 'inactive' attribute, respectively, inside a 'dcsa' attribute.
オファーがデータチャネルをRecVONLYとしてマークした場合、回答者はデータチャネルを「DCSA」属性内で「SendOnly」または 'inactive'属性を使用して、それぞれ 'sendonly'属性または 'inactive'属性を使用してデータチャネルをマークする必要があります。
If the offerer marked the data channel as inactive, the answerer MUST mark the data channel as inactive with an 'inactive' attribute inside a 'dcsa' attribute.
オファーがデータチャネルを非アクティブとしてマークした場合、回答者はデータチャネルを「DCSA」属性内の 'inactive'属性を使用して非アクティブとしてマークを付けなければなりません。
If the answerer has marked a data channel as sendrecv or recvonly, it MUST be prepared to receive data as soon as the state of the T.140 data channel allows transmission of data.
回答者がデータチャネルをSendRecvまたはRecvonlyとしてマークした場合、T.140データチャネルの状態がデータの送信を許可するとすぐにデータを受信する準備をしなければなりません。
When the offerer receives an answer to the offer and the answerer has marked a data channel as sendrecv (or the answerer did not mark the data channel) or recvonly in the answer, the offerer can start sending T.140 data as soon as the state of the T.140 data channel allows it. If the answerer has marked the data channel as inactive or sendonly, the offerer MUST NOT send any T.140 data.
オファーがオファーに答えを受け取り、回答者がSendRecv（または回答者がデータチャネルをマークしなかった）または回答の中でデータチャネルをマークした場合、オファーは州からすぐにT.140データの送信を開始できます。T.140データチャネルのうちの1回答者がデータチャネルを非アクティブまたは送信者としてマークした場合、オファーはT.140データを送信してはいけません。
If the answerer has not marked the direction of a T.140 data channel in accordance with the procedures above, it is RECOMMENDED that the offerer not process that scenario as an error situation but rather assume that the answerer might both send and receive T.140 data on the data channel.
上記の手順に従って、回答者がT.140データチャネルの方向をマークしていない場合、オファーはそのシナリオをエラー状況として処理しないことをお勧めしますが、むしろ回答者がT.140を送受信することができると推奨することをお勧めします。データチャネル上のデータ。
If an endpoint wishes to modify a previously negotiated text direction in an ongoing session, it MUST initiate an offer that indicates the new direction, following the rules in Section 4.2.3.1. If the answerer accepts the offer, it follows the procedures in Section 4.2.3.2.
エンドポイントが進行中のセッションで以前にネゴシエートされたテキスト方向を変更したい場合は、セクション4.2.3.1の規則に従って、新しい方向を示すオファーを開始する必要があります。回答者がオファーを受け入れる場合は、4.2.3.2項の手順に従います。
Below is an example of an "m=" section of an offer for a T.140 data channel offering real-time text conversation in Spanish and Esperanto, and an "m=" section in the associated answer accepting Esperanto. The maximum character transmission rate is set to 20. As the offerer and answerer have not explicitly indicated the real-time text direction, the default direction "sendrecv" applies.
以下は、スペイン語とエスペラント語でリアルタイムのテキスト会話を提供するT.140データチャネルのオファーの「M =」セクションの例です。最大文字伝送速度は20に設定されています。オファーと回答者がリアルタイムのテキスト方向を明示的に示されていないので、デフォルトの方向 "SendRecv"が適用されます。
Offer:
提供：
m=application 911 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3
a=max-message-size:1000
a=sctp-port 5000
a=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:es eo
a=dcsa:2 hlang-recv:es eo
Answer:
回答：
m=application 2004 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1
a=max-message-size:1000
a=sctp-port 6000
a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:eo
a=dcsa:2 hlang-recv:eo
Below is an example of an "m=" section of an offer for a T.140 data channel where the offerer wishes to only receive real-time text, and an "m=" section in the associated answer indicating that the answerer will only send real-time text. No maximum character transmission rate is indicated. No preference for the language to be used for the real-time text conversation is indicated.
以下は、提供者がリアルタイムテキストのみを受信したいと望んでいるT.140データチャネルのオファーの「M =」セクションの例であり、関連付けられた回答の「M =」セクションは、回答者だけであることを示しています。リアルタイムテキストを送信してください。最大文字伝送速度は示されていません。リアルタイムテキスト会話に使用される言語を好みません。
Offer:
提供：
m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3
a=max-message-size:1000
a=sctp-port 5000
a=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 recvonly
Answer:
回答：
m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1
a=max-message-size:1000
a=sctp-port 6000
a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 sendonly
Section 6.1 of [T140] describes the generic T.140 session control functions at a high level, in a manner that is independent of the signaling protocol. The list below describes how the functions are realized when using a T.140 data channel.
[T140]のセクション6.1は、シグナリングプロトコルとは無関係の方法で、一般的なT.140セッション制御機能をハイレベルで説明しています。以下のリストは、T.140データチャネルを使用するときにどのように機能が実現されるかを説明しています。
Prepare session: An endpoint can indicate its support of T.140 data channels using signaling-specific means (e.g., using SIP OPTIONS [RFC3261]) or by indicating the support in an offer or answer (Section 4).
準備セッション：エンドポイントは、シグナリング固有の手段（例えば、SIPオプション[RFC3261]を使用）またはオファーまたは回答のサポートを示すことによって、T.140データチャネルのそのサポートを示すことができます（セクション4）。
Initiate session: An offer is used to request the establishment of a T.140 data channel (Section 4).
セッションを開始する：オファーがT.140データチャネルの確立を要求するために使用されます（セクション4）。
Accept session: An answer is used to accept a request to establish a T.140 data channel (Section 4).
セッションを受け入れる：答えは、T.140データチャネルを確立するための要求を受け入れるために使用されます（セクション4）。
Deny session: An answer is used to reject a request to establish a T.140 data channel, using the generic procedures for rejecting a data channel [RFC8864].
拒否セッション：データチャネル[RFC8864]を拒否するための一般的な手順を使用して、T.140データチャネルを確立する要求を拒否するために答えが使用されます。
Disconnect session: An offer or answer is used to disable a previously established T.140 data channel, using the generic procedures for closing a data channel [RFC8864].
切断セッション：データチャネル[RFC8864]を閉じるための一般的な手順を使用して、以前に確立されたT.140データチャネルを無効にするためにオファーまたは回答が使用されます。
Data: Data is sent on an established T.140 data channel (Section 5.2).
データ：確立されたT.140データチャネルでデータが送信されます（セクション5.2）。
T.140 text is encoded and framed as T140blocks [RFC4103].
T.140テキストは、T140Blocks [RFC4103]としてエンコードされ、フレームを付けます。
Each T140block is sent on the SCTP stream [RFC4960] used to realize the T.140 data channel using standard T.140 transmission procedures [T140]. One or more T140blocks can be sent in a single SCTP user message [RFC4960]. Unlike RTP-based transport for real-time text [RFC4103], T.140 data channels do not use redundant transmission of text; this is because the T.140 data channel achieves robust transmission by using the "reliable" mode of the data channel.
各T140ブロックはSCTPストリームで送信されます[RFC4960]は、標準T.140送信手順[T140]を使用してT.140データチャネルを実現するために送信されます。1つ以上のT140ブロックを単一のSCTPユーザーメッセージで送信することができます[RFC4960]。リアルタイムテキストのRTPベースのトランスポートとは異なり、T.140データチャネルはテキストの冗長送信を使用しません。これは、T.140データチャネルがデータチャネルの「信頼できる」モードを使用して堅牢な送信を実現するためです。
Data-sending procedures conform to [T140].
データ送信手順[T140]に準拠しています。
See Section 8 of [T140] for coding details.
コーディングの詳細については[T140]のセクション8を参照してください。
| NOTE: The T.140 coding details contain information on optional
| control codes for controlling the presentation; these control
| codes may not be supported by the presentation level of the
| receiving application. The receiving application is expected
| to handle reception of such T.140 control codes appropriately
| (e.g., ignore and skip them) even if their effect on the
| presentation is not supported.
As described in [T140], buffering can be used to reduce overhead, with the maximum assigned transmission interval of T140blocks from the buffer being 500 ms as long as there is text to send.
[T140]に記載されているように、バッファリングを使用してオーバーヘッドを減らすことができ、送信するテキストがある限り、バッファからの最大割り当てされた送信間隔は500msである。
Buffering MAY also be used for staying within the maximum character transmission rate (Section 4.2).
バッファリングは、最大文字伝送速度内に留まるためにも使用され得る（4.2項）。
An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a transmission interval. It is RECOMMENDED to use the default transmission interval of 300 ms [RFC4103], for T.140 data channels. Implementers might also use lower values for specific applications requiring low latency, taking the increased overhead into consideration.
伝送間隔を割り当てるときに、実装は、リアルタイムのテキスト会話において、スムーズなフローおよび低い待ち時間のためにユーザ要件を取得する必要があります。T.140データチャネルでは、300 ms [RFC4103]のデフォルトの送信間隔を使用することをお勧めします。実装者は、低い待ち時間を必要とする特定のアプリケーションにも低い値を使用することができ、オーバーヘッドの増加を考慮に入れた。
In the case of network failure or congestion, T.140 data channels might fail and get torn down. If this happens but the session is sustained, it is RECOMMENDED that implementations try to reestablish the T.140 data channels. As a T.140 data channel does not provide a mechanism for the receiver to identify retransmitted T140blocks after channel reestablishment, the sending endpoint MUST NOT retransmit T140blocks. Similarly, a receiver SHOULD indicate to the user that a channel has been reestablished and text might have been lost. This MAY be done by inserting the missing text markers [T140ad1] or in any other way evident to the user.
ネットワーク障害や輻輳の場合、T.140データチャネルが失敗し、引き裂かれる可能性があります。これが起こるがセッションが持続する場合は、実装がT.140データチャネルを再確立しようとすることをお勧めします。T.140データチャネルは、チャネル再確立後に再送信されたT140ブロックを識別するための受信機のメカニズムを提供しないので、送信エンドポイントはT140ブロックを再送信してはいけません。同様に、受信機は、チャネルが再確立され、テキストが失われた可能性があることをユーザーに示す必要があります。これは、欠けているテキストマーカー[T140AD1]を挿入することによって、または他の方法でユーザーに明らかにされて行われる可能性があります。
| NOTE: If the SCTP association [RFC4960] used to realize the
| T.140 data channel fails and gets torn down, it needs to be
| reestablished before the T.140 data channel can be
| reestablished. After the T.140 data channel is reestablished,
| the procedures defined in this section apply, regardless of
| whether only the T.140 data channel or the whole SCTP
| association got torn down.
If an implementation needs to support multi-party scenarios, the implementation needs to support multiple simultaneous T.140 data channels, one for each remote party. At the time of writing this document, this is true even in scenarios where each participant communicates via a centralized conference server. This is because, unlike RTP media, WebRTC data channels and the T.140 protocol do not support the indication of the source of T.140 data. The 'label' attribute parameter in the SDP 'dcmap' attribute (Section 4.1) can be used by the offerer to provide additional information about each T.140 data channel and help implementations to distinguish between them.
実装がマルチパーティのシナリオをサポートする必要がある場合、実装は各リモートパーティに対して1つずつ、複数の同時T.140データチャネルをサポートする必要があります。この文書を書くときは、各参加者が集中型の会議サーバーを介して通信するシナリオでも当てはまります。これは、RTPメディア、WEBRTCデータチャネルとは異なり、T.140プロトコルはT.140データのソースの表示をサポートしていないためです。SDP 'DCMAP'属性（セクション4.1）内の 'Label'属性パラメータは、各T.140データチャネルに関する追加情報を提供し、それらを区別するための実装を提供するために、オファーによって使用されます。
| NOTE: Future extensions to T.140 or the T140block might permit
| the indication of the source of T.140 data, in which case it
| might be possible to use a single T.140 data channel to
| transport data from multiple remote sources. The usage of a
| single T.140 data channel, without any protocol extensions,
| would require the conference server to only forward real-time
| text from one source at any given time and, for example,
| include human-readable text labels in the real-time text stream
| that indicate the source whenever the conference server
| switches the source. This would allow the receiver to present
| real-time text from different sources separately. The
| procedures for such a mechanism are outside the scope of this
| document.
A number of real-time text transports and protocols have been defined for both packet-switched and circuit-switched networks. Many are based on the ITU-T T.140 protocol at the application and presentation levels [T140]. At the time of writing this document, some mechanisms are no longer used, as the technologies they use have been obsoleted, while others are still in use.
パケット交換ネットワークと回線交換ネットワークの両方について、いくつかのリアルタイムテキストトランスポートとプロトコルが定義されています。多くの人は、アプリケーションとプレゼンテーションレベルでのITU-T T.140プロトコルに基づいています[T140]。この文書を書く際は、使用している技術が廃止されていますが、他のものはまだ使用されていますが、いくつかのメカニズムは使用されなくなりました。
When performing interworking between T.140 data channels and real-time text in other transports and protocols, a number of factors need to be considered. At the time of writing this document, the most common IP-based real-time text transport is the RTP-based mechanism defined in [RFC4103]. While this document does not define a complete interworking solution, the list below provides some guidance and considerations to take into account when designing a gateway for interworking between T.140 data channels and RTP-based T.140 transport:
他のトランスポートおよびプロトコルのデータチャネルとリアルタイムテキストとの間でインターワーキングを実行する場合、いくつかの要因を考慮する必要がある。この文書の書き込み時には、最も一般的なIPベースのリアルタイムテキストトランスポートは[RFC4103]で定義されているRTPベースのメカニズムです。この文書は完全なインターワーキングソリューションを定義していませんが、T.140データチャネルとRTPベースのT.140トランスポートとの間のインターワーキングのためのゲートウェイを設計するときに考慮に入れるためのガイダンスと考慮事項を次のように提供します。
* For each T.140 data channel, there is an RTP stream for real-time text [RFC4103]. Redundancy is by default declared and used on the RTP stream. There is no redundancy on the T.140 data channel, but the reliable property [RFC8864] is set on it.
* T.140データチャネルごとに、リアルタイムテキストのRTPストリームがあります[RFC4103]。冗長性はデフォルトで宣言され、RTPストリームで使用されます。T.140データチャネルに冗長性はありませんが、信頼性のあるプロパティ[RFC8864]が設定されています。
* During a normal text flow, T140blocks received from one network are forwarded towards the other network. Keepalive traffic is handled by lower layers on the T.140 data channel. A gateway might have to extract keepalives from incoming RTP streams and MAY generate keepalives on outgoing RTP streams.
* 通常のテキストフローの間、あるネットワークから受信されたT140ブロックは他のネットワークに向かって転送される。キープアライブトラフィックは、T.140データチャネルの下位層によって処理されます。ゲートウェイは、着信RTPストリームからキープアライブを抽出する必要があり、発信RTPストリームでキープアライブを生成することがあります。
* If the gateway detects or suspects loss of data on the RTP stream and the lost data has not been retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel.
* ゲートウェイがRTPストリームのデータの損失を検出または容疑すると、冗長性のメカニズムを使用して失われたデータが取得されていない場合、ゲートウェイはT.140の欠落テキストマーカー[T140AD1]を送信T.140で送信されたデータに挿入する必要があります。データチャネル
* If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing RTP stream if it detects or suspects that data sent by the remote T.140 data channel endpoint was lost.
* ゲートウェイがT.140データチャネルが失敗して破棄されたことを検出し、データチャネルが再確立されたらゲートウェイは、発信RTPストリームで送信されたデータにT.140の欠落テキストマーカー[T140AD1]を挿入する必要があります。リモートT.140データチャネルエンドポイントによって送信されたデータが失われたことを検出または疑われる。
* If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel if it detects or suspects that data sent or to be sent on the T.140 data channel was lost during the failure.
* T.140データチャネルが失敗して破断したことをゲートウェイが検出した場合、データチャネルが再確立されると、ゲートウェイは送信T.140データで送信されたデータにT.140の欠落テキストマーカー[T140AD1]を挿入する必要があります。チャンネル障害の間にT.140データチャネルで送信または送信されるデータを検出または疑われる場合。
* The gateway MUST indicate the same text transmission direction (Section 4.2.3) on the T.140 data channel and the RTP stream.
* ゲートウェイは、T.140データチャネルとRTPストリームの同じテキスト送信方向（セクション4.2.3）を示す必要があります。
| NOTE: In order for the gateway to insert a missing text marker
| or perform other actions that require that the gateway have
| access to the T.140 data, the T.140 data cannot be encrypted
| end to end between the T.140 data channel endpoint and the RTP
| endpoint. At the time of writing this document, no mechanism
| to provide such end-to-end encryption is defined.
| NOTE: The guidance and considerations above are for two-party
| connections. At the time of writing this specification, a
| multi-party solution for RTP-based T.140 transport had not yet
| been specified. Once such a solution is specified, it might
| have an impact on the above interworking guidance and
| considerations.
This document updates [RFC8373] by defining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for the "application/webrtc-datachannel" media type.
このドキュメントは、SDP 'HLANG-SEND'属性と 'hlang-recv'属性が "application / webrtc-datachannel"メディアタイプにどのように使用されるかを定義することによって、[RFC8373]を更新します。
SDP offerers and answerers MUST NOT include the attributes directly in the "m=" section associated with the "application/webrtc-datachannel" media type. Instead, the attributes MUST be associated with individual data channels, using the SDP 'dcsa' attribute. A specification that defines a subprotocol that uses the attributes MUST specify the modality for that subprotocol, or how to retrieve the modality if the subprotocol supports multiple modalities. The subprotocol is indicated using the SDP 'dcmap' attribute.
SDPの提供者と回答者は、「アプリケーション/ WEBRTC-DataChannel」メディアタイプに関連付けられている「M =」セクションに直接属性を含めてはいけません。代わりに、属性は、SDP 'DCSA'属性を使用して、個々のデータチャネルに関連付けられている必要があります。属性を使用するサブプロトコルを定義する仕様は、そのサブプロタコクトのモダリティを指定する必要があります。サブプロトコルが複数のモダリティをサポートしている場合は、モダリティを取得する方法を指定する必要があります。サブプロトコルはSDP 'DCMAP'属性を使用して示されます。
The generic WebRTC security considerations are defined in [RFC8826] and [RFC8827].
一般的なWebRTCセキュリティ上の考慮事項は[RFC8826]と[RFC8827]で定義されています。
The generic security considerations for WebRTC data channels are defined in [RFC8831]. As data channels are always encrypted by design, the T.140 data channels will also be encrypted.
WebRTCデータチャネルに関する一般的なセキュリティ上の考慮事項は[RFC8831]で定義されています。データチャネルは常に設計によって暗号化されているので、T.140データチャネルも暗号化されます。
The generic security considerations for negotiating data channels using the SDP offer/answer mechanism are defined in [RFC8864]. There are no additional security considerations specific to T.140 data channels.
SDPオファー/回答メカニズムを使用してデータチャネルを交渉するための一般的なセキュリティ上の考慮事項は[RFC8864]で定義されています。T.140データチャネルに固有の追加のセキュリティ上の考慮事項はありません。
When performing interworking between T.140 data channels and RTP-based T.140 transport [RFC4103], in order for a gateway to insert a missing text marker or perform other actions that require that the gateway have access to the T.140 data, the T.140 data cannot be encrypted end to end between the T.140 data channel endpoint and the RTP endpoint.
T.140データチャネルとRTPベースのT.140トランスポート[RFC4103]の間にインターワーキングを実行する場合は、ゲートウェイが不足しているテキストマーカーを挿入するか、ゲートウェイがT.140データにアクセスできる他のアクションを実行するために、T.140データは、T.140データチャネルエンドポイントとRTPエンドポイントの間で暗号化された端に終わりを暗号化できません。
Per this document, the subprotocol identifier "t140" has been added to the "WebSocket Subprotocol Name Registry" as follows:
この文書ごとに、サブプロタコール識別子「T140」が次のように「WebSocketサブプロタ名レジストリ」に追加されました。
Subprotocol Identifier: t140
サブプロトコル識別子：T140
Subprotocol Common Name: ITU-T T.140 Real-Time Text
サブプロトコル共通名：ITU-T T.140リアルタイムテキスト
Subprotocol Definition: RFC 8865
サブプロトコルの定義：RFC 8865
Reference: RFC 8865
参照：RFC 8865
This document defines the usage of the SDP 'fmtp' attribute, if this attribute is included in an SDP 'dcsa' attribute associated with a T.140 real-time text session over a WebRTC data channel. The usage is defined in Section 4.2.1.
この属性が、WebRTCデータチャネルを介したT.140リアルタイムテキストセッションに関連付けられているSDP 'DCSA'属性に含まれている場合、このドキュメントはSDP 'fmtp'属性の使用法を定義します。使用法はセクション4.2.1で定義されています。
The usage level "dcsa (t140)" has been added to the registration of the SDP 'fmtp' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「セッション記述プロトコル（SDP）パラメータ」レジストリ内のSDP 'fmtp'属性の登録に使用レベル "DCSA（T140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: fmtp
属性名：FMTP
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Indicate format parameters for a T.140 data channel, such as maximum character transmission rates.
目的：最大文字伝送速度など、T.140データチャネルのフォーマットパラメータを指定します。
Reference: RFC 8865
参照：RFC 8865
This document modifies the usage of the SDP 'hlang-send' and 'hlang-recv' attributes, if these attributes are included in SDP 'dcsa' attributes associated with a T.140 data channel. The modified usage is described in Section 4.2.2.
T.140データチャネルに関連付けられているSDP 'DCSA'属性に含まれる場合、このドキュメントはSDP 'hlang-send'属性と 'hlang-recv'属性の使用状況を変更します。修正された使用法は4.2.2項で説明されています。
The usage level "dcsa (t140)" has been added to the registration of the SDP 'hlang-send' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「セッション記述プロトコル（SDP）パラメータ」レジストリのSDP 'hlang-send'属性の登録に使用量レベル "DCSA（t140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: hlang-send
属性名：Hlang-Send.
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Negotiate the language to be used on a T.140 data channel.
目的：T.140データチャネルで使用される言語を交渉します。
Reference: RFC 8865
参照：RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'hlang-recv' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「セッション記述プロトコル（SDP）パラメータ」レジストリのSDP 'hlang-recv'属性の登録に使用量レベル "DCSA（T140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: hlang-recv
属性名：HLANG-RECV
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Negotiate the language to be used on a T.140 data channel.
目的：T.140データチャネルで使用される言語を交渉します。
Reference: RFC 8865
参照：RFC 8865
This document modifies the usage of the SDP 'sendonly', 'recvonly', 'sendrecv', and 'inactive' attributes, if these attributes are included in SDP 'dcsa' attributes associated with a T.140 data channel. The modified usage is described in Section 4.2.3.
この文書は、T.140データチャネルに関連付けられているSDP 'DCSA'属性に含まれている場合、SDP 'SendOnly'、 'Revonly'、 'SendRecv'、および 'Inactive'属性の使用状況を変更します。修正された使用法はセクション4.2.3で説明されています。
The usage level "dcsa (t140)" has been added to the registration of the SDP 'sendonly' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「Session Description Protocol（SDP）パラメータ」レジストリのSDP 'SendOnly'属性の登録に使用量レベル "DCSA（T140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: sendonly
属性名：SendOnly
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Negotiate the direction in which real-time text can be sent on a T.140 data channel.
目的：リアルタイムテキストをT.140データチャネルで送信できる方向をネゴシエートします。
Reference: RFC 8865
参照：RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'recvonly' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「セッション記述プロトコル（SDP）パラメータ」レジストリのSDP 'Revonly'属性の登録に使用量レベル "DCSA（T140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: recvonly
属性名：Recvonly.
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Negotiate the direction in which real-time text can be sent on a T.140 data channel.
目的：リアルタイムテキストをT.140データチャネルで送信できる方向をネゴシエートします。
Reference: RFC 8865
参照：RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'sendrecv' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「セッション記述プロトコル（SDP）パラメータ」レジストリ内のSDP 'sendRecv'属性の登録に使用量レベル "DCSA（T140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: sendrecv
属性名：SendRecv
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Negotiate the direction in which real-time text can be sent on a T.140 data channel.
目的：リアルタイムテキストをT.140データチャネルで送信できる方向をネゴシエートします。
Reference: RFC 8865
参照：RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'inactive' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:
次のように、「セッション記述プロトコル（SDP）パラメータ」レジストリ内のSDP 'inactial'属性の登録に使用量レベル "DCSA（T140）"が追加されました。
Contact name: IESG
連絡先名：IESG
Contact email: iesg@ietf.org
Eメール：iesg@ietf.org.
Attribute name: inactive
属性名：非アクティブ
Usage level: dcsa (t140)
使用レベル：DCSA（T140）
Purpose: Negotiate the direction in which real-time text can be sent on a T.140 data channel.
目的：リアルタイムテキストをT.140データチャネルで送信できる方向をネゴシエートします。
Reference: RFC 8865
参照：RFC 8865
[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>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G.およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<https://www.rfc-editor.org/info/rfc4103>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[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>。
[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>。
[RFC8373] Gellens, R., "Negotiating Human Language in Real-Time Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, <https://www.rfc-editor.org/info/rfc8373>.
[RFC8373] Gellens、R.、「リアルタイム通信における人語の交渉」、RFC 8373、DOI 10.17487 / RFC8373、2018年5月、<https：//www.rfc-editor.org/info/rfc8373>。
[RFC8826] Rescorla, E., "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, January 2021, <https://www.rfc-editor.org/info/rfc8826>.
[RFC8826] Rescorla、E.、「WebRTCのセキュリティ上の考慮事項」、RFC 8826、DOI 10.17487 / RFC8826、2021年1月、<https：//www.rfc-editor.org/info/rfc8826>。
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.
[RFC8827] Rescorla、E.、「Webrtc Security Architecture」、RFC 8827、DOI 10.17487 / RFC8827、2021年1月、<https：//www.rfc-editor.org/info/rfc8827>。
[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>。
[RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>.
[RFC8864]ドラジング、K.、Makaraju、M.、Ejzak、R.、Marcon、J.、およびR.さえ、「セッション記述プロトコルを使用したネゴシエーションデータチャネル（SDP）」、RFC 8864、DOI 10.17487/ RFC8864、2021年1月、<https://www.rfc-editor.org/info/rfc8864>。
[T140] ITU-T, "Protocol for multimedia application text conversation", Recommendation ITU-T T.140, February 1998, <https://www.itu.int/rec/T-REC-T.140-199802-I/en>.
[T140] ITU-T、「マルチメディアアプリケーションのテキスト会話のためのプロトコル」、勧告ITU-T T.140、1998年2月、<https：//www.itu.int/rec/t-rec-t.140-199802-i / en>。
[T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 (02/2000), Protocol for multimedia application text conversation", February 2000, <https://www.itu.int/rec/T-REC-T.140-200002-I!Add1/en>.
[T140AD1] ITU-T、「推奨ITU-T.140補遺1（02/2000）、マルチメディアアプリケーションテキスト会話のためのプロトコル」、2000年2月、<https：//www.itu.int/rec/t-rec-T.140-200002-i！add1 / en>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[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>。
Acknowledgements
謝辞
This document is based on an earlier Internet-Draft edited by Keith Drage, Juergen Stoetzer-Bradler, and Albrecht Schwarz.
この文書は、Keith Drage、Juergen Stoetzer-Bradler、Albrecht Schwarzが編集した以前のインターネットドラフトに基づいています。
Thomas Belling provided useful comments on the initial (pre-submission) version of the current document. Paul Kyzivat and Bernard Aboba provided comments on the document.
Thomas Bellingは、現在の文書の最初の（前払い）バージョンについて有用なコメントを提供しました。Paul KyzivatとBernard Abobaは文書についてコメントを提供しました。
Authors' Addresses
著者の住所
Christer Holmberg Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
Christer Holmberg Ericsson Hirsalantie 11 Fi-02420 Jorvas Finland
Email: christer.holmberg@ericsson.com
Gunnar Hellström Gunnar Hellström Accessible Communication Esplanaden 30 SE-136 70 Vendelsö Sweden
GunnarHellströmGunnarHellströmアクセス可能なコミュニケーションEsplanaden 30 SE-136 70VendelsÖスウェーデン
Email: gunnar.hellstrom@ghaccess.se