FreeSWITCH cluster load balancing methods, load balancers, and systems

Abstract

This application discloses a load balancing method, load balancer, and system for FreeSWITCH clusters, relating to the field of digital communication technology. The load balancing method for FreeSWITCH clusters includes: obtaining registration information of all FreeSWITCH nodes in the FreeSWITCH cluster from a registration center; establishing a long-lived connection with the FreeSWITCH cluster using the registration information; when an ESL client sends a signaling request, selecting the applicable application scenario based on the traffic characteristics of the signaling request; selecting a corresponding load balancing strategy from predefined load balancing strategies based on the application scenario; and forwarding the signaling request to the FreeSWITCH node selected by the load balancing strategy using the long-lived connection. This application addresses the technical problems of existing technologies using third-party SIP proxy services, which are difficult to integrate with networks and pose security risks.

Description

Technical Field

[0001] This application relates to the field of digital communication technology, and in particular to load balancing methods, load balancers and systems for FreeSWITCH clusters. Background Technology

[0002] FreeSWITCH is an open-source softswitch platform that supports real-time audio and video communication and conferencing, as well as multiple communication protocols such as SIP. FreeSWITCH-based communication systems often need to support a large number of simultaneous call requests, thus placing high demands on call concurrency.

[0003] Typically, the FreeSWITCH server in such communication systems uses the SIP protocol to forward call requests. However, the SIP (Session Initialization Protocol) protocol stack, Sofia, can only perform single-threaded processing, resulting in a single-machine performance bottleneck. This leads to an unbalanced load on the FreeSWITCH cluster of the communication system and limited concurrency capabilities.

[0004] Currently, the traditional solution for load balancing in FreeSWITCH clusters is to forward SIP requests to FreeSWITCH nodes through servers that integrate SIP proxy services such as openSIPS and Kamailio.

[0005] The above solution for load balancing uses a SIP proxy service, which has the following problems:

[0006] Because SIP proxy services are only applicable to calls initiated by SIP clients, they can only proxy and distribute uplink SIP requests, making them difficult to be compatible with networks.

[0007] Traditional load balancing solutions all require the deployment of third-party application services, which are technically uncontrollable and pose certain security risks, making them unsuitable for industries such as banking that have high data security requirements.

[0008] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0009] The main purpose of this application is to provide a load balancing method, load balancer and system for FreeSWITCH clusters, aiming to solve the technical problems of existing technical solutions where third-party SIP proxy services are only applicable to calls initiated by SIP clients, have poor compatibility and pose certain security risks.

[0010] To address the above-mentioned technical shortcomings, the main objective of this invention is to provide a load balancing method for FreeSWITCH clusters, comprising:

[0011] Retrieve registration information for all FreeSWITCH nodes in the FreeSWITCH cluster from the registration center;

[0012] Establish a long-lived connection with the FreeSWITCH cluster using the registration information;

[0013] When using an ESL client to send signaling requests, the appropriate application scenario for the signaling request is selected based on the traffic characteristics of the signaling request.

[0014] Based on the application scenario, select the corresponding load balancing strategy from the predefined load balancing strategies;

[0015] Using long-lived connections, signaling requests are forwarded to the FreeSWITCH node selected by the load balancing strategy.

[0016] Preferably, in the above load balancing method, the step of establishing a long connection with the FreeSWITCH cluster through registration information includes:

[0017] Create a list of all service instances and a list of normal service instances;

[0018] Monitor the registry center in real time and add newly registered FreeSWITCH nodes to the list of all service instances;

[0019] Establish a long-lived connection with the newly registered FreeSWITCH node using the ESL protocol;

[0020] When a long connection to a newly registered FreeSWITCH node is successfully established, the newly registered FreeSWITCH node is added to the list of normal service instances.

[0021] Preferably, in the above load balancing method, when an ESL client sends a signaling request, the step of selecting the applicable application scenario for the signaling request based on the traffic characteristics of the signaling request includes:

[0022] Use the ESL client to convert HTTP requests sent by external web clients into signaling requests;

[0023] Extract traffic features corresponding to signaling messages from signaling requests;

[0024] Select application scenarios that correspond to the traffic characteristics.

[0025] Preferably, in the above load balancing method, the step of selecting a corresponding load balancing strategy from predefined load balancing strategies according to the application scenario includes:

[0026] Determine whether the signaling request applies to a stateful or stateless scenario;

[0027] If the application is determined to be suitable for a stateless scenario, a round-robin strategy or a random forwarding strategy is selected from the predefined load balancing strategies, and a signaling request is sent to the selected FreeSWITCH node.

[0028] If the application is determined to be suitable for a stateful scenario, a consistent hashing strategy is selected from the predefined load balancing strategies, and a signaling request is sent to the selected FreeSWITCH node.

[0029] Preferably, in the above load balancing method, the step of selecting a round-robin strategy or a random forwarding strategy from a predefined load balancing strategy and sending a signaling request to the selected FreeSWITCH node includes:

