One of the areas that I am very interested in right now is coming up with new ways to distribute Asterisk services across multiple servers, both locally with Asterisk clustering, or distributed with servers across the internet. Off and on this year I have been working on an event system. I want to have a framework that is easy to use such that when certain events occur on one server, they can be propogated to a federation of servers.

This effort is broken down to two main parts:

1. Internal Event API
2. Event Distribution Methods

Internal Event API

The first phase of this effort is to come up with a generic API for generating events inside of Asterisk. This is different than the Asterisk Manager Interface (AMI). The code for generating Asterisk manager events is very specific to the manager interface and does not lend itself toward using this information anywhere else in Asterisk.

I consider this part of the project to already be pretty mature. There is a generic, binary encoded event publish and subscribe API in Asterisk trunk. I have already converted some things to use it, such as Voicemail message waiting information (more on this later!), but a more aggressive effort to convert things to use this API will be done after phase 2 has matured.

Here is the header file for this API if you are curious.

Event Distribution Methods

This part is a little bit more tricky than the first. The project here is to take the binary encoded events that are passed around using the internal event API and distribute them between a distributed network of Asterisk servers. This part is still very much in development.

I have completed a module to implement one method of distributing events. I set it up and verified that voicemail message waiting state was distributed and available between multiple servers. This approach works great for some network scenarios, but not for others.

Details

I have more to say on the specifics of what I’m working on. I will be making follow up posts on this topic to describe details of the event distribution methods I come up with as well as what features are being converted to take advantage of these new underlying features. I can say now that the areas that I have been working on so far are sharing voicemail and device state (presence) information.

I hope that people will find this work useful as it progresses.

Astricon is coming up very soon, so I figured I would point out some of the things that the development team will be doing at the conference.

There are two big pre-conference activities for Tuesday, September 25th.

• Asterisk 101 – An introduction to Asterisk
• Developer 101 – An introduction to Asterisk development

Myself, and a number of other developers, will be spending all day talking about important things to know to be an active Asterisk developer. Some of the things we will be talking about are:

• Source code layout
  • Where do I find the code that handles X?
• Debugging
  • Built-in debugging tools, useful debugging techniques, best practices
• Community Interfacing
  • Using the issue tracker, submitting changes, where to have discussions

If there are any specific topic that you can think of that we should cover, please let me know. I hope you will be at Astricon!

There is a new Asterisk API in town, and it is called Audiohooks. It was developed by Joshua Colp, a fellow Asterisk developer and friend. As you may have inferred from the name, the audiohooks API lets you add hooks into the audio passing through an Asterisk channel. There are a lot of exciting things that can be done with this, including places where it is already in use.

First, let me explain how this came about. Since Asterisk 1.2, there have been a couple of applications called ChanSpy and MixMonitor that allow you to listen in on any call on the system or record any call, respectively. (Even earlier than 1.2, there was the Monitor application, but MixMonitor is more efficient when it comes to mixing the Tx and Rx audio for a channel.) This is especially useful in call centers … or for Big Brother. However, the implementation has been problematic. It has been a long road of crashes and deadlocks that has caused the underlying code to be re-written multiple times. The Audiohooks is the latest chapter in the saga of ChanSpy and MixMonitor.

If you’re hardcore, here is the header file that defines the API. However, I’ll continue here and give an explanation of the cool things this will let us do.

Continue reading →