Quality segmentation positioning detection system applied to medium-screen video call

Abstract

The invention discloses a quality segmentation positioning detection system applied to a middle-screen video call, and belongs to the technical field of communication exchange, and the system comprises a middle-screen end monitoring service module which is used for carrying out real-time statistics and anomaly detection on RTP (Real-time Transport Protocol) packets; the call service access layer monitoring module is used for analyzing packet loss data of a forward link and a backward link through a Kamailio and RTPengine architecture; and the multi-dimensional diagnosis decision module is used for fusing RTP statistical data of a middle screen end and a call service access layer, constructing a packet loss path topological graph, judging an influence source and triggering a corresponding optimization suggestion. According to the invention, accurate segmentation positioning of video stream packet loss and abnormal quality in a medium-screen video call scene is realized. According to the technology, a single view angle of traditional end-to-end monitoring is broken through, independent packet loss statistics and responsibility judgment of three sections of a WiFi wireless link, a mobile phone cellular link and a core network access layer are realized for the first time, the accuracy and timeliness of network anomaly positioning are greatly improved, and a solid data basis is provided for subsequent targeted optimization.

Description

Technical Field

[0001] This invention belongs to the field of communication switching technology, and specifically relates to a quality segmentation and positioning detection system for mid-screen video calls. Background Technology

[0002] Mid-screen video calling: Mid-screen refers to smart speakers with a built-in screen, typically 6-10 inches in size. These speakers feature voice wake-up and interactive functions and generally run on Android, supporting Android application development. Mid-screen video calling, specifically the mid-screen video calling APK client, is based on the SIP protocol and connects to a video calling cloud service via the internet. This cloud service then connects to the operator's core network, accessing the calling network. Users can directly dial mobile or landline numbers using the mid-screen video call APK to make calls. For terminals supporting VoLTE / VoNR video calling, video calling functionality is also available.

[0003] With the widespread adoption of mobile communication technology, the usage rate of traditional landline phones is gradually declining, while smart devices with screens (such as smart speakers) are becoming a new entry point for home communication. These devices typically feature 6-10 inch screens, run on the Android operating system, and support functions such as voice interaction, video calls, and calendar management. They connect to video calling cloud services via the SIP protocol, thereby accessing the operator's core network to enable calls with mobile phones or landlines. For video terminals supporting VoLTE / VoNR, high-definition video calling experiences can also be provided.

[0004] In practical applications, typical communication paths for mid-screen video calls include: Mid-screen → WiFi router (wireless), WiFi router → Call service access layer (wired), Call service access layer → Core network (wired), Core network → Base station (wired), Base station → Mobile phone (wireless).

[0005] In an ideal network environment, the encoding and decoding capabilities of both the mid-screen and the mobile phone have been verified to be problem-free, resulting in good video call quality. However, in practical applications, issues such as stuttering and screen flickering may still occur, primarily due to packet loss during network transmission. Because the call path involves multiple stages, and some stages (such as the wireless connection between the mobile phone and the base station, and the internal core network) are difficult to monitor directly, fault location becomes challenging. Currently, optimizing video call quality faces the following challenges: Wireless transmission is susceptible to interference: WiFi signals are affected by factors such as distance, obstacles, and channel interference, while the signal strength of mobile cellular networks (4G / 5G) also fluctuates, resulting in a high packet loss rate and a significant risk.

[0006] Wired transmission links are relatively stable: core networks and backbone networks typically have redundant designs and strict monitoring, resulting in a low probability of packet loss and minimal risk.

[0007] Limitations of end-to-end monitoring: Existing methods typically rely on end-to-end quality assessments (such as RTP / RTCP statistics), but cannot accurately distinguish whether the problem occurs in the WiFi segment, the cellular network segment, or the core network segment. For example, if a user reports video buffering, current technology struggles to determine whether it's due to a weak WiFi signal, poor cellular network performance, or abnormal core network transmission.

[0008] The optimization measures lack specificity: Since it is impossible to accurately locate the problem area, operators or users can only adopt general optimization methods (such as adjusting encoding parameters and enhancing WiFi signal), which are inefficient and may not solve the fundamental problem.

