I like Linphone. I want to say that up front, because what follows is going to read like criticism and it isn't, exactly. Linphone is free, open source, speaks SIP properly, and runs everywhere. For testing a SIP setup or running something small, it's one of the first things I reach for.

But I've watched a few teams try to run a real product on it, and there's a fairly predictable point where it stops being the right tool. Sharing where that point is and what people tend to move to, because I keep having this conversation and figured I'd write it down once.

Where it actually breaks: mobile push

The first wall almost everyone hits is incoming calls on mobile.

Here's the mechanism. To receive a call, a SIP client has to be reachable. On desktop that's easy, the app is running, the registration stays alive, calls come through. On mobile it's a different game entirely. iOS and Android aggressively suspend backgrounded apps to save battery. A softphone trying to hold a persistent SIP registration alive in the background loses that fight. The OS freezes the app, the registration goes stale, and an incoming call routes to a device that never rings.

The fix is push-based wake. The server (or an SBC in front of it) sends a push via APNs on iOS or FCM on Android, the OS wakes the app, and the call gets handled, ideally through CallKit and ConnectionService so it looks like a native call. This requires real push infrastructure on the server side, not just client config.

Linphone has push support, but how reliably it works end to end depends heavily on your setup, your flexisip configuration, and how much you want to operate that infrastructure yourself. For a hobby setup, fine. For a business where a missed call is a lost customer, "depends on your setup" is not a great place to be.

The other walls

Push is the first wall but not the only one.

Branding: Linphone is Linphone. If you're shipping an app to your own customers, you can fork the open-source code and rebrand it, but now you own a fork: you're maintaining a softphone codebase, tracking upstream changes, and shipping to the app stores yourself. That's a real engineering commitment most teams underestimate.

Support: When something breaks in production at a bad hour, your options are community forums and your own debugging. That's the deal with free software and it's a fair deal, but it's not what a business running on its phone system usually wants.

Provisioning at scale: Configuring a handful of clients by hand is fine. Centrally provisioning hundreds of users with managed config is a different problem, and not one a general-purpose open source client is built to solve cleanly.

What people move to

The honest answer is "it depends on why you hit the wall," but the options sort out roughly like this.

If you forked Linphone for the branding and are now drowning in maintenance, the move is usually a white-label softphone that someone else maintains. You get your branding, your app store listing, your push infrastructure, without owning the codebase. with native SIP and WebRTC, push handling built in, and full white-label branding; their Linphone alternatives writeup lays out the comparison from their angle if you want it. Acrobits and Bria are also in this space with different tradeoffs.

If you just need a better desktop client, MicroSIP (Windows) or Zoiper are simpler moves and might be all you need.

I wrote up the full business-side comparison of the alternatives separately, including who each one actually fits, over here on Medium if you want the non-engineering version to send to whoever signs off on the decision.

The takeaway for anyone building on SIP

None of this is Linphone being bad. It's Linphone being free and general-purpose, which is a different thing from being a maintained, supported, branded product. Those are real costs that someone has to carry, and with open source that someone is you.

If you're early, building, experimenting, Linphone is great and you shouldn't overthink it. If you've hit the mobile-push wall, or you're forking for branding and feeling the maintenance weight, or you need someone to call at 2am, that's the signal that you've outgrown the free tool and it's time to look at what you're actually willing to pay for: money, or your own engineering time. Pick one honestly.

Anyone else gone through this transition? Curious whether people forked and regretted it, or moved to something commercial and wished they'd just maintained the fork. I've seen both, and I'm not sure there's a universally right answer.