Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video call is broken #26471

Closed
Vlod-github opened this issue Jul 2, 2023 · 19 comments
Closed

Video call is broken #26471

Vlod-github opened this issue Jul 2, 2023 · 19 comments

Comments

@Vlod-github
Copy link

Vlod-github commented Jul 2, 2023

Steps to reproduce

Install telegram on PC
Install a unity camera on your PC
Install telegram on android
Restart PC
Make a call from android to PC or from PC to android

Expected behaviour

Firstly, it is expected that regardless of the hardware status of the devices or drivers, the connection will succeed if the internet is available.

Secondly, an inoperative camera on the PC is not expected to interfere with video streaming from the phone.

Actual behaviour

Actually connection cannot be established between Telegram Desktop 4.8.3 and android versions 9.5.3, 9.6.5, 9.6.7 (On android state reconnect, on PC state exchange encryption keys, and so on infinitely)

For Telegram Desktop version 4.8.3 and android version 9.3.3, a regular voice call may be set. However, trying to enable video broadcasting on the phone has no effect.

Operating system

Windows 10, Android 7

Version of Telegram Desktop

4.8.3

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

@Vlod-github Vlod-github added the bug label Jul 2, 2023
@manfred-h
Copy link

I saw similar issues with Telegram Desktop 4.8.4 on openSUSE Tumbleweed which is using openssl3 by default. We explicitly requested to stick with openssl-1_1 and calls are working again. Perhaps this helps to isolate the problem.

@Vlod-github
Copy link
Author

I added the item "reboot PC" because the bug happens randomly, but if I managed to call at least once, the bug does not appear in that session anymore. (I tested for half an hour) Secondly, the problem is solved by restarting the telegram.

@Vlod-github
Copy link
Author

So I assume that this is a problem of interaction between telegram and windows, (which may also be on the windows side, but still it is logical to take this into account when interacting)

@john-preston
Copy link
Member

@manfred-h Calls should be fixed in OpenSSL 3 on the latest code.

@john-preston
Copy link
Member

@Vlod-github Can you check 4.8.10?

@manfred-h
Copy link

I just tried to build everything on openSUSE Tumbleweed, which is quite challenging due to:

  • glib2 is required to be >= 2.77, but this does not (yet) exist on Tumbleweed
  • glibmm2 is required to be >= 2.77, but this also does not exist on Tumbleweed - it's worse that upstream marks this release as "unstable"

I built my own versions for these two packages and used them to build telegram-desktop, but failed compiling <Telegram/lib_base/base/platform/linux/base_network_reachability_linux.cpp> which erroneously uses sigc::track_object instead of sigc::track_obj, which works with glib-2.77.2, at least.

After successfully building the whole stuff, key-exchange fails the same way as it did before :(

@ilya-fedin
Copy link
Contributor

ilya-fedin commented Aug 14, 2023

@manfred-h you need to update tg_owt, not tdesktop. sigc::track_object is intended, track_obj is deprecated.

@manfred-h
Copy link

@ilya-fedin , I was afraid I need to update tg_owt :( Whenever I tried it in the past, I failed to build the stuff. With a copy checked out this morning, CMake doesn't find the pieces for the submodule crc32c:

`CMake Warning at cmake/external.cmake:170 (find_package):
By not providing "FindCrc32c.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Crc32c", but
CMake did not find one.

Could not find a package configuration file provided by "Crc32c" with any
of the following names:

 Crc32cConfig.cmake
 crc32c-config.cmake`

I checked if the submodule has actually been checked out at all, and yes, all the files are there at src/third_party/crc32c/src

I'm no expert of cmake at all, but it appears to me some glue logic between the tg_owt main tree and the submodules is missing.

@ilya-fedin
Copy link
Contributor

Yeah, github sadly doesn't archive submodules so you have to download them manually into the directories. In case of crc32c you can use a system package.

@manfred-h
Copy link

@ilya-fedin: the submodules are not the problem, as I wrote, their sources are included in the tarball. Trouble is, that e.g. openSUSE Leap 15.4 doesn't provide cmake(Crc32c), so it needs to build the packaged sources itself. The same is true for cmake(absl), which exists in Leap 15.5 and 15.6, but that version is too old, so I need to be able to glue these submodules to the base tree.

How do it do it?

@ilya-fedin
Copy link
Contributor

ilya-fedin commented Aug 15, 2023

I have a question: what would you do if there were no submodules? Most other projects don't provide submodules, they only try to find a packaged version. Think about that and do exactly what you would do in such case.

@manfred-h
Copy link

manfred-h commented Aug 15, 2023

@ilya-fedin: simple answer: I would give up if the distribution provided package does not fulfill the required features.

As I wrote before, I'm by no means cmake capable, how/where do I define these mentioned variables Crc32c_DIR or absl_DIR? To my understanding, these are the missing pieces to make the submodules available to the rest of the whole tree. If I knew how/where to define those variables (syntax, location, etc.), I bet I'd get further down the road...

@ilya-fedin
Copy link
Contributor

ilya-fedin commented Aug 15, 2023

how/where do I define these mentioned variables Crc32c_DIR or absl_DIR?

cmake -DCrc32c_DIR=... -Dabsl_DIR=.... Or you can rather specify CMAKE_PREFIX_PATH to rule them all.

To my understanding, these are the missing pieces to make the submodules available to the rest of the whole tree.

To make them work via the submodule code, you just need to download them and copy the content to the tg_owt source tree as I already said.

@ilya-fedin
Copy link
Contributor

ilya-fedin commented Aug 15, 2023

Honestly, trying to build newer software on an old distro almost always ends with lots of pain. I recommend to use static binary/flatpak/snap, that's exactly for all this was invented.

@manfred-h
Copy link

Honestly2, are you saying you don't know how to actually make use of the submodules? If so, why are they included at all?

@manfred-h
Copy link

Another thing is, "on an old distro", the referenced versions are still fully supported... New features as requested by some packages may require to find a way to make these features usable on the still supported, but ancient distros. This is my only thing I want to find out!

@manfred-h
Copy link

BUT, the

cmake -DCrc32c_DIR=... -Dabsl_DIR=...

piece really should help me further. Thanks a lot for that!

@ilya-fedin
Copy link
Contributor

Honestly2, are you saying you don't know how to actually make use of the submodules? If so, why are they included at all?

I already said two times how to make use of them.

@github-actions
Copy link

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants