Introduction
For the past ten years I have worked from a home office full time. This has been the major motivation for my education in networking, and onward into VOIP technologies.
Since the middle of 2005 we have not used traditional land-lines
(POTS) for either our home or office phones. Our transition to VOIP was
not flawless, but with some lessons learned along the way the system
has proven very reliable. Over the course of several posts I hope to
pass on those lessons that have served us well so that others may also benefit.
In the telling of this tale I will mention a number of devices many
of which are not the current state-of-the-art. This doesn’t matter. I’m
relating to you the actual devices I used. The principles will hold true for any similar current device.
Some Installation Basics
Here are a few fundamental considerations when planning a VOIP implementation using DSL.
- What is your actual available bandwidth inbound & outbound?
- How many simultaneous calls do you need to sustain?
- What voice codecs are you using? And so, how much total bandwidth do you require?
- Do you have managed QoS on your network?
- Can you also implement traffic shaping to reserve bandwidth for
VOIP purposes? Especially outbound bandwidth as this is typically the most scarce.
To begin to answer these questions, let’s start with some basic facts taken from my home office installation.
- My DSL service provides 2.2 M x 768k of measured, confirmed bandwidth.
- I need to sustain a minimum of four (4) simultaneous calls
- I will prefer G.729a encoded calls.
This is the codec typically used by ITSPs that have a reduced bandwidth feature
and requires ~ 20 kbps per call leg (inbound & outbound) including IP overheads - I must accommodate G.711 encoded calls.
This is the baseline codec used on the PSTN and
requires approx 80 kbps per call leg (inbound/outbound).
Based upon these simple facts, my VOIP activity could require from
80-320 kbps bandwidth in each direction, depending upon codec mix. Since I
expect calls incoming from several providers, some which don’t support
G.729a, I cannot force all calls into G.729a. However, my primary
provider will handle G.729a calls so the 320k figure is likely a worst case number.
What is QoS?
You hear an awful lot about QoS, which stands for Quality Of Service. In point of fact, it means different things to different people depending upon their perspective, telco or IP networking.
The big picture perspective tends to think of QoS as being the entire customer experience with the phone service.
- Do the calls get connected?
- Once the calls are connected do they sound good, bad or otherwise?
- Are there specific issues causing problems?
From a networking perspective, the term QoS has more specific meaning with respect to the management of traffic through a network.
It’s helpful to acknowledge that QoS in our SOHO scenario is an
"edge" phenomenon. That is, its impact is felt in the router where
traffic passes from your network to the ISP. Since the available
bandwidth is asymmentric, the problems usually arise on the outbound
data side. The remote party will think the call is "choppy" or
"burbling" but you will not hear any problems. This is a sure sign that you have QoS and/or bandwidth management issues.
As good backgrounders, your should study the following articles:
As a practical matter, DiffServ is the most common protocol deployed, which means that Ethernet frames are tagged for a specific Type Of Service. These are usually referred to as TOS tags.
TOS settings are established in Asterisk via the SIP.CONF and IAX.CONF files. There is really not much to this in Asterisk, as the tricky bit, prioritizing the traffic, happens elsewhere in the network.
It’s also worth thinking about QoS across the broader internet
backbone as a whole. This is commonly though of as potentially a good
thing, but ultimately may not be so good. It’s presently not available,
and very likely never will be. Here’s some well informed opinion on the matter:
- Why We Don’t Need QOS: Trains, Cars, and Internet Quality of Service by Dan Bricklin
- Why there’s no Internet QoS and likely never will be by Brough Turner
QoS Features In Small Routers
SOHO users like myself are unlikely to have high-end networking gear supporting their home office setups. My initial experience with VOIP over broadband involved using Vonage and a Linksys BEFSR-41 broadband router. At the time Vonage was the leading phone-over-broadband service and the BEFSR-41 was the leading SOHO router.
It helps to frame this up in time. I used Vonage back in 2002. At
that time Vonage was providing customers with a Cisco ATA-186 analog
terminal adapter as the device to bridge the network to a couple of FXS jacks. The ATA 186 was the very first widely deployed ATA.
Cisco ATA 186 Analog Terminal Adapter
The Cisco ATA 186 is a single function device. As such it had very
basic networking features. It could assign DiffServ TOS tags but relied
upon the upstream network devices to manage traffic priority. This is typical of many low cost ATA devices even today.
Some time later Vonage shifted to providing a Motorola ATA device.
This new device had the added feature of inserting itself into your
network between the router and the rest of the LAN. Positioned in this
manner it could itself ensure that the VOIP traffic received priority.
This type of hardware is now the more common way that consumer
phone-over-broadband companies address the unknown network circumstances of their customers.
The combination of the ATA 186 and the Linksys BEFSR-41 ultimately
proved troublesome. Actually, they worked well enough together, but any
other network activity could potentially interfere with the VOIP
traffic causing choppy sounding calls. This was especially likely to
happen if I had Outlook connected to my employers VPN. Outlook could
easily saturate the outbound side of the DSL and the VOIP calls would
suffer. The BEFSR-41 simply provided no mechanism to prioritize one sort of traffic over another.
After suffering with this problem some time, I found that Linksys had released a new router with built-in QoS features, the BEFSR-81. Since I had been happy enough with the first Linksys device until the VOIP troubles I bought the newer one immediately.
Linksys BEFSR-81 router with QoS features
The BEFSR-81 provided two means of traffic management; by physical Ethernet port, or by TCP-IP protocol and port.
QoS settings menu for Linksys BEFSR-81 router
It was a simple matter to put the Cisco/Vonage ATA on port 1 of the router and assign that port the highest priority. This took care of my QoS issue as long as I used Vonage.
As to its internal workings, according to Linksys literature the BEFSR-81 provides, "QoS Capabilities Based on IEEE 802.1p and IP TOS/DS Greatly Reduces the Chance of Data Loss Based on Weighted Round-Robin (WRR)"
The port based QoS feature is a little too simplistic to effectively
support an Asterisk server as it doesn’t allow you to assign QoS to a
range of ports as required for SIP media. You can see in the screen
shot where I had this setup for SIP signaling (port 5060) and IAX2 (port 4569.)
There was a period where Linksys let firmware development for the
BEFSR-81 lapse. At that point the current firmware release that I tried
had a serious bug that caused the device to lock up with startling
regularity. At the time Linksys didn’t seem at all interested in
providing a resolution even though the fault was well known on public
forums like Broadband Reports. This motivated my eventual migration to m0n0wall.
It is interesting
that the BEFSR-81 remains a current product as of December 2007. Its
cost/feature combination makes it in some ways it is an ideal device for non-technical SOHO users.
An Alternative To QoS In The Router
What if you can’t or simply don’t want to replace your router? There are other options. Both D-Link and Hawking Technology
(amongst others) make "voip accelerator" devices that are designed to
add QoS to a network that otherwise lacks such capability. (Hawking’s HBB1 is reviewed here). Both of
these devices are installed between the existing router and the rest of
the users network. All traffic passes through the device, which can thus identify RTP streams and prioritize traffic accordingly.
There are threads on the Vonage users forums that would indicate that these devices really do help some people with QoS issues. YMMV.
Recommending A Router
There are about three short of a zillion low cost consumer routers
available. It is not my intention to make specific recommendations
about hardware routers. Instead I’d rather convey my experience with those that I have actually used.
However, I will make one exception to this. If you are interested in
learning about routers, feel like supporting an open source project,
and cost is not your major concern, then I suggest you consider m0n0wall.
Addendum: I just happened to learn that the Linksys BEFSR-41 v4
router does in fact have a QoS feature like the BEFSR-81 that is the
basis of much of this article. Apparently this become possible in the v4 hardware revision.
In the second and final part, I’ll look at Traffic Shaping and Power Considerations.