User Option: Stay registered in background before/during/after user profile switch (maintain connectivity while using alt profiles for app isolation)

[pipe2null]

Many people with multi-user support on their devices use different user profiles simply to isolate different groups of apps from each other especially on de-googled phones like GrapheneOS. For apps that should probably be system apps like a default Voip app, maintaining connectivity is important when bouncing between profiles. Personally, I think voip should be built into the OS similar to the way normal 3/4/5G cellular connectivity/phone/SMS/etc and system phone app is, and owner can always install a separate voip app if needed, but the OS does not have built-in support for a default voip app ATM that reasonably handles a multi-profile environment.

Problem:
Baresip does not remain fully functional during a switch to another user profile, and does not automatically re-register when returning to the original profile. Exactly same behavior as previous issue:

#489

Other apps like WG and Linphone are able to maintain connectivity in background while other user profiles are active, and never lose connectivity, nor do they need to be restarted or manually re-registered after returning to the original profile. So it is possible for Baresip to optionally work this way.

Request:
Please add an option similar to a sub-option for "Start Automatically", that will persist Baresip fully functional in the background even when switched to another user profile, and especially continues to be registered when switching back to the original profile. Of course, please provide the disclaimer RE implications of using this feature.

I am willing to put $ toward a used Pixel 7a or something similar for dedicated GrapheneOS development/compat testing/etc, if this will help implement this feature, especially if seriously considering implementation of other requested features. Thanks!

[juha-h]

I could consider (time permitting) to implement quitting the app when switching to another user and then restarting it when switching back. But the idea that a call comes in for a user when some other user is currently active, is not good.

[pipe2null]

OS optionally allows some phone, sms, notifications, etc to get forwarded to the active profile for built-in phone/sms, but phone/sms still remains active in background regardless while in a different profile. So baresip optionally staying fully functional in the back ground while another app/user profile is active is the closest to normal phone/sms behavior presented by the OS for multi-profile/user configurations.

And if the phone rings while in a different profile or an SMS notification dings, if you can switch back to owner profile quickly enough, you can still answer the call. This specific scenario has happened to me several times within the last month, unfortunately Linphone is not reliable for me even though it handles switching user profiles similarly to the OS by staying operational and ringing within the installed profile even if different profile is active. And yes, I was able to switch profile quickly enough to answer the call, although linphone's mic tends to stop working after a few minutes during important calls.

Of course, if you are sharing your phone with a stranger off the street, or 5 different people are literally sharing the same phone, then optionally it would make sense just to shut down while another physical person is using the device. But it does not make sense to shutdown when there is only one physical person-user who has apps sectioned off into different profiles for app isolation. Or a parent doesn't want to miss a call from work while their kid is using a separate locked down profile.

However switching profiles is handled or not handled, baresip should be operational starting at boot (if the option is checked) and stay operational unless explicitly quit by the user. At least while the installed-in profile is active or after switching back to that profile. But, also, optionally, while other profiles are active as presented above.

It is also worth noting that if baresip does not keep running, there is no way to detect a missed call.