メインコンテンツまでスキップ

3.2 Session Descriptions and State Machine (セッション記述と状態機械)

3.2 Session Descriptions and State Machine (セッション記述と状態機械)​

メディアプレーンを確立するために, JSEP 実装はリモート側に何を送信するか, および受信したメディアをどのように処理するかを示す特定のパラメータが必要です。これらのパラメータは, offer と answer でのセッション記述の交換によって決定され, JSEP API で処理する必要があるこのプロセスの特定の詳細があります。

セッション記述がローカル側に適用されるかリモート側に適用されるかは, その記述の意味に影響します。例えば, リモートパーティに送信されるコーデックのリストは, ローカル側が受信する意思があるものを示し, リモート側がサポートするコーデックのセットと交差すると, リモート側が送信すべきものを指定します。ただし, すべてのパラメータがこのルールに従うわけではありません; 一部のパラメータは宣言的であり, リモート側はそれらを完全に受け入れるか拒否する必要があります。このようなパラメータの例は, DTLS [RFC6347] のコンテキストで使用される TLS フィンガープリント [RFC8122] です; これらのフィンガープリントは提供されたローカル証明書に基づいて計算され, ネゴシエーションの対象ではありません。

さらに, さまざまな RFC が offer と answer の形式に異なる条件を課しています。例えば, offer は任意の数の "m=" セクション ([RFC4566] のセクション 5.14 で説明されているメディア記述) を提案できますが, answer は offer と正確に同じ数を含む必要があります。

最後に, 正確なメディアパラメータは offer と answer が交換された後にのみわかりますが, offerer は answer を受信する前に ICE チェックおよび場合によってはメディア (例えば, 接続が確立された後の re-offer の場合) を受信する可能性があります。この場合に着信メディアを適切に処理するには, offerer のメディアハンドラは answer が到着する前に offer の詳細を認識している必要があります。

したがって, セッション記述を適切に処理するために, JSEP 実装には以下が必要です:

  1. セッション記述がローカル側またはリモート側に関係するかどうかを知ること。

  2. セッション記述が offer か answer かを知ること。

  3. offer を answer とは独立して指定できるようにすること。

JSEP は, setLocalDescription と setRemoteDescription の両方のメソッドを追加し, セッション記述オブジェクトに提供されるセッション記述のタイプを示すタイプフィールドを含めることでこれに対処します。これにより, 最初に setLocalDescription(sdp [offer]) を呼び出し, 後で setRemoteDescription(sdp [answer]) を呼び出す offerer と, 最初に setRemoteDescription(sdp [offer]) を呼び出し, 後で setLocalDescription(sdp [answer]) を呼び出す answerer の両方について, 上記の要件が満たされます。

offer/answer 交換中, 未処理の offer は, 受け入れられるか拒否される可能性があるため, offerer と answerer で "pending" と見なされます。これが re-offer の場合, 各側には, 最後の offer/answer 交換の結果を反映する "current" ローカルおよびリモート記述もあります。セクション 4.1.14, 4.1.16, 4.1.13, および 4.1.15 は, pending および current 記述の詳細を提供します。

JSEP は, answer をアプリケーションによって暫定的として扱うことも許可します。暫定 answer は, answerer が初期セッションパラメータを offerer に伝達する方法を提供し, セッションを開始できるようにしながら, 後で最終 answer を指定できるようにします。最終 answer の概念は, offer/answer モデルにとって重要です; このような answer を受信すると, 正確なセッション構成がわかったので, 呼び出し側によって割り当てられた追加のリソースを解放できます。これらの "リソース" には, 追加の ICE コンポーネント, Traversal Using Relays around NAT (TURN) 候補, またはビデオデコーダなどが含まれます。一方, 暫定 answer はそのような解放を行いません; その結果, 独自のコーデック選択, トランスポートパラメータなどを持つ複数の異なる暫定 answer を, 呼セットアップ中に受信および適用できます。最終 answer 自体は, 受信した暫定 answer のいずれとも異なる場合があることに注意してください。

[RFC3264] では, シグナリングレベルでの制約は, 特定のセッションに対して未処理の offer は 1 つだけであることですが, JSEP レベルでは, 任意の時点で新しい offer を生成できます。例えば, シグナリングに SIP を使用する場合, 1 つの offer が送信され, その後 SIP CANCEL を使用してキャンセルされた場合, 最初の offer に対する answer が受信されていなくても, 別の offer を生成できます。これをサポートするために, JSEP メディア層は, JavaScript アプリケーションがシグナリングに必要なときはいつでも createOffer メソッドを介して offer を提供できます。answerer は, ゼロ個以上の暫定 answer を送信し, 最終的に最終 answer を送信することで offer/answer 交換を終了できます。これの状態機械は次のとおりです:

                    setRemote(OFFER)               setLocal(PRANSWER)
                        /-----\                               /-----\
                        |     |                               |     |
                        v     |                               v     |
         +---------------+    |                +---------------+    |
         |               |----/                |               |----/
         |  have-        | setLocal(PRANSWER)  | have-         |
         |  remote-offer |------------------- >| local-pranswer|
         |               |                     |               |
         |               |                     |               |
         +---------------+                     +---------------+
              ^   |                                   |
              |   | setLocal(ANSWER)                  |
setRemote(OFFER)  |                                   |
              |   V                  setLocal(ANSWER) |
         +---------------+                            |
         |               |                            |
         |               |<---------------------------+
         |    stable     |
         |               |<---------------------------+
         |               |                            |
         +---------------+          setRemote(ANSWER) |
              ^   |                                   |
              |   | setLocal(OFFER)                   |
setRemote(ANSWER) |                                   |
              |   V                                   |
         +---------------+                     +---------------+
         |               |                     |               |
         |  have-        | setRemote(PRANSWER) |have-          |
         |  local-offer  |------------------- >|remote-pranswer|
         |               |                     |               |
         |               |----\                |               |----\
         +---------------+    |                +---------------+    |
                        ^     |                               ^     |
                        |     |                               |     |
                        \-----/                               \-----/
                    setLocal(OFFER)               setRemote(PRANSWER)

                     Figure 2: JSEP State Machine

これらの状態遷移以外に, 暫定 ("pranswer") と最終 ("answer") answer の処理に違いはありません。

に最終更新