Communication connection establishment method and apparatus, and electronic device

Abstract

The embodiment of the invention provides a communication connection establishment method and device and electronic equipment, and is applied to the technical field of communication. By applying the method provided by the embodiment of the invention, the passive receiver can directly realize the waiting process of skipping ICE to complete detection by judging whether the DTLS connection state information, the current remote address and the DTLS protocol packet source address are the same or not, the remote address of the passive receiver is directly updated, and the subsequent handshake process is carried out based on the updated address, so that the detection efficiency is improved. Therefore, the passive receiver can update the far-end address in time, and the situation of handshake delay or handshake failure caused by the fact that the far-end address is not updated in time is avoided, so that the communication connection establishment efficiency of the passive receiver and the active connection party is improved.

Description

A communication connection establishment method, apparatus and electronic device Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication connection establishment method, apparatus and electronic device. Background Technology

[0002] In WebRTC (Web Real-Time Communication) systems, to ensure the security of media streams, the DTLS (Datagram Transport Layer Security) protocol is typically used to encrypt and transmit RTP (Real-time Transport Protocol) media streams, i.e., the DTLS-SRTP scheme. During the DTLS handshake process, the communicating parties need to negotiate encryption suites, exchange certificates, and establish a secure channel.

[0003] However, in existing technologies, there is a handshake delay between the passive receiver and the active connection provider, which can easily lead to errors in the passive receiver's response to the DTLS handshake packet, resulting in low efficiency in establishing a communication connection between the two parties. Summary of the Invention

[0004] The purpose of this application is to provide a communication connection establishment method, apparatus, and electronic device to improve the efficiency of establishing a communication connection between a passive receiver and an active connection provider. The specific technical solution is as follows: In a first aspect of this application, a communication connection establishment method is provided, applied to a passive receiver in a communication system. The communication system further includes an active connection party, which actively sends a handshake request to the passive receiver. The passive receiver receives and responds to the handshake request. The method includes: receiving a data packet from the active connection party; determining whether the data packet is a DTLS protocol packet based on the first byte of the data packet; if the data packet is a DTLS protocol packet, determining whether the connection role in this handshake is a passive receiver according to the DTLS protocol rules; if the receiver is determined to be a passive receiver, obtaining the current DTLS connection state information; if the DTLS connection state information indicates that the handshake has not yet been completed, obtaining the source address in the data packet; determining whether the source address is a preset loopback address; if the source address is not a preset loopback address, updating the current remote address of the passive receiver to the source address; and continuing to execute the DTLS handshake process based on the updated remote address to complete the establishment of a communication connection with the active connection party.

[0005] In one possible implementation, determining whether the data packet is a DTLS protocol packet based on the first byte of the data packet includes: determining whether the first byte of the data packet is within the range of [20, 64]; if so, the data packet is considered to be a DTLS protocol packet.

[0006] In one possible implementation, determining whether the connection role in this handshake is a passive receiver according to the DTLS protocol rules includes: obtaining the user's DTLS role setting information; if the user's DTLS role setting information indicates an undetermined state, determining whether the sender of the DTLS protocol packet is the user; if not, determining that the user's connection role in this handshake is the passive receiver; if so, determining that the user's connection role in this handshake is the active connection party.

[0007] In one possible implementation, updating the current remote address of the passive receiver to the source address includes: obtaining the channel type corresponding to the DTLS protocol packet and the current remote address of the passive receiver corresponding to the channel type; if the current remote address is different from the source address, updating the current remote address of the passive receiver corresponding to the channel type to the source address in the DTLS protocol packet.

[0008] In one possible implementation, the method further includes: not updating the current remote address when the DTLS connection state information indicates that a connection has been established, or the source address in the DTLS protocol packet is a preset loopback address, or the current remote address is the same as the source address.

[0009] In one possible implementation, determining that the DTLS connection state indicates the handshake has not yet been completed specifically includes: obtaining the current state identifier in the DTLS connection state machine maintained by the passive receiver; if the current state identifier is a NEW state, then determining that the DTLS connection state indicates the handshake has not yet been completed; wherein, the NEW state means that: the passive receiver has created the corresponding DTLS connection object, but has not yet received the Client Hello message (the first message sent by the active connection to the passive receiver during the handshake process) from the active connection party, or although it has received the Client Hello message, it has not yet completed the parsing and response processing of the message.

