4.1.10.1. Use of Provisional Answers (暫定応答の使用)
4.1.10.1. Use of Provisional Answers (暫定応答の使用)
ほとんどのアプリケーションは, "pranswer" タイプを使用してアンサーを作成する必要はありません。セッショントランスポートを準備し, メディアクリッピングを防ぐために, オファーに即座に応答を送信することは良い習慣ですが, JSEP アプリケーションの推奨処理は, オファーを受信した直後に null MediaStreamTrack を使用して "sendonly" 最終アンサーを作成して送信することです。これにより, 呼び出し側によるメディアの送信が防止され, 被呼び出し側がアンサー時にメディアをすぐに送信できるようになります。後で, 被呼び出し側が実際に呼び出しを受け入れたとき, アプリケーションは実際の MediaStreamTrack をプラグインし, 新しい "sendrecv" オファーを作成して以前のオファー/アンサーペアを更新し, 双方向メディアフローを開始できます。これは "sendonly" pranswer に続いて "sendrecv" アンサーで行うこともできますが, 初期 pranswer はオファー/アンサー交換を開いたままにするため, この間に呼び出し側が更新されたオファーを送信できないことを意味します。
例として, オーディオとビデオをできるだけ早く設定したい典型的な JSEP アプリケーションを考えてみましょう。被呼び出し側がオーディオとビデオの MediaStreamTrack を含むオファーを受信すると, これらのトラックを sendonly として受け入れる即座のアンサーを送信します (つまり, 呼び出し側はまだ被呼び出し側にメディアを送信せず, 被呼び出し側もまだ独自の MediaStreamTrack を追加していないため, 被呼び出し側もメディアを送信しません)。次に, ユーザーに呼び出しを受け入れて必要なローカルトラックを取得するように要求します。ユーザーが受け入れると, アプリケーションは取得したトラックをプラグインします。ICE ハンドシェイクと DTLS ハンドシェイクがこの時点でおそらく完了しているため, すぐに送信を開始できます。アプリケーションは, 呼び出しの受け入れを示し, オーディオとビデオを双方向メディアに移動する新しいオファーをリモート側に送信します。これらに沿った詳細な例のフローは, セクション 7.3 に示されています。
もちろん, 一部のアプリケーション, 特にレガシーシグナリングプロトコルへのゲートウェイを試みているアプリケーションは, この二重オファー/アンサー交換を実行できない場合があります。これらの場合でも, pranswer はアプリケーションにトランスポートを準備するメカニズムを提供できます。