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.

Forem: john william

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

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