Softphone for Android: let sleep or sleep deprivation?

To beep, or not to beep, that is the question:
Does it befit us — make the batteries suffer?
Or to take arms against a sea of troubles,
Let all of them not die but freely sleep;
To sleep, perchance to Dream.

This post continues the story about how we did a White Label mobile softphone. Here we tell how we solved the ‘sleeping’ issue.

It’s widely known that many mobile applications have problems with sleeping. Rather, specifically with this there is no problem: they fall asleep very well, immediately after minimizing. Then they sleep like a log and cannot wake up, it annoys and bothers. Besides, this is fraught with a loss of clients: if the softphone could not awaken, then the client does not reach so there is no call and lead, and we get zilch.

So if we are not going to miss calls like others, we have a luxurious choice of these two alternatives: 1) no sleep at all; 2) wake up at the right time.

Sleepless in Seattle Android

Really, why sleep if there is a chance to stay awake forever? Sleep is for sissies!; be a 24/7 party animal is the motto, I’m loving it! Looks realistic, development seems to be easy, Mr. Bean convincingly proved it.

Mr. Bean’s view of the situation

The only thing is to talk clients into digging battery settings, may they grant background activity, and the trick is done! Yes? Not really. For every problem there is a solution that is simple, neat, and wrong — this is the very case.

First, it's an inconvenience for customers, so this is the wrong way. Additionally, clients will unlikely appreciate cravings to greedy eating of batteries.

Battery’s sudden death is not what we are looking for

No use to join Belshazzar's Feast, we go the other way.

The server calls: stand up and fight!

Another idea came: a SIP proxy between the softphone and PBX — this is a way to kill two birds with one stone.

• Keep registration on the PBX side active despite the app’s sleep mode (fell asleep? OK, no problem).
• Wake the phone by push-notification when an inbound call comes.

Schematic diagram of an “alarm clock” and PBX registration keeping

Respectively, for iOS (let us remind you we have a White Label softphone for iOS too) we use Apple Push, and everything else in the scheme is the same: from PBX to Push-proxy via SIP/RTP, then to Push-server through HTTP. As for the softphone and proxy interaction, it runs via SIP/RTP too.

This is in a nutshell how we’ve won the ‘sleeping’ issue, so it goes. In case you missed the story about choice between native and cross-platform framework for mobile softphone development, just click and read this post.

And let the true mobility be with you 📱

YOU MAY ALSO LIKE

Blog Mobile softphone, fit for White Label: how we did it

---