[要約] RFC 8835は、WebRTC (Web Real-Time Communication) のためのトランスポートプロトコルに関する文書です。このRFCは、WebRTCがリアルタイムの音声、ビデオ、データ通信を可能にするために使用するトランスポートメカニズムを定義しています。具体的には、Interactive Connectivity Establishment (ICE)、Session Traversal Utilities for NAT (STUN)、Traversal Using Relays around NAT (TURN) などのプロトコルを使用して、NATやファイアウォールを越えた通信を実現します。このRFCは、WebRTCをサポートするブラウザやアプリケーションの開発者にとって重要であり、関連するRFCにはRFC 5245 (ICE)、RFC 5389 (STUN)、RFC 5766 (TURN) などがあります。
Internet Engineering Task Force (IETF) H. Alvestrand
Request for Comments: 8835 Google
Category: Standards Track January 2021
ISSN: 2070-1721
Transports for WebRTC
WebRTCの輸送
Abstract
概要
This document describes the data transport protocols used by Web Real-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes.
このドキュメントでは、ファイアウォール、リレー、およびNATボックスなどの中間ボックスとの対話に使用されるプロトコルを含む、Webリアルタイム通信（WEBRTC）によって使用されるデータ転送プロトコルについて説明します。
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/rfc8835.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8835で入手できます。
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. Requirements Language
3. Transport and Middlebox Specification
3.1. System-Provided Interfaces
3.2. Ability to Use IPv4 and IPv6
3.3. Usage of Temporary IPv6 Addresses
3.4. Middlebox-Related Functions
3.5. Transport Protocols Implemented
4. Media Prioritization
4.1. Local Prioritization
4.2. Usage of Quality of Service -- DSCP and Multiplexing
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address
WebRTC is a protocol suite aimed at real-time multimedia exchange between browsers, and between browsers and other entities.
WebRTCは、ブラウザ間のリアルタイムのマルチメディア交換を目的としたプロトコルスイートです。ブラウザとブラウザやその他のエンティティ。
WebRTC is described in the WebRTC overview document [RFC8825], which also defines terminology used in this document, including the terms "WebRTC endpoint" and "WebRTC browser".
WebRTCは、「WEBRTCエンドポイント」および「WEBRTCブラウザ」という用語を含む、この文書で使用されている用語を定義するWebRTC概要文書[RFC8825]に記載されています。
Terminology for RTP sources is taken from [RFC7656].
RTPソースの用語は[RFC7656]から取得されます。
This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes.
このドキュメントは、ファイアウォール、リレー、およびNATボックスなどの中間ボックスとの対話に使用されるプロトコルを含む、実装を適合させることによって使用されるデータ転送プロトコルに焦点を当てています。
This protocol suite is intended to satisfy the security considerations described in the WebRTC security documents, [RFC8826] and [RFC8827].
このプロトコルスイートは、WebRTCセキュリティ文書、[RFC8826]と[RFC8827]に記載されているセキュリティ上の考慮事項を満たすことを目的としています。
This document describes requirements that apply to all WebRTC endpoints. When there are requirements that apply only to WebRTC browsers, this is called out explicitly.
このドキュメントでは、すべてのWebRTCエンドポイントに適用される要件について説明します。WebRTCブラウザにのみ適用される要件がある場合は、これは明示的に呼び出されます。
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 protocol specifications used here assume that the following protocols are available to the implementations of the WebRTC protocols:
ここで使用されているプロトコル仕様は、WebRTCプロトコルの実装に次のプロトコルが利用可能であるとします。
UDP [RFC0768]: This is the protocol assumed by most protocol elements described.
UDP [RFC0768]：これは、記載されているほとんどのプロトコル要素が想定しているプロトコルです。
TCP [RFC0793]: This is used for HTTP/WebSockets, as well as TURN/TLS and ICE-TCP.
TCP [RFC0793]：これはHTTP / WebSocket、ターン/ TLSおよびICE-TCPに使用されます。
For both protocols, IPv4 and IPv6 support is assumed.
プロトコルの両方の場合、IPv4とIPv6のサポートが想定されています。
For UDP, this specification assumes the ability to set the Differentiated Services Code Point (DSCP) of the sockets opened on a per-packet basis, in order to achieve the prioritizations described in [RFC8837] (see Section 4.2 of this document) when multiple media types are multiplexed. It does not assume that the DSCPs will be honored and does assume that they may be zeroed or changed, since this is a local configuration issue.
UDPの場合、この仕様は、[RFC8837]で説明されている優先順位付けを達成するために、パケットごとに開かれたソケットの差別化サービスコードポイント（DSCP）を設定する機能（この文書のセクション4.2を参照）を想定しています。メディアタイプは多重化されています。これはローカル構成の問題であるため、DSCPが尊重され、それらがゼロにされたり変更される可能性があると仮定していません。
Platforms that do not give access to these interfaces will not be able to support a conforming WebRTC endpoint.
これらのインタフェースにアクセスしないプラットフォームは、準拠のWebRTCエンドポイントをサポートすることはできません。
This specification does not assume that the implementation will have access to ICMP or raw IP.
この仕様は、実装にICMPまたはRAW IPにアクセスできるとは想定していません。
The following protocols may be used, but they can be implemented by a WebRTC endpoint and are therefore not defined as "system-provided interfaces":
以下のプロトコルを使用することができますが、それらはWebRTCエンドポイントによって実装することができ、したがって「システム提供のインタフェース」として定義されていません。
TURN: Traversal Using Relays Around NAT [RFC8656]
ターン：NAT周辺のリレーを使用したトラバーサル[RFC8656]
STUN: Session Traversal Utilities for NAT [RFC5389]
STUN：NATのセッショントラバーサルユーティリティ[RFC5389]
ICE: Interactive Connectivity Establishment [RFC8445]
ICE：インタラクティブ接続確立[RFC8445]
TLS: Transport Layer Security [RFC8446]
TLS：トランスポート層セキュリティ[RFC8446]
DTLS: Datagram Transport Layer Security [RFC6347]
DTLS：データグラムトランスポートレイヤセキュリティ[RFC6347]
Web applications running in a WebRTC browser MUST be able to utilize both IPv4 and IPv6 where available -- that is, when two peers have only IPv4 connectivity to each other, or they have only IPv6 connectivity to each other, applications running in the WebRTC browser MUST be able to communicate.
WebRTCブラウザで実行されているWebアプリケーションは、IPv4とIPv6の両方を利用できなければなりません。利用可能な場合は、すなわち、2つのピアが互いにIPv4接続のみを持っている場合、または互いにIPv6接続のみを持ち、WEBRTCブラウザで実行されているアプリケーション通信できる必要があります。
When TURN is used, and the TURN server has IPv4 or IPv6 connectivity to the peer or the peer's TURN server, candidates of the appropriate types MUST be supported. The "Happy Eyeballs" specification for ICE [RFC8421] SHOULD be supported.
ターンが使用され、ターンサーバーにIPv4またはIPv6接続がピアまたはピアのターンサーバーに接続されている場合は、適切なタイプの候補をサポートする必要があります。ICE [RFC8421]の「ハッピーアイボール」仕様をサポートする必要があります。
The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses. This is a change from the rules specified by [RFC3484]. For applications that select a single address, this is usually done by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014]. However, this rule, which is intended to ensure that privacy-enhanced addresses are used in preference to static addresses, doesn't have the right effect in ICE, where all addresses are gathered and therefore revealed to the application. Therefore, the following rule is applied instead:
IPv6デフォルトアドレス選択仕様[RFC6724]は、一時アドレス[RFC4941]が永続アドレスを超えて優先されるように指定します。これは[RFC3484]で指定された規則からの変更です。単一のアドレスを選択するアプリケーションの場合、これは通常[RFC5014]で指定されたIPv6_prefer_src_tmp設定フラグによって行われます。ただし、この規則は、プライバシー強化されたアドレスが静的アドレスを優先して使用されることを目的としているため、すべてのアドレスが収集され、したがってアプリケーションに明らかにされているICEに正しい影響がありません。したがって、代わりに次の規則が適用されます。
When a WebRTC endpoint gathers all IPv6 addresses on its host, and both nondeprecated temporary addresses and permanent addresses of the same scope are present, the WebRTC endpoint SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724].
WebRTCエンドポイントがホスト上のすべてのIPv6アドレスを収集し、同じスコープの非推奨一時アドレスと永続アドレスの両方が存在する場合、WEBRTCエンドポイントはアドレスをアプリケーションに露光する前にまたはICE内でそれらを使用する前に永続アドレスを破棄する必要があります。これは[RFC6724]で説明されているデフォルトのポリシーと一致しています。
If some, but not all, of the temporary IPv6 addresses are marked deprecated, the WebRTC endpoint SHOULD discard the deprecated addresses, unless they are used by an ongoing connection. In an ICE restart, deprecated addresses that are currently in use MAY be retained.
一時的なIPv6アドレスの一部が廃止予定であるとマークされているものがある場合、WEBRTCエンドポイントは、継続的な接続によって使用されない限り、廃止予定アドレスを破棄する必要があります。アイス再始動では、現在使用されている廃止予定のアドレスを保持することができます。
The primary mechanism for dealing with middleboxes is ICE, which is an appropriate way to deal with NAT boxes and firewalls that accept traffic from the inside, but only from the outside if it is in response to inside traffic (simple stateful firewalls).
ミドルボックスを扱うための主なメカニズムはICEです。
ICE [RFC8445] MUST be supported. The implementation MUST be a full ICE implementation, not ICE-Lite. A full ICE implementation allows interworking with both ICE and ICE-Lite implementations when they are deployed appropriately.
ICE [RFC8445]をサポートする必要があります。実装は、アイスライトではなく、フルアイス実装でなければなりません。完全な氷の実装は、それらが適切に展開されたときにICEとICE-Liteの両方の実装との相互作用を可能にします。
In order to deal with situations where both parties are behind NATs of the type that perform endpoint-dependent mapping (as defined in [RFC5128], Section 2.4), TURN [RFC8656] MUST be supported.
両当事者がエンドポイント依存マッピングを実行するタイプのNATSの背後にある状況に対処するために（[RFC5128]で定義されているように）、[RFC8656]をサポートする必要があります。
WebRTC browsers MUST support configuration of STUN and TURN servers, from both browser configuration and an application.
WebRTCブラウザは、ブラウザ構成とアプリケーションの両方から、STUNサーバの設定をサポートしている必要があります。
Note that other work exists around STUN and TURN server discovery and management, including [RFC8155] for server discovery, as well as [RETURN].
STUN周辺の作業が存在し、サーバー検出用の[RFC8155]を含むサーバーの検出と管理、および[Return]を含む、サーバーの検出と管理を回します。
In order to deal with firewalls that block all UDP traffic, the mode of TURN that uses TCP between the WebRTC endpoint and the TURN server MUST be supported, and the mode of TURN that uses TLS over TCP between the WebRTC endpoint and the TURN server MUST be supported. See Section 3.1 of [RFC8656], for details.
すべてのUDPトラフィックをブロックするファイアウォールに対処するためには、WebRTCエンドポイントとターンサーバーの間でTCPを使用するターンをサポートし、WebRTCエンドポイントとターンサーバーの間のTCPを介してTLSを使用するターンモードを必要とする必要があります。サポートされています。詳細については、[RFC8656]のセクション3.1を参照してください。
In order to deal with situations where one party is on an IPv4 network and the other party is on an IPv6 network, TURN extensions for IPv6 MUST be supported.
一方の当事者がIPv4ネットワーク上にある状況に対処するためには、IPv6ネットワーク上にある場合は、IPv6の拡張機能をサポートする必要があります。
TURN TCP candidates, where the connection from the WebRTC endpoint's TURN server to the peer is a TCP connection, [RFC6062] MAY be supported.
TCP候補を回すTCP候補者は、WebRTCエンドポイントのターンサーバーからピアへの接続がTCP接続である場合、[RFC6062]がサポートされている可能性があります。
However, such candidates are not seen as providing any significant benefit, for the following reasons.
しかしながら、そのような候補者は、以下の理由から、大きな利益を提供するとは見なされない。
First, use of TURN TCP candidates would only be relevant in cases where both peers are required to use TCP to establish a connection.
まず、ターンTCP候補者の使用は、両方のピアが接続を確立するためにTCPを使用する必要がある場合にのみ関連するものであろう。
Second, that use case is supported in a different way by both sides establishing UDP relay candidates using TURN over TCP to connect to their respective relay servers.
第二に、そのユースケースは、TCPを介してUDPリレー候補を確立して、それぞれのリレーサーバーに接続するようにUDPリレー候補を確立することによって異なる方法でサポートされています。
Third, using TCP between the WebRTC endpoint's TURN server and the peer may result in more performance problems than using UDP, e.g., due to head of line blocking.
第3に、WebRTCエンドポイントのターンサーバとピアとの間のTCPを使用すると、例えば、Lineブロックの先頭のために、UDPを使用するよりもパフォーマンス上の問題が発生する可能性があります。
ICE-TCP candidates [RFC6544] MUST be supported; this may allow applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server.
ICE-TCP候補[RFC6544]はサポートされている必要があります。これにより、ターンサーバを使用せずに、UDPブロックファイアウォールにわたるパブリックIPアドレスを使用してアプリケーションが通信することができます。
If TCP connections are used, RTP framing according to [RFC4571] MUST be used for all packets. This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets.
TCP接続が使用されている場合、[RFC4571]に準拠したRTPフレーミングをすべてのパケットに使用する必要があります。これには、RTPパケット、データチャネルを伝送するために使用されるDTLSパケット、およびSTUN接続チェックパケットが含まれます。
The ALTERNATE-SERVER mechanism specified in Section 11 of [RFC5389] (300 Try Alternate) MUST be supported.
[RFC5389]のセクション11で指定されている代替サーバーメカニズム（300代替）をサポートする必要があります。
The WebRTC endpoint MAY support accessing the Internet through an HTTP proxy. If it does so, it MUST include the "ALPN" header as specified in [RFC7639], and proxy authentication as described in Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported.
WebRTCエンドポイントは、HTTPプロキシを介してインターネットへのアクセスをサポートすることがあります。その場合は、[RFC7639]で指定されている「ALPN」ヘッダーを含める必要があり、[RFC7231]のセクション4.3.6のプロキシ認証もサポートされている必要があります。
For transport of media, secure RTP is used. The details of the RTP profile used are described in "Media Transport and Use of RTP in WebRTC" [RFC8834], which mandates the use of a circuit breaker [RFC8083] and congestion control (see [RFC8836] for further guidance).
メディアの輸送のために、安全なRTPが使用されます。使用されたRTPプロファイルの詳細は、「Media TransportとWEBRTCのRTPの使用」[RFC8834]で記述されています。これは、サーキットブレーカー[RFC8083]と輻輳制御の使用を義務付けます（さらなるガイダンスのための[RFC8836]を参照）。
Key exchange MUST be done using DTLS-SRTP, as described in [RFC8827].
[RFC8827]に記載されているように、鍵交換はDTLS-SRTPを使用して行う必要があります。
For data transport over the WebRTC data channel [RFC8831], WebRTC endpoints MUST support SCTP over DTLS over ICE. This encapsulation is specified in [RFC8261]. Negotiation of this transport in the Session Description Protocol (SDP) is defined in [RFC8841]. The SCTP extension for I-DATA [RFC8260] MUST be supported.
WEBRTCデータチャネル[RFC8831]を介したデータ転送のために、WebRTCエンドポイントはice上のDTLS上のSCTPをサポートしなければなりません。このカプセル化は[RFC8261]に指定されています。セッション記述プロトコル（SDP）におけるこのトランスポートの交渉は、[RFC8841]で定義されています。I-DATA [RFC8260]のSCTP拡張子をサポートする必要があります。
The setup protocol for WebRTC data channels described in [RFC8832] MUST be supported.
[RFC8832]に記載されているWEBRTCデータチャネルのセットアッププロトコルをサポートする必要があります。
| Note: The interaction between DTLS-SRTP as defined in [RFC5764]
| and ICE as defined in [RFC8445] is described in Section 6 of
| [RFC8842]. The effect of this specification is that all ICE
| candidate pairs associated with a single component are part of
| the same DTLS association. Thus, there will only be one DTLS
| handshake, even if there are multiple valid candidate pairs.
WebRTC endpoints MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], Section 5.1.2, with clarifications in [RFC7983]. All application-layer protocol payloads over this DTLS connection are SCTP packets.
[RFC7983]では、DTLS-SRTP仕様[RFC5764]、セクション5.1.2で説明されているように、WebRTCエンドポイントは、同じポートペアの上のDTLSとRTPの多重化をサポートしている必要があります。このDTLS接続に対するすべてのアプリケーション層プロトコルペイロードはSCTPパケットです。
Protocol identification MUST be supplied as part of the DTLS handshake, as specified in [RFC8833].
[RFC8833]で指定されているように、プロトコル識別書をDTLSハンドシェイクの一部として指定する必要があります。
In the WebRTC prioritization model, the application tells the WebRTC endpoint about the priority of media and data that is controlled from the API.
WEBRTC優先順位付けモデルでは、アプリケーションは、APIから制御されるメディアの優先順位に関するWEBRTCエンドポイントを指示します。
In this context, a "flow" is used for the units that are given a specific priority through the WebRTC API.
これに関連して、WEBRTC APIを介して特定の優先順位が与えられるユニットに「フロー」が使用されます。
For media, a "media flow", which can be an "audio flow" or a "video flow", is what [RFC7656] calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams". This specification does not describe prioritization between the RTP streams that come from a single media source.
メディアの場合は、「オーディオフロー」または「ビデオフロー」になる可能性がある「メディアフロー」が、[RFC7656]が「メディアソース」と呼び、その結果、「ソースRTPストリーム」と1つ以上のものがあります。冗長RTPストリーム」この仕様は、単一のメディアソースからのRTPストリーム間の優先順位付けを説明しません。
All media flows in WebRTC are assumed to be interactive, as defined in [RFC4594]; there is no browser API support for indicating whether media is interactive or noninteractive.
[RFC4594]で定義されているように、WebRTCのすべてのメディアフローはインタラクティブであると見なされます。メディアがインタラクティブまたは非対話型かどうかを示すためのブラウザAPIサポートはありません。
A "data flow" is the outgoing data on a single WebRTC data channel.
「データフロー」は、単一のWEBRTCデータチャネル上の発信データです。
The priority associated with a media flow or data flow is classified as "very-low", "low", "medium", or "high". There are only four priority levels in the API.
メディアフローまたはデータフローに関連する優先順位は、「非常に低い」、「低」、「中」、または「高」に分類されます。APIには4つの優先順位レベルしかありません。
The priority settings affect two pieces of behavior: packet send sequence decisions and packet markings. Each is described in its own section below.
優先度設定は2つの動作に影響します。パケット送信シーケンスの決定とパケットマーキング。それぞれ以下の自身のセクションで説明します。
Local prioritization is applied at the local node, before the packet is sent. This means that the prioritization has full access to the data about the individual packets and can choose differing treatment based on the stream a packet belongs to.
パケットが送信される前に、ローカル優先順位付けがローカルノードで適用されます。これは、優先順位付けが個々のパケットに関するデータへのフルアクセスが完全にアクセスし、パケットが属するストリームに基づいて異なる処理を選択することができることを意味する。
When a WebRTC endpoint has packets to send on multiple streams that are congestion controlled under the same congestion control regime, the WebRTC endpoint SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below.
WebRTCエンドポイントが同じ輻輳制御レジームの下で制御された複数のストリームで送信するパケットを持つ場合、WebRTCエンドポイントは、各レベルの優先順位の各ストリームが送信の約2倍になるようにデータを発信する必要があります。下記のレベルの容量（ペイロードバイトで測定）。
Thus, when congestion occurs, a high-priority flow will have the ability to send 8 times as much data as a very-low-priority flow if both have data to send. This prioritization is independent of the media type. The details of which packet to send first are implementation defined.
したがって、輻輳が発生した場合、両方が送信するデータがある場合、優先順位の高いフローには非常に低い優先順位のフローと同じくらい多くのデータを送信する機能があります。この優先順位付けはメディアタイプとは無関係です。最初に送信するパケットが実装定義されているかの詳細。
For example, if there is a high-priority audio flow sending 100-byte packets and a low-priority video flow sending 1000-byte packets, and outgoing capacity exists for sending > 5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions.
たとえば、100バイトのパケットを送信し、1000バイトのパケットを送信する低優先順位のビデオフローがある場合は、> 5000ペイロードバイトを送信するための発信容量が存在しますが、4000バイトを送信するのが適切でしょう（1回の送信決定の結果として、ビデオのオーディオ40パケットとビデオの1000バイト（1パケット）。
Conversely, if the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes.
逆に、オーディオフローが低優先度とマークされている場合、ビデオフローが優先順位の高いマークされている場合、スケジューラは2ビデオパケット（2000バイト）と5オーディオパケット（500バイト）を送信することを決定します。。
If there are two high-priority audio flows, each will be able to send 4000 bytes in the same period where a low-priority video flow is able to send 1000 bytes.
優先度の高いオーディオフローが2つある場合は、低優先順位のビデオフローが1000バイトを送信できるのと同じ期間に4000バイトを送信できます。
Two example implementation strategies are:
実装戦略の2つの例は次のとおりです。
* When the available bandwidth is known from the congestion control algorithm, configure each codec and each data channel with a target send rate that is appropriate to its share of the available bandwidth.
* 利用可能な帯域幅が輻輳制御アルゴリズムから知られている場合は、利用可能な帯域幅のシェアに適したターゲット送信レートで各コーデックと各データチャネルを構成します。
* When congestion control indicates that a specified number of packets can be sent, send packets that are available to send using a weighted round-robin scheme across the connections.
* 輻輳制御が指定された数のパケットを送信できることを示す場合は、接続を介して重み付けされたラウンド - Robinスキームを使用して送信できるパケットを送信します。
Any combination of these, or other schemes that have the same effect, is valid, as long as the distribution of transmission capacity is approximately correct.
伝送容量の分布がほぼ正しい限り、これらの任意の組み合わせ、または同じ効果を有する他の方式が有効である。
For media, it is usually inappropriate to use deep queues for sending; it is more useful to, for instance, skip intermediate frames that have no dependencies on them in order to achieve a lower bitrate. For reliable data, queues are useful.
メディアの場合、送信に深いキューを使用するのは通常不適切です。例えば、より低いビットレートを達成するためにそれらに依存関係を持たない中間フレームをスキップすることはより有用である。信頼できるデータの場合、キューは有用です。
Note that this specification doesn't dictate when disparate streams are to be "congestion controlled under the same congestion control regime". The issue of coupling congestion controllers is explored further in [RFC8699].
この仕様は、異種ストリームが「同じ輻輳制御体制の下で輻輳制御」になるときに決定されません。カップリング輻輳コントローラの問題は、[RFC8699]でさらに検討されています。
When the packet is sent, the network will make decisions about queueing and/or discarding the packet that can affect the quality of the communication. The sender can attempt to set the DSCP field of the packet to influence these decisions.
パケットが送信されると、ネットワークは通信の質に影響を与える可能性があるパケットをキューイングおよび/または破棄することに関する決定を下すことになる。送信者は、これらの決定に影響を与えるためにパケットのDSCPフィールドを設定しようとする可能性があります。
Implementations SHOULD attempt to set QoS on the packets sent, according to the guidelines in [RFC8837]. It is appropriate to depart from this recommendation when running on platforms where QoS marking is not implemented.
実装は、[RFC8837]のガイドラインに従って、送信されたパケットにQoSを設定しようとするはずです。QoSマーキングが実装されていないプラットフォーム上で実行するときは、この推奨から逸脱することが適切です。
The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behavior such as priority inversion or blocking of packets with certain DSCP markings. Some examples of such behaviors are described in [ANRW16]. The detection of these conditions is implementation dependent.
実装は、特定のDSCPマーキングを持つパケットの優先順位の反転やブロックなどの予期しない動作の症状を検出すると、DSCPマーキングの使用をオフにすることができます。そのような行動のいくつかの例は[ANRW16]に記載されている。これらの条件の検出は実装依存です。
A particularly hard problem is when one media transport uses multiple DSCPs, where one may be blocked and another may be allowed. This is allowed even within a single media flow for video in [RFC8837]. Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCPs that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent. This switch will, of course, invalidate any congestion information gathered up to that point.
特にハードの問題は、1つのメディアトランスポートが複数のDSCPを使用し、そこでブロックされ、別のものが許可され得る場合である。これは、[RFC8837]のビデオの単一のメディアフロー内でも許可されています。このシナリオを診断する必要があります。1つの可能な実装は、初期のICEプローブをDSCP 0で送信し、候補ペアが選択されたら使用することを意図したすべてのDSCPにICEプローブを送信することです。1つ以上のDSCPマークされたプローブが失敗した場合、送信側はメディアタイプをDSCP 0を使用して切り替えます。これは、最初のメディアトラフィックと同時に実行できます。失敗すると、初期データは再送が必要になる場合があります。このスイッチは、もちろん、その時点まで収集された輻輳情報を無効にします。
Failures can also start happening during the lifetime of the call; this case is expected to be rarer and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart.
呼び出しの有効期間中に失敗が発生し始めることができます。このケースはRARERであると予想され、輸送失敗のための通常のメカニズムによって処理することができ、それはICEの再始動を含み得る。
Note that when a DSCP causes nondelivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCPs, don't need to change.
DSCPが非配信を引き起こすとき、単一のメディアフローのすべてのトラフィックが輻輳制御の目的で同じキューにある必要があるため、メディアフロー全体をDSCP 0に切り替える必要があります。異なるDSCPを使用して、同じ輸送上の他の流れは変更する必要はありません。
All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP. The code point used SHOULD be that recommended by [RFC8837] for the highest-priority data channel carried. Note that this means that all data packets, no matter what their relative priority is, will be treated the same by the network.
データチャネルをサポートするSCTPアソシエーションからデータを運ぶすべてのパケットは、単一のDSCPを使用する必要があります。使用されるコードポイントは、優先順位が最も高いデータチャネルでは、[RFC8837]で推奨される必要があります。これは、それらの相対的な優先順位が何であっても、すべてのデータパケットがネットワークによって同じように処理されることに注意してください。
All packets on one TCP connection, no matter what it carries, MUST use a single DSCP.
1つのTCP接続のすべてのパケットは、それがどのようなものであっても、単一のDSCPを使用する必要があります。
More advice on the use of DSCPs with RTP, as well as the relationship between DSCP and congestion control, is given in [RFC7657].
RTPを使用したDSCPの使用、およびDSCPと輻輳制御の関係についてのさらなるアドバイスは、[RFC7657]に記載されています。
There exist a number of schemes for achieving quality of service that do not depend solely on DSCPs. Some of these schemes depend on classifying the traffic into flows based on 5-tuple (source address, source port, protocol, destination address, destination port) or 6-tuple (5-tuple + DSCP). Under differing conditions, it may therefore make sense for a sending application to choose any of the following configurations:
DSCPにのみ依存しないサービス品質を達成するためのいくつかのスキームがあります。これらのスキームの一部は、5タプル（送信元アドレス、送信元ポート、プロトコル、宛先アドレス、宛先アドレス、宛先ポート）、または6タプル（5タプルDSCP）に基づいてトラフィックをフローに分類することに依存します。したがって、異なる条件下では、送信側アプリケーションが次の構成のいずれかを選択することを理解する可能性があります。
* Each media stream carried on its own 5-tuple
* 各メディアストリームはそれ自身の5タプルで運ばれました
* Media streams grouped by media type into 5-tuples (such as carrying all audio on one 5-tuple)
* メディアタイプによってグループ化されたメディアストリーム（1つの5タプルのすべてのオーディオを持ち運ぶなど）
* All media sent over a single 5-tuple, with or without differentiation into 6-tuples based on DSCPs
* DSCPSに基づいて6つのタプルへの差別化の有無にかかわらず、すべてのメディアが1つの5タプルを介して送信されます。
In each of the configurations mentioned, data channels may be carried in their own 5-tuple or multiplexed together with one of the media flows.
言及された各構成において、データチャネルはそれら自身の5タプルで運ばれてもよく、または1つのメディアフローと共に多重化されてもよい。
More complex configurations, such as sending a high-priority video stream on one 5-tuple and sending all other video streams multiplexed together over another 5-tuple, can also be envisioned. More information on mapping media flows to 5-tuples can be found in [RFC8834].
1つの5タプル上の高優先順位の高いビデオストリームを送信し、他の5タプルを介して多重化された他のすべてのビデオストリームを送信するなど、より複雑な構成も想定できます。メディアフローのマッピングに関する詳細については、[RFC8834]にあります。
A sending implementation MUST be able to support the following configurations:
送信実装は、次の設定をサポートできなければなりません。
* Multiplex all media and data on a single 5-tuple (fully bundled)
* すべてのメディアとデータを単一の5タプル（完全にバンドル）に多重化する
* Send each media stream on its own 5-tuple and data on its own 5-tuple (fully unbundled)
* 各メディアストリームを独自の5タプルで送信する（完全にバンドルされていない）
The sending implementation MAY choose to support other configurations, such as bundling each media type (audio, video, or data) into its own 5-tuple (bundling by media type).
送信の実装は、各メディアタイプ（オーディオ、ビデオ、またはデータ）をバンドリングするなど、他の構成をサポートすることを選択できます（Media Typeによるバンドリング）。
Sending data channel data over multiple 5-tuples is not supported.
複数の5タプルを介したデータチャネルデータの送信はサポートされていません。
A receiving implementation MUST be able to receive media and data in all these configurations.
受信実装は、これらすべての構成でメディアとデータを受信できなければなりません。
This document has no IANA actions.
この文書にはIANAの行動がありません。
WebRTC security considerations are enumerated in [RFC8826].
WebRTCセキュリティ上の考慮事項は[RFC8826]で列挙されています。
Security considerations pertaining to the use of DSCP are enumerated in [RFC8837].
DSCPの使用に関するセキュリティ上の考慮事項は[RFC8837]で列挙されています。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[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>。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <https://www.rfc-editor.org/info/rfc4571>.
[RFC4571] Lazzaro、J.、「リアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）およびRFC 4571、RFC 4571、DOI 10.17487 / RFC4571、2006年7月、<https：// www.rfc-editor.org / info / rfc4571>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<https：//www.rfc-editor.org/ info / rfc4594>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R.およびS.Krishnan、「IPv6のステートレスアドレス自動設定のためのプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：///www.rfc-編集者.ORG / INFO / RFC4941>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P.、およびD. Wing、「Stun（Stun）のセッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：//www.rfc-editor.org/info/rfc5389>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] MCGREW、D.およびE. RESCORLA、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<HTTPS）：//www.rfc-editor.org/info/rfc5764>。
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010, <https://www.rfc-editor.org/info/rfc6062>.
[RFC6062] PerreAll、S.、ED。J.Rosenberg、「TCP割り当てのためのNAT（TURN）拡張（TCP割り当て（TCP割り当てのためのターン（ターン）の周りのリレーを使用して、RFC 6062、DOI 10.17487 / RFC6062、2010年11月、<https：//www.rfc-editor.org/info/rfc6062>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] RESCORLA、E.およびN. MODADUGU、「データグラムトランスポートレイヤセキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC6544] Rosenberg、J.、Keranen、A.、Lowekamp、BB、およびAB Roach、「インタラクティブ接続確立（ICP）」、RFC 6544、DOI 10.17487 / RFC6544、2012年3月、<HTTPS：// WWW.rfc-editor.org / info / rfc6544>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、ED。、Draves、R.、Matsumoto、A.、T. Chown、「インターネットプロトコルバージョン6のデフォルトアドレス選択（IPv6）」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月<https：//www.rfc-editor.org/info/rfc6724>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235] Fielding、R.、Ed。J.Reschke、Ed。、「Hypertext Transfer Protocol（HTTP / 1.1）：認証」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<https：//www.rfc-editor.org/info/rfc7235>。
[RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP Header Field", RFC 7639, DOI 10.17487/RFC7639, August 2015, <https://www.rfc-editor.org/info/rfc7639>.
[RFC7639] Hutton、A.、Uberti、J.、およびM. Thomson、「ALPN HTTPヘッダーフィールド」、RFC 7639、DOI 10.17487 / RFC7639、2015年8月、<https：//www.rfc-editor.org/情報/ RFC7639>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G.、B. Burman、ED。、「リアルタイムトランスポートプロトコル（RTP）ソースのためのセマンティクスおよびメカニズムの分類」、RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<https：//www.rfc-editor.org/info/rfc7656>。
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.
[RFC7983] Petit-Huguenin、M.およびG.Salgueiro、データグラムトランスポート層セキュリティ（DTLS）拡張（DTLS）拡張（DTLS）拡張（DTLS））、RFC 7983、DOI 10.17487 / RFC7983、2016年9月、<https://www.rfc-editor.org/info/rfc7983>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C、V.Singh、 "マルチメディア輻輳制御：ユニキャストRTPセッションのためのサーキットブレーカー"、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<https：//www.rfc-editor.org/info/ RFC8083>。
[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>。
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.
[RFC8260] Stewart、R.、Tuexen、M.、Loreto、S.、およびR.SegGelmann、「ストリーム制御伝送プロトコルのためのストリームスケジューラおよびユーザメッセージインターリーブ」、RFC 8260、DOI 10.17487 / RFC8260、2017年11月、<https://www.rfc-editor.org/info/rfc8260>。
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, <https://www.rfc-editor.org/info/rfc8261>.
[RFC8261] Tuexen、M.、Stewart、R.、Jesup、R.、およびS. Loreto、SCTPパケットの「データグラムトランスポート層セキュリティ（DTLS）カプセル化」、RFC 8261、DOI 10.17487 / RFC8261、2017年11月、<HTTPS：//www.rfc-editor.org/info/rfc8261>。
[RFC8421] Martinsen, P., Reddy, T., and P. Patil, "Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)", BCP 217, RFC 8421, DOI 10.17487/RFC8421, July 2018, <https://www.rfc-editor.org/info/rfc8421>.
[RFC8421] Martinsen、P.、Reddy、T。、およびP.Atil、「マルチホームおよびIPv4 / IPv6デュアルスタックインタラクティブ接続確立（ICE）」、BCP 217、RFC 8421、DOI 10.17487 / RFC8421、2018年7月<https：//www.rfc-editor.org/info/rfc8421>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020, <https://www.rfc-editor.org/info/rfc8656>.
[RFC8656] Reddy、T.、Ed。、Johnston、A.、ED。、Matthews、P.、およびJ.Rosenberg、「NAT周辺のリレーを使用したトラバーサル（ターン）：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張"、RFC 8656、DOI 10.17487 / RFC8656、2020年2月、<https：//www.rfc-editor.org/info/rfc8656>。
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.
[RFC8825] ALVESTRAND、H。、「概要：ブラウザベースのアプリケーション用リアルタイムプロトコル」、RFC 8825、DOI 10.17487 / RFC8825、2021年1月、<https：//www.rfc-editor.org/info/rfc8825>。
[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>。
[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>。
[RFC8833] Thomson, M., "Application-Layer Protocol Negotiation (ALPN) for WebRTC", RFC 8833, DOI 10.17487/RFC8833, January 2021, <https://www.rfc-editor.org/info/rfc8833>.
[RFC8833] Thomson、M.、「WebRTCのアプリケーション層プロトコルネゴシエーション（ALPN）、RFC 8833、DOI 10.17487 / RFC8833、2021年1月、<https：//www.rfc-editor.org/info/rfc8833>。
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8834] Perkins、C、Westerlund、M.、J. OTT、「WebRTCのメディアトランスポートとRTPの使用」、RFC 8834、DOI 10.17487 / RFC8834、<https：///www.rfc-編集者.ORG / INFO / RFC8834>。
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control Requirements for Interactive Real-Time Media", RFC 8836, DOI 10.17487/RFC8836, January 2021, <https://www.rfc-editor.org/info/rfc8836>.
[RFC8836] Jesup、R.およびZ.Sarker、Ed。、「インタラクティブリアルタイムメディアの輻輳制御要件」、RFC 8836、DOI 10.17487 / RFC8836、2021年1月、<https://www.rfc-editor.org/ info / rfc8836>。
[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January 2021, <https://www.rfc-editor.org/info/rfc8837>.
[RFC8837] Jones、P.、Ashesikan、S.、Jennings、C、およびD. Druta、「微分サービスコードポイント（DSCP）パケットマーキング」、RFC 8837、DOI 10.17487 / RFC8837、2021年1月、<https://www.rfc-editor.org/info/rfc8837>。
[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>。
[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, <https://www.rfc-editor.org/info/rfc8842>.
[RFC8842] Holmberg、C、R. Shpount、「セッション記述プロトコル（SDP）データグラムトランスポート層セキュリティ（DTLS）およびトランスポート層セキュリティ（TLS）およびトランスポート層セキュリティ（TLS）」、RFC 8842、DOI 10.17487 / RFC8842、2021年1月<https：//www.rfc-editor.org/info/rfc8842>。
[ANRW16] Barik, R., Welzl, M., and A. Elmokashfi, "How to say that you're special: Can we use bits in the IPv4 header?", ANRW '16: Proceedings of the 2016 Applied Networking Research Workshop, pages 68-70, DOI 10.1145/2959424.2959442, July 2016, <https://irtf.org/anrw/2016/anrw16-final17.pdf>.
[ANRW16] Barik、R.、Welzl、M.、A. Elmokashfi、「あなたが特別であると言う方法：IPv4ヘッダーのビットを使うことができますか？」、ANRW '16：2016年適用ネットワーク研究の手続き2016年7月、<https://irtf.org/anrw/2016/anrw16-final17.pdf>。
[RETURN] Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC", Work in Progress, Internet-Draft, draft-ietf-rtcweb-return-02, 27 March 2017, <https://tools.ietf.org/html/draft-ietf-rtcweb-return-02>.
[Return] Schwartz、B.およびJ.Uberti、「WebRTCの接続とプライバシーのための再帰的なカプセル化されたターン（戻り）、進行中の作業、インターネットドラフト、ドラフト-IETF-RTCWeb-Return-02,27,27,20,27,200,27https://tools.ietf.org/html/draft-ietf-rtcweb-return-02>。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/RFC3484, February 2003, <https://www.rfc-editor.org/info/rfc3484>.
[RFC3484] Draves、R.、 "インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択"、RFC 3484、DOI 10.17487 / RFC3484、2003年2月、<https://www.rfc-editor.org/info/rfc3484>。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, <https://www.rfc-editor.org/info/rfc5014>.
[RFC5014] Nordmark、E.、Chakrabarti、S.、J.Laganier、「Source Address Selection for Source Address Selection for Source Address Selection for Source Socket API」、RFC 5014、DOI 10.17487 / RFC5014、2007年9月、<https：///www.rfc-editor。ORG / INFO / RFC5014>。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <https://www.rfc-editor.org/info/rfc5128>.
[RFC5128] SRISURESH、P.、FORD、B.およびD.Kegel、「ネットワークアドレス翻訳者全体のピアツーピア（P2P）通信（NATS）」、RFC 5128、DOI 10.17487 / RFC5128、2008年3月<https://www.rfc-editor.org/info/rfc5128>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657]黒、D.、ED。P. Jones、「差別化サービス（DiffServ）およびリアルタイム通信」、RFC 7657、DOI 10.17487 / RFC 7657、2015年11月、<https：//www.rfc-editor.org/info/rfc7657>。
[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays around NAT (TURN) Server Auto Discovery", RFC 8155, DOI 10.17487/RFC8155, April 2017, <https://www.rfc-editor.org/info/rfc8155>.
[RFC8155] Patil、P.、Reddy、T.、D.ウィング、「NAT（ターン）サーバー自動検出」、RFC 8155、DOI 10.17487 / RFC8155、2017年4月、<HTTPS：// WWW。rfc-editor.org/info/rfc8155>。
[RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020, <https://www.rfc-editor.org/info/rfc8699>.
[RFC8699]イスラム教、S、WELZL、M.およびS.Gjessing、「RTPメディアの結合輻輳制御」、RFC 8699、DOI 10.17487 / RFC8699、2020年1月、<https：//www.rfc-editor.org/ info / rfc8699>。
Acknowledgements
謝辞
This document is based on earlier draft versions embedded in [RFC8825], which were the result of contributions from many RTCWEB Working Group members.
このドキュメントは、[RFC8825]に埋め込まれている以前のドラフトバージョンに基づいており、これは多くのRTCWebワーキンググループメンバーからの貢献結果でした。
Special thanks for reviews of earlier draft versions of this document go to Eduardo Gueiros, Magnus Westerlund, Markus Isomaki, and Dan Wing; the contributions from Andrew Hutton also deserve special mention.
以前のドラフトバージョンこの文書のバージョンの詳細については、Eduardo Gueiros、Magnus Westerlund、Markus Isomaki、Dan Wing wing;Andrew Huttonからの貢献も特別な言及に値する。
Author's Address
著者の住所
Harald Alvestrand Google
Harald alvestrand Google
Email: harald@alvestrand.no