如果我的kurento媒体服务器（S1）设置在公共服务器上，并且用户A可以连接到S1，但它很慢！我想买一台主机（H1），让用户A快速连接到H1！服务器 H1 快速连接到 S1！所以我认为在 H1 上安装 coturn 作为媒体中继。我可以在 H1 上安装 coturn，并通过 H1 的 coturn 强制传输用户 A 媒体流吗？
我正在尝试在运行 ubuntu 14.04 的谷歌计算云 VM 实例上设置 coturn 服务器。我认为这是一个防火墙问题，但我在防火墙设置中打开了端口 tcp:3478 和 udp:3478。没有其他进程在 3478 端口上运行。有人试过在 gcloud 上设置这个吗？我究竟做错了什么。
$ sudo turnserver -a -v -n -r north.gov -L 35.189.173.237
0: log file opened: /var/log/turn_2564_2017-07-06.log
0:
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Coturn-4.5.0.6 'dan Eider'
0:
Max number of open files/sockets allowed for this process: 65536
0:
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 32500 (approximately)
0:
==== Show him the instruments, Practical Frost: ====
0: TLS supported
0: …我正在尝试在 Google Cloud Ubuntu 实例中运行 Coturn。
在新的 VM 中安装 coturn 使用：sudo apt install coturn
我用私钥创建了一个证书文件并更新/etc/turnserver.conf：
listening-port=3478
tls-listening-port=5349
listening-ip=10.128.0.2
relay-ip=10.128.0.2
external-ip=35.192.224.52/10.128.0.2
lt-cred-mech
userdb=/var/lib/turn/turndb
user=attitudemarketing:password
cert=cert.crt
pkey=private.key
no-stdout-log
一切似乎都在运行，但是当我尝试 Trickle Ice 时：https : //webrtc.github.io/samples/src/content/peerconnection/trickle-ice/它似乎不起作用
这是来自 coturn 的日志文件：
0: log file opened: /var/log/turn_1978_2017-10-12.log
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: Wait for relay ports initialization...
0: relay 10.128.0.2 initialization...
0: relay 10.128.0.2 initialization done
0: relay ::1 initialization...
0: relay ::1 initialization done …我想在我们公司的服务器上搭建一个turn server（coturn）。而且我不确定外部访问应该允许哪些端口。8443 是必须的，使用 WebRTC。3478 是凭证使用的必要条件。但是TURN服务器使用的端口数不胜数，是否需要在防火墙中允许它们？或者应该允许哪些端口使用CoTURN没有问题？
默认情况下，coturn 使用范围 49152-65535 UDP 作为中继端口。有什么理由使用全系列吗？一个udp不能处理无限连接吗？把所有这些都打开有什么意义呢？是否存在安全风险？使用较少的 udp 端口是否有任何权衡？
我使用 webRTC 来建立与其他浏览器的网络浏览器实时通信。为了确保此连接始终可靠，我想设置自己的 STUN/TURN 服务器。我决定在 Azure VM（Ubuntu 服务器）上使用 coturn。我按照此文档在 Azure https://www.microsoft.com/developerblog/2018/01/29/orchestrating-turn-servers-cloud-deployment/上设置了 coturn 。
根据 [Trickele ICE][1] [1]: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/我的 STUN 服务器工作，我得到了积极的结果。
每当我尝试使用 STUN/TURN 服务器建立网络摄像头连接时，它都不起作用。
webRTC协议会话统计：
Local SDP
v=0
o=mozilla...THIS_IS_SDPARTA-58.0.2 8794114299540424628 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 8B:A5:5A:36:D7:42:B0:DE:D8:FB:3B:AC:7A:41:AE:D1:F2:86:71:66:CB:99:79:54:08:9B:B2:97:DC:54:D7:E6
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 52254 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 192.168.9.1
a=candidate:0 1 UDP 2122252543 192.168.9.1 52254 typ host
a=candidate:1 1 UDP 2122187007 192.168.67.1 52255 typ host
a=candidate:2 1 UDP 2122121471 192.168.1.151 52256 …我在 TLS 端口上连接到 Turnserver 时遇到问题。我最近将 Debian 服务器升级到了 Buster，发现 coturn 只监听端口 3478。stun 和turn 都工作得很好。然而，coturn 没有监听 5378，turns 不起作用。我尝试完全重新安装coturn，但没有成功。证书有效，来自 certbot。与默认配置文件的行为相同。无论是在详细模式还是在详细模式下都没有错误消息。不用说，没有其他任何东西在监听 TLS 端口。所以，现在我觉得自己完全被困住了......有人见过这种行为吗？或者我如何追踪导致 coturn 不开始侦听 TLS 的原因？