WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档
  • WebRTC音频处理
  • WebRTC-Mediasoup
  • FFMpeg音视频处理
  • H264编解码基础
  • openCV相关

WebRTC - ICE 过程简述

2021-07-06 14:38:29

1. ICE介绍

1.1.ICE 的角色
分为 controlling和controlled。

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

1.2.ICE的模式
分为FULL ICE和Lite ICE:

FULL ICE:是双方都要进行连通性检查,完成的走一遍流程。

Lite ICE: 在FULL ICE和Lite ICE互通时,只需要FULL ICE一方进行连通性检查, Lite一方只需回应response消息。这种模式对于部署在公网的设备比较常用。

1.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 是自身。

1.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.5.Checklist
由candidate pair生成按优先级排序的链表,用于ICE连通性检查。

1.6.Validlist
由连通性检查成功的candidate pair按优先级排序的链表,用于ICE提名和选择最终路径。

2.ICE过程


2.1.Gather candidates
根据Componet ID:

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

2.2.删除重复的candidate
收集地址完成后,需要去掉重复的candidate,如果两个candidate的地址一样,并且Base地址也一样,则删除它。

2.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

2.4. 生成candidate pairs
在本端收到远端candidates后,将Component ID和transport protocol相同的candidates组成pair。

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

对端也是同样的流程。

2.5.生成checklist
将candidate pairs按照优先级排序,生成checklist,供连通性检查使用。

2.6.连通性检查
Ordinary checks 两端都按照各自checklist分别进行检查。

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

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

2.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。

2.8.生成validlist
将连通性检查成功的candidate pair并按优先级排序加入validlist,这时本地candidate填写的是公网映射地址,remote candidate填写的是对端发送的STUN binding request地址。

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

提名方式又分为普通提名和进取型提名

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

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

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

3.ICE状态
Waiting:还未开始连通性检查,从checklist中选择合适优先级的pair进行检查
In-Progress:连通性检查已经开始,但还未结束
Succeeded:该pair 连通性检查已经完成并且成功
Failed:失败
Frozen:连通性检查还未开始 

4.ICE保活
对于每个ICE通道,都需要为其会话进行保活。
采用STUN binding request或者STUN binding indication。
如果没有收到响应,则会重传,直到最大重传次数。
5.ICE角色冲突解决
当两端角色都为controlling或者controlled角色冲突时,在连通性检查阶段,要求发送binding request消息里必须要带上tie-breaker属性。
当出现冲突时,比较tie-breaker大小,值比较大的则被认为是controlling,同时回应487错误给对端,对端收到487错误后切换角色。
6.结束语
随着WebRTC的应用越来越普遍,无论是Native端还是Web端,由于广泛的适应 能力以及对未来网络的支持,ICE作为一种综合的解决方案将有着非常广阔的应用前景。

另外附上一篇非常详尽的webrtc P2P相关的博文:
https://blog.csdn.net/xiaomucgwlmx/article/details/103217870?utm_medium=distribute.pc_relevant_t0.none-task-blog-OPENSEARCH-1.channel_param&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-OPENSEARCH-1.channel_param

原文链接:https://blog.csdn.net/paradox_1_0/article/details/109146458

By:rasp | WebRTC概念与基础 |

  • 分类目录

    • WebRTC概念与基础 (252)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (19)
    • WebRTC服务端开发 (27)
    • WebRTC网络与通信 (43)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
    • WebRTC音频处理 (6)
    • WebRTC-Mediasoup (2)
    • FFMpeg音视频处理 (3)
    • H264编解码基础 (10)
    • openCV相关 (1)
  • 最新文章

    • TensorFlow 中的通信机制 ——Rendezvous(二)gRPC 传输
    • 详解|SRT编码器中Rendezvous模式详解
    • 完整SIP/SDP媒体协商概论-ICE初始offer发送详解
    • 完整SIP/SDP媒体协商概论-ICE初始offer发送详解
    • WebRTC - ICE 过程简述
    • Webrtc delay-base-bwe代码分析(2): InterArrival模块
    • 从janus中学习webrtc的ice简单交换过程
    • WebRTC PeerConnection 建立连接过程介绍
    • P2P技术详解(三):P2P技术之STUN、TURN、ICE详解(转载)
    • WebRTC ICE 状态与提名处理
    • licode服务端总结
    • libnice调用流程分析
    • libnice调用流程分析
    • licode 学习总结
    • Licode—基于webrtc的SFU/MCU实现
    • ncnn_example
    • opencv-rtsp运动检测
    • WebRTC 基于GCC的拥塞控制(上)
    • WebRTC 基于GCC的拥塞控制(下)
    • LearningWebRTC: 拥塞控制LearningWebRTC: 拥塞控制
    • WebRTC入门(三)---- 目录结构
    • WebRTC之带宽控制部分学习(1) ------基本demo的介绍
    • webrtc视频流程
    • webrtc nack实现原理
    • webrtc QOS方法一(NACK实现)
    • webrtc源码之nack&&rtx详解
    • webrtc的rtp重传代码分析
    • webrtc QOS方法一(NACK实现)
    • WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)
    • WebRTC中丢包重传NACK实现分析
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.