WebRTC Trickle ICE 策略

什么是Trickle ICE？

在实际使用的过程中，ICE技术存在一个问题，那就是呼叫建立连接很慢，这其中的原因是ICE协商的过程耗费了很多时间。客户端在发起呼叫时先会和STUN服务器通信，从STUN这里获取映射的候选者地址（srflx）和中继候选地址（relay），再加上本地候选者地址（host），构造三类ICE候选。

最后，再把这3类候选放入SDP的属性（a=*）中，完成这些后，才会把这个庞大的SDP一起包在Offer中发送出去。SDP中的Candidate如下图所示：

• 音频通道一套（3个候选）

• 视频通道一套（3个候选）

• 数据通道一套（3个候选）

一端收集完所有 IceCandidate 后通过Offer发送出去，另一段也一样等收集完 IceCandidate 再通过Answer发送回来，这一来一回，耗时很久。待双方都得到对端的Candidate后，通过 setLocalDescription() 和 setRemoteDescription() 启动地址配对，又要耗时一下。

那么，有什么办法可以缩短这些耗时呢？

这就诞生了“Trickle Ice”策略，即一边协商SDP一边收集 IceCandidate，也就是在Offer与Answer协商的过程中，双方都提前开始收集本地的候选者地址，通过这样的并发思想，大幅缩短了等待时间。

此时，Offer与Answer不再携带 IceCandidate，而是通过信令 ICE_CANDIDATE 另行发送。

Trickle ICE

在Trickle ICE协商过程中，Viewer作为Offer发送者，Master作为Offer接收者。

对于Viewer，TrickleIce的策略是每收到一次onIceCandidate就先放入缓存，直到收到Answer后，再将已收到Candidate的一个一个地发出去，如果此时尚未全部收集完毕又得到Candidate，可以直接发出去。

对于Master，需要先判断对端Viewer是否支持TickleIce，如果支持，则每收到一次Candidate就发送一次，不会缓存。如果不支持，按nonTrickleIce策略走。

 

non Trickle ICE 

在non Trickle ICE协商过程中，Viewer作为Offer发送者，Master作为Offer接收者。

对于Viewer，策略是将收到的OnIceCandidate都先繁缛缓存，直到全部获取完毕后再通过Offer一起发出去。

对于Master，需要等待Candidate都获取完毕后再发送Answer。