[0010] In one possible implementation, the preset loopback address is a loopback address recorded and stored by the TURN (Traversal Using Relays around NAT) module during the ICE (Interactive Connectivity Establishment) negotiation process of the IPPBX (Internet Protocol Private Branch Exchange). Determining whether the source address is the preset loopback address includes: obtaining the loopback address record maintained by the IPPBX system; if the source address of the data packet is the same as the address in the loopback address record, then the source address is determined to be the preset loopback address, and the update of the current remote address is skipped; if the source address of the data packet is different from the address in the loopback address record, then the source address is determined not to be the preset loopback address.

[0011] In one possible implementation, continuing the DTLS handshake process based on the updated remote address includes: after updating the remote address, constructing a Server Hello (a message from the passive receiver responding to the Client Hello) message and sending it to the active connection party via the updated remote address.

[0012] In a second aspect of this application, a communication connection establishment apparatus is provided, applied to a passive receiver in a communication system. The communication system further includes an active connection party, which is configured to actively send a handshake request to the passive receiver, and the passive receiver is configured to receive and respond to the handshake request. The apparatus includes: a DTLS protocol packet determination module, configured to receive a data packet from the active connection party and determine whether the data packet is a DTLS protocol packet based on the first byte of the data packet; and a connection role determination module, configured to determine its own role according to DTLS protocol rules if the data packet is a DTLS protocol packet. The connection role in this handshake is determined to be that of a passive receiver; the connection status and source address acquisition module is used to acquire the current DTLS connection status information if it is determined to be a passive receiver; if the DTLS connection status information indicates that the handshake has not been completed, it acquires the source address in the data packet; the remote address update module is used to determine whether the source address is a preset loopback address; if the source address is not a preset loopback address, it updates the current remote address of the passive receiver to the source address; the communication establishment module is used to continue the DTLS handshake process based on the updated remote address to complete the communication connection establishment with the active connection party.

[0013] In one possible implementation, the DTLS protocol packet determination module includes: a first byte value determination submodule, specifically used to determine whether the first byte of the data packet is within the range of [20, 64]; if so, the data packet is considered to be a DTLS protocol packet.

[0014] In one possible implementation, the connection role determination module includes: a DTLS role setting information acquisition and determination submodule, specifically used to acquire its own DTLS role setting information, and when its own DTLS role setting information indicates an undetermined state, determine whether the sender of the DTLS protocol packet is itself; if not, determine that its connection role in this handshake is the passive receiver; if yes, determine that its connection role in this handshake is the active connection party.

[0015] In one possible implementation, the remote address update module includes: a channel type acquisition submodule, specifically used to acquire the channel type corresponding to the DTLS protocol packet and the initial current remote address of the passive receiver corresponding to the channel type; and a remote address update submodule, specifically used to update the initial current remote address of the passive receiver corresponding to the channel type to the source address in the DTLS protocol packet when the initial current remote address is different from the source address.

[0016] In one possible implementation, the apparatus further includes: a remote address non-update determination module, configured to not update the current remote address when the DTLS connection state information indicates that a connection has been established, or the source address in the DTLS protocol packet is a preset loopback address, or the current remote address is the same as the source address.

[0017] In one possible implementation, the connection state and source address acquisition module includes: a current state identifier acquisition submodule, specifically used to acquire the current state identifier in the DTLS connection state machine maintained by the passive receiver; and a current state identifier judgment submodule, specifically used to determine that if the current state identifier is a NEW state, the DTLS connection state indicates that the handshake has not yet been completed; wherein, the NEW state means that: the passive receiver has created the corresponding DTLS connection object, but has not yet received the Client Hello message from the active connection party, or although it has received the Client Hello message, it has not yet completed the parsing and response processing of the message.

