Almanac
Microsoft/teamsMicrosoft 365

Consultant-focused KB for Microsoft Teams: implementation notes, gotchas and configuration decisions beyond the official docs — across chat and collaboration, meetings, webinars and town halls, Teams Phone, PSTN connectivity (Direct Routing, Operator Connect, Calling Plans, Teams Phone Mobile), auto attendants, call queues and contact centre integration, Teams Rooms and devices, apps and extensibility, Copilot in Teams, administration and governance, security and compliance, network and call quality, and licensing — plus cross-cutting decision guides.

teams/11-network-and-call-quality/feature-network-bandwidth-planning-network-planner.md
feature-network-bandwidth-planning-network-planner.mdv1 · history
CurrentApplies to AllUpdated 3 weeks agoSource Microsoft Learn ↗

What it does

The per-modality bandwidth figures Microsoft publishes for Teams, plus Network Planner in the Teams admin center, which turns those figures into a per-site estimate using personas and headcounts. Between them they answer the question every network team asks first: "how much is Teams going to cost my WAN and internet links?"

Key facts

  • Audio (1:1 and meetings): 10/10 kbps minimum, 58/58 recommended, 76/76 for best performance (up/down).
  • Video 1:1: 150/150 kbps minimum, 1,500/1,500 recommended, 4,000/4,000 best. Video in meetings: 150/200 minimum, 2,500/4,000 recommended, 4,000/4,000 best.
  • Screen sharing 1:1: 200/200 minimum, 1,500/1,500 recommended. Screen sharing in meetings: 250/250 minimum, 2,500/2,500 recommended. Both top out at 4,000/4,000 for best performance.
  • Microsoft says HD video is possible under 1.5 Mbps; screen sharing frame rate is adaptive, from 1.875–7.5 fps at the bottom end up to 15–30 fps at best.
  • Town hall / events streaming is quoted per viewer: 2 Mbps for 720p, 3 Mbps for 1080p.
  • Network Planner lives under Planning > Network planner in the Teams admin center and needs Global Administrator, Teams Administrator or Teams Communications Administrator.
  • It ships with three recommended personas (Office workers, Remote workers, Teams Rooms System) and lets you add up to three custom personas. Default user split is 80% office, 20% remote.
  • Each site needs a name, user count, whether it's WAN-connected, WAN capacity, internet egress (local or remote) and PSTN egress (none, local or remote). Without WAN and internet capacity you don't get specific recommendations.
  • The meeting policy's media bit rate (MediaBitRateKb) caps what a user sends in meetings; TeamsNetworkRoamingPolicy (AllowIPVideo, MediaBitRateKb, default 50000 kbps) can override it per network site.
  • Network roaming policies are assigned to network sites, not users. For users who aren't Enterprise Voice enabled you also need AllowNetworkConfigurationSettingsLookup on in the meeting policy — it's off by default.
  • Microsoft's Teams Rooms guidance is 10 Mbps per room resource account (10,000 kbps media bit rate), with typical real usage around 3–4 Mbps.

When to use / skip

Use the published figures and Network Planner for any deployment where offices sit behind constrained links — branch sites on small circuits, sites backhauling internet over MPLS, or anywhere the network team wants a number before they'll sign off. Network Planner's output is a good conversation-starter with a network team because it's Microsoft's own maths, not yours.

Skip the detailed modelling for a cloud-first organisation with local internet breakout everywhere and links measured in hundreds of megabits. Teams adapts its bitrate dynamically, and for most well-connected offices the bottleneck is Wi-Fi and the last few metres, not the circuit. Spending a week on persona tuning there is wasted effort; go straight to the connectivity test and QoS instead.

The bit-rate controls (meeting policy and roaming policy) are a blunt instrument. Use them for genuinely starved sites — a ship, a remote depot on 4G, a branch on a 10 Mbps line — not as a general "save bandwidth" measure.

Configuration decisions

  • Which bandwidth tier to plan for: minimum, recommended or best. Recommended is the sensible default; minimum is a "it will work, badly" floor.
  • Whether to model each office in Network Planner or group them by circuit type. Grouping is faster and usually good enough.
  • Whether to build custom personas (e.g. contact centre agents who are on audio all day, or a video-heavy design team) or accept the defaults.
  • Internet egress model per site: local breakout versus backhaul to a hub. This drives most of the result and is the bigger architectural decision.
  • Whether to define network regions, sites and subnets at all — they're needed for roaming policies and shared with location-based routing and dynamic emergency calling, so coordinate with whoever owns the voice design.
  • Whether any site needs a roaming policy to cap bit rate or disable video, and what value.
  • What allowance to give town halls and events, especially at sites where hundreds of people might stream the same all-hands.

Gotchas

  • The tables are per-stream, per-user. People multiply audio by headcount and forget that a meeting with video on and a screen share is several concurrent streams.
  • Network Planner's numbers are estimates from personas, not measurements. Treat them as an upper bound for planning, then check reality in CQD after go-live.
  • Roaming policy only bites when the client resolves to a known network site. If your subnets and trusted IPs aren't defined properly, the policy silently doesn't apply.
  • Network site changes take up to four hours to reach clients. Don't test a new roaming policy five minutes after creating it.
  • Cloud proxies that rewrite the source IP break the network site lookup entirely — the client ends up in "unknown location".
  • Town hall streaming at a big site can dwarf all the interactive traffic combined. If the client runs regular all-hands, that's the number to plan around, and it's a candidate for an eCDN conversation.
  • Teams Rooms have no bandwidth-limiting policy by default; a room with multiple screens and content cameras will take what it can.

Consultant notes

  • Get the network team to give you circuit sizes and egress design per site before running Network Planner. Without them the report is half empty.
  • Save the Network Planner report and attach it to the design document; it's useful evidence when someone later blames Teams for a saturated link.
  • If you're defining network sites for roaming policies, do it once, properly, and reuse the same topology for dynamic emergency calling and location-based routing — don't let two projects build competing site lists.
  • Revisit the plan after the first month of CQD data. Real usage nearly always differs from the persona assumptions, often downward.
  • For starved sites, try audio-only or a lower bit rate via roaming policy before you recommend a circuit upgrade, but be honest that it trades away user experience.

Recheck the bandwidth tables if Microsoft changes the default video resolution again, and confirm Network Planner hasn't moved in the admin center menu

Was this accurate?
Related
QoS and DSCP marking for Teams media11-network-and-call-qualityBreakout Rooms in Teams Meetings02-meetings-webinars-and-eventsTown Halls and the Teams Live Events Retirement02-meetings-webinars-and-eventsCall analytics and real-time telemetry for per-user troubleshooting11-network-and-call-qualityCall Quality Dashboard (CQD) and building data upload11-network-and-call-qualityTeams media flows, ports, TURN and VPN split tunnelling11-network-and-call-quality