TURN error after initial tests (On-premises CE 2.16.0 install)

Hi all, we’re new to the forum & evaluating the feasibility of using OV for our project, so far it looks quite impressive! We’ve run into an installation issue & could use a hand on our 2nd installation of OV-CE using on-premises/Docker production installation.

In the past month, we’ve installed OV-CE 2.16.0 on 2 different servers w/Ubuntu LTS 20.04.01. The first install, on our own physical server, runs successfully (using OV Call), both within and outside our local network. The second install (a VPS on a 3rd party commercial host) however, seems to have a CoTURN issue, where we only see local video and solid black boxes for other devices’ video. These Firefox console error msgs appear as soon as we join a room (OV Call):

  • WebRTC: ICE failed, your TURN server appears to be broken, see about:webrtc for more details
  • IceConnectionState of RTCPeerConnection 65aec35e-30ee-4f95-9c0b-81bb203b5a4b (str_CAM_Eks0_con_UnNpVdzO8e) to “failed”

A similar pair of messages appear when other devices try to connect to the same room.

We’ve tested w/a variety of Macs and PCs with different combos of Firefox and Chrome, combinations that work fine with our first installation (our own server).

We’ve followed the on-premises/Docker production installation instructions, including the firewall port settings. Apologies in advance, this is our first exposure to the wonderful world of WebRTC, TURN, etc. so are quite novice in our experience.

Any suggestions on how to troubleshoot?

Thanks in advance for your assistance!
Dennis in Canada

This is output from the OV Dashboard …

KMS event [IceComponentStateChange]: -> endpoint: str_CAM_RlvO_con_CUk08PYglg (publisher) | state: GATHERING | componentId: 1 | streamId: 1 | timestamp: 1611628930091

KMS event [IceComponentStateChange]: -> endpoint: str_CAM_RlvO_con_CUk08PYglg (publisher) | state: CONNECTING | componentId: 2 | streamId: 1 | timestamp: 1611628930092

KMS event [IceComponentStateChange]: -> endpoint: str_CAM_RlvO_con_CUk08PYglg (publisher) | state: CONNECTING | componentId: 1 | streamId: 1 | timestamp: 1611628930091

KMS event [IceGatheringDone] -> endpoint: str_CAM_RlvO_con_CUk08PYglg (publisher) | timestamp: 1611628932139

KMS event [IceComponentStateChange]: -> endpoint: str_CAM_RlvO_con_CUk08PYglg (publisher) | state: FAILED | componentId: 2 | streamId: 1 | timestamp: 1611628937217

KMS event [IceComponentStateChange]: -> endpoint: str_CAM_RlvO_con_CUk08PYglg (publisher) | state: FAILED | componentId: 1 | streamId: 1 | timestamp: 1611628937217

What ports do you have opened in your VPS? Is the test with TrickleICE working?

1 - re: open ports: We’ve followed the on-premises/production installation instructions and opened all the ports requested. See below.

2 - re: TrickleICE - sorry, not sure that we’ve used it correctly.
STUN - We tried stun:ourdomain:3478 - we get 4 records like the Google example but after 11s get “Done” but no srflx records like the Google example. Should we get srflx recs?
TURN - Tried turn:ourdomain:3478, we get the 4 records again but after 11s an “Not reachable?” Should we enter a username and password (if so, which uname & pwd do we use)?

Appreciate any help you can offer.

OPEN PORTS:
Status: active

To Action From


22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
3478/tcp ALLOW Anywhere
3478/udp ALLOW Anywhere
40000:57000/tcp ALLOW Anywhere
40000:57000/udp ALLOW Anywhere
57001:65535/tcp ALLOW Anywhere
57001:65535/udp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
3478/tcp (v6) ALLOW Anywhere (v6)
3478/udp (v6) ALLOW Anywhere (v6)
40000:57000/tcp (v6) ALLOW Anywhere (v6)
40000:57000/udp (v6) ALLOW Anywhere (v6)
57001:65535/tcp (v6) ALLOW Anywhere (v6)
57001:65535/udp (v6) ALLOW Anywhere (v6)

  1. Yes the ufw rules are ok. But did you opened port for your instance in your cloud provider? I don’t know what cloud provider you are using, but AFAIK, instances have attached a security group in all cloud providers with open ports rules. Did you opened it?

  2. Yes you must receive srlfx candidates. To test the turn you need to create a user in the redis database to be accesible. In my next message I explain how to test the coturn server in OpenVidu.

Regards

Test STUN/TURN deployment:

  1. First create an user to test your turn server. Execute this in your deployment:
 docker exec -it openvidu_coturn_1 turnadmin -a -u testuser -p testuser -r openvidu --redis-userdb 'ip=127.0.0.1 dbname=0 password=<OPENVIDU_SECRET> connect_timeout=30'

Replace <OPENVIDU_SECRET> with your OpenVidu Secret.

  1. Open Firefox and TrickleICE WebPage.

  2. Enter this:
    image
    Where <YOUR_DOMAIN> is the domain of your deployment.

  3. If everything is ok, it should return something like this:


    See that we have relay and srlfx candidates.

  4. After that, delete the test user in your deployment:

docker exec -it openvidu_coturn_1 turnadmin -d -u testuser -r openvidu --redis-userdb 'ip=127.0.0.1 dbname=0 password=<OPENVIDU_SECRET> connect_timeout=30'

Replace <OPENVIDU_SECRET> with your OpenVidu Secret.

I hope this helps,

Regards

Thanks Carlos. We’ve got a msg into our VPS provider to see if any of those ports are blocked. (we just tried telnet’ing to the ports and 3478 timed out, so that suggests it’s not available). When we first got our site set up, the provider didn’t mention any ports that were closed when we’d explicitly asked if we could open ports on our own. So let’s see what they say.

Thanks for the TrickleICE info, that’s very helpful, I’ve just created the testuser with your tips. Same results as before but will try again once we hear from VPS provider.

Great news - indeed it was our VPS host that had port 3478 in their blocked list! We’ve been given access to it, so now OV works as it should (as does, of course, TrickleICE). Moral: Don’t assume anything, even if there’s an indication that things are different than they are! Thanks so much for your help Carlos!

1 Like

Glad to hear that!

Regards