前言

ICE全称Interactive Connectivity Establishment：交互式连通建设形式。

ICE参照RFC5245倡议实现，是一组基于offer/answer模式解决NAT穿梭的协定汇合。
它综合利用现有的STUN，TURN等协定，以更无效的形式来建设会话。

客户端侧无需关怀所处网络的地位以及NAT类型，并且可能动静的发现最优的传输门路。

webrtc·1.04

Classic STUN（RFC3489）的劣势

Classic STUN 有着诸多局限性，例如:

  1. 不能确定取得的公网映射地址是否用于P2P通信
  2. 没有加密办法
  3. 不反对TCP穿梭
  4. 不反对对称型NAT的穿梭
  5. 不反对IPV6

STUN（RFC5389）协定

RFC5389是RFC3489的升级版

  1. 反对UDP/TCP/TLS协定
  2. 反对平安认证

ICE利用STUN（RFC5389） Binding Request和Response，来获取公网映射地址和进行连通性查看。同时扩大了STUN的相干属性:

  1. PRIORITY:在计算candidate pair优先级中应用
  2. USE-CANDIDATE:ICE提名时应用
  3. tie-breaker:在角色冲突时应用

TURN协定

ICE应用TURN（RFC 5766）协定作为STUN的辅助，在点对点穿梭失败的状况下，借助于TURN服务的转发性能，来实现互通。端口与STUN保持一致

TURN音讯都遵循 STUN 的音讯格局，除了ChannelData音讯。

  1. 反对UDP/TCP/TLS协定，实用于UDP被限度的网络。
  2. 反对IPV6。

TURN的流程:

  • 创立Allocation：

client 应用allocation transaction创立relay 端口，并在allocation的响应中回复给client。

当allocation创立后须要应用refresh request来保活，默认lifetime为10分钟。

  • 创立Permission：

由allocation创立Permission，每个Permission 由 IP 地址 和lifetime组成。

有两种办法来创立和刷新Permission

  1. CreatePermission
  2. ChannelBind
  • 收发数据：
  1. CreatePermission应用Send and Data indication音讯
  2. ChannelBind应用ChannelData音讯

ICE介绍

  1. ICE 的角色

分为 controlling和controlled。

Offer 一方为controlling角色，answer一方为controlled角色。

2. ICE的模式

分为FULL ICE和Lite ICE：

FULL ICE:是单方都要进行连通性查看，实现的走一遍流程。

Lite ICE: 在FULL ICE和Lite ICE互通时，只须要FULL ICE一方进行连通性查看， Lite一方只需回应response音讯。这种模式对于部署在公网的设施比拟罕用。

3. Candidate

媒体传输的候选地址，组成candidate pair做连通性查看，确定传输门路，有如下属性：

  • Type 类型有：

Host/Srvflx/Relay/Prflx

  • Componet ID

传输媒体的类型,1代表RTP;2代表 RTCP。

WebRTC采纳Rtcp-mux形式，也就是RTP和RTCP在同一通道内传输，缩小ICE的协商和通道的保活。

  • Priority

Candidate的优先级。

如果思考延时，带宽资源，丢包的因素，Type优先级高下个别倡议如下程序：

host > srvflx > prflx > relay

  • Base

是指candidate 的根底地址。

Srvflx address 的base 是本地host address。

host address和 relayed address 的base 是本身。

4. Candidate pair

由本端和远端candidate组成的pair，有本人的优先级。

pair优先级的计算是取决candidate的priority。

priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

G:controlling candidate 优先级

D:controlled candidate 优先级

ICE抉择高优先级的candidate pair。

  1. Checklist

由candidate pair生成按优先级排序的链表,用于ICE连通性查看。

6. Validlist

由连通性查看胜利的candidate pair按优先级排序的链表,用于ICE提名和抉择最终门路。

ICE过程

  1. Gather candidates

依据Componet ID:

  • 获取本机host address.
  • 从STUN服务器获取 srvflx address.
  • 从TURN服务器获取 relay address.
  • 同时生成foundation。

2. 删除反复的candidate

收集地址实现后，须要去掉反复的candidate，如果两个candidate的地址一样，并且Base地址也一样，则删除它。

3. 替换candidates

ICE 应用offer/answer形式，单方通过SDP协商替换candidate信息.

Candidate信息包含type,foundation,base,component id,transport

