Call packet loss processing method, system, device and medium

Abstract

The invention provides a call packet loss processing method, system and device and a medium, and the method comprises the steps that a server responds to handshake request information sent by a user side, returns handshake response information to the user side, and caches the handshake response information to a cache region of a soft switch platform; the server responds to message anomaly detection, obtains target response information of a cache region from the soft switch platform and resends the target response information to the user side to confirm a handshake state; and the server responds to handshake confirmation information sent by the user side and returns server handshake ending information. According to the invention, the probability of DTLS handshake failure caused by the loss of the target message can be reduced through the cache region, and the success rate of DTLS handshake in the Vo IP system and the reliability of connection are improved, so that the problem of packet loss of the network call of the call center is solved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a call packet loss processing method, system, device and medium. Background Art

[0002] The VoIP protocol is a technology that converts analog sound signals into digital signals and transmits them over the Internet. The VoIP protocol allows users to make voice calls over an IP network to provide telephone services (such as outbound call systems). In the VoIP field, the DTLS protocol is used to ensure the secure transmission of voice data over the unreliable UDP transmission protocol. The DTLS protocol provides replay attack protection and retransmission mechanisms to adapt to the connectionlessness and unreliability of the UDP transmission protocol. The handshake process of the DTLS protocol is the basis for the communicating parties to establish a secure connection.

[0003] However, the DTLS handshake process is prone to problems such as packet disorder and failure to trigger the retransmission mechanism in a timely manner in an environment with unstable network or high packet loss rate, resulting in packet loss and handshake failure. Frequent re-handshakes not only consume a lot of network resources, but also increase network latency and affect the stability of VoIP calls. The existing DTLS protocol does not fully consider the impact of network stability on the handshake process, and there is still a lack of effective optimization measures.

[0004] Therefore, there is an urgent need for a call packet loss processing method to solve the problem that the above-mentioned network stability has many impacts on the DTLS protocol handshake process. Summary of the invention

[0005] In view of the deficiencies in the prior art, the present invention provides a call packet loss processing method, system, device and medium.

[0006] The first aspect of the present invention discloses a method for processing call packet loss, which is applied to a server of the DTLS protocol, and comprises:

[0007] The server responds to the handshake request information sent by the user terminal, returns the handshake response information to the user terminal and caches the handshake response information in the buffer area of ​​the soft switch platform;

[0008] In response to the message anomaly detection, the server obtains the target response information in the buffer area from the soft switch platform and resends it to the user end to confirm the handshake status;

[0009] The server responds to the handshake confirmation message sent by the client and returns a server handshake completion message.

[0010] In an optional embodiment, the handshake request information and the handshake response information both include a message data packet consisting of a message header, a message body, and a message verification code, the message header records a timestamp, a sequence number, a message length, a four-tuple and / or a five-tuple, the message body includes transmission data to be processed, and the message verification code includes verification information for verifying the legitimacy of the transmission data.

[0011] In an optional embodiment, the soft switch platform builds a call center under the VoIP system, the call center includes the server and multiple user terminals, the cache area is an upper-layer module loaded on the server by the soft switch platform, the upper-layer module synchronizes the communication protocol with the server and the user terminal, and the upper-layer module asynchronously processes the cache events of the handshake response information and the message exception events of the target response information.

[0012] In an optional embodiment, the step of caching the handshake response information in a buffer area of ​​a soft switch platform includes:

[0013] The soft switch platform sets a buffer area to store the message data packet of the handshake response information, and generates a detection mark including one or more of the time check, message length check and sequence continuity check according to the message header;

[0014] The time check includes a time continuity check of matching the context of a message data packet by a timestamp within a unit time; the message length check includes a check of matching the length of a digital summary of a temporary key generated by metadata in a message header with a message data packet; the sequence continuity check includes a continuity check of the associated context of serial numbers in multiple message data packets sent by the same terminal.

[0015] In an optional embodiment, the server responds to message anomaly detection, including:

[0016] Traversing the handshake request information received by the server, and determining the handshake request information associated with the context and the associated client according to the four-tuple or five-tuple of the detection identifier;

[0017] It is determined whether the associated client repeatedly sends handshake request information according to the detection identifier, and the target response information not received by the client is determined according to the time check, message length check and sequence continuity check of the detection identifier.

[0018] In an optional embodiment, obtaining the target response information of the buffer area from the soft switch platform and resending it to the user end to confirm the handshake state includes:

[0019] The server authenticates the identity of the user end based on the message verification code and metadata key. The server sends a retransmission request to the soft switch platform based on the message anomaly detection result, obtains the target response information sent by the buffer area and forwards it to the user end, and assembles the remaining message data packets out of order through the jitter buffer, and receives the handshake confirmation information returned by the user end.

[0020] A second aspect of the present invention discloses a call packet loss processing system, the system comprising:

[0021] A cache module, used for the server to respond to the handshake request information sent by the user end, return the handshake response information to the user end and cache the handshake response information in the cache area of ​​the soft switch platform;

[0022] A resending module, used for the server to obtain the target response information of the buffer area from the soft switch platform in response to the message abnormality detection and resend it to the user end to confirm the handshake status;

[0023] The confirmation module is used for the server to respond to the handshake confirmation information sent by the user end and return the server handshake completion information.

[0024] In an optional embodiment, the handshake request information and the handshake response information in the cache module both include a message data packet consisting of a message header, a message body, and a message verification code, the message header records a timestamp, a sequence number, a message length, a four-tuple and / or a five-tuple, the message body includes transmission data to be processed, and the message verification code includes verification information for verifying the legitimacy of the transmission data.

[0025] In an optional embodiment, the soft switch platform in the cache module builds a call center under the VoIP system, the call center includes the server and multiple user terminals, the cache area is an upper-layer module loaded on the server by the soft switch platform, the upper-layer module synchronizes the communication protocol with the server and the user terminal, and the upper-layer module asynchronously processes the cache events of the handshake response information and the message exception events of the target response information.

[0026] In an optional embodiment, the cache module caches the handshake response information to a cache area of ​​a soft switch platform, including:

[0027] The soft switch platform sets a buffer area to store the message data packet of the handshake response information, and generates a detection mark including one or more of the time check, message length check and sequence continuity check according to the message header;

[0028] The time check includes a time continuity check of matching the context of a message data packet by a timestamp within a unit time; the message length check includes a check of matching the length of a digital summary of a temporary key generated by metadata in a message header with a message data packet; the sequence continuity check includes a continuity check of the associated context of serial numbers in multiple message data packets sent by the same terminal.

[0029] In an optional embodiment, the server in the retransmission module responds to message anomaly detection, including:

[0030] Traversing the handshake request information received by the server, and determining the handshake request information associated with the context and the associated client according to the four-tuple or five-tuple of the detection identifier;

[0031] It is determined whether the associated client repeatedly sends handshake request information according to the detection identifier, and the target response information not received by the client is determined according to the time check, message length check and sequence continuity check of the detection identifier.

[0032] In an optional embodiment, the step of obtaining the target response information in the buffer area from the soft switch platform and resending the target response information to the user end to confirm the handshake status in the resending module includes:

[0033] The server authenticates the identity of the user end based on the message verification code and metadata key. The server sends a retransmission request to the soft switch platform based on the message anomaly detection result, obtains the target response information sent by the buffer area and forwards it to the user end, and assembles the remaining message data packets out of order through the jitter buffer, and receives the handshake confirmation information returned by the user end.

[0034] The third aspect of the present invention discloses a call packet loss processing device, comprising:

[0035] at least one processor, and

[0036] a memory communicatively connected to the at least one processor; wherein,

[0037] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the call packet loss processing method as described in any one of the first aspects of the present invention.

[0038] The fourth aspect of the present invention discloses a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the call packet loss processing method as described in any one of the first aspect of the present invention.

[0039] Compared with the prior art, the present invention has the following advantages:

[0040] The present invention proposes a method, system, device and medium for processing call packet loss, wherein the method includes the server responding to the handshake request information sent by the user end, returning the handshake response information to the user end and caching the handshake response information in the buffer area of ​​the soft switch platform; the server responding to the message anomaly detection, obtaining the target response information in the buffer area from the soft switch platform and resending it to the user end to confirm the handshake status; the server responding to the handshake confirmation information sent by the user end, returning the server handshake end information. The buffer area can reduce the probability of DTLS handshake failure caused by target message loss, improve the success rate of DTLS handshake and the reliability of connection in the VoIP system, thereby solving the packet loss problem of call center network calls. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0042] Figure 1 This is a flow chart of the call packet loss processing method of the present invention;

[0043] Figure 2 Schematic diagram of a call packet loss processing system of the present invention. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0045] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complicated and lengthy, for ordinary technicians in this field related to the content disclosed in this application, some changes in design, manufacturing or production based on the technical content disclosed in this application are just conventional technical means, and should not be understood as insufficient content disclosed in this application.

[0046] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0047] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantitative limitation, and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there may be three relationships, for example, "A and / or B" can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects before and after are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0048] Example 1

[0049] See also Figure 1 The embodiment of the present invention discloses a method for processing call packet loss, which is applied to a server of the DTLS protocol, and comprises:

[0050] 101. In response to the handshake request information sent by the user terminal, the server returns the handshake response information to the user terminal and caches the handshake response information in the cache area of ​​the soft switch platform;

[0051] It needs to be explained that the DTLS (Datagram Transport Layer Security) protocol is a variant of the TLS (Transport Layer Security) protocol. Since the TLS protocol cannot guarantee the security of data transmission on the UDP (User Datagram Protocol) transport protocol, the DTLS protocol is extended on the TLS protocol framework to become a version of TSL that supports data packet transmission, that is, the DTLS protocol is used to protect real-time communications such as (VoIP, video conferencing, etc.), and the DTLS protocol is implemented on top of UDP. UDP is a connectionless protocol. The connectionlessness of UDP means that there is no need to establish a two-end connection before sending data. The unreliability of UDP will not confirm whether the data packet is successfully delivered to the recipient, nor will it retransmit data. Therefore, when the network is unstable, data packet loss, data packet duplication, and data packet disorder are prone to problems.

[0052] Furthermore, the solution proposed by the DTLS protocol for the problem of UDP is to set a timeout retransmission mechanism. In the prior art, a timeout threshold is usually preset, and the unreceived data packets are retransmitted within the time allowed by the threshold. For example, if the downlink channel network is unstable and the handshake information sent back to the user end by the server is lost, the handshake information will be retransmitted according to the DTLS protocol. If the user end does not receive the expected message from the server end, the handshake information will be retransmitted. Conversely, if the server end does not receive the expected message, the retransmission step will be performed according to the retransmission mechanism specified in the protocol.

[0053] Furthermore, this mechanism is not perfect. If the delay is too large or the data packet is directly lost during the transmission of the uplink and downlink channels, the retransmission mechanism may not be triggered in time. For example, when the server sends the last handshake message to end the handshake stage, the server will consider that the handshake process is over and will no longer process the handshake message. The unstable network causes the user end to not receive the last handshake message from the server. In order to complete the handshake process, the user end will resend the previous handshake message that has not received a reply and expect the server to respond to the handshake message. However, after the server sends the last handshake message, it will no longer process any handshake message sent by the user end. Such frequent handshakes will consume a lot of network resources and affect the stability of the call. Therefore, this application proposes to cache the handshake response information sent by the server in the cache area constructed by the soft switch platform at the same time, and send it to the user end when it needs to be resent to avoid the above-mentioned handshake failure and waste network resources, causing call jams and affecting the stability of the call process.

[0054] In an optional embodiment, the handshake request information and the handshake response information both include a message data packet consisting of a message header, a message body, and a message verification code, the message header records a timestamp, a sequence number, a message length, a four-tuple and / or a five-tuple, the message body includes transmission data to be processed, and the message verification code includes verification information for verifying the legitimacy of the transmission data.

