Chris Tooley just recently gave it a test run and saw a boost of about 10% in the number of call setups per second that his machine could handle.
I would encourage others to give this a try when load testing your system. There is virtually no setup other than installing hoard. There are some Asterisk functionality that I feel would see much greater performance improvements than have been demonstrated so far.
I am excited to point out the John Todd has joined Digium as the new Open Source Community Director. John joins us with a vast amount of experience within the Asterisk community and beyond. Without further introduction, I will just point to John’s recent message to the development community in this mailing list post.
Also, see the Digium press release, as well.
Luigi Rizzo, a community developer for the Asterisk project has posted a message to the developers mailing list talking about some of the work that he and his students are working on. Previously, I pointed out how they had done work to allow you to use Asterisk as a softphone that supports video. Now, it sounds like they are taking this even further.
He talks about:
1) Merge console channel drivers in Asterisk.
Currently, there are three console channel drivers in Asterisk: chan_oss, chan_alsa, and chan_console. chan_console uses libportaudio to act as a cross platform channel driver. However, it does not have all of the features of chan_oss. Once chan_console has all of the features of the others, chan_console will be the single console channel driver.
2) Add support for multiple audio and video inputs for a single call.
This will allow switching between inputs within a call, as well as implementing interesting audio and video effects such as picture-in-picture or split screen during a call.
3) Make Asterisk run as a Firefox extension
This one completely blows my mind.
The goal here is to allow Asterisk to be embedded into Firefox so that the interface for making phone calls can be written within the web browser. It sounds like they already have this working, too! I can’t wait to see what this turns in to.
Admittedly, it seems like it could be overkill, but at the same time, Asterisk is an extremely powerful and flexible telephony platform. If the functionality of Asterisk was available as the backend for people that are capable of developing a great UI and user experience, the possibilities are quite interesting.
See the full mailing list post here.
Michiel van Baak has just completed some work for Asterisk 1.6 that cleans up a lot of the inconsistencies in the Asterisk CLI command interface. The code is now ready for testing.
See Michiel’s post on the asterisk-dev list.
See the related issue on the issue tracker.
Over the past week, there has been some debate over potential changes to our release process in the ares of release candidates and nightly builds. I have responded with some thoughts of my own on these issues:
See the post on the asterisk-dev list.
I just merged a new channel driver into Asterisk trunk which will be in Asterisk 1.6. The module is called chan_console. It is a new console channel driver which uses portaudio as a cross platform audio interface instead of using something like ALSA or OSS directly. I wrote it to give myself a console channel driver that I could use on my Mac. However, portaudio supports a number of other audio interfaces, as well.
The audio interfaces that portaudio supports are
- Advanced Linux Sound Architecture (ALSA)
- AudioScience HPI
- Macintosh Core Audio for OS X
- Windows Direct Sound
- JACK Audio Connection Kit
- Unix Open Sound System (OSS)
- Windows Vista WASAPI
- Windows WDM Kernel Streaming
- Windows MME
Asterisk-dev – Another Module for Testing: chan_console
Asterisk-commits – Commit to Asterisk trunk
I have a branch that is ready for testing that makes some significant changes to the Asterisk channel handling core. The changes improve the data structure management for Asterisk channels. This will provide a large performance benefit. See the following post to the asterisk-dev mailing list for more information, as well as where to get the code for testing.
Asterisk-dev – Request for Testing: team/russell/chan_refcount
I have published a document describing the details of the release management for Asterisk 1.6. See the full post to the mailing list here.
A few weeks ago, I proposed to this list that we create a new release series that is managed with a short release cycle to introduce smaller sets of new features. I also wanted to increase the emphasis that we put on testing new sets of functionality for potential regressions.
The feedback on this list was positive, as was all of the feedback I have received directly. I spoke to people about this a lot at Astricon, and received no negative feedback.
So, I would like to move ahead with formalizing this new release series, Asterisk 1.6. I have documented the new release policy that will apply to this release series, as well as some of the history that inspired these changes to release management.
I have included the document and would appreciate any feedback from the development community.
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.
I have made a post to the asterisk-dev mailing list describing a small project I am working on. I am making a way to create application timeouts, scheduled announcements, and periodic announcements that can be used with any Asterisk application. The results of the discussion will determine if this feature goes anywhere or hits the bit bucket.