Improvement: Don't wait UI on connection

[ManDay]

When I start Linphone anew, it first tries to connect to my SIP server. During that time, a rotating spinner is shown on the screen and no user interaction seems to be possible. For example, I can not see recent calls, or bring up the dialpad, while Linphone tries to connect. It would be good if the connection happens in the background and does not block the rest of the UI,

Linphone 6.0.16 from F-Droid

[Viish]

Hi @ManDay,

When you say "start Linphone anew", do you mean after app was killed or the first time it's installed?
Could you show me a screenshot of such spinner so that I understand correctly the one you're talking about please?

Thanks in advance.
Cheers,

[ManDay]

Hi @Viish, by "start Linphone anew" I mean start the app after it was killed. I attach a picture of the spinner which I see then, after the initial flash/logo:

[Viish]

Thanks for the screenshot.

That spinner doesn't mean it's waiting for you to get connected, simply it's waiting for the data to be available.
Would you mind sending me the app logs so I can take a look at why it takes so long?

[ManDay]

I attach the logs obtained after the following sequence:

. Clean logs
. Kill app
. Start app
. Get logs

linphone.log.txt

[Viish]

2025-09-03 14:48:31:629 [org.linphone/linphone-android] ERROR [Notifications Manager] Keep alive for third party accounts Service channel has been disabled, can't start foreground service!

It seems you have disabled the "keep alive service" notification channel, can you tell me why you did that?
Problem is it could impact the network capabilities of the app, as well as prevent it from staying alive in the background (and thus causing you to miss calls & messages).
If you knowingly don't want it, you can simply turn it off in advanced settings.

2025-09-03 14:48:31:637 [org.linphone/linphone-android] MESSAGE [Main Activity] Car connection is [NOT CONNECTED]
2025-09-03 14:48:36:599 [org.linphone/liblinphone] MESSAGE Account [0x413b103a00] ("My SIP" sip:manday@dom.ain) moving from state [LinphoneRegistrationNone] to [LinphoneRegistrationProgress] on core [0x46de826400]

There seems to be a huge delay here (5 secs) that may be due to your IPv6 DNS server.
Do you have the same behavior on another network? Did you try to disable IPv6 in the app's network settings?

[ManDay]

Thanks for the prompt investigation!

It seems you have disabled the "keep alive service" notification channel, can you tell me why you did that?

I disabled the notification because I did not want to be notified/informed about that. If disabling the information has other sideeffects besides disabling the notification, I did not intend that. I assume the (not stock) OS plays well without "workarounds" to keep background services alive, for that matter.

There seems to be a huge delay here (5 secs) that may be due to your IPv6 DNS server.

5 seconds sounds about right for the delay I experience. I do not have other networks or other SIP servers to try this with at the moment.

As I understand it, the DNS is somehow a prerequisite for something connection related. May I suggest that -- although it isn't "trying to connect" as you said -- it is still a sort of operation which would better not block the UI?

[ManDay]

I did disable IPv6 and it did not change anything about the delay.

[Viish]

I assume the (not stock) OS plays well without "workarounds" to keep background services alive, for that matter.

If that's the case (it can be), then I recommend you to disable the "Keep app alive in background using a service" toggle in advanced settings.

I did disable IPv6 and it did not change anything about the delay.

Thanks for the info.

I do not have other networks or other SIP servers to try this with at the moment.

When you do, and if it changes something or not, please let me know.

May I suggest that -- although it isn't "trying to connect" as you said -- it is still a sort of operation which would better not block the UI?

Yes you're absolutely right and I already opened an issue on our internal bug tracker to have one of my colleagues that know that area very well to take a look.

[Viish]

Hi @ManDay,

We haven't found in our SDK the part that may cause the freeze.
Did you had the chance to test on another network?

Thanks in advance.

[ManDay]

@Viish hi, I have not been able to test on another network and I don't think I will be able to, in the near future. If it helps, the server I see this with is the SIP Endpoint of a "FritzBox" WiFi router, which is a fairly popular consumer homeserver around Germany. Maybe that allows you to reproduce it.