webrtc - Kurento WebRTC 连接在约 30% 的情况下失败

Question

我花了几天时间寻找连接问题，但没有运气。我正在尝试使用 Kurento 实现一个相对简单的 one2one 调用。

下面是Kurento的调试日志，其中包括可以建立连接和连接失败的情况。

如果您需要更多日志(例如客户端、信令服务器、tcpdump 或 Kurento 的跟踪日志，请告诉我，我会提供!)

非常感谢任何帮助或新的意见!

问题描述:

大约30%的情况下，无法建立WebRTC连接。不幸的是，当可以建立连接时，我缺乏任何类型的模式，而当不能建立连接时，它看起来完全是随机的。我在同一个网络中，使用相同的设备，使用相同的 TURN 服务器，使用相同的信令协议(protocol)，但在 30% 的情况下无法建立连接。

当我在本地运行该应用程序时，它似乎工作得更可靠，几乎 100% 的时间都可以建立连接(或者甚至可能是 100% 的时间，我已经测试了很多次，以至于我失去了踪迹)。我使用 docker 在本地设置基础设施，并在不同的网络中运行不同的容器(TURN、Kurento、Signalling)以模拟生产部署。

我们在开发和生产环境中经历了相同的行为。在我们的开发环境中，我们绝对没有防火墙，因此这似乎不是问题。

我尝试查找问题原因的方法:

大多数情况下，我一直在比较有效案例和无效案例的日志，但我未能发现它们之间有任何显着差异，可以指出问题所在。

我已经通过 TURN 服务器(使用 Firefox 和 force_relay 标志)和直接通过 Kurento 测试了 WebRTC 连接，但在这两种情况下，大约 30% 的情况下连接失败。

我已尝试过滤所有非 Relay 候选者的 ICE 候选者。

我嗅探了我们的信令服务器(也控制 Kurento)和 Kurento 之间的流量，以查看交换的 JSON RPS 消息中的任何差异，但它们看起来本质上是相同的。

我已经使用此工具测试了我们的 STUN 和 TURN 服务器:https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/我得到了看起来正确的服务器反射和中继候选者

我嗅探了成功和不成功连接的客户端的流量，但可以发现显着差异

我简化了 Kurento 媒体管道(无记录，无集线器)，但行为是相同的

我使用了不同的浏览器(Chrome、Firefox 和 native iOS 实现)，但行为是相同的

可以建立连接的情况的Kurento调试日志:

https://gist.github.com/omnibrain/2bc7ad54f626d278d3c8bac29767ac4c

无法建立连接的Kurento调试日志:

https://gist.github.com/omnibrain/f7caee04a5c6d77ea22a9ccfa95dd825

Answer 1

经过几天的调试和几乎疯狂的我们终于找到了问题的原因:

我们使用了 Socket.IO 的 Swift 客户端和 Socket.IO 的 Java Netty Socket.IO 服务器实现。客户端 (iOS) 使用长轮询与服务器 (Java) 进行通信。事实证明，Netty Socket.IO 服务器正在对 Swift Socket.IO 客户端的长轮询负载进行 URL 解码，但 Swift Socket.IO 客户端实际上并未对其进行 URL 编码。这意味着从 Swift Socket.IO 客户端发送的每个“+”都会在服务器上被替换为“”(空格)。为什么这是个问题？因为客户端的SDP报价包含ufrag，其中可以包含加号!因此，如果 SDP 包含“+”，则会在服务器上将其替换为空格，从而导致 STUN ping 失败，因为无法验证消息完整性。