A multi-protocol based video conference system network inspection method and device

Abstract

The application relates to the technical field of video communication, and discloses a multi-protocol-based network inspection method and equipment for a video conference system, wherein 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 service flow data after screening processing to the network topology structure to obtain a service transmission path; respectively performing threshold value judgment on service detection data and multi-protocol state data to determine the network stability mode of the video conference system; when the network stability mode is an unstable network, respectively determining an affected service transmission path and an unstable network cause, and acquiring 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 application can improve the evaluation accuracy of network faults of the video conference system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of video communication, in particular to a multi-protocol-based network inspection method and device for a video conference system. BACKGROUND

[0002] With the popularity of remote work and digital collaboration, video conference systems have become an indispensable key infrastructure for daily operations of enterprises and institutions. Ensuring the stable operation of large-scale, cross-regional video conference systems is of great significance to improving the efficiency of digital operations.

[0003] Currently, the network inspection technology for video conference systems usually relies on the combined use of multiple monitoring tools. The operation and maintenance personnel will use tools based on the SNMP protocol to poll the hardware status of switches and routers, obtain device layer indicators such as CPU utilization and port traffic, and at the same time, use Ping tools based on the ICMP protocol to detect the basic connectivity and delay between network nodes. In addition, specific HTTP ports of application services are also detected to determine whether the video conference application service is in a normal operating state and can be effectively accessed. This kind of separate monitoring method, although it can provide data in its own dimension, produces isolated and one-sided data points. When the video conference appears to be stuck or interrupted, the operation and maintenance personnel need to rely on personal experience to manually correlate and analyze between multiple independent monitoring tools, making it difficult to quickly and accurately locate the root cause of the fault. SUMMARY

[0004] In view of the defects of the existing network inspection technology that the single monitoring dimension and data fragmentation lead to difficulty in locating the root cause of the fault and the inability to accurately assess the impact on business, the present application provides a multi-protocol-based network inspection method and device for a video conference system.

[0005] In a first aspect, the embodiments of the present application provide a multi-protocol-based network inspection method for a video conference system, comprising:

[0006] Obtaining multi-protocol state data and device connection information of the video conference system, and constructing a network topology structure reflecting the health status of the video conference transmission link based on the multi-protocol state data and the device connection information;

[0007] Obtaining business flow data from the video conference system, and mapping the filtered business flow data to the network topology structure to obtain a business transmission path;

[0008] Simulating a video conference data transmission process based on the business transmission path to obtain business detection data reflecting the path transmission quality;

[0009] respectively, the service detection data and the multi-protocol state data are subjected to threshold judgment to determine the network stability mode of the video conference system;

[0010] When the network stability mode is unstable network, the affected service transmission path and the cause of unstable network are determined respectively, and change management data related to the affected service transmission path is obtained;

[0011] Based on the cause of unstable network, the affected service transmission path and the change management data, the network stability result of the video conference system is generated.

[0012] Preferably, the multi-protocol state data and device connection information of the video conference system are obtained, and a network topology reflecting the health status of the video conference transmission link is constructed based on the multi-protocol state data and the device connection information, comprising:

[0013] The multi-protocol state data of the video conference system is obtained through network monitoring, and the device connection information of the video conference system is obtained based on a preset discovery protocol;

[0014] Based on the device connection information, the connection relationship between devices of the video conference system is determined;

[0015] Based on the multi-protocol state data, the dynamic quality weight corresponding to the connection relationship between devices is determined in combination with a pre-constructed graph neural network model;

[0016] Based on the device connection information, the connection relationship between devices and the dynamic quality weight, a network topology reflecting the health status of the video conference transmission link is generated.

[0017] Preferably, based on the multi-protocol state data, the dynamic quality weight corresponding to the connection relationship between devices is determined in combination with a pre-constructed graph neural network model, comprising:

[0018] The network devices in the video conference system are defined as nodes, and the device connection relationship is defined as edges;

[0019] Based on the multi-protocol state data, a corresponding node feature vector is constructed for each node and a corresponding edge feature vector is constructed for each edge, wherein the node feature vector includes CPU utilization and memory utilization, and the edge feature vector includes port traffic and port packet error rate;

[0020] Each node feature vector and each edge feature vector is input into a pre-constructed graph neural network model for inference to obtain the dynamic quality weight corresponding to each edge.

[0021] Preferably, the acquiring the service flow data from the video conference system and mapping the filtered service flow data to the network topology to obtain the service transmission path comprises:

[0022] acquiring the service flow data from the video conference system through network flow collection analysis, wherein the service flow data comprises a target port number;

[0023] filtering the service flow data based on the target port number to obtain matching service flow data satisfying a video conference service flow determination condition, and adding a mark to the matching service flow data to obtain marked service flow data, wherein the video conference service flow determination condition comprises that the target port number is consistent with a video conference protocol exclusive port number;

[0024] mapping the marked service flow data to the network topology to obtain the service transmission path.

[0025] Preferably, the simulating the video conference data transmission process based on the service transmission path to acquire service probe data reflecting path transmission quality comprises:

[0026] deploying a probe agent on the service transmission path to simulate a video conference data transmission process of transmitting a probe data packet from a source end of the service transmission path to a destination end of the service transmission path;

[0027] calculating service probe data comprising end-to-end network delay, packet jitter and packet loss rate by comparing a timestamp and a sequence number of the probe data packet in the video conference data transmission process.

