Video conference system network inspection method and device based on multiple protocols

Abstract

The invention relates to the technical field of video communication, and discloses a video conference system network inspection method and device based on multiple protocols. The method comprises the following steps: constructing a network topology structure reflecting the health state of a video conference transmission link based on multi-protocol state data and equipment connection information; mapping the screened service flow data to a network topology structure to obtain a service transmission path; threshold judgment is carried out on the service detection data and the multi-protocol state data, and a network stability mode of the video conference system is determined; when the network stability mode is an unstable network, respectively determining an affected service transmission path and an unstable network cause, and obtaining change management data related to the affected service transmission path; and generating a network stability result of the video conference system based on the unstable network cause, the affected service transmission path and the change management data. The evaluation accuracy of the network fault of the video conference system can be improved.

Description

Technical Field

[0001] This invention relates to the field of video communication technology, and in particular to a network inspection method and device for a multi-protocol video conferencing system. Background Technology

[0002] With the widespread adoption of remote work and digital collaboration, video conferencing systems have become an indispensable critical infrastructure for the daily operations of enterprises and organizations. Ensuring the stable network operation of large-scale, cross-regional video conferencing systems is of great significance for improving the efficiency of digital operations.

[0003] Currently, network inspection techniques for video conferencing systems typically rely on a combination of monitoring tools. Maintenance personnel use SNMP-based tools to poll the hardware status of switches and routers, obtaining device-level metrics such as CPU utilization and port traffic. Simultaneously, they use ICMP-based Ping tools to probe basic connectivity and latency between network nodes. Furthermore, they probe specific HTTP ports of application services to determine if the video conferencing application service is functioning correctly and is accessible. While this discrete monitoring approach provides data at each level, it produces isolated and fragmented data points. When video conferencing experiences buffering or interruptions, maintenance personnel must rely on personal experience to manually correlate and analyze data across multiple independent monitoring tools, making it difficult to quickly and accurately pinpoint the root cause of the problem. Summary of the Invention

[0004] To address the shortcomings of existing network inspection technologies, such as limited monitoring dimensions and fragmented data leading to difficulties in locating the root cause of faults and the inability to accurately assess the impact on business operations, this invention provides a network inspection method and device for a multi-protocol video conferencing system.

[0005] In a first aspect, embodiments of the present invention provide a network inspection method for a multi-protocol video conferencing system, comprising: Acquire multi-protocol status data and device connection information of the video conferencing system, and construct a network topology that reflects the health status of the video conferencing transmission link based on the multi-protocol status data and the device connection information; The service flow data is obtained from the video conferencing system, and the filtered service flow data is mapped to the network topology to obtain the service transmission path. Based on the service transmission path, simulate the video conferencing data transmission process and obtain service probe data reflecting the path transmission quality. The network stability mode of the video conferencing system is determined by performing threshold judgments on the service detection data and the multi-protocol status data respectively. When the network stability mode is unstable network, the affected service transmission paths and the causes of unstable network are determined respectively, and change management data related to the affected service transmission paths are obtained. Based on the causes of the unstable network, the affected service transmission paths, and the change management data, the network stability results of the video conferencing system are generated.

[0006] Preferably, the step of acquiring multi-protocol status data and device connection information of the video conferencing system, and constructing a network topology reflecting the health status of the video conferencing transmission link based on the multi-protocol status data and the device connection information, includes: The system obtains multi-protocol status data of the video conferencing system through network monitoring, and obtains device connection information of the video conferencing system based on a preset discovery protocol. Based on the device connection information, the inter-device connection relationships of the video conferencing system are determined; Based on the multi-protocol state data and combined with a pre-built graph neural network model, the dynamic quality weights corresponding to the inter-device connection relationships are determined. Based on the device connection information, the connection relationships between the devices, and the dynamic quality weights, a network topology that reflects the health status of the video conferencing transmission links is generated.

[0007] Preferably, determining the dynamic quality weights corresponding to the inter-device connection relationships based on the multi-protocol state data and a pre-built graph neural network model includes: The network devices in the video conferencing system are defined as nodes, and the device connection relationships are defined as edges; Based on the multi-protocol state data, a corresponding node feature vector and a corresponding edge feature vector are constructed for each node and each edge, respectively. The node feature vector includes CPU utilization and memory utilization, and the edge feature vector includes port traffic and port error rate. Each node feature vector and each edge feature vector are input into a pre-constructed graph neural network model for inference to obtain the dynamic quality weight corresponding to each edge.

[0008] Preferably, the step of acquiring service flow data from the video conferencing system and mapping the filtered service flow data to the network topology to obtain the service transmission path includes: Business flow data is obtained from the video conferencing system through network traffic collection and analysis, wherein the business flow data includes the target port number; Based on the target port number, the service flow data is filtered to obtain matching service flow data that meets the video conferencing service flow determination conditions, and the matching service flow data is marked to obtain marked service flow data. The video conferencing service flow determination conditions include that the target port number is consistent with the video conferencing protocol-specific port number. The marked service flow data is mapped to the network topology to obtain the service transmission path.

[0009] Preferably, the step of simulating video conferencing data transmission based on the service transmission path and obtaining service probe data reflecting the path transmission quality includes: Deploy a probe agent on the service transmission path to simulate the video conferencing data transmission process of transmitting probe data packets from the source end of the service transmission path to the destination end of the service transmission path; By comparing the timestamps and sequence numbers of the probe data packets during the video conferencing data transmission process, service probe data including end-to-end network latency, data packet jitter, and packet loss rate can be calculated.

[0010] Preferably, the step of determining the network stability mode of the video conferencing system by performing threshold judgments on the service probe data and the multi-protocol status data respectively includes: Determine whether the service detection data meets the service quality SLA threshold condition to obtain a first determination result; Determine whether the difference between the device layer data in the multi-protocol status data and the pre-built dynamic baseline meets the deviation condition to obtain a second determination result; Determine whether the difference between the network quality data in the multi-protocol status data and the dynamic baseline meets the deviation condition to obtain a third determination result; Based on the first determination result, the second determination result, and the third determination result, if at least one determination result is satisfied, then the network stability mode of the video conferencing system is determined to be an unstable network.

