I’ve recently been reflecting upon my history as an Asterisk user and the evolution of my preference for embedded systems (aka appliance) approach to Asterisk servers.
The path that I’ve followed is probably typical of a lot of people in many ways. Perhaps by sharing my experience I can help some people avoid some of the problems that I have faced, and understand how I arrived at my personal definition of an “Asterisk Appliance.”
One project that I’m am about to start is moving from my m0n0wall router to a new one build around pfsense. The motivation for the project is the integration of our Comcast Business Class internet service into the rest of the household. At present there are two separate networks, with only a few devices enjoying the high speed cable service. The pfsense system will be configured for dual WAN, accessing both the cable service and Covad DSL circuit.
My existing m0n0wall runs on an old Soekris Net4801. In service for many years, it has been extremely reliable. If m0n0wall does what you need I have no hesitation in recommending the software. Support from the user community is tremendous as well.
After a relatively long quiet period the Astlinux mailing list has been fairly active lately. This is thanks in part to some new users who have been extending the distro to meet their needs. Like any open source project, the more the merrier, even if we sometimes bring differing visions to the party.
During the VOIP Users Conference call on December 14th someone made some claims about the ability to handle G.729a encoded calls on various platforms. The comments revolved around the significance of cpu cache when dealing with the G.729a codec. Also some claims of the ability to deal with very high numbers of calls. The claim about the numbers of simultaneous transcodes possible were troubling to me.
G.729a is one of the more complex codecs in the VOIP universe. It puts considerable load on the CPU of the system that must for whatever reason transcode the call. In particular it’s FPU intensive. While CPU architectures are deeply interesting to me, suffice it to say that on some hardware platforms floating point operations are amongst the slowest operations that a CPU may perform.
Of course transcoding is not always necessary. A call may be placed from a phone that is itself G.729a capable, through the local Asterisk instance to an ITSP and on to the recipient…all of which are also G.729a capable. The call can thus be made without any transcoding at all. However, at any point along the path the a stage may not accept G.729a stream and so the call gets transcoded into something more acceptable, perhaps G.711 or GSM. Most typically calls that get routed to voicemail are transcoded to G.711 for the VM subsystem, although not always. Asterisk always transcodes into G.711 for MeetMe conferences.
I know for a fact that the Soekris Net4801 embedded platform can handle two G.729a transcodes when suitable licenses are installed. I used this very arrangement for over a year, and even wrote an article about it here.
The Net4801 features a National Semiconductor Geode SC1100 CPU running at 266 MHz with an unspecified amount of cache. When I first started using G.729a on the Net4801 I inquired with Kristian Keilhofner, the lead author of Astlinux, about his experience with the board. Kristian told me that 2-3 simultaneous transcoded calls was the most I could expect due to CPU limitations. My own experience supports his assertion.
More recently I’m using a HP T5700 thin client which features a Transmeta Crusoe CPU running at 1 GHz and with 512 kb of L2 cache. Under test conditions I’ve had four G.729a transcodes ongoing on this platform, but my test was limited to having only four licenses installed. I suspect that it could handle a few more channels, but the CPU use with even four concurrent channels points to a hard limit perhaps around 10 channels. I may well test this myself some day soon should the need arise.
Finally, Digium’s TC400b PCI card is specifically built to accelerate transcoding and offload that task from the host CPU. According to Digium, “The TC400B is rated to handle up to 96 bi-directional G.729a transformations or 92 bi-directional G.723.1 transformations.” If this is the stated capability of their accelerator then it seems unreasonable to expect similar or greater performance from a small format embedded platform, whatever the CPU cache might be.
The statements mentioned previously indicated the potential for a dramatically larger number of transcoded calls than would seem to be possible on the given platform. I find this unlikely on the basis of personal experience, the opinion of others whom I respect and Digium’s own statements about their transcoding hardware.
If you need transcoding capability on a low cost embedded platform it can’t hurt to consult with sources you trust. Ultimately you should conduct your own testing to be certain that the hardware supports your requirements reliably under real-world circumstances.
Back in January of 2006 I wrote an article about my experience building an embedded Asterisk server based on the Astlinux embedded distribution and a Soekris Net4801 single board computer. Here’s the link.
What with all the recent enthusiasm for “Asterisk Appliances” this article seems more useful then ever. It’s a little bit dated as it references Astlinux 0.28 and 0.29 whereas Astlinux is presently around 0.45.
Even so the article is written from the point of view of a Linux novice and includes a glimpse into manually editing the configs using SSH from a Windows PC. There’s minimal emphasis on GUI, which should make some people happy.