[0028] Preferably, the respectively performing threshold value judgment on the service probe data and the multi-protocol state data to determine the network stability mode of the video conference system comprises:

[0029] judging whether the service probe data satisfies a service quality (SLA) threshold condition to obtain a first determination result;

[0030] judging whether a difference between device layer data in the multi-protocol state data and a pre-constructed dynamic baseline satisfies a deviation condition to obtain a second determination result;

[0031] judging whether a difference between network quality data in the multi-protocol state data and the dynamic baseline satisfies a deviation condition to obtain a third determination result;

[0032] based on the first determination result, the second determination result and the third determination result, if there is at least one determination result that is satisfied, determining that the network stability mode of the video conference system is an unstable network.

[0033] Preferably, the process of constructing the dynamic baseline comprises:

[0034] Obtaining multi-protocol state historical data of the video conference system, and performing time series analysis on the multi-protocol state historical data to obtain trend characteristics and periodic characteristics;

[0035] Based on the trend characteristics, the periodic characteristics and the multi-protocol state historical data, determining a time series normal value range of the multi-protocol state historical data, and representing the time series normal value range as a dynamic baseline.

[0036] Preferably, when the network stability mode is unstable network, the affected service transmission path and the cause of unstable network are determined respectively, and change management data related to the affected service transmission path is obtained, including:

[0037] When the network stability mode is unstable network, the fault root node is found out, and the affected service transmission path is determined based on the fault root node;

[0038] In response to an application service probe request, it is detected whether there is application layer survival data in the video conference system, if there is the application layer survival data, it is determined that the cause of unstable network is network layer failure, otherwise it is determined that the cause of unstable network is application layer failure;

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

[0040] Preferably, the network stability result of the video conference system is generated based on the cause of unstable network, the affected service transmission path and the change management data, including:

[0041] The cause of unstable network, the affected service transmission path and the change management data are respectively weighted to obtain a first weight corresponding to the cause of unstable network, a second weight corresponding to the affected service transmission path and a third weight corresponding to the change management data;

[0042] The first weight, the second weight and the third weight are operated to obtain a fault risk score of the video conference system;

[0043] The fault risk score is compared with a threshold value to obtain a network stability result of the video conference system, wherein the network stability result includes potential risk, slight instability, main instability and serious instability.

[0044] In a second aspect, an embodiment of the present application provides a terminal device, comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, and the processor implements the multi-protocol-based video conference system network inspection method as described above when executing the computer program.

[0045] Compared with the prior art, the multi-protocol-based video conference system network inspection method and device has the following advantages:

[0046] (1) By acquiring multi-protocol state data covering device layer data and network quality data, combined with device connection information, the one-sidedness of single protocol data acquisition is avoided, and comprehensive and accurate data source support is provided for subsequent topology construction and stability analysis;

[0047] (2) The network topology reflecting the link health status is constructed based on the device connection information, not only the physical connection of the device is presented, but also the video conference exclusive service flow is filtered and mapped to the topology to generate a service transmission path, so that the isolated device node and the abstract data flow are integrated into a visual link, so that subsequent fault analysis does not need to traverse all devices, and the problem can be directly located along the service transmission path, and the fault locating efficiency is improved;

[0048] (3) While acquiring the static state of the device and the network by passive acquisition of multi-protocol state data, active simulation transmission based on the service transmission path is added to acquire service detection data. This detection method makes up for the deficiency of passive monitoring that only reflects the static state and cannot restore the real-time transmission experience of the service, so that the transmission quality evaluation is closer to the actual service scenario of the video conference;

[0049] (4) Threshold judgment is carried out on the service detection data and the multi-protocol state data respectively, the stability mode is determined through cross verification of the two-way data, and misjudgment of single dimension data is avoided; when it is determined that the network is unstable, not only the affected service transmission path and the cause of the unstable network are located, but also the change management data of the affected path is associated, and the finally generated network stability result is no longer a single unstable identifier, which is beneficial to greatly reduce the fault troubleshooting period and reduce the loss of video conference service interruption. BRIEF DESCRIPTION OF DRAWINGS

[0050] Figure 1 is a flowchart of a multi-protocol-based video conference system network inspection method according to an embodiment of the present application;

[0051] Figure 2 is a structural schematic diagram of a terminal device according to an embodiment of the present application;

[0052] REFERENCE NUMERALS:

[0053] 5000, terminal device; 5001, processor; 5002, bus; 5003, memory; 5004, transceiver. DETAILED DESCRIPTION

[0054] The specific embodiments of the present application will be further described in conjunction with the accompanying drawings and examples. The following examples are used to illustrate the present application, but not to limit the scope of the present application.

[0055] In the description of the present application, it should be understood that the terms "first" and "second" and the like in the present application are used to distinguish different objects, rather than to describe a specific order.

[0056] In the description of the present application, it should be noted that, unless otherwise defined, all technical and scientific terms used in the present application are the same as those commonly understood by those skilled in the art. The terms used in the specification of the present application are only for the purpose of describing the specific embodiments, and are not intended to limit the present application. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0057] As shown in Figure 1 , it is a flowchart of a network inspection method of a video conference system based on multiple protocols according to an embodiment of the present application. Referring to Figure 1 , a network inspection method of a video conference system based on multiple protocols according to an embodiment of the present application includes the following steps:

[0058] S1, obtaining multiple protocol state data and device connection information of the video conference system, and constructing a network topology structure reflecting the health state of the video conference transmission link based on the multiple protocol state data and the device connection information;

[0059] Specifically, step S1 includes:

[0060] 1) obtaining multiple protocol state data of the video conference system through network monitoring, and obtaining device connection information of the video conference system based on a preset discovery protocol;

[0061] The multiple protocol state data is collected by network monitoring means. This data is a heterogeneous data set that describes the health status of the network, including device layer data and network quality data. Among them, the device layer data focuses on the running state of the network device hardware, such as collecting indicators such as CPU utilization and memory consumption of the switch to reflect the running load and health degree of the device itself; the network quality data focuses on the performance of data transmission, such as collecting indicators such as round-trip delay time (RTT) and transmission packet loss rate to reflect the actual experience of data flow in network transmission. By obtaining the multiple protocol state data, necessary support is provided for subsequent accurate judgment of the overall running state of the network.

[0062] The device connection information is obtained through a preset discovery protocol, and the preset discovery protocol adopts a link layer discovery protocol (LLDP) or a Cisco discovery protocol (CDP). Specifically, a probe message is broadcast to devices in the network, and then a response message fed back by a neighbor device is listened to, and key information is extracted therefrom. Taking switch A as an example, after receiving the probe instruction, it will scan all physical ports, and if the GE0 / 1 port is connected to switch B, the neighbor device ID (Switch-B) and the opposite end port ID (GigabitEthernet0 / 5) will be reported in the response message. By periodically performing the collection process on all devices in the network, device connection information containing neighbor device ID, local and opposite end port ID is continuously obtained, providing original and reliable data materials for subsequent construction of the network topology of the connection relationship between devices.

[0063] 2) Determine the connection relationship between devices in the video conference system based on the device connection information;

[0064] The one-way device connection information collected in step 1) is cross-checked bidirectionally to finally determine the connection relationship between devices in the video conference system. Specifically, the device connection information collected from each device in step 1) is mostly one-way connection records (i.e., neighbor connection conditions from the perspective of a single device, such as only recording that the GE0 / 1 port of switch A is associated with the GE0 / 5 port of neighbor device B). Such one-way data may have 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 that the GE0 / 1 port of switch A is connected to the GE0 / 5 port of switch B, the system will automatically retrieve the device connection information collected from switch B to check whether the GE0 / 5 port of switch B also records the neighbor as the GE0 / 1 port of switch A. Only when the two one-way connection records are completely bidirectionally matched, the possibility of collection errors or false records can be excluded, and the existence of a real and effective connection relationship between switch A and switch B is finally confirmed.

[0065] Through the above bidirectional cross-checking mechanism, the dispersed one-way connection information can be integrated into an accurate device connection topology basis, avoiding errors in subsequent topology construction due to one-way data bias.

[0066] 3) Based on the multi-protocol state data, in combination with the pre-constructed graph neural network model, determine the dynamic quality weight corresponding to the connection relationship between devices;

[0067] Specifically, step 3) includes:

[0068] 31) Define the network devices in the video conference system as nodes, and define the device connection relationship as edges;

[0069] Each network device in the video conference system is defined as a node of a graph, and the connection relationship between the devices confirmed by the bidirectional check is defined as an edge of the graph, forming a basic graph topology framework.

[0070] 32) Based on the multi-protocol state data, a corresponding node feature vector is constructed for each node, and a corresponding edge feature vector is constructed for each edge.

[0071] The collected multi-protocol state data is subjected to feature extraction and structured processing, and a dedicated node feature vector (including device CPU utilization and memory utilization) is constructed for each node, and a dedicated edge feature vector (including port traffic and port packet error rate) is constructed for each edge.

[0072] 33) Each node feature vector and each edge feature vector is input into a pre-constructed graph neural network model for inference to obtain a dynamic quality weight corresponding to each edge.

[0073] Each node feature vector and each edge feature vector is input into a pre-constructed graph neural network model which is trained by a large amount of historical network data (including normal scene data and abnormal scene data). The model captures the associated features of nodes and edges, the topological dependency relationship between edges, and the mapping relationship between the features and quality weights learned from the historical data through inter-layer convolution operations for real-time inference. Finally, the model outputs a quantitative value for each edge in the graph, which is the dynamic quality weight reflecting the current comprehensive health level of the corresponding link.

[0074] 4) Based on the device connection information, the connection relationship between devices, and the dynamic quality weight, a network topology structure reflecting the health status of the video conference transmission link is generated.

[0075] Specifically, each network device in the video conference system is abstracted as a node of a graph, and the connection relationship between the devices confirmed by the bidirectional check is abstracted as an edge connecting the corresponding nodes, forming a static skeleton of the topology. The collected device connection information is associated, and the port identifier attribute corresponding to each edge is extracted, i.e. for the edge connecting the nodes, the local device port ID (such as GE0 / 1 of switch A) and the opposite device port ID (such as GE0 / 5 of switch B) are labeled, and the physical connection interface corresponding to the edge is determined, providing accurate identification for subsequent link positioning.