[0011] Preferably, the process of constructing the dynamic baseline includes: The system acquires historical data on the multi-protocol status of the video conferencing system and performs time-series analysis on the historical data to obtain trend and periodic characteristics. Based on the trend characteristics, the periodic characteristics, and the historical data of the multi-protocol status, the normal range of the time series of the historical data of the multi-protocol status is determined, and the normal range of the time series is characterized as a dynamic baseline.

[0012] Preferably, when the network stability mode is an unstable network, the affected service transmission path and the cause of the unstable network are determined respectively, and change management data related to the affected service transmission path is obtained, including: When the network stability mode is unstable, the root cause node of the fault is identified, and the affected service transmission path is determined based on the root cause node of the fault. In response to an application service probe request, the system detects whether there is application layer live data in the video conferencing system. If the application layer live data exists, the unstable network is determined to be caused by a network layer failure; otherwise, the unstable network is determined to be caused by an application layer failure. Obtain change management data related to network devices on the affected service transmission path within a preset time window before the fault occurs.

[0013] Preferably, generating the network stability result of the video conferencing system based on the causes of the unstable network, the affected service transmission paths, and the change management data includes: Weights are assigned to the causes of the unstable network, the affected service transmission paths, and the change management data to obtain a first weight corresponding to the causes of the unstable network, a second weight corresponding to the affected service transmission paths, and a third weight corresponding to the change management data. The first weight, the second weight, and the third weight are processed to obtain the fault risk score of the video conferencing system. The network stability results of the video conferencing system are obtained by comparing the fault risk scores with thresholds, wherein the network stability results include potential risk, slight instability, major instability and severe instability.

[0014] Secondly, embodiments of the present invention provide a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the network inspection method for a multi-protocol video conferencing system as described above.

[0015] Compared with existing technologies, the network inspection method and equipment for a multi-protocol video conferencing system according to embodiments of the present invention have the following advantages: (1) By acquiring multi-protocol status data covering device layer data and network quality data, and combining it with device connection information, the one-sidedness of single protocol data collection is avoided, providing comprehensive and accurate data source support for subsequent topology construction and stability analysis; (2) Based on the device connection information, a network topology reflecting the health status of the link is constructed. It not only presents the physical connection of the device, but also generates a service transmission path by filtering the video conferencing-specific service flow and mapping it to the topology. This integrates isolated device nodes and abstract data flow into a visualized link, so that subsequent fault analysis does not need to traverse all devices. Problems can be located directly along the service transmission path, which improves the efficiency of fault location. (3) While passively collecting multi-protocol status data to obtain the static status of devices and networks, an active simulated transmission based on the service transmission path is added to obtain service probe data. This probe method makes up for the shortcomings of passive monitoring, which only reflects the static status and cannot restore the real-time transmission experience of services, making the transmission quality assessment closer to the actual business scenario of video conferencing; (4) Threshold judgments are made for business probe data and multi-protocol status data respectively. Stability mode is determined by cross-validation of dual-path data to avoid misjudgment of single-dimensional data. When the network is determined to be unstable, not only are the affected business transmission paths and the causes of unstable networks located, but also the change management data of the affected paths are associated. The network stability result generated is no longer a single unstable indicator, which is conducive to significantly reducing the troubleshooting cycle and reducing the loss of video conferencing service interruption. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a network inspection method for a multi-protocol video conferencing system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a terminal device according to an embodiment of the present invention; Figure label: 5000, Terminal equipment; 5001, Processor; 5002, Bus; 5003, Memory; 5004, Transceiver. Detailed Implementation

[0017] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0018] In the description of this invention, it should be understood that the terms "first" and "second," etc., are used to distinguish different objects, rather than to describe a specific order.

[0019] In the description of this invention, it should be noted that, unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by those skilled in the art. The terminology used in this specification is for the purpose of describing specific embodiments only and is not intended to limit the invention. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0020] like Figure 1 The diagram shown is a flowchart illustrating a network inspection method for a multi-protocol video conferencing system according to an embodiment of the present invention. (Refer to...) Figure 1 This invention provides a network inspection method for a multi-protocol video conferencing system, comprising the following steps: S1. Obtain multi-protocol status data and device connection information of the video conferencing system, and construct a network topology that reflects the health status of the video conferencing transmission link based on the multi-protocol status data and device connection information; Specifically, step S1 includes: 1) Obtain multi-protocol status data of the video conferencing system through network monitoring, and obtain device connection information of the video conferencing system based on preset discovery protocols; Multi-protocol status data is collected through network monitoring methods. This data is a heterogeneous dataset characterizing network health, including device-level data and network quality data. Device-level data focuses on the hardware operating status of network devices, such as collecting metrics like CPU utilization and memory consumption of switches to reflect the device's own operating load and health level. Network quality data focuses on data transmission performance, such as collecting metrics like round-trip time (RTT) and packet loss rate to reflect the actual experience of data flow during network transmission. Acquiring multi-protocol status data provides necessary support for accurately assessing the overall network operating status.

[0021] Device connection information is obtained through a preset discovery protocol, which uses either the Link Layer Discovery Protocol (LLDP) or the Cisco Discovery Protocol (CDP). Specifically, probe messages are first broadcast to devices within the network, and then the response messages from neighboring devices are listened for, extracting key information. Taking switch A as an example, after receiving the probe command, it scans all physical ports. If port GE0 / 1 is connected to switch B, it will report the neighbor device ID (Switch-B) and the peer port ID (GigabitEthernet0 / 5) in the response message. By periodically performing this collection process on all devices within the network, device connection information containing neighbor device IDs, local and peer port IDs is continuously obtained, providing original and reliable data for subsequently building the network topology of inter-device connections.

