telegram encryption key exchange ends with an error

[kartavenko1983]

last_call_log.txt last_openal_log.txt log.txt log.txt

Steps to reproduce

1. Making an outgoing call from a computer to a Linux computer for both subscribers
2. Receiving an incoming call from a computer to a Linux computer from both subscribers

Expected behaviour

A connection should be made and a voice communication session is taking place

Actual behaviour

telegram exchange of encryption keys during a call it ends with an error, the call ends after 20 seconds

Operating system

linux

Version of Telegram Desktop

4.14.4

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

[ilya-fedin]

Static binary from official website

Are you sure about that? Such bugs are usually only on unofficial builds so I'm requesting a proof that you're using the official binary. The log.txt could be such a proof (how to get it is explained when you was creating the issue).

[kartavenko1983]

Naturally, the binary file is official. We use only the official application from the official website Sorry, I can't figure out how to get log.txt on the computer. There is no search bar in the application settings, there is nowhere to enter the cheat code.

[ilya-fedin]

Yes, it's called cheat code exactly because there's nowhere to enter. Just like when you enter a cheat code in a game.

[kartavenko1983]

But games have a console for that. And here it is unclear how to enter it And it is unclear how to collect logs. How can I collect logs?

[ilya-fedin]

And here it is unclear how to enter it

Just enter it blindly

And it is unclear how to collect logs.

Just upload the log.txt.

[kartavenko1983]

I'm sorry, I've formatted the log files incorrectly. I'm attaching it. log.txt

[kartavenko1983]

I attach the logs received after making unsuccessful calls. log.txt

[AdrianusWest]

Same story.

OS: Arch/EndeavourOS.

Incoming and outgoing calls, "Encryption key exchange", ends/disconnects the call, showing duration of 20 seconds.

In the logs standard garbage (three years can not fix for KDE, yep).

When trying to close the client and reopen it, it shows up in the logs, though why it updates the configuration EVERY DAMN EXIT is a mystery:

`20.01.2024 21:27 telegram-desktop D/tgvoip: === Updating voip config ===

20.01.2024 21:27 telegram-desktop D/tgvoip: {"enable_vp8_encoder":true,"enable_vp8_decoder":true,"enable_vp9_encoder":true,"enable_vp9_decoder":true,"enable_h265_encoder":true,"enable_h265_decoder":true,"enable_h264_encoder":true,"enable_h264_decoder":true,"audio_frame_size":60,"jitter_min_delay_60":2,"jitter_max_delay_60":10,"jitter_max_slots_60":20,"jitter_losses_to_reset":20,"jitter_resync_threshold":0.5,"audio_congestion_window":1024,"audio_max_bitrate":20000,"audio_max_bitrate_edge":16000,"audio_max_bitrate_gprs":8000,"audio_max_bitrate_saving":8000,"audio_init_bitrate":16000,"audio_init_bitrate_edge":8000,"audio_init_bitrate_gprs":8000,"audio_init_bitrate_saving":8000,"audio_bitrate_step_incr":1000,"audio_bitrate_step_decr":1000,"use_system_ns":true,"use_system_aec":true,"force_tcp":false,"jitter_initial_delay_60":2,"adsp_good_impls":"(Qualcomm Fluence)","bad_call_rating":true,"use_ios_vpio_agc":false,"use_tcp":false,"audio_medium_fec_bitrate":20000,"audio_medium_fec_multiplier":0.1,"audio_strong_fec_bitrate":7000}`

[kartavenko1983]

@AdrianusWest, Does it work fine in other desktop environments? The problem has become strongly felt in the last six months, and especially strongly in the last month. We used manjaro, now we have switched to Rosa OS linux fresh 12.4. We use pipewire with wireplumber.

[AdrianusWest]

@kartavenko1983 , I don't change the OS or desktop environments. Arch and KDE are always difficult.

[ilya-fedin]

I'd suggest to ask the counterpart to update their client or switch to another one as tgvoip is a legacy protocol and is not tested nowadays I guess

[AdrianusWest]

@ilya-fedin Versions on tablet, phones and more are fresh from the site, updated promptly.

[ilya-fedin]

@AdrianusWest maybe it's Telegram X that is always lagging behind?

[AdrianusWest]

@ilya-fedin telegram-desktop 4.14.8-1 - it's kind of ordinary.

[kartavenko1983]

@AdrianusWest, Okay, thanks for the clarification.

[ilya-fedin]

telegram-desktop 4.14.8-1 - it's kind of ordinary.

This version is not official and is not supported here. If you want support for this version, please refer to the distro bugtracker.

[AdrianusWest]

@ilya-fedin source=("https://github.com/telegramdesktop/tdesktop/releases/download/v${pkgver}/tdesktop-${pkgver}-full.tar.gz")

I must be dumb, but this is the same repository with the very code that you and I are discussing here and now.

It's not about another client, not about a fork, not about a neighboring repository - the source code is taken here.

What do you mean, "This version is not official and is not supported here."!?

[ilya-fedin]

Source code is not the only thing that could (and does) change the behavior. The way the client is built is also important and distributions never use the official way with pinned dependencies and build environment.