[0030] The number of signaling requests is moduloed by the number of nodes in the list of all FreeSWITCH nodes in the normal service instance list, and the modulo result is used as the machine index corresponding to this signaling request.

[0031] Select the FreeSWITCH node corresponding to the machine index to forward this signaling request;

[0032] or,

[0033] Input the number of all FreeSWITCH nodes in the normal service instance list into the random number generation algorithm, and use the resulting random number as the machine index corresponding to this signaling request;

[0034] Select the FreeSWITCH node corresponding to the machine index to forward this signaling request.

[0035] Preferably, in the above load balancing method, the step of selecting a consistent hashing strategy from a predefined load balancing strategy and sending a signaling request to the selected FreeSWITCH node includes:

[0036] Set up a hash space and map the hash space to a virtual ring;

[0037] Calculate the node hash result for each FreeSWITCH node in the normal service instance list, and map the node hash result to a virtual ring respectively;

[0038] Perform a hash calculation on the signaling request and map the signaling hash result to a virtual ring;

[0039] Find the FreeSWITCH node corresponding to the nearest neighbor node's hash result from the location of the signaling hash result, and forward the signaling request.

[0040] Preferably, the above load balancing method further includes, before the step of forwarding the signaling request to the FreeSWITCH node selected by the load balancing strategy:

[0041] Listen for heartbeat events on every FreeSWITCH node in the list of all service instances;

[0042] Determine whether the FreeSWITCH node is available based on the heartbeat detection event;

[0043] If the FreeSWITCH node is determined to be unavailable, then the FreeSWITCH node will be removed from the list of normal service instances.

[0044] During the predetermined monitoring period, unavailable FreeSWITCH nodes will be reactivated.

[0045] When an unavailable FreeSWITCH node fails to be reactivated, close the long-lived connection to the FreeSWITCH node and remove the unavailable FreeSWITCH node from the list of all service instances.

[0046] Preferably, the above load balancing method further includes, after the step of establishing a long connection with the FreeSWITCH cluster through registration information:

[0047] Real-time monitoring of long-lived connections with each FreeSWITCH node in the FreeSWITCH cluster;

[0048] When a long connection is detected to be broken, a timed thread is started to re-establish the long connection with the broken FreeSWITCH node.

[0049] To achieve the above objectives, this application also provides a load balancer for a FreeSWITCH cluster, comprising:

[0050] The memory, the processor, and the computer program stored on the memory and executable on the processor, the computer program being configured to implement the load balancing method for a FreeSWITCH cluster as provided in any of the above technical solutions.

[0051] To achieve the above objectives, this application also provides a load balancing system for a FreeSWITCH cluster, comprising:

[0052] The system consists of a signaling server, a registration center, and a FreeSWITCH cluster. Each FreeSWITCH node in the signaling server and FreeSWITCH cluster is connected to the registration center.

[0053] The signaling server includes ESL clients and the aforementioned load balancer;

[0054] The ESL client communicates with external web clients and is used to convert HTTP requests sent by web clients into signaling requests in ESL format.

[0055] The load balancer is connected to the ESL client and has a built-in computer program configured to implement the load balancing method for the FreeSWITCH cluster provided by any of the above technical solutions.

[0056] One or more technical solutions proposed in this application have at least the following technical effects:

[0057] The system retrieves registration information for all FreeSWITCH nodes in the FreeSWITCH cluster from the registry center. This registration information includes the configuration of each FreeSWITCH node. A persistent connection is then established with the FreeSWITCH nodes based on the ESL protocol. The connected ESL client implements the ESL protocol, which can be implemented in Java. This Java client can be integrated into Java web applications, enabling the conversion from HTTP to ESL protocol for web applications, thus adapting to most web applications (internet applications). When the ESL client sends a signaling request, the system selects the appropriate application scenario based on the request's traffic characteristics. It then selects a suitable load balancing strategy from predefined load balancing policies and chooses a suitable FreeSWITCH node to forward the request via the persistent connection. This establishes a signaling control channel from the ESL client to the FreeSWITCH cluster. This eliminates the need for third-party SIP proxy services, making the system technically controllable, reducing security risks, and suitable for industries with high data security requirements. Attached Figure Description

[0058] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0059] 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, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0060] Figure 1 A schematic diagram of the structure of a FreeSWITCH cluster load balancing system provided in this application embodiment;

[0061] Figure 2 A flowchart illustrating a load balancing method for a FreeSWITCH cluster provided in an embodiment of this application;

[0062] Figure 3 For this application Figure 2 The illustrated embodiment provides a flowchart of a method for establishing a long connection;

[0063] Figure 4 For this application Figure 2 The illustrated embodiment provides a flowchart of an application scenario selection method;

[0064] Figure 5 For this application Figure 2 The illustrated embodiment provides a flowchart of a method for selecting a load balancing strategy;

[0065] Figure 6 This application Figure 5 A flowchart illustrating the first signaling request sending method provided in the illustrated embodiment;