[0022] 2) Determine the connection relationships between devices in the video conferencing system based on device connection information; The one-way device connection information collected in step 1) undergoes bidirectional cross-validation to ultimately determine the inter-device connection relationships within the video conferencing system. Specifically, the device connection information collected from each device in step 1) is mostly one-way connection records (i.e., neighbor connections from the perspective of a single device, such as only recording the connection between switch A's GE0 / 1 port and neighbor device B's GE0 / 5 port). This one-way data may contain collection errors or incomplete information. Therefore, for each one-way connection record, the connection information of the corresponding neighbor device is matched in reverse. For example, taking the connection between switch A and switch B as an example, after obtaining the one-way record of switch A's GE0 / 1 port connecting to switch B's GE0 / 5 port, the system automatically retrieves the device connection information collected from switch B to check if switch B's GE0 / 5 port also records its neighbor as switch A's GE0 / 1 port. Only when the two one-way connection records are completely bidirectionally matched will the possibility of collection errors or false records be eliminated, ultimately confirming a genuine and valid inter-device connection relationship between switch A and switch B.

[0023] Through the aforementioned bidirectional cross-validation mechanism, scattered one-way connection information can be integrated into an accurate device connection topology foundation, avoiding erroneous links in subsequent topology construction due to one-way data deviation.

[0024] 3) Based on multi-protocol state data and combined with a pre-built graph neural network model, determine the dynamic quality weights corresponding to the connection relationships between devices; Specifically, step 3) includes: 31) Define network devices in the video conferencing system as nodes, and define the device connection relationships as edges; Each network device in the video conferencing system is defined as a node in the graph, and the connections between devices confirmed by bidirectional verification are defined as edges in the graph, forming a basic graph topology framework.

[0025] 32) Based on multi-protocol state data, construct corresponding node feature vectors for each node and corresponding edge feature vectors for each edge; Feature extraction and structuring are performed on the collected multi-protocol state data to construct a unique node feature vector for each node (including device CPU utilization and memory utilization) and a unique edge feature vector for each edge (including port traffic and port error rate).

[0026] 33) Input the feature vector of each node and the feature vector of each side into the pre-built graph neural network model for inference to obtain the dynamic quality weights corresponding to each side.

[0027] The feature vectors of each node and each edge are input into a pre-built graph convolutional network model, which has been trained on a large amount of historical network data (including normal and abnormal scenario data). The model captures the association features between nodes and edges and the topological dependencies between edges through inter-layer convolution operations. It combines the mapping relationship between features learned from historical data training and quality weights for real-time inference. Finally, the model outputs a quantized value for each edge in the graph, which is the dynamic quality weight that reflects the current overall health level of the corresponding link.

[0028] 4) Based on device connection information, inter-device connection relationships, and dynamic quality weights, generate a network topology that reflects the health status of video conferencing transmission links.

[0029] Specifically, each network device in the video conferencing system is abstracted as a node in a graph, and the bidirectionally verified connections between devices are abstracted as edges connecting the corresponding nodes, forming a static skeleton of the topology. The collected device connection information is correlated, and the port identifier attribute corresponding to each edge is extracted. That is, for each edge connecting a node, its local device port ID (e.g., GE0 / 1 of switch A) and the remote device port ID (e.g., GE0 / 5 of switch B) are labeled, determining the physical connection interface corresponding to the edge and providing accurate identification for subsequent link location.

[0030] Furthermore, the dynamic quality weights obtained through inference are incorporated and added to the graph structure as health status attributes of each edge. These weight values ​​quantify the real-time comprehensive health level of the corresponding link (e.g., higher weights represent better link transmission quality and lower failure risk). Finally, by integrating nodes (devices), edges (connection relationships), and edge attributes (port ID and dynamic quality weights), a multi-dimensional topology data set that combines static physical connection relationships with dynamic health status indicators is formed. This set is the network topology structure that can reflect the health status of video conferencing transmission links in real time.

[0031] S2. Obtain service flow data from the video conferencing system, and map the filtered service flow data to the network topology to obtain the service transmission path; Specifically, step S2 includes: 1) Obtain business flow data from the video conferencing system through network traffic collection and analysis; At key network nodes in a video conferencing system, network probes can be used to actively monitor port traffic, or the device's native flow analysis functions (such as sFlow and NetFlow) can be enabled. For example, taking sFlow as an example, by setting preset sampling rules, video conferencing-related data packets flowing through the device can be captured in real time and converted into structured metadata records, i.e., business flow data.

[0032] Specifically, when video conferencing communication occurs in the system, key information of the communication is automatically extracted through network traffic collection and analysis, including the source IP address that identifies the source of the communication, the destination IP address that identifies the target of the communication, and the target port number that is directly associated with the video conferencing service type. This information is then integrated into a complete service flow data.

[0033] 2) Filter the service flow data based on the target port number to obtain matching service flow data that meets the judgment conditions of video conferencing service flow, and add a mark to the matching service flow data to obtain marked service flow data; Construct video conferencing service flow determination conditions, including dedicated port numbers strongly bound to the video conferencing protocol (such as signaling port 1720 adapted to the H.323 protocol, session port 5060 adapted to the SIP protocol, etc.), and determine the determination rules for the target port number to be consistent with the protocol's dedicated port number.

[0034] For the full volume of service flow data collected in step 1), the "target port number" field is extracted from each data entry and compared with the protocol-specific port numbers in the judgment condition library. For example, when the target port number of a service flow data entry is detected to be 1720, it is determined that it meets the judgment condition of H.323 protocol video conferencing service flow, and the data entry is filtered as matching service flow data; while service flow data with target port numbers corresponding to web browsing (e.g., port 80) and file download (e.g., port 21) are excluded because they do not meet the judgment condition.