[AdrianusWest]

@ilya-fedin Cool! )))) "It's not us writing crookedly, it's them building from our code wrong!"

I'll contact the maintainer, of course, but the situation strikes me as extremely creepy and very ridiculous, especially considering that there are people sitting on github who are related to development in one way or another.

Your answer reminds me of the classic "But everything runs on my computer!".

[ilya-fedin]

"It's not us writing crookedly, it's them building from our code wrong!"

There's sadly no manpower to test for every possible environment, sorry. If you can provide such manpower and maintain fixes for your distro build, please do it. If you can't, feel free to use the build with tested libraries combination from the official website.

[AdrianusWest]

@ilya-fedin But we can't substitute one dependency for another, can we? The basic ones are immutable, regardless, aren't they? oO

[ilya-fedin]

You can build with a different version of a dependency just fine and that's what distros do. The dependencies also do have configurations flags and the chances the distros build them with the same flags as tdesktop does are little. Some dependencies are patched (e.g. Qt) as they have plenty of bugs affecting tdesktop and ruining the UX while having them fixed upstream is unrealistic (due to bureaucracy, low priority of the bugs to the upstreams and etc).

[kartavenko1983]

@ilya-fedin, what dependencies are needed for the normal operation of the telegram version from the official website? What should be installed in the system?

[kartavenko1983]

@ilya-fedin, Just analyzing what is happening, I get the feeling that something is missing.

[ilya-fedin]

Building instructions are linked in the readme. The key thing is building happening not in the system but in a container with all the required dependencies built the right way.

[ilya-fedin]

Oh, oops, I've mis-read. There are not much runtime dependencies, the binary is almost static, as long as it launches, you have everything required.

[ilya-fedin]

I'd guess something is wrong with the counterpart

[kartavenko1983]

@ilya-fedin, Obviously, something is wrong with telegram, as I said, we initially use the version from the official website. It is constantly updated in automatic mode. The problem with a long exchange of encryption keys and subsequent disconnection occurs only if both subscribers are working from a computer. If they call from the phone, and I answer from the computer, then the call is successful, which is also true in the opposite situation. I added the log files in the comments above and in the main message of the topic. Moreover, this happens somehow randomly, that is, the connection may go fine, or it may fail

[AdrianusWest]

Moreover, for some reason the old protocol was not shown in the logs.🤔

[ilya-fedin]

Calls are logged to their own logs and only when debug mode is active

[kartavenko1983]

@ilya-fedin, how can I check it? There's also log.txt , there is also some kind of Debug Logs folder. There are a lot of *.txt files there. Can I unload them here too?

[ilya-fedin]

The calls_last_log.txt (or something like that) from DebugLogs. Uploading entire folder means uploading network dump with session credentials.

[kartavenko1983]

@ilya-fedin last_call_log.txt last_openal_log.txt

[VladimirMrzv]

I can confirm this issue. call from ubuntu to fedora and back connection can not be established.

[kartavenko1983]

@ilya-fedin, Do I need to open any ports for telegram on my computer or router? Now I noticed that after the conversation, the 1900 udp port was opened in the firewall of the system.

[ilya-fedin]

I don't know, sorry

[kartavenko1983]

@ilya-fedin, Where can I find out about this?

[ilya-fedin]

I don't know this either, sorry

[AdrianusWest]

@kartavenko1983 Look here

[VladimirMrzv]

my logs from 2 linux pc DebugLogs.zip DebugLogs2.zip

[kartavenko1983]

@VladimirMrzv, What is your desktop environment?

[VladimirMrzv]

Ubuntu 22.04 with Unity

[ilya-fedin]

Try to run tdesktop without having system locale set (usually env -u LANG ./Telegram is enough but maybe not in case of advanced locale setups).

[kartavenko1983]

@ilya-fedin, and how can it help?

[ilya-fedin]

I don't know what to answer, please check and report back

[kartavenko1983]

@ilya-fedin, No, the problem persists. I specifically checked it using a desktop computer and a laptop and two different telegram accounts. I launched telegram on both devices using this command. The result is exactly the same.

[ilya-fedin]

Provide the result of env | grep LC_

[kartavenko1983]

@ilya-fedin, grep: /opt/Telegram/Telegram: двоичный файл совпадает

grep: /opt/Telegram/Telegram: binary file matches

[ilya-fedin]

@kartavenko1983 the command couldn't have such a result, you have entered it wrong

[kartavenko1983]

@ilya-fedin

LC_ADDRESS=ru_RU.UTF-8 LC_NAME=ru_RU.UTF-8 LC_MONETARY=ru_RU.UTF-8 LC_PAPER=ru_RU.UTF-8 LC_IDENTIFICATION=ru_RU.UTF-8 LC_TELEPHONE=ru_RU.UTF-8 LC_SOURCED=1 LC_MESSAGES=ru_RU.UTF-8 LC_MEASUREMENT=ru_RU.UTF-8 LC_CTYPE=ru_RU.UTF-8 LC_TIME=ru_RU.UTF-8 LC_COLLATE=ru_RU.UTF-8 LC_NUMERIC=ru_RU.UTF-8