Teams Phone Network Requirements for Multi-Site BusinessesTeams Phone runs well on a network that gives real-time voice a clean, short, prioritized path to Microsoft's cloud. In practice that means about 100 kbps per phone, the right firewall openings, consistent QoS marking, a wired connection where you can get one, and a local internet exit at each site. Direct Routing adds a certified session border controller (SBC) and, optionally, media bypass. This guide covers each requirement, the exact numbers Microsoft publishes, and how to apply them across many locations.

TL;DR

• Plan roughly 100 kbps up and down per Teams Phone, then size each site with Microsoft's Network Planner rather than a flat rule.
• Open UDP 3478–3481 plus TCP 80/443 and UDP 443 to the published Teams ranges, and automate updates because Microsoft changes the list regularly.
• Mark audio as DSCP 46 (EF) and keep that marking intact end to end, including across your SD-WAN and carrier handoffs.
• Media bypass for Direct Routing only works when the client can reach the SBC's public IP, even from inside the LAN.
• Prefer wired phones. If you use Wi-Fi, design for strong 5 GHz coverage and low channel utilization.

Table of Contents

• Licensing is separate from network readiness
• Bandwidth: per call, per phone and per site
• Firewall ports, protocols and IP ranges
• Direct Routing prerequisites
• Media bypass: when it helps and what it needs
• QoS: making voice win during congestion
• Latency, jitter and loss targets
• Wired or Wi-Fi
• VPNs and internet egress
• A multi-location readiness checklist
• Our perspective
• Get the network under Teams Phone ready
• FAQ
• Sources

Licensing is separate from network readiness

Before touching the network, separate two questions. Microsoft states that each user needs a Teams Phone license and must be voice-enabled, and that calling the public telephone network also requires a Calling Plan, Operator Connect, Teams Phone Mobile or Direct Routing. That is a licensing and carrier decision.

Network readiness is a different workstream. A user can be fully licensed and still get choppy audio because of a congested uplink, a firewall that drops UDP, or a VPN that hairpins media through a headquarters data center. Most multi-location problems we see belong to the second category, so the rest of this guide stays there.

Bandwidth: per call, per phone and per site

Microsoft's guidance for Teams Phone is 100 kbps up and down per phone to ensure calls perform well. Separately, Microsoft Support describes an audio send and receive limit of 70 kbps as a typical monitoring figure. The gap between the two is headroom for packet overhead and signaling, so use the higher number for planning.

A simple worked example shows why per-site sizing matters:

The voice share looks small, and it is. The risk is almost never that voice alone fills the pipe. It is that a backup job, software update or video meeting fills it while voice waits in the same queue. That is why bandwidth and QoS must be planned together.

For modeling, Microsoft offers the Network Planner. You enter sites, users, WAN capacity, internet egress, PSTN egress and personas, and it calculates the bandwidth each site needs for each activity. Microsoft's advice for multi-site deployments is to represent each building as a site, record its WAN and internet capacity and whether egress is local or remote, and model local connections before remotely connected sites.

If you want a broader method for sizing circuits across many locations, our guides on network bandwidth planning for multi-location businesses and bandwidth management for IT teams go deeper.

Firewall ports, protocols and IP ranges

Teams Phone media travels over UDP. Microsoft's current endpoint list shows Teams media optimization on UDP 3478–3481 to 52.112.0.0/14, 52.122.0.0/15 and IPv6 2603:1063::/38. Teams allow-required endpoints also include TCP 80 and 443 and UDP 443 for the published Teams domains and ranges.

The Direct Routing and SIP Gateway rows come from Microsoft's Direct Routing planning page and its SIP Gateway configuration guide. Two details are easy to miss. Microsoft recommends at least two media ports per concurrent call on the SBC, so size your port range to your peak call count. And SIP Gateway devices should bypass corporate HTTP/S proxies.

Keep the list current

Microsoft updates endpoint data as needed, usually monthly, and recommends that scripts and network devices pull it from its web service. A static rule set copied from a forum thread will age. If you manage dozens of firewalls, pull the endpoint feed into your change process so that every site gets the same update at the same time.

Two more practical points for stateful firewalls. Allow enough NAT pool capacity for your user count, and preserve UDP sessions, because Microsoft's network preparation guidance calls out both. Filtering by IP block and port, not URL, is normal for a stateful firewall, so rely on the published IP ranges for media.