[0035] After filtering, a tagging operation is performed on all matching business flow data to obtain tagged business flow data. Specifically, a "Business Type Identifier" field is added to the structured fields of each data entry, and the string "Video Conferencing" is filled in as a unique identifier. This makes the matching business flow data clearly distinguishable from other types of business flow data at the data level, avoiding confusion with non-conference business flows.

[0036] 3) Map the marked service flow data to the network topology to obtain the service transmission path.

[0037] Specifically, key information directly related to path location is extracted from the marked service flow data, including the source IP address of the service flow (corresponding to the sending device of the video conferencing service, such as the terminal device) and the destination IP address (corresponding to the receiving device of the video conferencing service, such as the conferencing server), in order to determine the starting point and ending point of the path calculation.

[0038] Furthermore, a path planning algorithm (such as Dijkstra's algorithm, shortest path first algorithm, etc.) is adopted to traverse all reachable links in the network topology, starting from the node corresponding to the source IP and ending at the node corresponding to the destination IP. Combined with the dynamic quality weight of the edges (prioritizing links with high health and low failure risk), the complete sequence of nodes and corresponding connecting links that need to be traversed from the source device to the destination device are calculated.

[0039] Finally, the calculated complete node sequence and corresponding connection links are visualized and highlighted in the network topology to form a clear service transmission path.

[0040] S3. Simulate the video conferencing data transmission process based on the service transmission path to obtain service probe data reflecting the path transmission quality; Specifically, step S3 includes: 1) Deploy a probe agent on the service transmission path to simulate the video conferencing data transmission process of transmitting probe data packets from the source end of the service transmission path to the destination end of the service transmission path; By deploying probe agents at key nodes in the service transmission path, the video conferencing data transmission process from the source to the destination is reproduced. Specifically, in the entire defined service transmission path, key nodes are selected to deploy probe agents, including the source devices (such as the terminal devices initiating the video conference), the destination devices (such as the MCU server receiving the conference data), and the main forwarding nodes in the path (such as switches and routers), ensuring that the probe agents cover the entire service flow transmission link.

[0041] These probing agents are pre-programmed to simulate the transmission characteristics of real video conferencing data. The source agent generates probing packets with the same format as the real video conferencing stream, based on the typical packet sending frequency of the video conferencing service. This includes encapsulation using RTP (Real-Time Transport Protocol), carrying the same DSCP (Differentiated Service Code Point) markers as the real conference stream, and embedding metadata such as timestamps and sequence numbers for subsequent performance calculations.

[0042] 2) By comparing the timestamps and sequence numbers of the probe data packets during the video conferencing data transmission process, service probe data including end-to-end network latency, data packet jitter, and packet loss rate can be calculated.

[0043] The source agent sends probe data packets to the destination along the service transmission path. The agent program at the intermediate node is responsible for forwarding the data packets. After receiving the data packets, the destination agent program calculates the end-to-end latency by comparing the sending timestamp and the receiving timestamp, calculates the jitter by analyzing the fluctuation of the data packet arrival interval, and calculates the packet loss rate by counting the missing sequence numbers, thus forming service probe data that includes end-to-end network latency, data packet jitter, and packet loss rate.

[0044] S4. Perform threshold judgments on the business probe data and multi-protocol status data respectively to determine the network stability mode of the video conferencing system; Specifically, step S4 includes: 1) Determine whether the business probe data meets the service quality SLA threshold conditions to obtain the first determination result; The first judgment result is obtained by comparing the business probing data with the service quality SLA threshold conditions. The service quality SLA threshold conditions are performance indicator thresholds pre-set based on the video conferencing business experience requirements, including key indicators strongly correlated with the smoothness of the meeting, such as the upper limit of end-to-end latency, the upper limit of data packet jitter, and the upper limit of packet loss rate. These thresholds are determined by combining industry standards and actual business scenarios.

[0045] Real-time performance metrics (including real-time latency, actual jitter, and measured packet loss rate) are extracted from the business probing data and compared one by one with the corresponding thresholds in the Service Quality Agreement (SLA) threshold conditions. If any metric exceeds the threshold, it is determined that the Service Quality Agreement (SLA) threshold conditions are not met. Finally, the comparison results of whether the conditions are met or not are recorded as the first determination result.

[0046] 2) Determine whether the difference between the device layer data and the pre-built dynamic baseline in the multi-protocol status data meets the deviation condition, and obtain the second determination result; The pre-built dynamic baseline is not a fixed value, but a normal range that changes over time. Real-time device-layer data is extracted from multi-protocol state data, and the difference between this data and the corresponding dynamic baseline at that time point is calculated. It is then determined whether the real-time data directly exceeds the baseline range. If the real-time data exceeds the baseline range, the second determination result is that the deviation condition is met (i.e., the device-layer data is abnormal); otherwise, the deviation condition is not met (i.e., the device-layer data is normal).

[0047] 3) Determine whether the difference between the network quality data and the dynamic baseline in the multi-protocol status data meets the deviation condition, and obtain the third judgment result; Real-time network quality data is extracted from multi-protocol state data, and the difference between the data and the dynamic baseline at the corresponding time point is calculated. It is then determined whether the real-time data directly exceeds the baseline range. If the real-time data exceeds the baseline range, the third determination result is that the deviation condition is met (i.e., network layer data is abnormal); otherwise, the deviation condition is not met (i.e., network layer data is normal).

[0048] It should be noted that the process of building a dynamic baseline includes the following steps: a) Obtain historical data of the multi-protocol status of the video conferencing system, and perform time-series analysis on the historical data of the multi-protocol status to obtain trend characteristics and periodic characteristics; Collect multi-dimensional, multi-protocol status historical data, including device-level historical data and network quality historical data. Preprocess the multi-protocol status historical data by data cleaning, missing value completion, and data standardization to eliminate noise interference, laying a high-quality data foundation for time-series analysis.

