3. Architecture and Functionality Groups (アーキテクチャと機能グループ)
ブラウザベースのアプリケーションのリアルタイムサポートのモデルは、ブラウザが電話やビデオ会議などのアプリケーションに必要なすべての機能を含むと仮定していません。ビジョンは、ブラウザが Web アプリケーションに必要な機能を持ち、バックエンドサーバーと連携してこれらの機能を実現することです。
これは、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
図1: ブラウザモデル
HTTPS と WebSockets も、ブラウザ API を通じて JavaScript アプリケーションに提供されていることに注意してください。
すべてのプロトコルおよび API 仕様と同様に、プロトコルは別のブラウザとの通信のみに制限されていません；プロトコルが完全に規定されているため、プロトコルを忠実に実装するあらゆるエンドポイントは、ブラウザで実行されているアプリケーションと相互運用できるはずです。
図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 | |
| | | |
+-----------+ +-----------+
図2: ブラウザ RTC トラペゾイド
この図で注目すべき重要な部分は、メディアパス（"下位パス"）がブラウザ間で直接転送されるため、WebRTC プロトコルスイートの規定に準拠する必要があることです；シグナリングパス（"上位パス"）はサーバーを経由し、これらのサーバーは必要に応じてシグナルを変更、変換、または操作できます。
2つの Web サーバーが異なるエンティティによって運営されている場合、標準化または他のプロトコル手段を通じてサーバー間シグナリングメカニズムに合意する必要があります。既存のプロトコル（例えば、SIP [RFC3261] または Extensible Messaging and Presence Protocol (XMPP) [RFC6120]）をサーバー間で使用でき、標準ベースのプロトコルまたはプロプライエタリプロトコルをブラウザと Web サーバー間で使用できます。
例えば、両方のオペレーターのサーバーが SIP を実装している場合、サーバー間の通信に SIP を使用し、ブラウザで実行されているアプリケーションと Web サーバー間では標準化されたシグナリングメカニズム（例えば、SIP over WebSockets）またはプロプライエタリシグナリングメカニズムを使用できます。同様に、両方のオペレーターのサーバーが XMPP を実装している場合、XMPP サーバー間の通信に XMPP を使用し、ブラウザで実行されているアプリケーションと Web サーバー間では標準化されたシグナリングメカニズム（例えば、XMPP over WebSockets または Bidirectional-streams Over Synchronous HTTP (BOSH) [XEP-0124]）またはプロプライエタリシグナリングメカニズムを使用できます。
クライアント・サーバーおよびサーバー間シグナリングのプロトコルの選択、およびそれらの間の変換の定義は、本文書で説明されている WebRTC プロトコルスイートの範囲外です。
ブラウザに必要な機能グループは、多かれ少なかれ、下層から上層に向けて次のように規定できます:
Data transport (データ転送): 例えば、TCP と UDP、およびエンティティ間で安全に接続を確立する方法、およびデータをいつ送信するかを決定する機能: 輻輳管理 (Congestion Management)、帯域幅推定 (Bandwidth Estimation) など。
Data framing (データフレーミング): RTP、Stream Control Transmission Protocol (SCTP)、DTLS、およびコンテナとして使用される他のデータ形式、およびデータの機密性と完全性のための機能。
Data formats (データ形式): コーデック仕様 (Codec Specifications)、フォーマット仕様 (Format Specifications)、およびシステム間で渡されるデータの機能仕様。オーディオおよびビデオコーデック、ならびにデータおよびドキュメント共有のための形式は、すべてこのカテゴリに該当します。データ形式を使用するには、それらを記述する方法（例えば、セッション記述 (Session Description)）が必要です。
Connection management (接続管理): 例えば、接続の確立、データ形式の合意、通話中のデータ形式の変更。SDP、SIP、および Jingle/XMPP はこのカテゴリに該当します。
Presentation and control (プレゼンテーションと制御): インタラクションが驚くべき方法で起こらないようにするために発生する必要があることです。これには、発言権制御 (Floor Control)、画面レイアウト (Screen Layout)、音声起動画像切り替え (Voice-Activated Image Switching)、およびシステムの一部が当事者間の協力を必要とするその他の機能が含まれます。Centralized Conferencing (XCON) [RFC6501] および Cisco/Tandberg の Telepresence Interoperability Protocol (TIP) は、このような機能を規定する試みの一部です；多くのアプリケーションは、これらの機能の標準化されたインターフェースなしで構築されています。
Local system support functions (ローカルシステムサポート機能): 各参加者が自分の選択に従って実装でき、他の人が注意しなければならない方法で線上のビットに影響を与えないため、統一的に規定する必要がない機能。このカテゴリの例には、エコーキャンセレーション (Echo Cancellation)（その一部の形式）、ローカル認証および承認メカニズム (Local Authentication and Authorization Mechanisms)、OS アクセス制御 (OS Access Control)、および会話のローカル録音を行う機能が含まれます。
各機能グループにおいて、イノベーションの自由とグローバルコミュニケーション能力の両方を保持することが重要です。イノベーションの自由は、実装ではなくインターフェースの観点から規定することによって支援されます；インターフェースに従って通信できるあらゆる実装は有効な実装です。グローバルコミュニケーション能力は、次の2点によって支援されます: (1) コア仕様が知的財産権 (IPR) の問題によって妨げられないこと、(2) フォーマットとプロトコルの仕様が独立した実装を可能にするのに十分完全であること。
最初の3つのグループを「メディアトランスポートインフラストラクチャ (Media Transport Infrastructure)」を形成するものと見なし、後の3つのグループを「メディアサービス (Media Service)」を形成するものと見なすことができます。多くの場合、メディアトランスポートインフラストラクチャに共通の仕様を使用することが理にかなっており、これはブラウザに埋め込まれ、標準インターフェースを使用してアクセスでき、「メディアサービス」層で「百花斉放」させることができます；しかし、相互運用可能なサービスを実現するには、少なくとも6つのグループのうち最初の5つを規定する必要があります。