CN117201677A - Incoming and outgoing call system and scheduling method for incoming and outgoing call system - Google Patents
Incoming and outgoing call system and scheduling method for incoming and outgoing call system Download PDFInfo
- Publication number
- CN117201677A CN117201677A CN202311474415.8A CN202311474415A CN117201677A CN 117201677 A CN117201677 A CN 117201677A CN 202311474415 A CN202311474415 A CN 202311474415A CN 117201677 A CN117201677 A CN 117201677A
- Authority
- CN
- China
- Prior art keywords
- service
- node
- service node
- cluster
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 230000007246 mechanism Effects 0.000 claims abstract description 20
- 238000010586 diagram Methods 0.000 description 5
- 238000012217 deletion Methods 0.000 description 4
- 230000037430 deletion Effects 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000003339 best practice Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000008602 contraction Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000006378 damage Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Landscapes
- Telephonic Communication Services (AREA)
Abstract
The application relates to an incoming and outgoing call system and a scheduling method for the incoming and outgoing call system, the incoming and outgoing call system comprising: service clusters, client clusters, configuration clusters, and management clusters. The service cluster includes service nodes, each service node configured to: executing corresponding incoming or outgoing session tasks under the condition that the incoming or outgoing session tasks are received; and the service information is reported through a heartbeat mechanism. The client cluster includes client nodes, each configured to: in case an outgoing request is received, the service node is allocated for the outgoing request based on the service information received from the service node via the heartbeat mechanism. The configuration cluster is configured to: in the case of receiving an incoming request, a service node is assigned to the incoming request based on the weights. The management cluster is configured to: the weights of the service nodes are configured for the configuration cluster based on the service information received from the client cluster. The incoming and outgoing call system can realize the balance of the resource utilization rate.
Description
Technical Field
The present application relates to the field of call center systems, and in particular, to an incoming and outgoing call system and a dispatch method for the incoming and outgoing call system.
Background
Call centers are often referred to as service work platforms for telephone calls. Through the call center, a group of agents can intensively process incoming calls of users and make telephone calls to the users. The call center may contain an incoming session service and an outgoing session service. The call completing rate and duration of a session, whether for an incoming or outgoing session, will typically vary with the list of session users and the model. The number of simultaneous calls made by a call center may be referred to as the call concurrency, which is one of the important indicators measuring the performance of the call center.
In some cases, the concurrency of outgoing and incoming calls fluctuates greatly. In order to increase the service capacity of the incoming and outgoing call system, to ensure a stable operation of the call center, it is often desirable to increase the call concurrency of the call center as much as possible.
Disclosure of Invention
The embodiment of the application provides an incoming and outgoing call system and a scheduling method for the incoming and outgoing call system, which are used for realizing the balance of the resource utilization rate of the incoming and outgoing call system so as to improve the call concurrency of the incoming and outgoing call system.
According to an aspect of the present application, there is provided an incoming and outgoing call system including: service clusters, client clusters, configuration clusters, and management clusters. The service cluster comprises a plurality of service nodes, each service node of the plurality of service nodes configured to: executing corresponding incoming call session task or outgoing call session task under the condition that the allocated incoming call session task or outgoing call session task is received; and reporting service information of the service node itself through a heartbeat mechanism, wherein the service information comprises state information indicating an operation state of the service node. The client cluster includes one or more client nodes, each of the one or more client nodes configured to: receiving service information from associated service nodes in the service cluster through a heartbeat mechanism; reporting the current service information of the associated service node; and in case an outgoing request is received, assigning a service node performing a corresponding outgoing session task to the outgoing request based on current service information of the associated service node. The configuration cluster is configured to: and under the condition that the incoming call request is received, distributing service nodes for executing corresponding incoming call tasks to the incoming call request based on the weights of the plurality of service nodes for executing the incoming call tasks. The management cluster is configured to: receiving service information of the service cluster from the client cluster; and configuring weights of the plurality of service nodes to perform incoming session tasks for the configuration cluster based on the received service information.
In some embodiments of the application, optionally, the client node is further configured to: judging whether the service node triggers the offline operation or not in the associated service nodes; and under the condition that the existence of the service node triggers the offline operation, modifying the state information of the service node triggering the offline operation into the offline state.
In some embodiments of the present application, optionally, determining whether a service node trigger drop-in operation exists in an associated service node is performed by any one or more of: judging whether each service node in the associated service nodes is effectively connected, and determining that the service node which is not effectively connected triggers the offline operation under the condition that the service node which is not effectively connected; judging whether the heartbeat of the service node is continuously lost for a threshold number of times or not in the associated service nodes, and determining that the service node with the heartbeat continuously lost for the threshold number of times triggers the offline operation under the condition that the heartbeat of the service node is continuously lost for the threshold number of times; and judging whether a service node is ready for offline based on the received service information of the associated service node, judging whether the service node is ready for offline satisfies the offline condition if the service node is ready for offline, and determining that the service node is ready for offline triggers offline operation if the service node is ready for offline satisfies the offline condition.
In some embodiments of the application, optionally, the service cluster is further configured to: under the condition of adding service nodes, the added service nodes send node information to the management cluster; the management cluster is further configured to: assigning an associated client node to the newly added service node upon receiving node information from the newly added service node, and issuing configuration information associated with the newly added service node to the associated client node; the client node is further configured to: upon receiving the configuration information from the management cluster, creating a link with the newly added service node based on the configuration information.
In some embodiments of the application, optionally, the service node is a FreeSWITCH node, the client node is an ESL node, and the configuration cluster is an OpenSIPS cluster.
According to another aspect of the present application, there is provided a scheduling method for an incoming and outgoing call system, the incoming and outgoing call system including a service cluster, a client cluster, a configuration cluster, and a management cluster, wherein the service cluster includes a plurality of service nodes, the client cluster includes one or more client nodes, the scheduling method comprising: reporting, by the plurality of service nodes, respective service information to an associated client node via a heartbeat mechanism, the service information including status information indicative of an operational status of the service node; reporting current service information of the associated service node to the management cluster by the client node; configuring, by the management cluster, weights of the plurality of service nodes to perform incoming session tasks for the configuration cluster based on the received service information; under the condition that the client node receives the calling request, distributing service nodes for executing corresponding calling session tasks for the calling request based on the current service information of the associated service nodes; under the condition that the configuration cluster receives the incoming call request, distributing service nodes for executing corresponding incoming call session tasks to the incoming call request based on the weight; and executing the corresponding incoming session task or outgoing session task by the service node under the condition of receiving the allocated incoming session task or outgoing session task.
In some embodiments of the application, optionally, the scheduling method further comprises the step of, by the client node: judging whether the service node triggers the offline operation or not in the associated service nodes; and under the condition that the existence of the service node triggers the offline operation, modifying the state information of the service node triggering the offline operation into the offline state.
In some embodiments of the present application, optionally, determining whether a service node trigger drop-in operation exists in an associated service node is performed by any one or more of: judging whether each service node in the associated service nodes is effectively connected, and determining that the service node which is not effectively connected triggers the offline operation under the condition that the service node which is not effectively connected; judging whether the heartbeat of the service node is continuously lost for a threshold number of times or not in the associated service nodes, and determining that the service node with the heartbeat continuously lost for the threshold number of times triggers the offline operation under the condition that the heartbeat of the service node is continuously lost for the threshold number of times; and judging whether a service node is ready for offline based on the received service information of the associated service node, judging whether the service node is ready for offline satisfies the offline condition if the service node is ready for offline, and determining that the service node is ready for offline triggers offline operation if the service node is ready for offline satisfies the offline condition.
In some embodiments of the present application, optionally, the scheduling method further includes: under the condition of adding service nodes, the added service nodes send node information to the management cluster; assigning, by the management cluster, an associated client node to the newly added service node upon receiving node information from the newly added service node, and issuing configuration information associated with the newly added service node to the associated client node; and creating, by the client node, a link with the newly added service node based on the configuration information upon receiving the configuration information from the management cluster.
In some embodiments of the application, optionally, the service node is a FreeSWITCH node, the client node is an ESL node, and the configuration cluster is an OpenSIPS cluster.
The embodiment of the application can dynamically adjust the distribution strategy according to the load condition of the service node, thereby effectively avoiding the problem of local hot spots and improving the overall resource utilization efficiency of the incoming and outgoing system. In some embodiments, the incoming and outgoing call system of the present application can implement dynamic capacity expansion of the service cluster by managing the scheduling of the cluster, and complete service expansion or reduction without shutdown.
Drawings
The above and other objects and advantages of the present application will become more fully apparent from the following detailed description taken in conjunction with the accompanying drawings, in which identical or similar elements are designated by the same reference numerals.
Fig. 1 shows a schematic diagram of an incoming and outgoing call system 100 in accordance with one or more embodiments of the present application;
fig. 2-4 illustrate a flow diagram of a scheduling method for an incoming and outgoing call system 100 in accordance with one or more embodiments of the present application.
Detailed Description
For the purposes of brevity and explanation, the principles of the present application are described herein primarily with reference to exemplary embodiments thereof. However, those skilled in the art will readily recognize that the same principles are equally applicable to all types of incoming and outgoing call systems 100 and scheduling methods for incoming and outgoing call systems 100, and that these same or similar principles may be implemented therein, any such variations without departing from the true spirit and scope of the application.
An incoming and outgoing call system 100 in accordance with one or more embodiments of the present application will be described below in conjunction with fig. 1.
Fig. 1 illustrates an incoming and outgoing call system 100 in accordance with one or more embodiments of the present application. In some embodiments, the incoming and outgoing call system 100 may be applied in an intelligent outbound cloud platform for performing incoming and outgoing call session traffic. The incoming and outgoing call system 100 of embodiments of the present application may increase call concurrency by dynamically balancing resource usage. As shown in fig. 1, the incoming and outgoing system 100 may include a client cluster 120, a traffic cluster 130, a configuration cluster 140, a gateway cluster 150, and a management cluster 160.
The service cluster 130 may comprise a plurality of service nodes 131. By way of example, service node 131 may be a FreeSWITCH node. Each service node 131 of the plurality of service nodes 131 may be configured to: and executing corresponding session tasks based on the allocated incoming session tasks or outgoing session tasks. For example, in case of being assigned to an incoming call request to be performed, the service node 131 may perform a corresponding incoming call session task; where assigned to perform outgoing session tasks, the service node 131 may perform corresponding outgoing session tasks.
Client cluster 120 may include one or more client nodes 121. As an example, client node 121 may be a Event Socket Library (ESL) node. Each client node 121 in client cluster 120 may be configured to: in case an outgoing request is received, the outgoing request is assigned a service node 131 for performing the corresponding outgoing session task. In the embodiment shown in fig. 1, the outgoing requests may be issued from the traffic layer 110, and accordingly, the client node 121 may receive the outgoing requests from the traffic layer 110.
Each client node 121 in the client cluster 120 may be associated with one or more service nodes 131 in the service cluster 130, and each properly functioning service node 131 in the service cluster 130 has an associated client node 121. A link is established between each pair of associated client nodes 121 and service node 131. In an embodiment of the present application, a many-to-many association between the client nodes 121 and the service nodes 131 may be implemented, i.e., one client node 121 may be associated with at least one service node 131 and one service node 131 may be associated with at least one client node 121. That is, there may be no quantitative association of the association configuration between the client node 121 and the traffic node 131.
Based on the link established between the associated client node 121 and the service node 131, the client node 121 may manage the associated service node 131. In some embodiments, the number of service nodes 131 managed by client node 121 may be adjusted in real-time. Dynamic provisioning of the manageable service nodes 131 of the client node 121 can improve the overall efficiency of the incoming and outgoing system 100, taking best practices in terms of cluster number and performance. The one-to-one static association configuration mode (i.e., one client node 121 is associated with one service node 131) is adopted between the service node 131 and the client node 121, and the dependence relationship of the specific service node 131 on the specific client node 121 can be relieved by adopting the many-to-many dynamic association configuration mode, so that the load balancing of the service cluster 130 is realized.
In an embodiment of the present application, each service node 131 of the plurality of service nodes 131 may be further configured to: the service information of the client node 121 associated with the client cluster 120 is reported to the client node based on the heartbeat mechanism. The traffic information may be used to characterize node resource usage of the corresponding traffic node 131. Wherein the service information may include operation information indicating the service node 131. For example, the operation information may include: status information indicating the current operational status of the relevant service node 131 (such as initialization status, waiting for connection status, down status, normal status), information indicating the current number of sessions of the service node 131, information indicating the number of initiated sessions per second of the service node 131, and information about the call completing rate of the service node 131. In some embodiments, the traffic information may also include other information about the traffic node 131, such as Central Processing Unit (CPU) usage, memory usage, free memory and hard disk usage, etc. associated with the traffic node 131. By adding heartbeat events, the client node 121 can monitor and count node resource usage of the associated service node 131 in real time.
The client nodes 121 may be used to maintain a connection state with an associated service node 131, and accordingly, each client node 121 may be configured to: traffic information from associated traffic nodes 131 in the traffic cluster 130 is received based on a heartbeat mechanism. After receiving the corresponding service information from one or more associated service nodes 131, the client node 121 may aggregate the service information of the connected service nodes 131 so that the received outgoing requests may be tasked according to the aggregated service information.
In an embodiment of the present application, each client node 121 may report the summarized service information of all the associated service nodes 131 to the management cluster 160, so that the management cluster 160 may obtain the operation condition of all the service nodes 131 in the service cluster 130 in a near real-time manner.
The management cluster 160 may be responsible for managing all client nodes 121 in the client cluster 120 and all service nodes 131 in the service cluster 130. In an embodiment of the present application, the management cluster 160 may be configured to: traffic information about the traffic cluster 130 is received from the client cluster 120. All traffic information corresponding to the traffic cluster 130 is transmitted to the client cluster 120 and the management cluster 160 may receive and aggregate the traffic information to all the traffic nodes 131 in the traffic cluster 130.
In some embodiments, the management cluster 160 may be further configured to: and calculating according to the received service information. For example, the management cluster 160 may calculate configuration information for the configuration cluster 141 according to parameters such as node resource usage of each service node 131, current session number, initiated session number per second, and the like. In some embodiments, the management cluster 160 may dynamically adjust configuration information for the configuration cluster 140 in the event that configuration information for the configuration cluster 140 needs to be modified.
As an example, the configuration information of the configuration cluster 140 may include routing information required to perform the session tasks and node weights of all traffic nodes 131. The term "node weight" as used herein includes: the service node 131 performs the weight of the incoming session task. For example, the management cluster 160 may configure the configuration cluster 140 with weights for the plurality of service nodes 131 to perform incoming session tasks based on the received service information. The greater the weight of a service node 131 for executing an incoming call session task, the higher the priority of the service node 131 for executing the corresponding incoming call session task. In some embodiments, the management cluster 160 may dynamically modify configuration information of the configuration cluster 140 through an HTTP protocol interface.
In some embodiments, the management cluster 160 may operate in a hot standby manner. As an example, management cluster 160 may include two management nodes. Of the two management nodes, one management node may operate as a master management node 161, and the other management node may operate as a standby management node 162, where the master management node 161 and the standby management node 162 may keep data consistent in a shared storage and cache manner. Two management nodes may guarantee service stateless and may acquire primary management node 161 eligibility through a distributed lock.
Configuration cluster 140 may include a plurality of configuration nodes 141, wherein each configuration node 141 is associated with one or more service nodes 131. In some embodiments, configuration cluster 140 may be an OpenSIPS cluster and, correspondingly, configuration node 141 may be an OpenSIPS node. Each configuration node 141 in the configuration cluster 140 may be configured to: in case of receiving an incoming call request, a service node 131 performing a corresponding incoming call session task is allocated to the incoming call request based on the weight information. The weight information may include, among other things, the weight of one or more service nodes 131 to perform the incoming session task.
Gateway cluster 150 may include a plurality of gateway nodes 151. Each gateway node 151 communicates with the operator 170 on the one hand and is associated with one or more configuration nodes 141 in the configuration cluster 140 on the other hand. As an example, gateway node 151 may be an ESL gateway server. In the embodiment shown in fig. 1, incoming requests may be issued from the operator 170 and communicated from the operator 170 to the respective gateway nodes 151 in the gateway cluster 150. Accordingly, the respective configuration node 141 in the configuration cluster 140 may receive the incoming request from the gateway node 151.
In the incoming and outgoing call system 100 according to the embodiment of the present application, the service node 131 may report service information including its own resource information and operation information to the client node 121 through a heartbeat event, so that the client node 121 may report the resource information and operation information of the service node 131 managed by itself to the management cluster 160 periodically. Accordingly, the management cluster 160 may perform calculations based on the received resource information and the running information to dynamically modify the routing information of the configuration cluster 140 through the HTTP protocol interface when the routing weights of the configuration cluster 140 need to be modified.
In case the incoming and outgoing system 100 receives an outgoing request from the service layer 110, the outgoing request may arrive at the client node 121, so that the client node 121 may select an appropriate service node 131 for the outgoing request according to the circumstances of the service node 131 managed by itself to perform a corresponding outgoing session task. In case the incoming and outgoing system 100 receives an outgoing request from the operator 170, the incoming request may arrive at the configuration node 141, so that the configuration node 141 may select an appropriate service node 131 for the incoming request according to the routing weight in the configuration information to perform the corresponding incoming session task. In the incoming and outgoing call system 100 of the present application, the incoming and outgoing call requests, after being routed appropriately, may reach the designated service node 131 to perform corresponding session operations (i.e., incoming and outgoing session tasks) through the designated service node 131.
The incoming and outgoing system 100 of the embodiment of the application realizes the monitoring and dynamic management of the resource usage condition of the service cluster 130 by adding the management cluster 160 and increasing the heartbeat event, can ensure the balance of the resource usage rate of the service cluster 130, and improves the call concurrency and the overall processing capacity of the incoming and outgoing system 100.
In some embodiments, the incoming and outgoing call system 100 may increase the resource usage limit so that when the resource usage status of the service node 131 reaches a bottleneck, the scheduling of the service node 131 may be stopped so as to avoid a crash of the service node 131.
In some embodiments, for the service node 131 with significantly lower call completing rate or service success rate, after the call completing rate or service success rate reaches the alert value, the incoming and outgoing system 100 may use an isolation means to reduce abnormal call caused by abnormal service node 131, so as to avoid call loss caused by normal heartbeat but abnormal system operation.
In some embodiments, the incoming and outgoing system 100 may intelligently calculate the real-time load capacity of each service node 131 in the service cluster 130 according to parameters such as the node resource usage condition of each service node 131, the current session number, the initiation session number per second, etc. under the condition that the heterogeneous problem of the service node 131 is fully considered, so as to dynamically adjust the session distribution policy, so as to implement balance of node resource usage for the service cluster 130.
In some embodiments of the present application, the incoming and outgoing call system 100 may be dynamically expanded without suspending traffic. To achieve dynamic capacity expansion without suspending traffic, in an embodiment of the present application, the traffic cluster 130 may be configured to: in the case of the newly added service node 131, the newly added service node 131 reports its own node information to the management cluster 160. The node information may include current state information of the newly added service node 131, information of an associated CPU, associated memory information, and the like. As an example, the running state of the newly added service node 131 after the start-up is an initialized state.
To enable dynamic capacity expansion without suspending traffic, in an embodiment of the present application, the management cluster 160 may be configured to: in the case of receiving node information from the newly added service node 131, relevant node information is added, and the operation state of the newly added service node 131 is modified to a waiting connection state. In some embodiments, the management cluster 160 may be further configured to: an appropriate client node 121 is selected for the newly added service node 131 in order to establish a link between the newly added service node 131 and the appropriate client node 121. To enable an associated configuration between the newly added service node 131 and the appropriate client node 121, the management cluster 160 may issue relevant configuration information to the appropriate client node 121 (hereinafter "associated client node 121").
To enable dynamic capacity expansion without suspending traffic, in an embodiment of the present application, the client node 121 may be configured to: upon receiving the configuration information from the management cluster 160, a link is created with the newly added service node 131 based on the configuration information. That is, by managing cluster 160, a link may be successfully established between newly added service node 131 and associated client node 121. After the associated client node 121 completes the link creation, the newly added service node 131 starts to enter an operating state, so that the newly added service node 131 can report its own service information to the associated client node 121 based on a heartbeat mechanism. After obtaining the service information from the newly added service node 131 based on the heartbeat mechanism, the associated client node 121 may modify the state information indicating the running state of the newly added service node 131 in the service information to be normal, and report the modified service information to the management cluster 160, so that the management cluster 160 may learn that the current running state of the newly added service node 131 is normal.
For a new service node 131 in the incoming and outgoing system 100, where the new service node 131 is in a normal running state, in some embodiments, the management cluster 160 may dynamically modify the configuration information of the configuration cluster 140 according to all the received service information through the HTTP protocol interface request when the new service node 131 may be used as an incoming node to perform an incoming session task. Thus, the configuration cluster 140 may route the subsequently received incoming call request to the newly added service node 131 according to the routing information in the configuration information, so as to allocate the newly added service node 131 to perform the related incoming call session task.
The incoming and outgoing call system 100 of the application realizes the informationized management of the whole incoming and outgoing call system 100 by adding the management cluster 160 and adding the heartbeat mechanism, thereby realizing the elastic capacity expansion of the node cluster 130 without affecting the service. In the embodiment of the present application, the newly added service node 131 may automatically report node information to the management cluster 160 after being started, so as to implement automatic management of the whole life cycle of the newly added service node 131 through the management cluster 160.
In some embodiments, the incoming and outgoing call system 100 may increase the unit time originating call limit for a single service node 131 to solve the problem of traffic congestion when a newly added service node 131 joins. For example, the incoming and outgoing system 100 may perform call fusing processing per unit time for a single service node 131 by counting the number of sessions initiated per second for the single service node 131 in real time. Thus, each service node 131 in the service cluster 130 may have call quantity per unit time protection, thereby avoiding call peaks when new service nodes 131 join, which may cause node failure.
In some embodiments, client node 121 and service node 131 may employ a many-to-many connection mode. In one aspect, the many-to-many connection mode may decouple the number of client nodes 121 and service nodes 131 such that the capacity expansion of the service cluster 130 is no longer dependent on the capacity expansion of the client cluster 120. On the other hand, the many-to-many connection mode enables the number of nodes managed by the client node 121 to be dynamically configurable, so that the client node 121 can adapt to different service cluster sizes, thereby realizing best practices for resource utilization efficiency of the service node 131.
In some embodiments of the present application, the incoming and outgoing call system 100 may dynamically delete the offline service node 131 without suspending the service. To dynamically expand capacity without suspending traffic, in an embodiment of the present application, each client node 121 in the client cluster 120 may be configured to: determining whether a service node 131 triggers a offline operation in the associated service nodes 131; and in the case that it is determined that there is a service node 131 that triggers the offline operation, modifying the state information of the service node 131 that triggers the offline operation to the offline state.
In some embodiments, the service node 131 may trigger the offline operation both actively and passively. In case the service node 131 actively triggers the offline operation, the service node 131 ready for offline may actively send service information indicating that itself is ready for offline, and report the service information to the associated client node 121 based on the heartbeat mechanism. In some embodiments, the client node 121 may determine whether there is a traffic node 131 in the associated traffic nodes to actively trigger an offline operation by: based on the received service information of the associated service node 131, it is determined whether there is a service node 131 ready for offline, further determining whether the service node 131 ready for offline satisfies the offline condition in the case that there is a service node 131 ready for offline, and determining that the service node ready for offline triggers the offline operation in the case that the service node 131 ready for offline satisfies the offline condition.
In some embodiments, the client node 121 may determine whether the service node 131 ready for the offline satisfies the offline condition by: judging whether the current session task number of the service node 131 ready for offline is zero; disconnecting the link with the service node 131 ready to be disconnected in case the current session task number is zero; and determines that the service node 131 ready for a drop satisfies a drop condition in the case that the link with the service node 131 ready for a drop is confirmed to be broken. The "session task number" referred to herein may include the sum of the number of incoming session tasks and outgoing session tasks. That is, as long as the service node 131 ready for offline has a session task at present, the offline condition is not satisfied, and the associated client node 121 will disconnect from the service node 131 ready for offline only after all tasks are completed.
For the case where the service node 131 actively triggers the offline operation, when the client node 121 finds that the received service information indicates that a certain service node 131 is ready for offline, the client node 121 may modify the operation state of the service node 131 ready for offline to the ready for offline state, and stop distributing tasks (e.g., an outgoing session task) to the service node 131 ready for offline. When the client node 121 confirms that the service node 131 ready for the offline satisfies the offline condition, the client node 121 may modify the running state of the service node 131 that satisfies the offline condition to be offline, and report the service information indicating that the service node 131 is offline to the management cluster 160.
In some embodiments, the client node 121 may continuously determine whether to make a valid connection with each of the associated service nodes 131, and in the event that it is determined that no valid connection is made with each service node 131, determine that the service node 131 that did not make a valid connection passively triggers an offline operation.
As an example, the client node 121 may determine whether there is a traffic node 131 in the associated traffic nodes 131 by performing the following steps: monitoring whether a link between each service node 131 associated therewith is broken; in case it is monitored that a disconnected service node 131 exists, reconnecting a link with the disconnected service node 131; judging whether the link between the service node 131 disconnected with the service node is successful; and in case of the link reconnection failure, confirming that there is a service node 131 passively triggering the offline operation, and the service node 131 failed to reconnect with it is the service node 131 triggering the offline operation.
In some embodiments, the client node 121 may continuously determine whether there is a continuous loss of the heartbeat of the service node 131 for a threshold number of times in the associated service node 131, and in the event that there is a continuous loss of the heartbeat of the service node 131 for the threshold number of times, determine that the service node 131 has a continuous loss of the heartbeat for the threshold number of times passively triggers the offline operation. Alternatively, the threshold number of times may be any value of 2 to 5 times, for example, the threshold number of times may be 3 times.
As an example, the client node 121 may determine whether there is a traffic node 131 in the associated traffic nodes 131 by performing the following steps: monitoring for heartbeat events with the associated service node 131 to determine if there is a lost heartbeat service node 131; in the case of the service node 131 losing the heartbeat, judging whether the service node 131 losing the heartbeat continuously loses the heartbeat for a threshold number of times; and in case that the service node 131 is confirmed to continuously lose the heartbeat for the threshold number of times, confirming that the service node 131 triggers the offline operation, and the service node 131 continuously losing the heartbeat for the threshold number of times is the service node 131 passively triggering the offline operation.
For the case where the service node 131 passively triggers the offline operation, when the client node 121 monitors that there is a link disconnection or a heartbeat loss of the service node 131, the client node 121 may modify the operation state of the service node 131 related to the link disconnection or the heartbeat loss into a suspicious state. In the case that the client node 121 confirms that the relevant service node 131 triggers the offline operation, the client node 121 may modify the running state of the service node 131 that triggers the offline operation into the offline state, and at the same time, the client node 121 may also stop distributing tasks (for example, an outgoing session task) to the service node 131 that triggers the offline operation, and report service information indicating that the service node 131 is offline to the management cluster 160.
In some embodiments, the management cluster 160 may request dynamic modification of configuration information of the configuration cluster 140 through the HTTP protocol interface after receiving traffic information indicating that the traffic node 131 is down, to delete node information about the down-line traffic node 131. Thus, the configuration cluster 140 may not route subsequently received incoming requests to the offline service node 131 any more, based on the configuration information. In some embodiments, the management cluster 160 may broadcast node information about the downstream service node 131, such that the associated client node 121 confirms disconnection from the associated service node 131 if the broadcast information is acquired and the current session task number of the associated service node 131 is 0.
The incoming and outgoing call system 100 of the embodiment of the application can monitor the service node 131 resource use condition in real time in the service process by adding the heartbeat mechanism and adding the management cluster 160, and can realize the dynamic capacity expansion and the dynamic capacity contraction of the service cluster 130 under the conditions of no shutdown maintenance and no influence on the service by intelligent scheduling through the management cluster 160.
In an embodiment of the present application, the service node 131 is automatically managed by the management cluster 160 throughout the process from creation to final destruction. In some embodiments, the incoming and outgoing call systems may be deployed in a containerized manner, thereby reducing the deployment cost of the service node 131. For example, creation of the service node 131 itself may be done by an operator or a Kubernetes (K8 s) container. In some embodiments, all operations of the incoming and outgoing call system 100, except for the manual operations only in the newly added service node 131, have been automated and support thermal expansion of the service cluster 130 without affecting the call service.
In the incoming and outgoing system 100 of the present application, by adding a heartbeat mechanism between the service node 131 and the associated client node 121, when the service node 131 fails or the internal network is congested, the associated client node 121 can quickly identify the failed service node 131, and realize effective disaster recovery of the cluster by suspending sending tasks to the service node 131, kicking out the service node 131, and the like, so as to ensure high availability of services.
Fig. 2-4 illustrate a scheduling method for an incoming and outgoing call system 100 in accordance with one or more embodiments of the present application. In some embodiments, the scheduling methods include the load distribution method 210 shown in fig. 2, the service node addition method 310 shown in fig. 3, and the service node deletion method 410 shown in fig. 4. In an embodiment where the traffic cluster 130 is a FreeSWITCH cluster, the scheduling method for the incoming and outgoing system 100 may be a FreeSWITCH-based and node resource usage-based unfair scheduling algorithm to achieve resource utilization balancing and dynamic expansion of the FreeSWITCH cluster.
Fig. 2 shows a flow diagram of a load distribution method 210. Fig. 2 illustrates a flow of the load distribution method 210 performed by the incoming and outgoing call system 100 in the case of adding the management cluster 160, taking as an example the operation of a certain client node 121 in the client cluster 120. As shown in fig. 2, the load distribution method 210 may include steps S211 to S221.
In some embodiments, step S211 may include: the service node 131 reports its own service information to the associated client node 121 based on the heartbeat mechanism. Wherein the service information may comprise status information indicating an operational status of the service node 131. In some embodiments, the traffic information may also include status information indicating the resource usage status of the traffic node 131. For convenience of description, the "state information of the operation state" will be referred to herein as "operation information", and the "state information of the resource usage state" will be referred to as "resource information".
In the embodiment shown in fig. 2, the client node 121 is associated with two service nodes 131, and the two service nodes 131 respectively perform step S211 to report respective resource information and operation information to the client node 121 through a heartbeat event. In other embodiments, the client node 121 may also be associated with other numbers of service nodes 131, wherein each service node 131 may perform step S211. The client node 121 may aggregate the resource information and the operation information of all the service nodes 131 managed by itself, through step S211.
In some embodiments, step S213 may include: the resource information and the operation information of all service nodes 131 received and summarized are reported to the management cluster 160 by the client node 121 periodically. The management cluster 160 may receive the resource information and the operation information of all the service nodes 131, through step S213.
In some embodiments, step S215 may include: the configuration information is configured or dynamically adjusted for the configuration cluster 140 by the management cluster 160 based on the received traffic information including the resource information and the operation information, in case the configuration information needs to be modified. The configuration information may include routing information required to perform session tasks and node weights of all service nodes 131, among other things. In some embodiments, step S215 may include: by calculation, by the management cluster 160, configuration information of the configuration cluster 140 is dynamically modified through the HTTP interface when it is required. That is, the management cluster 160 may synchronously adjust the node weights of the configuration cluster 140 according to the resource usage of the service cluster 130, thereby implementing the dynamic load of the incoming session task.
In some embodiments, step S217 may include: whether an outgoing request is received is continuously monitored by the client node 121. As an example, an outgoing request may be issued from the traffic layer 110, and accordingly, the client node 121 may monitor whether an outgoing request from the traffic layer 110 is received. In some embodiments, step S217 may further include: upon receipt of an outgoing request, the service node 131 performing the corresponding outgoing session task is assigned to the outgoing request based on the current service information of the associated service node 131 by the client node 121. That is, in the event that an outgoing request arrives at the client node 121, the client node 121 may select an appropriate service node 131 for routing the outgoing request based on the service information of one or more service nodes 131 managed by itself.
In some embodiments, step S219 may include: whether an incoming call request is received is continuously monitored by the configuration node 141. As an example, an incoming call request may be issued from the operator 170 and communicated from the operator 170 to a respective gateway node 151 in the gateway cluster 150, and accordingly, the configuration node 141 may monitor whether an incoming call request from the operator 170 is received. In some embodiments, step S219 may further include: in the case of receiving an incoming call request, the configuration node 141 assigns a service node 131 performing a corresponding incoming call session task to the incoming call request based on the weight values of the plurality of service nodes 131 in the configuration information. That is, in the case where the incoming request arrives at the configuration node 141, the configuration cluster 140 may select an appropriate service node 131 for routing the incoming request according to the configured weight value.
In some embodiments, step S221 may include: whether an incoming session task or an outgoing session task is received is continuously monitored by the service node 131. Wherein incoming session tasks may be routed via configuration node 141 and outgoing session tasks may be routed via client node 121. In case of receiving the assigned incoming or outgoing session task, the service node 131 performs the corresponding incoming or outgoing session task. That is, after the incoming or outgoing session task reaches the designated service node 131 through an appropriate route, the designated service node 131 may perform a related session operation according to the corresponding incoming or outgoing session task.
The load distribution method 210 of the present application can collect and aggregate service information of all service nodes 131 in real time, and perform a dynamic adjustment scheduling policy based thereon. Compared with loading according to a static policy, the load distribution method 210 of the present application does not cause unbalanced resource usage of the whole service cluster 130 due to a large difference between call completing rate and call duration of calls among different tenants, and avoids causing local hot spots of the service cluster 130. The load distribution method 210 of the application adopts a dynamic adjustment scheduling strategy, can effectively improve the resource utilization rate and throughput of the service cluster 130, and realizes the resource use balance of the service node 131 and the stable operation of the service cluster 130.
The load distribution method 210 of the application has stronger universality, is suitable for long-session service, and can perform task distribution according to the actual running condition of the service node 131, thereby solving the problems of uneven session service distribution and uneven resource use caused by longer single service session time of a certain service node 131.
Fig. 3 shows a flow diagram of a service node addition method 310. To be in the case of newly adding a service node 131 in the incoming and outgoing system 100, the service node newly adding method 310 may be performed. As shown in fig. 3, the service node adding method 310 may include steps S311 to S319. As an example, the client node 121 shown in fig. 3 has two associated service nodes 131 (shown as the two service nodes 131 on the far right in fig. 3). In the case where the client node 121 is to newly add an associated service node 131 (shown as the leftmost one of the service nodes 131 in fig. 3), the configuration of the newly added service node 131 can be completed by the following steps S311 to S319.
In some embodiments, step S311 may include: the newly added service node 131 sends its own node information to the management cluster 160. The management cluster 160 may add node information related to the newly added service node 131, via step S311. After step S311, step S313 may be performed by the management cluster 160.
In some embodiments, step S313 may include: in case node information is received from the newly added service node 131, the newly added service node 131 is assigned an associated client node 121 based on the node information and configuration information that causes an association between the newly added service node 131 and the associated client node 121 is issued to the associated client node 121 by the management cluster 160. That is, the management cluster 160 may select an appropriate client node 121 for the newly added service node 131 and issue configuration information of the newly added service node 131 to the appropriate client node 121 to enable the appropriate client node 121 to be associated with the newly added service node 131. In some embodiments, step S313 may further include: in case node information is received from the newly added service node 131, the state information of the newly added service node 131 is modified to a to-be-connected state by the management cluster 160. The associated client node 121 may obtain configuration information of the newly added service node 131, via step S313. After step S313, step S315 may be performed by the associated client node 121.
In some embodiments, step S315 may include: upon receiving the configuration information from the management cluster 160, a link is created by the client node 121 with the newly added service node 131 based on the configuration information. The associated client node 121 may implement link creation based on the acquired configuration information about the newly added service node 131, via step S315. When the link creation is completed, the newly added service node 131 may report its own service information to the associated client node 121 based on a heartbeat mechanism, where the service information reported by the newly added service node 131 to the client node 121 may include status information indicating its normal operation. After the link creation is completed so that the newly added service node 131 operates normally via step S315, the client node 121 may route the associated incoming session task to the newly added service node 131 according to the service information in case of subsequent reception of the outgoing request. In addition, after the newly added service node 131 operates normally, step S317 may be further performed by the management cluster 160.
In some embodiments, step S317 may include: according to the node information of the newly added service node 131, in the case that the newly added service node 131 can perform an incoming call session task as an incoming call node, the configuration information of the associated configuration node 141 is dynamically modified through the HTTP protocol interface. Wherein the modified configuration information may include routing information associated with the newly added service node 131 as well as node weights. After completing the configuration with respect to the newly added service node 131 for the associated configuration node 141 via step S317, step S319 may be further performed by the configuration node 141.
In some embodiments, step S319 may include: in case of subsequent receipt of an incoming call request from the operator 170 by the configuration node 141, the associated incoming call session task is routed to the newly added service node 131 according to the configuration information.
On the basis of adding the management cluster 160 and adding the heartbeat mechanism to the incoming and outgoing system 100, the service node adding method 310 of the application can realize the elastic capacity expansion of the node cluster 130 without affecting the original call service.
Fig. 4 shows a flow diagram of a service node deletion method 410. In case the service node 131 is to be deleted in the incoming and outgoing system 100, the service node deletion method 410 may be performed. The service node deletion method 410 includes steps S411 to S419. As an example, fig. 4 shows a client node 121 having three associated service nodes 131. In case the client node 121 is to delete an associated service node 131 (shown as the leftmost one of the service nodes 131 in fig. 4), the corresponding service node scaling operation may be implemented by the following steps S411 to S419.
In some embodiments, step S411 may include: a determination is made by client node 121 as to whether the associated one or more service nodes 131 exist for which service node 131 triggers a drop operation. In this context, the service node 131 triggering the offline operation indicates that the service node 131 needs to be deleted. As described above, in some embodiments, the service node 131 may trigger the offline operation both actively and passively. For both cases of triggering the offline operation, the client node 121 may determine whether the associated one or more service nodes 131 have a service node 131 triggering the offline operation according to the manner described above, which will not be described herein.
In some embodiments, step S411 may further include: in the case where the presence service node 131 triggers the offline operation, the client node 121 modifies the state information of the service node 131 triggering the offline operation to the offline state. In some embodiments, on the basis of modifying the state information of the service node 131 triggering the offline operation to the offline state, step S411 may further include: the distribution of tasks (e.g., outgoing session tasks) to the service node 131 that triggered the offline operation is stopped by the client node 121. Step S413 may be further performed by the client node 121 on the basis of modifying the state information of the service node 131 triggering the offline operation to the offline state via step S411.
In some embodiments, step S413 may include: traffic information, which may include status information indicating that the traffic node 131 triggering the drop-off operation has been currently dropped off, is reported by the client node 121 to the management cluster 160. The management cluster 160 may learn in time that the service node 131 existing in the service cluster 130 is offline, via step S413. After step S413, step S415 may be further performed by the management cluster 160.
In some embodiments, step S415 may include: in case it is known that a service node 131 is present in the service cluster 130 that it has been down, the configuration information of the associated configuration node 141 is modified by the management cluster 160 to delete the routing information and the node weight of the service node 131 in the down state, so that the subsequently received incoming request by the incoming and outgoing system 100 will no longer be routed to the service node 131 in the down state. After step S415, step S417 may be further performed by the management cluster 160.
In some embodiments, step S417 may include: information about the downstream service node 131 is broadcast by the management cluster 160 (e.g., to the client node 121). In some embodiments, the client node 121 may obtain information about the service node 131 down-line broadcast by the management cluster 160, via step S417. After step S417, step S419 may be further performed by the client node 121.
In some embodiments, step S419 may include: in the case where the current session task number of the service node 131 that is down is zero, the client node 121 confirms whether the link with the service node 131 that is down is disconnected, and in the case where the link is not disconnected, performs the operation of disconnecting the link with respect to the service node 131 that is down.
On the basis of adding the management cluster 160 and adding the heartbeat mechanism to the incoming and outgoing call system 100, the service node deleting method 410 of the application can realize dynamic capacity reduction of the node cluster 130 without affecting the original call service.
The incoming and outgoing call system 100 and the scheduling method for the same provided by the application can acquire the service information of all the service nodes 131 in real time in the scene of large-scale incoming and outgoing call session of the service cluster 130 by adding the management cluster 160 in the incoming and outgoing call system 100 and adding the heartbeat event between the client node 121 and the associated service node 131, and adopt node task scheduling based on the acquired service information, thereby solving the problem of unbalanced service node resource use caused by uneven distribution of the connected session, heterogeneous service node resources and the like, realizing the resource utilization balance and dynamic capacity expansion and contraction of the service cluster 130, and further greatly improving the overall throughput and stability of the service cluster 130.
The above is merely an embodiment of the present application, but the scope of the present application is not limited thereto. Other possible variations or substitutions will occur to those skilled in the art from the teachings disclosed herein and are intended to be within the scope of the present application. The embodiments of the present application and features in the embodiments may also be combined with each other without conflict. The protection scope of the present application is subject to the claims.
Claims (10)
1. An incoming and outgoing call system, characterized in that the incoming and outgoing call system comprises:
a service cluster comprising a plurality of service nodes, each service node of the plurality of service nodes configured to:
executing corresponding incoming call session task or outgoing call session task under the condition that the allocated incoming call session task or outgoing call session task is received; and is also provided with
Reporting self service information through a heartbeat mechanism, wherein the service information comprises state information indicating the running state of a service node;
a client cluster comprising one or more client nodes, each of the one or more client nodes configured to:
receiving service information from associated service nodes in the service cluster through a heartbeat mechanism;
reporting the current service information of the associated service node; and is also provided with
Under the condition that an outgoing call request is received, distributing service nodes for executing corresponding outgoing call session tasks for the outgoing call request based on the current service information of the associated service nodes;
a configuration cluster configured to:
under the condition that an incoming call request is received, distributing service nodes for executing corresponding incoming call tasks to the incoming call request based on the weights of the plurality of service nodes for executing the incoming call tasks; and
A management cluster configured to:
receiving service information of the service cluster from the client cluster; and is also provided with
And configuring weights of the plurality of service nodes for executing the incoming call tasks for the configuration cluster based on the received service information.
2. The incoming and outgoing system of claim 1, wherein the client node is further configured to:
judging whether the service node triggers the offline operation or not in the associated service nodes; and
and under the condition that the existence of the service node triggers the offline operation, modifying the state information of the service node triggering the offline operation into an offline state.
3. The incoming and outgoing system of claim 2, wherein the presence of a service node in the associated service node triggers an offline operation is determined by any one or more of:
judging whether each service node in the associated service nodes is effectively connected, and determining that the service node which is not effectively connected triggers the offline operation under the condition that the service node which is not effectively connected;
judging whether the heartbeat of the service node is continuously lost for a threshold number of times or not in the associated service nodes, and determining that the service node with the heartbeat continuously lost for the threshold number of times triggers the offline operation under the condition that the heartbeat of the service node is continuously lost for the threshold number of times; and
Judging whether a service node is ready for offline based on the received service information of the associated service node, judging whether the service node is ready for offline or not under the condition that the service node is ready for offline, and determining that the service node is ready for offline triggers offline operation under the condition that the service node is ready for offline meets the offline condition.
4. The incoming and outgoing system of claim 1, wherein the service cluster is further configured to: under the condition of adding service nodes, the added service nodes send node information to the management cluster;
the management cluster is further configured to: assigning an associated client node to the newly added service node upon receiving node information from the newly added service node, and issuing configuration information associated with the newly added service node to the associated client node;
the client node is further configured to: upon receiving the configuration information from the management cluster, creating a link with the newly added service node based on the configuration information.
5. The incoming and outgoing system of claim 1, wherein the service node is a FreeSWITCH node, the client node is an ESL node, and the configuration cluster is an OpenSIPS cluster.
6. A scheduling method for an incoming and outgoing call system, the incoming and outgoing call system comprising a service cluster, a client cluster, a configuration cluster, and a management cluster, wherein the service cluster comprises a plurality of service nodes, the client cluster comprises one or more client nodes, the scheduling method comprising:
reporting, by the plurality of service nodes, respective service information to an associated client node via a heartbeat mechanism, the service information including status information indicative of an operational status of the service node;
reporting current service information of the associated service node to the management cluster by the client node;
configuring, by the management cluster, weights of the plurality of service nodes to perform incoming session tasks for the configuration cluster based on the received service information;
under the condition that the client node receives the calling request, distributing service nodes for executing corresponding calling session tasks for the calling request based on the current service information of the associated service nodes;
under the condition that the configuration cluster receives the incoming call request, distributing service nodes for executing corresponding incoming call session tasks to the incoming call request based on the weight; and
And executing the corresponding incoming session task or outgoing session task by the service node under the condition of receiving the allocated incoming session task or outgoing session task.
7. The scheduling method of claim 6, further comprising the step of, by the client node:
judging whether the service node triggers the offline operation or not in the associated service nodes; and
and under the condition that the existence of the service node triggers the offline operation, modifying the state information of the service node triggering the offline operation into an offline state.
8. The scheduling method of claim 7, wherein determining whether a service node trigger drop-out exists in the associated service node is performed by any one or more of:
judging whether each service node in the associated service nodes is effectively connected, and determining that the service node which is not effectively connected triggers the offline operation under the condition that the service node which is not effectively connected;
judging whether the heartbeat of the service node is continuously lost for a threshold number of times or not in the associated service nodes, and determining that the service node with the heartbeat continuously lost for the threshold number of times triggers the offline operation under the condition that the heartbeat of the service node is continuously lost for the threshold number of times; and
Judging whether a service node is ready for offline based on the received service information of the associated service node, judging whether the service node is ready for offline or not under the condition that the service node is ready for offline, and determining that the service node is ready for offline triggers offline operation under the condition that the service node is ready for offline meets the offline condition.
9. The scheduling method of claim 6, wherein the scheduling method further comprises:
under the condition of adding service nodes, the added service nodes send node information to the management cluster;
assigning, by the management cluster, an associated client node to the newly added service node upon receiving node information from the newly added service node, and issuing configuration information associated with the newly added service node to the associated client node; and
creating, by the client node, a link with the newly added service node based on the configuration information upon receiving the configuration information from the management cluster.
10. The scheduling method of claim 6, wherein the service node is a FreeSWITCH node, the client node is an ESL node, and the configuration cluster is an OpenSIPS cluster.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311474415.8A CN117201677A (en) | 2023-11-08 | 2023-11-08 | Incoming and outgoing call system and scheduling method for incoming and outgoing call system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311474415.8A CN117201677A (en) | 2023-11-08 | 2023-11-08 | Incoming and outgoing call system and scheduling method for incoming and outgoing call system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117201677A true CN117201677A (en) | 2023-12-08 |
Family
ID=88989120
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311474415.8A Pending CN117201677A (en) | 2023-11-08 | 2023-11-08 | Incoming and outgoing call system and scheduling method for incoming and outgoing call system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117201677A (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1434393A (en) * | 2003-02-24 | 2003-08-06 | 武汉大学 | Dynamic loading balance method for cluster server |
| CN102447624A (en) * | 2011-11-23 | 2012-05-09 | 成都市华为赛门铁克科技有限公司 | Load balancing method in server cluster, as well as node server and cluster |
| CN104994156A (en) * | 2015-07-01 | 2015-10-21 | 北京京东尚科信息技术有限公司 | Load balancing method and system for cluster |
| CN107592429A (en) * | 2017-09-07 | 2018-01-16 | 北方联创通信有限公司 | A kind of more seat multimedia dispatching systems |
| CN111835927A (en) * | 2020-07-21 | 2020-10-27 | 上海茂声智能科技有限公司 | System and method for improving high concurrency performance and stability of telephone robot |
| CN113727464A (en) * | 2021-09-18 | 2021-11-30 | 睿云联(厦门)网络通讯技术有限公司 | Method and device for establishing high-concurrency call of SIP streaming media server |
| CN114615141A (en) * | 2022-03-11 | 2022-06-10 | 贝壳找房网(北京)信息技术有限公司 | Communication control method |
| CN115720204A (en) * | 2022-11-23 | 2023-02-28 | 证通股份有限公司 | Fault detection method and system for VoIP communication network element |
-
2023
- 2023-11-08 CN CN202311474415.8A patent/CN117201677A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1434393A (en) * | 2003-02-24 | 2003-08-06 | 武汉大学 | Dynamic loading balance method for cluster server |
| CN102447624A (en) * | 2011-11-23 | 2012-05-09 | 成都市华为赛门铁克科技有限公司 | Load balancing method in server cluster, as well as node server and cluster |
| CN104994156A (en) * | 2015-07-01 | 2015-10-21 | 北京京东尚科信息技术有限公司 | Load balancing method and system for cluster |
| CN107592429A (en) * | 2017-09-07 | 2018-01-16 | 北方联创通信有限公司 | A kind of more seat multimedia dispatching systems |
| CN111835927A (en) * | 2020-07-21 | 2020-10-27 | 上海茂声智能科技有限公司 | System and method for improving high concurrency performance and stability of telephone robot |
| CN113727464A (en) * | 2021-09-18 | 2021-11-30 | 睿云联(厦门)网络通讯技术有限公司 | Method and device for establishing high-concurrency call of SIP streaming media server |
| CN114615141A (en) * | 2022-03-11 | 2022-06-10 | 贝壳找房网(北京)信息技术有限公司 | Communication control method |
| CN115720204A (en) * | 2022-11-23 | 2023-02-28 | 证通股份有限公司 | Fault detection method and system for VoIP communication network element |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102037709B (en) | Resource pool in blade cluster switching center server | |
| CN103583063B (en) | System and method for the fault recovery of geographic redundancy gateway | |
| EP3264723B1 (en) | Method, related apparatus and system for processing service request | |
| US20150142958A1 (en) | Control node and communication control method | |
| US20080183991A1 (en) | System and Method for Protecting Against Failure Through Geo-Redundancy in a SIP Server | |
| CN107124453B (en) | Load balancing system for platform interconnection gateway stacking deployment and video calling method | |
| CN103685461B (en) | A kind of cluster management device, management system and management method | |
| US10911295B2 (en) | Server apparatus, cluster system, cluster control method and program | |
| US9621599B2 (en) | Communication system, communication method, and call control server | |
| CN111093162A (en) | Method for intelligently selecting short message sending channel | |
| CN106464516B (en) | Event handling in a network management system | |
| CN108183849B (en) | Device management method, device and system based on L2TP | |
| JP5444331B2 (en) | Blade cluster switching center server and signaling method | |
| WO2016058297A1 (en) | Method and system for achieving load balancing between virtual network elements, and virtual network elements | |
| WO2010127625A2 (en) | Seats processing method, exchange and call center | |
| CN117201677A (en) | Incoming and outgoing call system and scheduling method for incoming and outgoing call system | |
| CN114553704B (en) | A method and system for supporting simultaneous access of multiple devices to a server for capacity expansion and contraction | |
| JPH10243095A (en) | Traffic load distribution control system for multi-processor control exchange | |
| CN109005564B (en) | Method and system for distributing MME (mobility management entity) load | |
| US20050198022A1 (en) | Apparatus and method using proxy objects for application resource management in a communication network | |
| CN115967684B (en) | Data transmission method, device, electronic equipment and computer readable storage medium | |
| JPH11501495A (en) | Communication links interconnecting service control points of load balancing groups for traffic management control | |
| CN114679412B (en) | Method, device, equipment and medium for forwarding traffic to service node | |
| CN116208496A (en) | A distributed service monitoring and automatic operation and maintenance processing system | |
| JP2025047801A (en) | Control device, control method, and program for controlling network functions based on disaster information |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |