1. Introduction (はじめに)

この文書は, W3C Web Real-Time Communication (WebRTC) RTCPeerConnection インターフェース [W3C.webrtc] がマルチメディアセッションのセットアップ, 管理, 終了を制御するためにどのように使用されるかを説明します。

1.1 General Design of JSEP (JSEPの全体設計)

WebRTC 呼設定は, メディアプレーンの制御に焦点を当て, シグナリングプレーンの動作を可能な限りアプリケーションに任せるように設計されています。その理由は, 異なるアプリケーションが異なるプロトコルを使用することを好む可能性があるためです。例えば, 既存の SIP 呼シグナリングプロトコル, または特定のアプリケーション用にカスタマイズされたもの, おそらく新しいユースケース用のものなどです。このアプローチでは, 交換する必要がある重要な情報は, マルチメディアセッション記述であり, これはメディアプレーンを確立するために必要なトランスポートとメディア構成情報を指定します。

これらの考慮事項を念頭に置いて, この文書は JavaScript Session Establishment Protocol (JSEP) を説明します。これは JavaScript からシグナリング状態機械を完全に制御できるようにします。上記のように, JSEP は JavaScript アプリケーションが WebRTC API を含むランタイム内で実行されるモデルを想定しています ("JSEP implementation")。JSEP 実装は, コアシグナリングフローからほぼ完全に分離されており, 代わりに JavaScript が 2 つのインターフェースを使用して処理します: (1) ローカルおよびリモートセッション記述を渡すこと, (2) Interactive Connectivity Establishment (ICE) 状態機械 [RFC8445] と相互作用すること。JSEP 実装と JavaScript アプリケーションの組み合わせは, この文書全体で "JSEP endpoint" と呼ばれます。

この文書では, JSEP の使用は常に 2 つの JSEP エンドポイント間で発生するかのように説明されています。ただし, 多くの場合, 実際には JSEP エンドポイントと何らかのサーバー (ゲートウェイや Multipoint Control Unit (MCU) など) の間で発生することに注意してください。この区別は JSEP エンドポイントには見えません; それは API を介して与えられた指示に従うだけです。

JSEP のセッション記述の処理はシンプルで直接的です。offer/answer 交換が必要になるたびに, 開始側は createOffer API を呼び出して offer を作成します。次に, アプリケーションはその offer を使用して, setLocalDescription API を介してローカル構成をセットアップします。offer は最終的に, その優先するシグナリングメカニズム (例: WebSockets) を介してリモート側に送信されます; その offer を受信すると, リモートパーティは setRemoteDescription API を使用してそれをインストールします。

offer/answer 交換を完了するために, リモートパーティは createAnswer API を使用して適切な answer を生成し, setLocalDescription API を使用してそれを適用し, シグナリングチャネルを介して answer を開始者に送り返します。開始者がその answer を受け取ると, setRemoteDescription API を使用してそれをインストールし, 初期セットアップが完了します。このプロセスは, 追加の offer/answer 交換のために繰り返すことができます。

ICE [RFC8445] に関して, JSEP は ICE 状態機械を全体的なシグナリング状態機械から切り離します。ICE 状態機械は JSEP 実装内に残る必要があります。なぜなら, 実装のみが候補や他のトランスポート情報の必要な知識を持っているためです。この分離を実行することで, セッション記述をトランスポートから切り離すプロトコルに追加の柔軟性が提供されます。例えば, 従来の SIP では, 各 offer または answer は自己完結型であり, セッション記述とトランスポート情報の両方を含みます。しかし, [RFC8840] は SIP を Trickle ICE [RFC8838] と共に使用することを許可しており, この場合, セッション記述は即座に送信でき, トランスポート情報は利用可能になったときに送信できます。トランスポート情報を個別に送信することで, より高速な ICE および DTLS 起動が可能になります。なぜなら, ICE チェックは, すべてのトランスポート情報を待つのではなく, 任意のトランスポート情報が利用可能になるとすぐに開始できるためです。JSEP の ICE とシグナリング状態機械の切り離しにより, どちらのモデルにも対応できます。

