Microsoft Teams Web poor call health when using IPv6, works fine using IPv4

Gabriel 20 Reputation points
2026-07-21T12:47:46.2933333+00:00

Platform: Arch Linux
Product: Microsoft Teams Web (teams.microsoft.com)
Connection medium: Ethernet
Country: Brazil
ISP: [Moderator note: personal info removed]

Working remotely, I am experiencing constant audio/video freezes and call drops during Microsoft Teams meetings (teams.microsoft.com via WebRTC). The issue occurs daily, even while using a wired Ethernet connection, which severely impacts my professional activities. Connection health is fine for all other websites and services, no degradation.

After technical troubleshooting, I identified that the root cause is an IPv6 peering and routing failure between my ISP's network (- AS26599) and Microsoft's network (AS8075).

While IPv4 traffic successfully reaches Microsoft's edge servers with stable latency (~15ms), IPv6 traffic suffers severe degradation upon entering Microsoft's backbone. MTR diagnostic tests confirm a 31% packet loss at the final destination ([Moderator note: personal info removed]) when using IPv6. The report shows a progressive packet loss starting right at Microsoft's border (Hop 7) and propagating through to the Teams servers. The observed standard deviation reaches 16.1ms, introducing a high jitter level incompatible with the WebRTC protocol, directly degrading the audio and video experience. By forcing traffic over IPv4 (disabling IPv6 locally), audio stuttering and packet loss cease immediately.

Is this an ISP problem, a Microsoft problem or a configuration issue on my part?

Microsoft Teams | Microsoft Teams for business | Meetings and calls | Audio and video
0 comments
Answer accepted by question author
Jayden-P 26,280 Reputation points Microsoft External Staff Moderator
2026-07-21T13:17:40.58+00:00

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi @Gabriel

First, I'd like to clarify that we're not Microsoft support, this is a user-to-user support forum. Moderators have no backend access and cannot directly intervene in Microsoft products. We provide only technical guidance and best-practice recommendations based on reported issues.

Thank you for the detailed diagnostics and testing. Since the problem occurs only when using IPv6 and is immediately resolved when traffic is forced over IPv4, the issue appears to be related to the network path taken by IPv6 traffic between your ISP and Microsoft's network.

I recommend opening support cases with both parties:

  • Your ISP: Provide the IPv4 and IPv6 MTR/traceroute results and explain that Teams media quality issues disappear when IPv6 is disabled, which may indicate an IPv6 routing or peering problem.
  • Microsoft Support: Since Teams media traffic is affected, a Microsoft support engineer can review Teams service telemetry and network diagnostics to determine whether any issues are being observed on the Microsoft side. Open a support ticket via Admin Center.

For Microsoft 365 and Teams, Microsoft now commonly uses the teams.cloud.microsoft domain rather than only teams.microsoft.com, so you may also want to repeat your testing against the current Teams endpoints and include those results in your support requests.

As a temporary workaround, continuing to use IPv4-only connectivity may help maintain meeting stability until the underlying IPv6 routing issue is investigated by the network providers involved.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Newest
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.