Ok, let’s get something straight to start with: We love Asterisk, it was the Swiss Army Knife of telecommunications and the product on which many people started their VoIP adventures. We’re very thankful to the many many hours of development that has gone into it and think the current version 12 is really quite good. This post is not in any way a criticism of Asterisk.
We’ve been around since 1996, playing with Asterisk since 2000/2001 and took on our first VoIP customers in 2005. With approaching 500 Communication Provider customers now, of all sizes, and with many of the early ones still with us, enough time has passed for us to notice very clear generational differences that we’d like to discuss.
It is a fair summary to make that Asterisk is most commonly in use amongst our oldest customers, or rather those customers who have been offering VoIP services for longest, since at the time they started it was about the only and certainly the best option. Those customers have taken the flexibility of a fundamentally PBX product and built onto it with RealTime databases and AGI scripts. The result has use cases ranging from Class 4 switches through to large multi-tenant hosted PBX solutions. It is testament to the product that it can be used in such a variety of ways but the fact remains it was designed as a PBX, and with versions from 1.2 to 1.8 still in production use, the versions out there are getting very old now.
Talking to customers we notice something of a trap, somewhat akin to that of Mainframe computer systems. If you were starting again today you’d do it differently but how do you get there? What you have may be so big, complicated and necessary that there’s no simple upgrade path, even to newer versions of the underlying product.
As we highlighted in our VoIP Fraud Analysis, SIP Scans are so heavy now that any solution relying on a back-end relational database is likely to exhibit DoS like behaviour with genuine users having service affected. Meanwhile some of those who have built vPBX solutions have had to develop creative ways to overcome the limits of single box scale and availability. Others have bought overlaying solutions to give the functionality they need but, as we highlighted, they can introduce security vulnerabilities of their own and in some cases are very expensive. In any event what results is not of our time.
If you were building your business today, would you build it the same way? We think not and we believe that your solution would be much simpler since there are many things you may have done before that you don’t need to do now, and more elegant ways of achieving them. For example, you may have always handled media and bought licensing for certain codecs; you don’t need to nowadays as you can hand media off to the likes of us directly and actually improve quality. You may have built solutions to receive fax in media but end-user equipment supports T.38 now, so do we, plus you can make use of network level fax solutions such as our fax-to-http and outbound fax services. You were probably also billing, in some cases on the same box; now you get real-time CDRs from us and we even give you a reconciliation header to match calls one-on-one. Then there’s fraud control!
It is in our DNA to admire and favour those who build over those who simply [re]sell and we passionately believe the market is better for people like you. But just as mud gave way to stone which gave way to concrete, the way of doing that is changing as people invent new ways of achieving an improved outcome.
Our belief is that it is all about the API. Others might say ‘cloud’ but you have to be careful there. If they mean replacing hardware soft-switches with AWS hosted soft-switches we would argue that doesn’t benefit the end-user at all, or push things on. If they mean clustered, distributed services, controlled through an API then we agree. We think our customer of the future will be building application servers, not media servers. They won’t be worrying about the performance of back-end databases or SIP Scans, they’ll be pulling APIs from potentially several sources together and playing them like a fine instrument to build something amazing for the end user.
You may disagree and if you do we’d love to hear from you. But we’d like to hear from you either way and discuss a road-map. We’ve started with amazing fraud management features and we see the next frontier being taking the low-value commodity tasks away, abstracting them to the network and presenting them through an API. In doing so we’re enabling enhanced security, performance and features whilst easing the load on that legacy PBX-solution you may have. But what next, what features do you find to justify keeping that solution around and how would they need to look to make things better?
The answer to the title question will probably be ‘yes’, and there is likely a lot of investment in your current solution that human nature favours finding ongoing reason for. But does it need to do everything? Is there some functionality you’re pushing on to that poor old Asterisk that could be chipped-away? You may be handling media and transcoding; we can do that for you in hardware at no cost. You may be processing faxes which we can do for you and present through the API to process yourself, or provide native T.38. You might have domestic single-line or nomadic users that just need in/out calls rather than a full PBX; why not look to shift them to our Registration Proxy and give them TLS/SRTP in the process whilst protecting yourself from SIP Scans? SIP Trunks with real-time CDRs and fraud controls? All possible today through the API. Recording and trying to reconcile CDRs? Why? Use a trunk and get the trunk ID in real-time CDRs or use the reconciliation header to match up 100% one-to-one.
Harsh as it may sound we’re certain there are applications within your service that you could do better by not doing them, saving your skills and resources for where you really excel. There were for us – we outsourced email and DNS years ago despite having hundreds of servers and a national network to run them on.
If you are one of the people with a legacy PBX-based solution you should rightly be proud. But unless you seriously think it can give you competitive advantage in 2 or 3 years time then the time to start taking steps to evolve it is now. We’d love to be with you on that journey and to hear what you need from us to make it easy.
If on the other hand you know a rock-star developer with skills in Node.js, Redis, PHP and front-end development please point them our way. We’ve got a lot of exciting work to get done and are hiring!
