Asterisk was originally built as a stand-alone system, a single central point for all telephony communication. In short, a PBX. Nowadays, the Asterisk Open Source telephony server, is used in many ways – many of them not really being PBXs. All kinds of applications are being powered by Asterisk.

While building applications with Asterisk, you soon realize that you’re limited to that single server. It’s hard to scale and one limiting factor is that the call state is being held in one server. Many services depend on call states – if an agent in a call center is busy, you need to find an available agent. If a trunk to the PSTN is in use, you might want to find another way out. Call states are important.

Of course, the Asterisk project is now working on the long term solution, the Asterisk SCF and the applications that will be built using this framework. But that will take some time. Meanwhile, the Asterisk PBX team has been working on a few ways to distribute the call states between a group of servers. This article will be describing a few of the different architectures being worked on.

Generic event distribution using OpenAIS

Russell Bryant started of by building a solution based on OpenAIS. This was focused on distributing all kinds of events internal to Asterisk between the servers, a more generic approach than to target just call states. This code is still considered experimental, but is very interesting.

State distribution using XMPP pub/sub

Brad  Watkins continued the process by contributing a state distribution solution using XMPP publish/subscribe functionality. This was a bit more focused on getting call states to work, where Russell’s work was more open to other states, like voicemail and possibly other events in the future – PRI trunks going up and down, conference rooms opening up and queues being activated.

State distribution using SIP

During the fall of 2010, Brad and I started working on Pinana – a project based on using the SIP publish/subscribe framework to distribute device and extension states in Asterisk. They are two different things. Device states is when an object in a channel driver signals a state, like in a call, unreachable, available. Extension states is an aggregated state – one extension in a server can have a state based on multiple devices. The connection between an extension and a device in Asterisk is called a hint.

State distribution using a SIP presence server

In the Pinana project, we use an external SIP presence server – Kamailio. We first publish the device state, so that all the Asterisk servers in the cluster can subscribe to it and get updates. One server publish the state change once and Kamailio will update all the rest of the servers in the group. This code exist today – the possibility to PUBLISH (in SIP terminology) a device state and SUBSCRIBE to it (as a hint device state provider).  These states are really only interesting for Asterisk internal use, not for anything else.

Going forward – publishing extension state for blinking lamps

The information that will be of use to other devices is the extension states. When we have stabilized and tested the code for sharing device states between a group of Asterisk servers, we will make it possible for Asterisk to PUBLISH extension states to Kamailio. This way, all phones in the network can subscribe to states for lines in Kamailio – thus offloading the work for Asterisk. Asterisk will send ONE message to Kamailio and Kamailio will forward it to all your phones. That’s a huge improvement.

Aiming for Asterisk 1.10

This work will be completed during the spring of 2011, hopefully to be merged in Asterisk 1.10. We currently have the device state part ready for Asterisk 1.4 and will start porting it to trunk now. The customer that funds this work needed it for 1.4 so it was a natural starting point for us. The code is available in the group directory on the asterisk.org subversion server – feel free to test and give us feedback.

To summarize: Asterisk is getting more scalable

With these three different approaches, the Asterisk PBX is definitely getting more scalable.  While Asterisk SCF is built with scalability from the ground, there are still a lot of things we can do to improve the Asterisk PBX that is in use today and help the installed user base to grow their systems. Some of them are available today, some is work in progress. I am excited about all these projects and look forward to using these new tools in production for our customers.

/Olle E. Johansson

Comments are closed.