DEV Community: john william

The NetSapiens APIs that make a softphone actually feel integrated

john william — Wed, 01 Jul 2026 13:19:51 +0000

Been building and evaluating softphones on NetSapiens for a while, and I wanted to write something a bit more positive than my usual "here's what breaks" posts. Because the truth is, a lot of what makes a good NetSapiens softphone experience possible comes down to the platform exposing the right things through its APIs. When a softphone feels genuinely integrated rather than just registered, it's usually because someone leaned on these properly.

Sharing the API surfaces that actually matter, in case it's useful to anyone building on the platform.

Call history that isn't device-local
This is the one that changes the whole feel of an app. A basic SIP client stores call history locally on the device. Open the app on your phone and your desktop and you get two different histories, neither complete.

NetSapiens exposes call history through its API, which means a softphone can pull the user's actual call history from the platform rather than reconstructing it locally. Same history on every device. Make a call on your desk phone, see it in the mobile app. That's not a SIP feature, it's a platform-API feature, and it's the difference between an app that feels like part of the system and one that feels bolted on.

Voicemail and transcription sync
Similar story. NetSapiens holds voicemail centrally, and the API lets a softphone pull visual voicemail, play it, delete it, and have those actions sync back to the platform and every other endpoint.

If transcription is enabled on the platform side, the transcripts come through the same way. The softphone doesn't have to do any of the heavy lifting, it just surfaces what NetSapiens already has. When you delete a voicemail in the app and it disappears from your desk phone too, that's the API doing its job.

Contact and presence sync
NetSapiens exposes enterprise, private, and shared phone books through its API, plus presence. A softphone built around this can show the user their real directory with live presence, and push edits back to the platform.

The nice part is that the softphone becomes a window into the NetSapiens contact data rather than a separate island of contacts that drifts out of sync over time. Presence especially is one of those things that feels magic when it works and is entirely dependent on the platform exposing it cleanly, which NetSapiens does.

Click-to-originate across devices

This one is underused and genuinely clever. Because NetSapiens knows about all the devices registered to a user, the API lets a softphone originate a call from any of them, not just from itself.

So you can be in the mobile app, tap to call, and have the call actually ring out from your Polycom desk phone instead. The softphone is just the control surface. NetSapiens handles the origination on whichever device you picked. For people who live between a desk phone and a mobile app all day, this is a small thing that feels great in practice.

Answering rules and greetings from the app
NetSapiens lets a softphone read and modify a user's answering rules and voicemail greetings through the API. That means users can reorder their answering rules, record a new greeting, or change how their calls route, directly from the app, with the changes syncing back to the platform.

Most softphones don't bother implementing this, which is a shame, because it's one of the features that turns an app from "a thing I make calls with" into "the place I manage my phone."

The pattern: NetSapiens as the source of truth
The common thread across all of these is that NetSapiens acts as the single source of truth, and the softphone reflects it rather than trying to maintain its own separate state. Call history, voicemail, contacts, presence, device lists, answering rules, all of it lives on the platform and the softphone reads and writes through the API.

This is why softphones built around the NetSapiens APIs feel integrated and softphones that just register against it feel like a generic dialer that happens to be pointed at NetSapiens. The platform gives you the hooks. Whether the app uses them is what separates the two.

If you're building on NetSapiens, my honest advice is to lean into these APIs harder than you think you need to. Every one of them that you wire up properly makes the app feel more like part of the system and less like an accessory. Users notice, even if they can't articulate why.

Anyone else building on the NetSapiens API surface? Curious which endpoints you've found most worth the effort. (I went deeper on how these APIs shape a NetSapiens softphone here if it's useful.)

The point where Linphone stops working for production, and what people move to

john william — Mon, 22 Jun 2026 13:38:19 +0000

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.

5 tests I run on any softphone before deploying it on NetSapiens

john william — Tue, 16 Jun 2026 09:31:13 +0000

Sharing the actual test sequence I go through before signing off on a softphone for a NetSapiens deployment. These are the tests that catch the problems vendor demos hide. Posting in case it's useful to anyone doing the same, and because I'm curious what tests other people run that I don't.

Context: most of these came out of deployments that went wrong. Each test exists because skipping it cost me time at some point.

Test 1: Provisioning at realistic scale

Don't test provisioning with five accounts. Provision fifty or a hundred at once and watch what happens.

What I'm looking for:

Do all devices land on the same config version, or do some lag?
When I push a config change, does it propagate to everyone or just some?
After a credential rotation, do any devices keep authenticating with the old creds?