[0049] A time series decomposition algorithm is used to perform in-depth analysis on the preprocessed historical data of multi-protocol states. On the one hand, trend features are extracted through trend decomposition, such as analyzing the overall trend of CPU utilization over three months; on the other hand, periodic features are extracted through seasonal decomposition, such as identifying the daily cycle of CPU utilization: "peaking during the morning rush hour (9:00-11:00), falling back at noon, and reaching its lowest point at night (23:00-7:00)."

[0050] b) Based on trend characteristics, periodic characteristics, and historical data of multi-protocol status, determine the normal range of time series values ​​for historical data of multi-protocol status, and characterize the normal range of time series values ​​as a dynamic baseline.

[0051] Based on trend characteristics, a trend prediction model is used to fit historical data of multiple protocol states to calculate the trend prediction value at any future point in time. For example, for CPU utilization, if the trend characteristic is a monthly average increase of 5%, and historical data shows that the average CPU utilization at 10:00 AM on Monday of the same period last month was 55%, then the predicted trend value for the same period this month at that time is 57.75% (55% + 55% × 5% = 57.75%), reflecting the long-term trend of the indicator.

[0052] The trend forecast is dynamically adjusted by incorporating periodic characteristics. Specifically, based on the periodic phase to which the current time point belongs (e.g., "weekday morning peak" or "nighttime low load"), the fluctuation offset of that phase is added. For example, if periodic characteristics indicate that 10:00 AM on Monday is the morning peak, and the CPU utilization is 5% higher than the trend forecast, then the trend forecast of 57.75% is adjusted to 60.64% (57.75% + 57.75% × 5% = 60.64%), so that the forecast value conforms to the time-period fluctuation pattern and avoids deviating from the actual business load scenario.

[0053] By utilizing the standard deviation of historical multi-protocol status data and centering on the corrected trend forecast value, a normal range for the time series is constructed. For example, if the standard deviation of CPU utilization in historical multi-protocol status data is 5%, then the normal range is 60.64% ± 5%, i.e., [55.64%, 65.64%]. This dynamically adjusted normal range over time serves as the dynamic baseline characterizing the normal fluctuation range of multi-protocol status data.

[0054] 4) Based on the first determination result, the second determination result and the third determination result, if at least one determination result is satisfied, then the network stability mode of the video conferencing system is determined to be an unstable network.

[0055] If any one of the first, second, or third judgment results is satisfied, the network stability mode of the video conferencing system is determined to be an unstable network, ensuring that no anomaly in any dimension is overlooked and achieving comprehensive coverage of network problems.

[0056] S5. When the network stability mode is unstable network, determine the affected service transmission path and the cause of the unstable network, and obtain change management data related to the affected service transmission path. Specifically, step S5 includes: 1) When the network stability mode is unstable, find the root cause node of the fault and determine the affected service transmission path based on the root cause node; Based on the abnormal data obtained during the unstable network determination process (such as device-level abnormal indicators in multi-protocol status data), and combined with the association between nodes and edges in the network topology, the root cause node causing network instability is located through a fault tracing algorithm. For example, if it is determined that the GE0 / 3 port of switch B is experiencing forwarding abnormalities due to a hardware failure, then switch B is the root cause node of this fault.

[0057] The system retrieves all currently active service transmission paths (i.e., paths carrying video conferencing services and transmitting data in real time, excluding idle or inactive paths). These paths are mapped to the network topology and marked as dedicated video conferencing service links. The node sequence of each active service transmission path is traversed and checked to identify paths containing the root cause node of the fault. Finally, all the identified active service transmission paths containing the root cause node constitute the affected service transmission paths.

[0058] 2) In response to the application service probe request, check whether there is application layer live data in the video conferencing system. If there is application layer live data, determine that the unstable network is caused by a network layer failure; otherwise, determine that the unstable network is caused by an application layer failure. Having identified the scope of the fault (affected service transmission paths and terminals), to avoid misdiagnosing application-layer anomalies as network-layer faults, an application service probe request is proactively initiated for the affected video conferencing terminals or servers. This request is typically an HTTP or HTTPS request, directed to a specific port of a lightweight proxy service deployed on the target device, with the aim of detecting whether the application layer has normal responsiveness.

[0059] After the request is sent, the video conferencing system will receive the status code from the target device and compare it with the preset status code (usually the HTTP standard "200 OK", which represents that the application service has successfully received and processed the request and is the core identifier of the application layer's liveness).

[0060] If the feedback status code is the same as the preset status code (i.e., "200 OK" is returned), it indicates that the video conferencing application service itself is healthy and alive (there is application layer live data). At this time, the network stability mode is unstable. The problem is not caused by the application layer (such as application process crash, service not started), but by an anomaly in the network layer that carries application data transmission (such as link packet loss, node forwarding failure). Therefore, the cause of the unstable network is determined to be a network layer failure.

[0061] If the feedback status code is different from the preset status code, it indicates that the video conferencing application service cannot respond to the request normally (there is no application layer live data). Even if the network layer transmission is normal, the application service itself is in an abnormal state (such as application process suspension or configuration error). Therefore, the unstable network should be identified first as an application layer failure, and interference from network layer factors should be eliminated.

[0062] 3) Obtain change management data related to network devices on the affected service transmission path within a preset time window before the fault occurs.

[0063] Specifically, the boundary conditions for the query are determined by setting a preset time window (such as 24 hours before the fault to ensure coverage of operations that may affect the fault in the near future) based on the time of the fault occurrence. On the other hand, the scope is defined by the affected service transmission path, locking all network devices on the path and clarifying the device objects to be queried.

[0064] Furthermore, based on the aforementioned boundary conditions, a query request is initiated to the configuration management tool. If it is necessary to obtain device configuration change records (such as routing policy modifications or port parameter adjustments), a query command is sent to the Configuration Management Database (CMDB); if it is necessary to obtain device software / firmware upgrade logs (such as switch system version updates), a request is initiated to the version control system (Git) or the operation and maintenance log platform. Ultimately, all change management data directly related to the affected path devices within the preset time window are extracted, including but not limited to change time, change content, operator, and changed device ID.