SDP a行格局如下:

“a=candidate:1 1 UDP 9654321 212.223.223.223 12345 typ srflx raddr 10.216.33.9 rport 54321”

示意 foundation为1，媒体是RTP，采纳UDP协定，公网映射地址为212.223.223.223:12345，优先级为9654321，type为srflx，base地址为10.216.33.9:54321

4. 生成candidate pairs

在本端收到远端candidates后，将Component ID和transport protocol雷同的candidates组成pair。

修整candidate pair，如果是srvflx地址，则须要用其base地址替换。

对端也是同样的流程。

5. 生成checklist

将candidate pairs依照优先级排序，生成checklist，供连通性查看应用。

6. 连通性查看

Ordinary checks 两端都依照各自checklist别离进行查看。

Triggered checks 收到对端的查看时，也在对应的candidate pair上发动连通性查看，以提高效率

如果checklist里有relay candidate，则必须首先为relay candidate创立permission。

7. 发送连通性查看申请

ICE 应用STUN binding request/response，蕴含Fingerprint测验校验机制。

如果A收到B的response，则代表连通性查看胜利，否则须要进行重传直到超 时。

在建设连贯时，如果没有响应，则会以RTO工夫进行重传，每次翻倍，直到最大重传次数。

STUN申请 采纳STUN short-term credential形式认证，

STUN USERNAME属性 ”RemoteUsername：localUsername”

两端在SDP协商时替换ice-pwd和ice-ufrag，以得对端用户名和明码。

STUN 查看申请中须要查看地址的对称性，申请的源地址是响应的目标地址，申请的目标地址是响应的源地址，否则都设置状态为 Failed。

8. 生成validlist

将连通性查看胜利的candidate pair并按优先级排序退出validlist，这时本地candidate填写的是公网映射地址，remote candidate填写的是对端发送的STUN binding request地址。

9. 提名candidate pair

由controlling来提名哪对candidate pair为valid pair

提名形式又分为一般提名和进取型提名

一般提名形式会做两次连通性查看，在第一次做连通性查看时不会带上USE-CANDIDATE属性，而是在生成的validlist里抉择pair再进行一次连通性查看，这时会带上USE-CANDIDATE属性，并且置位nominated flag。

进取型形式则是每次发送连通性查看时都会带上USE-CANDIDATE属性，并且置位nominated flag，不会再去做第二次连通性查看。

10. 抉择最终传输地址

ICE在提名的valid pair里抉择优先级最高那对作为本次ICE流程传输地址。

ICE状态

  1. Waiting：还未开始连通性查看，从checklist中抉择适合优先级的pair进行查看
  2. In-Progress：连通性查看曾经开始，但还未完结
  3. Succeeded：该pair 连通性查看曾经实现并且胜利
  4. Failed：失败
  5. Frozen：连通性查看还未开始

ICE保活

  1. 对于每个ICE通道，都须要为其会话进行保活。
  2. 采纳STUN binding request或者STUN binding indication。
  3. 如果没有收到响应，则会重传，直到最大重传次数。

ICE角色冲突解决

  1. 当两端角色都为controlling或者controlled角色冲突时，在连通性查看阶段，要求发送binding request音讯里必须要带上tie-breaker属性。
  2. 当呈现抵触时，比拟tie-breaker大小，值比拟大的则被认为是controlling，同时回应487谬误给对端，对端收到487谬误后切换角色。

结束语

随着WebRTC的利用越来越广泛，无论是Native端还是Web端，因为宽泛的适应 能力以及对将来网络的反对，ICE作为一种综合的解决方案将有着非常广阔的利用前景。

网易云信翻译了W3C举荐规范WebRTC 1.0: Real-time CommunicationBetween Browsers，并提供《WebRTC1.0: 浏览器间实时通信》中文版收费下载。

  • 对于WebRTC初学者，本文档能够作为学习教程，帮忙你疾速对WebRTC有全面且具体的理解，学习相干API的应用，其附带的示例代码也是很好的学习材料；
  • 对于WebRTC资深开发者，本文档能够作为开发中的使用手册，依据所提供的函数调用链或是算法流程进行开发或bug定位；
  • 对于高阶玩家，也可通过浏览本文档对WebRTC工作组反馈改良意见。

webrtc·1.04

限时收费下载，WebRTC开发者必备。