[0009] Furthermore, mid-screen devices typically use the Android system, and the limitations of its network stack and video processing capabilities further increase the complexity of quality monitoring. For example, Android's network diagnostic tools (such as ping and traceroute) are difficult to apply directly to real-time video call scenarios and cannot distinguish the source of packet loss between wireless and wired links.

[0010] Therefore, there is an urgent need for a method to achieve accurate segmentation and localization in mid-screen video call scenarios. By analyzing data from monitorable nodes, this method can quickly identify the specific network segments (such as WiFi and cellular networks) causing quality degradation, thus providing a clear direction for optimization. For example, if the problem is located in the WiFi segment, the user can be advised to adjust the router location or switch to the 5GHz band; if the problem is located in the cellular segment, the called user can be prompted to switch to a more stable network; if the core network segment is abnormal (although the probability is low), the server-side disaster recovery switching mechanism can be triggered. Summary of the Invention

[0011] This invention addresses the shortcomings of existing technologies by providing a quality segmentation and localization detection system for mid-screen video calls. Through segmentation and localization detection methods, it can quickly and accurately identify specific network segments that cause video quality degradation, thereby providing precise basis for network optimization and improving the stability of video calls and user experience.

[0012] To achieve the above objectives, the present invention adopts the following technical solution: A quality segmentation and localization detection system for mid-screen video calls includes: The mid-screen monitoring service module is used to perform real-time statistics and anomaly detection on RTP packets; The call service access layer monitoring module is used to analyze packet loss data in the forward and backward links through the Kamailio and RTPengine architecture. The multi-dimensional diagnostic decision module is used to integrate RTP statistics from the mid-screen terminal and the call service access layer, construct a packet loss path topology map, identify the source of impact, and trigger corresponding optimization suggestions.

[0013] To optimize the above technical solution, the specific measures also include: Furthermore, the real-time statistics and anomaly detection of RTP packets specifically includes: By using a sliding window mechanism, the RTP packet sequence number data collected by the middle screen is analyzed to form a short-term packet loss heatmap. The short-term packet loss heatmap is used to describe the short-term packet loss rate within each time window. When the short-term packet loss rate within a window exceeds a set threshold, the time period in which the window is located is marked as a potential abnormal time period. After the call is initiated, record the sequence numbers of the first and last RTP packets, calculate the theoretical total number of RTP packets to be received, and count the actual number of RTP packets received. Compare this count with the theoretical total number of RTP packets to calculate the overall packet loss rate. By comparing short-term packet loss heatmaps, network quality can be assessed. If the overall packet loss rate is below the threshold, but the short-term packet loss rate exceeds the set threshold, WiFi link interference is determined; otherwise, insufficient uplink bandwidth at the remote end is determined. Analyze the FU-A fragment integrity of the IDR frame. If the FU-A fragment of the IDR frame is incomplete, mark the key frame as missing, and synchronously upload the relevant metadata of the abnormal flag frame, including the RTP sequence number and PTS timestamp.

[0014] Furthermore, the analysis of packet loss data in the forward and backward links using the Kamailio and RTPengine architecture specifically involves: During the call setup phase, when the Kamailio SIP agent receives the INVITE signaling, it automatically starts the media statistics service and automatically triggers the RTPengine's forward and reverse link statistics function for the audio and video media streams of this call. RTPengine caches and parses call RTP packets in real time, accumulating raw data for subsequent packet loss detection; During the call termination phase, after receiving the BYE signaling, RTPengine is triggered to terminate statistics and record the triggering time of various call signaling, providing basic call information for subsequent forward and reverse link packet loss judgment processes. Perform forward link packet loss detection and reverse link packet loss detection.

[0015] Furthermore, the forward link packet loss determination specifically involves: Analyze the RTP flow quality from the mobile terminal to the mid-screen terminal and check whether the packets received by the call service access layer are complete. If they are incomplete and the mid-screen terminal also reports an error, it is initially determined that the packet loss occurred on the public network uplink or the mobile terminal. Further correlation with signaling information is used to assist in the analysis of link performance.

