Today, we’ll begin to look at the core changes made in the previous release of Asterisk and refined over the past year for Asterisk 13. Specifically, we’ll look at the Stasis Message Bus, and how it helps make Asterisk a robust platform for users and application developers alike.
A Better Core for Better APIs
After AstriDevCon 2012, we set two goals for Asterisk’s APIs:
- Improve the consistency of information Asterisk provides to consumers of its APIs.
- Make it easier to write a custom communications application using Asterisk’s APIs.
Meeting the first goal required changes within the core of Asterisk. Without these core changes, there was no way for us to make it easier to write communications applications using any of Asterisk’s APIs. However, making the changes in the core required improving two fundamental parts of Asterisk:
- How Asterisk informs key components within itself about events that occur. Many of Asterisk’s interfaces were tightly coupled with the internal producers of information — channels, bridges, devices, etc. In the new Asterisk architecture, interfaces subscribe to an internal message bus for the information they need, and core objects produce messages informing subscribers about what occurred. This makes it easier to extend Asterisk and provides a layer of insulation for interfaces from changes to the core.
- How Asterisk bridges channels. To provide consistency across complex call scenarios, Asterisk now uses an improved Bridging Framework to manage channels in a bridge. This facilitates better control of the channels and removes the need for some historically complex channel operations.
These two fundamental aspects of Asterisk are provided by two new major components: the Stasis Message Bus and the Bridging Framework. In this blog post, we’ll explore the first of these.
The Stasis Message Bus
The Stasis Message Bus is an internal publish/subscribe message bus in Asterisk. As the real-time components of Asterisk change the state of channels, bridges, and other primary communications objects, they publish those state changes to the Stasis Message Bus. Components in Asterisk that want to consume this information — such as the Asterisk Manager Interface (AMI) or the Call Detail Record (CDR) Engine — receive the state changes and transform the information according to their interface logic. For AMI, this means converting the Stasis messages to AMI events. For CDRs, this means updating internal state and dispatching records to registered CDR backends, such as a Comma-Separated Value (CSV) logger.
This decoupling of the real-time components that produce information from the consumers of that information provides several major benefits:
- A common internal API for all consumers of real-time information. This allows us to add new capabilities to Asterisk in a much more efficient manner.
- Insulation from changes in the core and other APIs. A change to the CDR engine does not impact the AMI API, and vice versa.
- Consistency across all APIs. Since all subscribers to the Stasis Message Bus receive the same information, APIs now have a consistency to the scenarios they present to their clients. At the same time, each API can choose — based on their own intended purpose — what information from the message bus they share with their clients.
Combined, these benefits helped us improve the existing APIs in Asterisk as well as develop new ones. However, while the Stasis Message Bus helped enable new APIs in Asterisk, specifically, the Asterisk REST Interface (ARI), additional core changes were still necessary. As we’ll see in an upcoming blog post, to provide a clear and consistent model of the lifetime of a channel regardless of call scenario complexity, we required a new Bridging Framework.
To be continued…