Calls in Matrix/Element

[drpaneas]

@ericdrgn to find the correct ports, login to your cloudron server and run:

# docker inspect $(docker ps | grep synapse | awk '{ print $1}')  | grep CLOUDRON_TURN_TLS_PORT

# Output:
"CLOUDRON_TURN_TLS_PORT=5349",

And run again:

# iptables -L | grep 5349

# Output:
ACCEPT     tcp  --  anywhere             anywhere             multiport dports 3478,5349
ACCEPT     udp  --  anywhere             anywhere             multiport dports 3478,5349

So in my case this is the port and the firewall on my machine is configured properly. I do NOT have another external firewall to block this. Please check if you are using any other firewall blocking this port. To verify if something is blocking those ports, try from another PC:

sudo nmap -p 5349 -sUT <yourdomain>

The expected output should be:

PORT     STATE SERVICE
5349/tcp open  stuns
5349/udp open  stuns

Note: yourdomain means example.com.

To find out if the TURN server is running:

# ps ef `pgrep turnserver`

The expected output should be:

    PID TTY      STAT   TIME COMMAND
   2170 ?        Ssl    1:22 /usr/bin/turnserver -c /run/turnserver/turnserver.conf --pidfile /run/turnserver/turnserver.pid CLOUDRON_REALM=<YOURCLOUDRONINSTANCE> HOSTNAME=turn PWD=/ HOME=/root GOR

or check the container:

docker ps | grep turn

fd3541325e01        cloudron/turn:1.1.0                                                     "/app/code/start.sh"     4 days ago          Up 29 hours

May look at the logs of the turn server when you try to do the call.

[ericdrgn]

@drpaneas So this doesn't work for me

#docker inspect $(docker ps | grep synapse | awk '{ print $1}') | grep CLOUDRON_TURN_TLS_PORT

That returns a "got permission denied error and says "docker inspect" requires at least 1 argument.

Everything else returns what your expected outputs are except for running the nmap from another computer. I am getting a "filtered" instead of open on 5349/tcp and a "open|filtered" on 5349/udp which I am assuming is the issue. But I shouldn't have anything else blocking or filtering anything so I don't know what is causing the issue.

[ericdrgn]

This post is deleted!

[girish]

Yeah, these things are really hard to debug. I will invest some time next week to help people debug their setups and document it. It's not directly cloudron related but I think it will help everyone.

[ericdrgn]

@girish There was a Cloudflare Proxy thing causing that weird "filtered" thing. Even with that disabled though and the nmap output being "open" it still doesn't work. I use the cloudflare proxy just because I don't want my IP to be exposed like it is without it.

[girish]

@ericdrgn I think TURN behind cloudflare will never work because cloudflare can only proxy http traffic. Even with cloudflare disabled, I think the webrtc protocol requires the turn server to be publicly reachable for parties to connect reliably (after all, the main reason it exists is to act as a public tunnel for hosts behind NAT).

[ericdrgn]

@girish Yeah I initially had some problems with the cloudflare proxy + cloudron apps but once I switched SSL/TLS encryption to "Full" I no longer had issues. Do you think Cloudflare Spectrum would solve the issues with webrtc/voip?

[ericdrgn]

@girish With that though... Forgive me if I am thinking too simply here (I recognize I am barely scratching the surface of this networking stuff with my knowledge) if I had a VPN setup on my cloudron would users connecting to that be able to make calls to eachother when on the VPN?

[jimcavoli]

So I mean, technically Cloudflare can proxy nearly any type of traffic. The amount they will be billing you for that service, however, does tend to mean it won't be in play for most users here. Spectrum on the cheaper plans is limited to proxying SSH on port 22 or Minecraft on port 25565 to a backend IP. RDP is an option on the higher plan, but to even access anything custom/general you've got to be an enterprise customer and going through their sales team. There are also user and bandwidth limits. Full details on https://support.cloudflare.com/hc/en-us/articles/360041721872 but suffice it to say that's likely all cost-prohibitive. VPNs might be able to do some of the things you're talking about, but there's then the problem of these extra networking configurations on your Cloudron box and/or fiddling with the docker networking directly, and you've got a recipe for disaster on your hands. It's going to be easier and cheaper to either use a completely separate TURN server or just leave that record non-proxying. If you can attach an additional IP that is more easily changed for that entry, like another floating IP from your hosting provider, you might have a halfway decent workaround.

[A Former User]

Ah I think this is what I am experiencing. Yeah same issue where my TURN server throws permission errors (401s and 403s) when I connect to people outside my network. Note that my server is on the same network as my computer I am using to initiate calls.

Basically anything that uses the TURN addon for me is unusable for me and its quite frustrating. I am trying to provide conference calling for clients of mine and I have been unable to deliver thus far.

[A Former User]

@ericdrgn Go to the services page (top-right menu) and check the logs when you try a call. What do you see when someone else connects? 401 or 403 errors?

[martin]

@atrilahiji @ericdrgn I started working on this yesterday and have similar questions.

In my case I just opened 3478 TCP & UDP on inbound traffic (on a VPC in AWS) and two users on the Cloudron could then make video calls - on Nextcloud Talk and Kopano Meet.

Monitoring the STUN/TURN logs going via the Services page, I could see a few 401s thrown before connection, but I'm not sure how to read what is happenining at this stage.

Do I need to open up 5349, as well, as indicated in the post above?