Tested version 2.43.0 between two Android devices, one rooted with custom ROM, the other on stock ROM. Both firewalled and with add blocking.
First test was with unrooted device connected to the Internet via mobile network (reliable, fast connection), rooted device via wifi that gets Internet through the data connection of the unrooted device. Calls passed both ways, with or without video with good performance.
Then tested with the rooted device connected via wifi to a fixed broadband connection. Same results.
Finally tested with the rooted device connected to an organization wifi (that has several restrictions, eg.: no smtp sending except for organization domain). Same results.
I also noticed that the call passes in spite of the caller account or the receiver account being connected through proxy. I saw UDP traffic and STUN connection to local ISP and a couple of addresses traced to Germany, one I remember registered to one of the DC developers
Didn’t test desktop yet since I had no camera or microphone at the time.
I concentrated on connection possibility and quality. I know that the UI needs polishing. The most annoying UI deficiency I have found is the need to unlock the device and the fact that the screen does not show the call or turns on by itself. You have to open DC, go to the chat, and click the call message (can get there through the notification too, just like any other message).
If I happen to have the chance to test with desktop or with an iPhone I’ll report the results.
I’m impressed up to now. Looking forward to UI improvements or group calls.
about calls… I use it all the time if I need to quickly discuss something in words…
voice and video call separation works correctly in all directions
you can (!!!) receive a notification about an incoming call on your desktop and answer the call from your phone
the video call is of sufficient quality!
in Russia it all works… I don’t know how
the call passes (in my tests) in almost all network configurations, with and without VPN, from Wi-Fi to the mobile Internet and back…
yes, there is a nuance regarding the Bluetooth protocol and headsets, but apparently these are features of the protocol and the headset
PS: I will continue to test this function and will describe the interim results of the tests.
…and here is the first addition: the proximity sensor control on the phone does not work, in other words, when the screen goes dark, the microphone of the headset or phone is disconnected and the call may then fall apart…
I see a solution to ignore the proximity sensor or turn off the screen, the screen can always be activated
I tested calls to a desktop client, in this case Windows Electron 2.43.0, from Android same version. Both devices connected to the same broadband Internet connection through the same wifi.
Audio and video worked fine. Also, in the desktop the interface in more comfortable and responds as a user would expect, popping up a new window with the call.
If UDP is enabled in both directions in the firewall “P2P” appears in the desktop windows call, otherwise “non-P2P” appears.
A funny note: You can answer yourself in the desktop version if calling from one profile to another. Video works fine, but if one or both mics are enabled coupling occurs.
Once again, 'I’m impressed and looking forward for new versions.
This 2.22.0 version at the beginning of the thread is outdated, the topic is from 2025, currently released in F-Droid version is 2.43.0, and there is 2.46.0 in beta.
I have send a screenshot in Testflight with “back” button in mainscreen in iOS 2.46.0 b 164.
There is some problem at iPad iOS 26.3.1
This Back button if often missing inside chat in Portrait orientation.
