Microsoft Teams Calling at Scale: Network Requirements Most Businesses Miss

Most Australian organisations find it easy to activate Microsoft Teams calls. After you give employees their licenses and complete Teams Phone installation and number porting procedures, they will start using their laptops and mobile devices for calls within two days.

The system operates at full capacity with 10 to 20 users.

The system becomes non-functional when more than 100 users try to work simultaneously.

• The sound produces robotic speech patterns.
• The calls disconnect unexpectedly.
• The video freezes during client meetings.
• The executives begin to doubt their abilities.
• IT teams are currently working to solve the "Teams Calling Voice Quality Fixes" problem.

The main problem is that it is easy to turn on the Teams calling system. The system requires engineering work to be able to handle larger quantities of users.

Many organisations face failure because their system for managing Teams traffic treats it as standard web traffic. Teams Voice, on the other hand, is a real-time, time-sensitive media stream that uses UDP and requires rigors prioritisation, low latency, and little jitter. It is not web traffic. Users experience performance issues when network traffic increases and organisations lack a proper design for their networks.

The guide examines technological "blind spots" which lead to deployment failures of Teams Calling in Australian offices. These blind spots include UDP port depletion and DSCP tagging problems.

The Quality of Service (QoS) Gap: Why DSCP Tagging Fails

When IT leaders review Microsoft Teams calling network requirements, QoS always appears near the top of the list.
Most teams configure it.
Few extend it properly.

Trust Boundaries and Router Prioritisation

Most businesses configure QoS on their internal switches but fail to extend that “trust boundary” to their edge routers. Inside your LAN, you might correctly tag the following:

• EF (Expedited Forwarding) for voice
• AF41 for video

That’s a strong start — but this is where many deployments break down.

If your edge router or SDWAN appliance does not explicitly trust or prioritise those DSCP tags, it will ignore or reset them. When congestion hits, your Teams voice packets are treated the same as the following:

• Windows updates
• OneDrive sync
• SharePoint uploads
• Cloud backups

During peak periods, the router queues traffic indiscriminately. Because voice is time-sensitive UDP traffic, it suffers first — resulting in jitter, clipping audio, and multi-second delays.

The lesson is simple: QoS for Microsoft Teams must run end-to-end—from the endpoint to the internet edge.

Audit tip: Run show QoS interface on your router and verify EF traffic is explicitly trusted and prioritised.

Managing Port Ranges for Real-Time Media

Microsoft specifies a defined range of UDP ports (3478–3481) for real-time Teams media traffic. As businesses scale, they often miss the requirement to explicitly allow these ports for outbound traffic. When that happens, Microsoft Teams falls back to TCP relays.

TCP guarantees delivery — but it introduces retransmissions and delay. In real-time voice, that delay translates directly into:

• Increased latency
• Jitter
• “Choppy” or robotic audio

Another common scaling issue is hairpinning. Instead of allowing local branch offices to send media traffic directly to Microsoft over UDP, some organisations backhaul it through their office firewalls for inspection before sending it out on the internet. That unnecessary detour adds significant latency and degrades call quality.

The fix is straightforward:

• Explicitly allow outbound UDP 3478–3481 to Microsoft media endpoints.
• Avoid forcing Teams media over TCP.
• Implement local internet breakout where possible.
• Monitor UDP utilisation to detect port exhaustion early; PRTG sensors can help flag issues before users notice.

To successfully scale Teams Phone, make sure that direct outgoing UDP access is checked and that any extraneous routeing paths are removed.

Firewall "Deep Packet Inspection" (DPI) and Latency Spikes

The Problem of Excessive Inspection

Deep Packet Inspection (DPI) is used by organisations that put security first to keep an eye on all of their outgoing network traffic. The firewall employs DPI to find threats; however, this technology has to look at the contents of each packet in real time, which slows down the processing of each packet.

The web browsing experience shows only minimal delays to users.
Your voice needs this element for proper functioning.
Microsoft Teams Voice requires specific performance limits for its operation.
Latency should remain below 150 milliseconds for optimal performance.
The maximum allowable jitter for the system operate at 30 milliseconds.
The system experiences less than 1 per cent packet loss.

In high-concurrency setups (100+ active calls), firewall CPU use can skyrocket as it inspects thousands of UDP media packets each second. This processing overhead creates jitter, which consumers perceive as clipping, robotic audio, or abrupt audio dropouts.

The takeaway is straightforward: Apply DPI intelligently. Exclude trusted Microsoft 365 media traffic to protect real-time performance.

