这篇文章对各种流行的WebRTC平台中的信令通道实现进行了快速回顾。它考察了信道使用的协议，消息如何被序列化，以及应用程序是否使用会话描述协议（SDP）作为网络上的不透明字符串，或者他们是否以自定义格式发送所需的参数。
为了提供各种平台，我在表中列出了流行的最终用户应用程序、云提供商和开源实现。如果你愿意，我很乐意将其他人添加到列表中。
它是如何测试的？
要对其进行测试，请加入一个房间并在 Chrome 开发人员工具中检查是否已建立 WebSocket 连接或正在发出定期 HTTP 请求。然后，检查这些连接和请求的消息，并检查格式是否为 Binary/JSON/XML。在二进制消息的情况下，很难看到内容，并且信息有可能被压缩/加密，并且内部有一些 JSON 或 SDP。
接下来，在这些消息中查看 SDP 描述中的典型信息，例如 ufrag、标头扩展和负载类型，并查看它们是如何发送的。
传输
大多数应用程序似乎都使用 WebSockets，但一些最大的应用程序使用 HTTP 轮询。这可能是由于历史原因，为了更好地处理具有受限网络或设备的特定用户，或者为了更快地对不稳定连接中的断开做出反应。
在 Google Meet 的情况下，除了现有的HTTP长轮询机制外，看起来还有一部分信令是通过数据通道进行的。
序列化
在使用 XMPP 的情况下，序列化格式介于二进制（最有效）、JSON（最简单）和 XML 之间。在网络上使用 JSON 的效率较低，但需要较少的库/运行时来在浏览器中处理它。Google Meet 使用的 ProtoJSON 方法看起来是一个很好的折中方案。
SDP 用法
大多数应用程序似乎不通过网络使用 SDP。相反，他们只发送所需的参数并将 SDP 作为客户端的实现细节保留。这稍微更有效并且为您提供了更大的灵活性，但如果你的所有端点都是基于 libwebrtc 的，那么添加这些转换就不那么直接了。
结论可能是 WebRTC 信令没有单一的正确解决方案，而是所有这些都可以很好地工作的不同替代方案。然而，两种最常见的方法似乎是使用 WebSockets 而不是通过网络发送 SDP，我个人对此感到非常高兴。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/25989.html
