Twilio WebRTC TURN 中继在几分钟后随机停止工作

Question

我正在使用 Twilio Network Traversal Service作为 native 应用程序的一部分，我是 working on执行对等远程桌面连接。我们实现了 WebRTC 协议(protocol)栈的一个子集，相当于 WebRTC 数据 channel (不是 WebRTC 视频和音频协议(protocol))。使用 TURN 中继时，TURN 分配似乎在 session 开始后几分钟到最多 12 分钟之间随机失效。这个问题看起来很像这个 one ，但建议的解决方法(发送静音音频)在我的情况下是 Not Acceptable ，因为我没有实现 WebRTC 音频/视频协议(protocol)。

在过去的两周里，我一直在关注这个问题，并将这个问题隔离为 Twilio 服务本身。为了进行比较，我使用了基于 web 的 WebRTC 数据 channel 演示，使用 firefox 和 Xirsys TURN server cloud .我有wireshark 捕获显示firefox 与Twilio 断开连接，就像我的 native 应用程序一样，而完全相同的firefox 演示在使用Xirsys 服务器时不会断开连接。

我最初使用的是 Xirsys，但我在他们的服务中遇到了一些不稳定的问题，这让我切换到 Twilio，这就是为什么我宁愿让 Twilio 解决这个问题，而不是回到 Xirsys。至少，我宁愿有两个我可以选择的 WebRTC 托管服务提供商，我知道它们应该可以正常工作。这就是为什么我要花时间详细解释这个问题，以便它可以得到解决。

这是两个使用 WebRTC 数据 channel 和 Twilio TURN 中继服务器显示 firefox 的 wireshark 捕获(过滤掉对等数据消息):




第一次捕获 4 分钟后，第二次捕获约 11 分钟后，流量停止中继。在这两个捕获中，firefox 检测到流量停止中继(在数据 channel 级别)并通过发送生命周期为零的刷新请求数据包尝试正常断开连接。两次正常断开连接都会导致 437 分配不匹配错误，表明服务器甚至不知道 firefox 正在尝试正常关闭的分配。

对于我的 native 应用程序，这通常采用 CreatePermission Request 消息的形式，该消息失败并出现 438“Wrong nonce”错误，这基本上是如果客户端尝试更新不再存在的分配的权限时应该发生的情况。错误代码 438 通常表示“Stale nonce”，这不是真正的错误，而是表明 nonce 已过期并且客户端应使用“error”消息中包含的新 nonce 再次尝试。我花了一段时间才弄清楚，但即使错误代码是438，错误字符串也不相同。我在 Xirsys 中观察到了一个真正的陈旧随机数错误，并使用错误响应中的新随机数成功更新了我的权限，所以我知道我可以在我的实现中正确处理这种情况。

这是我使用的 WebRTC 数据 channel 演示的源代码:
https://github.com/devolutions/webrtc-demo

为了进行比较，这里是使用 Xirsys TURN 服务器云的相同 firefox 数据 channel 演示:



在这个捕获中，我让演示运行了大约 16 分钟(它的工作时间比这长得多，我尝试过的最长时间是两个小时)。我们可以看到，在整个 session 期间，流量一直在中继，并且 Firefox 不断成功发送 CreatePermission 请求。最后，正常断开连接是由 Firefox 关闭 WebRTC 数据 channel 触发的(而不是因为流量不再被中继而被关闭)。与 Twilio 捕获相反，生命周期为零的刷新请求是成功的:Xirsys TURN 服务器仍然知道分配情况并按预期发回成功响应。

应该注意的是，ICMP 不可达错误是正常的，因为我认为在这种情况下，当响应回来时，firefox 不再监听给定的端口。换句话说，它发送生命周期为零的刷新请求，并且不等待答案返回。

目前，我别无选择，只能回到 Xirsys，但我真的很想修复 Twilio 网络穿越服务。如果您对此问题有更多疑问，请告诉我。

我已经上传了wireshark捕获here以供引用。

编辑:我修改了 webrtc 演示页面，这样当冰连接状态设置为“断开连接”时它不会关闭连接。现在，当冰连接状态变为“失败”时，我真正断开了连接。然而，它实际上并没有改变任何东西，因为在这种情况下，状态从“断开连接”到“失败”只需要几秒钟的时间。

由于我有新的相关屏幕截图和截图，我正在更新原始问题以澄清 Philipp Hancke 指出的某些问题:

首先，这里是一个新的捕获与冰连接状态修复(浏览器仅在状态变为“失败”时关闭连接):



有趣的是，这一次， session 持续了整整 18 分钟。这是在星期六早上拍摄的，所以我猜这个问题可能与 twilio 服务器上的当前工作负载有关。然而，它以完全相同的方式失败了，因为它对我来说总是如此。作为奖励，我们甚至有一个由 Firefox 正确处理的有效陈旧随机数响应。

但是，如果我们对同一捕获采取不同的观点，我们可以看到，在 Firefox 认为连接已断开并发送生命周期为零的刷新请求之前，流量停止中继 30 秒。与之前的捕获一样，服务器响应分配不匹配错误，表明它不知道 firefox 正在谈论哪个分配。



发送的最后八个数据包大小相同，所以我猜测它们是重传。重传 30 秒后，很可能 SCTP 认为传输已被丢弃。

关于生命周期为零的刷新请求，我做了一个测试，我很早就从浏览器关闭了连接。在这种情况下，服务器识别分配并返回成功响应:



分配不匹配是最容易观察到的症状，但在我对 native 应用程序的测试中，我看到了类似的错误，包括非零生命周期的刷新请求和 CreatePermission 请求(438“错误的随机数”错误)。但是，由于浏览器在数据未中继 30 秒后关闭连接，因此很难通过当前的 webrtc 演示观察到这些错误。如果我们可以将该超时更改为 10 分钟，我们也会看到这些错误。

Answer 1

很好的问题描述!

如果没有服务器日志，很难确定哪里出了问题。我尝试使用运行最新版本的 coturn 并显示与 Twilio 服务器相同的行为的出现的 TURN 服务器。 Xirsys 似乎正在运行 coturn 的自定义版本(来自软件领域的 Coturn-0.5 'Xirsys Turn Services' 但 coturn 从未有过这样的版本)。

In both captures, firefox detects that traffic stops being relayed (at the data channel level) and attempts a graceful disconnection by sending a Refresh request packet with a lifetime of zero.

不完全的。生命周期为 0 的刷新请求用于丢弃分配。在这一点上，服务器返回什么并不重要，因为无论如何连接都无法修复。

这是因为如果 iceconnectionstate 更改为断开连接，peerjs 关闭了对等连接， here在您的捆绑库版本中。

这过于激进(甚至没有修复问题)，我们已经讨论了规范应该做什么来尝试通过冰重启来修复问题 here这也链接到对断开连接状态的一个很好的解释。

断开连接状态可能是因为丢失了一些数据包。但这是在有轻微拥堵时可能发生的事情。我建议在断开连接的情况下删除 pc.close() 。

如果您正在寻找其他 TURN 提供商，Tokbox 提供了 same service .对于数据 channel ，正确运行的分布式 TURN 网络的延迟并不像 VoIP 那样重要，因此您可以在单个位置运行自己的服务器。