DEV Community: Jack Morris

What I Learned Trying to Hire Kamailio Developers for a Production SIP Project

Jack Morris — Wed, 27 May 2026 05:39:28 +0000

We needed two Kamailio engineers. That's it. Two people who could build a production SIP proxy layer for our platform. I figured it would take a month to fill both roles.

It took seven months. And we only filled one.

Here's what nobody told us going in: Kamailio is not Asterisk. The talent pool is tiny. Most VoIP engineers you'll find on job boards have Asterisk or FreeSWITCH backgrounds. Kamailio-specific skills like dispatcher module configuration, dialog management, TLS setup, and custom routing scripts are a different category entirely. The overlap between "has worked with VoIP" and "can build a production Kamailio SIP proxy" is smaller than you'd expect.

We posted on LinkedIn, Stack Overflow Jobs, and three VoIP-specific forums. Plenty of applicants listed "Kamailio" on their resume. But when we asked about production scenarios, like how they'd handle active-active failover with shared registration state, or debug a 407 loop between two SIP proxies, most couldn't get past surface-level answers.

The engineers who could were already employed at telecom companies or VoIP consultancies and weren't looking. The few who were open to conversations wanted $180K+ and had zero interest in contract work.

After four months of searching, we changed approach entirely. Instead of trying to hire Kamailio developers from scratch, we started evaluating whether a Kamailio development company could handle the initial build while we continued the internal search at a slower pace.

The logic was straightforward. We needed the SIP proxy layer built and running in production. We did not need two full-time Kamailio engineers on payroll for the next three years. The heavy engineering was in the build phase. After that, maintenance would be lighter. Maybe 10 to 15 hours a month.
We ended up working with a specialist firm. They built the routing layer, configured dispatcher for load balancing across our application servers, set up TLS between internal services, and deployed the stack on Kubernetes. Three months from kickoff to production traffic.

What surprised me was the handover. Their team spent a month training our one internal engineer (the hire we did manage to make) on the codebase and operational playbook. By the end, he could handle routine config changes, dialplan updates, and basic troubleshooting solo. For anything bigger, we kept the firm on retainer at a fraction of what a second full-time hire would have cost.

Looking back, I'd skip the seven-month hiring cycle entirely next time. If your team doesn't already have Kamailio expertise, trying to hire Kamailio developers from zero while simultaneously scoping the project is a recipe for lost time and a delayed launch.

If the SIP proxy supports your platform rather than being the product itself, a Kamailio development company like Hire VoIP Developer can get you to production faster than building an internal team from scratch. That's not a knock on in-house teams. It's just the reality when the talent pool is this small.

Curious how others have handled this. Did you build your Kamailio layer in-house or outsource the initial build? What was the timeline like?

Things they don't tell you about building (or buying) an SBC

Jack Morris — Wed, 20 May 2026 12:09:25 +0000

Was helping a friend's team evaluate Session Border Controller options recently, and the conversation reminded me how much weird, undocumented knowledge SBC work involves. Sharing some of it here because most of the public material out there is either marketing brochures or RFC walls of text.
This isn't an intro to what an SBC does. If you're reading this you probably already know it sits at the edge of a VoIP network and handles NAT, security, interop, and a few other things. The point of this post is the stuff that bites you only after you've actually deployed one.

1. "Just put an SBC in front of it" hides a lot of complexity
Half the SIP advice on the internet ends with "put an SBC in front of it" as if that's a one-step fix. It isn't. The SBC is the thing that does the hard work, which means all the complexity that was hiding in NAT, codec negotiation, and SIP normalization now lives inside the SBC config instead.

A poorly configured SBC will silently break calls in ways that look like softphone bugs, network issues, or even DNS problems. Spent two weeks once chasing a "softphone bug" that turned out to be the SBC stripping a SIP header that the downstream PBX needed.

Lesson: when something breaks weirdly, suspect the SBC first, not last.

2. SIP normalization is where most real-world deployments live
Different SIP devices, providers, and softphones implement SIP slightly differently. Polycom does one thing. Yealink does another. Some softphones add custom headers. Some carriers expect a very specific From header format. Some downstream PBXes choke on whitespace in odd places.

A serious chunk of SBC configuration is just "rewrite this SIP message into the format the next hop expects." It's not glamorous. It's not what the marketing slides talk about. But it's where 60% of real SBC tuning time goes.

If you're building or configuring one, get comfortable with header manipulation, URI rewriting, and SDP modification early.

3. Topology hiding is more than a buzzword
Every SBC vendor talks about topology hiding. What they mean in practice is: rewriting Via headers, Record-Route headers, From and To URIs so the other side can't see your internal infrastructure.
Important because:

Exposed internal IPs help attackers fingerprint your setup.
Some attackers specifically target SBCs they can identify by vendor banner.
Some downstream networks reject calls that show internal routing hops.

In production, every outgoing call should look like it's coming from the SBC's public IP and nothing else. If you're seeing internal IPs leak in production traffic, your topology hiding is broken regardless of what the config screen claims.

4. Fraud is real and it happens fast
The first time you put a public-facing SBC into production, you will see scan traffic within minutes. SIP scanners are constant, automated, and aggressive. They'll try every common extension, every default password, every well-known account name.

If you have a misconfigured registration endpoint or an open trunk, fraud calls can start within hours. International premium rate numbers. Calls to obscure country codes that nobody at the company has ever called. The bill arrives at the end of the month, and it's usually large.

Defenses that actually matter:

Disable anonymous trunks completely
Rate-limit registration attempts per source IP
Block geographically (most fraud comes from specific country ranges)
Block international dialing patterns by default and whitelist countries individually
Monitor for unusual call patterns in real-time, not in monthly reports

Don't trust the vendor's defaults. Audit them yourself.

5. RTP is where the "interesting" performance problems live
SIP signaling is small. RTP is constant, real-time, and bandwidth-heavy. Most SBC performance issues at scale are actually RTP path issues.

Things that matter:

Whether the SBC is doing media anchoring (relaying RTP) or just signaling
Codec transcoding cost (Opus to G.711 conversion is CPU-expensive, do it sparingly)
Jitter buffer behavior under load
DTLS-SRTP handshake performance for WebRTC calls

A signaling-only SBC scales easily to thousands of concurrent registrations. The moment you start anchoring media or transcoding codecs, hardware budgets change drastically.

If you're sizing infrastructure, model your transcoding load carefully. It's the thing that most often surprises teams in production.