[0066] Figure 7 This application Figure 5 A flowchart illustrating the second signaling request sending method provided in the illustrated embodiment;

[0067] Figure 8 This is a flowchart illustrating a method for detecting the liveness of a FreeSWITCH node provided in an embodiment of this application;

[0068] Figure 9 This is a flowchart illustrating a method for reconnecting a FreeSWITCH node from a breakpoint, as provided in an embodiment of this application.

[0069] Figure 10 This is a flowchart illustrating a registration method for a registration center provided in an embodiment of this application;

[0070] Figure 11 This is a schematic diagram of the structure of a load balancer for a FreeSWITCH cluster provided in an embodiment of this application.

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

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

[0073] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0074] The existing technology has the following technical problems:

[0075] Existing solutions for load balancing in FreeSWITCH clusters typically involve servers that integrate SIP proxy services such as openSIPS and Kamailio to forward SIP requests to FreeSWITCH nodes.

[0076] The above-mentioned solution for load balancing, which uses a SIP proxy service, has the following problems:

[0077] Because SIP proxy services are only applicable to calls initiated by SIP clients, they can only proxy and distribute uplink SIP requests, making them difficult to be compatible with networks.

[0078] Traditional load balancing solutions all require the deployment of third-party application services, which are technically uncontrollable and pose certain security risks, making them unsuitable for industries such as banking that have high data security requirements.

[0079] To address the aforementioned technical issues, this application provides a solution that integrates an ESL client into the signaling service. The signaling service receives HTTP signaling requests sent from external web clients via the HTTP protocol, transforms the signaling messages using the ESL client, selects an appropriate application scenario based on the signaling traffic characteristics, and then determines a suitable load balancing strategy. Through a persistent connection to the FreeSWITCH cluster, it connects to the selected FreeSWITCH node, thereby sending the signaling request to that FreeSWITCH node for signaling forwarding. This method, based on the ESL protocol, does not require an external SIP proxy, is compatible with the internet, is technically controllable, and offers high security, making it suitable for fields with high data security requirements.

[0080] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or computer-readable storage medium that can achieve the above functions.

[0081] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments shown herein. Rather, these embodiments are provided so that this application can be thoroughly understood and its scope can be fully conveyed to those skilled in the art.

[0082] To achieve the above technical objectives, see [link to relevant documentation]. Figure 1 , Figure 1 A schematic diagram of a FreeSWITCH cluster load balancing system provided in an embodiment of this application. The load balancing system includes:

[0083] The signaling server, the registry center Zookeeper, and the FreeSWITCH cluster, where the FreeSWITCH cluster consists of multiple FreeSWITCH nodes (i.e., Figure 1 In FreeSWITCH instances 1-3), the signaling server includes ESL clients and a load balancer; among them,

[0084] ESL clients can communicate with external web clients (mobile clients, for example) through a message gateway. The mobile client sends a greeting signaling message, which is then sent as an HTTP request to the ESL client on the signaling server via the message gateway. The ESL client converts this HTTP request into an ESL protocol signaling request. The load balancer connected to this ESL client can then pre-register with the registry center and retrieve the registration information of each FreeSWITCH node in the FreeSWITCH cluster from the registry center's ZooKeeper. This allows the load balancer to establish long-lived connections with each FreeSWITCH node based on the ESL protocol. The load balancer extracts traffic characteristics from the signaling request, selects the application scenario applicable to these characteristics, and then chooses the corresponding load balancing strategy from a predefined set of load balancing strategies. This load balancing strategy selects the FreeSWITCH node that executes the signaling request, allowing the selected FreeSWITCH node to forward the signaling request. Figure 1 As shown in the embodiment of this application, FreeSWITCH instance 3 forwards the signaling request to the Huawei platform (a third-party service) via the SIP / RTP protocol, and the Huawei platform allocates the signaling request to the corresponding agent.

[0085] The above method enables direct establishment of the ESL channel, forwarding signaling requests through the ESL client, load balancer, and FreeSWITCH node without the need for a third-party SIP proxy. This enhances the service capabilities of real-time audio and video calls and improves the signaling channel's ability to handle concurrent uplink and downlink signaling. Externally, the FreeSWITCH node's real-time audio and video signaling channel uses the SIP protocol as the carrier of signaling messages, establishing a signaling exchange channel with Huawei switches via FreeSWITCH. Therefore, it eliminates the need for traditional F5 server-side load balancing solutions to achieve balanced traffic distribution.

[0086] Specifically, the following embodiments are Figure 1The load balancing method of the load balancing system provided in the embodiment shown consists of three main steps: 1. Registration and discovery of FreeSWITCH clusters; 2. Client load balancer, using a comprehensive load balancing algorithm, distributes uplink traffic to FreeSWITCH clusters; 3. Supports online expansion of FreeSWITCH nodes and automatic removal of faulty nodes.

