3.5.3. ICE Candidate Policy (ICE 候補ポリシー)

3.5.3. ICE Candidate Policy (ICE 候補ポリシー)

通常, ICE 候補を収集する際, JSEP 実装はすべての可能な形式の初期候補 (ホスト候補, サーバー反射候補, リレー候補) を収集します。ただし, プライバシーや関連する懸念により, 特定のケースでは, アプリケーションが収集プロセスをより具体的に制御したい場合があります。たとえば, できるだけ少ない位置情報を漏らすために, リレー候補のみを使用したい場合があります (この選択には対応する運用コストが伴うことに留意してください)。これを実現するために, JSEP はアプリケーションがセッションで使用される ICE 候補を制限できるようにします。このフィルタリングは, [RFC8828] で説明されているように, 実装がアプリケーションに許可される IP アドレスに関して実施することを選択する制限の上に適用されることに注意してください。

セッションがアクティブな間に使用される候補のタイプを変更したい場合もあります。主な例として, 呼び出し先が最初はリレー候補のみを使用して任意の呼び出し元への位置情報の漏洩を避けたいが, ユーザーが呼び出しを受けたいことを示した後, すべての候補を使用するように変更する (運用コストを下げるため) 場合があります。このシナリオでは, JSEP 実装は, 前述のローカルポリシーとの相互作用を条件として, セッション中に候補ポリシーを変更できるようにしなければなりません。

ICE 候補ポリシーを管理するために, JSEP 実装は各収集フェーズの開始時に現在の設定を決定します。次に, 収集フェーズ中, 実装は現在のポリシーによって許可されていない候補をアプリケーションに公開してはならず, それらを接続性チェックのソースとして使用したり, 他の ICE 候補の raddr/rport 属性などの他のフィールドを介して間接的に公開したりしてはなりません。後で, アプリケーションが異なるポリシーを指定した場合, アプリケーションは ICE 再起動を介して新しい収集フェーズを開始することでそれを適用できます。