A fault handling method and system for voice call testing

Abstract

The present invention provides a fault handling method and system for voice call testing, belonging to the technical field of communication network operation and maintenance, including: receiving a fault request from a signaling system; identifying the fault type of the fault request within a preset cache period, and merging and compressing the fault requests of the same fault type; determining the first fault request in the merged set, and performing a route tracing operation on the destination IP on the primary and standby data communication device switches corresponding to the source IP of the first fault request to obtain the current network status information; judging whether there are routing anomalies and latency anomalies according to the current network status information and historical network status information; determining the fault type according to the comparison result, and generating real-time alarm information; within a preset time period, sending the real-time alarm information to the management personnel terminal. The present invention realizes the rapid and accurate processing of a large number of fault requests in a short time through real-time route tracing, historical alarm comparison, and latency anomaly detection.

Description

Technical Field

[0001] The present invention relates to the technical field of communication network operation and maintenance, and in particular to a fault handling method and system for voice dialing. Background Art

[0002] With the continuous expansion of telecommunications networks and the increasing complexity of services, the rapid discovery and location of network equipment faults has become a major challenge in operations and maintenance. Currently, fault detection in telecommunications networks primarily relies on device-specific alarm information and performance logs. However, these alarms are numerous and dispersed, making it difficult to quickly locate the root cause of a fault. In large-scale networks, in particular, a large number of fault requests may be generated in a short period of time. Traditional technologies, which rely on polling and retrieving historical alarms, are inefficient and cannot meet the "150" operational and maintenance timeline requirement (i.e., reporting a fault within 1 minute, locating it within 5 minutes, and restoring it within 10 minutes). Furthermore, existing technologies typically perform separate network status checks (such as ping and tracing) on each fault request. This results in significant system resource utilization and response latency when large-scale faults occur within a short period of time. Frequent logins to datacom equipment can even impact switch performance. Furthermore, existing technologies lack effective mechanisms for merging and compressing fault requests, resulting in redundant processing of numerous duplicate requests, further increasing system burden. These issues not only reduce fault location efficiency but can also delay the resolution of critical faults, impacting service continuity and user experience.

[0003] Therefore, how to quickly and accurately handle large-scale fault requests in a short period of time has become a technical problem that needs to be solved urgently. Summary of the Invention

[0004] The present invention provides a voice dialing fault processing method, system, electronic device and storage medium, which are used to solve the defects in the existing technology and realize rapid and accurate processing of large-scale fault requests in a short time.

[0005] The present invention provides a method for troubleshooting voice dialing, comprising the following steps:

[0006] Receive a fault request from a signaling system, wherein the fault request includes a source IP address and a destination IP address;

[0007] Identifying the fault type of the fault request within a preset cache period, and merging and compressing the fault requests of the same fault type to obtain a merged set;

[0008] Determine the first fault request in the merged set, and perform a route tracing operation on the destination IP address on the primary and backup data communication device switches corresponding to the source IP address of the first fault request to obtain current network status information;

[0009] Based on the current network status information and historical network status information, determine whether there are routing anomalies and latency anomalies;

[0010] Determine the fault type according to the comparison result, and generate real-time alarm information including the fault type, the source IP, and the destination IP;

[0011] Within a preset time period, send the real-time alarm information to the manager's terminal.

[0012] According to a fault handling method for voice call testing provided by the present invention, the current network status information includes the current network connectivity status and the current latency value; performing a route trace operation on the destination IP on the main and standby data communication device switches corresponding to the source IP of the first fault request to obtain the current network status information specifically includes:

[0013] Determine the current network connectivity status according to the route trace result, where the route trace result is obtained after performing a route trace operation on the destination IP on the main and standby data communication device switches;

[0014] When it is determined that the current network connectivity status is a connected state, obtain the current latency value.

[0015] According to a fault handling method for voice call testing provided by the present invention, the determining the current network connectivity status according to the route trace result specifically includes:

[0016] When it is determined that the route trace result is that the destination IP address can be reached, or there is no interruption node in the route trace result, determine that the current network connectivity status is a connected state;

[0017] When it is determined that the route trace result is that the destination IP address cannot be reached, or there is an interruption node in the route trace result, determine that the current network connectivity status is a disconnected state.

[0018] According to a fault handling method for voice call testing provided by the present invention, the determining whether there are routing anomalies and latency anomalies according to the current network status information and historical network status information specifically includes:

[0019] When it is determined that the current network connectivity status is a non-connected state, determine that there is a routing anomaly;

[0020] When it is determined that the current network connectivity status is a connected state, for each current routing node in the current network status information, find the corresponding historical routing node from the historical network status information;

[0021] Calculate the latency difference between the current latency value of each current routing node and the historical latency value of the corresponding historical routing node;

[0022] When any one of the time delay differences is greater than a preset time delay threshold, it is determined that there is a time delay anomaly.

[0023] According to a fault handling method for voice call testing provided by the present invention, the method further includes:

