Custom development on open source telephony
Most of the work we get asked for starts the same way. Somebody has Asterisk or FreeSWITCH running, it does roughly what they need, and then the business asks for the one thing it doesn’t do. That gap is where we come in.
We’ve been building on open source telephony since 2003, and we still run the same stack in production ourselves. ICTCore, ICTFax, ICTDialer, ICTCRM and ICTBroadcast all came out of client work that turned into products. So when you describe a dialplan problem, you’re not explaining it to someone who read the documentation last week.
What we actually get called in for
Making two systems talk to each other
This is the bulk of it. A PBX that needs to read from a CRM mid-call. A dialer that has to push results into a billing system nobody has documentation for. Call records that need to land somewhere a reporting tool can see them. The telephony side is usually straightforward; the other system is where the time goes.
Dialplan and call flow work
Routing that reflects how the business actually runs rather than how it ran four years ago. Skills based distribution, time of day rules that account for the branch in another timezone, queue behaviour that stops callers falling into silence. We write it so the next person can read it, because often that next person is you.
Modules and channel work
Custom Asterisk modules, FreeSWITCH mod development, work against ARI, AMI, ESL and AudioSocket. We maintain client libraries for several of these in the open, so the ground is familiar.
Carrier and trunk integration
SIP trunk setups that survive a carrier changing something without telling you. Failover that fails over. Kamailio in front when the traffic justifies it, and an honest conversation about whether it does.
Rescuing something that already exists
A fair amount of what we do is picking up a system built by somebody who left. We’ve inherited enough undocumented dialplans to be calm about it. The first deliverable is usually a written description of what the thing currently does, because you cannot safely change what nobody can describe.
Asterisk or FreeSWITCH, and why we don’t have a favourite
We build on both and we’d rather not pretend one wins every argument.
Asterisk has the larger module ecosystem and most people hiring for telephony already know it. If your team has to maintain the result after we leave, that matters more than any technical comparison. ICTContact and ICTBroadcast are built on it.
FreeSWITCH handles concurrency better and its media handling is cleaner, which shows up once you’re running serious channel counts or doing anything unusual with audio. ICTFax, ICTPBX and ICTCore sit on FreeSWITCH.
If you already run one, we work with that. Migrating between them is occasionally the right answer and usually isn’t, and we’ll tell you which case you’re in before you spend anything.
How we work
We scope before we quote. That means a conversation about what the system does now, what you need it to do, and what happens if it breaks at 3am. Fixed price where the work is well defined, time and materials where it genuinely isn’t, and we’ll say which one applies rather than padding a fixed price to cover our uncertainty.
Everything we write is yours. No runtime licence on custom work, no dependency on us to keep it running. We publish a lot of our own code openly for the same reason.
If the honest answer is that an existing product already does what you need, we’ll point you at it. That has cost us work and it has also brought a good deal back.
Where this fits
If you need a standard install rather than custom work, the installation and deployment packages are cheaper and faster. If you want somebody keeping an eye on the system afterwards, that’s the monitoring and support side. Custom development is for the things those don’t cover.
Tell us what you’re trying to build
Send a short description of your current setup and the thing it won’t do. We’ll come back with a view on scope and effort, or a reason the work isn’t worth doing. Both answers are useful.