[0016] Furthermore, the reverse link packet loss judgment is specifically as follows: The RTP packet reception along the path from the middle screen, WiFi, AP to the call service access layer is analyzed. RTPengine monitors whether there are frequent interruptions or jitter anomalies in the packets sent by the middle screen. The stability of the WiFi link is inferred by combining the UDP inspection mechanism.

[0017] Furthermore, the specific process of integrating RTP statistics from the central screen and the call service access layer, constructing a packet loss path topology map, identifying the impact source, and triggering corresponding optimization suggestions is as follows: Receive RTP statistics from the middle screen terminal and the call service access layer, including packet loss rate and jitter count, and use RTP sequence number and PTS timestamp to confirm the continuity of data packets; Use a unified time base to synchronize the RTP statistics data of the middle screen terminal and the call service access layer on the time axis; Construct a packet loss path topology diagram, including three segments: forward link, backward link, and local link. The forward link is specifically: mobile terminal → public network → call service access layer; the backward link is specifically: call service access layer → public network → middle screen terminal; the local link includes middle screen WiFi access and system decoding. Based on the RTP statistics of the mid-screen terminal and the call service access layer after time axis synchronization, the link responsibility of the packet loss path topology is determined, and corresponding optimization suggestion strategies are matched according to the link responsibility determination results.

[0018] Furthermore, the specific process for determining link responsibility is as follows: If packet loss occurs in both the upstream data of the call service access layer and the mid-screen device, the problem is determined to be on the mobile phone side or the uplink; if the downstream data of the call service access layer is normal but the mid-screen device is abnormal, the problem is determined to be on the WiFi link or the mid-screen device itself; the upstream direction is from the mobile phone to the call service access layer, and the downstream direction is from the call service access layer to the mid-screen device. If the statistical data is normal but the user experience is abnormal, further analysis of local system logs should be conducted to determine if it is a device performance bottleneck.

[0019] Furthermore, the optimization suggestion strategies include: prompting users to switch networks, automatically adjusting video bitrate or frame rate, switching between software and hardware decoding methods, and suggesting proximity to the router and enabling the 5G band on the router.

[0020] The beneficial effects of this invention are: (1) Precise segmented positioning capability: Breaking through the limitations of traditional end-to-end monitoring, it achieves packet loss separation statistics for WiFi segment, cellular segment and core network segment for the first time, improving positioning accuracy by more than 80% (actual test data shows that the misjudgment rate of traditional methods is 35%, while this solution can reduce it to less than 5%).

[0021] (2) Lightweight monitoring architecture: monitoring points only need to be deployed on the mid-screen terminal and the controllable access layer, avoiding dependence on uncontrollable terminals (such as random mobile phones), reducing implementation costs by 60%.

[0022] (3) Real-time dynamic response: Through short-term statistics at the granularity of 100 packets, sudden packet loss can be identified within 2 seconds (traditional methods require more than 10 seconds). Combined with Android layer rendering status feedback, the closed-loop speed-up from fault discovery to repair is achieved by 3 times.

[0023] (4) This invention achieves accurate segmented location of video stream packet loss and quality anomalies in mid-screen video call scenarios by constructing a real-time packet loss monitoring module for the mid-screen terminal, a bidirectional link analysis module for the call service access layer, and a multi-dimensional intelligent diagnostic decision module. This technology breaks away from the single perspective of traditional end-to-end monitoring and, for the first time, realizes independent packet loss statistics and responsibility determination for three segments: WiFi wireless link, mobile cellular link, and core network access layer. This greatly improves the accuracy and timeliness of network anomaly location and provides a solid data foundation for subsequent targeted optimization.

[0024] (5) This invention designs a dual monitoring scheme that combines short-term packet loss detection and full-process packet loss statistics based on a sliding window mechanism. This scheme can capture instantaneous network fluctuations and overall transmission stability in real time. At the same time, it combines keyframe FU-A fragment integrity checks to accurately identify keyframe loss problems that have the greatest impact on video quality. This innovative mechanism makes full use of the underlying NALU information and rendering feedback of the mid-screen Android system, effectively avoiding the limitations of traditional network diagnostic tools that cannot be associated with user experience, and realizing a deep integration of business perception and network detection.

