16. Half Trickle (ハーフトリクル)

ハーフトリクルでは、開始者は、使用可能だが必ずしも完全ではない候補生成と共に初期ICE記述を送信します。これにより、ICE記述が通常のICE応答者によって処理できることが保証され、主に初期ICE記述を送信する前にTrickle ICEサポートを確認できない場合に使用することを目的としています。初期ICE記述はTrickle ICEサポートを示しているため、応答者は完全な候補生成よりも少ないもので応答し、その後残りをトリクルできます。ハーフトリクルの初期ICE記述には候補終了指示が含まれる場合がありますが、トリクルサポートが確認されれば、開始者は候補終了指示を送信する前に追加の候補をトリクルすることを選択できるため、これは必須ではありません。

ハーフトリクルメカニズムは、エージェントが事前にリモート側がTrickle ICEをサポートしているかどうかを確認する方法がない場合に使用できます。初期ICE記述には完全な候補生成が含まれているため、通常のICEエージェントによって処理できます。一方、Trickle ICE対応エージェントは、この仕様で定義されている最適化を使用できます。これにより、最初のケースではネゴシエーションの失敗を回避し、2番目のケースではTrickle ICEの約半分の利点を提供します。

ハーフトリクルの使用は、ICE記述の初期交換中にのみ必要です。両方の当事者が相手からICE記述を受信した後、それぞれはTrickle ICEサポートを確実に判断し、すべての後続の交換に使用できます(セクション15を参照)。

場合によっては、ハーフトリクルの使用は、ユーザーエクスペリエンスの観点から半分以上の改善をもたらす可能性があります。これは、エージェントが、ユーザーがまもなくインタラクションを開始することを示すユーザーインターフェースの兆候(例えば、キーボード上のアクティビティや電話が持ち上げられること)に基づいて候補の収集を開始する場合に発生する可能性があります。これは、エージェントが実際に候補情報を送信する必要がある前に、候補収集の一部またはすべてが完了する可能性があることを意味します。応答者が候補をトリクルできるため、両方のエージェントは接続性チェックを開始し、通常のICEよりも早く、場合によってはフルトリクルと同じくらい早くICE処理を完了できます。

ただし、そのような予測は常に可能であるとは限りません。たとえば、通信が中心的な機能ではない多目的ユーザーエージェントまたはWebRTC Webページ(例えば、主要機能に問題がある場合にサポートラインに電話する)では、通話の意図と他のユーザーアクティビティを区別する方法が必ずしもありません。このような場合、フルトリクルの使用が最も理想的なユーザーエクスペリエンスを提供する可能性が高いです。それでも、ハーフトリクルの使用は、応答者により良いエクスペリエンスを提供するため、通常のICEよりも改善されます。