Traffic switching method, apparatus, device, storage medium and computer program product

Abstract

The application relates to the technical field of traffic switching, and discloses a traffic switching method, device, equipment, storage medium and computer program product. The method is applied to a traffic switching device, the traffic switching device is connected with a main traffic device and a backup traffic device, and the method comprises the following steps: acquiring a current message sent by the main traffic device under the condition that the main traffic device performs a session operation according to the current message; performing unpacking on the current message, performing key information extraction based on the unpacked current message, and storing the key information extraction result; under the condition that the main traffic device meets a preset traffic switching condition, sending the key information extraction result and a generated traffic switching instruction to the backup traffic device, so that the backup traffic device performs a session operation based on the key information extraction result when the traffic switching instruction is received. The stored key information extraction result is sent to the backup traffic device for traffic switching, and the switching delay is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of traffic switching, in particular to a traffic switching method, device, equipment, storage medium and computer program product. BACKGROUND

[0002] Traffic switching refers to a process of seamlessly transferring ongoing communication traffic (such as voice calls, video conferences, data transmission, etc.) from a main traffic device to a backup traffic device when the main traffic device fails, network links are interrupted, devices are maintained, or service load is too high, etc. in a communication system, aiming to ensure the continuity and stability of communication, avoid communication interruption caused by main device failure, and protect user experience and service quality.

[0003] In the prior art, the session state information of the main device is usually synchronized to the backup device only when the main device fails. However, when synchronizing, the session state information needs to be processed by software operations of multiple modules such as the operating system kernel in the main device before being synchronized, resulting in high processing delay. SUMMARY

[0004] The main purpose of the present application is to provide a traffic switching method, aiming to solve the technical problem of how to reduce the traffic switching delay.

[0005] To achieve the above purpose, the present application provides a traffic switching method, which is applied to a traffic switching device connected with a main traffic device and a backup traffic device, and comprises the following steps:

[0006] When the main traffic device performs session operation according to the current message, the current message sent by the main traffic device is acquired;

[0007] The current message is unpacked, key information is extracted based on the unpacked current message, and the key information extraction result is stored;

[0008] When the main traffic device meets the preset traffic switching condition, the key information extraction result and the generated traffic switching instruction are sent to the backup traffic device, so that the backup traffic device performs session operation based on the key information extraction result when receiving the traffic switching instruction.

[0009] In an embodiment, the step of extracting key information based on the unpacked current message and storing the key information extraction result comprises:

[0010] The unpacked current message is extracted based on a preset message header format rule to obtain basic feature information;

[0011] determining a current protocol type according to the basic feature information, and performing feature extraction on the basic feature information according to the current protocol type to obtain function feature information;

[0012] determining a current session identifier based on the function feature information, and performing feature extraction on the function feature information based on the current session identifier to obtain detailed media information;

[0013] taking the detailed media information, the function feature information and the basic feature information as a key information extraction result, and storing the key information extraction result.

[0014] In an embodiment, before the step of unpacking the current message, the method further comprises:

[0015] obtaining a current check code in the current message, and performing check on the current check code based on a preset check rule;

[0016] in a case where the check result is that the message is abnormal, generating a retransmission request, and sending the retransmission request to the main traffic device, so that the main traffic device re-sends the current message to the traffic switching device based on the retransmission request;

[0017] in a case where the check result is that the message is normal, performing standardization processing on the current message, and performing the step of unpacking the current message.

[0018] In an embodiment, the step of performing standardization processing on the current message comprises:

[0019] performing field analysis on the current message to determine a current message field;

[0020] in a case where the current message field does not satisfy a protocol specification, performing standardization processing on the current message based on a preset mapping relationship table and the current message field.

[0021] In an embodiment, the step of unpacking the current message comprises:

[0022] performing type analysis on the current message to determine a message type corresponding to the current message;

[0023] performing header field extraction on the current message based on the message type to obtain a header key field corresponding to the current message;

[0024] unpacking the current message according to the header key field.

[0025] In an embodiment, after the step of sending the key information extraction result and the generated traffic switching instruction to the standby traffic device, the method further comprises:

[0026] regarding the main traffic device as a new standby traffic device and regarding the standby traffic device as a new main traffic device;

[0027] In a case where the new main traffic device performs a session operation according to a new current packet, the step of obtaining the new current packet sent by the new main traffic device is performed.

