为啥不推荐MediaSoup作为工业WebRTC的SFU，今天来聊聊这个话题。

去年我在面试某个RTC开发的时候，面试者是做嵌入式视频RTC推流的，用的MediaSoup框架，我和他聊MediaSoup做工业RTCSFU的情况，发现很多MediaSoup做工业RTC SFU的问题。

视频链接：

这里给大家总结MediaSoup在这方面的不足。

工业WebRTC应用有哪些需求

1.快速推拉流

快速推流，快速拉流；

2.RTC客户端SDK需要小巧

客户端SDK需要小巧，推流主要设备为：嵌入式摄像头。SDK业务代码不能太复杂

3.支持WHIP标准推流

需要支持WHIP，方便标准接入。

MediaSoup SFU的特点。

MediaSoup是一个非常优秀的音视频会议SFU开源

1.高性能，高并发

支持多进程，异步单线程转发；

2. RTC QOS实现比较全面

NACK，PLI, GCC/TCC, Simulcast

3. 客户端提供SDK，方便接入视频会议模式

SDK方式提供Transport，producer，consumer的概念，封装ICE通道。

让小白能轻松使用。

但同时，MediaSoup有一些天生的不足。不善于作为工业WebRTC的SFU服务。

MediaSoup不足一：信令协商次数过多

客户端推流到SFU，协商信令有7个协商来回，也就是说需要在7个web socket承载的信令交互后，才能开始ICE和DTLS的协商。

这个协商来回是比较高！对于工业RTC推流，要求快速推流，或者拉流的需求来说，是不可接受的。

对比RTCPilot SFU开源。

开源地址：https://github.com/runner365/RTCPilot.git

我们以RTCPilot SFU为例，RTCPilot SFU开源的协商流程，只有两个来回，一个Join：加入房间；一个SDP exchange: 交换SDP信息。然后就可以开始基于UDP的ICE协商了。

RTCPilot SFU：一个支持跨平台，高性能，支持集群的WebRTC SFU开源。更多的内容，关注开源地址，和本博主的其他内容介绍。

支持SDP Exchange的SFU，一两个RTT来回就搞定信令交互流程。

缺点二：不支持WHIP推流

WHIP 的全名是 WebRTC-HTTP Ingestion Protocol（WebRTC HTTP 接入协议）。

MediaSoup是强制绑定独有的SDK及其流程逻辑：

MediaSoup不支持WHIP推流

只支持MediaSoup Broadcast独有的推流流程。

也就是无法支持OBS，FFMPEG的WHIP推流。更不支持嵌入式设备使用WHIP协议推流到MediaSoup SFU。

RTCPilot SFU：支持WHIP推流，且支持RTC集群

RTCPilot支持WHIP标准推流，且支持集群。

支持FFMPEG，OBS的WHIP推流。

且支持集群后，可以支持可扩展的RTC观看群体。

可以这么说，支持WHIP的RTC推流，才能接入大量的工业RTC摄像头，语音采集器等。

MediaSoup不支持SDP交互，只支持MediaSoup的SDK接入模式。

如果你想支持SDP交互方式，需要自己二次开发：整合/解析SDP与transport, prodce等操作流程.

总结：

MediaSoup是非常好的音视频会议系统SFU，不过MediaSoup没法做一个工业的SFU。至少没法直接做一个工业的SFU，需要复杂的二次开发

请选择：支持SDP交互的SFU；支持信令交互次数少；支持WHIP标准协议的SFU。