为啥不推荐MediaSoup作为工业WebRTC的SFU

为啥不推荐MediaSoup作为工业WebRTC的SFU今天来聊聊这个话题。去年我在面试某个RTC开发的时候面试者是做嵌入式视频RTC推流的用的MediaSoup框架我和他聊MediaSoup做工业RTCSFU的情况发现很多MediaSoup做工业RTC SFU的问题。视频链接为啥不推荐MediaSoup作为工业WebRTC的SFU这里给大家总结MediaSoup在这方面的不足。工业WebRTC应用有哪些需求1.快速推拉流快速推流快速拉流2.RTC客户端SDK需要小巧客户端SDK需要小巧推流主要设备为嵌入式摄像头。SDK业务代码不能太复杂3.支持WHIP标准推流需要支持WHIP方便标准接入。MediaSoup SFU的特点。MediaSoup是一个非常优秀的音视频会议SFU开源1.高性能高并发支持多进程异步单线程转发2. RTC QOS实现比较全面NACKPLI, GCC/TCC, Simulcast3. 客户端提供SDK方便接入视频会议模式SDK方式提供Transportproducerconsumer的概念封装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 ProtocolWebRTC HTTP 接入协议。MediaSoup是强制绑定独有的SDK及其流程逻辑MediaSoup不支持WHIP推流只支持MediaSoup Broadcast独有的推流流程。也就是无法支持OBSFFMPEG的WHIP推流。更不支持嵌入式设备使用WHIP协议推流到MediaSoup SFU。RTCPilot SFU支持WHIP推流且支持RTC集群RTCPilot支持WHIP标准推流且支持集群。支持FFMPEGOBS的WHIP推流。且支持集群后可以支持可扩展的RTC观看群体。可以这么说支持WHIP的RTC推流才能接入大量的工业RTC摄像头语音采集器等。MediaSoup不支持SDP交互只支持MediaSoup的SDK接入模式。如果你想支持SDP交互方式需要自己二次开发整合/解析SDP与transport, prodce等操作流程.总结MediaSoup是非常好的音视频会议系统SFU不过MediaSoup没法做一个工业的SFU。至少没法直接做一个工业的SFU需要复杂的二次开发请选择支持SDP交互的SFU支持信令交互次数少支持WHIP标准协议的SFU。