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
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.
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>
Here's how my turnserver.conf file looks:
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
I am particularly concerned about the following points:
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?
I can see a couple of errors stating 'Allocation Timeout'. Does that mean refer to any RAM/CPU/Network allocation that may be insufficient?
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.
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?
Thanks! Appreciate your help.
There were a few problems in the TURN server setup I had.
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.
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.
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.
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.
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.
I don't fully understand the test code on Trickle ICE Page, but I believe the results over there are reliable.