[0087] See details Figure 2 , Figure 2 This application provides a flowchart illustrating a load balancing method for a FreeSWITCH cluster, as illustrated in the embodiments of this application. Figure 2 As shown, the load balancing method of this FreeSWITCH cluster includes:

[0088] S110: Retrieves the registration information of all FreeSWITCH nodes in the FreeSWITCH cluster from the registration center.

[0089] First, the FreeSWITCH cluster needs to be registered with the registry center Zookeeper, and then discovered by the load balancer, thereby realizing the ESL long connection between the load balancer and the FreeSWITCH node.

[0090] Specifically, the service registration section includes:

[0091] When FreeSWITCH starts, it registers the configuration information of the FreeSWITCH instance with the registry center Zookeeper, which is the registration information mentioned above. This registration information includes the instance name, IP address, and status. After a node in the FreeSWITCH cluster is updated, the node configuration information will be synchronized to the Zookeeper registry center.

[0092] S120: Establishes a long-lived connection with the FreeSWITCH cluster using registration information;

[0093] Combination Figure 10 As shown in the example, the load balancer also needs to register with the Zookeeper registry in advance and monitor changes to FreeSWITCH nodes in Zookeeper (such as creation, updates, and deletions) in real time. When the load balancer detects a change, it maintains the load list in real time, thus enabling hot updates of FreeSWITCH nodes. There are three ways to maintain the load list in real time after detecting changes, as follows:

[0094] a) When a new load balancer node (i.e., a FreeSWITCH node) is detected as being created, i.e., when the FreeSWITCH node is registered with the Zookeeper registry, the new node's configuration information is added to the load balancer list, and the FreeSWITCH ESL client is notified to connect to the newly added FreeSWITCH node; b) When a load balancer node is detected as being updated, the original load balancer node is removed from the load balancer list, the FreeSWITCH ESL client is notified to close the connection with the original FreeSWITCH node, and then the updated node's configuration information (the node will restart after the update, and will register its configuration information with the Zookeeper registry upon startup) is added to the load balancer list, and the ESL client is notified to connect to the updated FreeSWITCH node; c) When a load balancer node is detected as being deleted, the load balancer node is removed from the load balancer list, and the FreeSWITCH ESL client is notified to close the connection with the corresponding FreeSWITCH node.

[0095] Specifically, as a preferred embodiment, such as Figure 3 As shown, in the above load balancing method, step S120: establishing a long connection with the FreeSWITCH cluster using registration information includes:

[0096] S121: Create a list of all service instances and a list of normal service instances. The list of all service instances, i.e., the load balancing list mentioned above, stores all FreeSWITCH instances registered with the ZooKeeper registry. The list of normal service instances stores FreeSWITCH instances capable of establishing stable ESL connections.

[0097] S122: Monitors the registry center in real time and adds newly registered FreeSWITCH nodes to the list of all service instances.

[0098] S123: Establish a long-lived connection with the newly registered FreeSWITCH node via the ESL protocol.

[0099] S124: When a long connection to a newly registered FreeSWITCH node is successfully established, add the newly registered FreeSWITCH node to the list of normal service instances.

[0100] The technical solution provided in this application integrates a client-side load balancer as a module within a signaling server. When the signaling server's application system starts, it retrieves the registration information of all FreeSWITCH nodes in the current FreeSWITCH cluster from the Zookeeper registry and simultaneously monitors the Zookeeper registry. The client-side load balancer maintains two lists: a list of all service instances and a list of normal service instances. When a new FreeSWITCH node joins the FreeSWITCH cluster, it registers the necessary configuration information of that FreeSWITCH node with the Zookeeper registry. After detecting the change in the Zookeeper registry, the load balancer adds the FreeSWITCH node to the list of all service instances and simultaneously attempts to connect to the FreeSWITCH node via the ESL protocol. When the connection status changes to CONNECTED, a long connection has been successfully established with the node, and the node is added to the list of normal service instances.

[0101] Figure 2 The load balancing method for the FreeSWITCH cluster provided in the illustrated embodiment further includes the following steps after establishing a long connection with the FreeSWITCH cluster:

[0102] S130: When an ESL client sends a signaling request, select the applicable application scenario for the signaling request based on the traffic characteristics of the signaling request.

[0103] Combination Figure 1 As shown in the structure, the mobile client sends an HTTP request containing signaling information from the upstream message gateway to a signaling server that can provide real-time audio and video. The signaling server integrates an ESL client and a load balancer. The ESL client of the signaling server transmits the HTTP message containing the extracted signaling information to the load balancer. The client-side load balancer analyzes traffic characteristics (request headers, response headers, payload format in the request body, etc.) to determine the application scenario and selects the most suitable load balancing strategy based on the application scenario.

[0104] Specifically, as a preferred embodiment, such as Figure 4 As shown, in the above load balancing method, step S130: when an ESL client sends a signaling request, the steps of selecting the applicable application scenario for the signaling request based on the traffic characteristics of the signaling request include:

[0105] S131: Use an ESL client to convert HTTP requests sent by external web clients into signaling requests.

[0106] ESL clients can connect to external web clients via the internet. This allows HTTP requests sent by external web clients to be routed to the ESL client through a gateway. The ESL client can then use the ESL protocol to convert the HTTP request into a signaling request. Because the ESL protocol is compatible with the HTTP protocol, it is compatible with most internet applications, greatly improving the product's adaptability.

[0107] S132: Extract the traffic characteristics corresponding to the signaling message from the signaling request.

[0108] S133: Select the application scenario corresponding to the traffic characteristics.

[0109] In the technical solution provided in this application, current traffic feature analysis only needs to identify audio and video uplink and downlink signaling. The message structure of audio and video signaling includes fields such as conference number, called party ID, caller ID, caller name, service number, call data, call type, and device type, which are not present in ordinary signaling messages. The signaling type is identified by analyzing the message. Audio and video signaling is a stateful scenario, while other signaling is a stateless scenario.

[0110] Figure 2 The technical solution provided in the illustrated embodiment, after the step of selecting the applicable application scenario for the signaling request based on the traffic characteristics of the signaling request, further includes:

[0111] S140: Select the corresponding load balancing strategy from the predefined load balancing strategies according to the application scenario.

[0112] As mentioned earlier, audio and video signaling are suitable for stateful scenarios, while other signaling is suitable for stateless scenarios. Different load balancing strategies are applied to stateful and stateless scenarios to achieve load balancing for different types of signaling requests.

[0113] Specifically, as a preferred embodiment, such as Figure 5 As shown, in the above load balancing method, step S140: selecting the corresponding load balancing strategy from predefined load balancing strategies according to the application scenario includes:

[0114] S141: Determine whether the signaling request applies to a stateful or stateless scenario.

[0115] Typically, audio and video signaling messages have complex structures, unlike ordinary signaling messages. Signaling types are identified by analyzing these messages. Audio and video signaling are stateful scenarios, while other signaling scenarios are stateless.

[0116] S142: If it is determined that the application is suitable for a stateless scenario, then select either a round-robin strategy or a random forwarding strategy from the predefined load balancing strategies and send a signaling request to the selected FreeSWITCH node.

[0117] S143: If it is determined that the application is suitable for a stateful scenario, select the consistent hashing strategy from the predefined load balancing strategies and send a signaling request to the selected FreeSWITCH node.

[0118] The technical solutions provided in this application are applicable to two scenarios: stateful and stateless. For stateful scenarios, a consistent load balancing strategy needs to be selected, and the consistent hashing strategy can meet the requirements. For stateless scenarios, either a round-robin strategy or a random forwarding strategy is selected based on performance requirements. Specifically, the round-robin strategy is simple to implement but inflexible and cannot adapt dynamically; random forwarding can naturally distribute traffic, reduce the pressure on individual nodes, and enhance the fault tolerance of the cluster. Therefore, when signaling requests are suitable for stateless scenarios, a round-robin strategy or a random forwarding strategy is selected; when signaling requests are suitable for stateful scenarios, a consistent hashing strategy is selected.

[0119] This application embodiment requires pre-setting the aforementioned predefined load balancing strategy in the load balancer. The load balancing strategy includes: round-robin strategy, random forwarding strategy, and consistent hashing strategy. The scheme for sending signaling requests using the round-robin strategy or the random forwarding strategy is as follows:

[0120] Specifically, as a preferred embodiment, such as Figure 6 As shown, in the above load balancing method, step S142: selecting a round-robin strategy or a random forwarding strategy from predefined load balancing strategies and sending a signaling request to the selected FreeSWITCH node includes:

[0121] S1421: Obtain the number of signaling requests, take the modulo of the number of nodes of all FreeSWITCH nodes in the normal service instance list, and use the modulo result as the machine index corresponding to this signaling request;

[0122] S1422: Select the FreeSWITCH node corresponding to the machine index to forward this signaling request;

[0123] The technical solution provided in this application involves taking the modulo of the number of requests with the total number of available FreeSWITCH nodes in the FreeSWITCH cluster, and the modulo result corresponds to a machine index. If the current number of requests is i and the cluster has n machines, then the corresponding machine index is...

[0124] For example, if there are 10 FreeSWITCH nodes and the number of signaling requests is 100, then 100 mod 10 = 0, so the machine index is 0, corresponding to the first FreeSWITCH node in the normal service instance list. For the 101st signaling request, then 101 mod 10 = 1, so the machine index is 1, corresponding to the second FreeSWITCH node in the normal service instance list.

[0125] or,

[0126] S1423: Input the number of nodes of all FreeSWITCH nodes in the normal service instance list into the random number generation algorithm, and use the resulting random number as the machine index corresponding to this signaling request;

[0127] S1424: Select the FreeSWITCH node corresponding to the machine index to forward this signaling request.

