Asterisk, like so many great inventions, was born out of necessity. In the initial use case, a college student named Mark Spencer needed a PBX for his burgeoning business. Unable to afford one, he wrote one in software instead to fulfill that immediate purpose. The early iterations of Asterisk functioned quite well as an SMB PBX; however, Mark had much more in mind when he designed the software.
The name "Asterisk" reveals this intention. In UNIX, the "*" character is the wildcard match, meaning it matches everything; thus the vision for software that could meet any communications-related need. Although grandiose and a bit unrealistic, this name shows an early understanding of a fundamental open source truism--when you give something away to the masses, you give away control of what it becomes.
Ideas are fickle and malleable things. When you form them in your mind, they can feel solid enough; however, once you share the idea with someone else, the illusion of stability dissipates and your original concept morphs into something unanticipated. Good open source projects not only account for this dynamic, they embrace it. It is the external creative spark that moves things forward. When you fail to embrace the chaos of community, disaster ensues.
A key example of unanticipated community chaos was the #McDStories Twitter hashtag that was briefly launched in 2012. McDonald's was hoping to capitalize on social media by inspiring the masses to share positive stories promoting the good times they've had at McDonald's. Instead, it completely backfired on them as people used the hashtag to tell stories of how McDonald's food made them sick. The takeaway is how volatile crowd-sourcing can be. You can seed the public with an idea, but once you release it, the plant that grows is no longer your own.
In the case of Asterisk, this organic, crowd-fueled evolution has been the driver for positive change. The Asterisk of today bears only scant resemblance to the software of last century. People took the ball and ran with it. They deployed Asterisk in unanticipated contexts that it wasn't initially designed to handle. This created new use cases that actually drove development. So it wasn't simply how Asterisk was being used that changed; deployment became a catalyst for the evolution of the software itself. This is how the Asterisk PBX became a communications platform.
The Modern Asterisk PBX
With a longstanding project, not only does the project itself evolve, but the industry surrounding the project evolves as well. Today, other open source projects such as FreePBX, Elastix and PBX in a Flash have built their entire solutions on top of the Asterisk platform. This allows for a simple setup and GUI configuration of Asterisk as an SMB PBX.
Asterisk as Media Server
A growing use case for Asterisk is that of providing media services as part of a SIP infrastructure. This is its predominant use within carrier networks and large enterprise deployments. Here, Asterisk is commonly paired with a SIP proxy that provides routing and load balancing.
Although there are many different proxies that function well with Asterisk, a popular one that has gained traction with the Asterisk community is the open source Kamailio SIP server. In fact, Matt Jordan, the Asterisk project lead, will be speaking on deploying Asterisk together with Kamailo at this year's Kamailio World Conference in Berlin, Germany.
In order to understand the "media server" use case, it is helpful to take a quick look at the basics of how SIP devices work. SIP endpoints are designed intelligently--they contain all of the technology necessary to establish sessions and communicate without the need for a server. For example, it is possible, though uncommon, to make a call from one SIP phone to another SIP phone without the use of an intermediary server. The phones possess all of the necessary mechanisms to establish the call, using SIP signaling to negotiate the specifics of passing audio between the phones as an RTP media stream.
This works well as long as the originating phone knows the location of the other phone. In order to route calls to disparate locations, a SIP proxy is inserted into the topology. The diagram below greatly simplifies the role of a SIP proxy server, but it is a helpful abstraction. In reality, there is a more complex set of logic at work, and there are a couple of points to note. First, the signaling that actually sets up the call goes to the proxy, which then forwards it on to the destination. Second, when a call is established, the media then begins to flow directly between the endpoints.
Similar to the first scenario, this topology works well until you want to add additional functionality. In this case, that functionality is media services, e.g. playing media streams to endpoints, recording media streams and mixing streams together (conferencing).
Most PBX functionality can be boiled down to a few primitive actions. With the ability to play, record and mix media, higher-level functionally can be created, such as IVRs, voicemail systems, conference servers, call queues and more. This is what Asterisk provides that the SIP Proxy does not, and it is how the two work together in large-scale deployments.
Next page: Examples of common topologies that employ Asterisk.
Here are two common topologies that employ Asterisk as the media server providing PBX services.
Load Balancing an Asterisk Cluster
In this example, each Asterisk instance is providing a full set of PBX functionality, and the SIP server is functioning as a load balancer. This has the advantage of adding fault-tolerance to the network so that if one PBX goes down, calls can be routed to the working systems. With proper design, scalability is greatly increased as additional servers are added to compensate for additional load. Here, although Asterisk is labeled as a PBX, it is actually functioning as a media server with the entire topology functioning as "the PBX."
Asterisk as a Feature Server
Another example shows each Asterisk instance adding a discrete function to the network, for example conferencing, voicemail and IVR systems. This has the advantage of being easier to implement, but ease comes at the cost of the flexibility. One of the largest Asterisk systems in the world handles 6 million calls a day. (Although this system employs SS7, rather than SIP, the principle of using Asterisk to provide discrete services rather than an all-encompassing PBX is well represented.)
Future Evolution
As the Asterisk project continues to evolve, recent additions include a new SIP channel driver and a new RESTful API. Both of these enhancements set the stage for future implementations. In their current state, they greatly enhance Asterisk's capabilities as a media server behind a SIP proxy. For example, the new modular SIP channel driver opens the possibility of tighter integration between the SIP proxy and media server. The REST interface allows full applications to live outside of Asterisk, furthering its identity as the media server and expanding and simplifying the solution development process.
What's ahead for the Asterisk community? It will be exciting to see how the open source community uses the new tools that are available and begins to implement them in creative ways, driving the next generation of applications.