[0065] S6. Based on the causes of unstable networks, affected service transmission paths, and change management data, generate network stability results for the video conferencing system.

[0066] Specifically, step S6 includes: 1) Assign weights to the causes of unstable networks, the affected service transmission paths, and the change management data to obtain the first weight corresponding to the causes of unstable networks, the second weight corresponding to the affected service transmission paths, and the third weight corresponding to the change management data. The following sections explain the causes of unstable networks, the affected service transmission paths, and the weighting process for change management data: 11) The first weight corresponding to the cause of unstable network; The first weight is determined based on the fault level (network layer / application layer) and the scope of its impact. For example, core network layer faults (such as abnormal forwarding of core switches, affecting conferences across the entire region) are assigned a first weight of 5 due to their high repair difficulty and wide impact; access layer network faults (such as edge switch port failures, affecting only a single department's conference) are assigned a first weight of 2; among application layer faults, service crashes (affecting all conferences relying on the service) are assigned a first weight of 4, and application configuration errors (affecting only some terminals) are assigned a first weight of 1.5. By quantifying the contribution of faults to network instability through both fault level and scope of impact, the first weight is obtained.

[0067] 12) The second weight corresponding to the affected service transmission path; The second weight is determined based on business priority. For example, the path carrying VIP meetings is assigned a second weight of 10 due to its high business importance, while the path carrying routine internal department meetings is assigned a second weight of 3. By using business priority, the difference in business loss after different paths are affected is reflected, thus obtaining the second weight.

[0068] 13) Change the third weight corresponding to the management data.

[0069] A third weight is determined by combining the overall suspicion score of the change records. For example, a high-risk change with an overall suspicion score of 90 (such as modifying core routing policies) is assigned a third weight of 1.8; a low-risk change with an overall suspicion score of 40 (such as modifying device descriptions) is assigned a third weight of 0.5. By correlating the overall suspicion scores, the degree of correlation between change management data and network instability is quantified, resulting in the third weight.

[0070] It should be noted that the overall suspiciousness score is calculated based on time, topology, and semantic relevance, including: In the time relevance dimension, the score is calculated using a time decay function (such as an exponential decay function or a linear decay function) based on the time of failure occurrence. The shorter the time interval between the change occurrence and the failure occurrence, the higher the time score, thus highlighting the potential impact of recent changes on failures.

[0071] In the topology relevance dimension, the score is assigned based on the topology distance between the changed device and the faulty path. If the changed device is directly located on the affected service transmission path (such as the core switch in the faulty path), it is given the highest score; if the changed device is a one-hop neighbor of the device on the faulty path (such as the access switch directly connected to the core switch), it is given the second highest score, thus focusing on the physical correlation between the change and the faulty path.

[0072] In terms of semantic relevance, the risk attributes of the changed content are scored by analyzing them. High-risk operations (such as modifying core routing policies, adjusting firewall access control lists, and updating device firmware versions) are given high semantic scores because they directly affect network transmission logic or device stability. Low-risk operations (such as modifying device names, updating maintenance contact information, and adjusting device alarm thresholds) are given low semantic scores because they have no significant impact on core network functions. This accurately distinguishes the potential interference of the changed content with network stability.

[0073] Finally, based on the preset dimensional weight ratios (e.g., time dimension accounts for 40%, topology dimension accounts for 30%, and semantic dimension accounts for 30%), the scores of the three dimensions are weighted and summed to obtain the comprehensive suspicion score of each change record. The higher the score of the change record, the higher the probability of its association with this network instability event, and thus it is given priority to be judged as a suspicious change event.

[0074] 2) Perform calculations on the first, second, and third weights to obtain the fault risk score of the video conferencing system; Specifically, the first weight, the second weight, and the third weight are multiplied together to obtain the fault risk score of the video conferencing system.

[0075] 3) The fault risk scores are compared with thresholds to obtain the network stability results of the video conferencing system.

[0076] By comparing the fault risk score with preset three-level thresholds across different risk levels, and combining this with corresponding operation and maintenance strategies for different risk levels, the network stability result of the video conferencing system is ultimately determined, including potential risk, minor instability, major instability, and severe instability. Specifically, the preset three-level thresholds are first determined as the basis for risk classification; then, the calculated fault risk scores are compared with the thresholds, and each score is judged according to its corresponding range. In this embodiment, the three-level thresholds are set based on historical fault data and business tolerance, including a first threshold of 20, a second threshold of 50, and a third threshold of 80.

[0077] If the fault risk score is lower than the first threshold (e.g., a fault risk score of 15), the network stability result is judged as a potential risk. This scenario often involves a combination of low-weight risk factors (e.g., momentary jitter in non-critical equipment, unrelated changes and only slight deviations from the dynamic baseline, without affecting business paths). The risk level is low, and real-time alarms are not required. Only a baseline inspection strategy is initiated (e.g., basic data collection is performed every 30 minutes), which saves resources while ensuring monitoring coverage.

[0078] If the fault risk score is greater than the first threshold but less than the second threshold (e.g., a fault risk score of 35), the network stability result is determined to be slightly unstable. This scenario is mostly a localized, low-impact anomaly (e.g., a decrease in access layer link quality, affecting only some ordinary service paths, with low weighting for both fault type and service impact). It constitutes a clear anomaly but has a limited impact, corresponding to a low-priority alarm. At the same time, an encrypted inspection operation is triggered for the affected service transmission paths (e.g., the inspection frequency is increased from the baseline to once every 10 minutes) to closely monitor the evolution of the risk.

