Relay Agent-Based Channel Negotiation Method, Device, and Storage Medium

Abstract

The present application discloses a channel negotiation method, device and storage medium based on a relay agent. The present application relates to the field of electrical communication technologies. In this method, a request is sent to a relay server to obtain a relay agent address, the relay agent address is encapsulated into a candidate address of the Session Description Protocol (SDP), and is sent to the called end through the relay server. Then, the private network address in the response information fed back by the called end is parsed, and a binding request is initiated to the private network address of the called end. If the binding request fails to establish a connection with the called end, a penetration request is sent to a specified port of the relay server, and then a two-way network address channel with the called end is established through the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay agent address. The present application establishes a channel between the calling end and the called end through the relay agent address and the penetration request of the relay server, thereby improving the flexibility during media stream transmission.

Description

Technical Field

[0001] This application relates to the field of electric communication technologies, and in particular, to a channel negotiation method, device, and storage medium based on a relay proxy. Background Art

[0002] In a cross-network communication scenario, to implement media stream transmission between a mobile terminal and an enterprise intranet voice communication device, it is necessary to solve the penetration problem in a complex NAT (Network Address Translation) environment.

[0003] Currently, a static port mapping scheme is usually adopted. Manually configure a fixed public network port on the egress router and map this port to the corresponding port in the intranet, so as to implement media stream transmission between the mobile terminal and the communication device. However, the above scheme depends on manually predefined port rules and requires the public network IP of the egress router to remain fixed. When the public network IP or port changes, the mapping rules need to be readjusted, which cannot adapt to a dynamic public network environment. And when there are multiple layers of NAT between the mobile terminal and other communication devices, the port mapping rules cannot penetrate. This results in low flexibility of the traditional scheme when implementing media stream transmission.

[0004] The above content is only used to assist in understanding the technical solution of this application, and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] This application provides a channel negotiation method, device, and storage medium based on a relay proxy, aiming to solve the problem of low flexibility of the traditional scheme when implementing media stream transmission.

[0006] To achieve the above objective, a channel negotiation method based on a relay proxy provided by this application is applied to a calling end. The channel negotiation method based on a relay proxy includes the following steps:

[0007] Request a relay proxy address from a relay server, encapsulate the relay proxy address into a candidate address of the Session Description Protocol, and send it to the called end through the relay server;

[0008] Parse the private network address in the response information fed back by the called end, and initiate a binding request to the private network address of the called end;

[0009] If the binding request fails to establish a connection with the called end, send a penetration request to a specified port of the relay server. The penetration request includes the public network address of the called end, so that the relay server forwards the penetration request to the called end based on the public network address;

[0010] Establish a two-way network address channel with the called end through the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay proxy address.

[0011] In one embodiment, the step of requesting a relay proxy address from a relay server, encapsulating the relay proxy address into a candidate address of the Session Description Protocol, and sending it to the called party through the relay server includes:

[0012] Sending an address query request to a STUN server, where the relay server includes a STUN server and a TURN server;

[0013] Applying for a relay proxy port and the relay proxy address from the TURN server;

[0014] Encapsulating the relay proxy port and the relay proxy address into a candidate address list of the Session Description Protocol, and sending the candidate address list to the called party based on the relay proxy port.

[0015] In one embodiment, the step of parsing a private network address in the response information fed back by the called party and initiating a binding request to the private network address of the called party includes:

[0016] Parsing the response information fed back by the called party, and extracting the public network address and the private network address of the called party;

[0017] According to a preset policy, preferentially sending the binding request to the private network address of the called party;

[0018] If no response is received within a preset timeout threshold, sending the binding request to the public network address of the called party.

[0019] In one embodiment, after the step of parsing a private network address in the response information fed back by the called party and initiating a binding request to the private network address of the called party, it further includes:

[0020] When no feedback is received for the binding request, switching the private network address to the public network address of the called party;

[0021] Initiating a secondary binding request to the called party based on the public network address.

[0022] In one embodiment, before the step of switching the private network address to the public network address of the called party when no feedback is received for the binding request, it further includes:

[0023] If no response from the called party is received within a preset timeout threshold, determining that no feedback is received for the binding request;

[0024] Recording the number of detection failures of the current network address, and if the number of failures exceeds a preset threshold, prohibiting subsequent initiation of the binding request to the current network address.

[0025] In one embodiment, after the step of establishing a two-way network address channel with the called end by using the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay proxy address, the method further includes:

[0026] After the establishment of the two-way network address channel, exchange digital certificates with the called end based on a preset protocol and negotiate an encryption key;

[0027] Perform end-to-end encryption on the media stream by using the encryption key, and transmit the encrypted media stream to the called end based on the two-way network address channel;

[0028] If it is detected that the NAT type of the called end is a full cone type, skip the relay server and directly transmit an RTP packet to the called end through the public network address.

