End-to-end call details are the details of data transferred across the sender-receiver link. The preconditions of a smooth audio/video call are good network connections and stable device performance, which are what you should start with when checking the end-to-end details of a call.
The end-to-end details page shows the data of Video, Audio, and Screen Sharing, which can be viewed from the perspective of the receiver or sender.
You can analyze end-to-end data from network conditions and device status.
Ideally, data should be transferred at high bandwidth, with zero packet loss and no delay, but in reality, packet loss, delay, and instability are common, and bandwidth is often limited. Given this, you need to pay special attention to the following points when analyzing network conditions.
In the graph, packet loss is represented by a red line.
|Packet Loss Rate||Network Conditions|
|> 10% (or constant packet loss)||Serious network congestion|
Normally, the fluctuations of audio/video bitrate should be smaller than 10%. If the bitrate experiences dramatic fall or fluctuations larger than 30%, it indicates network congestion or jitter.
Because the GOP duration of screen sharing is relatively long (5-10 seconds), normally, the bitrate follows a regular cycle, represented by a curve which peaks at keyframes.
Normally, video frame rate should stabilize at around 15 fps or higher (5-10 fps for screen sharing). If the frame rate experiences fluctuations larger than 5 fps or falls and stays below 10 fps, it indicates network congestion or jitter. When this happens, users experience stutter. Periods of excessively low frame rates are marked red in the graph.
Stable device performance is necessary for a successful audio/video call. Preferably, the device uses a small amount of system resources, does not compete for resources with other devices, and collects data without interference. Pay attention to the following aspects when checking device status.
Both system CPU usage and application CPU usage are displayed. Normally, system CPU usage should be lower than 50%. The lower, the better. If system CPU usage exceeds 85%, the application may stop responding or respond slowly. This is marked by red lines in the graph.
Some Android devices and system versions are unable to calculate CPU usage, in which case you can use Time Consumption of SDK Task to assess device performance. If a task takes longer than 60 ms to complete, it indicates high system CPU usage, and the application may not respond or be slow to respond. Consider closing other processes in the background or update your hardware.
The normal volume range is 40-80 dB. If the volume is lower than 40 dB, and the user cannot hear any audio, check for hardware failure or whether the user’s phone is muted.
The resolutions of video and screen sharing are additional information used mainly to analyze relayed live streaming and the replay of recorded streams. Fluctuations in resolutions indicate that audience watching relayed live streams via CDN or replaying recorded videos, especially web users, may be experiencing player compatibility issues such as stuttering or pixelated video.
Resolution, bitrate, and frame rate are related to each other. Generally, when resolution is fixed, the higher the bitrate, the clearer the image; when bitrate is fixed, the higher the resolution, the blurrier the image. Set resolution, bitrate, and frame rate properly to ensure good video quality.
Client events correspond to the calling of SDK APIs by the application and are usually used to help locate software problems, analyze bugs, as well as simulate scenarios by analyzing users’ operations. Pay attention to these client events:
Click View Detailed Event to open the event list and view the operations of key client events.