Direct Routing prerequisites

If you connect Teams to your own carrier through Direct Routing, the network checklist grows. Microsoft requires a certified SBC, a PSTN trunk, online-homed users, verified domains, a publicly reachable SBC IP address, public DNS, a trusted certificate, the Microsoft SIP connection points, and a firewall that supports both signaling and media, per its Direct Routing plan.

In a multi-site business, the design question is where SBCs live. One central SBC is simple to manage, but remote sites then send their media across your WAN first. Regional or site-level SBCs shorten the path. We cover the planning trade-offs in MS Teams Direct Routing: enterprise planning and setup, and the SBC's role in SBC network design for engineers. If your trunks need a tested failover plan, see our SIP trunk failover runbook.

Media bypass: when it helps and what it needs

Media bypass sends audio directly between the Teams client and the Direct Routing SBC instead of through Microsoft's media processors. Signaling still goes through Microsoft's cloud. The shorter path means less latency and fewer hops, which is the reason to use it.

Microsoft's media bypass planning page sets the conditions:

• The client and the SBC should be in the same location or network.
• The client must be able to reach the SBC's public IP address, even from inside the corporate network.
• Your firewall and NAT must permit the documented SRTP ports. In the direct flow, clients use UDP/SRTP from source ports 50000–50019 to destination ports that the SBC defines.
• If the client cannot reach the SBC directly, Teams falls back to Transport Relays.

The second point trips up many internal rollouts. Internal users often cannot loop back to a public address because of how the firewall handles hairpin NAT. Test from a phone on the actual site VLAN, not from your desk. Each site that fails the test either needs a firewall change or is better left on the default path.

QoS: making voice win during congestion

Three symptoms map to three network measures. According to Microsoft, jitter can cause missing words or syllables, packet loss can make speech hard to understand, and delayed round-trip time causes conversational delays. QoS prioritizes real-time traffic, and it must be applied consistently along the whole path. A marking that is stripped at one router protects nothing after that point.

Microsoft's initial design uses DSCP with port-based ACLs:

Those values come from Microsoft's QoS implementation guide. For the configuration steps on switches, routers and firewalls, see our guides to VoIP QoS settings and the role of QoS in business voice. If you run SD-WAN, three tuning levers for voice quality show where markings usually get lost.

QoS also has a limit that engineers should know about: it only controls what you own. Marking is honored on your LAN and on a managed WAN, but a plain internet path may ignore it. This is why a managed underlay, or an SD-WAN that steers voice onto the best available path, matters for multi-site voice.

Latency, jitter and loss targets

Use two sets of numbers, and use them for different jobs.

Monitoring targets. Microsoft Support lists typical end-user targets of under 200 ms round-trip time, under 2% received packet loss and under 30 ms received jitter. Treat these as your alerting thresholds.

Poor-stream classification. In Call Quality Dashboard, the basic audio classifier marks a stream poor when packet utilization exceeds 500 and any average threshold is crossed: jitter above 30 ms, packet loss above 10%, or round-trip time above 500 ms. Microsoft also notes that these are diagnostic guidelines, not proof a user heard poor quality, since the media stack can compensate for some degradation.

The practical reading: alert on the tighter monitoring targets so you catch drift early, and use CQD classification to find which sites and subnets repeat the problem. For translating raw measurements into a single quality score, our MOS score explainer covers how to measure and alert.

Wired or Wi-Fi

Teams Phone does not require Wi-Fi, and desk phones can sit on a wired port with PoE. Microsoft strongly recommends wired connections for Teams Rooms devices, and the same logic applies to any fixed endpoint: one fewer variable.

Where wireless is unavoidable, such as warehouse floors, mobile handsets or retail back rooms, Microsoft's guidance is:

• Strong signal, with the device and at least one access point seeing each other at -60 dBm or better.
• Prioritize the 5 GHz band and use band steering.
• Apply QoS on the wireless side too.
• Keep interference low and channel utilization below 50%.

A predictive map rarely captures a real building, so a site survey before deployment pays for itself. We offer a WiFi site survey and managed WiFi for exactly this.

VPNs and internet egress

If remote workers or branches reach Teams through a full-tunnel VPN, voice takes a detour. Microsoft recommends split-tunnel VPN for Teams traffic because VPNs can add encryption overhead, hairpinning, latency and jitter, and can cause UDP compatibility problems.