[0029] In one embodiment, before the step of requesting the relay server to obtain a relay proxy address, encapsulating the relay proxy address into a candidate address of the session description protocol and sending it to the called end, the method further includes:

[0030] Send a port allocation request to the relay server, so that the relay server allocates corresponding port information according to the port request;

[0031] Receive the allocated mapped port returned by the relay server;

[0032] Establish a connection channel with the relay server according to the mapped port, and request the relay server to obtain the relay proxy address based on the connection channel.

[0033] In one embodiment, before the step of, if the binding request fails to establish a connection with the called end, sending a penetration request to a specified port of the relay server, the method further includes:

[0034] Detect the local network firewall policy. If the firewall restricts the outbound port, initiate port probing to a preset port range of the relay server;

[0035] Select an available target port according to the port probing result and send the penetration request.

[0036] In addition, to achieve the above object, the present application further provides a channel negotiation device based on a relay proxy. The channel negotiation device based on a relay proxy includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. The computer program is configured to implement the steps of the above-mentioned channel negotiation method based on a relay proxy.

[0037] In addition, to achieve the above object, the present application further provides a storage medium, which is a computer-readable storage medium. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the above-described channel negotiation method based on a relay agent are implemented.

[0038] The present application provides a channel negotiation method based on a relay agent, a channel negotiation device based on a relay agent, and a storage medium. By requesting a relay agent address from a relay server, encapsulating the relay agent address into a candidate address of a session description protocol, and sending it to a called party through the relay server, then parsing network address information in response information fed back by the called party, and initiating a binding request to a private network address of the called party. If the binding request fails to establish a connection with the called party, a penetration request is sent to a specified port of the relay server, and then a two-way network address channel with the called party is established through the penetration request forwarded by the relay server and a binding request initiated by the called party to the relay agent address. The present application establishes a communication channel between a calling party and a called party through a relay agent address and a penetration request of a relay server, thereby improving the flexibility during media stream transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0040] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0041] Figure 1 It is a schematic flowchart of the first embodiment of the channel negotiation method based on a relay agent of the present application;

[0042] Figure 2 It is a schematic overall flowchart of the solution of the embodiment of the present application;

[0043] Figure 3 It is a schematic flowchart of the second embodiment of the channel negotiation method based on a relay agent of the present application;

[0044] Figure 4 It is a schematic flowchart of the third embodiment of the channel negotiation method based on a relay agent of the present application;

[0045] Figure 5 It is a schematic architecture diagram of the hardware operating environment of the channel negotiation device based on a relay agent involved in the embodiment of the present application.

[0046] The realization, functional features and advantages of the present application will be further described in conjunction with the embodiments with reference to the accompanying drawings. Detailed implementation manners

[0047] It should be understood that the specific embodiments described herein are merely used to explain the present application and are not used to limit the present application.

[0048] In order to better understand the above technical solution, the exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present application can be more thoroughly understood and the scope of the present application can be fully conveyed to those skilled in the art.

[0049] In order to better understand the above technical solution, the above technical solution will be described in detail below in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0050] The main solution of the present application is as follows: request a relay proxy address from a relay server, encapsulate the relay proxy address into the candidate address of the Session Description Protocol, and send it to the called end through the relay server; parse the private network address in the response information fed back by the called end, and initiate a binding request to the private network address of the called end. The network address information includes the private network address and the public network address of the called end; if the binding request fails to establish a connection with the called end, send a penetration request to a specified port of the relay server. The penetration request contains the public network address of the called end, so that the relay server forwards the penetration request to the called end based on the public network address; establish a two-way network address channel with the called end through the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay proxy address.

[0051] In a cross-network communication scenario, to achieve media stream transmission between a mobile terminal and a voice communication device in an enterprise intranet, it is necessary to solve the penetration problem in a complex NAT (Network Address Translation) environment. Currently, a static port mapping scheme is usually adopted, where a fixed public network port is manually configured on the egress router and mapped to the corresponding port in the intranet, so as to achieve media stream transmission between the mobile terminal and the communication device. However, the above scheme relies on manually predefined port rules and requires the public network IP of the egress router to be fixed. When the public network IP or port changes, the mapping rules need to be adjusted again, which cannot adapt to a dynamic public network environment. Also, when there are multiple layers of NAT between the mobile terminal and other communication devices, the port mapping rules cannot penetrate. This results in low flexibility of the traditional scheme in realizing media stream transmission.