[0128] The random forwarding strategy uses the passed-in load balancer to obtain a list of available instances and a list of all instances. It then uses the `ThreadLocalRandom.current().nextInt(serverCount)` method to obtain a random number, which is used as the index to return the specific instance. If the cluster has n machines, the corresponding machine index is used. This allows the selection of the FreeSWITCH node corresponding to the given index to forward the signaling request.

[0129] The polling and random forwarding strategies described above are suitable for stateless scenarios, are simple to implement, and can dynamically adapt to the forwarding requirements of multiple signaling requests.

[0130] In addition, for stateful scenarios, a consistent hashing strategy needs to be selected, and signaling requests should be sent to the selected FreeSWITCH node.

[0131] Specifically, as a preferred embodiment, such as Figure 7 As shown, in the above load balancing method, step S143: selecting a consistent hashing strategy from predefined load balancing strategies and sending a signaling request to the selected FreeSWITCH node includes:

[0132] S1431: Set up the hash space and map the hash space to a virtual ring;

[0133] S1432: Calculate the node hash result of each FreeSWITCH node in the normal service instance list, and map the node hash result to the virtual ring respectively;

[0134] S1433: Perform a hash calculation on the signaling request and map the signaling hash result to a virtual ring;

[0135] S1434: Find the FreeSWITCH node corresponding to the nearest neighbor node's hash result from the location of the signaling hash result, and forward the signaling request.

[0136] In the technical solution provided in this application embodiment, for a distributed FreeSWITCH cluster, all requests issued throughout the entire lifecycle of a call should be sent to the same FreeSWITCH node, because FreeSWITCH maintains the connection and all state information of a call, and this information is not shared between different FreeSWITCH nodes. Traditional hash functions can establish a mapping relationship between data and servers, but when a server node is added or deleted, the data needs to be rehashed, which destroys the original mapping relationship and can lead to short-term service unavailability in real-time audio and video scenarios. Therefore, this application embodiment adopts a consistent hashing strategy to solve the above problems. The consistent hashing strategy does not require rehashing of signaling requests when a FreeSWITCH node is added or deleted.

[0137] The client-side load balancer will select the most suitable strategy for different scenarios.

[0138] Figure 2 The technical solution provided in the illustrated embodiment, after the step of selecting a corresponding load balancing strategy from predefined load balancing strategies according to the application scenario, further includes:

[0139] S150: Use a persistent connection to forward signaling requests to the FreeSWITCH node selected by the load balancing strategy.

[0140] like Figure 1 As shown, this long connection is established based on the ESL protocol. Therefore, using this long connection, a signaling channel can be established between the ESL client and the FreeSWITCH node. The FreeSWITCH node then establishes a connection with an external third-party operator through the SIP / RTP protocol, thereby realizing signaling exchange and balanced distribution of traffic from the Web client to the third-party operator.

[0141] The technical solution provided in this application obtains the registration information of all FreeSWITCH nodes in the FreeSWITCH cluster from the registration center. This registration information includes the configuration of the FreeSWITCH nodes. Then, a long connection with FreeSWITCH is established through this registration information. This long connection is based on the ESL protocol, and the connected ESL client is also based on the ESL protocol. Because the ESL protocol can support requests initiated based on the HTTP protocol, it is compatible with most Internet applications and therefore has strong adaptability. When a signaling request is detected from an ESL client, the application scenario applicable to the signaling request is selected based on the traffic characteristics of the signaling request. A corresponding load balancing strategy can be selected from predefined load balancing strategies based on the application scenario. A suitable FreeSWITCH node for forwarding the signaling request is selected according to the long connection, and the signaling request is forwarded externally. This establishes a signaling channel from the ESL client to the FreeSWITCH cluster. This eliminates the need for third-party SIP proxy services, making it technically controllable, reducing security risks, and suitable for industries with high data security requirements.

[0142] In addition, traditional FreeSWITCH clusters typically use a hot backup solution. When the primary instance fails, communication services will be interrupted, and a switch to a backup node is required, which leads to higher operation and maintenance costs.

[0143] To address the issue of communication service interruption caused by FreeSWITCH cluster failures, this application implements a FreeSWITCH cluster deployment scheme. Through a mechanism for detecting the liveness of FreeSWITCH nodes within the cluster and enabling reconnection after disconnection, high service availability is achieved.

[0144] Regarding the activation mechanism, specifically, as a preferred embodiment, such as Figure 8 As shown, the above load balancing method further includes the following steps before step S150: forwarding the signaling request to the FreeSWITCH node selected by the load balancing strategy:

[0145] S201: Listen for heartbeat events for each FreeSWITCH node in the list of all service instances.

[0146] S202: Determine whether the FreeSWITCH node is available based on the heartbeat detection event.

[0147] S203: If the FreeSWITCH node is determined to be unavailable, then remove the FreeSWITCH node from the list of normal service instances.

[0148] S204: Probe the activation of unavailable FreeSWITCH nodes within the predetermined monitoring time.

