16. Half Trickle (半渐进式)
🇨🇳 中文
在半渐进式 (half trickle) 中，发起方传达初始ICE描述时带有可用但不一定完整的候选地址生成。这确保ICE描述可以由常规ICE响应方处理，主要用于在传达初始ICE描述之前无法确认Trickle ICE支持的情况。初始ICE描述指示支持Trickle ICE，以便响应方可以以少于完整候选地址生成的内容响应，然后渐进式交换其余部分。半渐进式的初始ICE描述可以包含候选地址结束指示，但这不是强制性的，因为如果确认了渐进式支持，发起方可以选择在传达候选地址结束指示之前渐进式交换额外的候选地址。
半渐进式机制可用于代理无法提前验证远程方是否支持Trickle ICE的情况。由于初始ICE描述包含完整的候选地址生成，因此可以由常规ICE代理处理，同时仍允许Trickle ICE代理使用本规范中定义的优化。这可以防止在前一种情况下协商失败，同时在后一种情况下仍提供大约一半的Trickle ICE好处。
仅在ICE描述的初始交换期间需要使用半渐进式。在双方都从对等方接收到ICE描述后，它们各自可以可靠地确定Trickle ICE支持并将其用于所有后续交换（参见第15节）。
在某些情况下，在用户体验方面，使用半渐进式可能带来的改进不仅仅是一半。当代理根据用户即将发起交互的用户界面提示（例如键盘上的活动或电话摘机）开始收集候选地址时，可能会发生这种情况。这意味着在代理实际需要传达候选地址信息之前，可以完成部分或全部候选地址收集。由于响应方将能够渐进式交换候选地址，两个代理都将能够比常规ICE更早地开始连接性检查和完成ICE处理，甚至可能与完全渐进式一样早。
然而，这种预期并不总是可能的。例如，多用途用户代理或WebRTC网页，其中通信是非核心功能（例如，在主要功能出现问题时拨打支持热线），不一定有办法区分呼叫意图和其他用户活动。在这种情况下，使用完全渐进式最有可能产生理想的用户体验。即便如此，使用半渐进式也会比常规ICE有所改进，因为它会为响应方带来更好的体验。
🇬🇧 English
In half trickle, the initiator conveys the initial ICE description with a usable but not necessarily full generation of candidates. This ensures that the ICE description can be processed by a regular ICE responder and is mostly meant for use in cases where support for Trickle ICE cannot be confirmed prior to conveying the initial ICE description. The initial ICE description indicates support for Trickle ICE, so that the responder can respond with something less than a full generation of candidates and then trickle the rest. The initial ICE description for half trickle can contain an end-of-candidates indication, although this is not mandatory because if trickle support is confirmed, then the initiator can choose to trickle additional candidates before it conveys an end-of-candidates indication.
The half-trickle mechanism can be used in cases where there is no way for an agent to verify in advance whether a remote party supports Trickle ICE. Because the initial ICE description contains a full generation of candidates, it can thus be handled by a regular ICE agent, while still allowing a Trickle ICE agent to use the optimization defined in this specification. This prevents negotiation from failing in the former case while still giving roughly half the Trickle ICE benefits in the latter.
Use of half trickle is only necessary during an initial exchange of ICE descriptions. After both parties have received an ICE description from their peer, they can each reliably determine Trickle ICE support and use it for all subsequent exchanges (see Section 15).
In some instances, using half trickle might bring more than just half the improvement in terms of user experience. This can happen when an agent starts gathering candidates upon user-interface cues that the user will soon be initiating an interaction, such as activity on a keypad or the phone going off hook. This would mean that some or all of the candidate gathering could be completed before the agent actually needs to convey the candidate information. Because the responder will be able to trickle candidates, both agents will be able to start connectivity checks and complete ICE processing earlier than with regular ICE and potentially even as early as with full trickle.
However, such anticipation is not always possible. For example, a multipurpose user agent or a WebRTC web page where communication is a non-central feature (e.g., calling a support line in case of a problem with the main features) would not necessarily have a way of distinguishing between call intentions and other user activity. In such cases, using full trickle is most likely to result in an ideal user experience. Even so, using half trickle would be an improvement over regular ICE because it would result in a better experience for responders.
🇯🇵 日本語
ハーフトリクル (half trickle) では、イニシエーターは使用可能だが必ずしも完全ではない候補の生成を伴う初期ICE記述を伝達します。これにより、ICE記述が通常のICEレスポンダーによって処理できることが保証され、主に初期ICE記述を伝達する前にTrickle ICEのサポートを確認できない場合に使用されることを意図しています。初期ICE記述はTrickle ICEのサポートを示すため、レスポンダーは完全な候補生成よりも少ない内容で応答し、残りをトリクルすることができます。ハーフトリクルの初期ICE記述には候補終了指示を含めることができますが、トリクルサポートが確認された場合、イニシエーターは候補終了指示を伝達する前に追加の候補をトリクルすることを選択できるため、これは必須ではありません。
ハーフトリクルメカニズムは、エージェントがリモートパーティがTrickle ICEをサポートしているかどうかを事前に検証する方法がない場合に使用できます。初期ICE記述には完全な候補生成が含まれているため、通常のICEエージェントによって処理できる一方、Trickle ICEエージェントがこの仕様で定義された最適化を使用できます。これにより、前者の場合に交渉が失敗するのを防ぎながら、後者の場合にはTrickle ICEの利点の約半分を提供します。
ハーフトリクルの使用は、ICE記述の初期交換中にのみ必要です。双方がピアからICE記述を受信した後、それぞれがTrickle ICEサポートを確実に判断し、すべての後続の交換に使用できます（第15節を参照）。
場合によっては、ユーザーエクスペリエンスの観点から、ハーフトリクルの使用は半分以上の改善をもたらす可能性があります。これは、ユーザーがまもなく対話を開始するというユーザーインターフェースの合図（キーパッドでのアクティビティや電話が受話器から外れるなど）に基づいてエージェントが候補の収集を開始する場合に発生する可能性があります。これは、エージェントが実際に候補情報を伝達する必要がある前に、候補収集の一部または全部が完了する可能性があることを意味します。レスポンダーが候補をトリクルできるため、両方のエージェントは通常のICEよりも早く接続性チェックを開始してICE処理を完了でき、場合によっては完全トリクルと同じくらい早くなります。
ただし、このような予測が常に可能とは限りません。たとえば、多目的ユーザーエージェントまたは通信が非中心的機能であるWebRTCウェブページ（主要機能に問題がある場合にサポートラインに電話するなど）では、通話意図と他のユーザーアクティビティを区別する方法が必ずしもあるとは限りません。このような場合、完全トリクルを使用すると、理想的なユーザーエクスペリエンスが得られる可能性が最も高くなります。それでも、ハーフトリクルを使用すると、レスポンダーのエクスペリエンスが向上するため、通常のICEよりも改善されます。
🇫🇷 Français
Dans le half trickle, l'initiateur transmet la description ICE initiale avec une génération de candidats utilisable mais pas nécessairement complète. Cela garantit que la description ICE peut être traitée par un répondeur ICE régulier et est principalement destinée à être utilisée dans les cas où le support de Trickle ICE ne peut pas être confirmé avant de transmettre la description ICE initiale. La description ICE initiale indique le support de Trickle ICE, de sorte que le répondeur peut répondre avec quelque chose de moins qu'une génération complète de candidats, puis trickler le reste. La description ICE initiale pour half trickle peut contenir une indication de fin des candidats, bien que cela ne soit pas obligatoire car si le support de trickle est confirmé, l'initiateur peut choisir de trickler des candidats supplémentaires avant de transmettre une indication de fin des candidats.
Le mécanisme de half trickle peut être utilisé dans les cas où il n'y a aucun moyen pour un agent de vérifier à l'avance si une partie distante prend en charge Trickle ICE. Parce que la description ICE initiale contient une génération complète de candidats, elle peut donc être gérée par un agent ICE régulier, tout en permettant à un agent Trickle ICE d'utiliser l'optimisation définie dans cette spécification. Cela évite l'échec de la négociation dans le premier cas tout en donnant environ la moitié des avantages de Trickle ICE dans le second.
L'utilisation de half trickle n'est nécessaire que lors d'un échange initial de descriptions ICE. Après que les deux parties ont reçu une description ICE de leur pair, chacune peut déterminer de manière fiable le support de Trickle ICE et l'utiliser pour tous les échanges ultérieurs (voir Section 15).
Dans certains cas, l'utilisation de half trickle pourrait apporter plus que la moitié de l'amélioration en termes d'expérience utilisateur. Cela peut se produire lorsqu'un agent commence à collecter des candidats sur des indices d'interface utilisateur indiquant que l'utilisateur va bientôt initier une interaction, comme une activité sur un clavier ou le téléphone décrochant. Cela signifierait qu'une partie ou la totalité de la collecte de candidats pourrait être terminée avant que l'agent n'ait réellement besoin de transmettre les informations de candidat. Parce que le répondeur pourra trickler des candidats, les deux agents pourront commencer les vérifications de connectivité et terminer le traitement ICE plus tôt qu'avec l'ICE régulier et potentiellement même aussi tôt qu'avec le trickle complet.
Cependant, une telle anticipation n'est pas toujours possible. Par exemple, un agent utilisateur multifonction ou une page web WebRTC où la communication est une fonctionnalité non centrale (par exemple, appeler une ligne de support en cas de problème avec les fonctionnalités principales) n'aurait pas nécessairement un moyen de distinguer entre les intentions d'appel et d'autres activités utilisateur. Dans de tels cas, l'utilisation du trickle complet est la plus susceptible de donner une expérience utilisateur idéale. Même ainsi, l'utilisation de half trickle serait une amélioration par rapport à l'ICE régulier car elle donnerait une meilleure expérience pour les répondeurs.
🇩🇪 Deutsch
Bei Half Trickle übermittelt der Initiator die anfängliche ICE-Beschreibung mit einer verwendbaren, aber nicht unbedingt vollständigen Generation von Kandidaten. Dies stellt sicher, dass die ICE-Beschreibung von einem regulären ICE-Responder verarbeitet werden kann und ist hauptsächlich für Fälle gedacht, in denen die Unterstützung für Trickle ICE nicht bestätigt werden kann, bevor die anfängliche ICE-Beschreibung übermittelt wird. Die anfängliche ICE-Beschreibung zeigt Unterstützung für Trickle ICE an, sodass der Responder mit weniger als einer vollständigen Generation von Kandidaten antworten und dann den Rest tricklen kann. Die anfängliche ICE-Beschreibung für Half Trickle kann eine Ende-der-Kandidaten-Anzeige enthalten, obwohl dies nicht zwingend erforderlich ist, da der Initiator, wenn Trickle-Unterstützung bestätigt wird, wählen kann, zusätzliche Kandidaten zu tricklen, bevor er eine Ende-der-Kandidaten-Anzeige übermittelt.
Der Half-Trickle-Mechanismus kann in Fällen verwendet werden, in denen ein Agent keine Möglichkeit hat, im Voraus zu überprüfen, ob eine entfernte Partei Trickle ICE unterstützt. Da die anfängliche ICE-Beschreibung eine vollständige Generation von Kandidaten enthält, kann sie von einem regulären ICE-Agent behandelt werden, während einem Trickle-ICE-Agent weiterhin die in dieser Spezifikation definierte Optimierung ermöglicht wird. Dies verhindert, dass die Verhandlung im ersteren Fall fehlschlägt, während im letzteren Fall immer noch etwa die Hälfte der Trickle-ICE-Vorteile gewährt wird.
Die Verwendung von Half Trickle ist nur während eines anfänglichen Austauschs von ICE-Beschreibungen erforderlich. Nachdem beide Parteien eine ICE-Beschreibung von ihrem Peer erhalten haben, können sie jeweils zuverlässig die Trickle-ICE-Unterstützung bestimmen und sie für alle nachfolgenden Austausche verwenden (siehe Abschnitt 15).
In einigen Fällen kann die Verwendung von Half Trickle mehr als nur die Hälfte der Verbesserung in Bezug auf die Benutzererfahrung bringen. Dies kann passieren, wenn ein Agent beginnt, Kandidaten aufgrund von Benutzeroberflächenhinweisen zu sammeln, dass der Benutzer bald eine Interaktion initiieren wird, wie z. B. Aktivität auf einer Tastatur oder das Abnehmen des Telefons. Dies würde bedeuten, dass ein Teil oder die gesamte Kandidatensammlung abgeschlossen werden könnte, bevor der Agent die Kandidateninformationen tatsächlich übermitteln muss. Da der Responder Kandidaten tricklen kann, können beide Agenten Konnektivitätsprüfungen früher starten und die ICE-Verarbeitung früher als mit regulärem ICE abschließen und möglicherweise sogar so früh wie mit vollständigem Trickle.
Eine solche Antizipation ist jedoch nicht immer möglich. Zum Beispiel hätte ein Mehrzweck-User-Agent oder eine WebRTC-Webseite, bei der Kommunikation eine nicht zentrale Funktion ist (z. B. Anrufen einer Support-Hotline bei einem Problem mit den Hauptfunktionen), nicht unbedingt eine Möglichkeit, zwischen Anrufabsichten und anderen Benutzeraktivitäten zu unterscheiden. In solchen Fällen führt die Verwendung von vollständigem Trickle am ehesten zu einer idealen Benutzererfahrung. Dennoch wäre die Verwendung von Half Trickle eine Verbesserung gegenüber regulärem ICE, da sie zu einer besseren Erfahrung für Responder führen würde.
🇮🇹 Italiano
Nel half trickle, l'iniziatore trasmette la descrizione ICE iniziale con una generazione di candidati utilizzabile ma non necessariamente completa. Ciò garantisce che la descrizione ICE possa essere elaborata da un risponditore ICE regolare ed è principalmente destinata all'uso nei casi in cui il supporto per Trickle ICE non può essere confermato prima di trasmettere la descrizione ICE iniziale. La descrizione ICE iniziale indica il supporto per Trickle ICE, in modo che il risponditore possa rispondere con qualcosa di meno di una generazione completa di candidati e quindi trickle il resto. La descrizione ICE iniziale per half trickle può contenere un'indicazione di fine dei candidati, sebbene questo non sia obbligatorio perché se il supporto trickle è confermato, l'iniziatore può scegliere di trickle candidati aggiuntivi prima di trasmettere un'indicazione di fine dei candidati.
Il meccanismo di half trickle può essere utilizzato nei casi in cui non c'è modo per un agente di verificare in anticipo se una parte remota supporta Trickle ICE. Poiché la descrizione ICE iniziale contiene una generazione completa di candidati, può quindi essere gestita da un agente ICE regolare, consentendo comunque a un agente Trickle ICE di utilizzare l'ottimizzazione definita in questa specifica. Ciò impedisce il fallimento della negoziazione nel primo caso, fornendo comunque circa la metà dei vantaggi di Trickle ICE nel secondo.
L'uso di half trickle è necessario solo durante uno scambio iniziale di descrizioni ICE. Dopo che entrambe le parti hanno ricevuto una descrizione ICE dal loro peer, ciascuna può determinare in modo affidabile il supporto di Trickle ICE e utilizzarlo per tutti gli scambi successivi (vedere Sezione 15).
In alcuni casi, l'uso di half trickle potrebbe portare più di metà del miglioramento in termini di esperienza utente. Ciò può accadere quando un agente inizia a raccogliere candidati in base a segnali dell'interfaccia utente che indicano che l'utente sta per avviare un'interazione, come l'attività su una tastiera o il telefono che viene sollevato. Ciò significherebbe che parte o tutta la raccolta di candidati potrebbe essere completata prima che l'agente debba effettivamente trasmettere le informazioni sui candidati. Poiché il risponditore sarà in grado di trickle candidati, entrambi gli agenti saranno in grado di avviare i controlli di connettività e completare l'elaborazione ICE prima rispetto all'ICE regolare e potenzialmente anche presto come con il trickle completo.
Tuttavia, tale anticipazione non è sempre possibile. Ad esempio, un agente utente multiuso o una pagina web WebRTC in cui la comunicazione è una funzionalità non centrale (ad esempio, chiamare una linea di supporto in caso di problema con le funzionalità principali) non avrebbe necessariamente un modo per distinguere tra intenzioni di chiamata e altre attività utente. In tali casi, l'uso del trickle completo è più probabile che risulti in un'esperienza utente ideale. Anche così, l'uso di half trickle sarebbe un miglioramento rispetto all'ICE regolare perché risulterebbe in una migliore esperienza per i risponditori.