[0052] By requesting the relay proxy address from the relay server, encapsulating the relay proxy address into the candidate address of the Session Description Protocol (SDP), and sending it to the called party through the relay server, then parsing the network address information in the response message fed back by the called party, and initiating a binding request to the private network address of the called party. If the binding request fails to establish a connection with the called party, a penetration request is sent to the specified port of the relay server, and then a two-way network address channel with the called party is established through the penetration request forwarded by the relay server and the binding request initiated by the called party to the relay proxy address. This application establishes a communication channel between the calling party and the called party through the relay proxy address and penetration request of the relay server, thereby improving the flexibility during media stream transmission.

[0053] Embodiment 1

[0054] Based on this, an embodiment of this application provides a channel negotiation method based on a relay proxy. Refer to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the channel negotiation method based on a relay proxy in this application. The channel negotiation method based on a relay proxy includes steps S10 to S40:

[0055] Step S10: Request the relay proxy address from the relay server, encapsulate the relay proxy address into the candidate address of the Session Description Protocol, and send it to the called party through the relay server.

[0056] In this embodiment, the calling party executes the processing actions. A media interaction system is deployed in the calling party. The calling party can be a mobile terminal, such as a mobile phone or a tablet. The relay server is a server located in the public network, which is used to forward data packets between the calling party and the called party to solve the NAT (Network Address Translation) penetration problem. The relay proxy address is a virtual address provided by the relay server, which is used to identify a specific port or channel on the relay server. The Session Description Protocol (SDP) is a protocol used to describe multimedia sessions.

[0057] The calling party obtains a relay proxy address by sending a request (such as an HTTP or WebSocket request) to the relay server. Then the calling party encapsulates the obtained relay proxy address as one of the candidate addresses into the candidate address list of the Session Description Protocol (SDP). Next, the SDP containing the relay proxy address is sent to the called party, and the called party can identify the relay proxy address after parsing the SDP.

[0058] In this embodiment, the calling end is in an external network environment, and the called end is in an internal network environment. The called end is connected to an IP private branch exchange, on which an frpc (Fast Reverse Proxy) service is installed, which can map the signaling port to be proxied (e.g., the WSS port 7443) to the frps server (e.g., port 7200). In this way, the calling end initiates a WSS connection to port 7200 of the frps and performs SIP registration, and can be successfully registered on the IP private branch exchange through the proxy.

[0059] Specifically, WSS (WebSocket Secure) is an encrypted version of WebSocket, which realizes secure WebSocket communication by combining the SSL / TLS protocol. In its specific establishment process, the calling end requests to establish a connection, and the frps server responds and negotiates the encryption method to establish the connection. After the connection is established, both parties establish a secure channel through the TLS / SSL protocol to ensure the encryption and decryption of subsequent communication data. After the encrypted channel is established, the calling end and the frps server can communicate through WebSocket data frames.

[0060] SIP (Session Initiation Protocol) registration is a key step for terminal devices to establish identity identifiers in a communication network. The main process of SIP registration is that first, the calling end sends a REGISTER request to the registration server, and the request contains the user's identity identifier (such as the SIP address) and the current network location information (such as the IP address and port). If the server needs authentication, it will return a 401 Unauthorized response, asking the client to provide authentication information. The client encrypts the user information using the Digest authentication mechanism according to the server's challenge and resends the REGISTER request. Finally, the server verifies the authentication information provided by the client. If the verification is successful, it returns a 200 OK response, indicating that the registration is successful.

[0061] After the called end receives the SDP sent by the relay server, it parses the session description protocol and obtains the relay proxy address from it. Then the called end obtains its own private network address and public network address, generates a response message according to the private network address and the public network address, and sends the response message to the relay server through the relay proxy address. After receiving the response message, the relay server feeds back the response message to the calling end.

[0062] Optionally, in this embodiment, step S10 includes:

[0063] Send an address query request to the STUN server, where the relay server includes a STUN server and a TURN server; apply to the TURN server for a relay proxy port and the relay proxy address; encapsulate the relay proxy port and the relay proxy address into the candidate address list of the Session Description Protocol, and send the candidate address list to the called party based on the relay proxy port.

[0064] Specifically, a STUN server is a server used to discover the public IP address and port in a NAT environment, usually used for NAT traversal. The address query request is a request sent by the calling party to the STUN server to obtain its public IP address and port. The TURN server is used to forward data packets when a direct P2P connection cannot be established directly. The relay proxy address and the relay proxy port are the IP address and port assigned by the TURN server for relay communication. The candidate address list is a list that lists all network addresses and ports in the SDP. The calling party first sends an address query request (such as a STUN binding request) to the STUN server. After the STUN server processes the request, it returns response information containing the public IP address and the relay proxy port. Then the calling party sends a request to the TURN server to apply for the relay proxy address and the relay proxy port. The TURN server assigns the relay proxy address and the relay proxy port and returns response information. The calling party encapsulates the relay proxy address and the relay proxy port as one of the candidate addresses into the candidate address list of the SDP and generates an SDP containing the relay proxy address. Finally, the calling party sends the SDP containing the relay proxy address to the called party through the signaling server. After the called party parses the SDP, it identifies the relay proxy address and the relay proxy port.