[0028] In addition, to achieve the above object, the present application further provides a traffic switching device, which comprises:

[0029] a packet obtaining module, configured to obtain a current packet sent by a main traffic device in a case where the main traffic device performs a session operation according to the current packet;

[0030] a packet storage module, configured to unpack the current packet, perform key information extraction based on the unpacked current packet, and store the key information extraction result;

[0031] a traffic switching module, configured to send the key information extraction result and a generated traffic switching instruction to a standby traffic device in a case where the main traffic device meets a preset traffic switching condition, so that the standby traffic device performs a session operation based on the key information extraction result when receiving the traffic switching instruction.

[0032] In addition, to achieve the above object, the present application further provides a traffic switching device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the traffic switching method as described above.

[0033] In addition, to achieve the above object, the present application further provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the traffic switching method as described above.

[0034] In addition, to achieve the above object, the present application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the traffic switching method as described above.

[0035] The application provides a traffic switching method, device, equipment, storage medium and computer program product. The method is applied to a traffic switching device connected with a main traffic device and a backup traffic device. The method comprises the following steps: acquiring a current message sent by the main traffic device under the condition that the main traffic device performs a session operation according to the current message; performing decapsulation on the current message, performing key information extraction based on the decapsulated current message, and storing the key information extraction result; and under the condition that the main traffic device meets a preset traffic switching condition, sending the key information extraction result and a generated traffic switching instruction to the backup traffic device, so that the backup traffic device performs a session operation based on the key information extraction result when receiving the traffic switching instruction. Since the application stores the key information extraction result of the message in the main device in real time through the traffic switching device before traffic switching, the key information extraction result in the traffic switching device and the generated traffic switching instruction can be directly sent to the backup traffic device when traffic switching is needed, so that the backup traffic device performs a session operation based on the key information extraction result. Compared with the prior art, the application can pre-store the session state information in the traffic switching device instead of waiting for the main device to fail before starting to synchronize the session state information, and directly sends the pre-stored session state information to the backup traffic device after the main device fails, thereby greatly reducing the switching delay and improving the real-time performance and efficiency of traffic switching. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the application and, together with the specification, serve to explain the principles of the application.

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the accompanying drawings needed in the embodiments or the prior art description will be briefly introduced. Obviously, those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0038] Figure 1 Flow chart of the first embodiment of the traffic switching method proposed in the embodiments of the application;

[0039] Figure 2 Connection diagram of the device in the traffic switching method proposed in the embodiments of the application;

[0040] Figure 3 Flow chart of the second embodiment of the traffic switching method proposed in the embodiments of the application;

[0041] Figure 4 Flow chart of the third embodiment of the traffic switching method proposed in the embodiments of the application;

[0042] Figure 5 A diagram of a traffic switching device provided in an embodiment of this application;

[0043] Figure 6 A schematic diagram of the structure of a traffic switching device suitable for implementing the embodiments of this application.

[0044] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0045] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

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

[0047] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0048] Understandably, call switching refers to the process in a communication system where, when the primary call equipment fails, the network link is interrupted, the equipment is under maintenance, or the workload is too high, ongoing communication traffic (such as voice calls, video conferencing, data transmission, etc.) is seamlessly transferred from the primary call equipment to the backup call equipment. The purpose is to ensure the continuity and stability of communication, avoid communication interruptions caused by primary equipment failure, and guarantee user experience and service quality.

[0049] In existing technologies, during call handover, the session state information of the primary device is typically synchronized to the backup device only when the primary device fails. During synchronization, the session state information needs to be processed by multiple software modules, including the operating system kernel, within the primary device, resulting in high processing latency.

[0050] Therefore, to address the technical problem of reducing call handover latency, this embodiment proposes a call handover method. This method is applied to a call handover device, which is connected to both a primary call handover device and a backup call handover device. The method includes: when the primary call handover device performs a session operation based on the current message, obtaining the current message sent by the primary call handover device; decapsulating the current message, extracting key information based on the decapsulated current message, and storing the key information extraction results; when the primary call handover device meets preset call handover conditions, sending the key information extraction results and the generated call handover command to the backup call handover device, so that the backup call handover device can perform a session operation based on the key information extraction results upon receiving the call handover command. Because this embodiment stores the key information extraction results of the messages in the primary device in real time before call handover, when call handover is required, the key information extraction results and the generated call handover command in the call handover device can be directly sent to the backup call handover device, allowing the backup call handover device to perform a session operation based on the key information extraction results. Compared to existing methods, there is no need to wait for the primary device to fail before synchronizing session state information. Instead, session state information can be pre-synchronized to the call switching device. After the primary device fails, the pre-stored synchronized session state information is directly sent to the backup call device, which greatly reduces switching latency and improves the real-time performance and efficiency of call switching.