[0024] When the number of the fault requests is greater than a preset first number, concurrent processing is performed on the real-time routing trace instruction and the periodic routing trace instruction initiated by the signaling system on the main and standby multi-communication device switches, wherein the priority of the real-time routing trace instruction is higher than that of the periodic routing trace instruction.

[0025] According to a fault handling method for voice call testing provided by the present invention, the method further includes:

[0026] Map the source IP and the destination IP to the corresponding network element names through a pre-established service IP and network element correspondence table;

[0027] Retrieve in a preset historical alarm database according to the network element names to obtain historical alarm data;

[0028] Generate a link for viewing the routing trace operation and the historical alarm data;

[0029] Add the link to the real-time alarm information.

[0030] The present invention further provides a fault handling system for voice call testing, including the following modules:

[0031] A receiving module, configured to receive a fault request from a signaling system, where the fault request includes a source IP and a destination IP;

[0032] A processing module, configured to identify a fault type for the fault request within a preset cache period, and merge and compress the fault requests of the same fault type to obtain a merged set;

[0033] The processing module is further configured to determine the first fault request in the merged set, and perform a routing trace operation on the destination IP on the main and standby multi-communication device switches corresponding to the source IP of the first fault request to obtain current network status information;

[0034] The processing module is further configured to determine whether there is a routing anomaly and a time delay anomaly according to the current network status information and historical network status information;

[0035] An alarm generation module, configured to determine a fault type according to a comparison result, and generate real-time alarm information including the fault type, the source IP, and the destination IP;

[0036] An alarm sending module, configured to send the real-time alarm information to the terminal of the management personnel within a preset time period.

[0037] The present invention further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the fault handling method of voice call testing as described in any one of the above is implemented.

[0038] The present invention further provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the fault handling method of voice call testing as described in any one of the above is implemented.

[0039] The present invention further provides a computer program product, including a computer program. When the computer program is executed by a processor, the fault handling method of voice call testing as described in any one of the above is implemented.

[0040] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0041] By receiving a fault request from a signaling system and extracting the source IP and destination IP, the accurate triggering and preliminary positioning of network faults are realized; by identifying the fault type of the fault request within a preset cache period and merging and compressing requests of the same type, the amount of redundant alarm processing is significantly reduced, avoiding system resource waste and response delay caused by a large number of repeated requests in a short time; by preferentially determining the first fault request in the merge set and performing a routing trace operation on the primary and standby data communication device switches corresponding thereto, the real-time status detection of the core fault path is focused, ensuring the priority and efficiency of network diagnosis; by comparing and analyzing the current network status information with historical data for the routing jump node delay and path integrity, abnormal fluctuations or interruptions are quickly identified, improving the accuracy and timeliness of fault judgment; by dynamically generating real-time alarm information including specific fault types, source IPs, and destination IPs based on the comparison results, clear and operable data support is provided for management personnel; by pushing the alarm information to the terminal within a preset time period, the operation and maintenance time limit requirements are strictly met, and large-scale fault requests are quickly and accurately processed in a short time. Description of the Drawings

[0042] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0043] Figure 1 It is one of the schematic flowcharts of the fault handling method for voice call testing provided by the present invention.

[0044] Figure 2 It is the second schematic flowchart of the fault handling method for voice call testing provided by the present invention.

[0045] Figure 3 It is the third schematic flowchart of the fault handling method for voice call testing provided by the present invention.

[0046] Figure 4 It is the fourth schematic flowchart of the fault handling method for voice call testing provided by the present invention.

[0047] Figure 5 It is the schematic structural diagram of the fault handling system for voice call testing provided by the present invention.

[0048] Figure 6 It is the schematic structural diagram of the electronic device provided by the present invention. Detailed implementation manners

[0049] To make the objectives, technical solutions and advantages of the present invention clearer, the technical solutions in the present invention will be clearly and completely described below with reference to the accompanying drawings in the present invention. Apparently, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present invention without any creative efforts shall fall within the protection scope of the present invention.

[0050] It should be noted that in the description of the present invention, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article or device. Without further limitations, the element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element. The orientation or positional relationship indicated by the terms "upper", "lower", etc. is based on the orientation or positional relationship shown in the accompanying drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the system or element referred to must have a specific orientation, be constructed and operate in a specific orientation, and thus cannot be construed as a limitation of the present invention. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0051] The terms "first", "second", etc. in the present invention are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present invention can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same category, and do not limit the number of objects. For example, the first object can be one or more. In addition, "and / or" means at least one of the connected objects, and the character " / " generally indicates an "or" relationship between the associated objects before and after.

[0052] The following will combine Figures 1 - 6 to describe the fault handling method, system, electronic device and storage medium provided by the present invention for voice call testing.

[0053] Figure 1 is one of the schematic flowcharts of the fault handling method for voice call testing provided by the present invention, as Figure 1 shown, including but not limited to the following steps:

[0054] Step 101: Receive a fault request from the signaling system, where the fault request includes the source IP and the destination IP.