[0018] In one possible implementation, the preset loopback address is a loopback address recorded and stored by the TURN module during the ICE negotiation process of the IPPBX system; the remote address update module includes: a loopback address record acquisition submodule, specifically used to acquire the loopback address record maintained by the IPPBX system; and an address judgment submodule, specifically used to determine that if the source address of the data packet is the same as the address in the loopback address record, the source address is the preset loopback address, and the update of the current remote address is skipped; if the source address of the data packet is different from the address in the loopback address record, the source address is determined not to be the preset loopback address.

[0019] In one possible implementation, the communication establishment module includes a Server Hello message construction submodule, specifically used to construct a Server Hello message and send it to the initiating connection party via the updated remote address after updating the remote address.

[0020] In a third aspect of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any of the first aspects of this application.

[0021] In another aspect of the embodiments of this application, a computer-readable storage medium is provided, characterized in that the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method as described in any of the first aspects of the embodiments of this application.

[0022] Compared with the prior art, the embodiments of this application have at least the following technical effects: The communication connection establishment method, apparatus, and electronic device provided in the embodiments of this application receive a data packet from the active connection party, and determine whether the data packet is a DTLS protocol packet based on the first byte of the data packet; if the data packet is the DTLS protocol packet, determine whether the connection role in this handshake is a passive receiver according to the DTLS protocol rules; if it is determined that it is a passive receiver, obtain the current DTLS connection state information; if the DTLS connection state information indicates that the handshake has not been completed, obtain the source address in the data packet; determine whether the source address is a preset loopback address; if the source address is not a preset loopback address, update the current remote address of the passive receiver to the source address; and continue to execute the DTLS handshake process based on the updated remote address to complete the communication connection establishment with the active connection party.

[0023] By applying the method of this application embodiment, the passive receiver can directly update its remote address by judging whether the DTLS connection state information, the current remote address, and the source address of the DTLS protocol packet are the same, thus skipping the waiting process of ICE completion detection and directly updating the remote address of the passive receiver. The subsequent handshake process is then performed based on the updated address, enabling the passive receiver to update the remote address in a timely manner and avoiding handshake delays or failures due to the remote address not being updated in time. This improves the efficiency of establishing a communication connection between the passive receiver and the active connection party.

[0024] Of course, implementing any method of the embodiments of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0026] Figure 1 is an interactive schematic diagram of establishing a communication connection provided by the prior art; Figure 2 is a flowchart of a communication connection establishment method provided by an embodiment of this application; Figure 3 is an interactive schematic diagram of establishing a communication connection provided by an embodiment of this application; Figure 4 is another flowchart of a communication connection establishment method provided by an embodiment of this application; Figure 5 is a structural schematic diagram of a communication connection establishment device provided by an embodiment of this application; Figure 6 is a structural schematic diagram of an electronic device provided by an embodiment of this application. Detailed Implementation

[0027] 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 some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0028] IPPBX is a telephone exchange system based on the IP (Internet Protocol) protocol, used to manage telephone communications within an enterprise. IPPBX systems offer many advanced features not available in traditional PBX (Private Branch Exchange) systems.

[0029] In WebRTC (Web Real-Time Communication) systems, to ensure the security of media streams, the DTLS protocol is typically used to encrypt and transmit RTP (Real-time Transport Protocol) media streams, namely the DTLS-SRTP (Datagram Transport Layer Security - Secure Real-time Transport Protocol) scheme. During the DTLS handshake process, the communicating parties need to negotiate encryption suites, exchange certificates, and establish a secure channel. Based on the SDP (Session Description Protocol) negotiation results, one party acts as the active connection provider, and the other as the passive receiver.

[0030] However, the applicant discovered that the IPPBX currently using Asterisk / FreeSwitch as the call engine has at least the following technical issues in its WebRTC implementation: 1. Delayed remote address update: By default, the initial remote address in the initial SDP is used, and the switch is only completed after ICE has finished negotiating the candidate address. This causes additional delays for the Passive role, resulting in incorrect DTLS protocol packets (Client Hello) responses to the Active role.

[0031] 2. Address inconsistency in NAT (Network Address Translation Traversal) traversal scenarios: In complex network environments (NAT / firewall), the following situation may occur: the remote candidate address determined by ICE negotiation is <192.168.1.100:5004>, while the actual source address of the Client Hello received is <192.168.1.100:5006> (different ports).

