概括
这文档描述的是ICE扩展，ICE循序渐进的发送或者接受候选列表，而不是等待候选列表交换完成才开始。通过这样配置，ICE在采集候选列表的时候同时进行连接检查，这样大大缩短了完成ICE过程的时间。
备忘录
。。。。。。。（略过）
版权通知
。。。。。。。（略过）
目录内容表格
1. 简介 … … … … … … … … . 3
2. 术语 … … … … … … … … . 4
3. 和标准的ICE不同之处 … … … … . . 4
4. 为支持Trickle ICE的探测 … … … … . . 5
5. 关系到Offer/Answer模式 … … … … 6
6. 发送初始描述 … … … … … 7
7. 接受初始描述 … … … … … 7
7.1. 应答初始描述 … … … 8
7.2. 生成检测列表并且开锁连接检测 … … … 8
8. 接受一个应答初始描述 … . . 9
9. 执行连接检测 … … … … … . 9
9.1. 检测列表和时间状态更新 … … … … 9
10. 学习和发送附加的本地候选 … … . 10
10.1. 宣布结束的候选者 … … … … … 12
11. 接受附加的远程候选 … … … … 12
12. ICE 到 Trickle ICE作出的结论 … … … . 12
13. 用non-Trickle ICE的互动实现 … … . 13
14. 实例流程 … … … … … … … … . 13
15. 安全考虑 … … … … … … . 13
16. 致谢 … … … … … … … . . 13
17. 引用 … … … … … … … … . . 14
17.1. 比较规范的引用 … … … … … … . 14
17.2. 有用的引用 … … … … … … 14
附录 A. 未解决的问题 … … … … … … … 15
附录 B. 从早期版本的修改 … … … … … … … 15
B.1. 个人提交草案的修改 -00 … … . 15
作者的地址 … … … … … … … … 15
1. 简介
ICE协议【RFC5245】描述了收集，候选者，优先排序的机制，选择默认的与远程一端交换配对信息，并将信息列入检测列表。
一旦以上操作完成，只有完成以上操作，参与者才能开始连接检测阶段，最终确定选出一对候选者做为会话连接。
然而上述序列具有一定的优势，关系到直接部署到实现和调试，证明相当繁琐。收集候选者或接受候选者通常用到stun【RFC5389】
服务器，发现upnp设备，分配relayed候选在turn【RFC5766】服务器。所有这些都可能很明显的延时时间，然而这些都可以并行执行，
它们仍然需要按照【RFC5245】的要求，但可能延时会很突出。以上所有必须通过远程代理服务器来完成。两个代理都会接下来进行连接
检测，只有这样才能准备好开始的流媒体。
所有以上操作会导致建立Session会话关系时间变长而且带来不好的用户体验。
此篇文档的目的是定义一个替代ICE操作模式的实现，所有起名字为”trickle ICE“，这也带来了候选者以增量进行交换方式。一旦启动Session会话
允许ICE代理交换主候选。一旦开始候选者的流可以用，媒体流的连接检测也将启动。
在第一交换候选者连接被确定的情况下，Trickle ICE允许减少Session会话建立时间，即使不这样，正在运行的候选者搜集两个代理，同时并行连接
检测允许减少ICE处理时间。
值得一提的是在引用IETF之前，trickle ICE 已经被包含在例如XMPP jingle[XEP-0176]规范之中，同时也已经在各种实现中使用和部署。
除了基本的trickle ICE外，此文档也描述如何发现对trickle ICE的支持，在建立和更新检查列表时如何修改常规的ICE处理。以及trickle ICE的实现应该如
何只实现[RFC5245]处理的代理进行交互操作。
该规范并没有定义trickle ICE使用具体的信号或媒体描述协议，与之相反[RFC5245]定义了对ICE wht SIP和SDP的用法。这样的用法必须在单独的文
件中指定。
2.术语
关键词“必须”，“不得”，“需要”，“应该”，“不”，这个“应该”，“不应该”，“推荐”，“可能”和“可选”文件将被解释为[RFC2119]中所述。
此文档利用的所有术语都来自ICE协议[RFC5245]。
Vanilla ICE: ICE协议的定义在[RFC5245]文档。
候选搜集：ICE代理用来获取本地的模块候选者。候选搜集使用不同的机制
发现当地候选者。其中一些通常会造成使用协议如STUN或TURN。
其他人也可以使用 [RFC5245]中未引用的技术。基于UPnP端口分配和XMPP Jingle中继节点[XEP-0278]之间
可能的例子。
ICE描述：ICE启动所需的一组参数。 这些参数包括ICE-ufrag，ice-pwd和其他属性
代理商需要在ICE会话开始时进行交换。 ICE描述通过信令传输。如果是
使用Offer / Answer语法的协议，它们始终是Offer其中的一部分也经常也是Answer的一部分。
3.和标准的ICE不同之处
ICE协议设计的非常灵活，能适用不同的网络环境。尽管ICE非常灵活，但[RFC5245]中的规范不会支持trickle ICE，其至少指出了一些重要原因。
[RFC5245]描述当ICE代理处于运行状态时，更新检查列表所需的条件和定时器状态。 这些交易完成后验证条件，其中之一规定：
如果每个组件的有效列表中没有一个对媒体流，检查列表的状态设置为失败。这可能是一个问题，导致ICE处理过早失败在一些场景中。
考虑以下情况：
o Alice和Bob都位于与网络不同的网络中地址转换（NAT）。Alice和Bob本人都有不同的地址，但两个网络使用相同的[RFC1918]块。
o Alice发送Bob候选者10.0.0.10也恰好对应于Bob网络上的现有主机。
o Bob创建一个仅由10.0.0.10组成的检查列表并启动检查。
o 这些检查在Bob的网络中到达主机10.0.0.10响应ICMP“端口不可达”错误和每[RFC5245] Bob将交易标记为失败。
检查列表只包含失败的候选者和有效列表为空。这导致媒体流和潜在的所有ICE处理失败。
一个类似的竞争条件发生，假如来自Alice初始Offer只包含候选者，则从任何一个Bob采集到的候选者都可以确定不可达的。
这将导致Bob的候选者只包含IPv4地址和他收到Alice是一个IPv6的第一候选者。
当一个non-trickle ICE实现发送一个offer到另一个trickle，其他潜在问题可能发生，考虑一下以下情况：
o Alice的客户端有一个non-trickle ICE实现
o Bob的客户端支持trickle ICE。
o Alice和Bob是在NAT之后，有着地址过滤[RFC4787]。
o Bob有两个STUN服务器，但其中一个目前无法访问，Bob的代理人收到Alice的offer后，马上就会开始连接检查。
它也将开始收集候选人由于无法访问的STUN服务器需要很长时间。 当Bob的answer已经准备就绪的时候，
并发送给Alice，Bob的连接检查可能会失败：直到Alice得到Bob的answer，Alice将不能够在NAT中启动连接检查和打洞。
NAT会将Bob的检查当成了未知端点过滤掉。
4.为支持Trickle ICE的探测
为了避免第3节中的问题，有一个十分重要的前提是：Session会话双方都支持Trickle ICE本规范。
这意味着Trickle协议的使用必须提供以下之一：
o 代理验证方式在支持Trickle ICE之前开始一个会话
o 以一种方式尝试Trickle ICE会话的过程，当被非支持代理人接收时，将可以顺利回退到vanilla ICE，或失败在预测的方法中
可以随后重新进行vanilla ICE会话。
上述的验证确切机制是本文档范围之外，而是应该有ICE信令协议来处理。
一些信令协议示例如何处理服务和功能发现包括：
o 服务发现[XEP-0030]和对于XMPP实体功能[XEP-0115]
o 指示SIP用户代理功能[RFC3840]
Trickle ICE的使用应该利用这些机制，并能提供可靠的指示。
在某些情况下，代理商可以选择只发送一个offer远程方将拒绝为无效，除非它支持Trickle ICE。例如像这样的例子：将是一个没有ICE候选人的
offer无效的默认地址（例如0.0.0.0）。
使用Trickle ICE必须定义一个方式表明支持Trickle ICE，以及明确表明在没有支持的Trickle ICE情况下回到Vanilla ICE。
5.关系到Offer/Answer模式
Vanilla ICE规范使用Offer / Answer模型交换所有ICE参数。 只使用几个信号连消息显然不再可行，续候选人供应并试图使合适候选人交换成为连续
提供/答复对显然是不实际的。 本规范因此放宽与Offer / Answer模型的关系将Trickle ICE信号分成两个阶段：初始ICE描述和随后更换候选人。
ICE处理开始，ICE描述包括会话Session和media-level参数。那些包括ice-ufrag和ice-pwd的属性，由于它们的性质，ICE描述在一个会话
session开始时和Trickle ICE 代理必需没有发送任何候选者的情况下进行交换。然而ICE描述可能伴随着第一个设置的候选者。
当使用trickle ICE通过 Offer／Answer 协议代理，必须包含一个初始的ICE描述在它们的Offers里，在这情况下Answers可以随时发送它们的ICE描述，
之后接受提供者信息，但不晚它们的答复，如果代理人在没有提供一个ICE的描述之前，那么它必须包含一个ICE描述。
在发送ICE描述之后，每个代理可以继续trickling候选者，而不管供应/答复协商的状态是什么。
6. 发送初始描述
一个代理一开始收集候选人，一旦有指示该通信即将到来（例如，用户界面提示或显式请求启动会话）。与vanilla ICE相反，trickle ICE的实现不
需要收集候选人，并且应该尽早生成和发送它们的初始ICE描述。
在使用Offer / Answer模型的协议的情况下，代理必须在对应offer中包括初始ICE描述。
Trickle ICE代理商可以在ICE描述中包括任何设置的候选者。这包括可能生成没有候选人的描述，或一个包含所有候选人的描述，以至于代理计划
使用以下会话。
为了最好性能，推荐ICE描述仅包含主要候选人。 这将允许两个代理启动收集服务器反射，中转等非主机候选人同时也可以使他们开始连接检查。
如果主机地址泄露是一个隐私问题，那么代理可能生成一个初始的ICE描述，这个描述不包括候选者，然后只是那些不泄漏主机地址的trickle 候选
者（例如中继的候选）。
在实际发送初始ICE描述之前，代理可以验证远程方是否支持Trickle ICE。 如果没有支持，确认代理商应该回到使用vanilla ICE或放弃整个会话。
所有Trickle ICE描述必须表示支持本规范。 提供此指示的确切语法用来定义信令协议如何使用Trickle ICE的用法。
计算优先级和基础，以及确定候选人的那些复杂的处理方式与vanilla ICE相同。
7. 接受初始描述
当代理接收到初始的ICE描述时，在这种情况下协议使用Offer / Answer这个描述将offer的一部分，它将检查它是否表示支持Trickle ICE
在第4节中解释。如果不是这样，代理必须根据[RFC5245]程序处理描述标准[RFC3264]处理，如果没有检测到ICE支持所有。
如果，描述确实表明支持涓流ICE，代理将决定其作用，开始收集和优先考虑候选人，而在这样做的时候也会通过发送自己的ICE来做出
回应描述，以便两个代理可以开始形成检查列表开始连接检查。
否则代理将简单地回退到vanilla ICE处理。
7.1. 应答初始描述
代理人可以随时响应初始的ICE描述收集候选人 正如ICE初步描述（第6节）一样，代理人不会发送任何候选人或所有计划使用的描述。
同样，与初始描述一样，建议对初始ICE描述的响应包含主机候选，使得远程方也可以开始形成检查表并执行连接性检查。
答案必须表示支持Trickle ICE，如所述使用规格。
对于使用Offer / Answer语法的协议，响应初始ICE描述将在之前传输[RFC3264]回答或作为其一部分。
7.2 形成检查列表并开始连接检查
交换说明后，一旦收集就可以了候选人，代理商将开始形成候选人对，计算他们的优先事项和根据香草制作检查单ICE程序在[RFC5245]
中描述。显然是为了候选人配对是可能的，这两者都是必要的描述包含候选人。如果这不是代理人的情况仍然会创建检查列表（以便它们
的Active / Frozen状态可以被监视和更新），但它们只会填充一次他们已经学到了任何本地和偏远的候选人
最初，所有检查列表将设置其“Active / Frozen”状态冻结。
Trickle ICE代理商也将尝试解冻检查列表用于第一媒体流（即，第一媒体流从使用应用程序报告给ICE实现）。如果该清单仍然空白，
但代理商将继续检查媒体流按照他们的报告顺序，并unfreeze第一个非空清单。
列表已被报告给ICE的顺序实现，或换句话说，流的顺序由信令协议（例如SDP）描述，检查相同的媒体流更有可能被执行同时
由两名代理人是有帮助的。
8.接收对初始ICE描述的响应
当收到答复时，代理商将遵循vanilla ICE步骤确定他们的角色，然后他们将形成检查单和开始连接检查，如第7.2节所述。
9.执行连通性检查
在大多数情况下，Trickle ICE代理执行连接检查遵循vanilla ICE步骤。 当然是候选人异步的特征在Trickle中收获的ICE将强加一些变化：
……..待续
14.实例流程
一种成功类型的 trickle ICE 交换 Offer/Answer，协议看下面的方法:
Alice Bob
| Offer+ICE Description |
|---------------------------------------------->|
| Additional Candidates |
|---------------------------------------------->|
| |
| Answer+ICE Description |
|<----------------------------------------------|
| Additional Candidates |
|<----------------------------------------------|
| |
| Additional Candidates and Connectivity Checks |
|<--------------------------------------------->|
| |
|<=============== MEDIA FLOWS =================>|
15. 安全考虑
[TODO]
16. Acknowledgements
略过
17. 引用
略过
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