[0051] For ease of understanding, the following is combined with Figures 1 to 6 The present application provides a detailed description of the traffic switching method, as well as the traffic switching method, apparatus, device, storage medium, and computer program product provided in the following embodiments.

[0052] This application provides a call handover method, referring to... Figure 1 , Figure 1 This is a flowchart of the first embodiment of the traffic switching method proposed in this application.

[0053] like Figure 1 As shown, the method includes:

[0054] Step S10: When the main communication device performs a session operation based on the current message, obtain the current message sent by the main communication device.

[0055] refer to Figure 2 , Figure 2This is a schematic diagram of device connections in the traffic switching method proposed in this application embodiment. It should be noted that the executing entity in this embodiment can be a multi-functional machine device with traffic switching capabilities, such as a traffic switching device, or a device capable of performing the aforementioned functions. This embodiment uses a traffic switching device (hereinafter referred to as the device) for description. The aforementioned traffic switching device is connected to the main traffic device (i.e., Figure 2 The main call equipment and the backup call equipment (i.e.) Figure 2 (The backup call center equipment) is connected and used.

[0056] It should also be noted that the aforementioned primary traffic equipment can be the device responsible for handling the main session operations and plays a dominant role in the communication system. The aforementioned current message can be a data packet being transmitted or processed, containing session-related control information and data, such as a session initiation protocol message or a session description protocol message. The aforementioned session operations can be operations related to establishing, maintaining, and managing communication sessions, such as signal transmission and media stream control.

[0057] In its implementation, the aforementioned device acquires the current message sent by the primary call device when the primary call device performs session operations based on the current message. For example, when the primary call device processes a message, the aforementioned device captures the message in real time through a high-speed data interface.

[0058] Step S20: Decapsulate the current message, extract key information based on the decapsulated current message, and store the key information extraction results.

[0059] It should be noted that the above decapsulation can be the process of stripping a message from the transport layer protocol and restoring its original data content. The above key information extraction can be the process of extracting important features and data from the decapsulated message. The results of the above key information extraction can be the important features and data extracted from the message.

[0060] In its implementation, the aforementioned device first receives the current message sent by the primary call center, such as a SIPINVITE message. Then, the device decapsulates the message, stripping away the frame headers and trailers, IP headers, and TCP or UDP headers added sequentially by the physical layer, data link layer, network layer, and transport layer, to reconstruct the original application layer data. Next, the device extracts key information from the original data, such as source IP address, destination IP address, source port, destination port, protocol type, session ID, and caller and callee identifiers. Finally, the device stores the extracted key information in a cache and records the timestamp, message sequence number, etc., for quick retrieval and use when needed.

[0061] Furthermore, in order to achieve accurate traffic handover, the step of extracting key information based on the decapsulated current message and storing the key information extraction results includes:

[0062] Step S24: Extract features from the decapsulated current message based on the preset message header format rules to obtain basic feature information.

[0063] It should be noted that the aforementioned preset message header format rules can be message header structure specifications defined according to communication protocol standards. The aforementioned decapsulated current message can be the original application layer data after the transport layer, network layer, data link layer, and physical layer encapsulations have been removed. The aforementioned basic characteristic information can be basic attributes extracted from the decapsulated message, including source IP, destination IP, source port, destination port, etc.

[0064] In its implementation, the device extracts features from the decapsulated current packet based on preset packet header format rules to obtain basic feature information. For example, after decapsulating a SIP INVITE packet, the device extracts basic feature information such as source IP address 20.0.0.50, destination IP address 192.168.1.100, source port 5060, and destination port 39328 according to preset SIP protocol header format rules.

[0065] Step S25: Determine the current protocol type based on the basic feature information, and extract features from the basic feature information based on the current protocol type to obtain functional feature information.

[0066] It should be noted that the aforementioned current protocol type can be the type of communication protocol used in the current message. The aforementioned functional characteristic information can be features related to protocol functions further extracted from the basic characteristic information.

[0067] In its implementation, the device determines the current protocol type based on basic characteristic information and then extracts features from this basic characteristic information to obtain functional characteristic information. For example, after extracting basic characteristic information such as the source IP address 20.0.0.50, destination IP address 192.168.1.100, source port 5060, and destination port 39328 from the packet, the device searches the protocol port mapping table and finds that destination port 39328 is usually associated with the SIP protocol, thus determining that the current protocol type is SIP. Next, according to the SIP protocol format specifications, the device further extracts information such as the caller's phone number, the called party's phone number, the session ID, the media stream type, and the encoding / decoding method from the packet. This information constitutes the functional characteristic information, which is used for subsequent session management and processing.

[0068] Step S26: Determine the current session identifier based on the functional feature information, and extract features from the functional feature information based on the current session identifier to obtain detailed media information.

[0069] Step S27: Extract the detailed media information, the functional feature information, and the basic feature information as key information results, and store the key information extraction results.

[0070] It should be noted that the aforementioned current session identifier can be specific information used to uniquely identify the current communication session. The aforementioned detailed media information can be specific information about the media stream, such as media type, encoding / decoding method, etc.

[0071] In its implementation, the device determines the current session identifier based on the functional feature information and extracts features from the functional feature information based on the current session identifier to obtain detailed media information. For example, after extracting functional feature information such as source port 5060, destination port 39328, and protocol version SIP / 2.0 from the decapsulated SIP packet, the device determines the current session identifier as "SessionID_001" by looking up the session identifier mapping table. Then, based on this session identifier, the device further extracts detailed media information from the functional feature information, such as media type as audio, encoding / decoding method as G.711, and sampling rate as 8kHz. This detailed media information will be used for subsequent session management and processing to ensure that the media stream can be smoothly taken over and continue transmission during call handover. For example, when the primary call equipment fails, the backup call equipment can use this detailed media information to quickly establish a new media stream connection, ensuring call continuity.

[0072] Step S30: When the primary call device meets the preset call switching conditions, the key information extraction result and the generated call switching instruction are sent to the backup call device, so that the backup call device can perform a session operation based on the key information extraction result when it receives the call switching instruction.

[0073] It should be noted that the aforementioned preset traffic handover conditions can be pre-defined conditions that trigger traffic handover, such as primary equipment failure or network quality degradation. The aforementioned traffic handover command can be an operation command used to notify the backup device to take over the session. The aforementioned backup traffic device can be a backup device used to take over session operations when the primary device fails.

[0074] In its implementation, the aforementioned device sends the extracted key information and the generated call switching command to the backup device when the primary call device meets the preset call switching conditions. For example, if the CPU utilization of the primary call device exceeds 90% for 10 seconds, or the network latency exceeds 100 milliseconds, the device determines that the primary call device meets the preset call switching conditions. At this time, the device sends the previously extracted and stored key information, including source IP address 20.0.0.50, destination IP address 192.168.1.100, source port 5060, destination port 39328, protocol version SIP / 2.0, media type audio, codec G.711, sampling rate 8kHz, etc., along with the generated call switching command, to the backup call device. Upon receiving the call switching command, the backup call device immediately reads the extracted key information and performs session operations based on this information to ensure session continuity and stability. For example, backup call equipment can quickly establish a new media stream connection by using detailed media information such as media type and encoding / decoding method extracted from key information results, thus maintaining the continuity of the call.

[0075] In this embodiment, before traffic handover, the traffic handover device stores the key information extraction results of messages from the primary device in real time. When traffic handover is required, the key information extraction results and the generated traffic handover command can be directly sent to the backup traffic device, enabling the backup traffic device to perform session operations based on the key information extraction results. This embodiment eliminates the need to wait for a primary device failure before synchronizing session state information; instead, session state information can be pre-synchronized to the traffic handover device. After a primary device failure, the pre-stored synchronized session state information is directly sent to the backup traffic device, significantly reducing handover latency and improving the real-time performance and efficiency of traffic handover.

[0076] Based on the first embodiment, in the second embodiment, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart of a second embodiment of the traffic handover method proposed in this application. Further, to achieve more accurate traffic handover, before the step of decapsulating the current packet, the method includes:

[0077] Step S201: Obtain the current checksum in the current message and verify the current checksum based on the preset verification rules.

[0078] It should be noted that the aforementioned current checksum can be a specific field in the message used to verify data integrity and accuracy. The aforementioned preset verification rules can be pre-defined algorithms or methods used to verify whether the checksum is correct.

[0079] In its implementation, the device obtains the current checksum from the current message and verifies it based on preset verification rules. For example, the device extracts the checksum field from a SIPINVITE message. Then, the device uses preset verification rules, such as a CRC checksum algorithm or a checksum calculation method, to verify the checksum. If the verification result indicates that the message is complete and error-free, the device continues with subsequent processing; if the verification fails, a message retransmission mechanism may be triggered to ensure the accuracy and integrity of the data.

[0080] Step S202: If the verification result indicates that the message is abnormal, a retransmission request is generated and sent to the main traffic device, so that the main traffic device can retransmit the current message to the traffic switching device based on the retransmission request.

[0081] It should be noted that the above verification result can be a conclusion about the message status obtained after verifying the checksum, such as whether the message is abnormal or normal. The above retransmission request can be a signal or message used to request the retransmission of the message, containing the identification information of the abnormal message and the reason for retransmission, etc.

[0082] In its implementation, when the verification result indicates a message is abnormal, the aforementioned device generates a retransmission request and sends it to the primary traffic device. For example, when the traffic switching device detects that the checksum of the current message does not match the preset verification rules, it immediately generates a retransmission request. The device sends the retransmission request to the primary traffic device via the network interface. Upon receiving the retransmission request, the primary traffic device locates and retransmits the corresponding current message to the traffic switching device based on the information in the request. Specifically, assuming the current message is a SIPINVITE message, the traffic switching device finds that its checksum does not match the calculated result during verification and determines the message is abnormal. The traffic switching device then generates a retransmission request containing the message sequence number and error type (such as checksum error) and sends it to the primary traffic device via a preset communication link. Upon receiving the retransmission request, the primary traffic device locates the original message based on the message sequence number and retransmits it to the traffic switching device. Upon receiving the retransmitted message, the traffic switching device performs verification again. If the verification passes, the subsequent processing continues; if the verification still fails, further error handling mechanisms may be triggered, such as multiple retransmission requests or discarding abnormal packets. This process ensures the accuracy and integrity of packet transmission, providing a reliable data foundation for subsequent traffic handover and session synchronization.

[0083] Step S203: If the verification result shows that the message is normal, perform standardization processing on the current message and perform decapsulation on the current message.

[0084] It should be noted that the standardization process described above can be the process of converting a message into a format that conforms to a preset format, such as standardizing the field order or encoding method. The decapsulation process described above can be the process of stripping a message from the transport layer protocol and restoring its original data content.

[0085] In its implementation, when the verification result indicates the message is normal, the aforementioned device standardizes the current message and then decapsulates it. For example, when the device detects that the message's checksum matches a preset verification rule, it first standardizes the message. This step ensures that the message conforms to preset format specifications, such as uniform field order or encoding method. Next, the device decapsulates the standardized message, removing the encapsulation information added sequentially by the physical layer, data link layer, network layer, and transport layer, such as frame headers and trailers, IP headers, and TCP or UDP headers, to restore the original application layer data.

[0086] Furthermore, the step of standardizing the current message includes:

[0087] Step S2031: Perform field analysis on the current message to determine the fields of the current message.

[0088] It should be noted that the above field analysis can be a process of identifying and parsing the various components of a message. These message fields can be data segments within the message that have specific meanings and formats, such as source IP address, destination IP address, and port number.

[0089] In its implementation, the aforementioned device performs field analysis on the current message to determine its fields. For example, upon receiving a SIPINVITE message, the device first scans and parses the message byte by byte. The device identifies the starting line of the message as a request line, containing three fields: method, request URI, and protocol version. These fields are separated by spaces and end with a newline character. Next, the device parses the various fields in the message header, such as the source IP address, destination IP address, source port, and destination port. During parsing, the device identifies specific field names and corresponding values ​​according to protocol specifications, such as the SIP protocol. Finally, the device stores the parsed fields in memory for subsequent processing and analysis. This process ensures that the device can accurately understand and process the content of the current message. For example, through field analysis, the device extracts fields such as the source IP address 20.0.0.50, the destination IP address 192.168.1.100, the source port 5060, and the destination port 39328. This information will be used for subsequent session management and processing.

[0090] Step S2032: When the current message field does not meet the protocol specification, the current message is standardized based on the preset mapping relationship table and the current message field.

[0091] It should be noted that the aforementioned protocol specifications can be the message format and field requirements defined in a communication protocol. The aforementioned preset mapping table can be a pre-defined table used to map non-standard fields to standard fields.

[0092] In its implementation, when a packet field does not conform to the protocol specifications, the device standardizes the packet based on a pre-defined mapping table. For example, if the device receives a SIP packet and finds a misspelled "Call-ID" field, it uses the pre-defined mapping table to determine that the field should be "Call-ID" and replaces the incorrect field with the correct name. Simultaneously, the device checks other fields, such as correcting "Content-Type" to "Content-Type," ensuring that all fields conform to the SIP protocol specifications.

[0093] Based on the first and second embodiments, in the third embodiment, the content that is the same as or similar to that in Embodiments 1 and 2 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart of the third embodiment of the traffic handover method proposed in this application. Further, the step of decapsulating the current packet includes:

[0094] Step S21: Perform type analysis on the current message to determine the message type corresponding to the current message.

[0095] It should be noted that the above type analysis can be a detection process to determine the type of a message, usually based on protocol, format, or content. The message types mentioned above can be message categories classified according to protocol, format, or purpose, such as request messages, response messages, etc.

[0096] In its implementation, the device performs type analysis on the current message to determine its corresponding message type. For example, upon receiving a message, the device first checks the message header fields, especially the protocol version number and message type identifier. Assuming the message header field shows a protocol version number of SIP / 2.0 and the message begins with INVITE, the device determines that the current message is a SIP protocol request message, specifically an INVITE request. The device maintains a pre-defined message type mapping table, which defines the message types corresponding to different protocols and type identifiers. By matching the field information in the message header, the device can accurately determine the type of the current message, thereby initiating the corresponding processing logic. For example, for an INVITE request, the device will trigger a session establishment process, including parsing the session identifier, media type, and other information in the request, and performing corresponding resource allocation and session management operations.

[0097] Step S22: Extract header fields from the current message based on the message type to obtain the header key fields corresponding to the current message.

[0098] It should be noted that the above header fields can be any fields included in the message header, used to identify the attributes and content of the message. The above key header fields can be header fields in the message used to identify key information, such as source address, destination address, port number, etc.

[0099] In its implementation, the device extracts header fields from the current message based on the message type to obtain the corresponding key header fields. For example, when the device determines that the current message is a SIPINVITE request, it extracts key information from the header fields according to the SIP protocol specification. The device first identifies the request line of the message, confirming it is an INVITE method. Next, it extracts fields from the message header, such as source IP address, destination IP address, source port, destination port, Call-ID, From identifier, To identifier, CSeq sequence number, and Contact information. These key fields are stored in the device's memory for subsequent session management and processing. For example, the source IP address might be 20.0.0.50, the destination IP address 192.168.1.100, the source port 5060, and the destination port 39328. By extracting these key header fields, the device can accurately understand and process the content of the current message, ensuring the smooth operation of the session.

[0100] Step S23: Decapsulate the current message according to the header key fields.

[0101] It should be noted that the above decapsulation can be a process of stripping different layers of protocol headers from a message to extract the original application layer data. In specific implementation, the device decapsulates the current message based on key header fields. For example, the device identifies the message's source IP address as 20.0.0.50, destination IP address as 192.168.1.100, protocol type as UDP, and port number as 5060. Based on these key fields, the device first strips the physical and data link layer frame headers and trailers, then removes the network layer IP header, and finally strips the transport layer UDP header. Ultimately, the device successfully extracts the original application layer data, such as the SIP message content.

[0102] Furthermore, after the step of sending the key information extraction results and the generated call switching command to the backup call equipment, the method further includes:

[0103] Step S40: Designate the primary call equipment as the new backup call equipment, and designate the backup call equipment as the new primary call equipment;

[0104] Step S50: When the new primary communication device performs a session operation based on the new current message, the step of obtaining the new current message sent by the new primary communication device is executed.

[0105] In its implementation, the aforementioned device switches the primary traffic device to a new backup traffic device and vice versa. When the new primary traffic device performs session operations based on the new current message, the device performs the step of acquiring the new current message. For example, after the new primary traffic device starts processing a session, it will send a new current message, such as a SIPUPDATE message. The aforementioned device captures this new current message in real time through a high-speed data interface and decapsulates and extracts key information from it.

[0106] The aforementioned device parses the packet header, extracting key fields such as the source IP address (20.0.0.50), destination IP address (192.168.1.100), source port (5060), and destination port (39328). Simultaneously, the device extracts detailed media information from the packet, including the session ID, caller and callee identifiers, and stores this information in a cache. The device continues to monitor the status of the new primary call center device to ensure rapid handover and maintain session continuity should the new primary device malfunction.

[0107] This embodiment also provides a first embodiment of a traffic switching device, please refer to... Figure 5 , Figure 5 This is a diagram of a traffic switching device provided in an embodiment of this application. The traffic switching device includes:

[0108] The message acquisition module is used to acquire the current message sent by the main communication device when the main communication device performs a session operation based on the current message;

[0109] The message storage module is used to decapsulate the current message, extract key information based on the decapsulated current message, and store the key information extraction results.

[0110] The call switching module is used to send the key information extraction result and the generated call switching instruction to the backup call device when the primary call device meets the preset call switching conditions, so that the backup call device can perform a session operation based on the key information extraction result when it receives the call switching instruction.

[0111] The message storage module is further configured to: extract features from the decapsulated current message based on preset message header format rules to obtain basic feature information; determine the current protocol type based on the basic feature information, and extract features from the basic feature information based on the current protocol type to obtain functional feature information; determine the current session identifier based on the functional feature information, and extract features from the functional feature information based on the current session identifier to obtain detailed media information; and store the detailed media information, the functional feature information, and the basic feature information as key information extraction results.

[0112] Referring to the first embodiment of the traffic switching device, this embodiment also proposes a second embodiment of the traffic switching device. The contents that are the same as or similar to those in the first embodiment of the traffic switching device can be referred to the above description, and will not be repeated hereafter.

[0113] The message storage module is further configured to obtain the current checksum in the current message and verify the current checksum based on a preset verification rule; if the verification result indicates that the message is abnormal, a retransmission request is generated and sent to the main call equipment, so that the main call equipment retransmits the current message to the call switching equipment based on the retransmission request; if the verification result indicates that the message is normal, the current message is standardized and a decapsulation step is performed on the standardized current message.

[0114] The message storage module is further configured to perform field analysis on the current message to determine the fields of the current message; when the fields of the current message do not meet the protocol specifications, the current message is standardized based on a preset mapping table and the fields of the current message.

[0115] Referring to the first embodiment and the second embodiment of the traffic switching device, this embodiment also proposes a third embodiment of the traffic switching device. The contents that are the same as or similar to the first embodiment and the second embodiment of the traffic switching device can be referred to the above description, and will not be repeated hereafter.

[0116] The message storage module is further configured to perform type analysis on the current message to determine the message type corresponding to the current message; extract header fields from the current message based on the message type to obtain the header key fields corresponding to the current message; and decapsulate the current message according to the header key fields.

[0117] The traffic switching module is further configured to use the primary traffic device as a new backup traffic device and the backup traffic device as a new primary traffic device; and to perform the step of obtaining the new current message sent by the new primary traffic device when the new primary traffic device performs a session operation based on the new current message.

[0118] The traffic switching device provided in this embodiment, employing the traffic switching method described in the above embodiments, can solve the technical problem of reducing traffic switching latency. Compared with the prior art, the beneficial effects of the traffic switching device provided in this embodiment are the same as those of the traffic switching method described in the above embodiments, and other technical features in the traffic switching device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0119] This embodiment provides a traffic switching device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the traffic switching method in the first embodiment described above.