[0076] Further, the dynamic quality weight obtained by reasoning is integrated into the graph structure as a health state attribute of each edge, which quantifies the real-time comprehensive health level of the corresponding link (e.g., the higher the weight, the better the link transmission quality and the lower the failure risk); finally, by integrating nodes (devices), edges (connection relationships), and edge attributes (port ID and dynamic quality weight), a multi-dimensional topology data set is formed, which combines static physical connection relationships and dynamic health state indicators. The set is a network topology structure that can reflect the health state of the video conference transmission link in real time.

[0077] S2, obtaining service flow data from the video conference system, and mapping the service flow data after filtering to the network topology structure to obtain a service transmission path;

[0078] Specifically, step S2 includes:

[0079] 1) obtaining service flow data from the video conference system through network flow collection and analysis;

[0080] On the key network nodes of the video conference system, network probes can be used to actively listen to port traffic, or the original flow analysis function (such as sFlow, NetFlow) of the device can be enabled. For example, by using sFlow, video conference related data packets flowing through the device are captured in real time through preset sampling rules, and are converted into structured metadata records, i.e., service flow data.

[0081] Specifically, when video conference service communication is generated in the system, the key information of this communication is automatically extracted through network flow collection and analysis, including the source IP address identifying the source of the communication, the destination IP address identifying the target of the communication, and the target port number directly associated with the video conference service type, and these information is integrated into a complete service flow data.

[0082] 2) filtering the service flow data based on the target port number to obtain matching service flow data that meets the video conference service flow determination condition, and adding a label to the matching service flow data to obtain labeled service flow data;

[0083] The video conference service flow determination condition is constructed, including the exclusive port number strongly bound with the video conference protocol (such as the signaling port 1720 adapted to the H.323 protocol, the session port 5060 adapted to the SIP protocol, etc.), and the determination rule that the target port number is consistent with the protocol exclusive port number is determined.

[0084] For the full volume of service flow data collected in step 1), the "target port number" field in each piece of data is extracted one by one and compared with the protocol-specific port numbers in the judgment condition library. For example, when it is detected that the target port number of a piece of service flow data is 1720, it is determined that it meets the judgment condition of the H.323 protocol video conference service flow, and this piece of data is filtered as matching service flow data; while the target port number corresponds to web browsing (such as port 80) and file download (such as port 21) service flow data, it is excluded because it does not meet the judgment condition.

[0085] After the filtering is completed, a marking operation is performed on all matching service flow data to obtain marked service flow data. Specifically, a "service type identification" field is added to the structured field of each piece of data, and the "video conference" string is filled in as a special mark, so that the matching service flow data is clearly distinguished from other types of service flow data at the data level, avoiding confusion with non-conference service flow.

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

[0087] Specifically, from the marked service flow data, the key information directly related to path positioning is extracted, including the source IP address of the service flow (corresponding to the sending end device of the video conference service, such as a terminal device) and the destination IP address (corresponding to the receiving end device of the video conference service, such as a conference server), so as to determine the starting point and the end point of the path calculation.

[0088] Further, a path planning algorithm (such as Dijkstra algorithm, shortest path priority algorithm, etc.) is used, taking the source IP corresponding node as the starting point and the destination IP corresponding node as the end point, to traverse all reachable links in the network topology structure, and combining the dynamic quality weight of the edge (preferably selecting links with high health degree and low failure risk), to calculate the complete node sequence and corresponding connection links that need to be passed through from the source device to the destination device.

[0089] Finally, the complete node sequence and corresponding connection links calculated are visually highlighted in the network topology structure, forming a clear service transmission path.

[0090] S3, based on the service transmission path, simulating the video conference data transmission process to obtain service detection data reflecting the path transmission quality;

[0091] Specifically, step S3 includes:

[0092] 1) Deploy a detection agent program on the service transmission path to simulate the video conference data transmission process of transmitting a detection data packet from the source end of the service transmission path to the destination end of the service transmission path;

[0093] By deploying probe agents at key nodes of the service transmission path, the video conference data transmission process from the source end to the destination end is reproduced. Specifically, in the determined full link of the service transmission path, key nodes are selected to deploy probe agents, including the source end device of the path (such as the terminal device initiating the video conference), the destination end device (such as the MCU server receiving the conference data), and the main forwarding nodes (such as switches and routers) in the middle of the path, to ensure that the probe agents cover the complete link of the service stream transmission.

[0094] These probe agents are preset to simulate the transmission characteristics of real video conference data. The source end agent generates probe data packets consistent with the format of real video conference streams according to the typical packet sending frequency of video conference services, including encapsulating with RTP (Real-time Transport Protocol), carrying the same DSCP (Differentiated Services Code Point) mark as real conference streams, and embedding metadata such as timestamps and sequence numbers for subsequent performance calculation.

[0095] 2) By comparing the timestamps and sequence numbers of the probe data packets in the video conference data transmission process, service probe data containing end-to-end network latency, packet jitter, and packet loss rate are calculated.

[0096] The source end agent sends probe data packets along the service transmission path to the destination end, and the agent programs of the intermediate nodes are responsible for forwarding the data packets. The destination end agent program receives the data packets, calculates the end-to-end latency by comparing the sending timestamp with the receiving timestamp, calculates the jitter by analyzing the fluctuations of the data packet arrival intervals, and calculates the packet loss rate by counting the missing sequence numbers, forming service probe data containing end-to-end network latency, packet jitter, and packet loss rate.