The Solution

To effectively scale Teams Calling, IT must create "bypass" rules for Microsoft 365 trusted IP ranges. Exempting Teams media traffic from intensive firewall inspection cycles (SSL inspection and DPI) reduces CPU burden on the security appliance while providing a clean, low-latency channel for speech data.

If you want clear, consistent audio at scale:

• Identify and routinely update the Microsoft 365 Trusted IP ranges.
• Exempt Teams' Media Traffic from SSL Inspection and DPI
• Clearly prefer UDP 3478-3481 over regular web traffic.
• Monitor the firewall CPU during high call concurrency.

In practical deployments, this often involves downloading Microsoft’s official IP list and creating firewall security policies (for example, no DPI applied to UDP media ports on platforms like Palo Alto). Organisations that adopt effective bypass rules frequently see jitter drop drastically — for example, from 40 ms to 15 ms — just by removing superfluous inspection overhead.

This technique decreases latency and jitter and protects voice quality while maintaining overall security posture. When growing Teams Phone for Business, these setups should be common practice for Australian providers of managed IT for Microsoft Teams.

Symmetrical Bandwidth and the Upload Bottleneck

The Asymmetrical Trap

Many Australian SMEs still rely on asymmetrical NBN links such as 100/40 Mbps or even 100/20 Mbps. While 100 Mbps download feels generous for general consumption, the limited upload capacity quickly becomes a bottleneck when Teams calls and video usage scale.
The issue is simple: Microsoft Teams is cloud-based. Every voice packet, HD video stream, and screen share must be uploaded in real time.

Typical bandwidth usage per user:

• Voice call: ~100 Kbps
• HD video: up to 4 Mbps
• Screen sharing: 1–2 Mbps

If 30 staff members are on video calls simultaneously at a modest 2 Mbps average:

• 30 × 2 Mbps = 60 Mbps upload required
• On a 100/40 service, you only have 40 Mbps available.

Congestion begins. Packets are queued. Audio degrades.

Users experience:

• One-way audio
• Robotic or delayed speech
• Dropped calls

If you’re planning to scale beyond 50 users—especially with regular video usage—symmetrical bandwidth should be part of your network roadmap.

Calculating the Real-World Overhead

Microsoft Teams requires approximately the following:

• ~100 Kbps per voice call.
• Up to 4 Mbps per HD video stream

On paper, those numbers seem manageable. At scale, however, the real problem isn’t just call traffic—it's the background noise on your network.

Even when staff appear as "idle," your uplink is often busy with:

• OneDrive synchronisation
• SharePoint uploads
• CRM and cloud backups
• Endpoint security updates
• Operating system patches

This background traffic quietly consumes upload capacity and erodes headroom. When concurrency increases, voice traffic competes with bulk data transfers — and voice loses.

Capacity planning rule of thumb:

• Model peak concurrent usage, not daily averages.
• Allow at least 30% uplink headroom (many engineers plan for 30–40%).
• Prioritise real-time traffic above bulk transfers.

A simple sizing approach:

Users × 2.5 Mbps average video load + 30–40% overhead

For example:

• 100 users × 2.5 Mbps = 250 Mbps
• 40% overhead = ~350 Mbps upload required

Without adequate headroom, scaling Teams calling becomes unpredictable. Proper modelling, traffic prioritisation, and sufficient symmetrical bandwidth are essential to prevent background traffic from undermining real-time communication.

Enabling Teams Calling is quick — scaling it to 100+ concurrent users without degradation requires careful planning, testing, and disciplined network engineering. Many deployments fail because they treat Teams traffic like ordinary web browsing rather than a real-time media platform with strict latency requirements.

The most prevalent blind spots are the following:

• Not fully implementing end-to-end QoS
• Did not pay attention to DSCP trust boundaries
• UDP port ranges that were not handled correctly
• Too much DPI inspection
• Unbalanced bandwidth limits
• Firewall infrastructure that is too small

To make sure that all of your Australian offices get consistent, carrier-grade performance, follow these important rules:

• Give UDP traffic more importance than TCP traffic.
• Bypass DPI for Microsoft 365 IP ranges that are safe
• Make sure your upload capacity suits your growth goals.

Do a thorough review before you increase your deployment. An Anticlockwise Teams Calling audit expert can find hidden problems, keep executives from getting frustrated, and make sure that scaling goes smoothly. It's not just technical anymore when the CEO's call stops in the middle of a sentence. It's strategic.