Our Asterisk based home/office phone system provides tremendous flexibility in handling our phone calls. It gave us the opportunity to migrate away from using analog phone lines from a traditional carrier. We now send and receive all calls via IP over our DSL. Of course, the monthly cost of our calling is a lot less. However, it’s not a prefect system – yet.
From the outset, we have worked to make the system more robust. This we have done in many ways, including providing various redundancies in hardware and configuration. Most recently, we have added a cellular trunk to ensure calling capability should our DSL service fail. The process involved in arriving at this decision has proven interesting.
VOIP systems are more than just a phone line coming into the office/home, so there is more potential for problems. To prevent issues from occurring, it is best to address the potential problems before they happen. In our system, our VOIP has a number of redundancies built in to increase its reliability.
To begin with, the phones themselves, a combination of Polycom and Snom SIP phones, are registered both to the local Asterisk server and a remote service. The phones automatically failover, so if the local server is unresponsive, we can still make outgoing calls.
In addition, our phone numbers (aka DIDs, for Direct Inward Dialing numbers) provided through an online service provider also provide a failover system. My preferred service providers offer failover to a normal phone number, which I generally point to my cell phone.
Our Asterisk server provides it’s own form of redundancy as well. It is registered with three commercial service providers and a couple of free VOIP services including Free World Dialup. If any service provider is not available, it will cascade to another, and then a third. This is really only useful, however, when making outgoing calls.
Redundant Asterisk servers are, I think, a little beyond the scope of a typical home or home office environment. The sort of Linux clustering skills required to set this up are certainly beyond my present skill set. Also, redundant servers are more than a little inconsistent with my use of appliance-like Asterisk embedded systems.
Another area of redundancy that I need to address is connectivity. Some might assume this to imply network / Internet connectivity. But that’s only one possible connection methodology.
The simplest and probably most common approach here would be to keep one or two analog phones lines (POTS, for "Plain Old Telephone Service") and connect them to FXO interfaces on the Asterisk server. These are often called analog trunk lines. When so configured, calls could proceed via traditional wire-line service if IP connectivity was lost.
This is not an approach I choose to deploy for three reasons. First, analog FXO interfaces have, in my experience, been fiddly and unreliable, to be avoided if at all possible. Admittedly this opinion was something that I arrived at some time ago, before the most current crop of Sangoma, Pika and OpenVox hardware was available. Even so, the extra hardware would add to the cost of the implementation and would force us to use a larger host platform that can handle a PCI card.
Secondly, the monthly carrying cost of POTS lines is not inconsiderable, especially if you add a few “extra calling features” such as caller ID. One of the many sorry aspects of the 1996 Telecom Act was the deregulation of fees for ancillary services like caller id, directory service, listing services, etc.
Finally, the only provider of analog lines in our area is AT&T, a company that I have decided I’d rather not give my business to for personal reasons. So it was that some time ago we decided to drop our analog lines and move to a 100% VoIP phone system, whatever that might entail.
Redundant IP Connectivity
On the surface, redundant IP connectivity would seem to make sense. But one fact of VOIP life is that certain things about networking can be more difficult than they should be.
For example, the SIP protocol can make firewall and NAT traversal troublesome. Making an Asterisk server load-balance across two ISPs is even more complex. At the root of this is the fact that the end-point source and destination IP addresses are passed in the VoIP traffic. The Asterisk server itself is expected to have only one IP address, not two.
Voice-over-broadband providers themselves go to significant effort to load balance traffic. Like clustering Asterisk servers, this takes more effort than makes sense for a home office. So on my case, even though I have both DSL and cable modem service at my location, it appears that my VoIP traffic will use only one of these connection, at least for now.
There is an often overlooked third connectivity mechanism that we can leverage—wireless via a cellular carrier. This can effectively create a digital cellular trunk into Asterisk and potentially solves a number of problems. This is the thrust of the rest of this article.