The Kamailio deployments I've seen fall apart in production almost never failed because Kamailio itself is hard. They failed because the person who configured it didn't know what they didn't know. And by the time the symptoms showed up, the original engineer had usually moved on.
The hiring pressure right now makes this worse. Companies leaving CPaaS, voice AI startups standing up their own signaling layer, contact center platforms migrating off legacy switches. Demand for Kamailio talent is well past what the supply can cover. So teams settle. They take the candidate who has "Kamailio" on the resume and hope production will confirm the choice. Usually it doesn't.
Here's what bad Kamailio hires actually break.
The dispatcher that doesn't really dispatch
Dispatcher is the module that handles load balancing across multiple destinations (SIP servers, media gateways, application servers). The default configuration looks deceptively simple. Call ds_select_dst, set a list, pick an algorithm.
What an inexperienced engineer ships: dispatcher with algorithm 4 (round robin), no active probing, no failover logic in failure_route. It "works" in testing because all destinations are up. In production, when one destination flaps, calls disappear into the dead destination for the full retry window. Nobody on the team knows where the calls went.
What it should look like: probing enabled with realistic intervals (usually 30 to 60 seconds), gravity weighting if destinations have different capacities, failover handler in failure_route that re-selects and retries on a 503 or transport timeout, and SIP OPTIONS responses validated against expected codes.
Junior engineers ship the first version. Senior engineers ship the second.
Dialog state leaks
The dialog module tracks active calls. Under load it can leak memory if dlg_manage and the corresponding profile cleanup aren't wired correctly. The symptom is subtle. Kamailio runs fine for days, then memory usage starts climbing, and eventually the process is killed by the OOM handler.
I've seen this exact pattern on three different deployments. All built by engineers who had used Kamailio for proxy work but never operated it long enough to hit the leak. The fix is basic once you know what you're looking at. Knowing what to look at is the hard part.
TLS that breaks on certificate rotation
Kamailio's TLS module loads certificates at startup. Many engineers don't realize that a config reload doesn't reload the cert. So when the certificate rotates (and modern carriers and SBCs rotate frequently), Kamailio keeps presenting the expired cert until someone restarts the process.
The right pattern is a tlsops based reload, or a managed restart on cert rotation with proper drain handling so in-progress dialogs survive. Engineers who haven't operated production TLS deployments at scale rarely think about this until it breaks during an audit or a carrier hand-off.
RTPEngine that loses media at boundaries
When Kamailio is proxying SIP and RTPEngine is handling media, the rtpengine_offer and rtpengine_answer calls need to fire in the correct routing context. Bad implementations call them in the wrong route or skip them on reINVITEs.
Symptom: one-way audio after hold/resume. Or audio that drops thirty seconds into a call when re-negotiation happens. Both are signs that the engineer wrote the happy path and never tested codec change or hold scenarios.
The interview signals that actually filter
When you hire Kamailio developers, the resume screen catches almost nothing. Everyone lists the same modules. Everyone has a project where they "implemented SIP routing." The differentiator shows up in the interview.
Questions that work:
- Describe a production failover you operated. Walk me through what the failure was, what Kamailio did, and how you fixed it. (Real operators have stories. Reciters don't.)
- How do you handle dialog cleanup when a backend disappears mid-dialog? (Tests dialog module depth.)
- What's the difference between branch_route and onreply_route for failure handling? (Trivial for senior engineers, hard for fakes.)
- Walk me through how you'd debug one-way audio in a Kamailio plus RTPEngine setup. (Forces specific diagnostic steps, not generic talk.)
- What's your monitoring stack for Kamailio? (If they don't mention sipcapture, homer, or Prometheus exporters, they haven't run production.)
Candidates with real Kamailio depth will give you five to ten minutes of detail on each of these. The ones who don't will give you thirty seconds of textbook language.
When direct hire isn't working
If you've been running this interview for two months and haven't found anyone, the talent pool isn't going to magically improve. That's the moment to consider a specialist firm that can build the SIP layer for you and hand it over once stable. It costs more in the build phase. Over 18 months, factoring in the cost of a bad hire and the recruiting time, it usually comes out lower.
Hire VoIP Developer's Kamailio team is one option that follows this pattern. They build Kamailio, OpenSIPS, and FreeSWITCH stacks for telecom and B2B SaaS clients, and the engagement model maps cleanly to a build-then-handover approach. Worth evaluating if direct hiring is stalling out.
The hiring market for Kamailio talent isn't going to get easier in 2026. The teams that find a workable path early are the ones that actually ship.
Sign in to leave a comment.