[0055] In this embodiment, in order to achieve rapid reception and processing of fault information, the system first receives a fault request from the signaling system in step 101, and this fault request carries keyword fields such as the source IP and the destination IP. The reason for setting this reception link in the system is that the signaling system provides a data interface based on the RESTful protocol, and ensures the security and timeliness of data transmission by restricting the IP address of the calling party and configuring the HTTPHeader format.

[0056] Specifically, when the system is deployed, it will make the request address (such as "http: / / IP address: port / nexwise_faultLocation / faultAlarmInfo") public to the signaling system according to the pre-written interface document, and set the constraint of transmitting data in JSON format, ensuring that the system can quickly parse fields such as "source IP", "destination IP", "request serial number", "fault occurrence time point" in the fault request through the HTTP POST method, and map them to the data structure required for the subsequent processing flow. Since the RESTful interface is adopted, when the signaling system pushes the fault information in the form of a JSON message, the system can encrypt and authenticate sensitive data in the parsing link, and perform performance scheduling for high-concurrency scenarios, ensuring that the fault request will not be blocked or lost due to the influx of a large number of requests in a short time.

[0057] Through such a design, step 101 not only ensures real-time intercommunication with the signaling system, but also lays a data foundation for subsequent identification of fault types for fault requests, execution of route tracing operations, and generation of real-time alarm information, thereby capturing service anomalies and dispatching orders within minutes. The final effect is that any fault request from the signaling system can be accurately and quickly received and parsed, and the entire system can obtain key fields immediately when facing large-scale network failures, and then initiate a series of actions such as merging and compressing, route tracing, and alarm reporting, accelerating the efficiency of fault location and recovery.

[0058] Step 102: Identify the fault type of the fault request within a preset cache period, and merge and compress the fault requests of the same fault type to obtain a merged set.

[0059] In step 102, in order to handle a large number of possible fault requests in a short period of time and ensure the performance of rapid alarm reporting, the system pre-sets a cache period for identifying the fault type of the received fault requests and implementing merging and compression.

[0060] Specifically, when the system receives multiple fault requests with the same source IP or destination IP, or belonging to the same network category within the cache period, it will first identify the fault type of these fault requests according to key features (such as the attributes of the source network element or destination network element). After confirming that they belong to the same or similar fault types, all fault requests of the same type are merged into a "first fault request" to form a merged set.

[0061] The reason for this is that if route tracing and alarm dispatching are performed separately for each fault request, the system will consume a large amount of resources and may also delay the timely reporting of faults. By merging and compressing requests of the same fault type within the cache period, the repeated route tracing operations (i.e., trace operations, where trace in subsequent embodiments represents route tracing) and multiple dispatching processes can be significantly reduced, accelerating the fault detection link and optimizing the overall efficiency of alarm handling. The final effect is that the merged set only needs to perform further route tracing and historical alarm retrieval on the first fault request, ensuring the timeliness of alarm reporting within one minute and avoiding performance waste caused by repeated processing in high-concurrency scenarios.

[0062] Step 103: Determine the first fault request in the merged set, and perform a route tracing operation on the destination IP on the primary and standby data communication device switches corresponding to the source IP of the first fault request to obtain the current network status information.

[0063] In step 103, the reason for "determining the first fault request in the merged set and performing a route trace operation on the destination IP on the primary and standby data communication device switches corresponding to the source IP of the first fault request" is that after the merging and compression of the fault requests, only the first fault request can truly reflect the earliest and most representative abnormal situation in the merged set. Doing so can avoid repeatedly performing the trace operation on multiple fault requests of the same type.

[0064] In a possible implementation manner, refer to Figure 2 , Figure 2 which is the second schematic diagram of the process of the fault handling method for voice call testing provided by the present invention. As Figure 2 shown, step 103 specifically includes steps 201 - 202:

[0065] Step 201: Determine the current network connectivity status according to the route trace result, where the route trace result is obtained after performing a route trace operation on the destination IP on the primary and standby data communication device switches.

[0066] In step 201, the reason for determining the current network connectivity status according to the route trace result is to judge whether there is a link interruption or other abnormalities in the first time, which is convenient for rapid fault troubleshooting and timely warning.

[0067] In a possible implementation manner, step 201 specifically includes the following steps:

[0068] When it is determined that the route trace result is that the destination IP address can be reached, or there is no interruption node in the route trace result, determine that the current network connectivity status is the connected status.

[0069] When it is determined that the route trace result is that the destination IP address cannot be reached, or there is an interruption node in the route trace result, determine that the current network connectivity status is the disconnected status.

[0070] Specifically, after the system completes the route trace instruction, it will sequentially detect each hop from the source IP to the destination IP and obtain the IP address and delay information of each hop; if the target address can be finally reached and there is no " " or other unresolvable interruption nodes during this process, the system will mark the current network connectivity status as the connected status, otherwise it is judged as the disconnected status. The effect of doing so is that the system can accurately identify the network status in the shortest time. Once it is found that the route trace result shows that the target address cannot be reached or there is an interruption node, it can provide a key basis for analyzing route anomalies and delay anomalies in the subsequent steps, so as to meet the operation and maintenance requirements of fault reporting and location within the minute level.