[0055] Specifically, the DTLS protocol is used to protect the multiple handshakes between the server and the client to establish a secure connection and the subsequent data transmission process. The defect to be solved in this application is the process of the DTLS protocol to establish a secure connection through handshake, and the subsequent data transmission process including certificate verification, encryption algorithm negotiation, key exchange and other processes are no longer considered in this application. The DTLS protocol will provide multiple types of messages according to different functions, among which the handshake message is a message data packet containing handshake request information, and the message structure includes a message header, a message body and a message verification code, among which the message header is used to record the relevant content of the message, such as the message The message type, version number and message length, etc., while the message body is used to record the data content, such as handshake messages or other types of messages. The message verification code is used to verify the integrity and authenticity of the message to prevent data tampering and forgery. The timestamp, sequence number and message length in the message header are used to distinguish different handshake information. The four-tuple (source / destination IP address, source / destination port number) or five-tuple (source / destination IP address, source / destination port number, protocol type) is used to distinguish different user terminals, so as to provide a basis for finding the corresponding response information for subsequent message anomalies (such as terminals that did not receive the last handshake message).

[0056] In an optional embodiment, the soft switch platform builds a call center under the VoIP system, the call center includes the server and multiple user terminals, the cache area is an upper-layer module loaded on the server by the soft switch platform, the upper-layer module synchronizes the communication protocol with the server and the user terminal, and the upper-layer module asynchronously processes the cache events of the handshake response information and the message exception events of the target response information.

[0057] Specifically, taking freeSwitch as an example of a soft switching platform, it is easy for technicians in this field to know that, in addition to freeSwitch, other switching platforms can also be used to build a call center when establishing a VoIP system and a call center under the support of the platform. The modular architecture of freeSwitch allows users to customize functional modules and can support multiple protocols to achieve interactive operations. The upper-level module that is set can be a sliding module and configured with a cache event to start the cabinet cache function, thereby obtaining the last handshake message sent by the server and storing it in the cache area built by the upper-level module. For the abnormal event of repeated transmission of user-side messages, the upper-level module can be called to assist the server in completing the message retransmission. It should be noted that, since the DTLS protocol is built on the basis of UDP, when the UDP thread caches information, it is often prone to overload and will discard part of the cached information, resulting in cache loss, because the server or user end fails to obtain the information in time. UDP can only process multiple cached messages synchronously. In this embodiment, the upper-level module performs the caching work independently of the UDP thread, which can eliminate the problem that the UDP thread cannot asynchronously process multiple cached information, and ensure that each handshake information sent by the server can be cached in the cache area, and the invalid cache can be discarded through subsequent verification through the detection mark to ensure that sufficient memory can be used to cache new handshake information, thereby ensuring the stability of the call.

[0058] In an optional embodiment, the step of caching the handshake response information in a buffer area of ​​a soft switch platform includes:

[0059] The soft switch platform sets a buffer area to store the message data packet of the handshake response information, and generates a detection mark including one or more of the time check, message length check and sequence continuity check according to the message header;

[0060] The time check includes a time continuity check of matching the context of a message data packet by a timestamp within a unit time; the message length check includes a check of matching the length of a digital summary of a temporary key generated by metadata in a message header with a message data packet; the sequence continuity check includes a continuity check of the associated context of serial numbers in multiple message data packets sent by the same terminal.

[0061] 102. In response to the message anomaly detection, the server obtains the target response information in the buffer area from the soft switch platform and resends it to the user end to confirm the handshake status;

[0062] In an optional embodiment, the server responds to message anomaly detection, including:

[0063] Traversing the handshake request information received by the server, and determining the handshake request information associated with the context and the associated client according to the four-tuple or five-tuple of the detection identifier;

[0064] It is determined whether the associated client repeatedly sends handshake request information according to the detection identifier, and the target response information not received by the client is determined according to the time check, message length check and sequence continuity check of the detection identifier.