[0120] The following is for reference. Figure 6 , Figure 6 This is a schematic diagram of a call switching device suitable for implementing the embodiments of this application. The call switching device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), vehicle terminals (such as vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6The traffic switching device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0121] like Figure 6 As shown, the call switching device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the call switching device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the traffic switching equipment to communicate wirelessly or wiredly with other devices to exchange data. Although traffic switching equipment with various systems is shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0122] Specifically, according to this embodiment, the process described above with reference to the flowchart can be implemented as a computer software program. For example, this embodiment includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the disclosed embodiments of this embodiment.

[0123] The traffic switching device provided in this embodiment, employing the traffic switching method described in the above embodiment, can solve the technical problem of how to reduce traffic switching latency. Compared with the prior art, the beneficial effects of the traffic switching device provided in this embodiment are the same as those of the traffic switching method described in the above embodiment, and other technical features of this traffic switching device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0124] It should be understood that the various parts disclosed in this embodiment can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0125] The above description is merely a specific implementation of this embodiment, but the protection scope of this embodiment is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this embodiment should be included within the protection scope of this embodiment. Therefore, the protection scope of this embodiment should be determined by the protection scope of the claims.

[0126] This embodiment provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the call handover method described in the above embodiment.

[0127] The computer-readable storage medium provided in this embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0128] The aforementioned computer-readable storage medium may be included in the traffic switching device; or it may exist independently and not be assembled into the traffic switching device.