[0097] S4, respectively, threshold judgment is carried out on the service probe data and the multi-protocol state data, and the network stability mode of the video conference system is determined;

[0098] Specifically, step S4 includes:

[0099] 1) Determine whether the service probe data meets the service quality SLA threshold condition to obtain a first determination result;

[0100] By comparing the service probe data with the service quality SLA threshold condition, a first determination result is obtained. The service quality SLA threshold condition is a performance index threshold preset based on the experience requirements of video conference services, including key indicators strongly related to conference smoothness, such as end-to-end latency upper limit, packet jitter upper limit, and packet loss rate upper limit. These thresholds are determined in combination with industry standards and actual business scenarios.

[0101] Extract real-time performance indicators (including real-time delay, actual jitter value, and measured packet loss rate) in service detection data and compare them one by one with the corresponding thresholds in the service quality SLA threshold conditions. If any indicator exceeds the threshold, it is determined that the service quality SLA threshold condition is not met. Finally, the comparison results of meeting or not meeting are recorded as the first determination result.

[0102] 2) Determine whether the difference between the device layer data in the multi-protocol state data and the pre-constructed dynamic baseline meets the deviation condition, and obtain the second determination result;

[0103] The pre-constructed dynamic baseline is not a fixed value, but a normal range that changes over time. Extract the device layer real-time data from the multi-protocol state data and calculate the difference between it and the dynamic baseline at the corresponding time point. Determine 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, it is not met (i.e., the device layer data is normal).

[0104] 3) Determine whether the difference between the network quality data in the multi-protocol state data and the dynamic baseline meets the deviation condition, and obtain the third determination result;

[0105] Extract the network quality real-time data from the multi-protocol state data and calculate the difference between it and the dynamic baseline at the corresponding time point. Determine 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., the network layer data is abnormal); otherwise, it is not met (i.e., the network layer data is normal).

[0106] It should be noted that the construction process of the dynamic baseline includes the following steps:

[0107] a) Obtain multi-protocol state historical data of the video conference system and perform time series analysis on the multi-protocol state historical data to obtain trend characteristics and periodic characteristics;

[0108] Collect multi-dimensional multi-protocol state historical data, including device layer historical data and network quality historical data. Pre-process the multi-protocol state historical data by data cleaning, missing value completion, and data standardization to eliminate noise interference and lay a foundation for high-quality data for time series analysis.

[0109] The time series decomposition algorithm is used to deeply analyze the preprocessed multi-protocol state historical data. On the one hand, the trend item decomposition is used to extract the trend characteristics, such as analyzing the overall change trend of the CPU utilization in three months. On the other hand, the seasonal item decomposition is used to extract the periodic characteristics, such as identifying the daily cycle rule of the CPU utilization, that is, the early morning peak (9:00-11:00) arrives, the afternoon falls, and the night (23:00-7:00) drops to the valley.

[0110] b) Based on the trend characteristics, the periodic characteristics, and the multi-protocol state historical data, the time series normal value range of the multi-protocol state historical data is determined, and the time series normal value range is characterized as a dynamic baseline.

[0111] Based on the trend characteristics, a trend prediction model is used to fit the multi-protocol state historical data, and the trend prediction value at any future time point is calculated. For example, for the CPU utilization, if the trend characteristic is a monthly average increase of 5%, and the historical data shows that the CPU utilization average at 10 o'clock on Monday last month is 55%, then the trend prediction value at the same time point this month is predicted to be 57.75% (55%+55%*5%=57.75%), reflecting the long-term change trend of the index.

[0112] The trend prediction value is dynamically corrected in combination with the periodic characteristics. Specifically, according to the period stage (such as "early morning peak" "night low load") to which the current time point belongs, the fluctuation offset of the stage is superimposed. For example, if the periodic characteristic shows that 10 o'clock on Monday is the early morning peak, and the CPU utilization is 5% higher than the same trend prediction value, then the trend prediction value 57.75% is corrected to 60.64% (57.75%+57.75%*5%=60.64%), so that the prediction value fits the periodical fluctuation rule and avoids deviating from the actual business load scenario.

[0113] The standard deviation of the multi-protocol state historical data is used, and the corrected trend prediction value is taken as the center to construct the time series normal value range. For example, if the CPU utilization standard deviation of the multi-protocol state historical data is 5%, then the normal value range is 60.64%±5%, that is, [55.64%, 65.64%]. This normal value range that is dynamically adjusted over time is the dynamic baseline that characterizes the normal fluctuation interval of the multi-protocol state data.

[0114] 4) Based on the first determination result, the second determination result, and the third determination result, if there is at least one determination result that is satisfied, it is determined that the network stability mode of the video conference system is unstable network.

[0115] When any one of the first determination result, the second determination result and the third determination result is satisfied, it is determined that the network stability mode of the video conference system is an unstable network, ensuring that any dimension of anomaly is not missed, and achieving comprehensive coverage of network problems.

[0116] S5, when the network stability mode is an unstable network, respectively determining an affected service transmission path and a cause of the unstable network, and obtaining change management data related to the affected service transmission path;

[0117] Specifically, step S5 includes:

[0118] 1) When the network stability mode is an unstable network, finding out a fault root node, and determining an affected service transmission path based on the fault root node;