The failure mode this catches: softphones that work fine in small tests and fall apart when a reseller onboards a big customer in one batch. The "thundering herd" of simultaneous re-provisioning requests is where a lot of clients choke.

Test 2: The locked-phone push test

The single highest-value test. Lock the phone. Wait an hour. Call it from another number.

Does it ring? → Yes: push is probably implemented correctly
→ No: the client is relying on background registration
that the OS already killed

The clients that pass use proper APNs (iOS) and FCM (Android) with CallKit / ConnectionService. The ones that fail are trying to hold a persistent SIP registration alive in the background, which mobile operating systems shut down.

This one test eliminates more candidates than everything else combined.

Test 3: Network handoff mid-call

Start a call. Walk from Wi-Fi to cellular. Then back.

What I'm watching for:

Does the call survive the network switch, or drop?
Does audio cut out for a few seconds during the handoff?
Does it recover cleanly or stay broken?

Good clients do an ICE restart and keep the call alive. Weak ones drop it. This matters enormously for mobile users who move around during calls, which is most of them.

Test 4: White-label depth (not just a logo)

This isn't a technical test so much as a verification. Confirm the softphone ships under the reseller's own developer account, with their own app store listing, their own branding end to end.

The distinction that matters:

Co-branding: your logo on the vendor's app, shipped under the vendor's account
White-label: your app, your account, your listing, your brand throughout

For anyone building a branded service on NetSapiens, co-branding gives end customers near-zero switching cost. Worth confirming before you commit, because it's nearly impossible to change after deployment. (For reference on what genuine white-label NetSapiens integration looks like versus co-branding - useful as a comparison point even if you go with something else.)

Test 5: Vendor support response time

File a real support ticket during the evaluation. Time the response. Multiply by three for production behavior.

NetSapiens deployments generate edge cases. When something breaks at a bad hour mid-rollout, the vendor's response speed is the thing that actually determines whether you keep your customers happy. Nobody tests this during evaluation. Everybody wishes they had, later.

The pattern underneath all five
Most of these trace back to one idea: the NetSapiens platform is the easy, predictable part of the deployment. The softphone layer is where things actually break, because softphone clients vary wildly even when they all claim the same NetSapiens compatibility.

Two clients can both demo cleanly and behave completely differently at 300 users on real networks. The demo never shows you that. These tests do.

Over to the thread
What's on your list that's not on mine? I'm especially curious whether anyone has a cleaner way to test push notification reliability at scale rather than the manual lock-and-wait approach, because that one still feels more tedious than it should be. And for people running larger NetSapiens deployments, where does the softphone layer actually break for you first?

The NetSapiens inter-domain calling quirk that keeps showing up

john william — Mon, 08 Jun 2026 12:32:50 +0000

Quick share. Been running into this enough times across NetSapiens deployments that it's worth flagging.

Scenario: Call gets placed or transferred between two domains on the same NetSapiens platform. The call connects fine. Audio works. But the caller ID showing up on the receiving side is wrong. It's showing the local extension or domain user instead of the actual originating caller.

If you check the NetSapiens Known Issues page, this maps to NMS-2518. It shows up specifically when calls cross domain boundaries during hold or transfer.

The fallout is mostly cosmetic but it matters for anyone running multi-tenant reseller deployments. Your customer sees the wrong name in their call history. Voicemail attribution gets weird. Inter-domain analytics show calls from the wrong source.

A few patterns I've seen work around it:

Configure SIP header rewriting at the SBC layer to preserve the original From URI across domain hops
For softphones that pull call history from NetSapiens API directly, verify which field the client is actually displaying. Some pull from orig_user, others from local_user. The discrepancy shows up clearer than you'd expect.
If you're running a mobile softphone client, check whether the client is caching contact info locally and overriding what NetSapiens returns. A lot of "wrong caller ID" reports turn out to be client-side caching bugs, not platform bugs.

The deeper fix is platform-side and depends on what NetSapiens version you're running. The cleaner softphone integrations route call history through the NetSapiens API rather than building it locally on the device, which sidesteps the worst of this behavior.

White-label softphones that integrate natively with NetSapiens handle this more consistently than generic SIP clients. Tragofone is one example where the call history syncs through the NetSapiens softphone integration layer directly, so inter-domain caller ID is consistent with what the platform actually has. Other native integrations handle this similarly. Generic SIP clients that just register against NetSapiens without API integration tend to get hit by this more often.