[0071] Step 202: When it is determined that the current network connectivity status is the connected state, obtain the current latency value.

[0072] In step 202, only when it is determined that the current network connectivity status is the connected state, the system will obtain the current latency value from the route tracing result. The reason is that when the link is reachable, it is necessary to further evaluate the transmission performance of the reachable path in order to compare with historical latency data in subsequent processes to determine whether there is an anomaly. The specific approach is to parse the trace output executed by the primary and standby data communication device switches, extract the latency information of each hop node from the source IP to the destination IP, and record or archive these latency values according to the timestamp. By obtaining and saving the current latency value in this way, the system can compare it with the previous historical latency point by point in the next step. Once a large abnormal increment is found, it can quickly issue a warning or trigger a fault alarm, so as to timely capture potential high-latency risks even when the network connectivity is still normal, providing an important basis for subsequent rapid fault troubleshooting and service restoration.

[0073] Step 104: Based on the current network status information and historical network status information, determine whether there are routing anomalies and latency anomalies.

[0074] In step 104, the reason why the system determines whether there are routing anomalies and latency anomalies based on the current network status information and historical network status information is that a single route tracing result alone cannot comprehensively evaluate the network health. It is necessary to combine the historical route nodes and latency data within adjacent time periods to accurately identify possible performance degradation or link failures.

[0075] In a possible implementation manner, refer to Figure 3 , Figure 3 is the third schematic diagram of the process of the fault handling method for voice call testing provided by the present invention. As Figure 3 shown, step 104 specifically includes steps 301 - 304:

[0076] Step 301: When it is determined that the current network connectivity status is the non-connected state, determine that there is a routing anomaly.

[0077] In step 301, the reason why the core network integrated network management system directly determines that there is a routing anomaly when it is determined that the current network connectivity status is the non-connected state is that one of the core objectives of service call testing is to quickly identify faults that affect user communication. The loss of network connectivity usually means a network path interruption or device anomaly, and it is necessary to immediately trigger an alarm and enter the fault location process.

[0078] Specifically, after the system executes the trace operation, it will analyze the path information returned by the trace. If it is found that the destination IP is unreachable, or at a certain hop node, there is " If there is no "reachable" identifier, it is immediately determined that the current network connectivity status is a disconnected status, and this fault request is marked as a routing exception. In addition, to ensure the accuracy of the judgment, the system will also compare the historical trace records to confirm whether this path was once in a reachable state, so as to exclude misjudgments caused by short-term congestion or policy changes. Such a design enables the system to identify whether a serious fault has occurred in the network core node in the shortest possible time, quickly report an alarm, avoid the business interruption caused by connectivity problems from lasting too long, improve the overall operation and maintenance efficiency, and at the same time provide a reliable basis for fault classification for subsequent steps to ensure that different types of faults can be accurately processed and restored in a timely manner.

[0079] Step 302: When it is determined that the current network connectivity status is a connected status, for each current routing node in the current network status information, find the corresponding historical routing node from the historical network status information.

[0080] In step 302, the main reason why the core network integrated network management system needs to find the corresponding historical routing node for each current routing node in the current network status information from the historical network status information when the current network connectivity status is a connected status is to further analyze whether the network path has changed under the condition of maintaining connectivity, so as to detect potential abnormal situations and provide a comparison benchmark for subsequent delay analysis.

[0081] Specifically, when the system determines that the target IP is reachable, it will find the corresponding historical routing node in the historical routing result table according to the list of current routing nodes in the trace result, and perform a hop-by-hop comparison according to the matching rules to ensure the consistency of the current network path and the historical path; if it is found that some nodes do not exist in the historical trace or the node order has changed, the system will mark these nodes as possible abnormal path changes and store the comparison result for use in subsequent delay analysis.

[0082] Through such a design, the system can not only discover potential path drift problems when the connectivity is normal, but also ensure the accuracy of the comparison in the subsequent delay calculation link, avoid misjudgments caused by network path changes, thereby improving the overall accuracy of fault identification, providing more accurate decision-making basis for operation and maintenance personnel, and ensuring network stability and business continuity.

[0083] Step 303: Calculate the delay difference between the current delay value of each current routing node and the historical delay value of the corresponding historical routing node.

[0084] In step 303, the core network integrated network management system calculates the delay difference between the current delay value of each current routing node and the historical delay value of the corresponding historical routing node in order to further evaluate whether there are abnormal fluctuations in the transmission quality of the path when the network is still connected, so as to achieve rapid identification of high-delay faults.