[0079] If the fault risk score is greater than the second threshold but less than the third threshold (e.g., a fault risk score of 65), the network stability result is determined to be primarily unstable. This scenario often involves high-impact faults (e.g., a medium-risk change causing a core equipment failure, resulting in the interruption of the VIP meeting service path; both the service impact and fault type weights are high). Immediate intervention from operations personnel is required, along with corresponding high-priority alarms and the initiation of a high-priority response mode (e.g., increasing the inspection frequency to once every minute, automatically invoking deep diagnostic processes such as change correlation analysis and real-time graph neural network inference) to obtain the most accurate root cause clues.

[0080] If the fault risk score exceeds the third threshold (e.g., a fault risk score of 90), the network instability result is determined to be severely unstable. This scenario involves the superposition of multiple high-weight risk factors (e.g., a high-risk core route change causing a core switch failure, affecting multiple VIP service paths, with high weights for service impact, fault type, and change risk), which will cause severe interruption of critical services, triggering emergency alarms (e.g., telephone and SMS notifications). Simultaneously, it switches to the highest level of continuous monitoring mode (performing second-level detection of critical devices on core paths), triggering the emergency alarm escalation process, and notifying senior operations and maintenance personnel to intervene and handle the situation urgently.

[0081] This invention provides a network inspection method for a multi-protocol video conferencing system. By acquiring multi-protocol status data covering device layer data and network quality data, combined with device connection information, it avoids the limitations of single-protocol data collection, providing comprehensive and accurate data source support for subsequent topology construction and stability analysis. Based on device connection information, it constructs a network topology reflecting link health status, not only presenting physical device connections but also filtering video conferencing-specific service flows and mapping them to the topology to generate service transmission paths. This integrates isolated device nodes and abstract data flows into a visualized link, allowing subsequent fault analysis to directly locate problems along the service transmission path without traversing all devices, thus improving fault location efficiency. While passively acquiring multi-protocol status data to obtain the static status of devices and the network, it also adds active simulated transmission based on the service transmission path to obtain service probe data. This detection method overcomes the shortcomings of passive monitoring, which only reflects static states and cannot reproduce the real-time transmission experience of services. It makes the transmission quality assessment more closely resemble the actual business scenarios of video conferencing. Threshold judgments are performed on service detection data and multi-protocol status data respectively. Stability patterns are determined through cross-validation of dual-path data to avoid misjudgment based on single-dimensional data. When an unstable network is determined, not only are the affected service transmission paths and the causes of instability located, but also the change management data of the affected paths are associated. The final network stability result is no longer a single instability indicator, which helps to significantly reduce the troubleshooting cycle and reduce the loss of video conferencing service interruption.

[0082] This invention also provides a terminal device, which includes: Processor, memory, and bus; The bus is used to connect the processor and the memory; The memory is used to store operation instructions; The processor is configured to execute operations corresponding to the network inspection method for a multi-protocol video conferencing system described above by invoking the operation instructions.

[0083] In one alternative embodiment, a terminal device is provided, such as Figure 2 As shown, Figure 2 The terminal device 5000 shown includes a processor 5001 and a memory 5003. The processor 5001 and the memory 5003 are connected, for example, via a bus 5002. Optionally, the terminal device 5000 may also include a transceiver 5004. It should be noted that in practical applications, the transceiver 5004 is not limited to one type, and the structure of this terminal device 5000 does not constitute a limitation on the embodiments of the present invention.

[0084] Processor 5001 may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in connection with this disclosure. Processor 5001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0085] Bus 5002 may include a path for transmitting information between the aforementioned components. Bus 5002 may be a PCI bus or an EISA bus, etc. Bus 5002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 2 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0086] The memory 5003 may be a ROM or other type of static storage device capable of storing static information and instructions, RAM or other type of dynamic storage device capable of storing information and instructions, or it may be an EEPROM, CD-ROM or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0087] The memory 5003 is used to store application code that executes the present invention, and its execution is controlled by the processor 5001. The processor 5001 is used to execute the application code stored in the memory 5003 to implement the content shown in any of the foregoing method embodiments.

[0088] In summary, the present invention provides a network inspection method and device for a multi-protocol video conferencing system. By acquiring multi-protocol status data covering device layer data and network quality data, combined with device connection information, it avoids the limitations of single-protocol data collection, providing comprehensive and accurate data source support for subsequent topology construction and stability analysis. The network topology constructed based on device connection information reflects the health status of links, not only presenting physical device connections, but also integrating isolated device nodes and abstract data flows into a visualized link by filtering video conferencing-specific service flows and mapping them to the topology to generate service transmission paths. This allows subsequent fault analysis to directly locate problems along the service transmission path without traversing all devices, improving fault location efficiency. While passively acquiring multi-protocol status data to obtain the static status of devices and the network, it also adds active simulated transmission based on the service transmission path to obtain service probe data. This detection method overcomes the shortcomings of passive monitoring, which only reflects static states and cannot reproduce the real-time transmission experience of services. It makes the transmission quality assessment more closely resemble the actual business scenarios of video conferencing. Threshold judgments are performed on service detection data and multi-protocol status data respectively. Stability patterns are determined through cross-validation of dual-path data to avoid misjudgment based on single-dimensional data. When an unstable network is determined, not only are the affected service transmission paths and the causes of instability located, but also the change management data of the affected paths are associated. The final network stability result is no longer a single instability indicator, which helps to significantly reduce the troubleshooting cycle and reduce the loss of video conferencing service interruption.

[0089] The various embodiments in this specification are described in a progressive manner. For directly identical or similar parts of the various embodiments, refer to each other. Each embodiment focuses on its differences from other embodiments. It should be noted that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as these combinations of technical features do not contradict each other, they should be considered within the scope of this specification.

