element-hq / element-web

A glossy Matrix collaboration client for the web.
https://element.io
GNU Affero General Public License v3.0
11.04k stars 1.96k forks source link

Calls between different devices unreliable or not working although using coturn #16369

Open mr-teaser opened 3 years ago

mr-teaser commented 3 years ago

Description

Video- and voice calls are not working as expected on own homeserver. Turnserver just works unencrypted under very certain circumstances. tls is not working under no circumstances.

I have configured coturn correctly and my turnserver works very reliable with and without tls with xmpp and nextcloud. I also checked it with https://test.voip.librepush.net. No problems at all just with matrix/element I face connection issues.

Steps to reproduce

Describe how what happens differs from what you expected.

I usually use element in my browser (Iceweasel/Brave). Calls always seem to work calling a windows-machine with the installed app. But that is pretty much everything. When I try to call an iOS device or an Android device it does not establish a call most of the times.

I expect that calls go through to any device but what happens is that it does not work very reliable. It seems to work between mobile devices most of the times - unfortunately not always. It actually does not work between a mobile device and a browser. It works sometimes from browser to browser but it apparently depends on the type of browser. It not even reliable between same brower (e.g. brave).

When calls do not connect I get an "allocation timeout" in my coturn logs.

When I try to use tls on my turnserver then no calls are working and I get the following error in my coturn logs: "TLS/TCP socket buffer operation error (callback)" I use letsencrypt but the error is still there when I use a certificate from ZeroSSL. I do not have this error using xmpp. As I understand this issue it is a certificate problem but I do not know how to solve it. Anyway calls should work without tls on my turnserver but they don't.

By the way: just writing messages works fine although on mobile devices does the notification not work reliable (but that's another bug).

Describe here the problem that you are experiencing, or the feature you are requesting.

The problem is that calls do not get established many times although a turnserver is configured.

Logs: What kind of logs do you need? Synapse? Coturn? I tried tons of combinations. Please let me which logs I should provide.

Version information

For the web app:

Mobile App: iOS: 1.6.16 android: 1.0.14 from f-droid

matrix-synapse: 1.25.0+buster1 coturn: 4.5.1.1-1.1+deb10u2

tuetenk0pp commented 3 years ago

I have a similar issue with calls between the webclient/app for pc and any mobile client not working. Strange thing is that it was working (pc <-> iOS client) a few days ago when I tested the setup...

d3473r commented 3 years ago

Calls between webApp and mobile are also not working for me. webApp to desktop works fine. The mobile device and the desktop app are in the same wifi network.

tuetenk0pp commented 3 years ago

The mobile device and the desktop app are in the same wifi network.

Calls within the same network should always work since you don't need a STUN/TURN Server for that.

d3473r commented 3 years ago

No, i mean the called desktop and mobile app are in the same network. The call is coming from outside the network. On Desktop the call works, on mobile not.

Metzlmane commented 3 years ago

I also get a ton of complaints in the last few days.. and I really can't find the issue for that. maybe 1 month ago, only a very small amount of calls didn't work.

xundeenergie commented 1 year ago

I still face this bug.

I have element on my smartphone in one mobile-net, and my laptop is in another net. And voice/video-calls are hanging at "connecting".

From the Laptop to the other mobilephone (network is from the same provider, but mobile not cable-internet) it works and from one smartphone to the other smartphone it works too.

the not full working smartphone has an ipv4 and an ipv6 address... maybe this is the problem?