[0119] Based on the abnormal data (such as device layer abnormal indicators in multi-protocol state data) obtained in the unstable network determination process, in combination with the association relationship between nodes and edges in the network topology structure, the fault root node causing the network instability is located through a fault tracing algorithm. For example, it is determined that the GE0 / 3 port of switch B causes forwarding abnormality due to hardware failure, and the switch B is the root node of the fault.

[0120] All active service transmission paths (i.e. paths carrying video conference services and having real-time data transmission, excluding idle or inactive paths) are called, which have been mapped to the network topology structure and marked as video conference exclusive service links. The node sequence of each active service transmission path is checked, and the path containing the fault root node is screened out. Finally, all the screened active service transmission paths containing the fault root node jointly constitute the affected service transmission path.

[0121] 2) In response to an application service detection request, detecting whether there is application layer survival data in the video conference system, if there is application layer survival data, determining that the cause of the unstable network is a network layer fault, otherwise determining that the cause of the unstable network is an application layer fault;

[0122] On the basis of locating the fault influence range (affected service transmission path and terminal), in order to avoid misjudging the application layer itself anomaly as a network layer fault, an application service detection request is actively initiated for the affected video conference terminal or server. The request is usually an HTTP or HTTPS protocol request, which is sent to a specific port of a lightweight proxy service deployed on the target device, with the purpose of detecting whether the application layer has normal response capability.

[0123] After sending the request, the video conference system receives the feedback state code from the target device and compares it with the preset state code (usually "200 OK" in the HTTP standard, which means that the application service successfully receives and processes the request and is the core identifier of the application layer survival).

[0124] If the feedback state code is the same as the preset state code (i.e., "200 OK" is returned), it indicates that the video conference application service itself is healthy and alive (there is application layer survival data), and at this time the network stability mode is unstable network problem, not from the application layer (such as application process crash, service not started), but the network layer carrying the application data transmission appears abnormal (such as link packet loss, node forwarding failure), so it is determined that the cause of unstable network is network layer failure.

[0125] If the feedback state code is different from the preset state code, it indicates that the video conference application service cannot normally respond to the request (there is no application layer survival data), even if the network layer transmission is normal, the application service itself is in an abnormal state (such as application process suspension, configuration error), so the cause of unstable network is determined to be application layer failure, excluding the interference of network layer factors.

[0126] 3) Obtain the change management data related to the network devices on the affected business transmission path within the preset time window before the failure occurs.

[0127] Specifically, the boundary conditions of the query are determined. On the one hand, the preset time window (such as 24 hours before the failure, ensuring to cover recent operations that may affect the failure) is set based on the time point of the failure; on the other hand, all network devices on the affected business transmission path are locked to clearly define the device objects that need to be queried.

[0128] Further, based on the above boundary conditions, a query request is initiated to the configuration management tool. If the device configuration change record (such as route strategy modification, port parameter adjustment) needs to be obtained, a query instruction is sent to the configuration management database (CMDB); if the device software / firmware upgrade log (such as switch system version update) needs to be obtained, a request is initiated to the version control system (Git) or operation and maintenance log platform, and finally all change management data related to the affected path devices within the preset time window are extracted, including but not limited to change time, change content, operator, and change device ID.

[0129] S6, based on the cause of unstable network, the affected business transmission path and the change management data, generate the network stability result of the video conference system.

[0130] Specifically, step S6 includes:

[0131] 1) Weight assignment is performed on unstable network cause, affected service transmission path and change management data respectively to obtain first weight corresponding to unstable network cause, second weight corresponding to affected service transmission path and third weight corresponding to change management data;

[0132] The weight assignment process of unstable network cause, affected service transmission path and change management data is described as follows:

[0133] 11) First weight corresponding to unstable network cause;

[0134] The first weight is determined according to fault level (network layer / application layer) and fault influence range. For example, core network layer fault (such as core switch forwarding exception, affecting all regional meetings) is given a first weight of 5 due to high repair difficulty and wide range of influence; access layer network fault (such as edge switch port fault, only affecting a single department meeting) is given a first weight of 2; in the application layer fault, service crash type fault (affecting all meetings dependent on the service) is given a first weight of 4, and application configuration error (only affecting part of the terminal) is given a first weight of 1.5. Through the two dimensions of fault level and influence range, the contribution of the fault to network instability is quantified to obtain the first weight.

[0135] 12) Second weight corresponding to affected service transmission path;

[0136] The second weight is determined based on service priority. For example, the path carrying VIP meeting is given a second weight of 10 due to high business importance; the path carrying internal department daily meeting is given a second weight of 3. Through the service priority, the difference in business loss after the path is affected is reflected to obtain the second weight.

[0137] 13) Third weight corresponding to change management data.

[0138] The third weight is determined in combination with the comprehensive suspiciousness score of the change record. For example, a high-risk change (such as modifying core routing strategy) with a comprehensive suspiciousness score of 90 points is given a third weight of 1.8; a low-risk change (such as modifying device description) with a comprehensive suspiciousness score of 40 points is given a third weight of 0.5. Through the association of the comprehensive suspiciousness score, the correlation degree between change management data and network instability is quantified to obtain the third weight.

[0139] It should be noted that the comprehensive suspiciousness score is calculated based on time, topology and semantic correlation, including:

