What Is QoS? DSCP Marking for Smooth Teams Calls (2026)

What Is Quality of Service (QoS) and How Does It Work?

Quality of Service (QoS) is a policy for handling network traffic during contention, determining how packets are prioritised and queued when links become congested. It is not a bandwidth upgrade, does not add raw throughput, and cannot guarantee end-to-end performance across unmanaged paths. QoS commonly involves classification, marking and queue scheduling, with policing or shaping also possible; the exact functions depend on the device and design. In typical implementations, classification identifies the traffic type (such as matching source ports or protocols), marking sets a DSCP value in the IP header or a CoS value in the Ethernet VLAN tag, and queue scheduling determines which queue is serviced when an outbound link experiences contention.

While Teams provides a clear benchmark, the DSCP and queueing model applies across business networking generally. For instance, dedicated SIP trunks and VoIP desk phones typically require DSCP 46 (EF) for voice RTP and DSCP 24 (CS3) or 26 (AF31) for call control; video surveillance streams generally warrant AF41; and offsite backup replication or bulk file syncs are best tagged with DSCP 0 (best effort) or scavenger classes so they back off during business hours. In Teams deployments, Microsoft describes QoS as using DSCP markings together with port-based ACLs to identify, mark and classify real-time media packets: when a router sees a packet arrive on a configured port range, it can identify the media type, place the packet in the corresponding queue, and add a DSCP marker before forwarding it. QoS must be configured and verified at each relevant congestion point; an unconfigured or remarking hop can prevent the intended treatment across that segment, but does not necessarily invalidate QoS everywhere.

Crucially, QoS does nothing to a link that isn't congested. On a quiet connection, marked and unmarked packets travel identically. The entire point of QoS is to control behaviour at the moment of contention — exactly when a large file upload or a second video call starts competing for the same slice of bandwidth as someone's Teams meeting.

The Metrics QoS Is Actually Trying to Protect

QoS exists to manage three variables that determine whether a real-time call sounds clear: latency (how long a packet takes to arrive), jitter (how much that arrival time varies from packet to packet), and packet loss (how many packets never arrive at all). A composite score sometimes used to summarise the listener's subjective experience is Mean Opinion Score (MOS), but this research set doesn't include specific pass/fail thresholds for any of these, so they're worth understanding by symptom rather than by number.

High latency causes people to talk over each other because the natural pause-and-reply rhythm of conversation breaks down. Jitter is what produces the classic robotic or warbling audio artefact — the receiving device's jitter buffer has to either stretch or compress the audio stream to compensate for packets arriving unevenly, and if the variation is too large, it runs out of room to hide it. Packet loss causes outright dropouts, garbled syllables, or frozen video frames. QoS can reduce queueing delay and protect marked traffic from competing local flows during congestion, ensuring voice and video packets aren't stuck waiting behind large file transfers; it cannot guarantee low latency, jitter or packet loss end to end.

Layer 2 CoS vs Layer 3 DSCP: The Teams Mapping Matrix

DSCP (Differentiated Services Code Point) is a field inside the IP header that can be carried across routed networks when devices and providers preserve it. CoS (Class of Service, 802.1p) is a separate 3-bit field inside an Ethernet VLAN tag, used by switches on trunk links within the LAN; CoS is local to Layer 2 segments and normally must be mapped at routing boundaries. Consequently, DSCP and CoS typically work together rather than as alternatives — CoS prioritising frames across the switch fabric, and DSCP carrying classification across routed boundaries where supported.

Microsoft publishes standard Teams recommendations for DSCP values and matching client port ranges, which provide a predictable model for real-time traffic. These values are recommendations rather than universal requirements across every collaboration tool, Teams client or network vendor. Microsoft’s connectivity guidance separately specifies UDP 3478–3481 for Teams media connectivity — with UDP 3479–3481 handling transport-relay media alongside STUN on UDP 3478 — whereas QoS classification uses the client source-port ranges shown below; verify the exact role of each port for the deployment. The table below outlines Microsoft's standard recommendations.

Why Fixed Ports Matter: Sizing and the "Automatic Port" Trap

Microsoft publishes standard Teams client recommendations of audio 50000–50019, video 50020–50039, screen sharing 50040–50059 and signalling 50070–50089 (with 50060–50069 remaining unallocated). Microsoft Teams Rooms QoS guidance similarly specifies DSCP 46/EF for audio, DSCP 34/AF41 for video and DSCP 18/AF21 for screen sharing. As noted above, these Microsoft baselines should be verified against your specific endpoint hardware and software release. Fixed source-port ranges provide a predictable matching condition for Microsoft’s recommended Teams policy; administrators should monitor and adjust them as required when workloads change.