[0149] S205: When an unavailable FreeSWITCH node fails to be reactivated, close the long connection with the FreeSWITCH node and remove the unavailable FreeSWITCH node from the list of all service instances.

[0150] The technical solution provided in this application, to prevent the ESL client's load balancer from selecting a failed FreeSWITCH node, needs to check whether all FreeSWITCH nodes in the load list are available and in normal status; this is the liveness detection mechanism. Normally, a FreeSWITCH node generates a HEARTBEAT event every 20 seconds, which can be used to detect whether the FreeSWITCH is running normally. The load balancer determines the normality of a FreeSWITCH node by listening to its HEARTBEAT event. When a FreeSWITCH node does not send a HEARTBEAT event for more than 20 seconds, the client load balancer removes the node from the list of normal service instances, retains it in the list of all service instances, and starts a timer. If a HEARTBEAT event is received again from the FreeSWITCH node within the default timeout period, the node is added back to the list of normal service instances; otherwise, it is removed from the list of all service instances, and the ESL connection to it is closed. Through this liveness detection mechanism, nodes in the cluster that are temporarily unable to provide services can be intelligently filtered out, thereby avoiding impact on business operations.

[0151] In addition, FreeSWITCH nodes may experience updates or disconnections, in which case it is necessary to reconnect the FreeSWITCH node.

[0152] Specifically, as a preferred embodiment, such as Figure 9 As shown, the above load balancing method further includes, after step S120: establishing a long connection with the FreeSWITCH cluster using registration information:

[0153] S301: Real-time monitoring of long connections with each FreeSWITCH node in the FreeSWITCH cluster;

[0154] S302: When a long connection is detected to be broken, a timed thread is started to re-establish the long connection with the broken FreeSWITCH node.

[0155] The technical solution provided in this application embodiment connects the signaling server of the real-time audio and video signaling service to each FreeSWITCH node via a long-lived connection. The signaling server maintains communication with FreeSWITCH through the FreeSWITCH ESL (Event Socket Library) protocol, a custom protocol over TCP, similar to HTTP or SIP. The signaling service implements an ESL-based client based on the Netty framework. In Netty's connection handling method, an asynchronous callback event is added using the ChannelFutureListener method. When a long-lived connection is detected as broken, a timed thread is started to perform a reconnection operation until the connection is re-established. This method ensures the connection with the FreeSWITCH node and the smooth operation of the signaling service.

[0156] In summary, the technical solutions provided in the above embodiments of this application are the first to support a load balancing method for FreeSWITCH ESL, supporting clustered deployment of FreeSWITCH and greatly improving call concurrency processing capabilities. Furthermore, it supports FreeSWITCH cluster deployment by containerizing FreeSWITCH and scripting deployment, enabling FreeSWITCH node registration and discovery. Finally, through online scaling of FreeSWITCH cluster nodes and automatic removal of faulty nodes, it can automatically handle machine failures, significantly reducing the occurrence of production problems with low manpower input, greatly minimizing the impact time and scope of production failures.

[0157] To achieve the above objectives, such as Figure 11 As shown, this application also provides a load balancer for a FreeSWITCH cluster, including:

[0158] The memory, the processor, and the computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the load balancing method for a FreeSWITCH cluster as provided in any of the above embodiments.

[0159] The following is for reference. Figure 11This document illustrates a schematic diagram of a load balancer suitable for implementing the FreeSWITCH cluster embodiments of this application. The load balancer for the FreeSWITCH cluster in these embodiments can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 11 The FreeSWITCH cluster load balancer shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0160] like Figure 11 As shown, the FreeSWITCH cluster load balancer can include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the FreeSWITCH cluster load balancer. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 is capable of running a FreeSWITCH cluster load balancer to exchange data with other devices wirelessly or via wired communication. Although the figure shows a model building device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

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

[0162] The FreeSWITCH cluster load balancer provided in this application adopts the FreeSWITCH cluster load balancing method in the above embodiments. Compared with the prior art, its beneficial effects are the same as those of the FreeSWITCH cluster load balancing method provided in the above embodiments. Furthermore, the other technical features of the FreeSWITCH cluster load balancer are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0165] In addition, to achieve the above objectives, this application also provides a load balancing system for a FreeSWITCH cluster, comprising:

[0166] The system consists of a signaling server, a registration center, and a FreeSWITCH cluster. Each FreeSWITCH node in the signaling server and FreeSWITCH cluster is connected to the registration center.

[0167] The signaling server includes ESL clients, as well as the aforementioned Figure 11 The load balancer shown;

[0168] The ESL client communicates with external web clients and is used to convert HTTP requests sent by web clients into signaling requests in ESL format.

[0169] The load balancer is connected to the ESL client and has a built-in computer program configured to implement the load balancing method for the FreeSWITCH cluster provided by any of the above technical solutions.

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

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