[0065] Through the collaborative work of the STUN server and the TURN server, the NAT traversal problem in a complex network environment is solved. First, obtain the public address through the STUN server to ensure that the calling party can discover its public communication address in the NAT environment; second, apply for the relay proxy address through the TURN server to ensure that communication can still be achieved through the relay server when a direct P2P connection cannot be established directly. This solution not only improves the success rate of communication but also reduces the dependence on the network environment.

[0066] Further, in this embodiment, before the step of requesting the relay server to obtain the relay proxy address, encapsulating the relay proxy address into the candidate address of the Session Description Protocol and sending it to the called party, the following steps are further included:

[0067] Send a port allocation request to the relay server so that the relay server allocates corresponding port information according to the port request; receive the allocated mapped port returned by the relay server; establish a connection channel with the relay server based on the mapped port to request the relay proxy address from the relay server based on the connection channel.

[0068] Specifically, the port allocation request is used to apply to the relay server for allocating a specific port. The request contains a device identifier and a proxy protocol type. The device identifier is the identifier of the calling end, such as IMEI or a custom device ID. The proxy protocol type specifies the required proxy protocol type, such as UDP, TCP, etc. The mapped port is the port allocated by the relay server to the calling end and is used to establish a connection channel.

[0069] First, the calling end obtains the device identifier and determines the required proxy protocol type, then constructs a port allocation request according to the device identifier and the proxy protocol type. Send the port allocation request to the relay server through the network. The calling end receives the response returned by the relay server, and the response contains the allocated mapped port. Then parse the response to extract the mapped port information. Use the mapped port to establish a connection channel with the relay server, so that through the established connection channel, the calling end requests the relay proxy address from the relay server. By sending a port allocation request to the relay server and receiving the mapped port, it is ensured that the calling end can establish a connection channel with the relay server through the correct port. This method not only improves the flexibility of port allocation but also ensures communication reliability in a complex network environment (such as in the presence of a firewall or port restrictions).

[0070] Step S20: Parse the private network address in the response information fed back by the called end and initiate a binding request to the private network address of the called end.

[0071] In this embodiment, the response information is the SDP containing its own network address information returned by the called end after receiving the SDP of the calling end. The private network address is the IP address of the called end in the private network. The public network address is the public network IP address of the called end after NAT conversion. The binding request is a request used to verify whether the called end can be directly connected, usually implemented through the STUN protocol. After receiving the SDP returned by the called end, the calling end parses the network address information therein and extracts the private network address and the public network address of the called end. Then the calling end initiates a binding request (such as a STUN binding request) to the private network address of the called end.

[0072] Exemplarily, assume that the private network address of the called party is 10.0.0.1:3456 and the public network address is 203.0.113.20:7890. After the calling party parses the SDP, it sends a STUN binding request to 10.0.0.1:3456 to attempt a direct connection. If the NAT type of the called party allows a direct connection (such as a full cone NAT), the connection is successful; otherwise, proceed to the next step.

[0073] Optionally, in this embodiment, the step S20 includes:

[0074] Parse the response information fed back by the called party, and extract the public network address and the private network address of the called party; according to a preset policy, preferentially send the binding request to the private network address of the called party; if no response is received within a preset timeout threshold, send the binding request to the public network address of the called party.

[0075] Specifically, the preset policy is a predefined rule for determining which address to preferentially send the binding request to. Usually, the private network address is preferentially tried because the connection latency of the private network address is lower. Specifically, it can be the Interactive Connectivity Establishment (ICE) policy of WebRTC, which is a framework for establishing a communication session between two endpoints, aiming to solve the problem of NAT (Network Address Translation) traversal, enabling devices behind different NATs to communicate directly. The ICE policy mainly involves how to discover and select the optimal path to establish this communication. The preset timeout threshold is a predefined time value for determining whether the binding request times out, and it can usually be set from a few seconds to dozens of seconds.

[0076] When the calling party receives the SDP returned by the called party, the calling party parses the candidate address list in the SDP and extracts the public network address and the private network address of the called party. Then, according to the ICE policy, it preferentially sends a binding request to the private network address of the called party. If no response from the called party is received within the preset timeout threshold, it is determined that the connection attempt fails. The calling address is switched to the public network address, and a binding request is sent to the public network address of the called party. By preferentially attempting to connect to the private network address and then switching to the public network address after a timeout, the success rate and efficiency of communication are improved. This method not only reduces unnecessary relay forwarding, reduces communication latency, but also ensures communication reliability in a complex network environment (such as a symmetric NAT). Through flexible policies and timeout mechanisms, this solution can adapt to various network environments and provide stable and efficient communication services.