[0025] (6) In the call service access layer, the present invention adopts Kamailio and RTPengine to work together to form a segmented statistical system for bidirectional media streams. The statistical service is dynamically started by using the signaling triggering mechanism, and RTP packet quality data is cached and analyzed in real time. This enables independent judgment and attribution of packet loss in the forward (mobile terminal → middle screen) and reverse (middle screen → access layer) links, effectively avoiding the error of responsibility attribution caused by misjudgment due to single-end monitoring, and providing an accurate basis for the root cause analysis of network problems.

[0026] (7) This invention uses a multi-dimensional diagnostic engine to time-align and synchronize data collected from the mid-screen and access layers, constructs a packet loss path topology, comprehensively calculates the packet loss contribution of each link segment, and combines key frame anomaly weights and historical baseline dynamic thresholds to achieve accurate identification and graded alarms for abnormal links. Based on this diagnostic result, the system can intelligently generate targeted optimization suggestions, such as switching networks, adjusting video bitrate, or switching decoding strategies, and execute them automatically through the user interface or system, significantly improving the stability of video calls and user experience, reducing user complaint rates, and effectively shortening fault location time.

[0027] Through the combination of the above technologies, the present invention effectively solves the optimization blind spot problem caused by network segmentation in mid-screen video calls, reduces the average fault location time from 15 minutes in the traditional solution to 3 minutes, and reduces the user experience complaint rate by 70%. Attached Figure Description

[0028] Figure 1 This is a diagram showing the modules and connection attributes through which a video call passes through the central screen.

[0029] Figure 2 A flowchart for the overall process of quality segmentation and localization detection in mid-screen video calls. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0031] Example 1 This invention proposes a quality segmentation and localization detection system for mid-screen video calls, wherein the data flow of the mid-screen video call passes through the following modules: Figure 1 As shown, the principle of the quality segmentation positioning and detection system is as follows: Figure 2 As shown, the system includes: The mid-screen monitoring service module is used for real-time statistics and anomaly detection of RTP packets. Its innovation lies in binding the underlying network stack data of the Android system (such as NALU header information) with the video rendering layer state, solving the problem that traditional Android diagnostic tools cannot relate to business experience. The specific process of real-time statistics and anomaly detection of RTP packets is as follows: By employing a sliding window mechanism, the RTP packet sequence number data collected from the mid-screen is analyzed to generate a short-term packet loss heatmap. This heatmap describes the short-term packet loss rate within each time window. The window length (e.g., 100 packets) is dynamically adjusted based on the device's computing power to increase the detection frequency. When the short-term packet loss rate within a window exceeds a set threshold (e.g., 3%), the time period containing that window is marked as a potentially abnormal period. This mechanism possesses edge computing capabilities, allowing it to operate locally on the device with low power consumption, while simultaneously avoiding false alarms and false detections, thus improving recognition accuracy.

[0032] After the call is initiated, record the sequence numbers of the first and last RTP packets, calculate the theoretical total number of RTP packets to be received, and count the actual number of RTP packets received. Compare this count with the theoretical total number of RTP packets to calculate the overall packet loss rate. By comparing short-term packet loss heatmaps, network quality can be assessed. If the overall packet loss rate is below the threshold, but the short-term packet loss rate exceeds the set threshold, WiFi link interference is determined; otherwise, insufficient uplink bandwidth at the remote end is determined. Analyze the FU-A fragment integrity of the IDR frame. If the FU-A fragment of the IDR frame is incomplete, the key frame is missing. This anomaly usually causes severe pixelation or screen tearing, and the rendering engine will produce visual abnormalities. Synchronously upload the metadata related to the anomaly flag frame, including the RTP sequence number and PTS timestamp.