[0129] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the traffic switching device, cause the traffic switching device to perform traffic switching.

[0130] Computer program code for performing the operations of this embodiment can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this embodiment. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0132] The modules described in this embodiment can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0133] The readable storage medium provided in this embodiment is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-described traffic handover method, and can solve the technical problem of how to reduce traffic handover latency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this embodiment are the same as the beneficial effects of the traffic handover method provided in the above embodiments, and will not be repeated here.

[0134] The above descriptions are only some embodiments and do not limit the patent scope of this embodiment. All equivalent structural transformations made based on the technical concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A method of traffic switching, characterized by, The method is applied to a traffic switching device connected with a main traffic device and a backup traffic device respectively, and comprises the following steps: In the case that the main traffic device performs session operation according to a current message, the current message sent by the main traffic device is acquired; The current message is unpacked, key information is extracted based on the unpacked current message, and the key information extraction result is stored; In the case that the main traffic device meets a preset traffic switching condition, the key information extraction result and a generated traffic switching instruction are sent to the backup traffic device, so that the backup traffic device performs session operation based on the key information extraction result when receiving the traffic switching instruction.

2. The method of claim 1, wherein, The step of extracting key information based on the unpacked current message and storing the key information extraction result comprises the following steps: The unpacked current message is feature-extracted based on a preset message header format rule to obtain basic feature information; The current protocol type is determined according to the basic feature information, and the basic feature information is feature-extracted according to the current protocol type to obtain function feature information; The current session identifier is determined based on the function feature information, and the function feature information is feature-extracted based on the current session identifier to obtain detailed media information; The detailed media information, the function feature information and the basic feature information are taken as the key information extraction result, and the key information extraction result is stored.

