音视频练习实现基于mediasoup的sfu多人通话优化监控思路和断线问题

基于mediasoup已经实现了一个支持多人语音通话的sfu项目,再次回顾,对已知的几个问题进行优化:

1.考虑收集客户端网络和系统相关状态。

2.考虑观察服务端网络相关状态。

3.基本的防护考虑,在ice断开的情况下,在客户端切换网络的场景下业务的处理。

====》借助ai做项目实践,这里的内容也略感空泛,但总归是自己梳理思路处理的过程,做笔记进行备份。

1.总结

本来考虑的是基于已有的sfu功能,如何统计网络状态,再探索到网络断开问题,尝试基于已有的项目进行优化的问题。

不关注内部详细细节,以自己宏观的角度上分析一下该项目交互流。

2.实践回顾

1.客户端监控信息统计功能

这里实际上是由本地发送端链路和用于接收远端流的接收链路,分别统计其信息,定时器按需进行显示和打印:

核心需要统计的信息如下:

复制代码
发送质量(我的推流状况)
  qualityLimit  → 我的编码器是否被限制
  RTT           → 我到服务器的延迟
  send.jitter   → 我发出去的抖动
  retransmitted → 我重传了多少包

接收质量(我收到的每一路流)
  lossRate      → 每路流各自的丢包率
  jitterBuf     → 每路流各自的缓冲延迟
  fps           → 每路流各自的帧率
  nackCount     → 每路流触发了多少次重传请求
  pliCount      → 每路流触发了多少次关键帧请求

2.服务端的信息监控统计

提供专门的http服务入口,用于支持获取服务端本地必要的一些监控信息。

比如:通过url获取到服务器的一些必要监控信息:http://XXX.XXX.XXX.XXX:8445/health (代码中提供了接口),可以用其他接口获取房间信息等自己期望的信息,这里可以考虑扩展为一个监控系统。

复制代码
{
  "status": "ok",
  "timestamp": "2026-03-06T15:09:44.130Z",
  "workers": [
    {
      "pid": 2102963,
      "cpuMs": 0,
      "memMB": 13
    },
    {
      "pid": 2102965,
      "cpuMs": 0,
      "memMB": 10
    }
  ],
  "totals": {
    "rooms": 1,
    "peers": 2,
    "producers": 2,
    "consumers": 2
  }
}

3.房间断线重连机制

服务端提供了一个wss入口,供客户端主动连接,是所有开始的入口。

基于该wss入口,客户端通过协议控制实现加入房间,媒体协商,以及ice协商,创建发送链路和接收链路(流媒体交互链路,基于ice,一个链路发送多个流,SSRC识别)。

所以这里的断线有两种:

​ 第一:网络原因,流媒体交互链路异常,需要ice重新建链。

​ 第二:客户端切换网络,直接和服务器wss的链路断开。

====》虽然网络断开,但是可以根据服务端wss信息以及本地内存已经保存的信息进行恢复,全是代码控制细节逻辑,不涉及技术。

====》切换网络,涉及本地和服务端房间管理资源的清理和重置逻辑稍多。

复制代码
断线期间不能丢的状态:

myPeerId    → 我是谁,rejoin 用
myRoomId    → 我在哪个房间,rejoin 用
device      → 编解码能力,已经协商好,可以复用
camStream   → 摄像头的 MediaStream,track 还活着
micStream   → 麦克风的 MediaStream,track 还活着
camOn       → 摄像头是否开启的状态
micOn       → 麦克风是否开启的状态
muted       → 是否静音
remotePeers → 断线前房间里有哪些人(rejoin 后会用服务端数据更新)

断线时主动清理的状态(无法复用):

sendTransport   → IP 变了,必须重建
recvTransport   → IP 变了,必须重建
camProducer     → Transport 销毁后自动失效
micProducer     → Transport 销毁后自动失效
consumers       → Transport 销毁后自动失效
pendingReqs     → WSS 断了,所有等待中的请求全部 reject
4:简单运行效果

测试观察过监控效果,以及断线重连等问题,都已经正常。

目标关注问题相关测试代码问题已经修改,测试已经通过:demo

相关推荐
RTC实战笔记9 天前
Android 实时音视频接入教程:媒体补充增强信息(SEI)
音视频·媒体·rtc
潜创微科技9 天前
HDMI1.3 无线传输芯片方案 空旷 150 米量产级音视频方案
音视频
VidDown9 天前
VidDown 工具站:免费、本地优先的开发者工具箱
javascript·编辑器·音视频·视频编解码·视频
换个昵称都难9 天前
音频格式之WAV
音视频
AI创界者9 天前
PilotTTS 一键整合包(Win/Mac):8G 显存畅跑,实测解锁情绪与副语言的精准控制
人工智能·macos·aigc·音视频
u152109648499 天前
S.S.Audio PRO A2音频隔离器
嵌入式硬件·音视频·实时音视频·视频编解码·视频
VidDown10 天前
显卡处理视频技术详解:从硬解码到 NVENC,GPU 如何让视频处理起飞?
javascript·编辑器·音视频·视频编解码·视频
EasyDSS10 天前
全能音视频平台/私有化音视频系统EasyDSS!直播/点播/会议/集群对讲一站式落地
音视频
Damon_X10 天前
车载音频复习
音视频
3DVisionary10 天前
告别数据中断:XTDIC-VG视频引伸计在金属疲劳测试中3个真实案例
人工智能·音视频·应用案例·xtdic-vg·视频引伸计·疲劳测试·实战复盘