[0085] Specifically, after completing the matching of the current routing node and the historical routing node, the system will extract the delay data of each current routing node one by one, find the delay value of the corresponding historical routing node, calculate the difference between the two, and store the calculation result for subsequent comparison; during the calculation process, the system will not only pay attention to the delay changes of individual nodes, but also compare the cumulative delay on the entire path to determine whether there is a trend of overall performance degradation. The effect of doing this is that even if the network path remains reachable, the system can still accurately detect whether the delay is abnormal due to factors such as link congestion, device load, or network policy adjustment, so as to discover potential service quality degradation problems in advance, provide accurate data support for subsequent alarm triggering and operation and maintenance optimization, and ensure the stability and efficiency of the core network.

[0086] Step 304: When any one of the delay differences is greater than the preset delay threshold, it is determined that there is a delay anomaly.

[0087] In step 304, the core network integrated network management system immediately determines that there is a delay anomaly when it detects that any one of the delay differences is greater than the preset delay threshold because a simple network connectivity judgment is not sufficient to fully reflect the severity of the fault. It is necessary to combine the delay changes to detect potential network performance degradation to ensure rapid identification and alarm triggering of high-delay problems.

[0088] Specifically, after the system completes the calculation of the delay difference between the current routing node and the historical routing node, it will compare the delay increment of each node with the preset delay threshold. If the delay difference of any node exceeds this threshold, the system will determine that there is a delay anomaly in this path and mark the abnormal node and the corresponding delay change situation in the fault record for subsequent processing. To prevent misjudgment, the system can also perform trend analysis by combining data from multiple historical periods to ensure that the identified delay anomaly is a continuous fluctuation rather than an anomaly caused by short-term jitter or measurement error.

[0089] Such a design enables the system to accurately capture the potential trend of service quality degradation even when the network is still reachable, providing more comprehensive network status information for operation and maintenance personnel, so that preventive measures can be taken before the occurrence of faults, optimizing network scheduling, and improving the overall communication quality and service reliability.

[0090] Step 105: Determine the fault type based on the comparison result and generate real-time alarm information including the fault type, source IP, and destination IP.

[0091] In Step 105, the core network integrated network management system determines the fault type based on the comparison result and generates real-time alarm information including the fault type, source IP, and destination IP because relying solely on single network connectivity or latency analysis cannot comprehensively reflect the severity and impact scope of the fault. It is necessary to comprehensively consider various detection indicators for precise classification in order to trigger the corresponding alarm handling process more quickly.

[0092] Specifically, after completing the comparison of the current network status information and historical network status information, the system first determines whether the current fault belongs to routing anomaly or latency anomaly based on the judgment results of Steps 301 to 304, and further combines requests of the same fault type in the merge set to analyze whether the fault is an isolated event or belongs to a large-scale fault trend. If the fault type meets the determination criteria of "1510 scenario fault", "1510 scenario large-scale fault", or "packet domain registration failure", alarm information is generated in a preset format, and keyword fields such as the fault type, source IP, and destination IP are attached to the alarm content to ensure that the operation and maintenance personnel can quickly understand the specific situation of the fault.

[0093] The effect of this is that the system can not only accurately classify the fault at the first moment of its occurrence and meet the requirement of reporting the alarm within one minute, but also effectively distinguish the impact scope at the service level, avoiding additional processing delays caused by false alarms or missed alarms, providing an efficient and reliable basis for subsequent alarm push, fault handling, and automatic order assignment.

[0094] Step 106: Send the real-time alarm information to the manager's terminal within a preset time period.

[0095] In Step 106, the core network integrated network management system sends the real-time alarm information to the manager's terminal within a preset time period because simply completing the determination of the fault type and generating the alarm information is not sufficient to achieve the goal of rapid fault response. It is necessary to ensure that the alarm information can be accurately delivered to the duty personnel within the specified time to meet the operation and maintenance requirement of "reporting the alarm within one minute".

[0096] Specifically, after the system generates the alarm information in step 105, it will immediately trigger the alarm push mechanism. According to the severity and type of the fault, it will determine the transmission path and priority of the alarm to ensure that high-risk faults can be prioritized for dispatching and processing. The system will call the interface of the centralized alarm system to transmit the alarm information containing key fields such as fault type, source IP, destination IP, and request serial number, and append the network connectivity, latency change, and historical alarm comparison results calculated in the previous steps to the alarm content so that the management personnel can quickly grasp the detailed situation of the fault. At the same time, to improve the efficiency of fault handling, the system will also map the alarm information to the operation and maintenance duty terminal and append links for querying historical alarms and routing trace results, enabling the operation and maintenance personnel to click on the links to view the detailed information immediately upon receiving the alarm and even directly execute one-click emergency operations.

[0097] This design not only ensures that the alarm information can reach the relevant maintenance personnel in the shortest time after the fault occurs, but also avoids the response delay caused by manual retrieval and secondary confirmation, greatly improving the automation and intelligence level of fault handling and providing strong support for subsequent rapid disposal, impact assessment, and service restoration.

[0098] In a possible implementation manner, the method further includes the following steps:

[0099] When the number of fault requests is greater than a preset first number, the real-time routing trace instruction and the periodic routing trace instruction initiated by the signaling system are concurrently processed on the main and standby data communication device switches, where the priority of the real-time routing trace instruction is higher than that of the periodic routing trace instruction.

[0100] In this step, the reason why the core network integrated network management system needs to concurrently process the real-time routing trace instruction and the periodic routing trace instruction initiated by the signaling system on the main and standby data communication device switches when the number of fault requests is greater than a preset first number and ensure that the priority of the real-time routing trace instruction is higher than that of the periodic routing trace instruction is mainly to efficiently complete the network status detection in a large-scale fault scenario in a short time and avoid the system response delay caused by single-threaded execution of the routing trace instruction, which affects the timeliness of alarms and the operation and maintenance efficiency.

[0101] Specifically, when the system detects that the number of fault requests within the same time window exceeds the preset threshold, it will trigger the high-concurrency routing tracing scheduling mechanism and dynamically adjust the execution strategy of the routing tracing instructions, enabling the real-time fault requests of the signaling system to preferentially call the main and standby data communication device switches for routing tracing operations. The regularly configured routing tracing instructions within the system will enter the queue with a lower priority, ensuring that operation and maintenance personnel can obtain key network status information in the shortest possible time. To avoid overloading the switch devices, when concurrently executing routing tracing instructions, the system will also adopt a load balancing strategy, execute routing tracing for different network elements in batches, and store the results in the routing result table after completing each routing tracing instruction for subsequent comparison and analysis.

[0102] With such a design, the system can simultaneously handle the efficient processing of batch fault requests under the requirement of minute-level fault reporting, ensuring that even during a large-scale fault outbreak, the detection of the core network status can still remain efficient and stable, improving the overall operation and maintenance response speed, and reducing the impact of faults on service testing and user experience.

[0103] In a possible implementation manner, referring to Figure 4 , Figure 4 is the fourth flowchart of the fault handling method for voice testing provided by the present invention. As Figure 4 shown, the method further includes steps 401 - 404:

[0104] Step 401: Map the source IP and destination IP to the corresponding network element names through the pre-established business IP and network element correspondence table.

[0105] Step 402: Retrieve in the preset historical alarm database according to the network element names to obtain historical alarm data.

[0106] Step 403: Generate a link for viewing routing tracing operations and historical alarm data.

[0107] Step 404: Add the link to the real-time alarm information.

[0108] In steps 401 to 404, the core network integrated network management system realizes the rapid mapping from the source IP and destination IP to the network element names through the pre-established business IP and network element correspondence table, further retrieves historical alarm data to enhance the accuracy of fault judgment, and simultaneously generates a visual alarm information link to provide a convenient traceability analysis means for maintenance personnel.

[0109] In step 401, when the system receives a fault request, it uses the service IP and network element correspondence table to find the specific network element names to which the source IP and destination IP belong. Such a design can compensate for the limitations of directly retrieving historical alarm data based on IP because the historical alarm data of the core network integrated network management system is stored by network element dimension rather than IP dimension. Only by first completing the mapping from IP to network element can relevant alarm information be efficiently matched.

[0110] In step 402, based on the obtained source IP network element name and destination IP network element name, the system enters the preset historical alarm database, retrieves the alarm data from 24 hours before the alarm occurrence time point to 15 minutes after, and archives the query results for subsequent comparison analysis and alarm information display; this process ensures that even if a certain network element does not have real-time alarms currently, potential fault patterns or fluctuation anomalies can be discovered based on historical trends.

[0111] In step 403, to improve the fault handling efficiency of maintenance personnel, the system dynamically generates a visual access link for each alarm information. This link can jump to the alarm details page, including the current trace result, historical alarm comparison situation, and key network metrics, to support the operation and maintenance personnel for in-depth analysis and traceability verification.

[0112] In step 404, while pushing the alarm information to the centralized alarm system, the system attaches the generated access link to the alarm content, enabling the maintenance personnel to quickly obtain the complete historical alarms and trace analysis results by clicking the link after receiving the fault dispatch order, avoiding the time loss caused by manual retrieval, thereby improving the alarm response speed and fault handling efficiency. Through this complete processing link, the system completes the full process from IP parsing, historical alarm matching, result archiving to visual alarm pushing within one minute, making the fault location more accurate and the operation and maintenance operations more efficient, effectively supporting the intelligent and automated development of core network operation and maintenance.

[0113] Refer to Figure 5 , Figure 5 is a schematic structural diagram of the fault handling system for voice call testing provided by the present invention. The system includes:

[0114] A receiving module, configured to receive a fault request from a signaling system, where the fault request includes a source IP and a destination IP;

[0115] A processing module, configured to identify the fault type of the fault request within a preset cache period, and merge and compress the fault requests of the same fault type to obtain a merged set;

[0116] The processing module is further configured to determine the first fault request in the merging set, and perform a route tracing operation on the destination IP on the primary and standby data communication device switches corresponding to the source IP of the first fault request to obtain the current network status information;

