:bug: Answering calls take quite the amount of time to establish the connection

[x80486]

Code of Conduct

• [x] I have read and agree to adhere to the Code of Conduct.

Describe the Bug

When anyone calls (and this happens both ways for almost all my contacts), we only have up to (around) 30 seconds to pick up the call...but it takes approximately 10-15 seconds to establish the connection.

I'm aware there are many factors on this, and most of the times it's the network, but I've waited for some time to report this, and believe me it happens all the time, consistently :grimacing:

The side effect is then both recipients calling back each other as well...and you can imagine how this gets you in a loop.

On the other hand, when the connection is established, as long as the quality of the network coverage is maintained, the calls are crystal clear almost 95% of the times — so I guess the difficult part is almost done :wink:

To Reproduce

Just call one of your contacts :sweat_smile:

Smartphone

• Device: Google Pixel 4a (5G)
• OS: Android 13
• Version of Session: 1.41.1 (2935)

Additional Context

N/A

[hjubb]

I think we will increase the timeout when establishing a call to try prevent this issue in a future release. 60 seconds will probably be ok but will have to see if that fixes the issue here

[x80486]

What I was trying to describe is the action after all recipients are ready to start talking. For instance, when a call is started the status is Calling; then (I guess when able to locate the other party) it is Ringing. At that point, if the receiver picks up, that's when I say that "answering calls take quite the amount of time to establish the connection".

I think it's expected that to establish a call there is some time needed to be able to locate the other parties, but when the application indicates Ringing and the receiver picks up, I would expect the connection to be established pretty quick, and not having to wait for so long.

[hjubb]

the answer message is sent via session (not direct using the webrtc data channel it is trying to establish), so it will still rely on the initiator of the call to poll their swarm, and process all the messages to receive the call answer message before being able to set up the direct communication, basically like this:

caller (calling) --call message--> receiver

receiver polls swarm (at fixed interval) and processes incoming call, now ringing on receiver end

receiver --answer message--> caller (calling)

caller polls swarm (at fixed interval) and processes response message for existing call, now establishing on caller/receiver end at any time the caller and receiver can also send connection detail messages that are separate to a call/answer message

at this point the caller has built up a list of available connection establishment messages, which it will send in a batch to the receiver via the same method. These messages will be processed by the receiver and are required in order to establish the connection (basically tells the receiver where to try to establish the connection).

Sorry if this doesn't explain too well, but the idea I'm trying to say is that even after an answer from the receiver's side it isn't enough in some cases for a call to be established, and will require another round trip or two of polling the user's swarm to get the latest connection details.

There is probably a nicer way we can optimise this in future that doesn't tie up these real time messages to fixed interval polls to establish the call quicker. Even tweaking some of the existing values might help so will try to play around with those and test in multiple network conditions to get the best experience

[x80486]

OK, I was simplifying this a lot :sweat_smile:

There are a lot of terms and stuff I'm not familiar with, but like you mentioned, there could be some room for improvements here. I've seen that the application gets better with every release :1st_place_medal:, so I keep posting these so you folks are aware of the user's day-to-day usage.

[hjubb]

Thanks for the kind words. There are a lot of technical improvements to be made I'm sure, especially with the integration of lokinet to resolve a lot of poll time / network difficulties we currently face but there is also a lot we can do in the app itself :) We can continue improve over time to deliver the best experience for everyone

[trav3ll3r]

@hjubb I've been experiencing similar issue recently so I was just wondering if there has been any effort to improve this experience? I can see that timeout is still set to 30s in the code.

On top of that, I had cases where one party (original caller) would transition into a call (the time on the screen would start from 00:00) but the other party (original receiver) never connected to the call after hitting "Answer" button. Not sure if that is an edge case of the timeout or something else.

If I wanted to look at this issue myself, where would be the best to start looking? Android app, WebRTC integration, swarm traffic?

Thanks

[KeeJef]

Unfortunately we haven't had time to re-review our calls implementation in the last 6+ months, the foundations have been laid but we need to keep resolving bugs which are especially present when making calls cross platform, planning to re-review this implementation soon, but its taking a back seat to improvements on disappearing messages and closed groups.

I expect much of the slowness when answering calls comes down to signaling which occurs over the Session Service Node network which has a higher latency (due to onion requests) than the direct p2p connections which are made during calls. We will be replacing Onion requests with Lokinet soon, which should be much faster, so i do expect this issue to be better when that change is implemented.