ICTPbx

• 

  Extension managment

• 

  IVR flow

• 

  Ring Groups

Inspiration

We've been building open-source VoIP infrastructure since 2005, and the same complaint kept following us across almost every client conversation: businesses wanted a real PBX — one that could scale, handle multi-tenancy, and stand up to carrier-grade call volume — but every option on the market forced them into one of two bad trades. Either they paid steep per-seat or per-extension licensing fees to a proprietary vendor and lost all control over their own infrastructure, or they cobbled together a barebones open-source setup that worked fine for a five-person office and fell apart the moment they tried to run it as an actual service provider.

What it does

ICTPBX is an enterprise-grade, multi-tenant PBX platform built on top of Asterisk. It gives organizations everything a modern business phone system needs — extensions, IVRs, call queues, ring groups, voicemail, call recording, and detailed reporting — through a clean web interface that doesn't require deep telephony expertise to operate day to day.

Because it's multi-tenant by design, a single deployment can serve one office or scale to host thousands of tenants, which makes it a natural fit for ITSPs and agencies who want to offer hosted PBX services under their own brand. It supports SIP trunking, WebRTC softphones, and integrates cleanly with the rest of the ICT product family — ICTCRM for call-to-customer matching, and ICTContact for outbound campaign work.

How we built it

How we built it

The platform is built on Freeswitch & ICTCore as the underlying telephony engine, handling the actual signaling and media. On top of that, we built a custom application layer to handle multi-tenancy, administration, billing, and reporting — the pieces that don't exist natively in raw Asterisk.

The web interface is where most of the day-to-day complexity gets abstracted away. Instead of editing dialplan configuration files by hand, administrators manage extensions, trunks, IVRs, and queues through structured forms, and the platform generates and reloads the underlying Asterisk configuration behind the scenes. We put a lot of effort into making sure that abstraction doesn't leak — the moment a UI hides complexity but breaks when something unusual happens, it stops being useful for real deployments.

For real-time features like WebRTC calling, we layered in support for browser-based softphones without requiring a separate client install. And because the platform is meant to run as a hosted service for other businesses, tenant isolation was treated as a first-class architectural concern from day one, not bolted on afterward.

Challenges we ran into

Multi-tenancy without sacrificing performance. Isolating tenants cleanly — so one tenant's call volume or configuration mistake can't affect another's — while still running efficiently on shared infrastructure took several iterations to get right.

Making telephony approachable without dumbing it down. Asterisk is powerful specifically because it's flexible, but that flexibility is also what makes it intimidating. We had to build an interface simple enough for non-telecom admins to use confidently, without hiding the controls that experienced operators actually need.

Scaling concurrent call handling. Getting the platform to reliably support thousands of concurrent agents and calls required careful work on the media handling and resource management side — this isn't the kind of thing you can fully validate until you throw real load at it.

Accomplishments that we're proud of

Real production usage, not just a demo. ICTPBX isn't a proof of concept — it's actively deployed and running in production for ITSPs and businesses handling real call traffic today. Building something people trust to run their actual phone systems is a different bar than building something that just works on stage.

Scaling to thousands of concurrent agents. Getting the platform to reliably support that level of concurrent call handling, without falling over under real load, took serious engineering work on the media and resource management side — and seeing it hold up in live deployments was a genuine milestone.

Keeping it genuinely open source. We stayed committed to an MIT-style open, self-hostable model instead of taking the easier path of gating core functionality behind a proprietary layer. That decision meant more upfront discipline around architecture and documentation, but it's also what lets businesses actually inspect, trust, and extend the platform rather than just rent access to it.

What we learned

What we learned

Flexibility and simplicity are in constant tension, and you have to keep choosing. Every time we made the interface friendlier for a non-technical admin, we risked hiding a control someone else genuinely needed. We learned that the right answer usually isn't picking one side — it's finding where to draw the line for a given feature, again and again, rather than settling it once.

Multi-tenancy has to be a foundational decision, not a retrofit. Early on, we underestimated how much isolating tenants properly would shape the entire architecture — data models, resource allocation, even how configuration changes propagate. Trying to bolt real multi-tenancy onto something not designed for it from the start would have cost us far more than doing it right the first time.

Load testing on paper means nothing. We learned this the hard way — the platform behaved exactly as expected at moderate scale, and then surfaced entirely new bottlenecks once we pushed toward thousands of concurrent calls. Real telephony load has a way of exposing edge cases that no amount of synthetic testing catches upfront.

What's next for ICTPbx

Deeper AI integration across the call flow. We're extending AI-powered capabilities further into the platform — from intelligent call routing and IVR that understands natural language instead of rigid menu trees, to AI-assisted call summarization and sentiment analysis that feed directly into ICTCRM.

Expanding WebRTC and browser-based calling. We want to make the browser-first calling experience even more seamless, reducing setup friction for tenants who want to go all-in on softphones without any traditional hardware.

Stronger observability and self-service diagnostics. As deployments scale toward larger tenant counts, we're investing in better real-time monitoring, alerting, and self-service troubleshooting tools, so admins can catch and resolve issues themselves without needing to dig through raw logs or open a support ticket.

Tighter integration across the full ICT suite. ICTPBX already talks to ICTCRM and ICTContact, and we want to deepen that — making call data, customer context, and campaign activity feel like one connected system rather than several products that happen to interoperate.

Built With

• angular.js
• freeswitch
• fusionpbx
• ictcore
• php