Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Wi-Fi Router Charts

Click for Wi-Fi Router Charts

Mesh System Charts

Click for Wi-Fi Mesh System Charts


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.

  1. What is your actual available bandwidth inbound & outbound?
  2. How many simultaneous calls do you need to sustain?
  3. What voice codecs are you using? And so, how much total bandwidth do you require?
  4. Do you have managed QoS on your network?
  5. 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:

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Don't Miss These

  • 1
  • 2