[0172] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A load balancing method for a FreeSWITCH cluster, characterized in that, include: Retrieve registration information for all FreeSWITCH nodes in the FreeSWITCH cluster from the registration center; A long-lived connection is established with the FreeSWITCH cluster using the registration information. When the ESL client is invoked to send a signaling request, the application scenario applicable to the signaling request is selected based on the traffic characteristics of the signaling request. Based on the application scenario, select the corresponding load balancing strategy from the predefined load balancing strategies; Using the long connection, the signaling request is forwarded to the FreeSWITCH node selected by the load balancing strategy; The step of establishing a long connection with the FreeSWITCH cluster using the registration information includes: Create a list of all service instances and a list of normal service instances; Monitor the registry center in real time and add any newly registered FreeSWITCH nodes detected to the list of all service instances; A long-lived connection is established with the newly registered FreeSWITCH node via the ESL protocol; When a long connection is successfully established with the newly registered FreeSWITCH node, the newly registered FreeSWITCH node is added to the list of normal service instances. The step of selecting a corresponding load balancing strategy from predefined load balancing strategies based on the application scenario includes: Determine whether the signaling request applies to a stateful or stateless scenario; If it is determined that the application is suitable for a stateless scenario, then a round-robin strategy or a random forwarding strategy is selected from the predefined load balancing strategy, and the signaling request is sent to the selected FreeSWITCH node. If the application is determined to be suitable for a stateful scenario, a consistent hashing strategy is selected from the predefined load balancing strategies, and the signaling request is sent to the selected FreeSWITCH node.

2. The load balancing method as described in claim 1, characterized in that, The step of selecting the applicable application scenario for the signaling request based on the traffic characteristics of the signaling request when the ESL client is invoked to send a signaling request includes: The ESL client is used to convert HTTP requests sent by external web clients into signaling requests; Extract the traffic features corresponding to the signaling message from the signaling request; Select an application scenario that corresponds to the traffic characteristics.

3. The load balancing method as described in claim 1, characterized in that, The step of selecting either a round-robin strategy or a random forwarding strategy from the predefined load balancing strategy and sending the signaling request to the selected FreeSWITCH node includes: The number of requests for the signaling request is obtained, and modulo is taken with the number of nodes of all FreeSWITCH nodes in the normal service instance list. The modulo result is used as the machine index corresponding to this signaling request. Select the FreeSWITCH node corresponding to the machine index to forward this signaling request; or, The number of nodes of all FreeSWITCH nodes in the normal service instance list is input into the random number generation algorithm, and the resulting random number is used as the machine index corresponding to this signaling request. Select the FreeSWITCH node corresponding to the machine index to forward this signaling request.

4. The load balancing method as described in claim 1, characterized in that, The step of selecting a consistent hashing strategy from the predefined load balancing strategy and sending the signaling request to the selected FreeSWITCH node includes: Set up a hash space and map the hash space to a virtual ring; Calculate the node hash result for each FreeSWITCH node in the normal service instance list, and map the node hash result to the virtual ring respectively; The signaling request is hashed, and the hash result is mapped to the virtual ring. Find the FreeSWITCH node corresponding to the nearest neighbor node hash result from the location of the signaling hash result, and forward the signaling request.

5. The load balancing method as described in claim 1, characterized in that, Before the step of forwarding the signaling request to the FreeSWITCH node selected by the load balancing strategy, the method further includes: Listen for the heartbeat detection event of each FreeSWITCH node in the list of all service instances; Based on the heartbeat detection event, determine whether the FreeSWITCH node is available; If the FreeSWITCH node is determined to be unavailable, then the FreeSWITCH node will be removed from the list of normal service instances. During the predetermined monitoring period, the unavailable FreeSWITCH nodes will be reactivated. When the unavailable FreeSWITCH node fails to be reactivated, close the long connection with the FreeSWITCH node and remove the unavailable FreeSWITCH node from the list of all service instances.

6. The load balancing method as described in claim 1, characterized in that, After the step of establishing a long connection with the FreeSWITCH cluster using the registration information, the method further includes: Real-time monitoring of long-lived connections with each FreeSWITCH node in the FreeSWITCH cluster; When the long connection is detected to be broken, a timed thread is started to re-establish the long connection with the broken FreeSWITCH node within the timed thread.

7. A load balancer for a FreeSWITCH cluster, characterized in that, include: A memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the load balancing method for a FreeSWITCH cluster as described in any one of claims 1 to 6.

8. A load balancing system for a FreeSWITCH cluster, characterized in that, include: The system comprises a signaling server, a registration center, and a FreeSWITCH cluster, wherein the signaling server and each FreeSWITCH node in the FreeSWITCH cluster are connected to the registration center; wherein... The signaling server includes an ESL client and the load balancer as described in claim 7; The ESL client communicates with an external web client and is used to convert HTTP requests sent by the web client into signaling requests in ESL protocol form; The load balancer is connected to the ESL client, and the load balancer has a built-in computer program configured to implement the steps of the load balancing method for the FreeSWITCH cluster as described in any one of claims 1 to 6.

Images