Bit of an opinionated one today. After enough mobile VoIP work I've landed on a take I'll defend: push notifications are the single most important thing in a mobile softphone, and it isn't close.
Not call quality. Not the codec. Not the UI. Push. Because if the app doesn't reliably ring when a call comes in, none of the rest of it matters, and getting push right on mobile is harder than most people expect going in.
Sharing how I think about it, partly because I keep having this conversation and partly to see if anyone disagrees.
The core problem
Mobile operating systems suspend backgrounded apps. Aggressively. iOS and Android both do it to protect battery, and there's no arguing with them about it.
So the naive approach, keep a SIP registration alive in the background so the app is always reachable, just doesn't survive contact with reality. The OS freezes the app. The registration goes stale server-side. A call comes in, the server tries to route it to a client that's no longer listening, and the phone never rings. The user finds out hours later when they open the app and see a missed call that never actually rang.
I've watched entire mobile rollouts unravel over exactly this. The platform was fine. The SIP was fine. The softphone just wasn't reachable when it mattered.
Why push is the actual answer
Push flips the whole model. Instead of the app fighting to stay awake, the server sends a push notification the moment a call arrives, and the OS wakes the app on demand.
On iOS that means PushKit / VoIP push, reported into CallKit so the call comes up as a native call screen. On Android it's FCM into ConnectionService. The app only needs to be alive for the duration of the call itself, which is precisely what the OS is happy to allow. Work with the platform instead of against it.
Done properly, the user never sees any of the machinery. Their phone just rings. That's the goal, the whole apparatus disappearing behind a call that behaves like any other call.
The part people underestimate
Push isn't purely a client-side feature, and this trips people up.
The server side has to actually send the push when a call lands. On a platform like NetSapiens, that means the platform (or an SBC/proxy in front of it) fires the push to the device on an incoming INVITE. If that piece isn't wired up, you can have a flawless client implementation and still get nothing, because nothing woke the app.
So when push "doesn't work," the bug is often not where people look first. They dig into the client. The gap is on the server side, or in the handoff between them. Worth checking both ends before blaming the app.
The test that settles it
Forget spec sheets. "Supports push notifications" is close to meaningless as a claim. The only thing that tells you the truth is testing it.
Lock the phone. Wait an hour, long enough that the OS has fully suspended the app. Call it.
If it rings like a normal call, push is real. If it doesn't ring, or shows up late, the app is leaning on background registration the OS already killed. That's it. That one test has saved me from more bad softphone decisions than any amount of feature comparison.
Where this connects to the platform
For anyone building or picking a mobile softphone on NetSapiens specifically, this is worth taking seriously, because push reliability is one of the biggest differentiators between clients that all claim the same platform support. Some purpose-built options, like Tragofone's softphone with dedicated push handling, implement the APNs/FCM side properly by default rather than leaving it as an afterthought. Others vary, which is exactly why I run the locked-phone test on anything before it goes near production.
The takeaway
If you're evaluating or building a mobile softphone, sort out push first. Before the feature list, before the design review, before anything. Because a beautiful, feature-rich softphone that misses calls is a failed softphone, and a plain one that rings every single time is a working phone.
Everything else is negotiable. Push Notification isn't.
Anyone here landed somewhere different on this? Curious especially if you've found a clean way to test push reliability at scale, because the manual lock-and-wait approach still feels more tedious than it should be.
Top comments (0)