浅述webrtc中的ICE流程

背景

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

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

web 互通的基本流程

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

webrtc协议

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

会话建立协议
  • 媒体协商

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

  • ICE

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

  • DTLS

通过DTLS协议来保证安全性

流媒体传输协议

使用的是 RTP,SRTP协议

ICE

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

  1. 收集候选地址
  2. 产生offer/answer sdp,将候选地址携带在sdp中(通过Signal Server单独传输)
  3. 通过sdp中携带的候选者地址进行连通性测试

三个步骤是串行的,完成上一步骤才进行下一步

收集候选地址(Candiate)

互通的两端所在的网络拓扑可能包括如下几种:

  1. 在内网中(同一网段,或是跨网段),通过内网地址互通
  2. 在NAT之后,通过本机NAT映射后的外网的IP和Port互通
  3. 需要通过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,它是直接将核心流程进行了简化:

  1. 只收集host candidate地址,本质就是获取本地地址,所以时间将大大缩短
  2. 不再进行连通测试。

但是它两个限制:

  1. 互通的两端必须有一端是Full ICE(包括Tricle ICE)
  2. 使用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类型的地址(包括内网地址和公网地址) 。流程包含如下几步:

  1. SDP协商
  2. ICE 候选地址确定,媒体服务器只收集host类型的地址
  3. ICE连通性测试,ite ice端(服务端)不主动进行连通性测试,由full ice端(web端)发起
  4. 媒体流传输

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

  • 5
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

mo4776

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值