Page History
...
| Insight Message | Details |
|---|---|
| Potential Firewall Port Exhaustion Detected | Conditions:
Possible Actions?
|
| Audio stream was transferred between mobile and desktop versions of Teams | This can point at the user having problems with a device and switching to see if it improves. However, this can of course also happen for other reasons. Possible Actions?
|
| More than 5 BSSIDs were used | The user's device connected to more than 5 different (distinct) Wi-Fi AccessPoints during the call. This can occur when users move during a call but can also point at users who are in an environment where there are access points that service overlapping areas. This can cause unwanted/unnecessary switching between access point and have a detrimental effect on the user's call experience. Possible Actions?
|
| TCP was used for Audio traffic | UDP is always recommended for performance and preferred by Microsoft Teams, TCP is a fail back for unreliable connections or cases where UDP is blocked. Users using TCP during calls can point at configuration and or network policies that are misconfigured misconfigured. Possible Actions?
|
| Non-default Audio Ports Detected | Audio should use the local ports of 50000-50019. Other ports could result in QoS policies failing to identify and prioritize the traffic. Possible Actions?
|
| User Experienced Mid-Call Failure(s) | As reported by teams client and/or call records. This insight is identifed and detected by Microsoft. Possible Actions?
|
| Mid-Call Network Disconnect/Reconnect | Windows OS detects a network change event during the call. This insight is identified and detected by TrueDEM. This Insight is more reliable than Microsoft's report (see previous Insight). Ideally, both Insights should appear simultaneously. Possible Actions?
|
| Audio switched between wired and Wi-Fi In-Call | Teams Audio stream changes between Wi-FI and Wired connections during a call, and this change was not the result of a network change event. Both Wifi and Wired Networks used in the same audio segment Possible Actions?
|
| Multiple Audio Segments were used | More than 1 distinct audio segment AND no signs of previously listed network or teams issues. (disconnect, midcall failure, etc) |
| Audio traffic traversed a managed VPN | Audio traffic was routed via VPN (on a managed network) |
| AV1 codec detected in VBSS stream | AV1 codec detected during ScreenSharing. This is very resource intensive on receiver side because ore computation is required to decode the incoming stream. Any delay ind decoding AV1 frames can cause lag or dropped frames. |
| VBSS codec changes detected | ScreenSharing codec changes during Call. HW or SW / AV1 or H264 |
| Video codec changes detected | Video codec changes during Call. HW or SW, H264 |
| Audio codec changes detected | Audio codec changes during call. SATIN ,SATINFullband, Opus, etc. |
| Spatial Audio Detected | Spatial Audio detected during call. Spatial mopde needs 4Mb/s up and down compared to SATIN which needs just 36k for each direction. Using Spatial Audio impacts on Audio Quality |
| User transmitted streams with the potential to impact older devices | Sender of AV1 or spatial audio. Teams does not transcode. So all other computers (receiver) must do decoding (higher resources needed) |
Components on the Dashboard
...