[0065] In an optional embodiment, obtaining the target response information of the buffer area from the soft switch platform and resending it to the user end to confirm the handshake state includes:

[0066] The server authenticates the identity of the user end based on the message verification code and metadata key. The server sends a retransmission request to the soft switch platform based on the message anomaly detection result, obtains the target response information sent by the buffer area and forwards it to the user end, and assembles the remaining message data packets out of order through the jitter buffer, and receives the handshake confirmation information returned by the user end.

[0067] Specifically, the handshake process includes the process of establishing a two-way communication connection through multiple handshakes, wherein multiple handshakes will correspond to multiple handshake messages, and the handshake messages need to be confirmed by both ends. Therefore, the time check is mainly used as a basis for distinguishing different handshake messages, especially in identifying that multiple handshake request messages are repeatedly sent due to no handshake response message received in a short period of time, so that abnormal situations can be quickly confirmed, and the time check can also confirm the relationship between the response information and the request information cached by the server in a short period of time, thereby reducing the network resource consumption wasted by multiple confirmations and quickly solving the problem of call stability. Although the time check is set and cooperated with the timeout mechanism of the DTLS protocol, it is still impossible to achieve the purpose of more accurately judging abnormal situations and the target response information expected by the terminal. Therefore, the message length and sequence continuity are proposed. In order to more accurately determine whether there is a message anomaly (that is, the terminal has not received the expected handshake response information), the message length of the handshake message will be different due to the different information carried in its metadata, and the sequence number can detect the handshake message through the number information like the MAC code, but the handshake message has time attributes and continuity attributes of the same terminal in addition to the context relationship. It is also necessary to consider whether the received handshake message has a problem of continuous sequence number interruption in a short period of time, and whether there is a problem of losing part of the sequence in a continuous sequence for a long time. Therefore, applying time check, message length check and sequence continuity check to anomaly detection at the same time can allow the server to more accurately identify the occurrence of abnormal situations and make corresponding remedies in a timely manner, quickly repairing the call stability while reducing network overhead as much as possible.

[0068] 103. The server returns server handshake completion information in response to the handshake confirmation information sent by the client.

[0069] It is necessary to explain the specific steps of the DTLS protocol to complete the handshake. The client sends a ClientHello message to the server, which contains the encryption algorithm supported by the client, the protocol version, the random number and other information. This random number is used for subsequent key negotiation. After receiving the ClientHello message, the server replies with a ServerHello message, which contains the encryption algorithm, protocol version, random number and other information selected by the server. The server's random number is also used for key negotiation together with the client's random number.

[0070] Further, the server sends a Certificate message, including the server's digital certificate. The digital certificate is used to verify the identity of the server and ensure that the client communicates with the correct server. In some cases, the server may need to send a ServerKeyExchange message to transmit a temporary key generated by the server. This temporary key is used to negotiate the session key. The server sends a ServerHelloDone message to indicate the end of the server handshake message. This step often causes the problem mentioned above that the server thinks the handshake is over but the user end does not receive the message, resulting in repeated handshake requests. The method of the present application can be used to cache the handshake response information sent by the server to solve the call packet loss problem caused by this step. The corresponding subsequent handshake steps include: after the client receives the handshake message from the server, verify the server's digital certificate. If the certificate is valid, the client continues the subsequent handshake process. The client generates a random number as a pre-master key, and uses the public key in the server certificate to encrypt the pre-master key, and then sends it to the server. If the server requires the client to provide a digital certificate to verify the identity, the client sends a CertificateVerify message. This message contains a piece of data encrypted by the client using its own private key, and the server can use the client's public key for decryption verification. The client and server respectively send ChangeCipherSpec messages, indicating that new encryption parameters will be used starting from this message. This marks the end of the asymmetric encryption algorithm used in the handshake process and the beginning of the symmetric encryption algorithm. The client and server respectively send Finished messages, which contain the hash value of the handshake message. This hash value is used to verify the integrity of the handshake process to ensure that neither party has been tampered with during the handshake process. The above steps involve the content of the data transmission part. This application mainly considers how to solve the problem of call packet loss caused by repeated handshake requests due to the failure to receive handshake information from the server to the user. After this problem is solved, the subsequent data exchange handshake process will no longer be affected by network fluctuations or poor network stability.

