Use real-time telemetry to troubleshoot poor meeting quality
This article explains how to use Real-Time Analytics (RTA) to troubleshoot poor Microsoft Teams meeting quality for individual users. You can access Real-Time Analytics if you have one of the following roles:
- Teams Administrator
- Teams Communications Support Specialist
- Teams Communications Support Engineer
For more information on Teams admin roles, see Use Microsoft Teams administrator roles to manage Teams.
Real-Time Analytics lets IT admins look at their important users’ scheduled meetings and see audio, video, content sharing, and network-related issues. As an admin, you can use this telemetry to investigate these issues during meetings and troubleshoot in real time.
What is Real-Time Analytics?
Today, individual meeting troubleshooting is available for Teams administrators through Call Analytics after the meeting ends. Real-Time Analytics lets admins troubleshoot scheduled meetings while they're in progress.
Real-Time Analytics shows detailed information about Teams meetings for each user in your Office 365 account, updated in real time. It includes information about devices, network, connectivity, audio, video, and content sharing issues, which will help admins troubleshoot call quality more effectively.
As a Teams admin, you get full access to all real-time telemetry data for each user. In addition, you can assign Azure Active Directory roles to support staff. To learn more about these roles, see Give permission to support and help desk staff.
Where to find per-user real-time troubleshooting telemetry
To see all meeting information and data for a user, go to the Teams admin center. Under Users > Manage users, select a user, and open the Meetings & calls tab on the user's profile page. Under Recent meetings, you'll see a list of meetings the user has attended within the past 24 hours for which real-time telemetry is available, including any in progress meetings. If the meeting isn't in progress or doesn't have real-time telemetry data, it will show up in Past meetings.
Note
For a meeting to show up under "Recent Meetings", a Teams admin must have clicked on the meeting in Real-Time Analytics while the meeting was in progress to begin the flow of real-time client telemetry.
To get additional information about participants of a meeting that's in progress, including their device, network, and audio statistics, find the meeting in Recent meetings and select the link under the Participants column.
To look at the telemetry of a given user for an in-progress meeting, including information around device, network, audio, video, and content sharing details, select the Meeting ID.
Details and measures available in Real-Time Analytics
Device information
| Name | Description | Possible reasons for blank values |
|---|---|---|
| Audio capture device | Name of the audio capture device (eg: microphone) in use | System might not have a name associated with the device (eg: Remote Desktop or Virtual machine 'Remote audio' device) |
| Audio render device | Name of the audio render device (eg: speakers or headphones) in use | System might not have a name associated with the device (eg: Remote Desktop or Virtual machine 'Remote audio' device) |
| Video capture device | Name of the video capture device in use | User isn't sending video from the endpoint being monitored |
Connectivity information
| Metric | Units / Possible values | Description | Possible reasons for blank values |
|---|---|---|---|
| Network type | • Ethernet • Wi-Fi |
Type of network connection in use | |
| Wi-Fi strength | • Excellent : -50 dBm or greater • Good : -51 dBm to -64 dBm • Poor : -65 dBm or lower |
Strength of the user's current Wi-Fi connection | User isn't connected to Wi-Fi |
| Wi-Fi channel | Integer | Channel over which the Wi-Fi network's access point is broadcasting | User isn't connected to Wi-Fi |
| Physical type | String • Example: 802.11ac |
Wireless infrastructure type in use | User isn't connected to Wi-Fi |
| Wi-Fi band | 2.4 GHz or 5 GHz | Wi-Fi band to which the user is connected | User isn't connected to Wi-Fi |
| Location | String | Country in which the user is located | User's location information is blocked or unavailable |
| Local IP address | String (IP:Port) | Local IP address of the user's endpoint and the media port | |
| Server reflexive IP address | String (IP:Port) | Public IP address of the user's endpoint and the media port | |
| Connectivity type | UDP or TCP | Transport layer protocol in use; UDP is preferred for real-time media |
User signals
User signals identify when a user is actively participating in the call, isn't speaking but unmuted, or is muted. Currently, user signals are only available for audio.
| Modality | Possible values | Description |
|---|---|---|
| Audio | • Unmuted, participant speaking • Unmuted, not speaking • Muted |
Indicates the behavior of the user for the audio portion of the call |
Audio
| Measure Name | Units | Good Threshold | Description |
|---|---|---|---|
| Jitter | Milliseconds | Less than 30 ms | Jitter is a measure of the variation in packet delay for a data stream. When this is too high, audio can become choppy. |
| Packet Loss | Percentage | Less than 5% | Packet loss occurs when data packets fail to reach their destination. The percentage of packets lost is based on the total number of packets sent. |
| Round Trip Time | Milliseconds | Less than 500 ms | Round trip time is the time it takes for a single packet to travel from the client to the remote endpoint and back to the client. High round trip time can cause delays in stream playback. An example of this is when two people in a meeting are unintentionally speaking over each other due to the delay. Shown for outbound audio only. |
| Bitrate | Kilobits per second (Kbps) | Greater than 24 Kbps | Throughput of the audio stream expressed in kilobits per second. |
| Codec | String • Example: SATIN |
Information only | Displays the audio codec being sent and received. A different codec can be received than the one being sent. |
Video
| Measure Name | Units | Good Threshold | Description |
|---|---|---|---|
| Round Trip Time | Milliseconds | Less than 500 ms | Round trip time is the time it takes for a single packet to travel from the client to the remote endpoint and back to the client. High round trip time can cause delays in stream playback. An example of this is when two people in a meeting are unintentionally speaking over each other due to the delay. |
| Bitrate | Megabits per second (Mbps) | Information only | Throughput of the video stream expressed in megabits per second. |
| Frame Rate (Video) | Frames per second | 360p or better: 25-30 FPS 270p or lower: 7-15 FPS |
For outbound video streams, frame rate (FPS) is the number of frames per second of video the client is sending. Lower than expected values here may suggest system resource constraints, insufficient network bandwidth, or misbehaving video capture devices. Different resolutions have different acceptable FPS ranges. |
| Codec | String | Information only | Displays the video codec and rendering mode of the outbound video stream. (Example: H264 SW HW indicates an H264 video stream using both software and hardware rendering.) |
| Resolution | Pixels | Information only | The resolution of the video being sent. Outbound video resolution is dynamic, based on the highest requirement from an endpoint in the meeting. A client capable of 1920 x 1080 video will only send 640 x 360 video if no clients are displaying that user's video in a frame larger than 640 x 360 |
Application Sharing (VBSS)
| Measure Name | Units | Good Threshold | Description |
|---|---|---|---|
| Packet Loss | Percentage | Less than 5% | Packet loss occurs when data packets fail to reach their destination. The percentage of packets lost is based on the total number of packets sent. |
| Round Trip Time | Milliseconds | Less than 500 ms | Round trip time is the time it takes for a single packet to travel from the client to the remote endpoint and back to the client. High round trip time can cause delays in stream playback. An example of this is when two people in a meeting are unintentionally speaking over each other due to the delay. |
| Bitrate | Megabits per second (Mbps) | Information only | Throughput of the VBSS stream expressed in megabits per second. |
| Frame Rate | Frames per second (FPS) | Information only | For VBSS, frame rate is content-aware to ensure as many frames as necessary are sent to ensure a good experience while avoiding sending frames if they're not needed. For example, sharing a text document on-screen only requires 1 frame-per-second to produce a good experience, whereas sharing a video or content with more activity will increase frames per second to a maximum of 30 FPS to produce a smoother experience. |
| Codec | String | Information only | Displays the codec and rendering mode of the VBSS stream. (Example: H264 SW HW indicates an H264 VBSS stream using both software and hardware rendering.) |
| Resolution | Pixels | Information only | The resolution of the VBSS stream being sent and received. |
Client platforms supported for real-time telemetry
- Windows
- macOS
- Linux
- Android
- iOS
Note
Teams Web client (including VDI) does not support delivery of telemetry in real time.
Teams devices with support for real-time telemetry
- Teams display
- Teams phone
- Teams Rooms
- Teams Rooms on Surface Hub
Note
Devices that joined the meeting using Cloud Video Interop (CVI) solutions are not supported in Real-Time Analytics.
Limitations
- Real-time telemetry subscription isn't automatic for all meetings and must be started by a Teams admin while the meeting is in progress.
- Real-time telemetry will only be available for a meeting's supported endpoints from the point at which the admin first clicked the in-progress meeting in Real-Time Analytics.
- Real-time telemetry is only available for scheduled meetings and Meet Now. For PSTN, 1:1 calls, and group calls, real-time telemetry isn't available.
- Real-time telemetry is only available for presenters of scheduled live event. It's currently not available for live event attendees.
- Real-time telemetry data is available for a meeting under Recent meetings for 24 hours after the meeting has ended. After 24 hours, you can't access the data and the meeting moves to Past meetings. If a meeting is longer than 3 hours, real-time telemetry will only be available for the last 3 hours.
- Telemetry isn't available in real time when using older versions of Teams. If no telemetry is available, try updating your client.
- If external participants or anonymous users join a meeting, their display name will show as unavailable to retain cross-tenant privacy.
Note
As part of a limited-time public preview, real-time telemetry data is currently available for 7 days after a meeting has ended. After the preview ends, only tenants with Advanced Communications add-on licensing will have telemetry available for the extended 7 day period. All other tenants will be subject to the aforementioned limits.
Related topics
Feedback
Submit and view feedback for