I am extremely proud to be able to point out that Digium has acquired Switchvox.
Switchvox is an amazing packaged PBX system that is based on Asterisk. A team from Digium did an extensive analysis of the products available in this area, and concluded that the Switchvox package was superior in terms of features as well as ease of use.
Check out the Switchvox features and some screenshots.
Part of the plan is to work with the Switchvox team to take parts of the technology they have developed, and contribute it back to the open source community. As Mark Spencer noted in this interview,
“So as a contrast right, look at what Fonality did. They bought an open source project [trixbox/asterisk@home] and then turned it into a proprietary product. What we are trying to do is go the other way. Take something that started out as a fully proprietary product and to try to leverage that to bring some additional technologies into open source. That’s an interesting angle that I don’t think anyone has covered.”
This is an extremely exciting time for the world of Asterisk. This will have a great impact on our ability to bring the power of Asterisk to the mass market, while also continuing to drive the development of open source telephony. Everyone wins.
More details will be available in the near future as we approach Digium Asterisk World.
The process of developing, releasing, and maintaining Asterisk 1.4 has certainly been a learning experience. I have been putting a lot of thought into the things that we have been dealing with and would like to propose some changes to the way that we manage releases.
Over the past few years we have gone from not having managed releases, to Asterisk 1.0, 1.2, and now 1.4. Over this time period we have transitioned from everyone using the development code directly to now nobody using the development code for any real purpose. This has both been a great thing and a curse at the same time, as I have come to realize.
See the full mailing list post here.
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:
- Internal Event API
- 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.
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?
- 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.