1. Introduction (はじめに)
インターネットは、その誕生当初から、リアルタイムでインタラクティブなアプリケーションの展開の可能性を秘めた手段として考えられてきました -- 最も想像しやすいのは音声会話（いわゆる「インターネット電話」）やビデオ会議です。
このようなアプリケーションを構築する最初の試みは、特殊なネットワーク、特殊なハードウェア、カスタムメイドのソフトウェアに依存しており、多くの場合、非常に高価であるか品質が低く、インフラストラクチャに大きな要求を課していました。
利用可能な帯域幅が増加し、プロセッサやその他のハードウェアがますます高速になるにつれて、参加の障壁は低下し、一般的に利用可能なコンピューティングハードウェアで満足のいくエクスペリエンスを提供することが可能になりました。
しかし、普遍的な通信能力にはまだいくつかの障壁があります -- その1つは、すべての人が通信に利用可能にすべきだと同意する単一の通信プロトコルセットがまだ存在しないことです；もう1つは、他の通信システムの電話番号や電子メールアドレスのように機能する普遍的な識別システムが完全に欠如していることです。
しかし、「普遍的なソリューション」の開発は困難であることが証明されています。
過去数年間、サービス展開のための新しいプラットフォームの台頭も見られました: ブラウザ組み込みアプリケーション (Browser-Embedded Application)、または「Webアプリケーション (Web Application)」です。ブラウザプラットフォームが必要なインターフェースを備えている限り、その上でほぼあらゆる種類のサービスを提供することが可能であることが判明しました。
従来、これらのインターフェースはプラグイン (Plugins) によって提供されており、ブラウザとは別にダウンロードしてインストールする必要がありました；HTML5 [HTML5] の開発において、アプリケーション開発者は、これらのインターフェースをブラウザ内で標準化された方法で利用可能にする可能性に大きな期待を寄せています。
本メモは、(1) ブラウザ内のJavaScript APIを通じてアクセスおよび制御可能であり、(2) インターネットを介してブラウザ間で直接通信するアプリケーションでインタラクティブなオーディオとビデオの使用を可能にする十分な機能セットを共同で形成する、一連のビルディングブロック (Building Blocks) について説明します。結果として得られるプロトコルスイートは、WebRTC「ユースケース」文書 [RFC7478] に必須シナリオとして記載されているすべてのアプリケーションを可能にすることを意図しています。
他の取り組み -- 例えば、W3C Web Real-Time Communications、Web Applications Security、Devices and Sensors ワーキンググループ -- は、これらの機能のために、HTML5 の取り組みの範囲内または並行して、標準化された API とインターフェースを利用可能にすることに焦点を当てています。本メモは、ネットワーク上の相互作用を規定するために必要なプロトコルとサブプロトコルの規定に集中しています。
事業者は、WebRTC の展開が、ネットワーク上のリアルタイムメディアのシグナリングの性質の変化をもたらし、このようなメディアの作成と消費に使用されるデバイスの種類の変化をもたらす可能性があることに注意する必要があります。シグナリングの場合、WebRTC セッションのセットアップは通常、アプリケーション固有のプロトコルを使用する TLS セキュアな Web テクノロジーを介して行われます。セッション記述プロトコル (Session Description Protocol, SDP) を解釈するためにネットワーク要素を挿入する運用技術 -- (1) エンドポイントがネットワークに SIP サーバー [RFC3361] を要求するか、(2) SIP アプリケーション層ゲートウェイ (Application Layer Gateways, ALGs) の透過的な挿入のいずれかを通じて -- は、このようなシグナリングでは機能しません。協調的なエンドポイントを使用するネットワークの場合、[RFC8155] で定義されているアプローチは、[RFC3361] の適切な代替として機能する可能性があります。ブラウザベースの通信の増加は、SIP デスクトップ電話などの専用リアルタイム通信ハードウェアからの移行につながる可能性もあります。これにより、トラフィックフィルタリングや QoS などの目的で専用リアルタイムデバイスを独自のネットワークセグメント、アドレス範囲、または VLAN に配置する運用技術の有効性が低下します。[RFC8837] で説明されているマーキングを適用することは、このような技術の適切な代替となる可能性があります。
本文書は正式には [RFC8445] に依存していますが、その発行時点で、大多数の WebRTC 実装は [RFC5245] で説明されている Interactive Connectivity Establishment (ICE) のバージョンをサポートし、[RFC8838] で説明されている Trickle ICE メカニズムの標準化前バージョンを使用しています。[RFC8445] で定義されている "ice2" 属性は、リモートエンドポイントが使用しているバージョンを検出し、古い仕様から新しい仕様への円滑な移行を提供するために使用できます。
本メモは、IETF と W3C の取り組みの両方からなる全体的な取り組みを指すために、用語「WebRTC」（使用されている大文字小文字に注意）を使用しています。