6. WebRTC support is harder than it looks
If your SBC needs to bridge WebRTC clients to traditional SIP, you're

signing up for a different category of complexity.
WebRTC uses DTLS-SRTP, traditional SIP usually uses plain SRTP or unencrypted RTP.
ICE candidates need to be properly translated to/from SIP/SDP.
Some browsers behave differently in edge cases.
WebSocket connection management adds another layer of state to track.

A lot of older SBCs were retrofitted for WebRTC and it shows. If WebRTC matters to your deployment, test it explicitly with realistic scenarios, not just "it connected once."

7. Logs grow faster than you expect
An SBC at production volume will generate gigabytes of logs per day. SIP messages, RTP statistics, security events, performance counters. You need a real log pipeline.

Send logs to a centralized system (ELK, Loki, Splunk - whatever your team already uses)
Set retention policies before you fill up disks
Be ready to capture full SIP traces selectively when something breaks, because debugging without traces is misery
Watch your log levels - debug logging in production will crush both disk and CPU

The teams I've seen do this well treat the SBC like any other production service: monitoring, alerting, dashboards. The teams that don't, end up chasing problems blind.

8. Open source vs commercial isn't a binary choice
Common open-source SBC options: Kamailio (often configured as one), OpenSIPS, drachtio (programmable, Node.js-based). Commercial options: AudioCodes, Oracle (Acme Packet), Ribbon, Sansay, and several others.

The honest tradeoffs:

Open source: total control, zero license cost, but you own all the operational burden
Commercial: support contracts, certified hardware, but expensive and sometimes inflexible

A surprising number of large carriers run open-source SBCs in production. Kamailio in particular powers a huge amount of real-world VoIP infrastructure that you'd think runs on commercial gear.

Pick based on your team's expertise, not just the feature checklist.

Closing
SBC work is one of the more underrated parts of VoIP infrastructure. It's not glamorous, the documentation across the industry is patchy, and a lot of the real knowledge lives in the heads of engineers who've debugged enough production issues to know which questions to ask.
If you're getting started with SBC development or evaluation, the best advice I can give: don't trust the defaults, test under real network conditions, and assume fraud will find you within hours of going live.

If you've shipped SBC work and run into things I haven't covered, comments are open. Always interested in comparing notes on this stuff.

We Spent 9 Months Fighting Our CPaaS Bill Before Hiring a Custom VoIP Development Company. Here's What I Learned.

Jack Morris — Tue, 12 May 2026 12:21:54 +0000

Last year I was the engineering lead at a B2B SaaS that was supposed to do "smart calling" for outbound sales teams. Click-to-call from the CRM, AI transcription, call routing based on lead score, the usual stack you'd expect in 2024.

We chose a major CPaaS provider because nobody gets fired for picking the obvious one. The docs were great, the SDK worked in twenty minutes, and the pricing calculator told us we'd spend around $2,400 a month at our projected scale.

Nine months later, we were burning $14,000 a month, our call quality was degrading during our biggest customer's peak hours, and I was on a call with a custom VoIP development company explaining why we needed to migrate. This is the story of what went wrong, what I should have caught earlier, and what I'd do differently if I were starting over.

The first six months looked fine. We integrated their voice API for outbound calls, used their programmable calling SDK for the dialer logic, hooked up their conversation module for transcription, and stitched it all into our React frontend with the JS SDK. Our first big customer onboarded with 80 seats. By month three we had 600 seats across 14 companies. Our AWS bill was reasonable. The CPaaS bill was about $4,000 a month, not bad.

Then we started hearing about "the slowdown." Our biggest customer, a 200-person inside sales team, was telling us that calls between 2pm and 5pm Eastern were getting lower call quality. Latency was up. Some calls were dropping. Their VP of Sales was getting calls about it.

I spent two weeks chasing it. Our backend was fine. Our React app was fine. Our network was fine. The only common factor was the CPaaS layer. We opened a support ticket. They told us our usage profile was "inconsistent with optimal performance" and suggested we move to a higher-tier SIP trunk. The higher-tier trunk would have moved our monthly cost from $4,000 to about $9,000.

That was the first crack

The second crack came when we tried to add custom features. The CRM team wanted call recording stored in our own S3 buckets with custom retention policies. The CPaaS recording storage was fine for compliance, but we couldn't run our own ML models against the recordings without pulling them out and re-uploading them. The serverless function tier had hard limits that meant we were running half our call control logic in our own AWS Lambdas anyway, which added latency we couldn't optimize.

The third crack was the contract terms. As we grew past 800 seats, we needed predictable per-call costs to model our gross margins. Their pricing scaled in ways that didn't map cleanly to our unit economics. Every percentage point of margin compression hit our Series B forecasts.

That's when I started looking into what a custom VoIP development company actually does, and whether building on Asterisk or FreeSWITCH instead of a CPaaS would solve our problems.

What I learned during that research phase changed how I think about VoIP infrastructure

Building on FreeSWITCH, Asterisk, or Kamailio is not the same as building a VoIP company. You're not trying to become a phone company. You're building a piece of your product that happens to use VoIP protocols. The question isn't "can we build this?" It's "do we have the protocol-level expertise in house to debug it when it breaks at 2am during our customer's peak hour?"
The honest answer for us was no. None of our six engineers had ever written a Kamailio config file or debugged a SIP trace. Hiring someone full-time who had would cost us about $180,000 plus equity, and we'd still need at least two of them for redundancy.

That's the actual value of working with a specialist VoIP team. You're not buying code. You're buying production debugging experience that takes 5 to 10 years to accumulate. You're buying the engineer who's already seen the specific NAT traversal failure that's about to take down your platform, and knows exactly which RTPEngine flag fixes it.

We engaged a team that built a custom VoIP stack on top of FreeSWITCH and Kamailio. They handled the SIP trunk negotiations with our carrier directly, which saved us about $3,000 a month in trunk costs alone. They set up our own RTPEngine cluster for media handling, which dropped our call quality complaints by 92%. They built our recording pipeline directly against our S3, eliminating the round-trip we'd been doing through the CPaaS cloud.

The migration took about four months. The cost was a one-time build plus ongoing maintenance retainer, which together came out cheaper than our previous CPaaS bill within seven months.