[0032] Figure 1 illustrates the process of establishing a communication connection through a DTLS handshake between two parties in the prior art. The initiating party and the passive receiving party negotiate SDP. The client sends "SDP Offer (a=setup:active)" to the server. The server receives this message, parses it, and obtains the initial remote address as the ICE candidate address in the SDP, for example, "5004" in "203.0.113.10; 5004" shown in Figure 1. The server then returns a response message "SDP Answer (a=setup:passive)" to the client. After completing the SDP test, both parties perform ICE tests in parallel, i.e., sending "STUN Binding Request" to each other and waiting for a "STUN Binding Response" from the other party. The ICE test of the initiating party is faster than that of the passive receiving party. Therefore, when the initiating party completes its ICE test, the passive receiving party has not yet completed its ICE test.

[0033] In practical applications, when the initiating party completes the ICE test, it immediately sends a DTLS protocol packet to enter the DTLS handshake phase. The passive receiver, however, must wait for the ICE test to complete before it can enter the DTLS handshake phase and process the DTLS protocol packet. This causes a delay in the handshake process. Furthermore, if the source address in the DTLS protocol packet sent by the initiating party changes (for example, as shown in Figure 1, the address changes from 5004 to 5006), while the passive receiver's remote address remains the initial default address and has not been updated in time, the response generated by the passive receiver in response to the DTLS protocol packet cannot be sent to the correct port address. This can result in the Server Hello response failing to reach the initiating connection due to the unupdated remote address, causing a handshake delay of at least one second or even connection establishment failure.

[0034] To solve at least one of the above-mentioned technical problems, a first aspect of the present application provides a communication connection establishment method, applied to a passive receiver in a communication system. The communication system further includes an active connection party, which is used to actively send a handshake request to the passive receiver, and the passive receiver is used to receive and respond to the handshake request. The method includes the steps shown in FIG2: Step S201: Receive a data packet from the active connection party, and determine whether the data packet is a DTLS protocol packet based on the first byte of the data packet.

[0035] In the embodiments of this application, the two parties in the communication system are typically a client and a server. Either party can act as either the active connection provider or the passive receiver, depending on the specific application scenario. For example, in a communication system, the client is often the active connection provider, and the IPPBX server is often the passive receiver.

[0036] When determining whether a packet is a DTLS packet based on its first byte, it can be determined whether the value of the first byte is within a preset range corresponding to the DTLS protocol packet. In one possible implementation, it can be determined whether the value of the first byte of the packet is within the range [20, 64]; if so, the packet is considered a DTLS protocol packet. Here, the first byte is a preset byte range that can identify a DTLS protocol packet; for example, it can be the starting position of the packet, i.e., the first byte.

[0037] If the packet is determined not to be a DTLS protocol packet based on the first byte of the packet, it can then be further judged and processed according to other protocols, such as RTP, RTCP (RTP Control Protocol), STUN (SessionTraversal Utilities for NAT), etc.

[0038] Step S202: If the data packet is a DTLS protocol packet, determine whether the connection role in this handshake is a passive receiver according to the DTLS protocol rules.

[0039] The DTLS protocol rules stipulate that whoever sends the data packet first is the client (i.e., the active party, the active role), and the receiver automatically becomes the server (i.e., the passive party, the passive role). In one possible implementation, the connection role can be determined through the following steps: Obtain the user's own DTLS role settings. If the user's DTLS role settings indicate an undetermined state, determine whether the sender of the DTLS protocol packet is the user themselves. If not, determine that the user's connection role in this handshake is the passive party; if so, determine that the user's connection role in this handshake is the active party.

[0040] In practical applications, if the connection role of the client or server is determined, the corresponding role settings will be modified to mark the current connection role. If the DTLS role setting is "actpass" (i.e., undetermined), it means that the current connection role has not yet been determined. Therefore, it is necessary to determine the connection role according to the DTLS protocol rules.

[0041] Step S203: If it is determined that it is a passive receiver, then obtain the current DTLS connection state information; if the DTLS connection state information indicates that the handshake has not been completed, then obtain the source address in the data packet.

