椛茶的博客

这种技术就是 simulcast，也就是大小流。而且网络是在波动的，某个用户可能一段时间内网络很好，足以接收质量最佳的流，但过一段时间可能网络变差了，SFU 要快速探测出用户下行可用带宽的的变化，切换给用户发送的视频流。在多人音视频会议中，不同用户的下行网络质量是不同的，假设 A 发送的视频编码码率是 1.5Mbps，经过 SFU 转发时，接收者 B 的网络较好，能够正常接收播放，而接收者 C 的下行网络带宽较小，SFU 将视频流发送给 C 时会出现丢包等问题，导致 C 观看 A 的视频流很卡顿。

ICE 是一种交互式连接建立的流程协议，ICE 有两种类型（Full ICE 和 Lite ICE），Full ICE 要求建立连接的双方都要执行连通性检测，而 Lite ICE 则只要求响应 STUN binding request 信息即可，它不需要添加候选者并对候选者进行连通性检测。媒体服务器一般都使用的是 Lite ICE 实现，因为媒体服务器通常部署在公网，它的网络没有限制，因此一般只需要客户端检测与媒体服务器提供的候选者地址是连通的即可。

mediasoup 支持多种类型的 Transport，有 WebRtcTransport，PlainTransport 以及 PipeTransport，对于 WebRtcTransport 目前 mediasoup 最新版本已经支持多个 WebRtcTransport 共用单个端口的模式了，而在此之前每个 WebRtcTransport 都需要使用一个端口，对于 PlainTransport 和 PipeTransport 现在还是每个通道需要对应一个端口。

安装 nodejs，npm，尽量使用较新的 nodejs 版本，最好 >= node 18安装 gulp：sudo npm install -g gulp-cli安装 build-essential：sudo apt install build-essential。

在我们介绍了如何使用 mediasoup-demo 搭建多人音视频聊天室，本文将介绍 mediasoup-demo 的启动流程以及信令交互流程。mediasoup-demo 项目组成主要包括两部分：app，server。app 目录存放客户端代码，主要包含了前端页面以及加入房间、退出房间、闭麦等与服务端的信令交互处理。server 目录存放了服务端代码，主要负责启动 mediasoup 媒体进程、创建 websocket 监听信令消息并处理。

Worker：mediasoup 流媒体处理进程Router：路由对象，类似于房间的功能，保存了流之间的订阅关系，它接收 Producer 的数据并转发给订阅该 Producer 的 ConsumerProducer：音视频流生产者，一路音频就算一个单独的生产者，一路视频也算一个单独的生产者Consumer：音视频流消费者Transport：传输通道，有 WebRtcTransport，PlainRtpTransport 以及 PipeTransport。

在一个音视频通话中，用户发送的音视频数据不一定只通过一个前端媒体服务器进行转发，有可能是 UserA 连接 ServerA，UserB 连接 ServerB，ServerA 与 ServerB 创建一条连接，UserA 发送的数据到达 ServerA 后由 ServerA 转发给 ServerB，ServerB 再发送给 UserB。mediasoup 提供了 PipeTransport 的方式实现服务器级联（数据从一个 Router 转发到另一个 Router）。

在音视频通话中，我们常常使用 RTP 协议包荷载音视频数据，底层经常使用 UDP 作为其传输层协议，而 UDP 并不保证数据可靠性，因此当 RTP 产生丢包时，接收端需要告知源端哪些序号的包认为丢失了，请重传一遍过来。

使用 mediasoup 进行音视频通话时，客户端可以显示当前正在说话的用户，该功能是由 Speaker 端在发送音频 RTP 数据时携带这段音频音量值大小，mediasoup 从 RTP 包获取该信息后回调给 mediasoup-demo（音频值大小通常是计算一段时间的平均值），如果音量值大于设定的阈值则会通过 activeSpeaker 通知音频接收端当前用户正在讲话，音频接收客户端接收到该信令后做展示。

在这篇博客中我们介绍了，关键信令包括 getRouterRtpCapabilites，join, createWebRtcTransport, connectWebRtcTransport, produce，本文将介绍 createWebRtcTransport 和 connectRtcTransport 的流程。