webrtc调试记录

Hill的日记

已于 2022-07-29 11:41:28 修改

阅读量1.1k

点赞数 1

分类专栏：笔记文章标签： webrtc

于 2022-07-29 10:52:20 首次发布

本文链接：https://blog.csdn.net/qq_41101870/article/details/126048822

版权

笔记专栏收录该内容

7 篇文章 0 订阅

订阅专栏

前言：本文记录的是本人在工作中对webrtc调试过程中对一些现象，并加入了自己的一些理解，并不能保证观点的正确性，只能作为参考帮助初学者学习并理解webrc的连接过程。

4.发起端连接成功之前就响应addstream事件

5.ice过程详解

一期记录

记录使用亚马逊sdk kvs连接和使用浏览器原生api连接的过程

1.webrtc连接流程大体为

1.端从信令服务器获取ice后选项

2.收集完成后将sdp发送给信令

3.信令发送给对等端

2.kvs的处理方式是

1.信令监听收集对等端ice候选项事件，收到后添加到rtcPeerConns实例上，rtcPeerConns.addIceCandidate(candidate)

2.rtcPeerConns实例监听icecandidate事件，如果需要实时发给对等端就通过信令实时发送过去，到最后没有新的candidate进来时表示收集完成，通过信令将sdp发送给对等端，如下图

3.浏览器原生api的处理方式

收到offer后创建answer，设置setRemoteDescription和setLocalDescription，然后rtcPeerConns实例通过监听onicegatheringstatechange事件来完成sdp的发送，如下图

说明：onicecandidate事件的触发，主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址，当收集到一个候选项对象时会触发一次。

以上方式在chrome和safiri上可以运行，但是在firefox上无效

分析原因：

现象:创建连接实例以后，firefox上的连接状态、收集状态没有改变，一直是初始值new

chrome上的实例：

firefox上的实例：

作为对比，看一下kvs在firefox上

kvs在firefox上的实例：

可以看到firfox上使用kvs连接ice收集状态是complete，而使用原生api连接自有stun服务器的状态是new。具体原因是什么，现在还不得而知，可能和stun服务器有关，对firefox发起的收集请求没有做响应。

4.webrtc连接流程详解

参考文章：https://www.jianshu.com/p/16e86e8fef1f

stun抓包内容说明：

抓包分析收集后选项

通过抓包记录一下同一个局域网和不同局域网下连接turn服务器的异同：

共同点：都会从turn服务器获得中继地址

不同点：

1.同一局域网下：

拿到offer里的候选项后逐个直接进行连通性检查（stun协议），如果互相连接成功则会忽略从turn服务器获取的中继地址，即不会设置到本地候选项中去，然后会周期性地发送心跳包保持连接。

2.不同局域网下：

拿到offer里的候选项后逐个直接进行连通性检查（stun协议），如果全部不通，则会对每个远程候选项地址创建自己的中继地址权限，然后继续进行连通性检查，获得连通响应后添加到本地候选项，直到建立连接成功，然后会周期性地发送心跳包保持连接。

候选项有四种：

host, srvflx, prflx, relay

参考：

https://blog.csdn.net/freeabc/article/details/108200557

https://zhuanlan.zhihu.com/p/25087606

抓包分析连接过程

chrome抓包（成功连接）：

请求后选项：

响应后选项：

记录sdp内容（如果不能连接成功可能是协商失败）

chrome连接：

Offer:

answer:

firefox连接：

Offer:

answer:

kvs在firefox：

Offer:

answer:

假如某览器不能正常出流，原因估计是两端视频支持的编解码方式不一致，如果出流设备只支持h264，而该浏览器只支持vp8，则会协商失败。

sdp字段释义参考：

https://www.cnblogs.com/chyingp/p/sdp-in-webrtc.html

https://webrtcforthecurious.com/zh/docs/02-signaling

https://www.cnblogs.com/ZY-Dream/p/13964263.html

safari和edge上的限制：

safari浏览器默认情况下需要开启媒体流才能进行ice候选项收集，因此要正常连接webrtc需要以下条件之一：

1.开启音频或者视频，并且加入轨道rtcPeerConns.addTrack(audioTrack, this.localStream);

2.手动停用浏览器限制：

edge浏览器如果不开启音频收集的本地ice候选项会不完整

记录ice连接状态

1.由于网络连接或者断开，ice连接状态在连接过程中会发生变化，当失败以后会导致rtcPeerConns连接状态变化，然后ice会自动重启协商。

3.连接大约十分钟后会断开连接

原因分析：

NAT映射到期、TURN服务器崩溃等原因会导致选定的候选地址对停止工作，ICE Agent将进入失败状态，然后重启iec Agent，重新执行收集候选项及后续操作。

二期记录

谷歌浏览器调试工具地址：chrome://webrtc-internals/

1.webrtc的连接流程

发起端生成offer，createOffer

发起端设置本地会话描述，setLocalDescription(offer)

响应端设置远程会话描述，setRemoteDescription(offer)

响应端生成answer，createAnswer

响应端设置本地会话描述，setLocalDescription(answer)

发起端设置远程会话描述，setRemoteDescription(answer)

2.关于收集依赖

通过多次观察webrtc连接过程中收集依赖到表现发现有以下现象：

1.发起offer的端往往会收集比较全的依赖，包括host、srflx，relay

2.响应answer的端往往只收集host

对比发现分析发现有以下规律：

signalingstatechange表示ice协商的状态，它的变化影响着是否继续收集依赖，当它的状态是stable（稳定）后就不再收集依赖。

对于响应端，setLocalDescriptionOnSuccess之后signalingstatechange就变为stable

对于发起端，setRemoteDescriptionOnSuccess之后signalingstatechange就变为stable

根据webrtc1.0规范：signalingstatechange的stable表示的是初始状态/或者协商完成状态。

参考：https://www.w3.org/TR/2021/REC-webrtc-20210126/#rtcsignalingstate-enum

总结原因：

发起端从setLocalDescriptionOnSuccess到setRemoteDescriptionOnSuccess的过程中一直在收集依赖，因此会收集的比较全面，而响应端收到offer以后马上创建answer，执行setLocalDescriptionOnSuccess才开始收集，如果协商成功，立即进行连通性检查，如果检查失败则会继续收集，如果成功就会直接连接停止继续收集。