Anyone else seeing this on their deployments? Curious if there's a version of NetSapiens where this got cleaner that I'm missing.

TIL: that "one-way audio" bug in SIP softphones is almost never a SIP bug

john william — Mon, 01 Jun 2026 13:12:12 +0000

Spent two days last week debugging what looked like a softphone issue. Calls would connect cleanly, both sides could see the call was active, but audio only flowed in one direction. Sometimes caller could hear receiver, sometimes the opposite. Inconsistent across users.

My first instinct, like most people's, was to blame the softphone. Switched clients. Same problem. Switched again. Same problem. That's when I realized I was debugging the wrong layer.

What was actually happening

SIP was working perfectly the whole time. Signaling went through, both endpoints negotiated codecs, the call set up cleanly. The break was in the media layer. RTP packets were getting dropped in one direction because of NAT timeouts on the user's home router.

Here's the sequence:

Call connects, both sides exchange ICE candidates
RTP starts flowing in both directions
NAT on one side creates a temporary mapping for the inbound RTP
NAT mapping expires (some routers do this in 30 seconds)
The other side keeps sending RTP packets to a closed door
One-way audio. SIP still thinks everything is fine.

This pattern shows up everywhere. Mobile VoIP deployments. Browser-based WebRTC calling. White-label softphones. The protocol layer doesn't matter. NAT will eat your RTP if the mapping isn't kept alive.

Things that actually fix it
A few patterns that work, depending on your setup:

RTP keep-alives: Send a small RTP packet every 20-30 seconds even when nobody's talking. Keeps the NAT mapping open. Crude but reliable.
ICE with TURN fallback: If STUN can't establish a peer connection, route through a TURN server. Adds some latency but solves NAT problems definitively. Run coturn or use a managed TURN service.
SBC in the path: A Session Border Controller sits between your softphone and the public network, handling NAT and media relay properly. Most production VoIP deployments end up doing this regardless of how their SIP softphone is configured.
Symmetric RTP: Configure the softphone client to send RTP from the same port it receives on. Helps in restrictive NAT setups.

Mental model shift
The shift that made this easier for me was treating SIP and RTP as two completely separate things that happen to ride together. SIP working fine tells you nothing about whether RTP is going to work. They're different protocols with different problems.

Now when I see one-way audio reports, the first thing I check is RTP path. NAT, firewalls, SBC config. The SIP softphone itself is almost never the actual problem, even when it looks like it is.

For mobile specifically
Mobile makes this worse. Cellular NAT is aggressive. Wi-Fi to cellular handoffs reset NAT mappings. Background apps lose their RTP path entirely if they aren't kept alive properly with push notifications.

This is why a lot of white-label softphone providers (Tragofone, Acrobits, CounterPath among others) ship dedicated push-driven architectures and RTP keep-alive defaults rather than expecting the client to maintain a persistent connection. Tragofone in particular handles this through their VoIP softphone with built-in push notifications approach, which is one of the cleaner implementations I've seen in production.

The auto-provisioning patterns that actually scale (and the ones that quietly break)

john william — Mon, 25 May 2026 12:59:36 +0000

Watched a deployment last month go from 40 users to 400 in about three weeks. The softphone itself handled the load fine. The provisioning system did not. Sharing what came out of that experience because auto-provisioning is one of those topics that looks simple in a demo and quietly falls apart in production.

Why naive provisioning falls apart fast

Most deployments start with what looks like a clean provisioning setup. A central config server, an HTTPS endpoint, devices pull their config on registration. Works great in testing. Holds together for the first hundred users or so.

Then it breaks in places nobody anticipated.

The patterns I've seen go wrong most often:

Thundering herd on restart: Every device tries to refetch config simultaneously after a network blip or server reboot. The config server gets hammered for a few minutes and some devices timeout and fall back to old cached config. Now you've got a fleet of devices running mixed config versions.
Cache poisoning: Devices aggressively cache config they pulled hours or days ago and refuse to recheck even after admin changes. Updates pushed from the dashboard don't take effect for some subset of users, and nobody knows which subset.
Stale credential rotation: SIP credentials get rotated for security, but a subset of devices keep authenticating with the old ones because they haven't pulled the new config yet. Looks like an auth issue when it's actually a provisioning lag issue.
Tenant config bleed: Multi-tenant deployments where one tenant's config accidentally gets served to another. Usually a templating bug, sometimes a caching bug. Either way, very bad.

None of these show up in test environments. All of them show up at scale.

