A new open-source technical toolkit (based on Linux, Asterisk, OpenSER and perhaps OpenSS7) is emerging for Voice 2.0 applications. In this note we will discuss the elements that go into it, the possibilities and problems involved, and the consequences of these developments for existing operators.
Two kinds of technical change: conservative…
Technological change is happening in several forms in the industry. One of these mainly affects how existing network designs and business models are executed. For example, switches that were once dedicated hardware systems running extremely specialised software are being replaced with softswitches which run on standard bladeservers or even PC-servers. OSS-BSS installations, similarly, are migrating from being monolithic enterprise systems based on mini- or mainframe technology into standard data-centres. Across all of these, the underlying operating system is increasingly likely to be Linux or another of the open-source Unix variants. CAMEL and IN are being replaced with applications servers, frequently implemented in Java, which provide (usually) XML interfaces for further development.
But none of this, by itself, changes the fundamental business model. It still implies a world of big, closed telcos who get their equipment from a small number of large vendors, whose business model and general philosophy is essentially that of a hardware company. And it often implies a centralised IMS or hybrid SS7/IP architecture.
So far, this has mostly been a question of cost reduction. Google, Sun Microsystems, and the Internet Archive have shown the way in terms of providing high-availability, high-performance IT using large numbers of low-cost PC servers, virtualisation, and open-source operating systems, and no doubt the telcos are moving that way as well, at least the less hidebound ones. Cost reduction is an honest goal, after all. It’s no revolution, though.
For that, you’ve got to look at the wing of the open-source community that wants to replace you entirely.
…and revolutionary
The core of the new voice community is Asterisk, the free PBX which has grown into a general-purpose telephony solution. It is no overstatement to say that every Voice 2.0 player we’ve interviewed turns out to be using Asterisk somewhere in their system. The key advantages of Asterisk are the classic ones of open-source software - you can do what you want with it, and as a result it offers great feature richness. For example, it supports unified messaging out of the box, using the standard IMAP e-mail protocol, and it handles a wide range of network protocols, both telco and IETF.
Where it genuinely excels is in the scope it provides for systems integration and applications development. The Asterisk dialplan language permits fairly extensive customisation and some application logic to be built directly in a configuration file, but things get genuinely interesting through its AGI and AMI features - Asterisk Gateway Interface and Asterisk Manager Interface, which permit Asterisk to execute other programs from within the dialplan and permit other programs to control Asterisk from either a local or a network connection respectively. Further, Asterisk’s version of a BSS/OSS interface is a database connector that can be invoked in any of these options to write CDRs into a database, to populate the dialplan with users dynamically, or to store users, configuration data, and the like so that many Asterisk instances can be cloned, as in this presentation by Serge Kruppa at ASTRICON on building a carrier-grade call centre with it.
Many, many small applications
Performance is not, of course, in the AXE10 class. One of the downsides of the feature-richness is that in many modes of operation, the audio stream must pass through the Asterisk server, which makes it a highly-concurrent application and therefore causes scaling issues. The canonical approach to scaling Asterisk deployments is to multiply and distribute the nodes, thus keeping the maximum concurrent calls on any given instance down to the low hundreds. Sam Houston State University, for example, has 6,000 users with six servers, but only two of them are used for call processing rather than voicemail or PSTN interconnection. The world’s biggest Asterisk installation, an enterprise project carried out by Synetrics, has over 100,000 lines and 6,500 concurrent calls. Pennsylvania University’s Asterisks are serving 30,000 end points.
This is, of course, a typical post-Google IT architecture, which would imply a similar approach to the back-end databases. Indeed, this is roughly what Mapesbury Comms’ UK01 Mobile service is doing to minimise its costs. There’s a fascinating talk on running a really big Asterisk deployment on Amazon EC2 by Nir Simionovich here, from this year’s AMOOCON.
Even if running an entire service provider this way is unrealistic, however, handling voice and messaging within a specific application, enterprise, or call-centre is precisely what Asterisk is designed to do. At the other end of the scaling spectrum, it has been successfully compiled and used on a bewildering variety of embedded platforms, including set-top devices and SOHO WLAN routers. We recently saw a handheld WLAN router with cellular backhaul that one UK mobile operator will soon be pushing; imagine if you shipped them with an Asterisk node installed with its native Web GUI, preconfigured to talk to your infrastructure. It’s an office in your pocket.
OpenSER and OpenSS7 - aiming for scale
If you need really high performance, you ought to be looking at the OpenSER and related projects. This is a long-running open-source project to develop both a SIP media server and a simpler, higher-performance SIP router (Open SIP Express Router). It’s being used by several of the Voice 2.0 companies we mentioned above in conjunction with Asterisk, as what the IP world would think of as a gateway router or load-balancing proxy and what the telco world would think of as a tandem switch, in order to terminate incoming bulk SIP connections and distribute them among the Asterisk nodes. This makes it possible to push towards telco scale, whilst keeping the complexity of the call-processing abstracted from the networks outside.
And if that isn’t enough for you, there’s also the OpenSS7 project, which aims to provide an open-source SS7 implementation for use either with classic transport types or with SIGTRAN over an IP network. Their performance figures are impressive - back in this post, we pointed out that their HLR implementation is designed for 4,000 transactions a second.
Conclusion: enterprises, MVNOs, and Voice 2.0 are driven by open-source
So, the take-away lessons are that if you have a major enterprise business, and even more if you do IT/systems integration, you will soon be asked by your customers for Asterisk. And if you aren’t, perhaps you should consider offering it to them. Beyond that, even if you are unlikely to substitute the core infrastructure for a swarm of Asterisk boxes, you should be aware of it as an option for any new voice or messaging application you want to build, as a strong option for voice-centric services for SMBs, and as something developers you work with will almost certainly want to use with your services.
Further, other open-source communities are working hard to reduce the scaling gap between their products and the traditional vendors’. This is likely to be a major empowering factor for MVNOs, MVNEs, enterprise networks, independent developers, and all kinds of disruptors, but it can also do the same for your own new ideas. Small operators may yet benefit from looking at a total overhaul.