[0071] The present invention can reduce the probability of DTLS handshake failure caused by target message loss through the cache area, reduce handshake failure caused by packet loss, improve the stability and quality of VoIP calls, reduce the frequency of re-handshake, save network resources and system performance, and reduce call delays. It does not require major modifications to the existing DTLS protocol, and can be achieved by simply adding a cache mechanism, thereby solving the packet loss problem of call center network calls.

[0072] like Figure 2 As shown, the second aspect of the present invention discloses a call packet loss processing system, the system comprising:

[0073] A cache module, used for the server to respond to the handshake request information sent by the user end, return the handshake response information to the user end and cache the handshake response information in the cache area of ​​the soft switch platform;

[0074] A resending module, used for the server to obtain the target response information of the buffer area from the soft switch platform in response to the message abnormality detection and resend it to the user end to confirm the handshake status;

[0075] The confirmation module is used for the server to respond to the handshake confirmation information sent by the user end and return the server handshake completion information.

[0076] In an optional embodiment, the handshake request information and the handshake response information in the cache module both include a message data packet consisting of a message header, a message body, and a message verification code, the message header records a timestamp, a sequence number, a message length, a four-tuple and / or a five-tuple, the message body includes transmission data to be processed, and the message verification code includes verification information for verifying the legitimacy of the transmission data.

[0077] In an optional embodiment, the soft switch platform in the cache module builds a call center under the VoIP system, the call center includes the server and multiple user terminals, the cache area is an upper-layer module loaded on the server by the soft switch platform, the upper-layer module synchronizes the communication protocol with the server and the user terminal, and the upper-layer module asynchronously processes the cache events of the handshake response information and the message exception events of the target response information.

[0078] In an optional embodiment, the cache module caches the handshake response information to a cache area of ​​a soft switch platform, including:

[0079] The soft switch platform sets a buffer area to store the message data packet of the handshake response information, and generates a detection mark including one or more of the time check, message length check and sequence continuity check according to the message header;

[0080] The time check includes a time continuity check of matching the context of a message data packet by a timestamp within a unit time; the message length check includes a check of matching the length of a digital summary of a temporary key generated by metadata in a message header with a message data packet; the sequence continuity check includes a continuity check of the associated context of serial numbers in multiple message data packets sent by the same terminal.

[0081] In an optional embodiment, the server in the retransmission module responds to message anomaly detection, including:

[0082] Traversing the handshake request information received by the server, and determining the handshake request information associated with the context and the associated client according to the four-tuple or five-tuple of the detection identifier;

[0083] It is determined whether the associated client repeatedly sends handshake request information according to the detection identifier, and the target response information not received by the client is determined according to the time check, message length check and sequence continuity check of the detection identifier.

[0084] In an optional embodiment, the step of obtaining the target response information in the buffer area from the soft switch platform and resending the target response information to the user end to confirm the handshake status in the resending module includes:

[0085] The server authenticates the identity of the user end based on the message verification code and metadata key. The server sends a retransmission request to the soft switch platform based on the message anomaly detection result, obtains the target response information sent by the buffer area and forwards it to the user end, and assembles the remaining message data packets out of order through the jitter buffer, and receives the handshake confirmation information returned by the user end.

[0086] The third aspect of the present invention discloses a call packet loss processing device, comprising:

[0087] at least one processor, and

[0088] a memory communicatively connected to the at least one processor; wherein,

[0089] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the call packet loss processing method as described in any one of the first aspects of the present invention.

[0090] The computer device may be a terminal, and the computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a call packet loss processing method is implemented. The display screen of the computer device may be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device may be a touch layer covering the display screen, or a key, trackball or touchpad provided on the housing of the computer device, or an external keyboard, touchpad or mouse, etc.

