COTURN error 401: Unauthorized w/ on premises

Issues with deployment
1

I have been struggling for a while trying to get my 2.15.0 OpenVidu install running on my cloud VPS. I started with the standard install_openvidu_latest.sh script and modified the .env as well as opened up all of the prescribed ports on my server via ufw. I have successfully been able to run a test on the dashboard page and I have attempted to have 2 of my local PCs behind the same firewall connect via the same OpenVidu room. I can’t see the other person’s video. When I perform docker-compose logs -f coturn I see sporadic errors like the ones below:

1249: session 001000000000000083: new, realm=, username=, lifetime=3600
coturn_1 | 1249: session 001000000000000083: realm user : incoming packet ALLOCATE processed, success
coturn_1 | 1249: session 000000000000000084: realm user <>: incoming packet message processed, error 401: Unauthorized
coturn_1 | 1249: session 001000000000000087: realm user <>: incoming packet BINDING processed, success
coturn_1 | 1249: session 000000000000000082: realm user <>: incoming packet OLD BINDING processed, success

I have also seen TCP socket errors: (I replaced the IP addresses with [userIP] and [serverIP]
coturn_1 | 1571: session 000000000000000071: TCP socket error: Connection reset by peer [userIP]:53852
coturn_1 | 1571: session 000000000000000071: closed (2nd stage), user realm origin <>, local [serverIP]:3478, remote [userIP]:53852, reason: TCP socket buffer operation error (callback)

Any thoughts? I am using a self-certify deployment right now until I can get everything debugged. I tried using Trickle but don’t know what username and password to enter for my TURN server.

Thanks,
-Rob

1 Like
2

Not only it is necessary to open ports with ufw.
Did you ensure that all specified ports are open in your Cloud Provider?

Also, can you test your app with our demos deployment? In this way we can check if the issue is in your deployment.

url: demos.openvidu.io
user: OPENVIDUAPP
password: MY_SECRET

1 Like
3

I tried using Trickle but don’t know what username and password to enter for my TURN server.

Hello @rob,

The username & password for the TURN server are generated dynamically on each peer connection for security purposes.

But you can test if the TURN server works correctly by adding a long-term user to the configuration file.

On the OpenVidu server you need to do these steps:

1 - enter the coturn docker

cd /opt/openvidu
docker-compose exec coturn bash

2 - install a text editor (nano for example)

apt-get install nano -y

3.1 - edit the TURN server configuration file

nano /etc/turnserver.conf

3.2 - add the following lines with a ‘static’ username and password

lt-cred-mech
user=TurnUser:TurnPassword

4 - restart the TURN server

service coturn restart

Now you can test the TURN server with Trickle.

Remember to remove these before going to production!

Cheers,
Mihail

1 Like
4

We have exactly the same issue. The log seems pretty similar to ours. We can establish video connection within local network and with some but not all remote networks. In particular, using 2 different WiFi networks are ok, but if one of participants use cellular network, they can’t see each other.

With Tricke Ice get are getting successfully host, rtp srflx, rpt relay. And message: The server stun:xxx.xxx.xx.xx:3478 returned an error with code=701: STUN server address is incompatible.

But when I tested our STUN with command-line utility (stantman), it shows no errors.

We are running on VPS, I will ask VPS provider is I need to do anything else to open ports on their side. On server itself we have all range of ports opened.

Any help would be appreciated.

EDIT:

I can confirm that all ports are open and I was able to transmit data over any port, so I don’t think it’s network issue.

You can find the OpenVidu log file of connection of 2 people (unsuccessful) here: http://mafia-game.net/static/ov-log.txt

5

Hello @mikeks,

How have you deployed you OpenVidu platform? Can you test with https://demos.openvidu.io (secret=MY_SECRET)?

Regards

6

You can find the OpenVidu log file of connection of 2 people (unsuccessful) here: http://mafia-game.net/static/ov-log.txt

In the logs I can see that the Publisher is successfully sending media to Kurento:

[NewCandidatePairSelected] (publisher)
    local: candidate:1 1 UDP 2015363327 162.246.17.61 10900 typ host
    remote: candidate:842163049 1 UDP 1686052607 98.114.175.80 37143 typ srflx raddr 192.168.1.17 rport 37143

(local is Kurento, and remote is the publisher’s public IP, 98.114.175.80)

and this is later confirmed by the two FLOWING events:

(publisher) | state: FLOWING | pad: default | mediaType: VIDEO
(publisher) | state: FLOWING | pad: default | mediaType: AUDIO

… later, there is a Subscriber that is successfully receiving media from Kurento:

[NewCandidatePairSelected] (subscriber)
    local: candidate:1 1 UDP 2015363327 162.246.17.61 7762 typ host
    remote: candidate:842163049 1 UDP 1686052607 98.114.175.80 59203 typ srflx raddr 192.168.1.17 rport 59203

(again, local is Kurento and remote is the subscriber’s public IP, which seems to be the same than the publisher)

but then the flowing of media is not confirmed (no FLOWING event), which means no media could flow from Kurento to the selected address at 98.114.175.80:59203.

It’s interesting that a candidate pair could be selected, which only happens if connectivity has been successfully tested, but then later the media is not able to flow. This means that STUN did its work, successfully opened the subscriber’s port 59203, but in the meantime something broke and media couldn’t be sent to that port.

Testing against our own OpenVidu Demos platform will be useful to compare if things are different.

7

Thank you for your answer. After deep investigation (we tested which ports are open on both client and server and other things) was able to resolve the issue with no-video issue when using T-Mobile cellphone provider.

It turns out that we had to enable IPv6 on our server. After we enabled IPv6 (i.e. set AAAA DNS record for our domain and enable it on Kurento) everything starts working fine.

Hopefully my answer my be helpful for other users, who may have the same problem. Seems that you must support IPv6 on server nowadays, otherwise some mobile devices won’t be able to connect.

1 Like