Plan for roughly recommended-quality one-to-one and group video bandwidth around 1,500 kbps up and down per endpoint, and up to 4,000 kbps per endpoint for best-performance calls, but treat these as starting points, not the definitive values. Run active diagnostics for jitter and packet loss, turn on QoS with the correct DSCP markings, and model concurrency with Network Planner before you size a site's internet connection. Group calls, large events, and screen sharing scale differently from a simple one-to-one call, and poor latency or jitter will make Teams downgrade video quality even when raw bandwidth looks generous.
TL;DR:
- Bandwidth recommendations vary from 1,500 kbps for normal calls to 4,000 kbps for high-quality video per endpoint, with scaled needs for group calls and shared content.
- Latency should stay under 200 milliseconds, packet loss below 2%, and jitter within limits to prevent Teams from degrading video quality during calls.
- Implementing and verifying QoS with correct DSCP markings and port configurations is essential before increasing bandwidth, as it fixes many quality issues at lower cost.
- Large events or encoder feeds require about 4 Mbps per viewer for 1080p streams, with wired Ethernet and eCDN used to manage high concurrent viewership efficiently.
- Active diagnostics for jitter, packet loss, and latency are more effective than simply upgrading internet capacity, especially if edge Wi-Fi or misconfigured firewalls cause call quality problems.
Table of Contents
- Per-endpoint bandwidth: what Teams actually needs
- How latency, jitter, and packet loss change call quality
- Setting up QoS: DSCP values, ports, and validation
- Sizing Town Halls, live events, and encoder feeds
- Building a testing and monitoring workflow
- Wi-Fi and edge fixes that don't require new hardware
- Why measurement beats buying more bandwidth
- Verify your network before you deploy Teams at scale
- Sources
- FAQ
Per-endpoint bandwidth: what Teams actually needs
Microsoft publishes three tiers for Teams bandwidth: minimum, recommended, and best-performance, and the gap between them matters more than most network plans account for. According to Microsoft's network preparation guidance, recommended one-to-one video calls run around 1,500 kbps up and down, while best-performance quality can require roughly 4,000 kbps in each direction. Group video calls often land in the 1,000 to 1,500 kbps recommended range per endpoint, scaling up toward 4,000 kbps at best-performance settings.
Screen sharing and content sharing add a separate load on top of audio and video streams, since Teams treats them as distinct media types with their own bandwidth allocation. Audio alone needs comparatively little, typically under 100 kbps, which is why Teams protects audio first when a connection degrades.
A few definitions keep sizing conversations consistent:
- Minimum is the floor at which a call functions, often with reduced resolution or frame rate.
- Recommended is the tier Microsoft targets for a normal business call.
- Best-performance is the ceiling Teams uses when the network has headroom for high-fidelity video, often 1080p or better.
Worked example: a branch office with 20 staff on video calls at recommended quality needs roughly 20 times 1.5 Mbps in each direction, or about 30 Mbps up and down, before accounting for screen sharing or best-performance upgrades. If half those staff also join from a mobile device alongside a desktop client, that's 30 separate endpoints, not 20, since Teams treats each connected device as its own stream. This is the calculation Network Planner automates when you model a site by persona rather than by headcount.
How latency, jitter, and packet loss change call quality
Bandwidth is only part of the equation. According to Microsoft's call quality monitoring guidance, roundtrip time should stay under 200 milliseconds for group calls, and packet loss should remain under 2%. Jitter, the variation in packet arrival time, also has defined tolerances, and Teams enforces its own send and receive limits to protect the call when any of these metrics slip.
Roundtrip latency under 200 milliseconds and packet loss under 2% are the thresholds Microsoft ties to reliable Teams call quality, according to Microsoft's monitoring guidance. When either threshold is breached, Teams reduces video resolution and frame rate first, since preserving audio intelligibility takes priority.
When troubleshooting a complaint, check metrics in this order:
- Confirm packet loss and jitter before assuming a bandwidth shortage.
- Check roundtrip time on the specific path, not just a generic internet speed test.
- Look for video degrading while audio stays clear, which points to adaptive throttling rather than a capacity problem.
Setting up QoS: DSCP values, ports, and validation
QoS is the lever most networks underuse. Microsoft's QoS implementation guide recommends configuring it before adding bandwidth, and it specifies exact DSCP markings: audio at EF (46), video at AF41 (34), and screen sharing at AF21 (18). Client source ports are also defined: audio uses 50,000 to 50,019, video uses 50,020 to 50,039, and screen sharing uses 50,040 to 50,059.
A practical deployment sequence:
- Enable the QoS setting in the Teams admin center so clients mark outgoing traffic.
- Push the DSCP markings through Group Policy or your device management platform.
- Configure edge routers and switches to honor and preserve those markings across the path.
- Verify markings survive VPN tunnels and NAT, since encapsulation strips DSCP values on many configurations.
- Capture traffic at the WAN egress and confirm the values persist end to end.
Common pitfalls include routers that reset DSCP by default and browser-based Teams clients, which can use dynamic ports and behave differently from the desktop app during validation.
Pro Tip: Test QoS with the desktop client first, then repeat the test with the browser client, since dynamic ports can make browser sessions bypass your marking rules.
Sizing Town Halls, live events, and encoder feeds
Large events follow different math than everyday calls. Per Microsoft's 1080p event guidance, a 1080p event stream requires about 4 Mbps, while a 720p stream without eCDN runs closer to 2 Mbps per viewer.
A 1080p Teams event stream needs approximately 4 Mbps, according to Microsoft's guidance on enabling 1080p resolution, which is the figure to use when calculating total egress for a large audience.
- Multiply per-viewer bandwidth by expected concurrent attendees to estimate total egress before eCDN.
- Use eCDN once viewer counts are dense enough that egress becomes impractical, since it redistributes the stream locally.
- Always connect event encoders by wired Ethernet rather than Wi-Fi to avoid variable throughput mid-broadcast.
- Provision roughly double the recommended encoder bitrate as a safety buffer against transient congestion.
Teams also applies adaptive bitrate streaming for events, meaning viewers on constrained connections automatically drop to a lower resolution rather than buffering outright.
Building a testing and monitoring workflow
A repeatable workflow beats one-off troubleshooting. Start with Network Planner to model a site before deployment, since it calculates bandwidth needs from persona and concurrency inputs rather than raw headcount. After rollout, use Call Quality Dashboard and per-user call analytics to review historical trends and flag sites that consistently underperform.
For active diagnostics, run tests that measure jitter, packet loss, latency, and bufferbloat specifically, since a simple download speed number will not surface any of them. GrandSpeed's speed test and streaming quality test report these metrics directly, and the guide to optimizing streaming with GrandSpeed walks through mapping those results to conferencing needs.
- Model the site with Network Planner before committing to a circuit size.
- Pull CQD and per-user analytics monthly to catch drift.
- Run active diagnostics for jitter, packet loss, and bufferbloat at problem sites.
- Escalate to the ISP only after confirming DSCP markings hold and capturing packet traces at egress.
| Workflow stage | Tool | What it tells you |
|---|---|---|
| Pre-deployment | Network Planner | Estimated bandwidth by site and persona |
| Ongoing monitoring | Call Quality Dashboard | Historical call quality trends |
| Active diagnostics | Speed and diagnostic tests | Jitter, packet loss, latency, bufferbloat |
| Escalation | Packet capture at egress | Whether DSCP markings survived the path |
Wi-Fi and edge fixes that don't require new hardware
Most Teams complaints trace back to the edge of the network, not the WAN circuit. Wire every conference room codec and event encoder directly to a switch, since Wi-Fi introduces variable latency that Teams cannot compensate for. Where wireless is unavoidable, put conferencing devices on 5 GHz rather than 2.4 GHz, and plan channel assignments so neighboring access points don't overlap and cause retransmissions.
- Keep encoders and room systems on wired Ethernet, never Wi-Fi, for anything client-facing.
- Segment conferencing devices onto their own SSID to isolate them from general guest or IoT traffic.
- Update access point firmware and client network drivers regularly, since older drivers mishandle roaming and QoS tags.
- Avoid routing Teams media through a VPN when a split-tunnel option exists, since VPN encapsulation often strips DSCP values.
- Confirm firewall rules allow the required Teams ports and don't reset markings for browser-based sessions.
Pro Tip: If a conference room has intermittent video drops but clean audio, check the access point's channel width and interference first, since that pattern usually points to Wi-Fi contention rather than a WAN shortage.
Why measurement beats buying more bandwidth
The instinct to solve call quality problems by upgrading the circuit is usually the wrong first move. QoS configuration is cheaper than a bandwidth upgrade and fixes more problems, since most degraded calls trace back to congestion and marking, not raw capacity. Make site modeling and active diagnostics a routine part of network planning, not a one-time exercise before a big rollout.
— Peter D
Verify your network before you deploy Teams at scale
Sizing a Teams rollout on guesswork leads to the wrong fix later, and running the numbers first saves the rework. Some diagnostic tools measure metrics like upload and download throughput, jitter, packet loss, bufferbloat, and DNS resolution time, which can be mapped to the thresholds Teams uses.
- Run the Speed Test to check baseline throughput and latency at a site before committing to a circuit size.
- Use the Video Streaming Quality Test to see the maximum resolution your connection can sustain for events and encoder feeds.
- Try the Video bitrate planner when sizing encoder bitrates and safety buffers for Town Halls.
Run these checks before a major Teams rollout or event, and again whenever a site reports recurring call quality issues.
Sources
- Prepare your organization's network for Microsoft Teams
- Monitor call and meeting quality in Microsoft Teams
FAQ
Is 25 Mbps fast enough for a Teams meeting?
Yes, for a single user joining a standard video call, Teams typically needs around 1,500 kbps up and down per endpoint, according to Microsoft's network guidance. The real constraint is usually latency and jitter, not raw throughput, so a fast connection with high packet loss can still produce poor call quality.
Does Teams require more bandwidth than Zoom?
Bandwidth needs across major video conferencing platforms are broadly similar for equivalent video quality, since all of them scale bitrate with resolution and frame rate. Rather than comparing platforms, size your network against Microsoft's own published tiers for Teams, since that is the figure your deployment actually depends on.
How can I reduce bandwidth usage in Microsoft Teams?
Enabling QoS so video and screen sharing don't compete with other traffic is the most effective step, alongside encouraging audio-only participation when video isn't necessary. Limiting background bandwidth consumers, such as scheduling Windows Update traffic outside call hours as described in this guide on limiting Windows Update bandwidth, also protects capacity for Teams.
What firewall rules are needed for Microsoft Teams?
Firewalls need to allow the Teams media ports and preserve the DSCP markings Teams applies, since Microsoft's QoS documentation specifies distinct source port ranges for audio, video, and screen sharing. Test with both desktop and browser-based clients, since browser sessions can use dynamic ports that behave differently under the same firewall rules.