[0090] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and substitutions can be made without departing from the technical principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A network inspection method for a multi-protocol video conferencing system, characterized in that, include: Acquire multi-protocol status data and device connection information of the video conferencing system, and construct a network topology that reflects the health status of the video conferencing transmission link based on the multi-protocol status data and the device connection information; The service flow data is obtained from the video conferencing system, and the filtered service flow data is mapped to the network topology to obtain the service transmission path. Based on the service transmission path, simulate the video conferencing data transmission process and obtain service probe data reflecting the path transmission quality. The network stability mode of the video conferencing system is determined by performing threshold judgments on the service detection data and the multi-protocol status data respectively. When the network stability mode is unstable network, the affected service transmission paths and the causes of unstable network are determined respectively, and change management data related to the affected service transmission paths are obtained. Based on the causes of the unstable network, the affected service transmission paths, and the change management data, the network stability results of the video conferencing system are generated.

2. The network inspection method for a multi-protocol video conferencing system according to claim 1, characterized in that, The step of acquiring multi-protocol status data and device connection information of the video conferencing system, and constructing a network topology reflecting the health status of the video conferencing transmission link based on the multi-protocol status data and the device connection information, includes: The system obtains multi-protocol status data of the video conferencing system through network monitoring, and obtains device connection information of the video conferencing system based on a preset discovery protocol. Based on the device connection information, the inter-device connection relationships of the video conferencing system are determined; Based on the multi-protocol state data and combined with a pre-built graph neural network model, the dynamic quality weights corresponding to the inter-device connection relationships are determined. Based on the device connection information, the connection relationships between the devices, and the dynamic quality weights, a network topology that reflects the health status of the video conferencing transmission links is generated.

3. The network inspection method for a multi-protocol video conferencing system according to claim 2, characterized in that, The determination of dynamic quality weights corresponding to the inter-device connection relationships based on the multi-protocol state data and a pre-built graph neural network model includes: The network devices in the video conferencing system are defined as nodes, and the device connection relationships are defined as edges; Based on the multi-protocol state data, a corresponding node feature vector and a corresponding edge feature vector are constructed for each node and each edge, respectively. The node feature vector includes CPU utilization and memory utilization, and the edge feature vector includes port traffic and port error rate. Each node feature vector and each edge feature vector are input into a pre-constructed graph neural network model for inference to obtain the dynamic quality weight corresponding to each edge.

4. The network inspection method for a multi-protocol video conferencing system according to claim 1, characterized in that, The step of acquiring service flow data from the video conferencing system and mapping the filtered service flow data to the network topology to obtain the service transmission path includes: Business flow data is obtained from the video conferencing system through network traffic collection and analysis, wherein the business flow data includes the target port number; Based on the target port number, the service flow data is filtered to obtain matching service flow data that meets the video conferencing service flow determination conditions, and the matching service flow data is marked to obtain marked service flow data. The video conferencing service flow determination conditions include that the target port number is consistent with the video conferencing protocol-specific port number. The marked service flow data is mapped to the network topology to obtain the service transmission path.

5. The network inspection method for a multi-protocol video conferencing system according to claim 1, characterized in that, The process of simulating video conferencing data transmission based on the service transmission path, and obtaining service probe data reflecting the path transmission quality, includes: Deploy a probe agent on the service transmission path to simulate the video conferencing data transmission process of transmitting probe data packets from the source end of the service transmission path to the destination end of the service transmission path; By comparing the timestamps and sequence numbers of the probe data packets during the video conferencing data transmission process, service probe data including end-to-end network latency, data packet jitter, and packet loss rate can be calculated.

6. The network inspection method for a multi-protocol video conferencing system according to claim 1, characterized in that, The step of determining the network stability mode of the video conferencing system by performing threshold judgments on the service detection data and the multi-protocol status data respectively includes: Determine whether the service detection data meets the service quality SLA threshold condition to obtain a first determination result; Determine whether the difference between the device layer data in the multi-protocol status data and the pre-built dynamic baseline meets the deviation condition to obtain a second determination result; Determine whether the difference between the network quality data in the multi-protocol status data and the dynamic baseline meets the deviation condition to obtain a third determination result; Based on the first determination result, the second determination result, and the third determination result, if at least one determination result is satisfied, then the network stability mode of the video conferencing system is determined to be an unstable network.

7. The network inspection method for a multi-protocol video conferencing system according to claim 6, characterized in that, The process of constructing the dynamic baseline includes: The system acquires historical data on the multi-protocol status of the video conferencing system and performs time-series analysis on the historical data to obtain trend and periodic characteristics. Based on the trend characteristics, the periodic characteristics, and the historical data of the multi-protocol status, the normal range of the time series of the historical data of the multi-protocol status is determined, and the normal range of the time series is characterized as a dynamic baseline.

8. The network inspection method for a multi-protocol video conferencing system according to claim 1, characterized in that, When the network stability mode is unstable, the affected service transmission paths and the causes of the unstable network are determined, and change management data related to the affected service transmission paths is obtained, including: When the network stability mode is unstable, the root cause node of the fault is identified, and the affected service transmission path is determined based on the root cause node of the fault. In response to an application service probe request, the system detects whether there is application layer live data in the video conferencing system. If the application layer live data exists, the unstable network is determined to be caused by a network layer failure; otherwise, the unstable network is determined to be caused by an application layer failure. Obtain change management data related to network devices on the affected service transmission path within a preset time window before the fault occurs.

9. The network inspection method for a multi-protocol video conferencing system according to claim 1, characterized in that, The process of generating network stability results for the video conferencing system based on the causes of network instability, the affected service transmission paths, and the change management data includes: Weights are assigned to the causes of the unstable network, the affected service transmission paths, and the change management data to obtain a first weight corresponding to the causes of the unstable network, a second weight corresponding to the affected service transmission paths, and a third weight corresponding to the change management data. The first weight, the second weight, and the third weight are processed to obtain the fault risk score of the video conferencing system. The network stability results of the video conferencing system are obtained by comparing the fault risk scores with thresholds, wherein the network stability results include potential risk, slight instability, major instability and severe instability.

10. A terminal device, characterized in that, The method includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the network inspection method for a multi-protocol video conferencing system as described in any one of claims 1 to 9.

Images