[0140] In the time correlation dimension, the score is calculated based on the time decay function (such as exponential decay function or linear decay function) with the fault occurrence time as the benchmark. The shorter the interval between the change occurrence time and the fault occurrence time, the higher the time score, so as to highlight the potential impact of recent changes on the fault.

[0141] In the topology correlation dimension, the score is assigned according to the topological distance between the changed device and the fault path. If the changed device is directly located on the affected service transmission path (such as the core switch in the fault path), the highest score is given; if the changed device is one-hop neighbor of the device on the fault path (such as the access switch directly connected to the core switch), the second highest score is given, so as to focus on the degree of physical association between the change and the fault path.

[0142] In the semantic correlation dimension, the score is calculated by analyzing the risk attributes of the change content. High-risk operations (such as modifying core routing strategy, adjusting firewall access control list, updating device firmware version) are given high semantic scores because they directly affect the network transmission logic or device stability; low-risk operations (such as modifying device name, updating operation and maintenance contact information, adjusting device alarm threshold) are given low semantic scores because they have no significant impact on the core function of the network, accurately distinguishing the potential interference degree of the change content on the network stability.

[0143] Finally, according to the preset dimension weight proportion (such as time dimension accounting for 40%, topology dimension accounting for 30%, semantic dimension accounting for 30%), the scores of the three dimensions are weighted and summed to obtain the comprehensive suspiciousness score of each change record. The higher the score of the change record, the higher the association probability with the current network instability event, and then it is determined as a suspicious change event.

[0144] 2) Perform operation processing on the first weight, the second weight and the third weight to obtain a fault risk score of the video conference system;

[0145] Specifically, the first weight, the second weight and the third weight are multiplied to obtain the fault risk score of the video conference system.

[0146] 3) Perform threshold comparison on the fault risk score to obtain a network stability result of the video conference system.

[0147] By comparing the fault risk score with the preset three-level threshold value, and combining the corresponding operation and maintenance strategy of different risk levels, the network stability result of the video conference system is finally determined, including potential risk, slight instability, main instability and serious instability. Specifically, first, the preset three-level threshold value is determined as the judgment basis for risk classification; then the calculated fault risk score is compared with the threshold value, and each interval is determined according to the score. Among them, the three-level threshold value is set based on historical fault data and business tolerance, including the first threshold value of 20, the second threshold value of 50 and the third threshold value of 80.

[0148] If the fault risk score is lower than the first threshold value (for example, the fault risk score is 15), it is determined that the network stability result is potential risk. This scenario is mostly a combination of low-weight risk factors (such as non-critical equipment transient jitter, unassociated changes and only slight deviation from the dynamic baseline, and no impact on business paths), with low risk level, no need for real-time alarm, and only starting the baseline inspection strategy (such as performing basic data collection once every 30 minutes), which saves resources while ensuring monitoring coverage.

[0149] If the fault risk score is greater than the first threshold value and less than the second threshold value (for example, the fault risk score is 35), it is determined that the network stability result is slight instability. This scenario is mostly a local low-impact anomaly (such as a decrease in access layer link quality, affecting only part of the ordinary business path, with low fault type and business impact weight), which has formed a clear anomaly but the impact is limited, corresponding to a low-priority alarm, and at the same time triggering the inspection encryption operation (such as increasing the inspection frequency from the baseline to once every 10 minutes) for the affected business transmission path, closely monitoring the risk evolution.

[0150] If the fault risk score is greater than the second threshold value and less than the third threshold value (for example, the fault risk score is 65), it is determined that the network stability result is main instability. This scenario is mostly a high-impact fault (such as a medium-risk change causing a core device failure, resulting in a VIP conference business path interruption, with high business impact and fault type weight), which requires immediate intervention by the operation and maintenance personnel, corresponding to a high-priority alarm, and at the same time starting a high-priority response mode (such as increasing the inspection frequency to once every 1 minute, automatically calling change association analysis, real-time reasoning of graph neural network and other deep diagnosis processes), to obtain the most accurate root cause clues.

[0151] If the fault risk score is greater than a third threshold value (for example, the fault risk score is 90), it is determined that the network instability result is serious instability. This scenario is a high-weight risk factor superposition (for example, a high-risk core route change causes a core switch failure, affecting multiple VIP service paths, service impact, fault type, and change risk weight all reaching a high level), which will cause a serious interruption of critical services, trigger an emergency alarm (such as a phone or SMS notification), and simultaneously switch to the highest level of continuous monitoring mode (performing second-level detection on key devices on the core path), and trigger an emergency alarm escalation process to notify senior operation and maintenance personnel to intervene and handle the problem urgently.

[0152] The embodiment of the application provides a network inspection method based on a multi-protocol video conference system, which comprises the following steps: acquiring multi-protocol state data covering device layer data and network quality data, and combining device connection information to avoid one-sidedness of single protocol data acquisition, thereby providing a comprehensive and accurate data source support for subsequent topology construction and stability analysis; constructing a network topology reflecting the link health status based on the device connection information, not only presenting the physical connection of the device, but also filtering the video conference exclusive service flow and mapping the service transmission path to the topology, integrating the isolated device node and the abstract data flow into a visual link, so that subsequent fault analysis does not need to traverse all devices, and the problem can be directly located along the service transmission path, thereby improving the fault location efficiency; acquiring the device and network static state by passively collecting the multi-protocol state data, and acquiring the service detection data by newly adding active simulation transmission based on the service transmission path. This detection method makes up for the deficiency of passive monitoring in reflecting only the static state and being unable to restore the real-time transmission experience of the service, so that the transmission quality evaluation is closer to the actual service scenario of the video conference; threshold value judgment is carried out on the service detection data and the multi-protocol state data respectively, and the stability mode is determined through cross verification of the dual data, thereby avoiding misjudgment of single dimension data; when it is determined that the network is unstable, not only the affected service transmission path and the cause of the unstable network are located, but also the change management data of the affected path is associated, and finally the generated network stability result is no longer a single unstable identifier, which is beneficial to greatly reducing the fault troubleshooting period and reducing the interruption loss of the video conference service.