[0077] Step S30: If the binding request fails to establish a connection with the called end, send a penetration request to a specified port of the relay server. The penetration request includes the public network address of the called end, so that the relay server forwards the penetration request to the called end based on the public network address.

[0078] In this embodiment, the penetration request is a request forwarded by the relay server, which is used to establish a communication channel when direct connection is not possible. The specified port is a specific port on the relay server for receiving penetration requests. The calling end detects that the binding request fails (such as timeout or rejection), and determines that NAT penetration needs to be performed through the relay server. Then the calling end sends a penetration request to the specified port of the relay server, and the request includes the public network address of the called end. After receiving the penetration request, the relay server forwards the request to the called end according to the public network address of the called end.

[0079] In addition, if the calling end establishes a communication connection with the called end through the initiated binding request, there is no need to perform subsequent steps of sending a penetration request to the relay server to establish a two-way network address channel between the calling end and the called end. The media stream and signaling between the called end and the calling end can be directly transmitted through the communication connection established by the binding request.

[0080] Further, in this embodiment, before the step of "if the binding request fails to establish a connection with the called end, send a penetration request to a specified port of the relay server", the following steps are further included:

[0081] Detect the local network firewall policy. If the firewall restricts the outbound port, initiate a port probe to a preset port range of the relay server; select an available target port according to the port probe result and send the penetration request.

[0082] Specifically, the local network firewall policy is the firewall rules configured in the local network, which are used to control the inbound and outbound network traffic. The preset port range is a group of ports predefined by the relay server for receiving and processing penetration requests. The port probe result is the result returned by the probe request, which indicates which ports are available. The target port is an available port selected from the preset port range of the relay server for sending the penetration request.

[0083] The calling end detects the local network firewall policy through the system API or network tool, and determines whether there is an outbound port restriction. If it is detected that the firewall restricts the outbound port, the calling end sends a probe request to the preset port range of the relay server to determine which ports are available. The calling end analyzes the port probe result to determine which ports are open. Select one of the open ports as the target port for sending the penetration request.

[0084] By detecting the local network firewall policy and performing port probing, it is ensured that the penetration request can be sent through the open port, improving the success rate and efficiency of communication. This method not only adapts to complex network environments but also avoids communication failures caused by port restrictions by the firewall. Through a flexible port selection mechanism, this solution can ensure stable and efficient communication under various network restrictions.

[0085] Step S40: Establish a two-way network address channel with the called end through the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay proxy address.

[0086] In this embodiment, the two-way network address channel is a network channel that allows two-way communication between the calling end and the called end. After receiving the penetration request forwarded by the relay server, the called end initiates a binding request to the relay proxy address. At this time, the relay server has both the message from the called end to the calling end's address and the message from the relay proxy address to the called end, and this NAT channel is successfully established, enabling the calling end and the called end to establish a two-way communication channel through the relay server, and the data packet is forwarded through the relay server.

[0087] Exemplarily, as Figure 2 shown, Figure 2 is a schematic diagram of the overall process involved in the solution of the embodiment of the present application. Assume that the calling end is a mobile phone, the called end is an IP private branch exchange, there is an app on the mobile phone responsible for signaling interaction and media stream transmission, there is an frps client deployed on the IP private branch exchange, the relay server includes STUN and TURN services, and there is a proxy management server deployed. As Figure 2, when the mobile phone APP initiates a call, it first queries its public network address and port from the stun server, and at the same time applies for a relay proxy address and port. After success, it is put into the SDP OFFER and sent to the IPPBX. Then when the IPPBX receives an invite call, it also queries its public network address and port from the stun server. After success, it puts its public network address and private network address into the SDP ANSWER and replies to the mobile phone APP. When the APP receives the SDP, according to the ICE policy of WebRTC, it preferentially sends a stun binding request to the private network address of the IPPBX. If no reply from the private network is received, it sends a stun binding request to the public network address of the IPPBX. At the same time, the IPPBX also sends a stun binding request to the relay address of the APP. If the APP does not receive a reply in both of the above two ways, it continues to send a request to the 3478 port of the stun server, and tells the stun server to forward this request message to the public network address of the IPPBX. Finally, after the stun server receives this message, it forwards the APP's message to the 3478 port and sends a message to the public network address of the IPPBX. At this time, there are messages from the IPPBX to the APP Relay address and messages from the Relay address to the IPPBX on the stun, and this NAT channel is successfully established. Subsequent DTLS negotiation and RTP forwarding communicate along the channel.

