Issue with MYCOLLAB 9.8.102 on Android 14: App Reconnects on Phone Lock

[kevger1]

Hello,


We are using MYCOLLAB 9.8.102 on our PIXEL smartphone with ANDROID 14. Despite testing all possibilities via the documentation, I can't get the application to consistently work during the phone's sleep or lock mode. When I lock and unlock the phone after 10 seconds, I see that the application is still running, but it goes through a reconnection process with a banner saying 'connecting' on the app. I'm desperate not to find the solution."

[lundah]

That's normal behavior since Apple and Google don't allow apps to run in the background.

[kevger1]

Hello Lundah,
o there's no solution other than disabling sleep mode or phone lock? It's quite problematic nonetheless...
When you say google and apple, its for IOS and ANDROID ? only the phone?

Thanks you

[lundah]

No. When the app is no longer in foreground it's basically closed and is reliant on push notifications to wake back up for an incoming call or notification. This is due to how Apple and Google require apps to work (or really not work) in the background.

[kevger1]

So I apologize for the question, but does this mean that the application is currently unusable when the phone is in sleep mode or locked?
Because I have tried everything on my phone and nothing wakes up the application, even when configuring the push notification system.
I apologize, but I am using translation and I just have a hard time understanding the response to know whether or not I can receive calls if my phone is in sleep mode or locked

Thank you again for your help!

[lundah]

So I apologize for the question, but does this mean that the application is currently unusable when the phone is in sleep mode or locked?
Because I have tried everything on my phone and nothing wakes up the application, even when configuring the push notification system.
I apologize, but I am using translation and I just have a hard time understanding the response to know whether or not I can receive calls if my phone is in sleep mode or locked

Thank you again for your help!

Yes. Mobile apps on iOS and Android do not actually run in the background in order to save battery and use less data. The app must use push notifications in order to wake up for an external request or notification.

[Dutch]

We have had months of contact with Mitel since januari especially concerning softphones during a big project.

The issues mostly were in the smartphone clients. I am sure we as a team (customer/us/mitel) had a big deal in the client going from 9.7.117 to 9.8.102 (103 for desktop) where it is now. I can only say the following:

Make sure ALL the clients are up-to-date!! This is not a choice!! iOS users we see update automatically whereas Android sometimes doesn't. You use Pixel. Make sure to Auto Update the client!

Thats a good start off and you will notice extensions remaining green. (it all has to do with push notifications and MBGs/MiVBs acting correctly in combination the the MiCollab. Not going into details but aside that for the latest MiVB version the MiVB will ignore people being offline for extended periods and the MiVB/MBG will still accept invites. Together with the new FCM API update this should resolve a lot.

You mention Pixel Phones which are Android. We see that Android (occasionally) is slower then Apple notifications but thats very scarcely and it can not be controlled. For UC endpoints this is fine. For ACD this could sometimes pose issues.

Basically the general idea now is make sure you have the latest MiVB. We currently use 9.7.110 for MiCollab and for us we only see issues sometimes with ACD. We set the No Answer Make Busy timer to 60 seconds in the COS to circumvent status changes due to delayed push. This kinda resolved the issue. UC Endpoints are fine but in case a push notification has a big delay and IF the user is working on a smartphone they will still receive the call assuming they have a good internet connection.

In the end its simple. If people have a phone job make them use the desktop client. Problem solved. Simple. Normal users with non-customer contacts eg non-acd will be fine.

As for the phones the new client will also ask for extra permissions during the first activation where the battery will want to be optimized. Unlimited will be the best solution as well as being able to have full access on the background and it circumvents deep sleep mode. Then you will see all is fine. We had the best experience with Samsung A5x as opposed to other Android devices. That said it can be situational. A good internet connection is key.

We have tested with phones being silent for a week and still got a good notification and ring on an Android phone.

In the deployment make sure you use TLS/SRTP Optional and port 5061. Use OPUS on the CODEC. You dont want to change the deployment profile with an active base. These settings work best since you deviate control to the MBG with the Optional Setting.

In the MBG make sure to use the SRTP or RTP setting for inbound. It will enforce SRTP when possible but it will allow RTP when applicable. Always use AVG+Crypto for outbound in combination with and 80 SHA1.

If you encounter issues you can now set a per user to RTP and avoid the encryption on traces so you can troubleshoot. All other users will remain to be encrypted. And for the test users you can analyse the traces and use them on tickets.

Long explanation. I hope it helps and I hope it doesnt come accross as too chaotic.

Cheers,

Dutch