[0153] The embodiment of the application further provides a terminal device, which comprises:

[0154] a processor, a memory and a bus;

[0155] the bus is used for connecting the processor and the memory;

[0156] the memory is used for storing operation instructions;

[0157] the processor is used for executing the operation corresponding to the network inspection method based on the multi-protocol video conference system according to the operation instructions.

[0158] In an optional embodiment, a terminal device is provided, comprising Figure 2 As shown in the figure, Figure 2 The terminal device 5000 shown in the figure comprises a processor 5001 and a memory 5003. The processor 5001 and the memory 5003 are connected, for example, through a bus 5002. Optionally, the terminal device 5000 can further comprise a transceiver 5004. It should be noted that in actual applications, the transceiver 5004 is not limited to one, and the structure of the terminal device 5000 does not constitute a limitation on the embodiments of the present application.

[0159] The processor 5001 can be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules and circuits described in combination with the present disclosure. The processor 5001 can also be a combination of computing functions, such as one or more microprocessor combinations, DSP and microprocessor combinations, etc.

[0160] The bus 5002 can comprise a channel for transmitting information between the above-mentioned components. The bus 5002 can be a PCI bus or an EISA bus, etc. The bus 5002 can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 2 In the figure, only one thick line is used to represent the bus, but it does not mean that there is only one bus or only one type of bus.

[0161] The memory 5003 can be a ROM or other type of static storage device that can store static information and instructions, a RAM or other type of dynamic storage device that can store information and instructions, an EEPROM, a CD-ROM or other optical disk storage, an optical disk storage (including a compact disk, a laser disk, an optical disk, a digital versatile disk, a Blu-ray disk, etc.), a 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 capable of being accessed by a computer, but not limited thereto.

[0162] The memory 5003 is used to store application program codes for executing the scheme of the present application, and is controlled by the processor 5001 to execute. The processor 5001 is used to execute the application program codes stored in the memory 5003 to realize the content shown in any of the preceding method embodiments.

[0163] In summary, the embodiment of the application provides a network inspection method and device for a video conference system based on multiple protocols, which obtains multiple protocol state data covering device layer data and network quality data, combines device connection information, avoids one-sidedness of single protocol data collection, and provides comprehensive and accurate data source support for subsequent topology construction and stability analysis; a network topology reflecting link health status is constructed based on device connection information, not only physical connection of devices is presented, but also video conference exclusive service flow is filtered and mapped to a service transmission path, isolated device nodes and abstract data flow are integrated into a visual link, so that subsequent fault analysis does not need to traverse all devices, and problems can be directly located along the service transmission path, and fault location efficiency is improved; while obtaining static state of devices and networks by passive collection of multiple protocol state data, active simulation transmission based on the service transmission path is newly added to obtain service detection data. This detection method makes up for the deficiency of passive monitoring that only reflects static state and cannot restore real-time service transmission experience, so that transmission quality evaluation is closer to the actual service scenario of the video conference; threshold judgment is carried out on the service detection data and the multiple protocol state data respectively, and stability mode is determined through cross verification of the two-way data, so as to avoid misjudgment of single dimension data; when it is determined that the network is unstable, not only the affected service transmission path and the cause of the unstable network are located, but also the change management data of the affected path is associated, and finally the generated network stability result is no longer a single unstable identifier, which is beneficial to greatly reduce the fault troubleshooting period and reduce the loss of video conference service interruption.

[0164] Each of the embodiments in the specification is described in a progressive manner, and the same or similar parts of each of the embodiments can be referred to each other, and each of the embodiments mainly describes the difference from other embodiments. It should be noted that each of the technical features of the above embodiments can be combined arbitrarily, and in order to make the description simple, each of the technical features of the above embodiments is not described in all possible combinations, however, as long as the combination of the technical features does not exist contradictory, it should be considered as the scope of the description.

[0165] The above is only the preferred embodiment of the application, and it should be noted that for ordinary skilled in the art, without departing from the technical principles of the application, a number of improvements and replacements can be made, and these improvements and replacements should be considered as the protection scope of the application.

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. 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. The multi-protocol status data includes device usage status data and network status data of the video conferencing system. 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 relationship between the devices, and the dynamic quality weight, a network topology that reflects the health status of the video conferencing transmission link is generated. 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. The dynamic quality weight corresponding to each edge is configured to select a link with a healthy state that meets the requirements when traversing all reachable links in the network topology, and then calculate and generate a service transmission path from the source device to the destination device.

2. 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.

3. 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.

4. 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.

5. The network inspection method for a multi-protocol video conferencing system according to claim 4, 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.

6. 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.

7. 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.

8. 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 7.

Images