[0088] In addition, the IPPBX can carry its own SN to submit proxy configuration to the relay server and specify which ports need to be allocated, such as TCP, WSS, TLS. Then the relay server allocates idle ports from the port pool and returns them to the IPPBX. After the IPPBX receives the response message, it fills in the address of the FRPS and the allocated ports in the configuration file of the FRPC and starts the FRPC process. The FRPC will automatically connect to the FRPS and map the private network port of the IPPBX to the public network. Finally, the IPPBX refreshes the server regularly with the already allocated FRPS address and port. If the IPPBX is offline and times out for a long time, the port is automatically recycled and the database is updated. When the mobile phone APP successfully connects to the IPPBX, it will directly pull the proxy information. On the contrary, in case of failure, it will request proxy information from the relay server through the SN.

[0089] In the technical solution provided in this embodiment, by requesting a relay proxy address from a relay server, encapsulating the relay proxy address into the candidate address of the Session Description Protocol, and sending it to the called party through the relay server, then parsing the network address information in the response message fed back by the called party, and initiating a binding request to the private network address of the called party. If the binding request fails to establish a connection with the called party, a penetration request is sent to a specified port of the relay server, and then a two-way network address channel with the called party is established through the penetration request forwarded by the relay server and the binding request initiated by the called party to the relay proxy address. In this embodiment, a communication channel between the calling party and the called party is established through the relay proxy address and the penetration request of the relay server, thereby improving the flexibility during media stream transmission.

[0090] In addition, in this embodiment, the NAT penetration problem is solved through the relay proxy address and the penetration request of the relay server, ensuring that the calling party and the called party can successfully establish a two-way communication channel in a complex network environment. This method not only improves the success rate of communication but also reduces the dependence on the network environment of the called party, and is applicable to various NAT types and firewall configurations. Through the forwarding mechanism of the relay server, efficient and stable communication can be achieved even in a symmetric NAT environment. Through the collaborative proxy architecture, unified management of signaling (frps) and media (STUN / TURN) penetration is realized.

[0091] Embodiment Two

[0092] Based on the same inventive concept, the present application also provides a second embodiment. Refer to Figure 3 , Figure 3 which is a schematic flowchart of the second embodiment of the channel negotiation method based on relay proxy in the present application. In this embodiment, the channel negotiation method based on relay proxy includes steps S50 to S60:

[0093] Step S50: When the binding request fails to receive a feedback, switch the private network address to the public network address of the called party.

[0094] Step S60: Initiate a secondary binding request to the called party based on the public network address.

[0095] In this embodiment, that the binding request fails to receive a feedback means that no response to the binding request from the called party is received within a preset time, usually indicating that the connection attempt fails. The private network address switch means changing the communication target address from the private network address to the public network address. The secondary binding request is a binding request re-initiated based on the public network address after the first binding request fails.

[0096] When the calling party does not receive a response from the called party within the preset timeout period, it determines that the binding request has not been feedback. Then it switches the communication target address from the private network address to the public network address of the called party, and resends the binding request based on the public network address of the called party. The called party receives the request and verifies the connection. If the verification is successful, it returns a response.

[0097] Optionally, in this embodiment, before the step of switching the private network address to the public network address of the called party when the binding request has not been feedback, it further includes:

[0098] If the calling party does not receive a response from the called party within the preset timeout threshold, it determines that the binding request has not been feedback; records the number of detection failures of the current network address. If the number of failures exceeds the preset threshold, subsequent binding requests to the current network address are prohibited.

[0099] Specifically, a timeout timer can be set in the calling party. The calling party starts the timer when sending a binding request. Before the timer times out, it detects whether a response from the called party is received. If the timer times out and no response is received, it determines that the binding request has not been feedback. Each time the binding request has not been feedback, the count of the number of detection failures of the current network address is incremented. The number of detection failures is compared with the preset threshold. If the number of detection failures exceeds the preset threshold, the network address is marked as unreachable, and subsequent binding requests to this address are prohibited. By setting the timeout threshold and the failure count threshold, it effectively avoids repeated invalid attempts when the network address is unreachable, improves communication efficiency and system performance. By recording the number of failures and prohibiting subsequent requests, it reduces unnecessary consumption of network resources, and at the same time ensures the stability and reliability of communication.

[0100] In the technical solution provided in this embodiment, this embodiment improves the success rate and reliability of communication by switching to the public network address and initiating a secondary binding request when the first binding request has not been feedback. This method effectively solves the problem of communication failure caused by the unreachability of the private network address, adapts to complex network environments, and ensures communication stability under various NAT types and firewall configurations.

[0101] Embodiment Three

[0102] Based on the same inventive concept, the present application also provides a third embodiment. Refer to Figure 4 , Figure 4 which is a schematic flowchart of the third embodiment of the channel negotiation method based on a relay proxy in the present application. In this embodiment, the channel negotiation method based on a relay proxy includes steps S70 to S90:

[0103] Step S70: After the two-way network address channel is established, exchange digital certificates with the called party based on a preset protocol and negotiate encryption keys.

