webrtc的提供音视频解决方案是针对P2P的场景，如果在实际的应用中直接通过P2P来互通，首先NAT穿越就很麻烦，如果NAT场景比较复杂，整个互通流程就会变长，直接的影响就是首屏会出来的慢。所以一般的会有一个webrtc接入服务来实现对web的接入，第一个是解决NAT穿越的问题，第二个是实现与具体的音视频业务的结合。

这篇文章先简要的介绍web互通的基本流程，webrtc接入的基本要求。再介绍ICE的核心流程，及webrtc接入服务的ICE。这里并不是详细介绍ICE流程，ICE有诸多细节，很难全面把握。但是其核心就那几点。再是webrtc接入服务上的ICE流程也更加简单。这里列出标准文档，STUN RFC5389，TURN RFC5766 就当作手册查询吧。

web 互通的基本流程

上图是web对通的基本流程，图中描述的是两个web进行点对点互通。涉及到角色有信令服务，STUN，TURN服务。STUN/TURN+NAT穿越流程即代表了ICE流程

webrtc协议

要实现webrtc的接入，首先需要实现webrtc协议，这里的协议指包括，会话建立协议，媒体流传输协议

本文福利，免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

会话建立协议

媒体协商

通过sdp进行媒体协商，webrtc对sdp协议进行了一些扩展，主要是为了满足媒体特性

ICE

通过ICE来进行NAT穿透及确定媒体流传输地址

DTLS

通过DTLS协议来保证安全性

流媒体传输协议

使用的是 RTP，SRTP协议

ICE

ICE用于NAT穿透，确定媒体流传输地址。这是音视频互通的第一步。包括如下四个流程

收集候选地址
产生offer/answer sdp，将候选地址携带在sdp中(通过Signal Server单独传输)
通过sdp中携带的候选者地址进行连通性测试
三个步骤是串行的，完成上一步骤才进行下一步

收集候选地址(Candiate)
互通的两端所在的网络拓扑可能包括如下几种：

在内网中(同一网段，或是跨网段)，通过内网地址互通
在NAT之后，通过本机NAT映射后的外网的IP和Port互通
需要通过relay服务器来互通
所以收集地址时，分别对应三种类型的Candiate地址

host 类型,即本机内网的 IP 和端口
srflx 类型,即本机 NAT 映射后的外网的 IP 和端口
relay 类型,即中继服务器的 IP 和端口
3种类型的Candiate优先级依次是host,srflx,relay。按这种优先级进行连通测试。

ICE流程

如下是 Web A和 Web B 互通前的ICE流程，首先是要获取Candiate，因为两个web端各自都不知道所在的网络拓扑，所以在获取Candiate时，必须拿到所有类型的地址，其中就有通过STUN，TURN服务器获取relay类型的地址。即使两个web在同一内网中也会走去拿STUN/TURN的地址，如果没有，直到超时为止。

分为三步：

1.收集candidates

获取本机host address

从STUN服务器获取srvflx address

从TURN服务器获取relay address

2.交换candidates

发起offer的一方称为主叫方，Web A为主叫方。在A获取到candidates后，会在offer携带。被叫方Web B收到offer，开始收集candiates，收集完后，在answer消息中携带。(sdp中的a=candidate属性行携带本端的candidates地址)

3.按优先级进行连通检查

先发起offer的一方，必须等到收到answer消息拿到对方地址后才开始进行连通测试。被叫方也是等到回了answer消息后才开始进行连通测试。双方相互通过stun中Binding request和Binding response 进行，发出的Bingding request，如果收到response，则代表连通性检查成功，否则需要进行重传直到超时，则认为不可连通。双方各自进行。

上面描述的是ICE的核心流程，可以看到整个过程是应答式的，发出请求，等到响应才会开始下一步，整个过程非常耗时。直接的现象就是首屏会很慢。

Trickle ICE 流程

webrtc标准中采用的是 Trickle ICE，是ICE的一种扩展。相比与Full ICE，收集Candiate地址与offer协商同时进行，所以在offer/answer 的sdp中不会携带候选地址(sdp中不再携带candidate属性行)。

一旦有获取candidate地址，会发送给对端(通过信令服务)，并且开始进行连通性测试，不再等所有类型的地址都收集完毕。

**其特点是一边进行offer协商，一边收集cadidate，一边进行连通测试 **，就是上了图中所示的三步流程是并行进行。

这里得注意，offer/answer不再携带candiate，就需要通过新增一条用于携带candiate的消息交互。

ice-ite

尽管有了Trickle ICE流程可以缩短ICE的时间。但它还是囊括了ICE的核心流程，只是步骤执行时机进行变换。ICE的流程可能还是会耗时较长。

为了进一步优化ICE的耗时，还有一个简化版本叫做ice-ite，它是直接将核心流程进行了简化:

只收集host candidate地址，本质就是获取本地地址，所以时间将大大缩短

不再进行连通测试。

但是它两个限制：

互通的两端必须有一端是Full ICE(包括Tricle ICE)

使用ice-ite的一端必须有public ip

ice-ite非常适用于webrtc接入服务，因为作为它通常是个服务程序，一般都会有固定的IP(内网或公网），下面web与webrtc接入服务(media server)基于ice-ite的互通的流程

流程图中media server是ice-ite 模式，web端是full ice(Trickle ICE)，在NAT后。media server端只收集Host类型的地址(包括内网地址和公网地址) 。流程包含如下几步：

SDP协商

ICE 候选地址确定，媒体服务器只收集host类型的地址

ICE连通性测试，ite ice端(服务端)不主动进行连通性测试，由full ice端(web端)发起

媒体流传输

这种模式下不再需要专门的stun服务器，web通过向media server发送stun binding request来确定自己的可用地址(IP和Port)，所以对ice-ite端也需支持stun binding消息。