The failure mode Microsoft warns against directly explains why QoS policies can appear active while real-time media degrades. Microsoft recommends specifying fixed port ranges and instructs administrators not to select automatically available ports when implementing QoS. When left to automatic assignment, a client can use any available port between 1024 and 65535, making fixed media classification unavailable for the policy. A fixed source-port rule will not match traffic using automatically assigned ports, so that particular classification and marking policy will not apply unless another policy handles the traffic.

The Public Internet Problem: Why QoS Stops at Your Router

DSCP only influences forwarding on devices configured to read and respect it. Inside a managed corporate LAN, edge router, or controlled private network, policies are applied consistently because each hop is configured. However, you should not assume DSCP treatment across public Internet transit: providers and networks may preserve, remark, ignore or reset markings. End-to-end prioritisation requires explicit provider support and contractual service characteristics, as public Internet services provide no inherent QoS guarantees.

The practical consequence is that QoS configured on an office router cannot govern traffic across a remote worker's home broadband or public Internet hops to external call participants. An office router can order outbound packets leaving the local building, but cannot dictate queuing behaviour across third-party infrastructure. For stronger end-to-end treatment, specify a provider service with documented QoS classes, capacity and SLAs; an SD-WAN overlay can help steer and manage traffic but does not automatically guarantee public-Internet performance.

SME vs Enterprise: LLQ on Routers vs SQM on DrayTek, UniFi and pfSense

Many enterprise platforms support LLQ or other class-based scheduling. On platforms using strict-priority or LLQ queues, configure appropriate bandwidth limits or policing so priority traffic cannot starve other classes. Matching DSCP values like Teams' EF and AF41 allows predictable treatment, but requires administrators to configure and maintain classification rules matching application marks and ports across each managed device.

In the UK SME market, routers such as the DrayTek Vigor series (ubiquitous in UK branch offices) expose dedicated App QoS and bandwidth limits in their web UI, while UniFi gateways and pfSense appliances implement SQM algorithms like FQ-CoDel or Cake. Rather than manually carving out guaranteed bandwidth per application, these modern SQM algorithms actively manage queue depth on the link and share capacity fairly across active flows. This directly targets bufferbloat — the build-up of packets queued inside a router or modem buffer during link saturation, which inflates latency and jitter even when packets are not dropped. A connection can pass a speed test showing full bandwidth and still degrade real-time audio the moment a large upload saturates the buffer. When correctly configured, FQ-CoDel or Cake can reduce bufferbloat and improve fairness between flows, but they do not guarantee call quality.

Verdict: Do You Still Need QoS on a 1 Gbps Full-Fibre Connection?

Yes. Headline speed describes capacity — how much data can fit down the pipe — not queuing behaviour, which is about what happens in the brief moments the pipe is actually full. Most UK business full-fibre services delivered over Openreach or CityFibre infrastructure remain asymmetric: a standard 1 Gbps FTTP package typically provides only 115 Mbps upstream (or 70 Mbps on 500 Mbps lines). A scheduled cloud backup, large file upload, or multiple outgoing video streams can easily saturate that narrower upstream pipe, causing bufferbloat on edge devices that spikes latency and jitter for live calls. QoS or an SQM equivalent provides the policy that protects interactive media during local link contention.

For UK business procurement, Microsoft's published DSCP and port recommendations serve as a baseline specification for MSPs, switches, Wi-Fi access points, firewalls and WAN routers. Consider voice or media VLANs where appropriate, but specify the required trust boundaries, DSCP handling and queueing behaviour for each LAN, Wi-Fi, WAN and endpoint design rather than requiring a voice VLAN universally. Deployments also benefit from setting source and destination IP addresses to 'any' in port-based rules per Microsoft's guidance, and monitoring and adjusting port ranges as workloads change. Network diagnostic tools should be used before and after configuration to verify that traffic is actually being classified and queued as intended.

Sources

Every figure in this article traces to the sources below.

• •Microsoft — Teams QoS implementation, DSCP values and port ranges
• •Microsoft Learn — classification and queuing mechanics for Teams QoS
• •Microsoft — guidance against automatically assigned ports for QoS
• •Microsoft Learn — Teams Phone transport-relay UDP ports
• •Microsoft — Windows client QoS policy port mapping
• •Microsoft — Teams Rooms device QoS DSCP values