[0104] Step S80: End - to - end encrypt the media stream with the encryption key, and transmit the encrypted media stream to the called end based on the two - way network address channel.

[0105] Step S90: If it is detected that the NAT type of the called end is a full - cone type, skip the relay server and directly transmit the RTP packet to the called end through the public network address.

[0106] In this embodiment, the preset protocol is a protocol for exchanging digital certificates and negotiating encryption keys, such as DTLS (Datagram Transport Layer Security). A digital certificate is a digital credential for verifying the identities of both communication parties. An encryption key is a key for encrypting and decrypting communication data. End - to - end encryption can ensure that the media stream is encrypted at the sending end and decrypted at the receiving end, and intermediate nodes cannot read the content. A media stream is a data stream such as real - time transmitted audio and video. A full - cone NAT is a type of NAT that allows direct communication between internal and external addresses. An RTP packet is a Real - Time Transport Protocol (RTP) packet for transmitting real - time data such as audio and video.

[0107] Specifically, the calling end and the called end exchange their respective digital certificates through a preset protocol (such as DTLS). Then both parties verify each other's digital certificates to ensure the legitimacy of the identities of both communication parties. Based on the digital certificates, both parties negotiate a shared encryption key through a key negotiation algorithm (such as ECDH). The calling end encrypts the media stream with the negotiated encryption key. The encrypted media stream is sent to the called end through the two - way network address channel, and the called end decrypts the media stream with the same encryption key. If it is detected that the NAT type of the called end is a full - cone type, skip the relay server and directly transmit the RTP packet, that is, the calling end directly sends the RTP packet through the public network address of the called end.

[0108] In the technical solution provided in this embodiment, by performing digital certificate exchange and encryption key negotiation after the establishment of the two - way network address channel, the security and privacy of communication are ensured. Through end - to - end encryption, the confidentiality and integrity of the media stream are protected. In addition, by detecting the NAT type of the called end, the communication path is optimized. In a full - cone NAT environment, the relay server is skipped, reducing latency and improving communication efficiency.

[0109] The present application provides a channel negotiation device based on a relay agent. The channel negotiation device based on a relay agent includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the channel negotiation method based on a relay agent in the first embodiment above.

[0110] The following refers to Figure 5 , which shows a schematic structural diagram of a channel negotiation device based on a relay agent suitable for implementing the embodiments of the present application. The channel negotiation device based on a relay agent in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, personal digital assistants (PDAs, Personal Digital Assistants), tablet computers (PADs, Portable Application Descriptions), portable multimedia players (PMPs, Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The shown channel negotiation device based on a relay agent is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0111] As Figure 5As shown, the relay agent-based channel negotiation device may include a processing device 1001 (such as a central processor, a graphics processor, etc.), which may perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM) 1004. In the random access memory 1004, various programs and data required for the operation of the relay agent-based channel negotiation device are also stored. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 may allow the relay agent-based channel negotiation device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a relay agent-based channel negotiation device with various systems, it should be understood that it is not required to implement or have all the shown systems. More or fewer systems may be implemented or had alternatively.

[0112] Specifically, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the read-only memory 1002. When the computer program is executed by the processing device 1001, the above functions defined in the methods of the embodiments disclosed in the present application are executed.

[0113] The relay agent-based channel negotiation device provided by the present application adopts the relay agent-based channel negotiation method in the above embodiments, and can solve the technical problem of low flexibility in realizing media stream transmission in the traditional solution. Compared with the prior art, the beneficial effects of the relay agent-based channel negotiation device provided by the present application are the same as those of the relay agent-based channel negotiation method provided by the above embodiments, and other technical features in the relay agent-based channel negotiation device are the same as the features disclosed in the method of the previous embodiment, and will not be elaborated here.

[0114] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0115] As mentioned above, the above are only specific embodiments of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed in this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

[0116] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the channel negotiation method based on a relay agent in the above embodiments.

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

[0118] The above computer-readable storage medium can be included in the channel negotiation device based on a relay agent; it can also exist alone without being assembled into the channel negotiation device based on a relay agent.

[0119] The above computer-readable storage medium carries one or more programs, which, when executed by a relay-agent-based channel negotiation device, cause the relay-agent-based channel negotiation device to: request a relay agent address from a relay server, encapsulate the relay agent address into a candidate address of the Session Description Protocol, and send it to a called party through the relay server; parse the network address information in the response information fed back by the called party, and initiate a binding request to the private network address of the called party, where the network address information includes the private network address and the public network address of the called party; if the binding request fails to establish a connection with the called party, send a penetration request to a specified port of the relay server, where the penetration request contains the public network address of the called party, so that the relay server forwards the penetration request to the called party based on the public network address; establish a two-way network address channel with the called party through the penetration request forwarded by the relay server and the binding request initiated by the called party to the relay agent address.

