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.”
Phase 1: A Beginning
I started tinkering with Asterisk early in 2004 when v0.70 was the current release. At that time I assembled my first Asterisk server using older hardware that I had on-hand. It was Dell Optiplex GX110 tower with a 733 MHZ Pentium III processor. The hardware was due to be decommissioned, so I re-purposed it as an experimental PBX for my office.
I added three single port FXO cards to handle three of our four analog lines. These devices were called X100P, aka “WildCards.” Little did I know how appropriate that name was for that hardware. Lastly, a snom 200 SIP phone graced my desk at that time.
This box was completely not ideal for my home office. It was everything I would later come to despise in an Asterisk server. It was big and loud. It drew a considerable amount of power and therefore threw off a substantial amount of heat. It’s 20 GB disk was old, slow and probably would not be reliable over time. Even so, that old beige box had three things going for it; it’s CPU and memory was adequate for the task, it would handle the FXO cards, and it was free. In short, it was something to get me started.
I used that server for about six months, essentially just long enough to prove out the idea that Asterisk might become the basis for our home & home office phones.
I learned a lot along the way. One of the key lessons at that time was a simple truism;
FXO interfaces suck!
I had a very difficult time with the combination of our SBC analog lines and the X100p cards. There were issues of echo, noise and lines remaining off-hook long after the call had ended. It was by all accounts a mess.
The trouble with analog interfaces was so bad that in May 2004 when Sipura had a public beta program for their new SPA-3000 I signed up right away. The SPA-3000 had one FXS and one FXO port, so I used it to bring my main office line into the PBX as a SIP device, dropping one of the X100P cards. The SPA-3000 was better behaved than the X100P, but it was not without its own issues…primarily a problem with inadequate audio levels.
Phase 2: Built-to-Order
When I finally decided to build a computer specifically for Asterisk I turned to Logic Supply to find a small format system based on a low-power VIA CPU. The idea was to build a small, fanless and possibly diskless system. Along the way I decided to purchase one of Digium’s new TDM400P cards, with 3 FXOs, to replace the troublesome X100P analog interfaces.
I put considerable thought into building this little system. I knew that I wanted something quite, reliable and low-power. It was only going to run Asterisk so a 500 MHz VIA C3 CPU was more than enough. That meant that I could go with a fanless mini-ITX motherboard in a small form factor case.
The system had a 60 watt power supply, meaning that it drew less power than my laptop at that time….much less than the elderly Dell. While the motherboard was fanless, the case had one small, very quiet, low-speed fan for the DC-to-DC converter. It also accepted 2 PCI cards, allowing me to add a second NIC and the TDM400P card.
Instead of ordering a disk I ordered a CF-to-IDE adapter as I was determined to try the newly released Astlinux. Astlinux was a new embedded Asterisk+OS distribution that was designed to boot and run from flash media.
Also about this time a friend was just ending a period of experimentation with Asterisk. Whereas I had been bitten by the Asterisk bug, they had not. So they decided to give me a Polycom Soundpoint IP600 desk phone that they had been using. It was a major step up from the snom 200, which I resold on E-bay.
The VIA system stayed in service as our PBX for about a year. It was more than up to the task. Astlinux also proved to be a good choice.The system booted to a 256 MB CF card and stored VM to a USB key plugged into the rear panel.
At this time we were using a Covad DSL line that was 1.5 MB x 768 kb. This drove me to learn about QoS and traffic shaping using m0n0wall, which I ran on a Soekris Net4501 system. It also caused me to I load four G.729 licenses installed to the server. By using G.729 we made better use of the available bandwidth, especially the outbound leg.
While the TDM400P card was better than the cheapo X100Ps or the SPA-3000 device, it was still far less than ideal. Nagging problems with the analog interfaces ultimately drove me to simply give up on them altogether.
I developed a strategy for moving away from POTS lines over time. To begin I established an account with a ITSP who could provide DIDs on our area. Then I had SBC add remote access call forwarding to our analog lines. Next, I call forwarded the analog lines to the DIDs I had from the ITSP. In this manner our analog lines now arrived via IP. However, if the ITSP or DSL had problems I could release the call forwarding and get the analog lines back.
This proved to be a good strategy for evaluating the reliability of what would come to be called SIP trunking. When after six months I realized that I had never had to defeat the call forwarding I simply ported the numbers out to the ITSP and canceled the analog lines.
Phase 3: Smaller Yet
After a year of running Astlinux on the VIA box I decided that I was due for a project. I knew that I didn’t need any PCI slots as I was no longer using physical interfaces to bring in analog lines. There would be no PCI slots required in the new host platform.
I had been so happy with m0n0wall running on the Soekris Net4501 that I decided to try Astlinux running on the slightly faster Soekris Net4801. In theory that would free up the VIA box to be upgraded and re-tasked as a file server for music.
This project went so well that I decided to write it up for Tim Higgins over at Small Net Builder who published it in January 2006. I later republished the article here when I launched this blog.
It’s worth noting that Digium didn’t launch their Asterisk Appliance Developers Kit until September of 2006, and their Asterisk Appliance itself in early 2007. Astlinux-on-Soekris hardware was an idea that was truly out in front of the trend.
The Soekris Net4801 was a good platform for running Astlinux. However, there was a limit to how much I could use G.729. The 266 MHz Geode CPU could only handle two simultaneous channels of transcoding. This was perhaps not ideal, but it turned out that it wasn’t a big problem.
Not long after we put the Net4801 system into service we were able to get an upgrade to our DSL service. We went from 1.5M x 768k to 2.2M x 1.0M. This improvement reduced the need for using the G.729 codec, which made using Astlinux on the Net4801 even more practical.
I had finally achieved my Asterisk nirvana. Our local Asterisk server was dead silent, cool running and drew only 15 watts. It booted from a CF card and stored configs & VM to a USB key. It went from off to fully functional in under 90 seconds, with no user intervention. It was nearly perfect.
Phase 4: Small…But Faster!
One of the problems of being someone who likes to tinker is that I tend to be restless. Just as I complete a project I am already considering ways that I could improve it if I were to do it again. So it was that when someone gifted me a box of HP T5700 series thin clients that were due to be recycled I saw an opportunity to rework the Astlinux server, yet again.
I received a box eight identical HP T5700s from a friend who was an IT manager for a local company. They were actually about to pay Dell to recycle these little goodies. In saving the devices from that fate I spared the company that expense.
One of the projects for the T5700s was a music server, which I documented here. But before I undertook that project I first used one as the basis of an Astlinux system.
The Net4801 and the T5700s are similar in many respects. However, the T5700 has a 1 GHz Transmeta CPU, giving it enough grunt to perform transcoding or run a heavier Asterisk distribution, like Ward Mundy’s PBX-In-A-Flash.
They also had the advantage of having a traditional VGA port and on-board audio should I decide I need to use chan_console. They also have an array of standard ports including 4 x USB, serial and parallel.
The T5700s normally boot from a flash “Disk-On-Module” (aka DOM.) I elected to make minimal changes to the one that would host Astlinux. I removed the DOM and built a USB key with an Astlinux image. Then I set the T5700 BIOS to boot from USB devices first. Thus my Astlinux server booted from a USB key.
The T5700 was an improvement over the Net4801 only in that it was more convenient. I could perform admin functions with a keyboard and monitor directly connected. It had more CPU power, but I doubt that I ever truly need that. It draws about 12 watts of power, is completely fanless…but so was the Net4801.
Summary
So in my time using Asterisk I made use of four different D.I.Y. servers. From a re-purposed tower I refined my host platform based upon my needs and the evolution of my personal definition of an “Asterisk appliance.”
The trend was “green” as it constantly moved in the direction of using less power and operating cooler, so requiring less use of air conditioning. It was also about reliability in that systems without spinning disks or fans are inherently less likely to fail.
Here’s a synopsis of my personal definition of appliance:
- Physically small
- Fanless
- Diskless
- Low power consumption (<15 watts)
- Low heat output
- Silent
- Boots to a fully functional state on application of power with no user intervention
By the summer of 2008 I had decided to abandon the use of a local PBX, instead favoring a hosted PBX service. The reasons for this are many, but the biggest one being the ability to rely upon someone else to administer the system in my absence. Shortly after I made that decision for myself my employer decided to follow the same path, using the same provider, and putting me in charge…so I’m back on the hook again…at least in a small way.
While this might seem like the end of this tale, it’s actually the beginning. I’ve been intending to take a look at the current landscape of Asterisk Appliances, including some DIY approaches that I’ve recently seen. Understanding what I value in an “appliance” is critical to appreciating any comments that I might offer on those other approaches.
This post has laid the foundation for whatever comes next.