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, 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

[AdrianusWest]

@ilya-fedin what should be the correct result of executing the command?

[ilya-fedin]

That explains why it didn't help, you have an advanced locale setup

[ilya-fedin]

Try env LC_ALL=C ./Telegram

[kartavenko1983]

@ilya-fedin

Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.

[VladimirMrzv]

on my system:
$ env | grep LC_
LC_ALL=en_US.UTF-8

$ env LC_ALL=C ./Telegram
Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
qt.gui.imageio.jpeg: Corrupt JPEG data: premature end of data segment

[ilya-fedin]

That's right. Do calls work now? If yes, you can try LC_ALL=C.UTF-8 to suppress the warning.

[VladimirMrzv]

it helps, but not understand why not work with en_us or ru_ru

[kartavenko1983]

@ilya-fedin,
When launched from a terminal with the LC_ALL=C parameter, calls work, with the LC_ALL=C.UTF-8 parameter, they work the same way. When starting telegram by default, calls do not work.

[NTMan]

This sounds crazy, but redefining LC_ALL=C on any side fixes the problem.

By default on Fedora LC is not defined.

Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
mikhail@primary-ws ~> env | grep LC
mikhail@primary-ws ~ [0|1]> 

[ilya-fedin]

if LC_* aren't defined then the value from $LANG is used and undefining $LANG (the first command I asked to try) should be enough

[ilya-fedin]

but not understand why not work with en_us or ru_ru

Linux's standard C++ library thinks converting integer to string should be locale-dependent

[kartavenko1983]

@ilya-fedin How to fix it all, do not run it through the terminal every time?

[NTMan]

if LC_* aren't defined then the value from $LANG is used and undefining $LANG

mikhail@primary-ws ~> echo $LANG
en_US.UTF-8

(the first command I asked to try) should be enough

mikhail@primary-ws ~> env -u LANG Downloads/Telegram/Telegram
Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.

yes, I confirm on Fedora it enough

[ilya-fedin]

How to fix it all, do not run it through the terminal every time?

This has to be done in source code. Do you want to build tdesktop from source?

[kartavenko1983]

@ilya-fedin No

[kartavenko1983]

@ilya-fedin

Okay, thanks a lot, we'll be waiting

[VladimirMrzv]

after last update to beta Telegram crashes after accepting call, crash report has been sent automatically

[kartavenko1983]

@VladimirMrzv, You need to create a separate problem, and specify the failure ID

[john-preston]

@kartavenko1983 No need, it'll be fixed later today.

[kartavenko1983]

In version 4.14.11 beta, the calls worked correctly, we are waiting for the stable version to be updated