[0120] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0122] The modules described in the embodiments of the present application can be implemented in software or in hardware. In some cases, the name of the module does not constitute a limitation on the unit itself.

[0123] The readable storage medium provided by the present application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned channel negotiation method based on a relay agent, and can solve the technical problem of low flexibility in implementing media stream transmission in the traditional solution. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as those of the channel negotiation method based on a relay agent provided in the above embodiments, and will not be elaborated here.

[0124] The embodiments of the present application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the channel negotiation method based on a relay agent as described above.

[0125] The computer program product provided by the present application can solve the technical problem of low flexibility in implementing media stream transmission in the traditional solution. Compared with the prior art, the beneficial effects of the computer program product provided by the embodiments of the present application are the same as those of the channel negotiation method based on a relay agent provided in the above embodiments, and will not be elaborated here.

[0126] The above are only the preferred embodiments of the present application, and do not limit the patent scope of the present application. Any equivalent structural or equivalent process transformation made using the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be similarly included in the patent scope of the present application.

Claims

1. A channel negotiation method based on a relay agent, characterized in that Applied to the calling end, the relay agent-based channel negotiation method includes the following steps: Request the relay server to obtain the relay agent address, encapsulate the relay agent address into the candidate address of the Session Description Protocol, and send it to the called end through the relay server; Parse the private network address in the response information fed back by the called end, and initiate a binding request to the private network address of the called end; If the binding request fails to establish a connection with the called end, send a penetration request to the specified port of the relay server, where the penetration request includes the public network address of the called end, so that the relay server forwards the penetration request to the called end based on the public network address; Establish a two-way network address channel with the called end through the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay agent address.

2. The method according to claim 1, characterized in that The step of requesting the relay server to obtain the relay agent address, encapsulating the relay agent address into the candidate address of the Session Description Protocol and sending it to the called end through the relay server includes: Send an address query request to the STUN server, where the relay server includes the STUN server and the TURN server; Apply to the TURN server for a relay agent port and the relay agent address; Encapsulate the relay agent port and the relay agent address into the candidate address list of the Session Description Protocol, and send the candidate address list to the called end based on the relay agent port.

3. The method according to claim 1, characterized in that, The step of parsing the private network address in the response information fed back by the called end and initiating a binding request to the private network address of the called end includes: Parse the response information fed back by the called end, and extract the public network address and the private network address of the called end; According to a preset policy, preferentially send the binding request to the private network address of the called end; If no response is received within a preset timeout threshold, send the binding request to the public network address of the called end.

4. The method according to claim 1, wherein After the step of parsing the private network address in the response information fed back by the called end and initiating a binding request to the private network address of the called end, it further includes: When the binding request fails to get a response, switch the private network address to the public network address of the called end; Initiate a secondary binding request to the called end based on the public network address.

5. The method according to claim 4, wherein Before the step of switching the private network address to the public network address of the called end when the binding request fails to get a response, it further includes: If no response from the called end is received within a preset timeout threshold, determine that the binding request fails to get a response; Record the number of detection failures of the current network address. If the failure number exceeds a preset threshold, prohibit subsequent binding requests to the current network address.

6. The method according to claim 1, wherein After the step of establishing a two-way network address channel with the called end through the penetration request forwarded by the relay server and the binding request initiated by the called end to the relay agent address, it further includes: After the two-way network address channel is established, exchange digital certificates with the called end based on a preset protocol and negotiate encryption keys; Perform end-to-end encryption on the media stream using the encryption key, and transmit the encrypted media stream to the called end based on the two-way network address channel; If it is detected that the NAT type of the called end is a full cone type, skip the relay server and directly transmit the RTP packet to the called end through the public network address.

7. The method according to claim 1, wherein Before the step of requesting the relay proxy address from the relay server and encapsulating the relay proxy address into the candidate address of the session description protocol and sending it to the called end, it further includes: Send a port allocation request to the relay server, so that the relay server allocates corresponding port information according to the port request; Receive the allocated mapped port returned by the relay server; Establish a connection channel with the relay server according to the mapped port, and request to obtain the relay proxy address from the relay server based on the connection channel.

8. The method according to claim 1, wherein Before the step of sending a penetration request to the specified port of the relay server if the binding request fails to establish a connection with the called end, it further includes: Detect the local network firewall policy. If the firewall restricts the outbound port, initiate port probing to the preset port range of the relay server; Select an available target port according to the port probing result and send the penetration request.

9. A channel negotiation device based on a relay agent, characterized in that, The channel negotiation device based on the relay proxy includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. The computer program is configured to implement the steps of the channel negotiation method based on the relay proxy according to any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it implements the steps of the channel negotiation method based on the relay proxy according to any one of claims 1 to 8.

Images