[0042] During the DTLS handshake process, a DTLS connection state machine exists to describe the current DTLS connection state of the communicating parties. When the DTLS connection state machine indicates that the passive receiver's current DTLS connection state information (i.e., the current state identifier, connection) is in the NEW state, the DTLS connection state is considered to indicate that the handshake is not complete.

[0043] During the DTLS handshake process, the DTLS protocol packet sent by the active connection party to the passive receiver includes a Client Hello message (the first message sent by the active connection party to the passive receiver). After receiving this message, the passive receiver parses and processes it, generates a Server Hello message, and returns it to the active connection party. The active connection party completes the handshake upon receiving the Server Hello message.

[0044] When the passive receiver has created the corresponding DTLS connection object but has not yet received the Client Hello message from the active receiver, or has received the Client Hello message but has not yet completed the parsing and response processing of the message, the handshake has not yet been completed. At this time, the current state flag in the DTLS connection state machine maintained by the passive receiver is still in the NEW state.

[0045] Step S204: Determine whether the source address is the preset loopback address. If the source address is not the preset loopback address, update the current remote address of the passive receiver to the source address.

[0046] The source address in the data packet refers to the port address in the DTLS protocol packet. This source address may not be the same as the remote address of the server (i.e., the passive receiver). In this case, the server's remote address needs to be updated to the source address. However, if the source address is a preset loopback address, this address is only used for local client communication, and the server cannot respond to the client through this address. Therefore, when the source address is a preset loopback address, the server's remote address is not updated.

[0047] Step S205: Continue the DTLS handshake process based on the updated remote address to complete the establishment of a communication connection with the initiating connection party.

[0048] After updating the remote address of the server, the addresses of both communicating parties are the same. During the subsequent DTLS handshake process, it can be ensured that the client can receive the server's response in a timely manner to complete the establishment of the communication connection between the two parties.

[0049] In one possible implementation, after updating the remote address, the server (i.e., the passive receiver) parses and processes the Client Hello message sent by the client, constructs a Server Hello message, and sends it to the active connection party via the updated remote address, thereby completing the DTLS handshake. The constructed Server Hello message is based on the updated remote address; that is, the address in the Server Hello message is the same as that in the Client Hello message, ensuring that the client can receive the message.

[0050] By applying the method of this application embodiment, the passive receiver can directly update its remote address by judging whether the DTLS connection state information, the current remote address, and the source address of the DTLS protocol packet are the same, thus skipping the waiting process of ICE completion detection and directly updating the remote address of the passive receiver. The subsequent handshake process is then performed based on the updated address, enabling the passive receiver to update the remote address in a timely manner and avoiding handshake delays or failures due to the remote address not being updated in time. This improves the efficiency of establishing a communication connection between the passive receiver and the active connection party.

[0051] In this embodiment of the application, if the DTLS connection status information indicates that a connection has been established, or the source address in the DTLS protocol packet is a preset loopback address, or the current remote address is the same as the source address, then the current remote address of the passive receiver will not be updated.

[0052] In one possible implementation, if the source address is not the preset loopback address, updating the remote address of the passive receiver also requires determining the channel type to update the remote address corresponding to the channel type. In one example, the remote address update can be achieved through the following steps: Step A: Obtain the channel type corresponding to the DTLS protocol packet and the current remote address of the passive receiver corresponding to that channel type.

[0053] Step B: If the current remote address is different from the source address, update the current remote address of the passive receiver corresponding to the channel type to the source address in the DTLS protocol packet.

[0054] The channel type can include RTP channels and RTCP channels. In one example, the channel type can be determined by a preset byte in the DTLS protocol packet, where the preset byte represents the channel type. In another example, if the value of the preset byte is within the first value range, the corresponding channel type is an RTP channel; if the value of the preset byte is within the second value range, the corresponding channel type is an RTCP channel. The first and second value ranges do not overlap.

[0055] In one possible implementation, the preset loopback address in this application embodiment is the loopback address recorded and stored by the TURN module of the IPPBX system during the ICE negotiation process; then determining whether the source address is the preset loopback address may include the following steps: Step 1: Obtain the loopback address record maintained by the IPPBX system.

