Hello everyone,
I’m reaching out to see if others in the community are experiencing a specific, persistent issue we’ve been diagnosing in our environment. For the past several weeks, we’ve observed intermittent but disruptive drops in Microsoft Teams voice and video calls specifically when traffic is routed through our SASE proxy. Other 365 applications—SharePoint, Exchange Online, even file transfers within Teams—remain stable. The problem manifests as sudden audio cutouts, frozen video, or complete call disconnections, typically lasting 5-15 seconds before reconnecting.
Our architecture follows a fairly standard SASE pattern: all branch office internet traffic, including direct-to-internet Microsoft 365 optimized routes, is backhauled to a cloud security stack (we’re using a combination of Zscaler and Netskope for different segments) for inspection before egressing to Microsoft’s front doors. We’ve implemented Microsoft’s recommended endpoints and optimized categories, treating Teams media as a non-inspected, allowed flow.
Despite these optimizations, the issue persists. Our working theory is that even with bypass rules, the inherent proxy architecture and the UDP-based, real-time nature of Teams media (especially for video) are at odds. The media streams seem sensitive to the additional latency and potential packet reordering introduced by the SASE cloud hops, even when inspection is off.
I’d be very interested to hear if you’ve faced similar challenges and, more importantly, what your resolution path looked like. Specifically:
* **Deployment Model:** Are you using an explicit forward proxy (PAC file) or a tunnel-based (GRE/IPsec) integration to your SASE cloud? We’re on explicit proxy, and I’m wondering if a tunnel model provides more stability for real-time media.
* **Traffic Segmentation:** Have you found success with a more aggressive bypass, perhaps steering all Teams traffic (not just media endpoints) directly to the internet at the branch level, completely outside the SASE path? This feels like a step back from the SASE principle, but reliability is critical.
* **Vendor Config Nuances:** Are there specific settings within your SASE provider’s portal (e.g., UDP timeout values, MTU adjustments, or specific “real-time media” profiles) that proved pivotal?
* **Monitoring & Metrics:** What key metrics did you monitor to pinpoint the issue? We’re looking at packet loss, jitter, and latency to the SASE egress nodes versus directly to Microsoft, but correlating it to the exact moment of a call drop is tricky.
We’re currently weighing whether to implement a local breakout for all Teams traffic, which complicates our security posture, versus pushing our SASE vendor for more granular controls. Any real-world lessons or data points from your migrations would be invaluable.
— Harry
Architect first, buy later