[0117] The processing module is further configured to judge whether there are routing anomalies and latency anomalies according to the current network status information and the historical network status information;

[0118] The alarm generation module is configured to determine the fault type according to the comparison result, and generate real-time alarm information including the fault type, source IP, and destination IP;

[0119] The alarm sending module is configured to send the real-time alarm information to the management personnel terminal within a preset time period.

[0120] In a possible implementation manner, the processing module is further configured to:

[0121] According to the route tracing result, determine the current network connectivity status, where the route tracing result is obtained after performing a route tracing operation on the destination IP on the primary and standby data communication device switches;

[0122] When it is determined that the current network connectivity status is a connected state, obtain the current latency value.

[0123] In a possible implementation manner, the processing module is further configured to:

[0124] When it is determined that the route tracing result is that the destination IP address can be reached, or there is no interruption node in the route tracing result, determine that the current network connectivity status is a connected state;

[0125] When it is determined that the route tracing result is that the destination IP address cannot be reached, or there is an interruption node in the route tracing result, determine that the current network connectivity status is a disconnected state.

[0126] In a possible implementation manner, the processing module is further configured to:

[0127] When it is determined that the current network connectivity status is a non-connected state, determine that there is a routing anomaly;

[0128] When it is determined that the current network connectivity status is a connected state, find the corresponding historical routing nodes for each current routing node in the current network status information from the historical network status information;

[0129] Calculate the latency difference between the current latency value of each current routing node and the historical latency value of the corresponding historical routing node;

[0130] When any one of the latency differences is greater than the preset latency threshold, determine that there is a latency anomaly.

[0131] In a possible implementation, the processing module is further configured to:

[0132] When the number of fault requests is greater than a preset first number, perform concurrent processing on the real-time routing trace instruction and the periodic routing trace instruction initiated by the signaling system on the active-standby data communication device switch, where the priority of the real-time routing trace instruction is higher than that of the periodic routing trace instruction.

[0133] In a possible implementation, the processing module is further configured to:

[0134] Map the source IP and the destination IP to the corresponding network element names through a pre-established service IP and network element correspondence table;

[0135] Retrieve in a preset historical alarm database according to the network element names to obtain historical alarm data;

[0136] Generate a link for viewing the routing trace operation and historical alarm data;

[0137] Add the link to the real-time alarm information.

[0138] It should be noted that the fault processing system for voice call testing provided by the present invention can execute the fault processing method for voice call testing in any of the above embodiments during specific operation, and this embodiment will not be elaborated herein.

[0139] Figure 6 is a schematic structural diagram of an electronic device provided by the present invention. As Figure 6 shown, the electronic device may include: a processor 610 (processor), a communication interface 620 (Communications Interface), a memory 630 (memory), and a communication bus 640. Among them, the processor 610, the communication interface 620, and the memory ********** are interconnected through the communication bus 640. The processor 610 can call the logical instructions in the memory 630 to execute the fault processing method for voice call testing, and the method includes: receiving a fault request from the signaling system, where the fault request includes a source IP and a destination IP; identifying the fault type of the fault request within a preset cache period, and merging and compressing the fault requests of the same fault type to obtain a merged set; determining the first fault request in the merged set, and performing a routing trace operation on the destination IP on the active-standby data communication device switch corresponding to the source IP of the first fault request to obtain the current network status information; judging whether there are routing anomalies and latency anomalies according to the current network status information and the historical network status information; determining the fault type according to the comparison result, and generating real-time alarm information including the fault type, the source IP, and the destination IP; sending the real-time alarm information to the management personnel terminal within a preset time period.

[0140] In addition, when the logical instructions in the above-mentioned memory 630 are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, external hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0141] On the other hand, the present invention also provides a computer program product. The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the fault handling method for voice call testing provided in the above-mentioned various embodiments. The method includes: receiving a fault request from a signaling system, where the fault request includes a source IP and a destination IP; identifying the fault type of the fault request within a preset caching period, and merging and compressing the fault requests of the same fault type to obtain a merged set; determining the first fault request in the merged set, and performing a route tracing operation on the destination IP on the primary and standby data communication device switches corresponding to the source IP of the first fault request to obtain the current network status information; judging whether there are routing anomalies and latency anomalies based on the current network status information and historical network status information; determining the fault type according to the comparison result, and generating real-time alarm information including the fault type, source IP, and destination IP; and sending the real-time alarm information to the management personnel terminal within a preset time period.

[0142] In another aspect, the present invention further provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is configured to execute the fault handling method for voice call testing provided in the above-mentioned embodiments. The method includes: receiving a fault request from a signaling system, the fault request including a source IP and a destination IP; identifying the fault type of the fault request within a preset caching period, and merging and compressing the fault requests of the same fault type to obtain a merged set; determining the first fault request in the merged set, and performing a route tracing operation on the destination IP on the primary and standby digital communication device switches corresponding to the source IP of the first fault request to obtain the current network status information; judging whether there are routing anomalies and latency anomalies according to the current network status information and the historical network status information; determining the fault type according to the comparison result, and generating real-time alarm information including the fault type, the source IP, and the destination IP; within a preset time period, sending the real-time alarm information to the management personnel terminal.

