QoS for VoIP Is Not the Big Deal the Vendors Want You to Think
-
Here is one of those dirty little secrets of VoIP - it doesn't need QoS. Seriously. I know that this is blasphemy and this truly is not a universal statement and it isn't to say that you shouldn't have QoS since it is generally free to implement. But the reality is is that QoS is almost always unnecessary with VoIP and even most shops that think that they have it really don't and everything works just fine (and they swear by the QoS that they don't even have.)
QoS is tricky as it is very commonly misconfigured and misunderstood. So many, many smaller businesses have been running VoIP for years proving that QoS is not necessary, without knowing it. And many more skip QoS from the beginning, also demonstrating this.
There are a few points where QoS can exist, it can exist on the outgoing WAN link, on the LAN and at any point where there is a transition between network devices. On a normal LAN, even a very large one, links are rarely saturated. So LAN QoS is generally useless. In the SMB having link saturation between networking gear is almost unheard of and solving saturation issues with QoS is often very silly and ineffective compared to fixing the saturation itself with faster links or reduced traffic. If QoS is needed for the VoIP traffic, everything else on the network is delayed as well. So the QoS is, at best, a band aid or preventative measure but not a useful, regular tool.
For all intents and purposes, we can assume that LAN traffic is simply not a candidate for viable QoS. We can do it there and if the effort is low there is little reason not to, so I am not recommending avoiding it. Just the assumption that it will ever prove useful is what is incorrect. Also, VoIP traffic does not have audible delay until we hit around 200ms, which is an eternity of a delay on a LAN. LAN QoS would be normally about gaining a few milliseconds at best (unless other problems are just enormous.)
The real need for QoS is when our data is bottlenecked and heading out to the WAN. Here is where good QoS can be very useful and, for normal RTP traffic, it is nice to add it to ensure that RTP traffic is not waiting on other protocols. This is free (normally) and beneficial as the "other party" will get an improved audio experience.
Where we cannot have QoS is on the inbound audio side of things, the RTP stream coming in from our WAN. The upside here is that generally if there is going to be an audio problem it is more likely to be heard internally than externally. But this is rare and generally not an issue and when it is, QoS cannot help us.
The majority of audio problems happen the traffic has already left the network and is on the Internet at large where QoS has already been dropped. If problems are going to happen there there is little that we can do, QoS won't help us. But for the majority of SMBs using VoIP, it will work fine here.
Is QoS good? Of course. But the utility of it is often very low and rarely delivers the assumed value that people expect for VoIP traffic. Also telling is that vendors often swear that VLANs and VoIP QoS are absolutely essential for good audio, yet many competing technologies like Skype, Skype for Business, WedEx, Slack, Google Hangouts and more, often services that deliver far more demanding workloads that just VoIP alone, never recommend or even suggest QoS be applied indicating that the need is very much one of perception and not one that generally affects us in the real world.
