It seems I eat so much of my own dog food these days that I don’t have time to enjoy a nice steak every now and again. My experience with Asterisk hasn’t been any different.
[ Watch the screencast: Inside Trixbox 2.0 ]
Because I see little sense in writing about what I don’t know, I downloaded Trixbox in November, and within two weeks, my whole lab -- and later, my whole house -- was running on a single Asterisk instance under VMware Server. Equipped with a few SIP trunks through BroadVoice, two Verizon PSTN lines attached through Sipura SPA-3102 ATAs (analog telephony adapter), two analog cordless phone sets, a few SIP softphones, and a handful of Cisco 7960 and 7970 IP phones, the implementation is complete -- and I have a few new scars to show for it.
The first thing that became apparent is that although it’s certainly possible to run Asterisk in a virtual machine, unless the deployment is small, it’s not scalable. This isn’t a matter of performance -- more one of protocol and ATA maturity. With PSTN lines in the equation, it’s definitely worth deploying a physical server with either analog or TDM line cards. SIP ATAs work, but they’re generally fraught with little problems such as poor echo cancellation, audible tones when used to place calls, configurations hassles, and so on. The experience with TDM and analog cards is far better.
That said, I’m running two Linksys/Sipura ATAs on two analog lines, and they work well enough to keep. I also maintain two BroadVoice SIP trunks for long-distance use. These lines behave relatively well but occasionally suffer from brief loss of DTMF (dual-tone multifrequency) functions and re-registration problems. These problems appear far less frequently than when initially configured, however. Once functional, they tend to stay that way, though attaining this harmony required more than a little tweaking.
With these trunks configured within Asterisk, I was able to easily construct a dial plan that would force local calls out to the PSTN lines in an outbound hunt and long-distance calls to flow over the main BroadVoice SIP line. With BroadVoice, each SIP trunk can carry multiple voice channels, so several simultaneous calls can be made on a single line. The secondary line is used for inbound external numbers. For instance, I have local numbers in Manhattan and San Francisco that link to this number, allowing me to create different inbound call routing for callers to those lines rather than the main SIP line. This is due to the fact that no DID (direct inward dialing) information is available for my “phantom” numbers, so I have no way of determining the called number. In practice, this configuration could be simpler, but it’s functional for now.
Having run this setup for a few months now, I have every intention of keeping it. The benefits of a full-fledged PBX accompanied with the long-distance cost savings and ease of use make it a no-brainer. In fact, the ease of use -- and my own laziness -- was brought into sharp focus recently when I found all the phone lines tied up when I needed to make a call. I set up an IAX (Inter-Asterisk eXchange) extension in 30 seconds, downloaded JackenIAX for my MacBook Pro, logged in to the extension, and placed a call from my laptop. After all, isn’t technology supposed to make our lives easier?