Calls in Matrix/Element

[ericdrgn]

@girish I saw the old post about it but it wouldn't let me reply in there. Was it ever figured out how to get voice/video calls working within Matrix (using Element)? Or is it not expected to work? Basically it just perpetually tries to connect. A call can be initiated on one end and it looks fine but the receiving party can never actually connect. Basically just running into the same issue the other poster was taking about where calls work over the same network but not outside of the network.

[drpaneas]

@ericdrgn my experience so far:

AV (audio/video) calls between two persons (Direct) works without an issue. If you have an issue there, it's most likely because of the TURN server. Quote from Matrix.org:

Do I need a TURN server?

VoIP calls should work if both parties are on public networks. However, in practice one (or both) devices are often behind NAT, and so having a TURN server is important to help set up the call.

My issue is that group calls doesn't work, e.g. being inside a Room, when I try to start a videocall, it crashes

[ericdrgn]

@drpaneas Good to know... But how do I setup a TURN server with Cloudron? While not being able to do group calls would be a bummer even getting 1:1 working would be super helpful.

[drpaneas]

@ericdrgn it should be enabled by default -- at least I hope it is. If it's not this is a major issue for the service.

Are you using this is behind a firewall/NAT? If so, you have to open the respective TURN server ports.

[ericdrgn]

@drpaneas Yup... I self host, but as far as I know I have opened the correct ports. Is there a proper list somewhere of which ports need to be open? 3478 & 5349 are the ones I should have for TURN to work properly right?

[ericdrgn]

Good to know someones is working though. I just need to know what to do to get mine working. I saw the other thread about someone having the same issue as me but for some reason couldn't reply to that thread and I didn't see a resolution.

[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?