Call Insights enables customers to evaluate a call efficiently without reviewing all the various call metrics. The highlevel information is available on the Call Debug Level dashboard , indicated by the following panel visible above the map:
Clicking on the panel opens the Single Call Insights Dashboard.
On the dashboard there are several tables that give information on the types of insights we've found, the users impacted by them and the networks the users who experienced them were working on. Insights are comprised of an analysis of several factors occuring during the call in certain combinations. They generally point at unusual or potentially problematic situations and can help administrators in determining the causes of issues more quickly. The list of Insights as determined so far is listed below and this can be exapanded with more insights as we go forward.
Elements:
- KPI's: Provide general overview information about the users for which insights were registered (excluding users in the call without insights!)
- Insights table: Lists each individual Insight per user with additional details about the users networking situation during the call. A single insight can occur multiple times and users can have multiple insights but an insight can not occur multiple times for the same user.
- Device Platform(s) Used table: Shows each user with the platforms he/she used during the call and indicates when changes took place. Use the Information text (
icon) in the top to see which number corresponds to which platform.
List of Insights
Current list of possible Insights
| 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. 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). This can be due to device (microphone) or driver related issues - faulty hardware/outdated driver. But if can be related to Codec changes or OS activity. Possible Actions?
|
| Audio traffic used a managed VPN | Audio traffic was routed via VPN (on a managed network). This insight is more a informational one. |
| AV1 codec detected in VBSS stream | AV1 codec detected during ScreenSharing. AV1 is a highly efficient codec. However it is very resource intensive on sender / receiver side because more computation is required to decode the incoming stream/encode the outgoing stream. For instance, any delay in decoding AV1 frames can cause lag or dropped frames. Unfortunately there is no way to switch off this codec for VBSS. Teams Client decides this automatically and may failover to h264. Possible Actions?
|
| VBSS codec changes detected | ScreenSharing codec changes during Call. HW or SW / AV1 or H264. Teams Client decides based on certain conditions which codec is used and failover to h264 hw, sw. These changes usually impacts the end user experience (loss rate, ...) Possible Actions?
|
| Video codec changes detected | Video codec changes during Call. HW or SW, H264. Teams Client and Operating System decides based on certain conditions which codec is used and failover to h264 hw, sw. These changes usually impacts the end user experience (loss rate, ...) Possible Actions?
|
| Audio codec changes detected | Audio codec changes during call. SATIN ,SATINFullband, Opus, etc.Teams Client decides based on certain conditions which codec is used and failover to h264 hw, sw. These changes usually impacts the end user experience (loss rate, ...). Possible Actions?
|
| Spatial Audio Detected | Spatial Audio detected during call. Spatial mode needs 4Mb/s up and down compared to SATIN which needs just 36k for each direction. Using Spatial Audio impacts on Audio Quality. TrueDEM can differentiate if Spatial Audio has been received and/or transmitted. Typically the Audio Codec x-multichannel2 is one of the indication for this. Possible Actions?
|
| User transmitted streams with the potential to impact older devices | Sender uses AV1 or spatial audio. Because Teams does not transcode,all other devices (receiver) must do decoding (higher resources needed) Possible Actions?
|
| A firewall or other network equipment blocked traffic to a required IP address and port | MissingFWIPBlockExemptionRule in the call data typically indicates a firewall rule that is blocking necessary traffic for Teams calls to function correctly. This can lead to poor call quality or even failed calls. Possible Actions?
|
| User Experienced Call Initialization Failure(s) | This insight is appears if MissingFWIPBlockExemptionRule or CallSetupFailure event caused an Initialization error. The issue could be related to either firewall and network reasons or other events where the call setup was unsuccessful. Possible Actions?
|