Here's what I'd tell my past self
CPaaS is not wrong. It's a great fit for the first 12 months when you don't know what your call volume looks like, what your customers will actually demand, or whether your product will even work. The mistake we made wasn't choosing a CPaaS. The mistake was not knowing what the migration signals were, and not having a plan for what comes after CPaaS when your unit economics or feature requirements outgrow it.

The questions to ask yourself are simple. Are you paying more than $8,000 a month in CPaaS fees? Do you have feature requirements that don't map to your provider's API? Is call quality becoming a customer complaint? Are your unit economics getting worse as you scale instead of better? If two or more of these are true, it's probably time to talk to people who build custom VoIP infrastructure for a living.

The decision isn't between CPaaS and DIY. It's between renting infrastructure that someone else has optimized for the general case, or bringing in engineers to build infrastructure optimized for your specific case. Both are valid. Which one is right for you depends on where you are in your scale curve.

If you're staring at a growing CPaaS bill and wondering whether there's a better way, there usually is. Just make sure you talk to engineers who've shipped VoIP infrastructure at scale before, not generalist dev shops who think they can figure it out.

For what it's worth, the team we ended up working with is Hire VoIP Developer, a B2B custom VoIP development company that handles Asterisk, FreeSWITCH, Kamailio, OpenSIPS, and WebRTC builds end to end. There are other good ones out there too. The important thing is that you're working with people who've already debugged the failure modes you're about to hit.

Why Most VoIP Call Center Solutions Break at 100 Agents (And What Actually Scales)

Jack Morris — Tue, 05 May 2026 12:16:26 +0000

Working on call center infrastructure for the last few years has taught me something most vendor pitches won't tell you. The architecture decisions that work fine for 30 agents fall apart somewhere between 100 and 200 agents. And nobody warns you about it until you're already there.
This is a write-up of the actual technical decisions that matter when building VoIP call center solutions that hold up under real load.

The 100-Agent Wall
Most teams pick their VoIP call center solution based on feature checkboxes. The demo looks great. The pricing seems reasonable. They go live with 30 agents and everything's fine for months.
Then the team grows. Around the 100-agent mark, things start getting weird. Calls drop intermittently during peak hours. Reports take forever to generate. Database queries that ran in milliseconds now take seconds. Reps complain that the dashboard is "slow" without being able to point to a specific issue.
What's actually happening is that the architecture wasn't built for that load. Most off-the-shelf platforms scale fine vertically up to a point, then need fundamental architecture changes that vendors quietly charge extra for or punt on entirely.
The teams that scale past this wall make different decisions early.

Architecture Decisions That Actually Matter
Here's what I've found separates VoIP call center solutions that scale from those that don't.

1. Signaling and Media Separation
The single biggest architectural decision is whether your stack separates SIP signaling from media handling. PBX-style architectures (Asterisk, FreeSWITCH alone) handle both in the same process. SIP-proxy-fronted architectures (Kamailio or OpenSIPS in front of media servers) separate them.

For under 50 agents, monolithic Asterisk works fine. Past that, you need separation:
Carrier --> Kamailio (SIP signaling) --> FreeSWITCH cluster (media) | v RTPEngine (media relay/NAT)

This separation lets each component scale independently. Kamailio handles thousands of registrations on a single node. FreeSWITCH handles a few hundred concurrent media sessions per node. You scale the bottleneck, not the entire stack.

2. Database Architecture for Real-Time State

Here's where most VoIP call center solutions secretly fall apart. Real-time agent state, queue position, call routing decisions - all of this lives in some kind of state store. The default in most platforms is "throw it in MySQL" or "use whatever the platform provides."

That works fine until it doesn't. Production-grade setups separate concerns:

Hot data (real-time state) → Redis or Memcached for sub-millisecond reads
Warm data (active call records) → MySQL or PostgreSQL with read replicas
Cold data (historical CDRs, recordings) → Object storage (S3) + analytical database (BigQuery, Redshift, ClickHouse) for reporting

When your reports start timing out at 200 agents, this is almost always why.

