这实际上是一个初步的事实调查问题：过去我们一直在使用Zoom来促进我们的音频/视频会议(实际上是教师会议：1次学生会议(。现在，我们已经开发了自己的内部JavaScript客户端来做同样的事情。我们有一个刚刚测试过的原型。在这次测试中(一名老师和一名学生(，起初一切似乎都很顺利。然而，我们注意到，a(发送者和接收者之间的音频和视频曲目接收似乎比Zoom应用程序中的滞后更多，b(在短时间间隔(5-10分钟的会话持续时间(内，其中一方崩溃，需要另一次启动音频/视频会话(getUserMedia，然后是RTCPeerConnection协议功能和onicecandidate，需要ONGOTIATION和反馈到我们的信令服务器的控制回调(。很明显，由于这还处于原型阶段，会有一些错误需要修复，但我想知道Zoom这样的应用程序是否真的使用了与我们相同的webRTC协议和功能，或者它是否正在通过自己的内部库来解决预传输问题中涉及的一些相当复杂的问题，如编解码器和多媒体数据压缩，然后实际处理数据分组的udp传输。非常感谢任何对此有想法的人！
伊凡：非常感谢你的介绍——了解一下这个主题的背景知识很有用。我们知道webassembly，并在三年前使用它将.wav压缩为.mp3(尽管使用了预先构建的wasm模块(。
伊凡：非常感谢。是的，我们知道webassembly——实际上，我们在两年前做了一些工作，使用预先构建的wasm模块将.wav压缩为.mp3格式。移动设备不适用于我们的主应用程序。你所说的受限网络也很有用，但我们认为这里的主要问题是网络速度。我们对所有用户进行了快速检查，总的来说，他们分为两组，给出了3-14 Mbps和100-120 kbps的网络速度。总的来说，我们的用户是在家里使用Wifi路由器或连接手机的学生。Wifi路由器似乎一致地给出了Mps的范围，而那些连接到手机的路由器可以等于Mps的数字，但根据一天中的时间或数据信号的接近程度，可能会降至100-120 kbps甚至更低。我们怀疑，当可用带宽降至100 kbps以下时，发送视频/音频出现问题的人(我们发现，在这种情况下，发送者仍然可以看到和听到收到的视频，但他们的对手开始抱怨视频帧丢失——黑屏，然后没有音频(。有趣的是，Zoom应用程序似乎能更好地处理降级情况，但我们真的不知道为什么。这促使我问webRTC是否需要最小带宽，以及它如何计算发送器/接收器的比特率——我想计算后者将取决于前者，并考虑到网络摄像头的固有特性。有没有一种方法可以在考虑到这种降级情况的网络条件的情况下进行某种动态配置？
问这个问题的原因是试图在这些降级的情况下保持视频聊天(尽管比特率/分辨率/帧速率降低(。
如果你特别想知道Zoom web——是的，他们使用webrtc，但只是作为一种传输选项，不包括与媒体相关的内容。他们的编码/解码是基于WebAssembly的，他们在画布上绘制视频帧。有关更多详细信息，请参阅本文。
但我想你的问题更像是"；我可以只使用webrtc API制作一个生产就绪的会议吗">
我相信你可以，但有一些局限性。
- WebRTC在移动设备上有点不可预测，尤其是在iOS上。查看这篇文章以了解详细信息。去年，我个人在iOS上的webrtc调用非常糟糕，最终编写了一个本地客户端。希望随着时间的推移情况会好转
- 在某些受限制的网络中，webrtc流量可能会被阻止。这可能是Zoom在websocket上后退的原因
如果您打算录制会议或有很多参与者，可能需要一个媒体服务器。我建议你看看一些基于开源webrtc的会议应用程序，看看它是否适合你的需求：
- Jitsi会面
- Peercalls
- Janus视频室