Patterns that actually hold up
The provisioning setups I've seen survive real growth have a few things in common.

Versioned config with explicit invalidation:
Every config has a version. Devices send their current version on each registration. The server decides whether to send fresh config or a "you're current" response. Clean, cheap, predictable.

Pull, not push, with smart staleness windows:
Devices check for new config on their own schedule, not on a central push. The schedule includes some randomization so 1000 devices don't all check at the same second. Important config changes (credential rotation, codec changes) trigger a notification, not a full push.

Atomic config delivery:
Config gets delivered as a single atomic blob. Either the whole new config applies or none of it does. This prevents the half-updated device state that comes from delivering settings field by field.

Templating with strict scoping
Tenant boundaries enforced at the templating layer, not just at the routing layer. A tenant ID is included in every config lookup, and there's a hard check that nothing crosses tenant lines. Belt and suspenders.

Out-of-band verification
Devices report their active config version back to a monitoring system. You can see at a glance which devices are on which version. Stale devices become visible instead of mystery cases.

On the protocol layer
For SIP softphone provisioning specifically, you've got a few patterns that show up in the wild.

TFTP / HTTP / HTTPS pull: The classic pattern. Device boots, pulls config from a known URL based on its MAC address or username. HTTPS is the right default in 2026. Plain HTTP and TFTP should be gone from production environments. Both are unencrypted and there's no reason to keep using them.
DHCP option 66: DHCP delivers the provisioning URL during network negotiation. Useful for hardware phones especially. Less useful for mobile softphones where DHCP isn't part of the flow.
SIP-based provisioning: Provisioning happens through SIP itself, usually via SUBSCRIBE/NOTIFY or via custom headers in REGISTER responses. Works well for softphones because they're already maintaining SIP state. The disadvantage is the SIP server now also has to handle config delivery, which conflates two responsibilities.
QR-code provisioning for mobile: The mobile-specific pattern that's gotten more common. User scans a QR code, the app pulls full configuration in one shot. Great UX, fewer support tickets, harder to set up correctly than it looks.
Out-of-band activation tokens User receives a one-time token via email or SMS. App exchanges the token for full config. Good for security, slightly more friction at onboarding.

In practice, most production deployments mix two or three of these depending on the device type.

The encryption piece that people skip
Provisioning data contains SIP passwords. Encryption is not optional.

The things that should be on by default for any production provisioning system:

HTTPS with a real certificate (not self-signed, not expired, not wildcard if you can avoid it)
Per-device encryption keys where the provisioning data is sensitive enough
TLS for any SIP-based provisioning channel
No fallback to unencrypted protocols if HTTPS fails — better to fail closed than open

I've seen production environments with TFTP-based provisioning where SIP passwords were transmitted in cleartext over wired networks. The fact that it's a wired network doesn't make it secure. Anyone with access to the network can sniff and replay.

What good auto-provisioning looks like at the operator side

If you're running a service provider or operator deployment, the things that make day-to-day work bearable:

A dashboard that shows config version per device, not just per template
The ability to push a config change to a single user, a tenant, a group, or globally without redeploying templates
Audit logs of who changed what and when
A "test mode" where new config can be deployed to one device before pushing to a fleet
Rollback that actually works not "revert the template" but "restore the device to the config it was on yesterday"

Most provisioning UIs cover the basics. Few cover all of these well. It's worth checking the operator side of the system as carefully as the device side, because that's where the day-to-day work happens.

A few things to test before going live

Deploy to 10 devices. Verify all of them are on the same config version.
Push a config change. Wait for the staleness window. Verify all devices picked it up.
Reboot the provisioning server. Verify devices recover without manual intervention.
Rotate a SIP credential. Verify the new credential propagates and the old one stops working.
Push different config to two tenants. Verify there's no bleed.
Try to fetch one tenant's config from a device authenticated for another tenant. Verify it fails closed.
Disable HTTPS temporarily and verify devices refuse to fetch config over plain HTTP.

Run this whole thing on a real network, not localhost. Half the issues you'll find only show up over actual network conditions.

Auto-provisioning is one of those topics where everything looks fine until it doesn't, and then you're debugging a fleet of misconfigured devices at 11pm. The patterns that hold up at scale aren't magical. They're just careful about versioning, encryption, tenant isolation, and observability.

Why NetSapiens Integrations Feel Better When the Softphone Is Built Around the Platform

john william — Mon, 18 May 2026 13:13:56 +0000

