Coturn服务器-中继不起作用 [英] Coturn server - Relay is not working

查看:711
本文介绍了Coturn服务器-中继不起作用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试为基于WebRTC的应用程序设置COTURN服务器.但是,我遇到了一些无法理解的错误消息,并且无法在Internet上找到任何帮助.

I am trying to setup a COTURN server for my WebRTC based application. However I am stuck with a couple of error messages that I am unable to understand, and can't find any help on them on internet.

以下是有关该应用的一些详细信息:

Here are some details about the app:

  • 两个用户登录到该应用程序,并且其中一个用户可以与另一个用户共享屏幕-因此,视频流仅在一个方向上进行

  • Two users log on to the app, and one of the user can share their screen with the other - so the stream is going in only one direction

我能够使该应用程序在Intranet内和某些外部网络上运行.因此,我有信心只要STUN模式就足够,该应用程序就可以正常工作.

I am able to get the app to work within intranet and on some external networks. So I'm confident that the application is working fine wherever STUN mode is sufficient.

对于某些网络,STUN候选对象经常失败,因此我需要使用TURN服务器来中继流.

For some of the networks the STUN candidates are constantly failing, so I need to get a TURN server to relay the stream.

我已经从服务器上收集了一些服务器日志,以防有人可以根据它们识别问题:

I have collected some server logs from the server, in case someone could identify the problem based on them:

handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59942

handle_turn_command: STUN method 0x1 ignored

handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59944

handle_turn_command: STUN method 0x1 ignored

session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised

session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised

session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised

IPv4. Local relay addr: <IP Address>:64306

session 128000000000000096: new, realm=<server URL>, username=<username>, lifetime=600

session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success

IPv4. Local relay addr: <IP Address>:65384

session 128000000000000097: new, realm=<server URL>, username=<username>, lifetime=600

session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success

session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

handle_turn_command: STUN method 0x1 ignored

session 128000000000000096: refreshed, realm=<server URL>, username=<username>, lifetime=0

session 128000000000000096: realm <server URL> user <username>: incoming packet REFRESH processed, success

session 128000000000000097: refreshed, realm=<server URL>, username=<username>, lifetime=0

session 128000000000000097: realm <server URL> user <username>: incoming packet REFRESH processed, success

session 128000000000000096: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59942, reason: allocation timeout

session 128000000000000096: delete: realm=<server URL>, username=<username>

session 128000000000000097: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59944, reason: allocation timeout

session 128000000000000097: delete: realm=<server URL>, username=<username>

这是我的 turnserver.conf 文件的外观:

listening-port=3478
#tls-listening-port=443
realm=subdomain.domain.com
server-name=subdomain.domain.com
lt-cred-mech
userdb=/etc/turnserdb.conf

cert=/home/ubuntu/certificate.crt
pkey=/home/ubuntu/qc.key
pkey-pwd=L1ght!t

no-stdout-log
Verbose

我特别关注以下几点:

  • 我是否应该假定由于我的代码可在STUN服务器上使用,所以它也可在工作 TURN服务器上使用?因此,该错误是否意味着问题出在TURN服务器上?

  • Should I assume that since my code is working with a STUN server, it would work with a working TURN server as well? Hence, the error means that the problem is with the TURN server?

我可以看到一些错误,指出分配超时".这是否表示可能没有足够的RAM/CPU/网络分配?

I can see a couple of errors stating 'Allocation Timeout'. Does that mean refer to any RAM/CPU/Network allocation that may be insufficient?

某些请求的用户名部分为空的'<>'而不是'',并且其后是"401未经授权",而我已经三重检查了RTCPeerConnection配置-它们确实包含用户名和密码.

Some of the requests have username portion empty '<>' rather than '', and it is followed by a '401 Unauthorized', while I have triple checked the RTCPeerConnection configurations - they do contain the username and password.

除了上面的日志外,我还经常看到"438错误的随机数"出现.我对此进行了搜索,但似乎无法通过JS控制.它与任何服务器配置有关吗?

Apart from the logs above, I have seen '438 Wrong nonce' come in quite frequently as well. I searched a bit about that, but it doesn't seem like something I can control through JS. Is it related to any server configurations?

谢谢!感谢您的帮助.

推荐答案

我在TURN服务器设置中遇到了一些问题.

There were a few problems in the TURN server setup I had.

  • 首先,我们从一个已有两年历史的博客中获取了它.结果,该设置也只有两年的历史-Coturn Monza.理想的开始方式是获得Coturn AMI(Amazon Machine Image)(

  • First off, we had taken it from a blog which was about two years old. As a result, the setup was also two years old - Coturn Monza. The ideal way to start would be to get the Coturn AMI (Amazon Machine Image)(Version 4.5.0.6 details) and use it to setup the server. Alternatively, we should have at least taken the most recent setup through the git repository.

第二个问题与配置有关.甚至在这里发布问题之前,我们都错过了打开服务器上必要的端口的机会.完成此操作后,我们开始获得STUN响应,但是中继尚未起作用.

Second problem was with the configurations. Even before posting the question here, we had missed to open the necessary ports on the server. Once we did that, we started getting the STUN responses, but the relay wasn't working yet.

第三关键问题是Turnserver.config文件中的配置.我们几乎没有经历过所有配置,在Polaris回答之后,我们做到了.配置文件包含每种配置的充分说明,而问题确实出在配置上.

Third key problem was with the configurations in Turnserver.config file. We had barely gone through all configurations and after Polaris's answer we did. The config file contains sufficient explanation for each configuration, and the problem was indeed with the configurations.

最后一个问题是测试用例.我们想要确保中继正常",并且在测试的早期阶段,我们已经确定了需要中继的特定网络设置(即,只有STUN无法完成请求.)最终,我们了解到,即使是TURN服务器将无法通过该设置.

The last problem was with the test cases. We wanted to ensure that the relay was "working", and during earlier stages of testing we had identified a particular network setup that would require relay (i.e. only STUNs would not be able to complete the request.) Eventually we learned that even TURN server would not be able to get through that setup.

我们确实花了一些时间尝试一下NOSTUN模式(位于turnserver.config中),但是由于缺乏良好的测试用例,我们无法确认中继是否正常工作.

We did spend some time trying the NOSTUN mode (it's there in the turnserver.config), but due to lack of good test cases, we were never able to confirm that relay was working.

我不完全了解 Trickle ICE上的测试代码Page ,但我相信那边的结果是可靠的.

I don't fully understand the test code on Trickle ICE Page, but I believe the results over there are reliable.

这篇关于Coturn服务器-中继不起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