[0143] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative effort.

[0144] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disc, etc., and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiments.

[0145] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of the present invention.

Claims

1. A method for troubleshooting voice dialing, characterized in that: include: Receive a fault request from a signaling system, wherein the fault request includes a source IP address and a destination IP address; Identifying the fault type of the fault request within a preset cache period, and merging and compressing the fault requests of the same fault type to obtain a merged set; Determine the first fault request in the merged set, and perform a route tracing operation on the destination IP address on the primary and backup data communication device switches corresponding to the source IP address of the first fault request to obtain current network status information; the current network status information includes a current network connectivity status and a current latency value; Determine whether there are routing anomalies and latency anomalies based on the current network status information and historical network status information; The determining whether there is a routing anomaly and a latency anomaly based on the current network status information and the historical network status information specifically includes: When it is determined that the current network connectivity state is a non-connectivity state, determining that a routing anomaly exists; When it is determined that the current network connectivity state is a connectivity state, searching for a corresponding historical routing node for each current routing node in the current network status information from the historical network status information; Calculating the delay difference between the current delay value of each current routing node and the historical delay value of the corresponding historical routing node; When any of the delay differences is greater than a preset delay threshold, it is determined that a delay anomaly exists; Determine the fault type based on the comparison result, and generate real-time alarm information including the fault type, the source IP address, and the destination IP address; The real-time alarm information is sent to the administrator terminal within a preset time period.

2. The voice dialing fault handling method according to claim 1, characterized in that: The current network status information includes the current network connectivity status and the current delay value; the route tracing operation for the destination IP address is performed on the primary and backup data communication device switches corresponding to the source IP address of the first fault request to obtain the current network status information, specifically including: Determining the current network connectivity status according to a route tracing result, wherein the route tracing result is obtained after performing a route tracing operation on the destination IP address on the primary and backup data communication device switches; When it is determined that the current network connectivity state is a connectivity state, a current delay value is obtained.

3. The voice dialing fault handling method according to claim 2, characterized in that: Determining the current network connectivity status according to the route tracing result specifically includes: When it is determined that the route tracing result is that the destination IP address can be reached, or when there is no interrupted node in the route tracing result, determining that the current network connectivity state is a connected state; When it is determined that the route tracing result is that the destination IP address cannot be reached, or when there is an interrupted node in the route tracing result, it is determined that the current network connectivity state is a disconnected state.

4. The voice dialing fault handling method according to claim 1, characterized in that: The method further comprises: When the number of the fault requests is greater than a preset first number, the real-time route tracing instructions and the periodic route tracing instructions initiated by the signaling system are processed concurrently on the primary and backup data communication equipment switches, wherein the priority of the real-time route tracing instructions is higher than the priority of the periodic route tracing instructions.

5. The voice dialing fault handling method according to claim 1, characterized in that: The method further comprises: Map the source IP and destination IP to the corresponding network element name through the pre-established service IP and network element correspondence table; Searching a preset historical alarm database according to the network element name to obtain historical alarm data; generating a link for viewing the route tracing operation and the historical alarm data; The link is added to the real-time alert information.

6. A voice dialing fault handling system, characterized in that: include: A receiving module, configured to receive a fault request from a signaling system, wherein the fault request includes a source IP address and a destination IP address; a processing module, configured to identify the fault type of the fault request within a preset cache period, and merge and compress the fault requests of the same fault type to obtain a merged set; The processing module is further configured to determine the first fault request in the merged set, and perform a route tracing operation on the destination IP address on the primary and backup data communication device switches corresponding to the source IP address of the first fault request to obtain current network status information; the current network status information includes a current network connectivity status and a current latency value; The processing module is further configured to determine whether there is a routing anomaly and a delay anomaly based on the current network state information and the historical network state information. Specifically, the processing module includes: determining that a routing anomaly exists when the current network connectivity state is determined to be a disconnected state; searching for a corresponding historical routing node for each current routing node in the current network state information from the historical network state information when the current network connectivity state is determined to be a connected state; calculating a delay difference between a current delay value of each current routing node and a historical delay value of a corresponding historical routing node; and determining that a delay anomaly exists when any of the delay differences is greater than a preset delay threshold. An alarm generation module is used to determine the fault type according to the comparison result and generate real-time alarm information including the fault type, the source IP address and the destination IP address; The alarm sending module is used to send the real-time alarm information to the management terminal within a preset time period.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the fault handling method for voice dialing according to any one of claims 1 to 5 is implemented.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the fault handling method for voice dialing according to any one of claims 1 to 5 is implemented.

9. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the fault handling method for voice dialing according to any one of claims 1 to 5 is implemented.

Images