Your Office Network: Part 5 of 10
We have covered the equipment in your network closet, why wired beats Wi-Fi for voice, what switches do and why managed ones matter, and how VLANs give your phones their own lane on the network. All of those pieces set the stage for the topic that ties them together: Quality of Service.
Quality of Service, or QoS, is the mechanism that tells your network equipment which traffic matters most. Without it, your network treats every packet the same way, whether it is a voice packet from an active phone call or a chunk of a software update downloading in the background. With it, voice packets get to the front of the line.
If you have read our fundamentals post on Quality of Service, you already have a solid understanding of the concepts. This post covers the same territory from a practical, office-network perspective: what you need to do, where you need to do it, and what you can realistically expect.
The problem
Picture your router at 2 PM on a busy Tuesday. Twenty people are working. A few are on phone calls. Others are in video meetings. Someone started a cloud backup. A software deployment is pushing updates to a dozen computers. Three people are streaming training videos over lunch.
All of this traffic funnels through your router on its way to and from the internet. The router has one outbound connection: your internet link. If your internal network runs at gigabit speeds but your internet connection is 200 megabits per second, the router is a funnel. Everything has to squeeze through.
Without QoS, the router handles this traffic on a first-come, first-served basis. Every packet waits in the same queue. When the queue fills up because more traffic is arriving than the internet link can carry, the router starts dropping packets from the end of the queue. It does not know or care what those packets contain.
The software update does not care. It uses TCP, which detects the dropped packet and retransmits it automatically. The user never notices. The video meeting buffers for a moment and recovers. The cloud backup slows down slightly.
But the voice call cares. Voice uses UDP, which does not retransmit. A dropped voice packet is gone. The listener hears a gap, a click, or a moment of choppy, robotic audio. A few dropped packets in a row and the call becomes hard to follow. And unlike a video meeting that can buffer a little, voice is real-time. There is no buffer to absorb the delay. The packet either arrives on time or it is useless.
This is the problem QoS solves. Not by creating more bandwidth, but by ensuring that when bandwidth is scarce, the traffic that cannot tolerate delay gets served first.
How QoS identifies voice traffic
Before the network can prioritize voice packets, it has to know which packets are voice. There are several ways to identify them, and in practice, most VoIP deployments use a combination.
DSCP marking
DSCP stands for Differentiated Services Code Point. It is a 6-bit field in the header of every IP packet that can carry a value indicating what type of traffic the packet contains and how it should be treated.
The standard DSCP value for voice traffic is 46, which maps to a forwarding behavior called Expedited Forwarding (EF). This is the highest-priority forwarding class intended for user traffic. When a router or switch sees a packet marked with DSCP 46, it knows to treat it as real-time voice that needs immediate forwarding with minimal delay and minimal loss.
Here is the important part: most VoIP phones mark their packets with DSCP 46 by default, right out of the box. You do not need to configure this on the phones. They do it automatically. The phones are already telling the network "this is voice traffic, please prioritize me." The question is whether your network equipment is listening.
On an unmanaged switch, the answer is no. Unmanaged switches do not read DSCP markings. They forward every packet the same way regardless of what the DSCP field says. The phone is asking for priority, but nobody is home to hear the request.
On a managed switch with QoS enabled, the switch reads the DSCP value, recognizes that 46 means high priority, and puts the packet in a priority queue. On a properly configured router, the same thing happens at the outbound interface where traffic leaves your network.
VLAN membership
If you have implemented VLANs as we described in the previous post, the network has another way to identify voice traffic: VLAN membership. Everything on the voice VLAN is, by definition, voice traffic. The switch and router can apply priority rules to the entire VLAN without needing to inspect individual packet headers.
This is one of the reasons VLANs and QoS work so well together. VLANs provide the classification (this is voice traffic), and QoS provides the action (give it priority).
802.1p priority
When a packet is tagged with a VLAN ID (using 802.1Q, as we discussed in the VLAN post), the tag includes a 3-bit priority field called 802.1p or CoS (Class of Service). This field can carry a value from 0 to 7, with higher numbers indicating higher priority. Voice traffic is typically assigned a value of 5.
The 802.1p priority works at Layer 2 (the switch level), while DSCP works at Layer 3 (the IP level). In a well-configured network, these two systems are aligned: a voice packet tagged with 802.1p priority 5 on the VLAN also carries a DSCP value of 46 in its IP header. The switch uses the 802.1p value for its internal queuing decisions, and the router uses the DSCP value for its outbound queuing decisions.
Most managed switches can be configured to map between these two systems automatically. When a packet arrives with DSCP 46, the switch assigns it 802.1p priority 5 for internal handling, and vice versa.
The three things that need to happen
Making QoS work for VoIP requires three things to be in place. If any one of them is missing, the chain is broken and voice packets do not get the priority treatment they need.
1. Phones mark their packets
As mentioned, most VoIP phones do this by default. They stamp every voice packet with DSCP 46. You should verify this is happening rather than just assuming it, especially if your phones are older or if your VoIP provider uses non-standard configurations.
If you are using softphones (VoIP applications on computers) rather than hardware desk phones, the situation is slightly more complex. Some operating systems restrict applications from setting DSCP values on packets unless the application has elevated permissions. Windows, in particular, has a Group Policy setting that controls whether applications can set DSCP markings. If your softphone packets are leaving the computer with DSCP 0 (best effort, the default), they will not receive priority treatment regardless of how well the rest of the network is configured.
Your VoIP provider or IT team can verify that phones are marking correctly by capturing a few packets and inspecting the DSCP field.
2. Switches honor the markings
This is where managed switches earn their keep. A managed switch with QoS enabled reads the DSCP value (or the 802.1p value if VLANs are in use) and places the packet in the appropriate internal queue.
Most managed switches support at least four priority queues, and some support eight. The typical mapping puts voice (DSCP 46) in the highest-priority queue, video (DSCP 34) in the next, important data in the third, and everything else in the default best-effort queue. The switch services the highest-priority queue first, ensuring that voice packets are forwarded with minimal internal delay.
On an unmanaged switch, this step is missing entirely. The switch has one queue, processes packets in order of arrival, and the DSCP markings are invisible to it. The phone's packets still carry the DSCP 46 marking, and if they reach a managed switch or router downstream, the marking will be honored there. But within the unmanaged switch, voice gets no special treatment.
This is why we emphasized in Part 3 that a managed switch is important for VoIP environments. The switch is not just a passive connector; it is an active participant in traffic prioritization.
3. The router prioritizes outbound traffic
This is where QoS has the most impact. The router's outbound interface, where your internal network meets your internet connection, is the most common bottleneck in any office network. Your internal network runs at gigabit speeds. Your internet connection is probably 100 to 500 megabits per second, maybe faster, maybe slower. Every packet leaving your network has to pass through this bottleneck.
When more traffic is trying to leave than the internet link can carry, the router has to decide what goes first and what waits. Without QoS, it is first come, first served. With QoS, the router checks each packet's DSCP marking and places it in the appropriate outbound queue. Voice packets (DSCP 46) go into a strict priority queue that is serviced first. Everything else goes into lower-priority queues that are serviced when the priority queue is empty.
The result: during periods of congestion, voice packets experience near-zero additional delay at the router while file transfers, backups, and updates absorb the wait. The file transfer takes a fraction of a second longer. The voice call stays clear. This is almost always the correct trade-off.
The router is also where you set the bandwidth cap for the priority queue. This is an important safety measure. If you leave the priority queue uncapped and something misconfigured floods it with traffic (marked as DSCP 46 but not actually voice), it can starve all other traffic on the network. A typical configuration reserves bandwidth equal to your maximum expected number of simultaneous calls plus a safety margin, usually 10 to 20 percent of your total upload bandwidth.
For example, if you have a 100 Mbps upload connection and expect a maximum of 20 simultaneous calls, each requiring roughly 100 Kbps, that is 2 Mbps of voice traffic. You might set the priority queue cap at 5 Mbps to provide generous headroom while ensuring that 95 Mbps remains available for everything else.
QoS on the switch versus the router
People sometimes ask whether they need QoS on both the switch and the router, or if one is enough.
The short answer: the router is more important, but having both is better.
QoS on the router protects voice traffic at the most critical bottleneck, the internet connection. This is where congestion is most likely to occur because the internet link is slower than the internal network. If you could only configure QoS in one place, the router is the place.
QoS on the switch protects voice traffic within the internal network. This matters when internal traffic is heavy: large file transfers between computers, backups to a local server, multicast traffic, or high-volume data between departments. If internal traffic never creates congestion, switch-level QoS is less critical. But if internal traffic does occasionally spike, switch-level QoS prevents those spikes from affecting voice.
In practice, if you have invested in a managed switch (which you should, per Part 3), enabling QoS on it is straightforward and there is no reason not to do it. Belt and suspenders.
What QoS does not do
This is important to understand so you have realistic expectations.
It cannot create bandwidth
QoS decides which traffic gets priority when there is not enough bandwidth for everyone. It does not make your internet connection faster. If your 50 Mbps connection is consistently running at 50 Mbps because your actual usage requires that much, QoS can prioritize voice within that 50 Mbps, but it cannot add a 51st megabit.
If your total traffic demand routinely exceeds your internet capacity, you need a faster connection. QoS buys you time during temporary bursts, but it cannot compensate for a connection that is fundamentally undersized. If you are evaluating whether your ISP connection is adequate, QoS should be part of the conversation but not a substitute for adequate bandwidth.
It only works on equipment you control
Once your voice packets leave your router and enter your ISP's network, your QoS settings no longer apply. ISPs strip DSCP markings at their network edge or ignore them entirely. This is not occasional or inconsistent -- it is standard practice across virtually all consumer and business internet connections. ISPs have no reason to honor priority markings set by their customers. If they did, every customer would mark all their traffic as high priority and the system would collapse.
This means QoS protects your voice traffic from congestion within your own network and at your router's outbound interface. It does nothing for the internet leg of the call. If the problem is jitter or packet loss occurring somewhere between your ISP and your VoIP provider, QoS on your end will not help. And that internet leg is where the majority of VoIP quality problems actually live.
Dedicated internet access helps not because of end-to-end QoS guarantees (those are rare and expensive even on DIA circuits), but because DIA provides consistent, uncontested bandwidth with SLA-backed performance commitments. The connection itself is better, which matters more than packet markings.
It can mask the real problem
This is worth understanding clearly. If your network is congested enough that voice quality suffers without QoS, enabling QoS will keep calls clean by pushing the congestion onto other traffic. The calls sound better, but the congestion is still there. File transfers slow down. Cloud applications lag. And because the calls sound fine, nobody investigates.
Congestion is a signal. QoS suppresses that signal for voice while leaving the underlying problem in place. For most small and medium offices, the better response to congestion is to find out what is causing it and fix it -- whether that means upgrading the internet connection, scheduling backups outside business hours, or replacing a router that cannot handle the traffic volume. A network that is properly sized for its workload does not need QoS to keep calls clean.
QoS is genuinely valuable on large networks where some congestion is unavoidable -- contact centers, large campuses, environments with hundreds of concurrent calls. At that scale, traffic prioritization is a legitimate engineering tool. For a typical office, it is more often a band-aid over a problem that should be solved directly.
It cannot fix broken equipment
QoS prioritizes traffic within a functioning network. If your switch is dropping packets because of a hardware defect, or your router is crashing under load, or your cables have bad terminations, QoS will not compensate. Fix the underlying hardware problems first, then apply QoS to optimize traffic handling.
It requires correct configuration
Misconfigured QoS can make things worse than no QoS at all. If the wrong traffic is marked as high priority, it crowds out actual voice traffic. If the priority queue bandwidth cap is set too high, non-voice traffic starves. If DSCP markings are being stripped somewhere in the path, packets that should be prioritized are treated as best effort.
This is not a reason to avoid QoS. It is a reason to configure it carefully and verify it is working as intended. Running a VoIP quality test during business hours, with QoS enabled, is the definitive way to confirm that voice traffic is actually getting the priority treatment you configured.
Practical setup summary
Here is the sequence for implementing QoS in a typical small or medium office. The specific configuration steps depend on your equipment manufacturer, but the logic is the same everywhere.
Step 1: Verify phone markings. Confirm that your VoIP phones are marking voice packets with DSCP 46 (EF). Most do this by default. Softphones may need operating system configuration to allow DSCP marking.
Step 2: Configure the switch. On your managed switch, enable QoS and configure it to honor DSCP markings. Map DSCP 46 to the highest-priority queue. If you are using VLANs (which you should be, per Part 4), enable 802.1p and map voice traffic to priority 5.
Step 3: Configure the router. Create a QoS policy on your router's outbound (WAN) interface. Define a strict priority queue for DSCP 46 traffic. Set a bandwidth cap on the priority queue that covers your maximum expected call volume with margin. Place all other traffic in a default queue or create additional queues for video and important data if your router supports it.
Step 4: Configure inbound QoS if supported. Some routers support inbound QoS (also called ingress policing) to prioritize incoming voice packets over incoming data. This is less common and less impactful than outbound QoS because you have less control over the rate at which packets arrive from the internet. But if your equipment supports it, it provides additional protection for the download direction of voice calls.
Step 5: Test during business hours. Configure everything during a maintenance window, then test during a normal business day with typical traffic loads. Listen to calls during the afternoon peak when the network is busiest. Measure jitter and packet loss on voice traffic. If the numbers look good under load, your QoS is working.
Step 6: Monitor and adjust. QoS is not set-it-and-forget-it. As your office grows, as traffic patterns change, and as you add new applications and devices, the balance of traffic shifts. Review your QoS configuration periodically and adjust the bandwidth allocations if needed.
The relationship between QoS and the rest of the series
QoS does not exist in isolation. It works best as part of a coherent network strategy.
Wired connections eliminate the jitter and loss that Wi-Fi introduces, giving QoS clean traffic to work with. If voice packets arrive at the switch already damaged by wireless interference, QoS can prioritize them but cannot un-damage them.
Managed switches provide the hardware capability to read DSCP markings and enforce priority queuing internally. Without a managed switch, QoS only works at the router.
VLANs provide clean traffic classification so QoS knows exactly which traffic to prioritize. Without VLANs, QoS has to rely entirely on packet-level inspection, which is less reliable.
Together, wired connections, managed switches, VLANs, and QoS form a stack of protections that give your voice traffic the best possible chance of arriving intact, on time, every time. Any one of them helps. All of them together transform your local network from a variable that threatens call quality into a foundation that supports it.
The bottom line
Quality of Service is not complicated in concept. It is the idea that not all network traffic is equally urgent, and the network should reflect that reality during moments of congestion. For VoIP, the implementation comes down to three things: phones mark their packets, switches honor the markings, and the router prioritizes outbound voice traffic at the internet bottleneck.
But keep two things in perspective. First, QoS only operates on your local network. It does nothing once packets hit your ISP. Most call quality problems originate on the internet side, where your QoS configuration has no effect. Second, if you are experiencing call quality problems that QoS would fix, that means your local network is congested, and you should understand why before you cover it up with traffic prioritization.
If you have been experiencing call quality that degrades in the afternoon, or calls that sound fine most of the time but occasionally fall apart, the first question to ask is not "do I have QoS configured?" It is "why is my network congested?" The answer might be an undersized internet connection, a backup job running during business hours, or a router that cannot keep up with the traffic load. Fix the root cause and QoS becomes insurance for unexpected spikes rather than a crutch for an undersized network.
What comes next
The next post in the series moves beyond the core infrastructure and into the practical realities of managing an office network over time: firmware updates, monitoring, documentation, and the ongoing maintenance that keeps everything running smoothly after the initial setup.
This is Part 5 of the Your Office Network series. Part 6 covers ongoing network management and maintenance, the work that keeps your office network healthy after the initial setup.
Share
Want to know when we publish new articles? Sign up for updates