[0091] The fourth aspect of the present invention discloses a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the call packet loss processing method as described in any one of the first aspect of the present invention.

[0092] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned call packet loss processing method. Among them, any reference to memory, storage, database or other media used in the embodiments provided in the present application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0093] Alternatively, if the above modules of the present invention are implemented in the form of software function modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention can be essentially or partly reflected in the form of a software product that contributes to the relevant technology. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, terminal, or network device, etc.) to execute all or part of the methods of each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, RAM, ROM, magnetic disks or optical disks.

[0094] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for processing call packet loss, characterized in that: The method is applied to a server of the DTLS protocol, and the method comprises: The server responds to the handshake request information sent by the user terminal, returns the handshake response information to the user terminal and caches the handshake response information in the buffer area of ​​the soft switch platform; In response to the message anomaly detection, the server obtains the target response information in the buffer area from the soft switch platform and resends it to the user end to confirm the handshake status; The server responds to the handshake confirmation message sent by the client and returns a server handshake completion message.

2. The call packet loss processing method according to claim 1, characterized in that: The handshake request information and the handshake response information both include a message data packet consisting of a message header, a message body and a message verification code, the message header records a timestamp, a sequence number, a message length, a four-tuple and / or a five-tuple, the message body includes transmission data to be processed, and the message verification code includes verification information for verifying the legitimacy of the transmission data.

3. The call packet loss processing method according to claim 2, characterized in that: The soft switch platform constructs a call center under the VoIP system, and the call center includes the server and multiple user terminals. The cache area is an upper-layer module loaded on the server by the soft switch platform. The upper-layer module synchronizes the communication protocol with the server and the user terminal, and the upper-layer module asynchronously processes the cache event of the handshake response information and the message exception event of the target response information.

4. The call packet loss processing method according to claim 3, characterized in that: The step of caching the handshake response information in a buffer area of ​​a soft switch platform includes: The soft switch platform sets a buffer area to store the message data packet of the handshake response information, and generates a detection mark including one or more of the time check, message length check and sequence continuity check according to the message header; The time check includes a time continuity check of matching the context of a message data packet by a timestamp within a unit time; the message length check includes a check of matching the length of a digital summary of a temporary key generated by metadata in a message header with a message data packet; the sequence continuity check includes a continuity check of the associated context of serial numbers in multiple message data packets sent by the same terminal.

5. The call packet loss processing method according to claim 4, characterized in that: The server responds to the message anomaly detection, including: Traversing the handshake request information received by the server, and determining the handshake request information associated with the context and the associated client according to the four-tuple or five-tuple of the detection identifier; It is determined whether the associated client repeatedly sends handshake request information according to the detection identifier, and the target response information not received by the client is determined according to the time check, message length check and sequence continuity check of the detection identifier.

6. The call packet loss processing method according to claim 5, characterized in that: The step of obtaining target response information of a buffer area from the soft switch platform and resending the information to the user end to confirm the handshake status includes: The server authenticates the identity of the user end based on the message verification code and metadata key. The server sends a retransmission request to the soft switch platform based on the message anomaly detection result, obtains the target response information sent by the buffer area and forwards it to the user end, and assembles the remaining message data packets out of order through the jitter buffer, and receives the handshake confirmation information returned by the user end.

7. A call packet loss processing system, characterized in that: The system comprises: A cache module, used for the server to respond to the handshake request information sent by the user end, return the handshake response information to the user end and cache the handshake response information in the cache area of ​​the soft switch platform; A resending module, used for the server to obtain the target response information of the buffer area from the soft switch platform in response to the message abnormality detection and resend it to the user end to confirm the handshake status; The confirmation module is used for the server to respond to the handshake confirmation information sent by the user end and return the server handshake completion information.

8. A call packet loss processing device, characterized in that: include: at least one processor, and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the call packet loss processing method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the call packet loss processing method as described in any one of claims 1 to 7.

Images