3. Multi-Tenant Architecture (If You're a Service Provider)
If you're building VoIP call center solutions for a BPO, MSP, or as a white-label product, multi-tenancy is the architectural decision that breaks teams.

Three patterns I've seen:

Pattern A - Shared everything: One database, tenant_id columns everywhere. Cheapest to build, most fragile in production. One bad tenant query takes everyone down. Not recommended for compliance-heavy industries.

Pattern B - Shared infrastructure, isolated data: Separate databases per tenant, shared application infrastructure. Good middle ground. Tenant data is isolated, but you can still scale the app layer horizontally.

Pattern C - Fully isolated: Separate everything per tenant — separate Kamailio configs, separate media servers, separate databases. Most expensive, most secure. Required for some regulated industries.

The right choice depends on your tenant size, compliance requirements, and operational complexity tolerance. There's no universal answer.

4. WebRTC for Browser-Based Agents
By 2026, hardware desk phones for call center agents make less sense than they used to. WebRTC softphones running in the browser are the default for new builds. The architecture pattern is:

Agent browser (WebRTC) --> WebSocket gateway --> SIP server | v Media server

The hidden complexity is NAT traversal, codec negotiation, and browser update churn. Teams that go live with WebRTC and don't invest in proper monitoring find out about issues from agents complaining, which is the worst possible failure mode.

If you're building this from scratch, budget for proper rtpengine or mediasoup deployment alongside the SIP infrastructure. WebRTC fails in subtle ways that are very hard to debug retroactively.

5. CRM Integration Depth
Every VoIP call center solution claims CRM integration. The depth varies wildly.
Surface-level integrations do click-to-call and basic call logging. That's table stakes. Real production integrations handle:

Custom field synchronization (Salesforce custom objects, HubSpot custom properties)
Workflow automation triggered by call events (lead scoring updates, case creation, campaign enrollment)
Two-way data sync with conflict resolution
Bulk historical data import for reporting consistency
Audit trails for compliance requirements

The depth of integration usually correlates with whether the platform was built API-first or SDK-bolted-on. API-first platforms support deeper integrations natively. SDK-bolted-on platforms hit limitations fast.

What Production-Grade VoIP Call Center Solutions Look Like

Putting this together, here's what a well-architected VoIP call center solution looks like in 2026:

Signaling layer: Kamailio or OpenSIPS handling SIP routing, registration, and load balancing. Multiple nodes for HA.

Media layer: FreeSWITCH cluster (or Asterisk for specific use cases) handling actual media. Separated from signaling. Scales horizontally.

Application layer: Custom logic for routing, queues, agent skills, IVR, recording. This is where the business logic lives.

Integration layer: API-first design. Native CRM integration (Salesforce, HubSpot, Zoho). Webhooks for everything. Open APIs for custom integrations.

State management: Redis for real-time state. PostgreSQL or MySQL with read replicas for active data. Object storage for recordings. Analytical database for historical reporting.

Edge security: Session Border Controller (Kamailio configured as SBC) at the network perimeter. TLS for signaling, SRTP for media. Rate limiting. Toll fraud detection.

Monitoring: Real-time metrics (Prometheus + Grafana), SIP capture (Homer), media quality monitoring, automated alerting.

This is what separates production deployments from "works in testing" deployments.

The Build vs Buy Reality

After working through enough deployments, I'll be honest about when each approach makes sense.

Off-the-shelf VoIP call center solutions like Five9, Genesys, RingCentral Contact Center, and Talkdesk work fine for businesses with under 50-100 agents and standard workflows. The per-seat economics are reasonable, the integrations are decent, and the operational complexity is low.

Custom-built VoIP call center solutions become the better choice when:

Per-seat pricing has become punishing at your scale (usually past 100-150 active users)
You're a service provider yourself (BPO, MSP, white-label reseller)
Compliance requirements exceed standard SaaS configurations
Your workflow is your competitive advantage and SaaS forces you to compromise it
You're integrating voice into a custom product where it's a core feature

For these scenarios, custom development typically pays back within 18-24 months and continues delivering savings indefinitely after that.

Closing Thoughts

The architecture decisions you make at 30 agents shape what happens at 300 agents. Most teams pick their VoIP call center solution based on what looks good in the demo, then spend the next two years working around its limitations.

The teams that scale past the 100-agent wall make architectural decisions early that off-the-shelf platforms force you to compromise on. That's not a critique of off-the-shelf solutions — they're the right choice for plenty of use cases. It's just an honest acknowledgment that they have ceilings, and those ceilings hit faster than most teams expect.

If you're architecting a call center stack right now and want to compare notes on specific architectural decisions, drop a comment below. Always interested in how other teams are solving these problems.

I work on custom VoIP infrastructure with the team at Hire VoIP Developer, focused on VoIP call center solutions for telecom operators, BPOs, and enterprises. Mostly Kamailio, FreeSWITCH, and WebRTC work.

Most WebRTC Projects Don't Fail at Scale. They Fail at 300 Users.

Jack Morris — Mon, 27 Apr 2026 05:02:20 +0000

I've lost count of how many WebRTC projects I've seen hit a wall long before they hit "scale."
Not at 10,000 concurrent users. Not at 1,000. At 300.

And almost every time, the root cause is the same thing: the team built for the demo, not for the third user who tried to join from a hotel Wi-Fi in Manila while the second user was tethering off a phone in a parking lot.

The "It works on my machine" trap is worse in WebRTC
Every backend engineer knows the "works on my machine" meme. In WebRTC, it's weaponized.

Your demo works because:

Everyone's on the same LAN
Nobody's behind a symmetric NAT
Your STUN server is reachable
The codec negotiation happens to pick something both browsers agree on
There's no packet loss because you're all sitting in the same office

Then you ship. And suddenly half your users can connect, a quarter can connect but have one-way audio, and the rest get stuck in a "connecting..." state that never resolves.

The infrastructure didn't fail. Your assumptions did.

Why 10,000 concurrent users isn't actually the hard part
Here's the thing nobody tells you early: scaling WebRTC to 10,000 concurrent users is mostly a solved problem. Deploy an SFU. Cluster it. Put a load balancer in front. Geographic distribution. Done, basically.

The hard part is the other 40% of your users who can't establish a connection at all because:

Their corporate firewall blocks UDP
They're behind a CGNAT
Their ISP is rate-limiting STUN requests
ICE candidate gathering times out before it finds a working path
Your TURN server is in a region that adds 400ms of latency

You can have the most beautifully architected SFU cluster in the world. If your TURN infrastructure is an afterthought, it's a $50,000/month decoration.

The three things people skip that actually matter
In my experience, the teams that quietly scale WebRTC to meaningful numbers without drama do three things differently from day one:

1. They treat TURN as a first-class service, not an add-on
Most teams install coturn on one box, set turn:your-server:3478, and move on. Production teams deploy TURN clusters across multiple regions, with their own monitoring, their own capacity planning, and their own SLAs. TURN traffic isn't 5% of your load. For some user populations, it's 40%.

2. They instrument ICE, not just call quality
Everyone measures MOS scores, packet loss, and jitter. Fewer teams measure ICE gathering time, ICE candidate selection patterns, or how many users fall back to relay candidates. But those metrics tell you whether users are even successfully connecting. Quality metrics only matter if the connection happens.

3. They stop thinking of browsers as the only client
WebRTC starts in the browser for most teams. Then someone wants it on iOS. Then Android. Then a desktop app. Each of these has different media stack quirks, different codec support, and different edge cases with network transitions. Teams that plan for this from the start build abstraction layers. Teams that don't rewrite their signaling three times.

The uncomfortable truth about WebRTC scaling
Most teams building on WebRTC think the challenge is technical. It's actually operational.

Can you spin up a new media server in under 10 minutes when traffic spikes? Do you have observability into individual RTP streams? Can your on-call engineer trace why a specific user had one-way audio last Tuesday at 3:47 PM?

The teams that succeed at 10K concurrent users aren't smarter than the teams that fail at 300. They just took the operational side seriously before they needed to.

If you're building toward real scale
Here's my honest advice: don't optimize for 10,000 users until you can reliably support 1,000. And don't worry about 1,000 until the first 100 work every time, across every network, on every client.

The architecture matters. The infrastructure matters. But the thing that matters most is the willingness to build for the conditions your users actually have, not the ones your development network gives you.

If you're thinking through what a production-grade WebRTC architecture actually looks like at 10K concurrent users, here is a more detailed breakdown on: How to Architect WebRTC Systems for 10K Concurrent Users. It covers SFU selection, TURN cluster design, signaling patterns, and the operational bits most articles skip.

I work on VoIP and real-time communications infrastructure. If you're running into WebRTC scaling issues and want to trade war stories, drop a comment happy to dig into specifics.

What changed after our IVR started pulling data from the CRM

Jack Morris — Thu, 16 Apr 2026 14:30:33 +0000

Last year we rebuilt the IVR for a mid-size financial services company. Around 2,500 inbound calls a day, mix of existing customers and new leads, five departments handling everything from account inquiries to collections.

The original IVR had been running for three years. It worked. Calls got answered, menus got navigated, people eventually reached a human. Nobody was complaining loudly enough for it to become a priority.

Then someone pulled the actual numbers, and the picture wasn't great.

How the old IVR worked

Every caller got the same experience regardless of who they were. You'd hear a welcome message, sit through five menu options, pick one, and wait in a queue. If you picked wrong, you'd get transferred and wait again.

Agents had zero context when the call connected. The first 20-30 seconds of every call was spent on "can I get your name and account number?" Even for callers who'd been customers for years. Even for someone who called yesterday about the same issue.

The IVR had no idea who was calling. It couldn't. It was a standalone system with no connection to anything else in the business.

Here's what the numbers looked like:

Average handle time per call was around 4 minutes 40 seconds
Roughly 35-40 seconds of that was just identification and account lookup at the start
Call abandonment rate sat around 12%, mostly people dropping off during menu navigation or hold queues
Overdue accounts were going through the full standard menu before reaching collections. Some of them never got there they'd pick the wrong option, land in general support, and get transferred. The transfer added another 2-3 minutes to those calls
New leads from marketing campaigns were treated identically to everyone else. No priority routing, no personalized greeting, no assignment to the rep who was running the campaign

The support team had gotten used to it. That's how phones work, right? Caller comes in, you ask who they are, you pull up the account. Standard stuff.
We thought there was a better way.

The core idea
The concept was straightforward. Before the IVR plays its first word, it checks the caller's phone number against the CRM. If there's a match, the system now knows who's calling, what their account status is, who their assigned rep is, and whether they have any open tickets.

That data changes everything about how the call gets handled.

Instead of a one-size-fits-all menu, the IVR can make routing decisions based on actual business context. An overdue account doesn't need to hear about sales promotions. A VIP customer shouldn't wait in the general queue. A brand new lead who filled out a web form five minutes ago should hear their own name and get connected to the right rep immediately.

The IVR stops being a dumb phone tree and starts acting like a front desk that actually recognizes people when they walk in.

What we built
We used Asterisk as the IVR platform with Kamailio handling SIP routing in front of it. The CRM was Salesforce. Between Asterisk and Salesforce, we set up a small caching service backed by Redis so the IVR wasn't hammering the Salesforce API on every single call.

When a call comes in, the IVR queries the cache layer with the caller's phone number. If there's a recent record, it comes back in about 30-50 milliseconds. If not, the cache layer queries Salesforce, stores the result, and returns it. Either way, the IVR has CRM data before the caller hears anything.

We normalized all phone numbers to E.164 format on both sides. This turned out to be a bigger deal than expected about 40% of initial "caller not found" results were just formatting mismatches between how Asterisk received the number and how Salesforce stored it. Same person, same number, different format. Easy fix once we found it, but it was the single biggest source of lookup failures early on.

The whole lookup-to-greeting path takes under 200 milliseconds. No dead air, no awkward pause before the welcome message.

The five routing paths
After the CRM lookup, every call falls into one of five buckets:
Overdue accounts skip the menu entirely. The system routes them straight to the collections queue. The agent's screen already shows the account details, outstanding balance, and payment history before they even pick up the call. No "can I get your account number," no transfers, no wasted time.

VIP customers get a personalized greeting using their name and connect directly to their assigned account manager. If that person is unavailable, they go to a priority queue with shorter wait times. They never hear the standard five-option menu.

Active regular accounts get the standard menu but with a difference. The agent already has their account pulled up when the call connects. That 30-40 second identification ritual at the start of every call just disappears.

New leads hear a different greeting. Something like "Hi [Name], thanks for reaching out to us." They get routed to the sales rep assigned to that lead in Salesforce. If the lead came from a specific campaign, the rep knows that too before answering.

Unknown callers - people whose number isn't in the CRM - get the original standard menu. Nothing changes for them. The system degrades gracefully instead of breaking.

What changed in the numbers

We measured everything we could over the first 90 days. Some of the improvements were expected, some caught us off guard.

Handle time dropped by about 18%: The biggest contributor was eliminating the account identification step at the start of calls. When the agent already has the account on screen, the conversation starts with the actual issue immediately. Across 2,500 daily calls, those saved seconds add up fast.

Call abandonment went from 12% down to around 7%: Two things drove this. First, eliminating the dead air gap that happened when API lookups were slow (we solved that with the caching layer). Second, callers who got routed directly to the right place didn't have to navigate menus and wait in the wrong queue before getting transferred.

Collections contact rate improved noticeably: Overdue accounts were actually reaching the collections team now instead of getting lost in the general menu. Before, some of those callers would pick "general inquiries," sit in a queue, explain their situation, get transferred to collections, and sit in another queue. A lot of them gave up halfway through. Direct routing removed that entire detour.

New lead response time got faster: Marketing was running paid campaigns that drove phone calls. Previously, those callers were treated like everyone else. Now they were recognized and connected to the right sales rep within seconds. The sales team said it made a real difference in conversion conversations when the rep could greet someone by name and reference the specific thing they'd inquired about.

Agent satisfaction, surprisingly: We didn't measure this formally, but the feedback was consistent. Agents said not having to ask "who am I speaking with" on every call made their job feel less repetitive. Having context before the conversation started let them focus on solving the problem rather than playing detective for the first minute.

The problems we didn't expect

It wasn't all smooth. A few things caught us off guard.

Multiple accounts tied to one phone number: More common than we anticipated, especially with business lines. A single number might be associated with three different accounts in Salesforce. We solved this by defaulting to the most recently active account and giving the caller a quick confirmation: "We found your account under [Company Name]. Press 1 if that's correct, press 2 to search by account number." Worked fine, but we hadn't planned for it initially.

Stale CRM data causing wrong routing: An account marked as "overdue" in Salesforce that had actually just made a payment would still get routed to collections until the CRM record updated and the cache expired. We shortened the cache duration for accounts with recent status changes and added a webhook listener that invalidated the cache when certain Salesforce fields were modified. Took some back and forth to get right.

Agents trusting the screen pop too much: Because the system was accurate 97% of the time, agents started skipping verbal verification entirely. Usually fine, but occasionally the caller was using someone else's phone. We added a soft verification prompt to the agent script for sensitive transactions (payments, account changes) even when the screen pop was populated.

What I'd tell someone considering this

If your IVR handles more than a few hundred calls a day and your business logic depends on who the caller is, the CRM integration is worth doing. The impact on handle time and routing accuracy alone probably justifies the build.

But don't call the CRM API directly from the IVR for every single call. It seems like the obvious approach, and it works in testing, but it won't survive production call volumes. Put a caching layer between them. You'll avoid latency spikes, rate limit issues, and token management headaches.

And spend time on phone number normalization before anything else. It's not glamorous work, but mismatched number formats will quietly tank your lookup accuracy. We lost about two weeks troubleshooting "caller not found" results that turned out to be nothing more than formatting inconsistencies.

The whole project from planning to production took about 6 weeks. If we did it again knowing what we know now, we could probably cut that to four.

I work with the VoIP engineering team at Hire VoIP Developer we build custom IVR Systems and telephony systems, and CRM integrations are a regular part of that work. If you've done something similar, especially with a CRM other than Salesforce, I'd be curious how you handled the data sync and caching side.

7 Asterisk Development Mistakes That Only Show Up After You Go Live

Jack Morris — Tue, 31 Mar 2026 13:07:16 +0000

I've been building and fixing Asterisk-based systems for close to a decade now. PBX platforms, multi-tenant hosted solutions, IVR systems, call center dialers - the works. And the pattern I keep seeing is that most Asterisk projects don't fail during development. They fail after launch.

The dev environment works perfectly. Calls connect, the dialplan routes correctly, voicemail picks up, CDRs get written. Everyone's happy. Then you go live, connect real SIP trunks, put actual traffic on it, and things start falling apart in ways nobody anticipated.

Here are the mistakes I've seen repeatedly - not the beginner stuff, but the production-level problems that cost teams weeks of debugging and sometimes a full re-architecture.

1. Still using chan_sip when you should've migrated to PJSIP already

I still run into Asterisk deployments using chan_sip in 2026. It technically works, sure. But chan_sip has been deprecated for years, it doesn't get security patches anymore, and it's missing features that PJSIP handles natively — like multiple SIP registrations per endpoint, better TLS handling, and cleaner NAT traversal.

The real problem is that teams put off the migration because "everything works fine." Then they need to add a WebRTC integration or a second carrier trunk with different auth requirements, and chan_sip can't handle it cleanly. Now they're doing a PJSIP migration under pressure, with live traffic, which is exactly when you don't want to be doing it.

If you're starting a new Asterisk development project today, there's zero reason to use chan_sip. And if you're maintaining a legacy system, schedule the migration before it becomes an emergency. The config syntax is different enough that it's not a quick find-and-replace endpoint, auth, AOR, and transport objects all need to be set up correctly.

2. Writing dialplan logic that only works for one carrier

This one is subtle and it bites hard. You build your dialplan, test it against your primary SIP trunk, everything routes perfectly. Then you add a second carrier for failover or least-cost routing, and the dialplan starts doing weird things.

The root cause is almost always hardcoded assumptions — a specific caller ID format, a particular way the carrier sends the To header, or regex patterns in your extensions.conf that only match one carrier's number formatting. I inherited a system once where the outbound routing only worked because the original developer had hardcoded the carrier's tech prefix into a GoSub routine. Nobody documented it. When the client switched carriers, outbound calls just... stopped.

What I do now: I normalize all inbound traffic at the entry point. Strip formatting, standardize E.164, handle any carrier-specific quirks in a dedicated context before the call hits the main routing logic. It's a boring 30 minutes of work upfront that saves you days of debugging later.

3. Treating ARI as "just another API"

Asterisk's REST Interface is incredibly powerful — it basically lets you control Asterisk from an external application, which opens the door to building custom VoIP solutions that go way beyond what the dialplan can do. Real-time call control, dynamic IVR flows, integration with CRMs and AI services — all possible through ARI.

But here's what trips teams up: ARI uses WebSockets for event delivery, and if your application doesn't handle connection drops and reconnection properly, you end up with ghost channels. Calls come in, your app doesn't get the event because the WebSocket silently disconnected, and nobody picks up. The caller hears silence. Your monitoring shows the channel was created but no application claimed it.

The other mistake is treating ARI calls as synchronous when they're fundamentally async. I've seen applications that make an ARI request to bridge two channels and immediately assume the bridge is active, without waiting for the actual event confirmation. Works fine with low traffic. Falls apart at 50+ concurrent calls.

If you're building on ARI, invest time in proper event handling, connection resilience, and a state machine for channel lifecycle management. It's not a REST API you can call and forget.

4. Ignoring codec negotiation until calls sound terrible

Same issue as FreeSWITCH deployments, honestly, but Asterisk has its own quirks here. By default, Asterisk will try to negotiate codecs in the order you list them in your endpoint config. But what happens when your carrier sends an SDP offer with only G.729, your system is configured to prefer G.722, and the receiving endpoint only supports G.711?

You get transcoding. Asterisk will handle it — it'll transcode between codecs using CPU resources. On a lightly loaded server, no problem. On a box handling 200 concurrent calls, that transcoding overhead can tank your call quality and spike your CPU past 80%.

The fix is boring but essential: define codec profiles per trunk, per endpoint type, and per use case. Internal calls between SIP phones can use a wideband codec like G.722 or Opus. Carrier trunks should match whatever the carrier actually supports ask them, don't guess. And disable transcoding entirely on paths where it's not needed by using the

allow and disallow directives aggressively.

I've lost count of how many "call quality" tickets I've resolved just by fixing codec configuration. It's never the first thing anyone checks, but it's almost always the actual problem.

5. No separation between your PBX logic and your business logic

Early Asterisk projects tend to dump everything into the dialplan. Call routing? Dialplan. Business hours check? Dialplan. CRM lookup? AGI call from the dialplan. Billing logic? Another AGI call. Custom hold music xselection based on the caller's account tier? You guessed it dialplan.
Six months later you've got an extensions.conf that's 3,000 lines long, with GoSub calls nested four levels deep, and any change requires a full regression test because nobody can predict the side effects.

The developers I've worked with who build Asterisk solutions that actually scale long-term treat the dialplan as a thin routing layer. It answers the call, does basic classification (inbound/outbound, internal/external, carrier identification), and hands off to an external application via ARI or a lightweight AGI script for everything else. Business logic lives in your application code where you have proper version control, testing frameworks, and debugging tools not buried in Asterisk config files.

This separation also makes it way easier to scale later. Asterisk handles the telephony. Your app handles the decisions. If you need to add a second Asterisk node behind a Kamailio load balancer, your business logic doesn't care it's already decoupled.

6. Skipping proper CDR and CEL configuration

Call Detail Records and Channel Event Logging are two things that nobody thinks about until the business side of the house starts asking questions. "How many calls did we handle last Tuesday?" "What's our average call duration per carrier?" "Why does our bill from the SIP trunk provider not match our internal records?"
Default Asterisk CDR logging is... fine for a lab. In production, you need CDRs going to a database (MySQL, PostgreSQL), not flat files. You need proper handling of transfer scenarios — a call that gets transferred three times generates multiple CDR entries, and if your billing logic doesn't account for that, you'll either double-bill or under-count.

CEL is even more granular and catches events that CDRs miss — like hold time, parking events, and conference participation. If you're building anything that eventually connects to a VoIP billing system, set up CEL from day one. Retrofitting it later means you've lost months of historical data that the finance team definitely wanted.

7. Scaling by buying a bigger server instead of thinking about architecture

Asterisk's single-threaded-per-module architecture means there's a ceiling to what one instance can handle. You can throw more RAM and faster CPUs at it, and that buys you time, but eventually you hit a wall usually somewhere around 300-500 concurrent calls depending on your transcoding load and complexity.

When teams hit that wall, they panic. "We need to hire Asterisk developers who can optimize our config!" And yeah, there's always some optimization headroom turning off modules you don't need, reducing logging verbosity, tuning the kernel's network stack. But the real answer is usually architectural.

For VoIP enterprise solutions at scale, the standard pattern is Kamailio or OpenSIPS sitting in front as a SIP proxy and load balancer, distributing registrations and call traffic across multiple Asterisk instances behind it. Each Asterisk box handles a subset of the traffic. Kamailio handles the routing decisions, failover, and NAT traversal at the edge.

This isn't something you can bolt on easily after the fact. The registration model, the dialplan structure, the CDR pipeline, the monitoring setup all of it changes when you go from a single-box architecture to a distributed one. Which is why thinking about it early, even if you don't implement it on day one, saves you a full rewrite later.

The common thread

Every one of these mistakes comes from the same root cause: treating Asterisk development like regular software development. It's not. It's telecom — different protocols, different failure modes, different debugging tools.
The developers who do this well aren't necessarily better coders. They're people who've debugged one-way audio on a specific carrier's trunk at 2 AM, dealt with SIP ALGs silently rewriting SDP packets, and watched a system fall over because nobody tested what happens when the CDR database connection pool gets exhausted.
That production experience is what separates a working lab project from a reliable production system.

Why VoIP Billing Solutions Become Complex as You Scale

Jack Morris — Fri, 20 Mar 2026 09:19:25 +0000

Lately I’ve been noticing that billing is becoming one of the most complex parts of building a VoIP system.

It’s not something most teams think about early on. The focus is usually on call quality, SIP signaling, or scaling infrastructure. But once real users start generating traffic, billing quickly turns into a critical piece of the system.

A lot of VoIP platforms start with basic billing logic something like tracking call duration and applying simple rates. That works initially. But as soon as things scale, it gets complicated.

For example:

• Different rates for different destinations
• Peak vs off-peak pricing
• Multi-currency billing
• Reseller or multi-tenant models
• Real-time balance deduction
• Fraud detection and usage limits

This is where more advanced VoIP billing solutions come into play.

In most real-world deployments I’ve seen, billing is not just a separate module it’s tightly connected with the signaling layer and call routing.

A typical setup might involve:

SIP servers (like OpenSIPS or Kamailio) generating CDRs
A mediation layer processing call records
A billing engine calculating charges in real time
A database handling user balances and invoices
APIs connecting billing with dashboards or external systems

One thing that’s often underestimated is real-time billing. If you're working with prepaid models, you need to control the call duration based on available balance which means your billing system has to interact with the call flow itself.

Another challenge is accuracy. Even small delays or incorrect CDR handling can result in revenue leakage or customer disputes.

Because of this, many teams are moving toward custom VoIP billing solutions instead of relying on generic systems. It gives them more control over pricing models, integrations, and scalability.

Still, it’s not trivial to build.

You have to think about performance, concurrency, data consistency, and edge cases like dropped calls or partial sessions.

Curious how others here are handling this.

Are you using an off-the-shelf billing platform, or building your own VoIP billing system integrated with your SIP infrastructure?

What Does a Modern Hosted PBX Architecture Look Like in 2026?

Jack Morris — Tue, 17 Mar 2026 05:16:32 +0000

I was having a discussion with a colleague recently about PBX setups, and it got me thinking about how much things have changed in the VoIP space over the last few years.

Back then, most companies I worked with were perfectly fine using a typical cloud PBX provider. You sign up, configure extensions, connect a SIP trunk, and you're basically ready to go. For small teams it still works well.

But once organizations start growing, the cracks begin to show.

One problem that comes up pretty often is routing flexibility. Another one is integration. If the company wants deeper integration with internal tools or wants to experiment with more complex call flows, those packaged PBX systems can feel a bit restrictive.

Because of that, I’ve started seeing more engineering teams experiment with custom hosted PBX solutions instead of relying completely on managed platforms.

In practice, the architecture usually isn’t that complicated conceptually, but it does require more engineering effort.

A setup I saw recently looked something like this:

• OpenSIPS handling SIP routing and registration
• Asterisk managing the dial plans and PBX logic
• A couple of SIP trunk providers for redundancy
• WebRTC support so calls can also happen inside browser apps
• Infrastructure running on cloud VMs so scaling is easier when traffic grows

The main advantage is control. Teams can design their own routing logic, integrate with internal services, and adjust the infrastructure when call volumes increase.

Of course the downside is that you now have to manage everything yourself — monitoring, failover strategies, security, scaling, all of that.

Still, it seems like more companies are exploring custom hosted PBX solutions when they need flexibility that typical cloud PBX platforms don’t provide.

Curious what others here are running in production these days.

Are you sticking with managed PBX platforms, or building your own setups with tools like Asterisk, FreeSWITCH, OpenSIPS, or Kamailio?

Why Off-the-Shelf UCaaS Platforms Fall Short for Growing Product Teams

Jack Morris — Tue, 10 Mar 2026 11:05:02 +0000

So I've been working with a few product teams over the past couple of years — mostly companies in the telecom and SaaS space — and there's one complaint I keep hearing over and over again.

"We picked [insert popular UCaaS platform], and now we're stuck."
Sound familiar? Yeah, it's more common than you'd think.

The thing is, platforms like RingCentral, 8x8, or even Zoom's UCaaS offering work perfectly fine when your needs are straightforward. Basic voice, video meetings, team chat — done. But the moment your product roadmap asks for something slightly different, you hit walls everywhere.

I worked with one team that spent three months trying to build a custom IVR flow on their existing platform. Three months. For something that should've taken weeks. The APIs were limited, the documentation was outdated, and support kept pointing them to "workarounds" that weren't really workarounds just band-aids.

Another team needed real-time CRM sync during live calls. Not after the call ends. During. Their platform technically supported Salesforce integration, but the data lag was 15-20 minutes. Totally useless for their use case.
And don't even get me started on white-labeling. If you're offering communication features to your own clients, most platforms give you a logo swap and call it "white-label." That's not white-labeling. That's a skin.

So what's the alternative?

This is where custom UCaaS solutions actually make practical sense. I'm not saying everyone should go build their own communication stack from scratch — that would be overkill for most teams. But if your product genuinely needs custom call flows, deep integrations, real white-labeling, or you're reselling communication features, then building on open-source frameworks like FreeSWITCH or Kamailio gives you control that no packaged platform ever will.

The catch? You need people who actually know this stuff. Telecom engineering is niche. Really niche. The pool of developers who understand SIP at a protocol level, who can architect a scalable media layer, and who've actually shipped production-grade voice systems it's tiny. Most teams I've seen go this route end up partnering with firms that specialize in building custom UCaaS solutions rather than trying to hire and train internally. The ramp-up time alone makes it a no-brainer.

Honestly curious though has anyone here gone through this exact transition? Moved from a packaged UCaaS platform to something custom-built? What finally made you pull the trigger? And was it worth the effort?

Because from what I've seen, the teams that make the switch never look back. But getting there is definitely not a weekend project.

Why Scaling a FreeSWITCH Solution Is More About Architecture Than Code

Jack Morris — Wed, 25 Feb 2026 13:04:41 +0000

When teams start building on FreeSWITCH, the focus is usually on features call routing, IVR logic, SIP trunking, maybe some basic integrations. And in early stages, that’s enough.

But the real challenges don’t show up in development. They show up when traffic increases.

A FreeSWITCH solution that works perfectly in a staging environment can start behaving very differently under load. RTP jitter becomes noticeable. Call setup latency increases. Database writes slow down. CPU spikes at unexpected times. At that point, it’s no longer about writing dialplan logic it’s about architecture decisions.

Scaling Starts With Separation

One of the first lessons learned in production is separating signaling, media, and database responsibilities. Running everything on a single node works for small deployments, but carrier-level or enterprise environments demand horizontal scaling.

Clustering FreeSWITCH instances, isolating media handling, and properly managing SIP profiles can dramatically improve stability. It’s not complex — but it has to be intentional.

Dialplan Logic Matters More Than It Looks

FreeSWITCH gives enormous flexibility through XML dialplans, Lua scripting, and ESL. That flexibility can become technical debt if routing logic grows without structure. Nested conditions, redundant checks, and unnecessary media processing all impact performance over time.

Clean dialplan design is just as important as server capacity.

Carrier-Scale Traffic Requires Monitoring

FreeSWITCH can absolutely handle high concurrent calls but only when paired with proper monitoring and optimization. RTP handling, CPS limits, thread management, and database performance all need continuous review.

This is usually the stage where companies decide whether to internally scale their team or hire FreeSWITCH developers with production experience. The difference isn’t syntax knowledge it’s understanding how the system behaves under real traffic.

Integration Is Where Complexity Hides

Modern deployments rarely use FreeSWITCH in isolation. It often integrates with:

VoIP billing systems
SBCs
WebRTC applications
CRM platforms
Analytics pipelines

Each integration layer introduces latency, edge cases, and failure points. Planning for that early prevents painful rewrites later.

FreeSWITCH is extremely powerful but production stability depends far more on architecture and scaling decisions than on module installation.

The teams that succeed long-term treat their FreeSWITCH solution as infrastructure, not just application logic.

Why Scaling WebRTC Applications Is Mostly an Infrastructure Problem

Jack Morris — Fri, 20 Feb 2026 10:52:34 +0000

When people talk about WebRTC, the conversation usually revolves around APIs.

getUserMedia(), RTCPeerConnection, ICE candidates the browser side gets most of the attention. And to be fair, getting a basic video call working isn’t particularly hard anymore.

But scaling WebRTC is rarely a browser problem.

It’s an infrastructure problem.

Once traffic increases or enterprise users start connecting from unpredictable network environments, the weak points begin to show. TURN usage spikes under restrictive NATs. Signaling servers struggle with session churn. Packet timing issues surface under load even though CPU graphs look normal.

The challenge isn’t building the feature. The challenge is building the system around it.

For example:

Corporate networks that block UDP can quietly push most sessions through TURN relays.
Poor signaling design can introduce state synchronization delays across instances.
Overloaded media nodes can amplify jitter even when bandwidth appears sufficient.

These issues don’t show up in small staging environments. They appear when concurrency grows or when WebRTC is integrated with SIP infrastructure like PBX systems or SBC layers.

That’s usually when teams realize WebRTC is not just a frontend feature it’s a real-time distributed system.

And distributed systems behave differently.

Scaling means thinking about:

TURN server placement across regions
Stateless signaling design
RTP observability and packet-level metrics
Intelligent load balancing for SFU clusters
Failover behavior that doesn’t break active sessions

At that stage, having general JavaScript knowledge isn’t enough. Specialized WebRTC developers who understand both signaling and media flow can prevent architecture decisions from becoming long-term bottlenecks.

In some cases, companies even decide to hire WebRTC developers with production experience rather than iterating through trial-and-error in live environments.

Because once communication becomes mission-critical, stability matters more than speed of implementation.

Real-time systems don’t forgive architectural shortcuts.

If you're building serious communication platforms and exploring how to strengthen the engineering side of WebRTC deployments, teams like Hire VoIP Developer tend to focus specifically on infrastructure-level challenges where scaling, interop, and reliability actually define success.