search

grishka / libtgvoip

VoIP library for Telegram clients
The Unlicense
387 stars 156 forks source link

Voice calls stuck on connecting status #70

Closed shorewall closed 5 years ago

shorewall commented 5 years ago

Linux Mageia 6.0 64 bits on Lenovo T530. Telegram Desktop 1.5.8

Telegram is working fine except for voice calls. After ringing the call remains in 'connecying status. The libtgvoip seems unable to connect a socket.

Here is the debug log: W/tgvoip: Set remote endpoints, allowP2P=1, connectionMaxLayer=92 V/tgvoip: Adding endpoint: 91.108.8.4:536, UDP V/tgvoip: Adding endpoint: 91.108.8.8:526, UDP V/tgvoip: Adding endpoint: 91.108.12.3:539, UDP V/tgvoip: Adding endpoint: 91.108.12.1:533, UDP V/tgvoip: Adding endpoint: 91.108.16.1:531, UDP V/tgvoip: Adding endpoint: 91.108.16.3:540, UDP
I/tgvoip: update data saving mode, config 0, enabled 0, reqd by peer 0 W/tgvoip: Starting voip controller E/tgvoip: error creating socket: 97 / Famiglia di indirizzi non supportata dal protocollo V/tgvoip: Call state changed to 4 I/tgvoip: before create audio io I/tgvoip: AEC: 1 NS: 1 AGC: 1 (audio_processing_impl.cc:394): Capture analyzer activated: 0 Capture post processor activated: 0 Render pre processor activated: 0 (audio_processing_impl.cc:658): Highpass filter activated: 1 (audio_processing_impl.cc:672): Gain Controller 2 activated: 1 (audio_processing_impl.cc:674): Pre-amplifier activated: 0 I/tgvoip: Audio initialization took 0,003698 seconds W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing I/tgvoip: === send thread exiting === D/tgvoip: Entered VoIPController::Stop D/tgvoip: before shutdown socket

The same Telegram Desktop 1.5.8 works perfectly on a Mageia 5 Linux box Lenovo T410, as like as the previous Telegram versions. The trivk enable/disable IPv6 changes nothing.

grishka commented 5 years ago

You need to enable IPv6 support in your kernel.

shorewall commented 5 years ago

Tks. I'll try, even if I had many line speed problems in the past with ipv6 enable.

pi-yush commented 5 years ago

I have the same issue, and even when ipv6 is enabled in the kernel, the call still doen't go through. Although, the reason for the above error in my case is different as i am trying to send the data through a local SOCKS proxy. Any comments on how that can be done?

grishka commented 5 years ago

@Piyush825 Does your SOCKS proxy support UDP? If it does not, libtgvoip, as of the latest versions, will detect that and try using UDP directly anyway. If it doesn't work directly, it will then try TCP as a last resort, and that always goes through proxy is one is set. Could you please provide the relevant part from the log?

pi-yush commented 5 years ago

@grishka Nope, the SOCKS proxy does not support UDP. Here is the log for your reference :

State changed: <tgvoip.file_stream_call.VoIPOutgoingFileStreamCall object at 0x7f562415e438> 12 I/tgvoip: update data saving mode, config 0, enabled 0, reqd by peer 0 W/tgvoip: Set remote endpoints, allowP2P=0, connectionMaxLayer=92 V/tgvoip: Adding endpoint: 91.108.16.2:526, UDP V/tgvoip: Adding endpoint: 91.108.16.1:522, UDP V/tgvoip: Adding endpoint: 91.108.12.5:533, UDP V/tgvoip: Adding endpoint: 91.108.12.3:531, UDP V/tgvoip: Adding endpoint: 91.108.8.5:525, UDP V/tgvoip: Adding endpoint: 91.108.8.1:528, UDP W/tgvoip: Starting voip controller E/tgvoip: error creating socket: 1 / Operation not permitted V/tgvoip: Call state changed to 4 I/tgvoip: before create audio io State changed: <tgvoip.file_stream_call.VoIPOutgoingFileStreamCall object at 0x7f562415e438> CallState.ESTABLISHED I/tgvoip: AEC: 1 NS: 1 AGC: 1 (audio_processing_impl.cc:394): Capture analyzer activated: 0 Capture post processor activated: 0 Render pre processor activated: 0 (audio_processing_impl.cc:658): Highpass filter activated: 1 (audio_processing_impl.cc:672): Gain Controller 2 activated: 1 (audio_processing_impl.cc:674): Pre-amplifier activated: 0 I/tgvoip: Audio initialization took 0.002503 seconds W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing W/tgvoip: Not ready to send - enqueueing I/tgvoip: === send thread exiting === State changed: <tgvoip.file_stream_call.VoIPOutgoingFileStreamCall object at 0x7f562415e438> 11 D/tgvoip: Entered VoIPController::Stop D/tgvoip: before shutdown socket D/tgvoip: before join sendThread D/tgvoip: before join recvThread D/tgvoip: before stop messageThread D/tgvoip: Before stop audio I/O D/tgvoip: Left VoIPController::Stop [need rate = 0] D/tgvoip: Entered VoIPController::~VoIPController D/tgvoip: before close socket D/tgvoip: before delete audioIO D/tgvoip: before delete encoder D/tgvoip: before delete echo canceller D/tgvoip: Left VoIPController::~VoIPController

grishka commented 5 years ago

error creating socket: 1 / Operation not permitted

Any ideas why? UDP socket failing to create is obviously considered a fatal error because that shouldn't happen. And if that was because of AF_INET6 then it would be that specific error code for that as in the first log, wouldn't it?

pi-yush commented 5 years ago

I just tried initiating a call without using a SOCKS proxy and everything works fine. I think the problem is that this SOCKS just drops UDP packets. Is there a way to force tgvoip to initiate calls using TCP instead of UDP?

grishka commented 5 years ago

There is. You're writing a custom client, right? Then just change the endpoint types you pass to VoIPController::SetRemoteEndpoints() to Endpoint::Type::TCP_RELAY. While this will force it to use TCP, it won't prevent it from creating a UDP socket and failing if it fails to create.

I still don't really understand why the socket fails to create though. Do you set that proxy system-wide?

pi-yush commented 5 years ago

Thanks, your suggestion helped me run it. :) As for the reason why UDP sockets weren't created, i guess that is to do with the fact that i did not specify the proxy internally in the code. I was using a utility torify , which comes with Tor, to send all data to a local Tor SOCKS port. Since it does not support UDP, i guess the request to create socket was not served.

grishka commented 5 years ago

It's always better if you set up your proxy on libtgvoip level. Since torify appears to be replacing system socket APIs with its own implementations but I only ever use TCP as a last resort, this failing behavior is to be expected. I thought it was the kernel that was returning that error.