In a modern enterprise network, the problem is often not capacity or classic packet loss, but how real-time Teams media behaves through NATs (Network Address Translation), VPN solutions, proxies, SSE/SASE services, and TCP fallback mechanisms. How do you fix choppy Teams audio? This post explores Why Teams Lags While Your Network Looks Fine — and how to find the true root cause of the problem.
Feedback from Users
One of the most common situations encountered in modern enterprise networks is users experiencing poor Microsoft Teams performance while the network service provider sees everything as being in order. Users report stuttering audio, frozen video, delayed screen sharing, and unstable remote meetings. Meanwhile, the network team looks at the metrics: latency looks good, packet loss is low, WiFi is working, and WAN links are not congested. This easily leads to a false conclusion: there is no problem in the network.
We blame unstable Internet connections, buy more capacity, talk about prioritization (QoS), or switch operators. In reality, the problem is often very real, but it is being viewed from the wrong perspective.
Modern cloud-based real-time applications, like Microsoft Teams, do not behave the same way as traditional enterprise applications. A network can appear technically healthy and yet the user experience can be poor.
Teams Media is Not Normal HTTPS Traffic
Teams chat, signaling, and login function as HTTPS traffic over TCP 443. These almost always work. However, the user experience isn’t formed by chat or login, but by real-time media: audio, video, and screen sharing. It is precisely this media that works completely differently than traditional HTTPS traffic.
Teams always primarily aims to use UDP. This is no coincidence. UDP enables low latency and a steady media stream without the delays caused by TCP retransmissions. When Teams is allowed to use direct UDP media to Microsoft’s edge nodes, the user experience is usually excellent. In enterprise networks, this is no longer a given.
Enterprise Networks Easily Break Real-Time Media
A modern corporate network often includes several NAT layers, firewalls, proxy solutions, SSE/SASE services, VPN clients, and SD-WAN logic. Each of these can affect how the Teams ICE/STUN/TURN negotiation succeeds. A key observation is that Teams usually doesn’t stop working entirely. Instead, it switches to fallback mechanisms.
First, the optimal “Direct UDP” changes to Relay-UDP via Microsoft’s TURN node. This often still works quite well. The problems begin when UDP no longer works reliably and traffic falls back to TCP 443. This is the moment when users start complaining about “robotic” voices, frozen video, and slow screen sharing. And meanwhile, the network still looks perfectly healthy.
The Network Looks Healthy — The User Experience Does Not
This is perhaps the greatest illusion in modern network diagnostics. Traditional network monitoring might not see the problem at all, because the issue isn’t the amount of bandwidth or classic packet loss. The problem arises from the behavior of real-time media around NATs, session timeouts, and fallback logic. The quality of real-time media depends on what kind of media path the application is able to establish.
-
The best possible state is UDP Direct, where media travels via the most direct UDP path possible through the nearest Microsoft edge service. This minimizes latency and jitter. The connection also stays better within the same region.
-
The next level is UDP Relay (TURN), where media is relayed through a relay server due to NAT or firewall restrictions. This adds a bit of latency and jitter.
-
If a UDP connection cannot be established, Teams moves to TCP fallback mode. In this case, retransmissions, packet processing, and TCP’s reliability mechanisms easily add latency, especially in unstable networks.
-
The final fallback is HTTPS/TLS over TCP port 443. At this point, the media essentially operates on the terms of web traffic, and the network no longer offers an optimized path for real-time media.
Proxies, SSE, and VPNs Worsen the Problem
In many environments, the problem is further exacerbated by secure web gateway and SSE solutions such as Zscaler, Umbrella, and Netskope. Their purpose is, of course, to increase visibility and security for cloud traffic, but Teams media does not behave well through proxies or SSL inspection. When media is forced into HTTPS tunneling or for inspection, UDP often disappears entirely, and Teams switches to TCP fallback.
Similarly, enterprise firewalls (NGFW) and VPN solutions often significantly worsen the situation. They were designed for an era where “stateful inspection” was the primary concept. Default configurations are often not optimized, meaning fallback occurs almost every time. Additionally, it should be noted that if a remote user’s traffic is routed entirely through an NGFW or VPN gateway, an unnecessary detour, extra NAT layers, and additional latency are created, resulting in a fallback.
From the user’s perspective, the result is simple: Teams works poorly, and from the network’s perspective, everything still looks green.
SD-WAN Doesn’t Automatically Solve Teams
The same phenomenon is seen in SD-WAN environments. Many assume that modern SD-WAN automatically solves Teams performance challenges. In practice, this is not necessarily the case. Real-time media values stable and predictable session behavior more than aggressive path optimization. If SD-WAN changes the WAN path or the NAT mapping changes mid-session, Teams may have to renegotiate the media or fallback to a relay. And that’s when something very interesting starts to happen.
This problem usually doesn’t show up in documentation or network diagrams. The network appears to be built perfectly correctly, but the actual data path is something else entirely.
Teams Needs a Simpler Network
This is exactly why investigating Teams problems nowadays requires much more than traditional network monitoring. One must understand:
-
How is the media actually traveling?
-
At what point does UDP disappear?
-
Where does the relay begin?
-
When does TCP fallback activate?
-
What is NAT actually doing?
-
How does a proxy or VPN affect the media?
And often the most important observation is ultimately very simple: Teams does not need a more complex network. It needs a simpler network. The most direct, stable, and least manipulated UDP path to the cloud almost always produces the best user experience.
Could IPv6 Solve the Problem?
One interesting question in this context is: would IPv6 ultimately solve the entire Teams/WebRTC challenge? Partially, yes. The entire modern WebRTC world is practically built around IPv4 and NAT environments. STUN, TURN, ICE, and UDP hole punching are all mechanisms designed to help real-time media survive in a NAT world.
In an IPv6 environment, NAT dependency decreases significantly because the client can have a direct public IPv6 address. In practice, this means “Direct UDP” succeeds more easily, UDP relay is needed less, and real-time traffic behaves more stably.
But in enterprise networks, the problem today is no longer just NAT. The real challenge often arises from traffic being tunneled through a VPN, routed to proxies or secure web gateways, inspected inside SSL, recycled through a centralized Internet breakout, or subjected to SD-WAN path steering. And it is precisely these things that break the Teams user experience much more often than NAT itself.
Perhaps the most important architectural shift is this: modern real-time traffic usually works best when the network does less. That is why Microsoft’s recommendations also emphasize local internet breakout, direct UDP traffic, and as little “middlebox” processing as possible.
IPv6 helps significantly because it removes one major layer of complexity. But if the rest of the network still heavily manipulates the traffic, a good user experience will not happen automatically.
5G and 6G Won’t Automatically Solve the Problem
Mobile networks bring another interesting perspective to the discussion. Although 5G connections offer very high capacity and lower radio network latency, the user experience is not determined solely by radio performance.
In practice, nearly all mobile operators still use Carrier Grade NAT (CGNAT) solutions, where a large number of users share the same public IPv4 addresses. This complicates the optimal functioning of real-time UDP-based traffic, such as Teams and WebRTC media. In such cases, traffic more easily ends up traveling through relay servers or even into TCP/TLS fallback mode, even if there is plenty of capacity available.
In mobile networks, the increasing prevalence of native public IPv6 addresses changes the situation significantly. When the endpoint receives a genuine end-to-end IPv6 connection without CGNAT, real-time media NAT traversal problems are essentially reduced, and establishing UDP Direct media becomes easier. This significantly reduces latency, jitter, and relay dependency.
So, here too, it is not primarily about capacity, but about how simple, direct, and predictable the network path itself is for real-time traffic.
Finally
The most interesting part of this phenomenon is perhaps that even modern AI-driven network management or automation finds it difficult to see the problem correctly. The network still looks “healthy” because classic metrics — capacity, interface drops, latency, and packet loss — can stay completely normal while the user experience degrades significantly.
That is why a traditional network analyzer is still one of the most important tools for studying modern real-time traffic. A modern network is no longer just about routing and capacity. Increasingly, it’s about how well the network knows how to avoid interfering with real-time media.
5Feet Networks Oy