0

有一个类似的问题Coturn server - Relay is not working但它不适用，因为亚马逊在 NAT 后面有它的服务器，而我们没有。

我们有一台连接到开放互联网的裸机。当我们强制使用 WebRTC 连接时relay，候选者被交换并且我们看到了一个relay 候选者，但是没有流。

这是配置。我们玩了各种各样的东西，比如设置external-ip、打开和关闭 TLS，但无济于事。

listening-ip=<public-address>
listening-port=443
tls-listening-port=443
cert=/etc/star-attach-live-certificate.pem
pkey=/etc/star-attach-live-certificate.key

min-port=49152
max-port=65535

realm=turn.example.com
server-name=servername.example.com

fingerprint
max-bps=550000
use-auth-secret
static-auth-secret=<secret>
check-origin-consistency
userdb=/usr/local/var/db/turndb

realm指向可能重定向到此服务器或另一台服务器的负载均衡器，但我想这不是问题。

当我从https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/调用服务器时，我得到了所有 3 个候选人。

ICE 涓流响应

https://test.webrtc.org工具给了我这个：

WebRTC 测试工具

我认为结果是错误的，因为我看到了srflx上面的候选人，并且通过srflx实际进行了交流。

这是来自 chrome://webrtc-internals 的双方。我看到没有建立候选对。

客户A 客户 B

relay候选人看起来像这样：

sdpMid: 0, sdpMLineIndex: 0, candidate: candidate:3193418391 1 udp 24846335 95.216.16.200 55992 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag qW0i network-id 1 network-cost 10

我们已经没有什么可以尝试的想法了。我们甚至更换了服务器以避免潜在的硬件问题。我们在 Alpine 上的 Docker 容器中运行它。我们没有尝试过的是使用 Ubuntu 16.04LTS。

任何人都可以看到有什么问题或有想法我们还可以尝试什么？

额外的信息：

深入挖掘后，我们发现中继有时效果很好，有时效果不佳。虽然它在美国运行良好，但在调用欧盟用户时似乎会出现问题。我怀疑欧盟提供商隐藏了 prflx 候选人，强制中继连接然后失败。即使它通常不工作，它在极少数情况下也能工作，当我从我的美国位置强制中继连接时，流被中继得很好。当它工作时，coturn 上使用的带宽几乎与 in 和 out 相同，但是当它失败时，入站带宽比出站高很多，如图所示。

coturn 上使用的带宽

我无法在此处添加完整的转储，但我将其发布到https://fippo.github.io/webrtc-dump-importer/并提取了显示连接建立和候选对的相关部分。

候选对

4

0 回答 0