[0033] The call service access layer monitoring module analyzes packet loss data in the forward and backward links using the Kamailio and RTPengine architecture. This module is the first to implement bidirectional segmented diagnosis based on the core network access point. Specifically, the analysis of packet loss data in the forward and backward links using the Kamailio and RTPengine architecture involves: During the call setup phase, when the Kamailio SIP agent receives the INVITE signaling, it automatically starts the media statistics service and automatically triggers the RTPengine's forward and reverse link statistics function for the audio and video media streams of this call. RTPengine caches and parses call RTP packets in real time, accumulating raw data for subsequent packet loss detection; During the call termination phase, after receiving the BYE signaling, RTPengine is triggered to terminate statistics and record the triggering time of various call signaling, providing basic call information for subsequent forward and reverse link packet loss judgment processes. Perform forward link packet loss detection and reverse link packet loss detection.

[0034] The forward link packet loss judgment is specifically as follows: Analyze the RTP flow quality from the mobile terminal to the mid-screen terminal and check whether the packets received by the call service access layer are complete. If they are incomplete and the mid-screen terminal also reports an error, it is initially determined that the packet loss occurred on the public network uplink or the mobile terminal. Further correlation with signaling information (such as media negotiation time and ICE candidate selection) is used to assist in the analysis of link performance.

[0035] The specific steps for determining packet loss on the reverse link are as follows: The RTP packet reception along the path from the middle screen, WiFi, AP to the call service access layer is analyzed. RTPengine monitors whether there are frequent interruptions or jitter anomalies in the packets sent by the middle screen. The stability of the WiFi link is inferred by combining the UDP inspection mechanism.

[0036] The multi-dimensional diagnostic decision-making module integrates RTP statistics from the mid-screen terminal and the call service access layer to construct a packet loss path topology map, identify the impact source, and trigger corresponding optimization suggestions. The specific process is as follows: Receive RTP statistics from the middle screen terminal and the call service access layer, including packet loss rate and jitter count, and use RTP sequence number and PTS timestamp to confirm the continuity of data packets; The timeline of RTP statistics between the mid-screen terminal and the call service access layer is synchronized using a unified time base; this ensures that abnormal data from different sources can be compared and correspond, providing consistent data support for link responsibility judgment.

[0037] Construct a packet loss path topology diagram, including three segments: forward link, backward link, and local link. The forward link is specifically: mobile terminal → public network → call service access layer; the backward link is specifically: call service access layer → public network → middle screen terminal; the local link includes middle screen WiFi access and system decoding. Based on the RTP statistics of the mid-screen terminal and the call service access layer after time axis synchronization, link responsibility is determined for the packet loss path topology. The specific process is as follows: If packet loss occurs in both the upstream data of the call service access layer and the mid-screen device, the problem is determined to be on the mobile phone side or the uplink; if the downstream data of the call service access layer is normal but the mid-screen device is abnormal, the problem is determined to be on the WiFi link or the mid-screen device itself; the upstream direction is from the mobile phone to the call service access layer, and the downstream direction is from the call service access layer to the mid-screen device. If the statistical data is normal but the user experience is abnormal, further analysis of local system logs should be conducted to determine if it is a device performance bottleneck.

[0038] Based on the link responsibility assessment results, corresponding optimization suggestions are matched. These suggestions include: prompting users to switch networks, automatically adjusting video bitrate or frame rate, switching between hardware and software decoding methods, and recommending proximity to routers and enabling 5G frequency bands on routers.

[0039] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0040] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A quality segmentation and positioning detection system for mid-screen video calls, characterized in that, include: The mid-screen monitoring service module is used to perform real-time statistics and anomaly detection on RTP packets; The call service access layer monitoring module is used to analyze packet loss data in the forward and backward links through the Kamailio and RTPengine architecture. The multi-dimensional diagnostic decision module is used to integrate RTP statistics from the mid-screen terminal and the call service access layer, construct a packet loss path topology map, identify the source of impact, and trigger corresponding optimization suggestions.

2. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 1, characterized in that, The real-time statistics and anomaly detection of RTP packets specifically involves: By using a sliding window mechanism, the RTP packet sequence number data collected by the middle screen is analyzed to form a short-term packet loss heatmap. The short-term packet loss heatmap is used to describe the short-term packet loss rate within each time window. When the short-term packet loss rate within a window exceeds a set threshold, the time period in which the window is located is marked as a potential abnormal time period. After the call is initiated, record the sequence numbers of the first and last RTP packets, calculate the theoretical total number of RTP packets to be received, and count the actual number of RTP packets received. Compare this count with the theoretical total number of RTP packets to calculate the overall packet loss rate. By comparing the short-term packet loss heatmap, network quality can be better judged. If the overall packet loss rate is lower than the threshold, but the short-term packet loss rate exceeds the set threshold, WiFi link interference is determined. Conversely, it is determined that the uplink bandwidth at the remote end is insufficient; Analyze the FU-A fragment integrity of the IDR frame. If the FU-A fragment of the IDR frame is incomplete, mark the key frame as missing, and synchronously upload the relevant metadata of the abnormal flag frame, including the RTP sequence number and PTS timestamp.

3. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 1, characterized in that, The analysis of packet loss data in the forward and backward links using the Kamailio and RTPengine architecture specifically involves: During the call setup phase, when the Kamailio SIP agent receives the INVITE signaling, it automatically starts the media statistics service and automatically triggers the RTPengine's forward and reverse link statistics function for the audio and video media streams of this call. RTPengine caches and parses call RTP packets in real time, accumulating raw data for subsequent packet loss detection; During the call termination phase, after receiving the BYE signaling, RTPengine is triggered to terminate statistics and record the triggering time of various call signaling, providing basic call information for subsequent forward and reverse link packet loss judgment processes. Perform forward link packet loss detection and reverse link packet loss detection.

4. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 3, characterized in that, The forward link packet loss judgment specifically refers to: Analyze the RTP flow quality from the mobile terminal to the mid-screen terminal and check whether the packets received by the call service access layer are complete. If they are incomplete and the mid-screen terminal also reports an error, it is initially determined that the packet loss occurred on the public network uplink or the mobile terminal. Further correlation with signaling information is used to assist in the analysis of link performance.

5. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 3, characterized in that, The specific steps for determining packet loss on the reverse link are as follows: The RTP packet reception along the path from the middle screen, WiFi, AP to the call service access layer is analyzed. RTPengine monitors whether there are frequent interruptions or jitter anomalies in the packets sent by the middle screen. The stability of the WiFi link is inferred by combining the UDP inspection mechanism.

6. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 1, characterized in that, The specific process of integrating RTP statistics from the central screen and the call service access layer, constructing a packet loss path topology map, identifying the impact source, and triggering corresponding optimization suggestions is as follows: Receive RTP statistics from the middle screen terminal and the call service access layer, including packet loss rate and jitter count, and use RTP sequence number and PTS timestamp to confirm the continuity of data packets; Use a unified time base to synchronize the RTP statistics data of the middle screen terminal and the call service access layer on the time axis; Construct a packet loss path topology diagram, including three segments: forward link, backward link, and local link. The forward link is specifically: mobile terminal → public network → call service access layer. The backlink specifically consists of the call service access layer → public network → middle screen terminal, and the local link includes middle screen WiFi access and system decoding; Based on the RTP statistics of the mid-screen terminal and the call service access layer after time axis synchronization, the link responsibility of the packet loss path topology is determined, and corresponding optimization suggestion strategies are matched according to the link responsibility determination results.

7. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 6, characterized in that, The specific process for determining link responsibility is as follows: If packet loss occurs in both the upstream data of the call service access layer and the mid-screen device, the problem is determined to be on the mobile phone side or the uplink; if the downstream data of the call service access layer is normal but the mid-screen device is abnormal, the problem is determined to be on the WiFi link or the mid-screen device itself; the upstream direction is from the mobile phone to the call service access layer, and the downstream direction is from the call service access layer to the mid-screen device. If the statistical data is normal but the user experience is abnormal, further analysis of local system logs should be conducted to determine if it is a device performance bottleneck.

8. The quality segmentation and positioning detection system for mid-screen video calls as described in claim 6, characterized in that, The optimization suggestions include: prompting users to switch networks, automatically adjusting video bitrate or frame rate, switching between software and hardware decoding methods, and suggesting proximity to the router and enabling the 5G band on the router.

Images