[要約] RFC 8825は、ブラウザベースのアプリケーション向けのリアルタイムプロトコルに関する概要を提供します。このRFCの目的は、ブラウザベースのアプリケーションでのリアルタイム通信をサポートするためのプロトコルを定義することです。
Internet Engineering Task Force (IETF) H. Alvestrand
Request for Comments: 8825 Google
Category: Standards Track January 2021
ISSN: 2070-1721
Overview: Real-Time Protocols for Browser-Based Applications
概要：ブラウザベースのアプリケーション用のリアルタイムプロトコル
Abstract
概要
This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
このドキュメントでは、ブラウザに展開できるリアルタイムアプリケーションでの使用を目的としたプロトコルスイートの概要とコンテキスト、つまり「Webでのリアルタイム通信」について説明します。
It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track.
これは、（1）この目標を達成するために必要なすべての部分が見つけられ、（2）インターネットプロトコルスイートに属する部分が完全に指定され、適切な出版物にあることを確認するための開始点および調整点として機能することを目的としています。追跡。
This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC).
このドキュメントは適用性に関する声明です。プロトコル自体は指定していませんが、Web Real-Time Communication（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コミュニティのコンセンサスを表しています。パブリックレビューを受け、Internet Engineering Steering Group（IESG）による公開が承認されました。インターネット標準の詳細については、RFC7841のセクション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/rfc8825.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8825で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2021 IETFTrustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Principles and Terminology
2.1. Goals of This Document
2.2. Relationship between API and Protocol
2.3. On Interoperability and Innovation
2.4. Terminology
3. Architecture and Functionality Groups
4. Data Transport
5. Data Framing and Securing
6. Data Formats
7. Connection Management
8. Presentation and Control
9. Local System Support Functions
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Author's Address
The Internet was, from very early in its lifetime, considered a possible vehicle for the deployment of real-time, interactive applications -- with the most easily imaginable being audio conversations (aka "Internet telephony") and video conferencing.
インターネットは、その生涯の非常に早い段階から、リアルタイムのインタラクティブなアプリケーションを展開するための可能な手段と考えられていました。最も簡単に想像できるのは、音声会話（別名「インターネットテレフォニー」）とビデオ会議です。
The first attempts to build such applications were dependent on special networks, special hardware, and custom-built software, often at very high prices or of low quality, placing great demands on the infrastructure.
このようなアプリケーションを構築する最初の試みは、特別なネットワーク、特別なハードウェア、およびカスタムビルドのソフトウェアに依存しており、多くの場合、非常に高価格または低品質であり、インフラストラクチャに大きな要求を課していました。
As the available bandwidth has increased, and as processors and other hardware have become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware.
利用可能な帯域幅が増加し、プロセッサやその他のハードウェアがこれまでになく高速化するにつれて、参加への障壁が減少し、一般的に利用可能なコンピューティングハードウェアで満足のいくエクスペリエンスを提供できるようになりました。
Still, there are a number of barriers to the ability to communicate universally -- one of these is that there is, as of yet, no single set of communication protocols that all agree should be made available for communication; another is the sheer lack of universal identification systems (such as is served by telephone numbers or email addresses in other communications systems).
それでも、普遍的に通信する能力には多くの障壁があります。その1つは、現時点では、すべてが同意する単一の通信プロトコルのセットを通信に使用できるようにする必要がないことです。もう1つは、ユニバーサルIDシステム（他の通信システムの電話番号や電子メールアドレスによって提供されるものなど）がまったくないことです。
Development of "The Universal Solution" has, however, proved hard.
しかし、「ユニバーサルソリューション」の開発は困難であることが証明されています。
The last few years have also seen a new platform rise for deployment of services: the browser-embedded application, or "web application". It turns out that as long as the browser platform has the necessary interfaces, it is possible to deliver almost any kind of service on it.
ここ数年、サービスを展開するための新しいプラットフォーム、つまりブラウザ組み込みアプリケーション、つまり「Webアプリケーション」も登場しています。ブラウザプラットフォームに必要なインターフェイスがある限り、ほぼすべての種類のサービスを提供できることがわかりました。
Traditionally, these interfaces have been delivered by plugins, which had to be downloaded and installed separately from the browser; in the development of HTML5 [HTML5], application developers see much promise in the possibility of making those interfaces available in a standardized way within the browser.
従来、これらのインターフェースはプラグインによって提供されていました。プラグインはブラウザーとは別にダウンロードしてインストールする必要がありました。HTML5 [HTML5]の開発において、アプリケーション開発者は、これらのインターフェースをブラウザー内で標準化された方法で利用できるようにする可能性に大きな期待を寄せています。
This memo describes a set of building blocks that (1) can be made accessible and controllable through a JavaScript API in a browser and (2) together form a sufficient set of functions to allow the use of interactive audio and video in applications that communicate directly between browsers across the Internet. The resulting protocol suite is intended to enable all the applications that are described as required scenarios in the WebRTC "use cases" document [RFC7478].
このメモでは、（1）ブラウザのJavaScript APIを介してアクセスおよび制御できるようにし、（2）直接通信するアプリケーションでインタラクティブなオーディオとビデオを使用できるようにするために、十分な機能のセットを形成する一連のビルディングブロックについて説明します。インターネット上のブラウザ間。結果として得られるプロトコルスイートは、WebRTCの「ユースケース」ドキュメント[RFC7478]で必要なシナリオとして説明されているすべてのアプリケーションを有効にすることを目的としています。
Other efforts -- for instance, the W3C Web Real-Time Communications, Web Applications Security, and Devices and Sensors Working Groups -- focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions. This memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network.
その他の取り組み（たとえば、W3C Webリアルタイム通信、Webアプリケーションセキュリティ、デバイスとセンサーのワーキンググループ）は、HTML5の取り組みの範囲内または並行して、これらの機能で標準化されたAPIとインターフェイスを利用できるようにすることに重点を置いています。このメモは、ネットワークを介した相互作用を指定するために必要なプロトコルとサブプロトコルの指定に焦点を当てています。
Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real-time media on the network and may result in a shift in the kinds of devices used to create and consume such media. In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies using application-specific protocols. Operational techniques that involve inserting network elements to interpret the Session Description Protocol (SDP) -- through either (1) the endpoint asking the network for a SIP server [RFC3361] or (2) the transparent insertion of SIP Application Layer Gateways (ALGs) -- will not work with such signaling. In the case of networks using cooperative endpoints, the approaches defined in [RFC8155] may serve as a suitable replacement for [RFC3361]. The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones. This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS. Applying the markings described in [RFC8837] may be appropriate replacements for such techniques.
オペレーターは、WebRTCの展開により、ネットワーク上のリアルタイムメディアのシグナリングの性質が変化し、そのようなメディアの作成と消費に使用されるデバイスの種類が変化する可能性があることに注意する必要があります。シグナリングの場合、WebRTCセッションのセットアップは通常、アプリケーション固有のプロトコルを使用して、TLSで保護されたWebテクノロジーを介して行われます。セッション記述プロトコル（SDP）を解釈するためにネットワーク要素を挿入することを含む運用技術-（1）ネットワークにSIPサーバー[RFC3361]を要求するエンドポイント、または（2）SIPアプリケーション層ゲートウェイ（ALG）の透過的な挿入-このようなシグナリングでは機能しません。協調エンドポイントを使用するネットワークの場合、[RFC8155]で定義されているアプローチは、[RFC3361]の適切な代替として役立つ可能性があります。ブラウザベースの通信の増加は、SIPデスクフォンなどの専用のリアルタイム通信ハードウェアからのシフトにもつながる可能性があります。これにより、トラフィックフィルタリングやQoSの適用などの目的で、専用のリアルタイムデバイスを独自のネットワークセグメント、アドレス範囲、またはVLANに配置する運用手法の有効性が低下します。 [RFC8837]に記載されているマーキングを適用することは、そのような技術の適切な代替となる可能性があります。
While this document formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of Interactive Connectivity Establishment (ICE) that is described in [RFC5245] and use a pre-standard version of the Trickle ICE mechanism described in [RFC8838]. The "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
このドキュメントは正式には[RFC8445]に依存していますが、発行時点では、WebRTC実装の大部分は、[RFC5245]で説明されているバージョンのInteractive Connectivity Establishment（ICE）をサポートし、TrickleICEの先行標準バージョンを使用しています。[RFC8838]で説明されているメカニズム。[RFC8445]で定義されている「ice2」属性を使用して、リモートエンドポイントで使用されているバージョンを検出し、古い仕様から新しい仕様へのスムーズな移行を提供できます。
This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.
このメモでは、「WebRTC」という用語（使用されているケースに注意）を使用して、IETFとW3Cの両方の取り組みからなる全体的な取り組みを指します。
The goal of the WebRTC protocol specification is to specify a set of protocols that, if all are implemented, will allow an implementation to communicate with another implementation using audio, video, and data sent along the most direct possible path between the participants.
WebRTCプロトコル仕様の目標は、すべてが実装されている場合、参加者間の最も直接的なパスに沿って送信されるオーディオ、ビデオ、およびデータを使用して、実装が別の実装と通信できるようにするプロトコルのセットを指定することです。
This document is intended to serve as the roadmap to the WebRTC specifications. It defines terms used by other parts of the WebRTC protocol specifications, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite.
このドキュメントは、WebRTC仕様へのロードマップとして機能することを目的としています。これは、WebRTCプロトコル仕様の他の部分で使用される用語を定義し、WebRTCコンテキストでさらに詳しく説明する必要のない他の仕様への参照をリストし、WebRTCスイートの一部を形成する他のドキュメントへのポインターを提供します。
By reading this document and the documents it refers to, it should be possible to have all information needed to implement a WebRTC-compatible implementation.
このドキュメントとそれが参照するドキュメントを読むことで、WebRTC互換の実装を実装するために必要なすべての情報を入手できるはずです。
The total WebRTC effort consists of two major parts, each consisting of multiple documents:
WebRTCの全体的な取り組みは、2つの主要な部分で構成され、それぞれが複数のドキュメントで構成されています。
* A protocol specification, done in the IETF
* IETFで行われるプロトコル仕様
* A JavaScript API specification, defined in a series of W3C documents [W3C.WD-webrtc] [W3C.WD-mediacapture-streams]
* 一連のW3Cドキュメントで定義されているJavaScriptAPI仕様[W3C.WD-webrtc] [W3C.WD-mediacapture-streams]
Together, these two specifications aim to provide an environment where JavaScript embedded in any page, when suitably authorized by its user, is able to set up communication using audio, video, and auxiliary data, as long as the browser supports these specifications. The browser environment does not constrain the types of application in which this functionality can be used.
これら2つの仕様は、ブラウザがこれらの仕様をサポートしている限り、任意のページに埋め込まれたJavaScriptが、ユーザーによって適切に承認された場合に、オーディオ、ビデオ、および補助データを使用して通信をセットアップできる環境を提供することを目的としています。ブラウザ環境は、この機能を使用できるアプリケーションの種類を制限しません。
The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for interoperation to know whether the entity one is communicating with is a browser or another device implementing the protocol specification.
プロトコル仕様は、すべての実装がこのAPIを実装することを前提とはしていません。通信しているエンティティがブラウザであるか、プロトコル仕様を実装している別のデバイスであるかを相互運用で知る必要はありません。
The goal of cooperation between the protocol specification and the API specification is that for all options and features of the protocol specification, it should be clear which API calls to make to exercise that option or feature; similarly, for any sequence of API calls, it should be clear which protocol options and features will be invoked. Both are subject to constraints of the implementation, of course.
プロトコル仕様とAPI仕様の間の連携の目標は、プロトコル仕様のすべてのオプションと機能について、そのオプションまたは機能を実行するためにどのAPI呼び出しを行うかを明確にすることです。同様に、API呼び出しのシーケンスについては、どのプロトコルオプションと機能が呼び出されるかを明確にする必要があります。もちろん、どちらも実装の制約を受けます。
The following terms are used across the documents specifying the WebRTC suite, with the specific meanings given here. Not all terms are used in this document. Other terms are used per their commonly used meanings.
以下の用語は、WebRTCスイートを指定するドキュメント全体で使用されており、ここに特定の意味があります。このドキュメントでは、すべての用語が使用されているわけではありません。他の用語は、一般的に使用される意味に従って使用されます。
Agent: Undefined term. See "SDP Agent" and "ICE Agent".
エージェント：未定義の用語。「SDPエージェント」および「ICEエージェント」を参照してください。
Application Programming Interface (API): A specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics.
アプリケーションプログラミングインターフェイス（API）：一連の呼び出しとイベントの仕様。通常はプログラミング言語またはWebIDLなどの抽象的な形式仕様に関連付けられており、セマンティクスが定義されています。
Browser: Used synonymously with "interactive user agent" as defined in [HTML5]. See also the "WebRTC Browser" (aka "WebRTC User Agent") definition below.
ブラウザ：[HTML5]で定義されている「インタラクティブユーザーエージェント」と同義で使用されます。以下の「WebRTCブラウザ」（別名「WebRTCユーザーエージェント」）の定義も参照してください。
Data Channel: An abstraction that allows data to be sent between WebRTC endpoints in the form of messages. Two endpoints can have multiple data channels between them.
データチャネル：データをメッセージの形式でWebRTCエンドポイント間で送信できるようにする抽象化。2つのエンドポイントは、それらの間に複数のデータチャネルを持つことができます。
ICE Agent: An implementation of the Interactive Connectivity Establishment (ICE) protocol [RFC8445]. An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance, those that use Jingle [XEP-0166]).
ICEエージェント：Interactive Connectivity Establishment（ICE）プロトコル[RFC8445]の実装。ICEエージェントはSDPエージェントでもありますが、SDPを使用しないICEエージェント（たとえば、Jingle [XEP-0166]を使用するICEエージェント）が存在します。
Interactive: Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, where the total time required for the action/reaction/ observation is on the order of no more than hundreds of milliseconds.
インタラクティブ：複数の当事者間のコミュニケーション。ある当事者からのアクションが別の当事者による反応を引き起こす可能性があり、その反応は、アクション/反応/観察に必要な合計時間がオンになっている最初の当事者によって観察されます。数百ミリ秒以下のオーダー。
Media: Audio and video content. Not to be confused with "transmission media" such as wires.
メディア：オーディオおよびビデオコンテンツ。ワイヤーなどの「伝送媒体」と混同しないでください。
Media Path: The path that media data follows from one WebRTC endpoint to another.
メディアパス：メディアデータが1つのWebRTCエンドポイントから別のエンドポイントにたどるパス。
Protocol: A specification of a set of data units, their representation, and rules for their transmission, with their defined semantics. A protocol is usually thought of as going between systems.
プロトコル：データユニットのセット、それらの表現、およびそれらの送信のルールの仕様と、それらの定義されたセマンティクス。プロトコルは通常、システム間を行き来するものと考えられています。
Real-Time Media: Media where the generation and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). Real-time media can be used to support interactive communication.
リアルタイムメディア：コンテンツの生成と表示が時間的に密接に発生することを目的としたメディア（数百ミリ秒以下のオーダー）。リアルタイムメディアを使用して、インタラクティブなコミュニケーションをサポートできます。
SDP Agent: The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in [RFC3264], Section 3.
SDPエージェント：[RFC3264]のセクション3で定義されている、Session Description Protocol（SDP）オファー/アンサー交換に関連するプロトコル実装。
Signaling: Communication that happens in order to establish, manage, and control media paths and data paths.
シグナリング：メディアパスとデータパスを確立、管理、および制御するために発生する通信。
Signaling Path: The communication channels used between entities participating in signaling to transfer signaling. There may be more entities in the signaling path than in the media path.
シグナリングパス：シグナリングに参加しているエンティティ間で使用され、シグナリングを転送する通信チャネル。メディアパスよりもシグナリングパスに多くのエンティティが存在する場合があります。
WebRTC Browser (also called a "WebRTC User Agent" or "WebRTC UA"): Something that conforms to both the protocol specification and the JavaScript API cited above.
WebRTCブラウザー（「WebRTCユーザーエージェント」または「WebRTCUA」とも呼ばれます）：上記のプロトコル仕様とJavaScriptAPIの両方に準拠するもの。
WebRTC Non-Browser: Something that conforms to the protocol specification but does not claim to implement the JavaScript API. This can also be called a "WebRTC device" or "WebRTC native application".
WebRTC Non-Browser：プロトコル仕様に準拠しているが、JavaScriptAPIの実装を主張していないもの。これは、「WebRTCデバイス」または「WebRTCネイティブアプリケーション」と呼ばれることもあります。
WebRTC Endpoint: Either a WebRTC browser or a WebRTC non-browser. It conforms to the protocol specification.
WebRTCエンドポイント：WebRTCブラウザーまたはWebRTC非ブラウザーのいずれか。プロトコル仕様に準拠しています。
WebRTC-Compatible Endpoint: An endpoint that is able to successfully communicate with a WebRTC endpoint but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached or may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints.
WebRTC互換エンドポイント：WebRTCエンドポイントと正常に通信できるが、WebRTCエンドポイントの一部の要件を満たしていない可能性があるエンドポイント。これにより、ネットワーク内のどこにそのようなエンドポイントを接続できるかが制限されたり、他のエンドポイントに提供されるセキュリティ保証が制限されたりする場合があります。この仕様による制約はありません。言及されている場合は、WebRTCエンドポイントに課せられた要件がWebRTC互換エンドポイントに与える影響に注意する必要があります。
WebRTC Gateway: A WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities.
WebRTCゲートウェイ：非WebRTCエンティティへのメディアトラフィックを仲介するWebRTC互換エンドポイント。
All WebRTC browsers are WebRTC endpoints, so any requirement on a WebRTC endpoint also applies to a WebRTC browser.
すべてのWebRTCブラウザーはWebRTCエンドポイントであるため、WebRTCエンドポイントの要件はすべてWebRTCブラウザーにも適用されます。
A WebRTC non-browser may be capable of hosting applications in a way that is similar to the way in which a browser can host JavaScript applications, typically by offering APIs in other languages. For instance, it may be implemented as a library that offers a C++ API intended to be loaded into applications. In this case, security considerations similar to those for JavaScript may be needed; however, since such APIs are not defined or referenced here, this document cannot give any specific rules for those interfaces.
WebRTC非ブラウザーは、ブラウザーがJavaScriptアプリケーションをホストできるのと同様の方法で、通常は他の言語でAPIを提供することにより、アプリケーションをホストできる場合があります。たとえば、アプリケーションにロードすることを目的としたCAPIを提供するライブラリとして実装できます。この場合、JavaScriptの場合と同様のセキュリティ上の考慮事項が必要になる場合があります。ただし、このようなAPIはここでは定義または参照されていないため、このドキュメントではこれらのインターフェイスに特定のルールを与えることはできません。
WebRTC gateways are described in a separate document [WebRTC-Gateways].
WebRTCゲートウェイについては、別のドキュメント[WebRTC-Gateways]で説明されています。
The "Mission statement for the IETF" [RFC3935] states that "The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users."
「IETFの使命声明」[RFC3935]は、「インターネットに対する標準の利点は相互運用性にあります。標準を実装する複数の製品が連携して、インターネットのユーザーに価値のある機能を提供できることです」と述べています。
Communication on the Internet frequently occurs in two phases:
インターネット上の通信は、次の2つのフェーズで頻繁に発生します。
* Two parties communicate, through some mechanism, what functionality they are both able to support.
* 2つのパーティは、何らかのメカニズムを介して、両方がサポートできる機能を伝達します。
* They use that shared communicative functionality to communicate or, failing to find anything in common, give up on communication.
* 彼らはその共有されたコミュニケーション機能を使用してコミュニケーションをとるか、共通点が見つからない場合はコミュニケーションをあきらめます。
There are often many choices that can be made for communicative functionality; the history of the Internet is rife with the proposal, standardization, implementation, and success or failure of many types of options, in all sorts of protocols.
多くの場合、コミュニケーション機能のために行うことができる多くの選択肢があります。インターネットの歴史は、あらゆる種類のプロトコルにおける多くの種類のオプションの提案、標準化、実装、および成功または失敗に満ちています。
The goal of having a mandatory-to-implement function set is to prevent negotiation failure, not to preempt or prevent negotiation.
実装必須機能を設定する目的は、ネゴシエーションの失敗を防ぐことであり、ネゴシエーションを先取りしたり防止したりすることではありません。
The presence of a mandatory-to-implement function set serves as a strong changer of the marketplace of deployment in that it gives a guarantee that you can communicate successfully as long as (1) you conform to a specification and (2) the other party is willing to accept communication at the base level of that specification.
実装が必須の機能セットの存在は、（1）仕様に準拠し、（2）相手がいる限り、正常に通信できることが保証されるという点で、展開の市場を大きく変える役割を果たします。その仕様の基本レベルでの通信を喜んで受け入れます。
The alternative (that is, not having a mandatory-to-implement function) does not mean that you cannot communicate; it merely means that in order to be part of the communications partnership, you have to implement the standard "and then some". The "and then some" is usually called a profile of some sort; in the version most antithetical to the Internet ethos, that "and then some" consists of having to use a specific vendor's product only.
代替手段（つまり、実装が必須の機能がない）は、通信できないことを意味するものではありません。それは単に、通信パートナーシップの一部となるために、標準を「そしていくつか」実装しなければならないことを意味します。「そしていくつか」は通常、ある種のプロファイルと呼ばれます。インターネットの精神に最も反するバージョンでは、その「そしていくつか」は、特定のベンダーの製品のみを使用する必要があることで構成されています。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように、ここに示すように、すべて大文字で表示される場合にのみ解釈されます。
For browser-based applications, the model for real-time support does not assume that the browser will contain all the functions needed for an application such as a telephone or a video conference. The vision is that the browser will have the functions needed for a web application, working in conjunction with its backend servers, to implement these functions.
ブラウザベースのアプリケーションの場合、リアルタイムサポートのモデルは、ブラウザに電話やビデオ会議などのアプリケーションに必要なすべての機能が含まれていることを前提とはしていません。ビジョンは、ブラウザがWebアプリケーションに必要な機能を備え、バックエンドサーバーと連携してこれらの機能を実装することです。
This means that two vital interfaces need specification: the protocols that browsers use to talk to each other, without any intervening servers; and the APIs that are offered for a JavaScript application to take advantage of the browser's functionality.
これは、2つの重要なインターフェースに仕様が必要であることを意味します。ブラウザーがサーバーを介さずに相互に通信するために使用するプロトコル。また、ブラウザの機能を利用するためにJavaScriptアプリケーションに提供されるAPI。
+------------------------+ On-the-wire
| | Protocols
| Servers |--------->
| |
| |
+------------------------+
^
|
|
| HTTPS/
| WebSockets
|
|
+----------------------------+
| JavaScript/HTML/CSS |
+----------------------------+
Other ^ ^ RTC
APIs | | APIs
+---|-----------------|------+
| | | |
| +---------+|
| | Browser || On-the-wire
| Browser | RTC || Protocols
| | Function|----------->
| | ||
| | ||
| +---------+|
+---------------------|------+
|
V
Native OS Services
Figure 1: Browser Model
図1：ブラウザモデル
Note that HTTPS and WebSockets are also offered to the JavaScript application through browser APIs.
HTTPSとWebSocketは、ブラウザーAPIを介してJavaScriptアプリケーションにも提供されることに注意してください。
As for all protocol and API specifications, there is no restriction that the protocols can only be used to talk to another browser; since they are fully specified, any endpoint that implements the protocols faithfully should be able to interoperate with the application running in the browser.
すべてのプロトコルおよびAPI仕様に関して、プロトコルが別のブラウザーとの通信にのみ使用できるという制限はありません。それらは完全に指定されているため、プロトコルを忠実に実装するエンドポイントは、ブラウザーで実行されているアプリケーションと相互運用できる必要があります。
A commonly imagined model of deployment is depicted in Figure 2. ("JS" stands for JavaScript.)
一般的に想像される展開モデルを図2に示します（「JS」はJavaScriptを表します）。
+-----------+ +-----------+
| Web | | Web |
| | | |
| |------------------| |
| Server | Signaling Path | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Application-defined
/ \ over
/ \ HTTPS/WebSockets
/ Application-defined over \
/ HTTPS/WebSockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
| | | |
| | | |
| Browser |--------------------------------| Browser |
| | Media Path | |
| | | |
+-----------+ +-----------+
Figure 2: Browser RTC Trapezoid
図2：ブラウザRTC台形
In this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify, translate, or manipulate the signals as needed.
この図で注意すべき重要な部分は、メディアパス（「ローパス」）がブラウザー間を直接通過するため、WebRTCプロトコルスイートの仕様に準拠している必要があることです。シグナリングパス（「ハイパス」）は、必要に応じて信号を変更、変換、または操作できるサーバーを経由します。
If the two web servers are operated by different entities, the inter-server signaling mechanism needs to be agreed upon, by either standardization or other means of agreement. Existing protocols (e.g., SIP [RFC3261] or the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server.
2つのWebサーバーが異なるエンティティによって運用されている場合は、標準化またはその他の合意手段によって、サーバー間シグナリングメカニズムについて合意する必要があります。サーバー間では既存のプロトコル（SIP [RFC3261]やExtensibleMessaging and Presence Protocol（XMPP）[RFC6120]など）を使用できますが、ブラウザーとWebサーバー間では標準ベースまたは独自のプロトコルを使用できます。
For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g., SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server. Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g., XMPP over WebSockets or Bidirectional-streams Over Synchronous HTTP (BOSH) [XEP-0124]) or a proprietary signaling mechanism used between the application running in the browser and the web server.
たとえば、両方のオペレーターのサーバーがSIPを実装している場合、SIPは、標準化されたシグナリングメカニズム（SIP over WebSocketsなど）またはブラウザーで実行されているアプリケーションとWeb間で使用される独自のシグナリングメカニズムのいずれかとともに、サーバー間の通信に使用できます。サーバ。同様に、両方のオペレーターのサーバーがXMPPを実装している場合、XMPPは、標準化されたシグナリングメカニズム（たとえば、WebSocketを介したXMPPまたは同期HTTPを介した双方向ストリーム（BOSH）[XEP-0124]）を使用して、XMPPサーバー間の通信に使用できます。ブラウザで実行されているアプリケーションとWebサーバーの間で使用される独自のシグナリングメカニズム。
The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.
クライアント/サーバーおよびサーバー間シグナリングのプロトコルの選択、およびそれらの間の変換の定義は、このドキュメントで説明されているWebRTCプロトコルスイートの範囲外です。
The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as:
ブラウザで必要な機能グループは、次のように、多かれ少なかれボトムアップで指定できます。
Data transport: For example, TCP and UDP, and the means to securely set up connections between entities, as well as the functions for deciding when to send data: congestion management, bandwidth estimation, and so on.
データ転送：たとえば、TCPとUDP、エンティティ間の接続を安全にセットアップする手段、およびデータを送信するタイミングを決定する機能（輻輳管理、帯域幅推定など）。
Data framing: RTP, the Stream Control Transmission Protocol (SCTP), DTLS, and other data formats that serve as containers, and their functions for data confidentiality and integrity.
データフレーミング：RTP、Stream Control Transmission Protocol（SCTP）、DTLS、およびコンテナーとして機能するその他のデータ形式、およびデータの機密性と整合性のためのそれらの機能。
Data formats: Codec specifications, format specifications, and functionality specifications for the data passed between systems. Audio and video codecs, as well as formats for data and document sharing, belong in this category. In order to make use of data formats, a way to describe them (e.g., a session description) is needed.
データ形式：システム間で受け渡されるデータのコーデック仕様、形式仕様、および機能仕様。オーディオとビデオのコーデック、およびデータとドキュメントの共有の形式は、このカテゴリに属します。データ形式を利用するには、それらを説明する方法（セッションの説明など）が必要です。
Connection management: For example, setting up connections, agreeing on data formats, changing data formats during the duration of a call. SDP, SIP, and Jingle/XMPP belong in this category.
接続管理：たとえば、接続の設定、データ形式の合意、通話中のデータ形式の変更。SDP、SIP、およびJingle / XMPPはこのカテゴリに属します。
Presentation and control: What needs to happen in order to ensure that interactions behave in an unsurprising manner. This can include floor control, screen layout, voice-activated image switching, and other such functions, where part of the system requires cooperation between parties. Centralized Conferencing (XCON) [RFC6501] and Cisco/Tandberg's Telepresence Interoperability Protocol (TIP) were some attempts at specifying this kind of functionality; many applications have been built without standardized interfaces to these functions.
プレゼンテーションと制御：相互作用が驚くべき方法で動作することを保証するために何が起こる必要があるか。これには、フロアコントロール、画面レイアウト、音声起動の画像切り替えなど、システムの一部で当事者間の協力が必要な機能が含まれます。Centralized Conferencing（XCON）[RFC6501]およびCisco / TandbergのTelepresenceInteroperability Protocol（TIP）は、この種の機能を指定するためのいくつかの試みでした。多くのアプリケーションは、これらの機能への標準化されたインターフェースなしで構築されています。
Local system support functions: Functions that need not be specified uniformly, because each participant may implement these functions as they choose, without affecting the bits on the wire in a way that others have to be cognizant of. Examples in this category include echo cancellation (some forms of it), local authentication and authorization mechanisms, OS access control, and the ability to do local recording of conversations.
ローカルシステムサポート機能：各参加者は、他の参加者が認識しなければならない方法でネットワーク上のビットに影響を与えることなく、選択したとおりにこれらの機能を実装できるため、一律に指定する必要のない機能。このカテゴリの例には、エコーキャンセレーション（その一部の形式）、ローカル認証および承認メカニズム、OSアクセス制御、会話のローカル録音を行う機能が含まれます。
Within each functionality group, it is important to preserve both freedom to innovate and the ability for global communication. Freedom to innovate is helped by doing the specification in terms of interfaces, not implementation; any implementation able to communicate according to the interfaces is a valid implementation. The ability to communicate globally is helped by both (1) having core specifications be unencumbered by IPR issues and (2) having the formats and protocols be fully enough specified to allow for independent implementation.
各機能グループ内では、革新の自由とグローバルなコミュニケーション能力の両方を維持することが重要です。革新の自由は、実装ではなくインターフェースの観点から仕様を作成することによって助けられます。インターフェイスに従って通信できる実装はすべて有効な実装です。グローバルに通信する機能は、（1）コア仕様がIPRの問題に邪魔されないこと、および（2）フォーマットとプロトコルが独立した実装を可能にするために十分に指定されていることの両方によって支援されます。
One can think of the first three groups as forming a "media transport infrastructure" and of the last three groups as forming a "media service". In many contexts, it makes sense to use a common specification for the media transport infrastructure, which can be embedded in browsers and accessed using standard interfaces, and "let a thousand flowers bloom" in the "media service" layer; to achieve interoperable services, however, at least the first five of the six groups need to be specified.
最初の3つのグループは「メディアトランスポートインフラストラクチャ」を形成し、最後の3つのグループは「メディアサービス」を形成すると考えることができます。多くの場合、ブラウザに埋め込んで標準のインターフェイスを使用してアクセスできるメディアトランスポートインフラストラクチャの共通仕様を使用し、「メディアサービス」レイヤーで「千本の花を咲かせる」ことは理にかなっています。ただし、相互運用可能なサービスを実現するには、6つのグループのうち少なくとも最初の5つを指定する必要があります。
Data transport refers to the sending and receiving of data over the network interfaces, the choice of network-layer addresses at each end of the communication, and the interaction with any intermediate entities that handle the data but do not modify it (such as Traversal Using Relays around NAT (TURN) relays).
データ転送とは、ネットワークインターフェイスを介したデータの送受信、通信の両端でのネットワーク層アドレスの選択、およびデータを処理するがデータを変更しない中間エンティティとの相互作用（Traversal Usingなど）を指します。NAT（TURN）リレー周辺のリレー）。
It includes necessary functions for congestion control, retransmission, and in-order delivery.
輻輳制御、再送信、および順序どおりの配信に必要な機能が含まれています。
WebRTC endpoints MUST implement the transport protocols described in [RFC8835].
WebRTCエンドポイントは、[RFC8835]で説明されているトランスポートプロトコルを実装する必要があります。
The format for media transport is RTP [RFC3550]. Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations.
メディアトランスポートの形式はRTP [RFC3550]です。Secure Real-time Transport Protocol（SRTP）[RFC3711]の実装は、すべての実装に必要です。
The detailed considerations for usage of functions from RTP and SRTP are given in [RFC8834]. The security considerations for the WebRTC use case are provided in [RFC8826], and the resulting security functions are described in [RFC8827].
RTPおよびSRTPの関数の使用に関する詳細な考慮事項は、[RFC8834]に記載されています。WebRTCユースケースのセキュリティに関する考慮事項は[RFC8826]に記載されており、結果として得られるセキュリティ機能は[RFC8827]に記載されています。
Considerations for the transfer of data that is not in RTP format are described in [RFC8831], and a supporting protocol for establishing individual data channels is described in [RFC8832]. WebRTC endpoints MUST implement these two specifications.
RTP形式ではないデータの転送に関する考慮事項は[RFC8831]で説明されており、個々のデータチャネルを確立するためのサポートプロトコルは[RFC8832]で説明されています。WebRTCエンドポイントは、これら2つの仕様を実装する必要があります。
WebRTC endpoints MUST implement [RFC8834], [RFC8826], [RFC8827], and the requirements they include.
WebRTCエンドポイントは、[RFC8834]、[RFC8826]、[RFC8827]、およびそれらに含まれる要件を実装する必要があります。
The intent of this specification is to allow each communications event to use the data formats that are best suited for that particular instance, where a format is supported by both sides of the connection. However, a minimum standard is greatly helpful in order to ensure that communication can be achieved. This document specifies a minimum baseline that will be supported by all implementations of this specification and leaves further codecs to be included at the will of the implementer.
この仕様の目的は、各通信イベントが、接続の両側でフォーマットがサポートされている特定のインスタンスに最適なデータフォーマットを使用できるようにすることです。ただし、コミュニケーションを確実に実現するには、最低限の基準が非常に役立ちます。このドキュメントでは、この仕様のすべての実装でサポートされる最小ベースラインを指定し、実装者の意志でさらにコーデックを含めるようにします。
WebRTC endpoints that support audio and/or video MUST implement the codecs and profiles required in [RFC7874] and [RFC7742].
オーディオやビデオをサポートするWebRTCエンドポイントは、[RFC7874]および[RFC7742]で必要なコーデックとプロファイルを実装する必要があります。
The methods, mechanisms, and requirements for setting up, negotiating, and tearing down connections comprise a large subject, and one where it is desirable to have both interoperability and freedom to innovate.
接続を設定、ネゴシエート、および破棄するための方法、メカニズム、および要件は、大きな主題であり、相互運用性と革新の自由の両方を持つことが望ましいものです。
The following principles apply:
次の原則が適用されます。
1. The WebRTC media negotiations will be capable of representing the same SDP offer/answer semantics [RFC3264] that are used in SIP, in such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation.
1. WebRTCメディアネゴシエーションは、SIPとWebRTCメディアネゴシエーションの間にシグナリングゲートウェイを構築できるように、SIPで使用されるのと同じSDPオファー/アンサーセマンティクス[RFC3264]を表すことができます。
2. It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP/SDP mechanisms, codecs, and security mechanisms without using a media gateway. A signaling gateway to convert between the signaling on the web side and the SIP signaling may be needed.
2. メディアゲートウェイを使用せずに、ICEをサポートするレガシーSIPデバイスと、適切なRTP / SDPメカニズム、コーデック、およびセキュリティメカニズムの間でゲートウェイを設定することが可能になります。Web側のシグナリングとSIPシグナリングの間で変換するシグナリングゲートウェイが必要になる場合があります。
3. When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that codec in the web browsers. Adding new codecs that might have new SDP parameters should not change the APIs between the browser and the JavaScript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate, with no changes to the JavaScript applications.
3. 新しいコーデックのSDPが指定されている場合、そのコーデックをWebブラウザーで使用できるようにするために、他の標準化は必要ありません。新しいSDPパラメータを持つ可能性のある新しいコーデックを追加しても、ブラウザとJavaScriptアプリケーション間のAPIは変更されません。ブラウザが新しいコーデックをサポートするとすぐに、コーデックが指定される前に作成された古いアプリケーションは、JavaScriptアプリケーションに変更を加えることなく、必要に応じて新しいコーデックを自動的に使用できるようになります。
The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in [RFC8829].
WebRTCに対して行われた特定の選択、およびWebRTCを実装するブラウザーによって提供されるAPIに対するそれらの影響については、[RFC8829]で説明されています。
WebRTC browsers MUST implement [RFC8829].
WebRTCブラウザは[RFC8829]を実装する必要があります。
WebRTC endpoints MUST implement those functions described in [RFC8829] that relate to the network layer (e.g., BUNDLE [RFC8843], "rtcp-mux" [RFC5761], and Trickle ICE [RFC8838]), but these endpoints do not need to support the API functionality described in [RFC8829].
WebRTCエンドポイントは、ネットワーク層に関連する[RFC8829]で説明されている機能（BUNDLE [RFC8843]、 "rtcp-mux" [RFC5761]、Trickle ICE [RFC8838]など）を実装する必要がありますが、これらのエンドポイントはサポートする必要はありません。[RFC8829]で説明されているAPI機能。
The most important part of control is the users' control over the browser's interaction with input/output devices and communications channels. It is important that the users have some way of figuring out where their audio, video, or texting is being sent; for what purported reason; and what guarantees are made by the parties that form part of this control channel. This is largely a local function between the browser, the underlying operating system, and the user interface; this is specified in the peer connection API [W3C.WD-webrtc] and the media capture API [W3C.WD-mediacapture-streams].
制御の最も重要な部分は、入力/出力デバイスおよび通信チャネルとのブラウザーの相互作用に対するユーザーの制御です。ユーザーが自分のオーディオ、ビデオ、またはテキストメッセージがどこに送信されているかを把握する方法を持っていることが重要です。何のために;そして、この制御チャネルの一部を形成する当事者によってどのような保証がなされるか。これは主に、ブラウザ、基盤となるオペレーティングシステム、およびユーザーインターフェイス間のローカル機能です。これは、ピア接続API [W3C.WD-webrtc]およびメディアキャプチャAPI [W3C.WD-mediacapture-streams]で指定されています。
WebRTC browsers MUST implement these two specifications.
WebRTCブラウザーは、これら2つの仕様を実装する必要があります。
These functions are characterized by the fact that the quality of an implementation strongly influences the user experience, but the exact algorithm does not need coordination. In some cases (for instance, echo cancellation, as described below), the overall system definition may need to specify that the overall system needs to have some characteristics for which these facilities are useful, without requiring them to be implemented a certain way.
これらの機能は、実装の品質がユーザーエクスペリエンスに大きく影響するという事実によって特徴付けられますが、正確なアルゴリズムは調整を必要としません。場合によっては（たとえば、以下で説明するエコーキャンセレーション）、システム全体の定義で、特定の方法で実装する必要なしに、これらの機能が役立つ特性をシステム全体に持たせる必要があることを指定する必要があります。
Local functions include echo cancellation; volume control; camera management, including focus, zoom, and pan/tilt controls (if available); and more.
ローカル機能にはエコーキャンセレーションが含まれます。音量調節;フォーカス、ズーム、パン/チルトコントロール（利用可能な場合）を含むカメラ管理。もっと。
One would want to see certain parts of the system conform to certain properties; for instance:
システムの特定の部分が特定のプロパティに準拠していることを確認したい場合があります。例えば：
* Echo cancellation should be good enough to achieve the suppression of acoustical feedback loops below a perceptually noticeable level.
* エコーキャンセレーションは、知覚的に目立つレベル以下の音響フィードバックループの抑制を達成するのに十分なはずです。
* Privacy concerns MUST be satisfied; for instance, if remote control of a camera is offered, the APIs should be available to let the local participant figure out who's controlling the camera and possibly decide to revoke the permission for camera usage.
* プライバシーの懸念は満たされなければなりません。たとえば、カメラのリモートコントロールが提供されている場合、APIを使用して、ローカル参加者がカメラを制御しているユーザーを特定し、カメラの使用許可を取り消すことができるようにする必要があります。
* Automatic Gain Control (AGC), if present, should normalize a speaking voice into a reasonable dB range.
* 自動ゲイン制御（AGC）が存在する場合は、話している音声を適切なdB範囲に正規化する必要があります。
The requirements on WebRTC systems with regard to audio processing are found in [RFC7874], and that document includes more guidance about echo cancellation and AGC; the APIs for control of local devices are found in [W3C.WD-mediacapture-streams].
オーディオ処理に関するWebRTCシステムの要件は、[RFC7874]に記載されており、そのドキュメントには、エコーキャンセレーションとAGCに関する詳細なガイダンスが含まれています。ローカルデバイスを制御するためのAPIは、[W3C.WD-mediacapture-streams]にあります。
WebRTC endpoints MUST implement the processing functions in [RFC7874]. (Together with the requirement in Section 6, this means that WebRTC endpoints MUST implement the whole document.)
WebRTCエンドポイントは、[RFC7874]の処理機能を実装する必要があります。（セクション6の要件とともに、これはWebRTCエンドポイントがドキュメント全体を実装する必要があることを意味します。）
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Security of the web-enabled real-time communications comes in several pieces:
Web対応のリアルタイム通信のセキュリティにはいくつかの要素があります。
Security of the components: The browsers, and other servers involved. The most target-rich environment here is probably the browser; the aim here should be that the introduction of these components introduces no additional vulnerability.
コンポーネントのセキュリティ：ブラウザ、および関連するその他のサーバー。ここで最もターゲットが豊富な環境は、おそらくブラウザです。ここでの目的は、これらのコンポーネントの導入によって追加の脆弱性が発生しないことです。
Security of the communication channels: It should be easy for participants to reassure themselves of the security of their communication -- by verifying the crypto parameters of the links that they participate in, and to get reassurances from the other parties to the communication that those parties promise that appropriate measures are taken.
通信チャネルのセキュリティ：参加者は、参加しているリンクの暗号化パラメータを確認することで、通信のセキュリティを簡単に安心できる必要があります。また、他の当事者から、それらの当事者の通信に対して安心感を得ることができます。適切な措置が取られることを約束します。
Security of the partners' identities: Verifying that the participants are who they say they are (when positive identification is appropriate) or that their identities cannot be uncovered (when anonymity is a goal of the application).
パートナーのIDのセキュリティ：参加者が本人であるか（確実なIDが適切な場合）、またはIDを明らかにできない（匿名性がアプリケーションの目標である場合）ことを確認します。
The security analysis, and the requirements derived from that analysis, are contained in [RFC8826].
セキュリティ分析、およびその分析から導き出された要件は、[RFC8826]に含まれています。
It is also important to read the security sections of [W3C.WD-mediacapture-streams] and [W3C.WD-webrtc].
[W3C.WD-mediacapture-streams]と[W3C.WD-webrtc]のセキュリティセクションを読むことも重要です。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、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、「Session Description Protocol（SDP）を使用したオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org/ info / rfc3264>。
[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：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https://www.rfc-editor.org/info/rfc3711>。
[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, <https://www.rfc-editor.org/info/rfc7742>.
[RFC7742] Roach、A.B。、「WebRTC Video Processing and Codec Requirements」、RFC 7742、DOI 10.17487 / RFC7742、2016年3月、<https://www.rfc-editor.org/info/rfc7742>。
[RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, <https://www.rfc-editor.org/info/rfc7874>.
[RFC7874]ヴァリン、JM。およびC.Bran、「WebRTCオーディオコーデックおよび処理要件」、RFC 7874、DOI 10.17487 / RFC7874、2016年5月、<https://www.rfc-editor.org/info/rfc7874>。
[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>。
[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] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[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>。
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, <https://www.rfc-editor.org/info/rfc8829>.
[RFC8829] Uberti、J.、Jennings、C。、およびE. Rescorla、Ed。、「JavaScript Session Establishment Protocol（JSEP）」、RFC 8829、DOI 10.17487 / RFC8829、2021年1月、<https：//www.rfc-editor.org/info/rfc8829>。
[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 Data Channels」、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 Data Channel Establishment Protocol」、RFC 8832、DOI 10.17487 / RFC8832、2021年1月、<https://www.rfc-editor.org/info / rfc8832>。
[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、「Media Transport and Use of RTP in WebRTC」、RFC 8834、DOI 10.17487 / RFC8834、2021年1月、<https：//www.rfc-editor.org / info / rfc8834>。
[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, DOI 10.17487/RFC8835, January 2021, <https://www.rfc-editor.org/info/rfc8835>.
[RFC8835] Alvestrand、H。、「Transports for WebRTC」、RFC 8835、DOI 10.17487 / RFC8835、2021年1月、<https://www.rfc-editor.org/info/rfc8835>。
[W3C.WD-mediacapture-streams] Jennings, C., Aboba, B., Bruaroey, J-I., and H. Boström, "Media Capture and Streams", W3C Candidate Recommendation, <https://www.w3.org/TR/mediacapture-streams/>.
[W3C.WD-mediacapture-streams] Jennings、C.、Aboba、B.、Bruaroey、JI。、およびH.Boström、「Media Capture and Streams」、W3C Candidate Recommendation、<https://www.w3.org/ TR / mediacapture-streams />。
[W3C.WD-webrtc] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Proposed Recommendation, <https://www.w3.org/TR/webrtc/>.
[W3C.WD-webrtc] Jennings、C.、Boström、H。、およびJ-I。Bruaroey、「WebRTC 1.0：ブラウザ間のリアルタイム通信」、W3C提案の推奨事項、<https://www.w3.org/TR/webrtc/>。
[HTML5] WHATWG, "HTML - Living Standard", January 2021, <https://html.spec.whatwg.org/>.
[HTML5] WHATWG、「HTML-Living Standard」、2021年1月、<https://html.spec.whatwg.org/>。
[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：SessionInitiationProtocol」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, DOI 10.17487/RFC3361, August 2002, <https://www.rfc-editor.org/info/rfc3361>.
[RFC3361] Schulzrinne、H。、「Session Initiation Protocol（SIP）Serversの動的ホスト構成プロトコル（DHCP-for-IPv4）オプション」、RFC 3361、DOI 10.17487 / RFC3361、2002年8月、<https：//www.rfc-editor.org/info/rfc3361>。
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <https://www.rfc-editor.org/info/rfc3935>.
[RFC3935] Alvestrand、H。、「A Mission Statement for the IETF」、BCP 95、RFC 3935、DOI 10.17487 / RFC3935、2004年10月、<https://www.rfc-editor.org/info/rfc3935>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<https：// www.rfc-editor.org / info / rfc5245>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C。およびM. Westerlund、「単一ポートでのRTPデータと制御パケットの多重化」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<https://www.rfc-editor.org/info/ rfc5761>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<https://www.rfc-editor.org/info/rfc6120>。
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <https://www.rfc-editor.org/info/rfc6501>.
[RFC6501] Novo、O.、Camarillo、G.、Morgan、D。、およびJ. Urpalainen、「集中会議（XCON）の会議情報データモデル」、RFC 6501、DOI 10.17487 / RFC6501、2012年3月、<https：//www.rfc-editor.org/info/rfc6501>。
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.
[RFC7478] Holmberg、C.、Hakansson、S。、およびG. Eriksson、「Web Real-Time Communication Use Cases and Requirements」、RFC 7478、DOI 10.17487 / RFC7478、2015年3月、<https：//www.rfc-editor.org/info/rfc7478>。
[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. Wing、「Traversal Using Relays around NAT（TURN）Server Auto Discovery」、RFC 8155、DOI 10.17487 / RFC8155、2017年4月、<https：// www。rfc-editor.org/info/rfc8155>。
[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.、Dhesikan、S.、Jennings、C。、およびD. Druta、「WebRTC QoSのDifferentiatedServices Code Point（DSCP）パケットマーキング」、RFC 8837、DOI 10.17487 / RFC8837、2021年1月<https://www.rfc-editor.org/info/rfc8837>。
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021, <https://www.rfc-editor.org/info/rfc8838>.
[RFC8838] Ivov、E.、Uberti、J。、およびP. Saint-Andre、「Trickle ICE：Interactive Connectivity Establishment（ICE）プロトコルの候補のインクリメンタルプロビジョニング」、RFC 8838、DOI 10.17487 / RFC8838、2021年1月<https://www.rfc-editor.org/info/rfc8838>。
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.
[RFC8843] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、RFC 8843、DOI 10.17487 / RFC8843、2021年1月<https：// www。rfc-editor.org/info/rfc8843>。
[WebRTC-Gateways] Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways", Work in Progress, Internet-Draft, draft-ietf-rtcweb-gateways-02, 21 January 2016, <https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02>.
[WebRTC-Gateways] Alvestrand、H。and U. Rauschenbach、 "WebRTC Gateways"、Work in Progress、Internet-Draft、draft-ietf-rtcweb-gateways-02、21 January 2016、<https：//tools.ietf。org / html / draft-ietf-rtcweb-gateways-02>。
[XEP-0124] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., Stout, L., and W. Tilanus, "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF XEP 0124, November 2016, <https://xmpp.org/extensions/xep-0124.html>.
[XEP-0124] Paterson、I.、Smith、D.、Saint-Andre、P.、Moffitt、J.、Stout、L。、およびW. Tilanus、「Bidirection-streams Over Synchronous HTTP（BOSH）」、XSFXEP 0124、2016年11月、<https://xmpp.org/extensions/xep-0124.html>。
[XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166, September 2018, <https://xmpp.org/extensions/xep-0166.html>.
[XEP-0166] Ludwig、S.、Beda、J.、Saint-Andre、P.、McQueen、R.、Egan、S。、およびJ. Hildebrand、「Jingle」、XSF XEP 0166、2018年9月、<https：//xmpp.org/extensions/xep-0166.html>。
Acknowledgements
謝辞
The number of people who have taken part in the discussions surrounding this document are too numerous to list, or even to identify. The people listed below have made special, identifiable contributions; this does not mean that others' contributions are less important.
このドキュメントを取り巻く議論に参加した人の数は、リストすることも、特定することさえできないほど多すぎます。以下にリストされている人々は、特別で識別可能な貢献をしました。これは、他の人の貢献がそれほど重要ではないという意味ではありません。
Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus Westerlund, and Jörg Ott, who offered technical contributions to various draft versions of this document.
このドキュメントのさまざまなドラフトバージョンに技術的な貢献をしてくれたCaryBran、Cullen Jennings、Colin Perkins、Magnus Westerlund、およびJörgOttに感謝します。
Thanks to Jonathan Rosenberg, Matthew Kaufman, and others at Skype for the ASCII drawings in Section 3.
セクション3のASCII図面について、SkypeのJonathan Rosenberg、Matthew Kaufman、およびその他の人々に感謝します。
Thanks to Alissa Cooper, Björn Höhrmann, Colin Perkins, Colton Shields, Eric Rescorla, Heath Matlock, Henry Sinnreich, Justin Uberti, Keith Drage, Magnus Westerlund, Olle E. Johansson, Sean Turner, and Simon Leinen for document review.
ドキュメントのレビューをしてくれたAlissaCooper、BjörnHöhrmann、Colin Perkins、Colton Shields、Eric Rescorla、Heath Matlock、Henry Sinnreich、Justin Uberti、Keith Drage、Magnus Westerlund、Olle E. Johansson、Sean Turner、SimonLeinenに感謝します。
Author's Address
著者の住所
Harald T. Alvestrand Google Kungsbron 2 SE-11122 Stockholm Sweden
Harald T. Alvestrand Google Kungsbron 2SE-11122ストックホルムスウェーデン
Email: harald@alvestrand.no