[0056] Step 2: If the source address of the data packet is the same as the address in the loopback address record, then the source address is determined to be the preset loopback address, and the update of the current remote address is skipped.

[0057] Step 3: If the source address of the data packet is different from the address in the loopback address record, then it is determined that the source address is not the preset loopback address.

[0058] The TURN module is used to facilitate communication negotiation between the client and server. It stores a preset loopback address for self-testing and internal communication of the local network service. The passive receiver cannot send responses to the active connection party via this address. Therefore, when the source address is the preset loopback address, the server skips updating the current remote address.

[0059] The following example illustrates the interaction process between the client (active connection party) and the server (passive receiver) during the DTLS handshake in this embodiment of the application. As shown in Figure 3, the client and server first negotiate SDP. At this time, the server determines the initial remote address as "5004". After the negotiation, they perform ICE detection in parallel. The client completes the ICE detection before the server and directly enters the DTLS handshake phase, sending a DTLS protocol packet to the server. At this time, the server has not yet completed the ICE detection.

[0060] However, the server can proceed without waiting for ICE to complete the check. First, it checks if the current connection flag in its maintained DTLS connection state machine is in the NEW state. If so, it retrieves the source address (5006) from the DTLS packet and checks if this address is the preset loopback address. If not, it compares the source address (5006) with the current remote address (5004). If they differ, it updates the current remote address to 5006. The Client Hello message is then processed directly according to address 5006, generating a Server Hello message to be returned to the client, thus completing the DTLS handshake. After the handshake is complete, the server changes the current connection flag in its maintained DTLS connection state machine to the EXISTING state.

[0061] In another example, as shown in Figure 4, the execution flow of the server during the DTLS handshake is illustrated. After receiving the DTLS packet, the server checks its own connection state. If the current state flag in its maintained DTLS connection state machine is NEW, it determines whether the source address (SA) in the DTLS packet is the preset loopback address. If so, it means that ICE has been correctly configured, and the server's remote address is not updated; the DTLS handshake process continues directly. If not, it determines whether the channel type corresponding to the DTLS packet is an RTP channel or an RTCP channel.

[0062] Obtain the remote address corresponding to the channel type (e.g., obtain the current remote address of the RTP channel or the current remote address of the RTCP channel), determine whether the current remote address is the same as the source address (SA), if they are different, update the current remote address to the source address and continue the DTLS handshake process, and send the DTLS response packet to the client based on the updated remote address.

[0063] If the current state flag in the DTLS connection state machine maintained by itself is EXISITING, or the current remote address is the same as the source address, then no remote address update will be performed.

[0064] By applying the method of this application embodiment, the passive receiver can directly update its remote address by judging whether the DTLS connection state information, the current remote address, and the source address of the DTLS protocol packet are the same, thus skipping the waiting process of ICE completion detection and directly updating the remote address of the passive receiver. The subsequent handshake process is then performed based on the updated address, enabling the passive receiver to update the remote address in a timely manner and avoiding handshake delays or failures due to the remote address not being updated in time. This improves the efficiency of establishing a communication connection between the passive receiver and the active connection party.

[0065] In a second aspect of this application, a communication connection establishment apparatus is provided, as shown in FIG5, applied to a passive receiver in a communication system. The communication system further includes an active connection party, which is used to actively send a handshake request to the passive receiver, and the passive receiver is used to receive and respond to the handshake request. The apparatus includes: a DTLS protocol packet determination module 501, used to receive a data packet from the active connection party and determine whether the data packet is a DTLS protocol packet based on the first byte of the data packet; and a connection role determination module 502, used to determine the connection role according to DTLS protocol rules when the data packet is the DTLS protocol packet. The connection state and source address acquisition module 503 is used to determine whether the connection role in this handshake is a passive receiver; if it is determined to be a passive receiver, it acquires the current DTLS connection state information; if the DTLS connection state information indicates that the handshake has not been completed, it acquires the source address in the data packet; the remote address update module 504 is used to determine whether the source address is a preset loopback address; if the source address is not a preset loopback address, it updates the current remote address of the passive receiver to the source address; the communication establishment module 505 is used to continue the DTLS handshake process based on the updated remote address to complete the communication connection establishment with the active connection party.

