This document primarily discusses how to perceive the quality of the current network.
Check network quality during the call
TRTC offers a callback event known as onNetworkQuality, which reports the current network quality to you every two seconds. Its parameters include two parts: localQuality and remoteQuality
localQuality: Represents your current network quality, divided into 6 levels, which are Excellent, Good, Poor, Bad, VeryBad, and Down.
remoteQuality: Represents the network quality of remote users. This is an array, each Element (XML) in the array represents the network quality of a remote user.
Quality
Name
Description
0
Unknown
Unperceived
1
Excellent
The present network is exceedingly good
2
Good
The current network is fairly good
3
Poor
Current network is average
4
Bad
Present network quality is poor, it might cause noticeable stutters and communication delays
5
VeryBad
The current network conditions are abysmal, TRTC can barely maintain a connection, yet it can't guarantee the quality of communication
6
Down
The current network does not meet the minimum requirements of TRTC, obstructing the normal audio and video conversation
All you need is to monitor TRTC's onNetworkQuality and make corresponding prompts on the interface:
// Monitor the onNetworkQuality callback and perceive the alterations in the current network status
During speed testing, the SDK sends a batch of probe packets to the server node, measures the quality of return packets, and returns the testing result via a callback API.
The testing result can be used to optimize the SDK's server selection policy, so you are advised to run the test before the first call, which will help the SDK select the optimal server. If the result is unsatisfactory, you can show a UI message asking users to change to a better network.
The results of the speed test (TRTCSpeedTestResult) include the following fields:
Field
Meaning
Description
success
Whether it is successful
Whether this test was successful
errMsg
Error message
Detailed error information of bandwidth testing
ip
Server address
Testing server IP
quality
Network quality score
Network quality measured by the evaluation algorithm. The lower the loss, the smaller the RTT, and the higher the score
upLostRate
Upstream packet loss rate
The range is [0 - 1.0], for example, 0.3 means that out of 10 data packets sent to the server, 3 may be lost midway
downLostRate
Downstream packet loss rate
The range is [0 - 1.0], for example, 0.2 means that out of every 10 data packets received from the server, 2 may be lost
rtt
Latency
Represents the time consumed in the round trip between the SDK and the server. The smaller the value, the better. The normal range is between 10ms and 100ms
availableUpBandwidth
Upstream bandwidth
Predicted upstream bandwidth, in kbps. -1 indicates an invalid value
availableDownBandwidth
Downstream bandwidth
Predicted downstream bandwidth, in kbps. -1 indicates an invalid value
How to Test Speed
You can start the speed test feature through the startSpeedTest method of TRTCCloud (in Flutter, use the startSpeedTestWithParams interface). The speed test results will be returned via a callback function.
// Sample code to start network speed test. Requires sdkAppId and UserSig (refer to the basic feature for how to obtain these)
// This is an example starting from log in to begin testing
_onLogin(String userId,String userSig) async {
TRTCSpeedTestParams params =TRTCSpeedTestParams(
// sdkAppID is the actual app's AppID obtained from the console
sdkAppId: sdkAppId,
userId: userId,
userSig: userSig,
scene:TRTCSpeedTestScene.delayBandwidthTesting,
// Expected upstream bandwidth in Kbps. Value range: 10–5000. 0 indicates not to test
expectedDownBandwidth:500,
// Expected downstream bandwidth in Kbps. Value range: 10–5000. 0 indicates not to test