3.8.2. Parallel Forking (並列フォーキング)

3.8.2. Parallel Forking (並列フォーキング)

並列フォーキングは, 呼び出しが複数のリモート被呼者に送信されることを含み, 各被呼者は呼び出しを受け入れることができ, 結果として複数の同時アクティブなシグナリングセッションが確立される可能性があります。複数の被呼者が同時にメディアを送信する場合, これを処理する可能性は [RFC3960] のセクション 3.1 で説明されています。今日のほとんどの SIP デバイスは, 一度に 1 つのデバイスとのメディア交換のみをサポートし, 複数の早期メディアオーディオソースを混合しようとはしません。これは混乱した状況を引き起こす可能性があるためです。たとえば, ヨーロッパのリングバックトーンと北米のリングバックトーンを混合することを考えてみてください -- 結果として得られる音はどちらのトーンとも異なり, ユーザーを混乱させるでしょう。シグナリングアプリケーションが一度に 1 つのリモートエンドポイントとのみメディアを交換したい場合, メディアエンジンの観点からは, これは順次フォーキングケースとまったく同じです。

JavaScript アプリケーションが複数のピアと同時にメディアを交換したい並列フォーキングケースでは, フローはやや複雑になりますが, JavaScript アプリケーションは [RFC3960] が説明する戦略に従うことができ, UPDATE を使用します。UPDATE アプローチにより, シグナリングは, メディアを交換したい各ピアに対して個別のメディアフローを設定できます。JSEP では, UPDATE で使用されるこの offer は, 単に新しい PeerConnection を作成し (セクション 4.1 を参照), 同じローカルメディアストリームがこの新しい PeerConnection に追加されていることを確認することで形成されます。次に, 新しい PeerConnection オブジェクトは, [RFC3960] で説明されている UPDATE 戦略を実行するためにシグナリングが使用できる SDP offer を生成します。

メディアストリームを共有した結果, アプリケーションは N 個の並列 PeerConnection セッションを持つことになり, それぞれにローカルおよびリモート記述と, 独自のローカルおよびリモートアドレスがあります。これらのセッションからのメディアフローは, setDirection を使用して管理できます (セクション 4.2.3 を参照)。または, アプリケーションは, すべてのセッションのメディアを混合して再生することを選択できます。もちろん, アプリケーションが単一のセッションのみを保持したい場合は, 不要になったセッションを単に終了できます。