3. The method of claim 1, wherein, Before the step of unpacking the current message, the following steps are further included: The current check code in the current message is acquired, and the current check code is checked based on a preset check rule; In the case that the check result is a message exception, a retransmission request is generated, and the retransmission request is sent to the main traffic device, so that the main traffic device re-sends the current message to the traffic switching device based on the retransmission request; In the case that the check result is a normal message, the current message is standardized processed, and the step of unpacking the current message is executed.

4. The method of claim 3, wherein, The step of standardizing processing the current message comprises the following steps: The current message is field-analyzed to determine a current message field; In the case that the current message field does not meet the protocol specification, the current message is standardized processed based on a preset mapping relationship table and the current message field.

5. The method of claim 1, wherein, The step of unpacking the current message comprises the following steps: The current message is type-analyzed to determine a message type corresponding to the current message; The current message is header field-extracted based on the message type to obtain a header key field corresponding to the current message; The current message is unpacked according to the header key field.

6. The method of claim 1, wherein, After the step of sending the key information extraction result and the generated traffic switching instruction to the backup traffic device, the following steps are further included: The main traffic device is taken as a new backup traffic device, and the backup traffic device is taken as a new main traffic device; In a case where the new master traffic device performs a session operation according to a new current message, the step of acquiring the new current message sent by the new master traffic device is performed.

7. A traffic switching device, characterized by The device comprises: a message acquisition module, configured to acquire a current message sent by a master traffic device in a case where the master traffic device performs a session operation according to the current message; a message storage module, configured to perform decapsulation on the current message, perform key information extraction based on the decapsulated current message, and store the key information extraction result; a traffic switching module, configured to send the key information extraction result and a generated traffic switching instruction to a backup traffic device in a case where the master traffic device meets a preset traffic switching condition, so that the backup traffic device performs a session operation based on the key information extraction result when the traffic switching instruction is received.

8. A traffic switching device, characterized by The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the traffic switching method according to any one of claims 1 to 6.

9. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the traffic switching method according to any one of claims 1 to 6.

10. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to implement the steps of the traffic switching method according to any one of claims 1 to 6.

Images