シグナリングを抽象化しますが, JSEP アプローチでは, アプリケーションがシグナリングプロセスを認識している必要があります。アプリケーションは呼を設定するためにセッション記述の内容を理解する必要はありませんが, アプリケーションは適切なタイミングで適切な API を呼び出し, セッション記述と ICE 情報を選択したシグナリングプロトコルの定義されたメッセージに変換し, 他方から受信したメッセージに対して逆変換を実行する必要があります。

アプリケーションの作業を容易にする 1 つの方法は, 開発者からこの複雑さを隠す JavaScript ライブラリを提供することです; そのライブラリは, 特定のシグナリングプロトコルとその状態機械およびシリアライゼーションコードを実装し, アプリケーション開発者により高レベルの呼指向インターフェースを提示します。例えば, JSEP API の上に SIP [RFC3261] および Extensible Messaging and Presence Protocol (XMPP) [RFC6120] シグナリングプロトコルの実装を提供するライブラリが存在します。したがって, JSEP は, 初心者開発者に追加の複雑さを強制することなく, 経験豊富な開発者により大きな制御を提供します。

1.2 Other Approaches Considered (検討された他のアプローチ)

JSEP の代わりに検討されたアプローチの 1 つは, 軽量シグナリングプロトコルを含めることでした。API にセッション記述を提供する代わりに, API はこのプロトコルからのメッセージを生成および消費します。より高レベルの API を提供する一方で, これは JSEP 実装内でのシグナリングの制御を増やし, シグナリンググレア ([RFC3264], セクション 4 を参照) などの概念を理解および処理する必要が生じました。

検討されたが選択されなかった 2 番目のアプローチは, メディア制御オブジェクトの管理をセッション記述から切り離し, 代わりに各コンポーネントを直接制御する API を提供することでした。これは, アプリケーションプログラマにこのレベルの複雑さを公開することを要求することは有益ではないという議論に基づいて拒否されました; それは (1) 単純な例でさえ, 必要なすべての相互作用を調整するために大量のコードを必要とする API になり, (2) 合意および文書化する必要がある大きな API サーフェスを作成します。さらに, これらの API ポイントは任意の順序で呼び出すことができ, JSEP アプローチよりもメディアサブシステムとのより複雑な一連の相互作用をもたらします。JSEP アプローチは, セッション記述がどのように評価および適用されるかを指定します。

検討された JSEP のバリエーションの 1 つは, 基本的なセッション記述指向の API を維持するが, offer と answer を生成するメカニズムを JSEP 実装から移動することでした。実装内で createOffer/createAnswer メソッドを提供する代わりに, このアプローチは代わりに getCapabilities API を公開し, アプリケーションに独自のセッション記述を生成するために必要な情報を提供します。これにより, アプリケーションが行う必要がある作業量が増加します; それは, 機能からセッション記述を生成する方法を知る必要があり, 特に任意の offer とサポートされている機能から正しい answer を生成する方法を知る必要があります。これは確かに上記のようなライブラリを使用することで対処できますが, 基本的に単純な例でもそのライブラリの使用を強制します。createOffer/createAnswer を提供することで, この問題を回避します。

1.3 Contradiction regarding bundle-only "m=" sections (bundle-only "m=" セクションに関する矛盾)

WebRTC 仕様文書の承認以来, IETF は JSEP を指定する文書と BUNDLE を指定する文書 (この RFC と [RFC8843], それぞれ) の間に不一致があることに気づきました。解決策に達するために発行をさらに遅らせるのではなく, 文書は元々承認されたとおりに発行されています。IETF はこれらの技術に関する作業を再開する予定であり, 解決策が利用可能になり次第, これらの文書の改訂版が発行される予定です。

具体的な問題は, この RFC のセクション 4.1.1 で説明されているように, bundle-only として指定された "m=" セクションの処理に関係します。現在, JSEP と BUNDLE の間, およびこれらの仕様と既存のブラウザ実装の間に相違があります:

JSEP は, これらの "m=" セクションは初期 offer ではポートゼロを使用し "a=bundle-only" 属性を追加する必要があるが, answer または後続の offer では追加しないと規定しています。
BUNDLE は, これらの "m=" セクションは前のポイントで説明したようにマークする必要があるが, すべての offer と answer でマークすると規定しています。
現在のほとんどのブラウザは, ポートゼロで "m=" セクションをマークせず, 代わりにすべてのバンドルされた "m=" セクションに同じポートを使用します; 他のいくつかは JSEP の動作に従います。