[0066] In one possible implementation, the DTLS protocol packet determination module includes: a first byte value determination submodule, specifically used to determine whether the first byte of the data packet is within the range of [20, 64]; if so, the data packet is considered to be a DTLS protocol packet.

[0067] In one possible implementation, the connection role determination module includes: a DTLS role setting information acquisition and determination submodule, specifically used to acquire its own DTLS role setting information, and when its own DTLS role setting information indicates an undetermined state, determine whether the sender of the DTLS protocol packet is itself; if not, determine that its connection role in this handshake is the passive receiver; if yes, determine that its connection role in this handshake is the active connection party.

[0068] In one possible implementation, the remote address update module includes: a channel type acquisition submodule, specifically used to acquire the channel type corresponding to the DTLS protocol packet and the initial current remote address of the passive receiver corresponding to the channel type; and a remote address update submodule, specifically used to update the initial current remote address of the passive receiver corresponding to the channel type to the source address in the DTLS protocol packet when the initial current remote address is different from the source address.

[0069] In one possible implementation, the apparatus further includes: a remote address non-update determination module, configured to not update the current remote address when the DTLS connection state information indicates that a connection has been established, or the source address in the DTLS protocol packet is a preset loopback address, or the current remote address is the same as the source address.

[0070] In one possible implementation, the connection state and source address acquisition module includes: a current state identifier acquisition submodule, specifically used to acquire the current state identifier in the DTLS connection state machine maintained by the passive receiver; and a current state identifier judgment submodule, specifically used to determine that if the current state identifier is a NEW state, the DTLS connection state indicates that the handshake has not yet been completed; wherein, the NEW state refers to: the passive receiver has created the corresponding DTLS connection object, but has not yet received the Client Hello message from the active connection party, or although it has received the Client Hello message, it has not yet completed the parsing and response processing of the message.

[0071] In one possible implementation, the preset loopback address is a loopback address recorded and stored by the TURN module during the ICE negotiation process of the IPPBX system; the remote address update module includes: a loopback address record acquisition submodule, specifically used to acquire the loopback address record maintained by the IPPBX system; and an address judgment submodule, specifically used to determine that if the source address of the data packet is the same as the address in the loopback address record, the source address is the preset loopback address, and the update of the current remote address is skipped; if the source address of the data packet is different from the address in the loopback address record, the source address is determined not to be the preset loopback address.

[0072] In one possible implementation, the communication establishment module includes a Server Hello message construction submodule, specifically used to construct a Server Hello message and send it to the initiating connection party via the updated remote address after updating the remote address.

[0073] A third aspect of this application provides an electronic device, as shown in FIG6, including a memory 601, a processor 602, and a computer program stored in the memory and executable on the processor. When the processor 602 executes the computer program, it implements the steps of any of the methods of the first aspect of this application.

[0074] In a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of any of the methods in the first aspect of the embodiments of this application.

[0075] Electronic devices can be computing devices such as desktop computers, laptops, handheld computers, and cloud servers. Those skilled in the art will understand that Figure 6 is merely an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0076] The processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0077] In some embodiments, the memory can be an internal storage unit, such as a hard disk or RAM. The memory can be a removable / non-removable, volatile / non-volatile computer system storage medium; for example, the memory is a non-volatile memory used for reading and writing non-volatile magnetic media. In other embodiments, the memory can also be an external storage device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, etc., found in electronic devices. The memory is used to store operating systems, applications, bootloaders, data, and other programs, such as program code for computer programs. The memory can also be used to temporarily store data that has been output or will be output.

[0078] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0080] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

[0081] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate to describe embodiments of this application, for example, those that can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0082] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0083] In the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0084] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

Claims

