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, it’s 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’s 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 thought 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
In part 3 I’ll give an overview of QoS mechanisms in small routers.