Something I’ve started noticing in larger NetSapiens deployments is that generic SIP softphones usually work “fine” in the beginning… until teams start scaling.

That’s when small operational problems begin showing up:

separate provisioning workflows
voicemail sync inconsistencies
disconnected messaging
limited presence visibility
difficult mobile management
extra admin overhead And honestly, support teams usually end up spending more time managing the communication layer than the PBX itself.

The smoother environments I’ve seen are usually the ones where the softphone is deeply integrated into the NetSapiens ecosystem instead of acting like a standalone SIP client.

Especially when features like:

API-driven call history
centralized provisioning
presence sync
visual voicemail
WebRTC communication
multi-device continuity
queue management

all stay connected directly to the platform.

I also think softphone expectations changed completely after remote work became normal.

Users don’t just want “calling” anymore.

They expect communication to feel seamless across desktop, browser, and mobile without constantly thinking about the infrastructure underneath.

Things I’ve Started Noticing in Modern NetSapiens & Softphone Deployments

john william — Wed, 13 May 2026 12:42:46 +0000

A small thing I’ve noticed while working around VoIP and NetSapiens environments lately:

Most communication issues people blame on the “softphone” usually start somewhere else.

Sometimes it’s:

SIP ALG interference
unstable push notifications
NAT traversal
broken provisioning logic
network switching between WiFi/mobile
delayed registration refresh

The softphone UI gets blamed first because that’s what users see, but the actual issue often sits deeper inside the communication flow.

Another interesting shift is how quickly NetSapiens deployments seem to be moving toward softphone-first environments now.

A few years ago desk phones still felt mandatory.

Now many setups seem more focused on:

WebRTC
browser calling
mobile-first communication
API synchronization
centralized provisioning
presence/messaging sync

Honestly feels like the communication layer around hosted PBX platforms is evolving faster than most people realize.

TIL: most "audio cutting out" issues on SIP softphones are actually NAT problems

john william — Wed, 06 May 2026 12:31:20 +0000

Spent three days debugging a SIP softphone where audio would cut out exactly 15-20 seconds into every call. Switched softphones. Same issue. Switched networks. Same issue. Was about to blame the user's ISP.

Turned out it was NAT timeouts on the router silently killing the inbound RTP stream after the initial mapping expired.

The annoying thing is SIP signaling stays alive the whole time, so the call looks fine. Registration is fine. SDP exchange is fine. But the actual audio (RTP) gets dropped because one side's NAT mapping closes too aggressively.

Quick mental checklist for next time you see this:

Audio cuts out at a consistent time mark? → NAT timeout
One-way audio only? → NAT or firewall on one end
Works on Wi-Fi but breaks on cellular? → Almost always NAT
SIP signaling fine but media broken? → Look at RTP path, not SIP

Fixes that usually work: ICE, TURN, an SBC in front of things, or just configuring the softphone to send keep-alive packets so the NAT mapping doesn't expire.

Wish someone had told me this on day one. Sharing in case it saves someone else the three days.

Why I stopped trusting "free" SIP softphones for production work

john william — Mon, 04 May 2026 12:59:10 +0000

When I first started working with VoIP, I burned a few weeks trying to make free SIP softphones from the app stores work for production setups. Sharing what I learned, in case anyone else is going down the same path.

The problem wasn't that the apps were bad. Most of them work fine for casual use. The problem was that the things you don't notice in casual use become huge in production.

Push notifications were the first wall
Free SIP dialers usually keep a persistent connection alive to receive calls, which absolutely destroys mobile battery life. Real production-grade clients use push notifications properly through APNs and FCM. Without that, users miss calls or burn through their battery in three hours.

Background behavior on iOS:
iOS will quietly kill any app that isn't behaving the way the OS expects. CallKit integration is what makes incoming SIP calls actually show up like a normal phone call. Most free apps skip this step entirely. Calls technically arrive, but they look weird, ring weirdly, or don't ring at all if the phone is locked.

Encryption was an afterthought
A lot of the free clients support TLS and SRTP technically, but they're not on by default and the configuration is buried somewhere obscure. For any production setup in a regulated industry, that's a non-starter.

No real support when things break
This is the one that hurt the most. When something goes sideways at midnight on a Saturday, free apps don't have anyone to call. Forums and GitHub issues don't help when an enterprise customer is on the line.

I'm not saying free softphones are useless. They're great for testing, for hobby projects, for learning how SIP works. Just don't ship them to paying customers and expect things to be fine.

Anyone else have a "free softphone in production" story? Curious what others have run into.