1. A method for establishing a communication connection, characterized in that, A passive receiver in a communication system, the communication system also including an active connection party, the active connection party being used to actively send a handshake request to the passive receiver, the passive receiver being used to receive and respond to the handshake request, the method comprising: receiving a data packet from the active connection party; determining whether the data packet is a DTLS protocol packet based on the first byte of the data packet; if the data packet is the DTLS protocol packet, determining whether its connection role in this handshake is a passive receiver according to the DTLS protocol rules; if it is determined to be a passive receiver, obtaining the current DTLS connection state information; if the DTLS connection state information indicates that the handshake has not been completed, obtaining the source address in the data packet; determining whether the source address is a preset loopback address; if the source address is not a preset loopback address, updating the current remote address of the passive receiver to the source address; and continuing to execute the DTLS handshake process based on the updated remote address to complete the establishment of a communication connection with the active connection party.

2. The method according to claim 1, characterized in that, The step of determining whether the data packet is a DTLS protocol packet based on the first byte of the data packet includes: determining whether the first byte of the data packet is within the range of [20, 64]; if so, the data packet is considered to be a DTLS protocol packet.

3. The method according to claim 1, characterized in that, The step of determining whether the connection role in this handshake is a passive receiver according to the DTLS protocol rules includes: obtaining the user's DTLS role setting information; if the user's DTLS role setting information indicates an uncertain state, determining whether the sender of the DTLS protocol packet is the user; if not, determining that the user's connection role in this handshake is the passive receiver; if yes, determining that the user's connection role in this handshake is the active connection party.

4. The method according to claim 1, characterized in that, The step of updating the current remote address of the passive receiver to the source address includes: obtaining the channel type corresponding to the DTLS protocol packet and the current remote address of the passive receiver corresponding to the channel type; if the current remote address is different from the source address, updating the current remote address of the passive receiver corresponding to the channel type to the source address in the DTLS protocol packet.

5. The method according to claim 1, characterized in that, The method further includes: when the DTLS connection state information indicates that a connection has been established, or the source address in the DTLS protocol packet is a preset loopback address, or the current remote address is the same as the source address, the current remote address is not updated.

6. The method according to claim 1, characterized in that, Determining that the DTLS connection state indicates that the handshake has not yet been completed specifically includes: obtaining the current state identifier in the DTLS connection state machine maintained by the passive receiver; if the current state identifier is NEW, then determining that the DTLS connection state indicates that the handshake has not yet been completed; wherein, the NEW state means that: the passive receiver has created the corresponding DTLS connection object, but has not yet received the Client Hello message from the active connection party, or has received the Client Hello message but has not yet completed the parsing and response processing of the message.

7. The method according to claim 1, characterized in that, The preset loopback address is the loopback address recorded and stored by the TURN module during the ICE negotiation process in the IPPBX system. Determining whether the source address is the preset loopback address includes: obtaining the loopback address record maintained by the IPPBX system; if the source address of the data packet is the same as the address in the loopback address record, then the source address is determined to be the preset loopback address, and the update of the current remote address is skipped; if the source address of the data packet is different from the address in the loopback address record, then the source address is determined not to be the preset loopback address.

8. The method according to claim 1, characterized in that, The step of continuing the DTLS handshake process based on the updated remote address includes: after updating the remote address, constructing a Server Hello message and sending it to the initiating connection party through the updated remote address.

9. A communication connection establishment device, characterized in that, An apparatus for use as a passive receiver in a communication system, wherein the communication system also includes an active connection party, the active connection party being used to actively send a handshake request to the passive receiver, and the passive receiver being used to receive and respond to the handshake request, the apparatus comprising: a DTLS protocol packet determination module, used to receive data packets from the active connection party and determine whether the data packet is a DTLS protocol packet based on the first byte of the data packet; a connection role determination module, used to determine whether its connection role in the current handshake is a passive receiver according to DTLS protocol rules when the data packet is the DTLS protocol packet; a connection status and source address acquisition module, used to acquire the current DTLS connection status information if it is determined to be a passive receiver; if the DTLS connection status information indicates that the handshake has not been completed, it acquires the source address in the data packet; a remote address update module, used to determine whether the source address is a preset loopback address; if the source address is not a preset loopback address, it updates the current remote address of the passive receiver to the source address; and a communication establishment module, used to continue the DTLS handshake process based on the updated remote address to complete the establishment of a communication connection with the active connection party.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method as claimed in any one of claims 1 to 8.

Images