基于 本文，在实现没有服务器的WebRTC方案时，我想应该是指SFU，瓶颈是只能4-6个参与者工作。
有没有一种解决方案可以解决这个问题？比如我只想用Firebase作为唯一的后台，主要是信令，没有SFU。在WebRTC中，要实现至少25-50人参与，一般的实现策略是什么？
更新一下。 这个 Github项目 分享了一个不同的说法。 它说："全网状的网状结构最多可以连接100个左右。"
你的MESH真正的瓶颈是每个RTCPeerConnection会在浏览器中自己做视频编码。
p2p的概念自然包括要求两个对等体应该根据网络条件调整编码质量。所以，当你的浏览器向对等体X(下载速度好)和Y(下载速度差)发送两个流时，X和Y的编码会有所不同--Y收到的帧率和比特率会比X低。
听起来很合理吧？但不幸的是，强制要求每个对等连接都要进行单独的视频编码。
如果多个对等连接可以重复使用相同的视频编码，那么MESH将更加可行。但谷歌在浏览器中并没有提供这个选项。Simulcast需要SFU，所以你的情况不是这样。
那么，对于720p 30 fps的视频，浏览器在一般的机器上能执行多少个并发视频编码呢？5-6个，不会更多。对于640x480 15 fps的视频？也许20个编码。
在我看来，在WebRTC设计中，编码层和网络层可以分开，甚至可以将getUserMedia扩展为getEncodedUserMedia，这样就可以将相同的编码内容发送给多个对等机。
所以这才是人们使用SFU进行多对等WebRTC的真正实际原因。
如果你想做一个25人的会议，所有的人都发送他们的视频，那么一个普通的Webrtc设置将无法工作。除非你大幅降低视频质量。原因是每个参与者都需要发送24个独立的视频流到每个其他客户端。因此，让我们说你的流是128 KBs，那么你将需要有3MBs的上传速度。这并不总是可用的。然后还需要下载相同数量的数据。
问题是这是不可扩展的。这就是为什么你需要一个SFU。那么你将只发送一个单一的流，并从其他人那里接收。关于SFU的另一个积极的事情是，你可以使用同步广播，它可以根据你的网络速度调整你的接收流的质量。
例如，你可以使用Janus网关或mediasoup。这里有一个已经设置好的mediasoup视频会议应用程序，是可扩展的。github仓库