The same principle applies to branch design. Microsoft recommends efficient routing to the nearest data centers, so a branch that backhauls all internet traffic to a central site adds distance to every call. Local internet breakout at each location, with security applied there, is the cleaner pattern.

A multi-location readiness checklist

1. Inventory sites. List each building, its users, circuit type and capacity, and where it reaches the internet.
2. Model in Network Planner. Start with sites that have local egress, then add remote ones.
3. Confirm the PSTN path. Calling Plan, Operator Connect, Teams Phone Mobile or Direct Routing, per site.
4. Update firewalls. Apply the current Microsoft endpoint list and automate refreshes.
5. Standardize QoS. One DSCP policy, verified at every hop, including the WAN edge.
6. Decide on media bypass. Enable it only at sites that pass the SBC reachability test.
7. Go wired first. Survey and tune Wi-Fi where wireless voice is needed.
8. Pilot, then monitor. Move one site, watch Teams admin center and CQD, then roll out.

Microsoft itself recommends monitoring with CQD and the Teams admin center, so build those dashboards before go-live, not after the first complaint.

Our perspective

Most Teams Phone trouble we are asked about is not a Teams problem. It is a path problem: a branch with a single circuit, QoS marking that disappears at the carrier edge, or a firewall rule set nobody has refreshed in a year.

Our view is that voice should be engineered, not hoped for. For multi-location businesses, that means a carrier-neutral design, sourcing circuits from 50+ carriers so each site gets the right fit, and multi-carrier SD-WAN so voice can move to a healthy path. It also means one team that owns the whole chain from the circuit to the firewall to the phone.

We back that with a 24/7 U.S.-based NOC and direct access to certified engineers, so a quality complaint goes to someone who can look at the path immediately. Our Netverge platform is designed to give real-time visibility across sites, so a jitter spike at one location is visible before users call it in.

If you are lean on IT and running many sites, treat the network as a managed service with a single point of accountability. It is the fastest way we know to make Teams Phone feel boring, which is the goal.

Jim

Get the network under Teams Phone ready

If you run multiple California locations and want one team to handle the circuits, SD-WAN, firewalls, Wi-Fi and voice, start with our Microsoft Teams Calling service. We design and deploy each site with our own engineers, with one provider and one bill.For the underlay, look at Managed SD-WAN and Dedicated Fiber Internet. To see how we watch voice quality across sites, see Netverge network observability.

FAQ

How much bandwidth does Teams Phone need?

Microsoft recommends 100 kbps up and down per Teams Phone. Multiply by the number of simultaneous calls at a site, then add headroom for everything else on the circuit. Microsoft's Network Planner calculates this per site for you.

Which ports does Teams Phone use?

Teams media optimization uses UDP 3478–3481 to Microsoft's published ranges, and Teams endpoints also use TCP 80 and 443 and UDP 443. Direct Routing adds TCP 5061 for signaling and UDP 49152–53247 for media. Check Microsoft's endpoint list regularly, since it changes.

Do I need media bypass?

No. It is an optional Direct Routing feature that shortens the media path. It requires that clients can reach the SBC's public IP, even internally, and that the firewall allows the SRTP ports. Without that, Teams uses Transport Relays.

Does Teams Phone need Wi-Fi?

No. Wired desk phones work well, and Microsoft recommends wired connections for fixed devices. If you use Wi-Fi, aim for a strong 5 GHz signal, QoS and channel utilization under 50%.

Are VoIP and UCaaS requirements the same as Teams Phone?

The fundamentals match: low jitter, low loss, consistent QoS and adequate bandwidth. Teams adds Microsoft-specific ports, IP ranges and, with Direct Routing, SBC requirements, so follow Microsoft's documentation for those.

Sources

• Prepare your network for Teams phones
• Use the Network Planner for Microsoft Teams
• Microsoft 365 URLs and IP address ranges
• Plan Direct Routing
• Configure SIP Gateway
• Plan for media bypass with Direct Routing
• Prepare your organization's network for Teams
• Implement Quality of Service in Microsoft Teams
• Stream classification in Call Quality Dashboard
• Monitor call and meeting quality in Microsoft Teams
• Set up Teams Phone in your organization

Recommended

• Single Provider Multi-Location Connectivity: A Business Guide
• How to Choose a Managed Network Provider for Multi-Site
• Multi-Site Network Deployment Examples for IT Leaders
• Multi-Site Network Management Explained for IT Leaders