Digium’s Big Gambit
I know from two consecutive Astricon’s that it is a very unique and informative conference, but unfortunately I missed it this year. I did follow the information flow as best I could remotely and spoke to several attendees during the event. There was the usual activities and relationship forging. Unlike other customer conferences, the attendees of Astricon are, in many cases, its developers or self-appointed custodians. Astricon is Digium’s opportunity to invigorate its base with direction and vision as well as hear what’s is most passionate users have to say. 
Astricon usually has big announcements – but they don’t always pan out. Three years ago, the big news was the acquisition of Switchvox. I was a Switchvox fan before the acquisition, and I still think the acquisition was a good move for both companies. Two years ago the news was Skype for Asterisk – a celebrated partnership that integrated features of the Skype client/service into Asterisk. The solution didn’t really take-off, but no other phone system offers a comparable level of integration. Last year the big news was a partnership with IBM around its Cube ‘appliance’ server. I felt that had some legs, but it didn’t. IBM killed the Cube in lieu of the competing Foundations server (which now appears to be on the ropes).
So what’s the big news this year? Asterisk SCF. I wrote a post on Asterisk SCF at UCStrategies, so I won’t repeat myself here. I want to focus more on the dilemma Digium had leading to this decision as I don’t think their predicament was unique.
Asterisk was originally created to be a small business PBX (actually for Digium). I know, we don’t use “PBX” any more. Everyone knows instead to use Unified Communications solutions/systems. Unfortunately, it truly is more than just a name change. I don’t want to start the ‘let’s define UC’ conversation again, so let me just simply offer some loose requirements often included in the UC conversation.
- Multi-Modal Communications (IM, Email, Presence, VMail, Video, SMS, and voice).
- Conferencing
- Whiteboarding and desktop sharing
- Rich APIs for extensibility
So if you make a PBX and you want to instead make a UC solution, all that’s needed is a few bolt-ons to deliver some or all of the above. That’s not so bad – and that’s exactly what many vendors offer. The problem is the bolt-on concept loses its shine rather quickly with larger implementations. In other words – scalability.
For illustration, consider video conferencing. Videoconferencing on a laptop without additional hardware other than a basic webcam is simple. The computer does the heavy lifting which is why webcams are so cheap. Not only are software codecs pretty good, but continue to get better. One might conclude the hardware MCU (multipoint conference unit) business is doomed, but it is instead growing. One small web-conference is easy, but managing a group of HD video clients takes more power – often best delivered through optimized hardware.
Since voice is morphing to unified communications and unified communications is rapidly embracing video conferencing – then the evolution of the PBX is to include the functionality of a videoconferencing MCU. It’s simple and straightforward except for one thing… the PBX is also rapidly evolving away from hardware – there lies the rub. Asterisk is, after all, software completely independent of specific hardware. Videoconferencing illustrates the point, but the correct term is mutli-modal communications – rich user selectable media types.
The ace up the sleeve is Moore’s Law which keeps this scalability thing off the front page. Moore’s law has fueled many aspects of telecom and VoIP. Asterisk in particular is now supporting huge systems unfathomable 11 years ago when it was created. But Moore may not be enough for the upcoming multi-modal onslaught. There are other solutions such as virtualization, clusters, even the cloud – all of which treat rather than solve the problem.
The solution requires a new architecture that incorporates native APIs at its core delivered via a system of distributed components deployed on either a single core or distributed cluster of systems (or services). There were four key design objectives for Asterisk SCF:
- Performance
- Scalability
- Fault tolerance
- Extensibility
The developers at Digium realized they had a problem – the architecture of its flagship product Asterisk was wrong for dynamic scalability needed for multimodal communications. A secret team was formed at Digium code named Hydra (mythological creature with many heads that cannot be killed), to determine a strategy that accommodates dynamic scalability. Virtualization allows key resources, such as processors, to be added or subtracted from running applications. Asterisk SCF is conceptually similar, but separates core application processes (routing, SIP engine, conference engines, etc.) into discrete components enabling scalability at a process rather than application level. I submit this Digium problem was not unique or even uncommon. The vast majority of UC solutions (all?) on the market were not designed for dynamically scalable multi-modal communications.
The obvious solution is to end-of-life the current product and replace it with something better. Alas just a few complications with that – first this new product is years away, may not even exist, and it’s a gamble in its own right. This is not a feature set that gets added in a new release, but a core change to the architecture. Further complicated by the fact Asterisk is doing just fine – gaining popularity, heading into larger accounts, and attracting more interest from developers, resellers, and end users.
Instead, Digium opted for a “companion” product strategy – keep Asterisk going strong (version 1.8 released last week with long term support) and simultaneously start on a brand new architecture – Asterisk SCF. The announcement was the easy part, now for the tall order of developing an open-source cutting-edge framework. Even worse is many of the loyal Asterisk developers are not familiar with Internet Communications Engine. Digium has to attract new talent to use new unproven technologies, to build a framework unlike anything that has ever been built. It sounds crazy, but realistically Digium might be able to pull this off. Why? For one because it did it before. But also because Digium has a clear vision that it was able to communicate at Astricon, and a head start that was sufficient enough for a live demo, It also helps that the project has sizzle and solves a clear need with clear criteria for success. Asterisk SCF is not really needed today – it is a next generation technology. It isn’t a game changer yet, but has potential.
Digium developed the strategy secretly up to the Astricon keynote and is now actively recruiting community engagement. Conversely, commercial competitors will typically keep such efforts secretive nearly up to its release as a product. With most vendors, these conversations are internal, set by the CTO and development teams. It is reasonable to assume Asterisk SCF will be closely watched by competitors that need to solve the same problem. Asterisk SCF has implications to large enterprises, carriers, and cloud service providers. It’s distributed nature and API architecture will likely further blur the boundaries of private clouds, public clouds, hosted, and CPE. The cloud angle is intriguing, Asterisk SCF as envisioned will be optimized for the cloud.
Open source makes development efforts transparent, and Asterisk SCF is going to provide a rare glimpse into large system sausage making. But it is not the only initiative out of Huntsville. Asterisk progress will continue unabated, and expect some bigger news out of Switchvox which tends to follow Asterisk innovation. Some of the Asterisk 1.8 features should appear in Switchvox next year such as Google Voice and Microsoft Outlook integration. There’s also clues that Digium is still guarding a few secrets planned for next year such as a potential new endpoint strategy.
Related:
Text:The Next Big Thing: Asterisk SCF (UCStrategies.com)
Audio:Discussion with Kevin Flemming (VUC).
Special thanks to Jason Goeckeof Voxeo Labs who patiently answered my questions over Skype during Astricon. Jason was one of the few external advisors invited early into the inner circle of discussions that lead to Asterisk SCF.
