4.1.1. Constructor (コンストラクタ)
4.1.1. Constructor (コンストラクタ)
PeerConnection コンストラクタを使用すると, アプリケーションは, 候補を収集するときに使用する STUN/TURN サーバーと資格情報, 初期 ICE 候補ポリシーとプールサイズ, 使用するバンドルポリシーなど, メディアセッションのグローバルパラメータを指定できます。
ICE 候補ポリシーが指定されている場合, それはセクション 3.5.3 で説明されているように機能し, JSEP 実装は許可された候補のみ (実装内部フィルタリングを含む) をアプリケーションに提供し, 接続チェックにはそれらの候補のみを使用します。使用可能なポリシーのセットは次のとおりです。
all: 実装ポリシーによって許可されたすべての候補が収集および使用されます。
relay: リレー候補以外のすべての候補がフィルタリングされます。これにより, 受信した候補からリモートピアが確認できる可能性のある位置情報が難読化されます。アプリケーションがリレーサーバーを展開および選択する方法によっては, 位置を都市レベルまたは場合によってはグローバルレベルまで難読化できる可能性があります。
デフォルトの ICE 候補ポリシーは "all" に設定しなければなりません。これは一般的に望ましいポリシーであり, また通常はアプリケーション TURN サーバーリソースの使用を大幅に削減します。
ICE 候補プールにサイズが指定されている場合, これは候補を事前に収集する ICE コンポーネントの数を示します。事前収集は潜在的に長期間にわたって STUN/TURN サーバーリソースを利用することになるため, これはアプリケーションのリクエストがあった場合にのみ発生しなければならず, したがってデフォルトの候補プールサイズはゼロでなければなりません。
アプリケーションは, [RFC8843] で定義されている多重化メカニズムであるバンドルの使用に関する優先ポリシーを指定できます。ポリシーに関係なく, アプリケーションは常にバンドルを単一のトランスポートにネゴシエートしようとし, すべての "m=" セクションにわたって単一のバンドルグループを提供します。この単一のトランスポートの使用は, アンサラーがバンドルを受け入れることに依存します。ただし, 以下のリストからポリシーを指定することにより, アプリケーションは, メディアストリームをどの程度積極的にバンドルしようとするかを正確に制御でき, これは非バンドル対応エンドポイントとの相互運用方法に影響します。非バンドル対応エンドポイントとネゴシエートする場合, バンドルのみとマークされていないストリームのみが確立されます。
使用可能なポリシーのセットは次のとおりです。
balanced: 各タイプ (オーディオ, ビデオ, またはアプリケーション) の最初の "m=" セクションにはトランスポートパラメータが含まれ, アンサラーがそのセクションをアンバンドルできるようになります。各タイプの 2 番目以降の "m=" セクションはバンドルのみとマークされます。その結果, N 個の異なるメディアタイプがある場合, N 個のメディアストリームに対して候補が収集されます。このポリシーは, 多重化の希望と, レガシーケースで基本的なオーディオとビデオを引き続きネゴシエートできるようにする必要性とのバランスをとります。アンサラーとして機能する場合, オファーにバンドルグループがない場合, 実装は各タイプの最初の "m=" セクション以外のすべてを拒否します。
max-compat: すべての "m=" セクションにトランスポートパラメータが含まれます。バンドルのみとマークされるものはありません。このポリシーでは, すべてのストリームを非バンドル対応エンドポイントで受信できますが, メディアストリームごとに個別の候補を収集する必要があります。
max-bundle: 最初の "m=" セクションのみにトランスポートパラメータが含まれます。最初以外のすべてのストリームはバンドルのみとマークされます。このポリシーは, 候補収集を最小限に抑え, 多重化を最大化することを目的としていますが, レガシーエンドポイントとの互換性は低くなります。アンサラーとして機能する場合, 実装は, その "m=" セクションと同じバンドルグループにない限り, 最初の "m=" セクション以外の "m=" セクションを拒否します。
パフォーマンスとレガシーエンドポイントとの互換性の間で最適なトレードオフを提供するため, デフォルトのバンドルポリシーは "balanced" に設定しなければなりません。
アプリケーションは, 次のポリシーのいずれかを使用して, RTP/RTCP 多重化 [RFC5761] の使用に関する優先ポリシーを指定できます。
negotiate: JSEP 実装は RTP と RTCP の両方の候補を収集しますが, "a=rtcp-mux" も提供するため, 多重化エンドポイントまたは非多重化エンドポイントのいずれとも互換性があります。
require: JSEP 実装は RTP 候補のみを収集し, 生成するオファーの新しい "m=" セクションに "a=rtcp-mux-only" 指示を挿入します。これにより, オファラーが収集する必要のある候補の数が半減します。"a=rtcp-mux" 属性を含まない "m=" セクションを含む記述を適用すると, エラーが返されます。
デフォルトの多重化ポリシーは "require" に設定しなければなりません。実装は, アプリケーションが多重化ポリシーを "negotiate" に設定しようとする試みを拒否することを選択してもかまいません。