Conference processing method, electronic device, medium and product

Abstract

The application discloses a conference processing method, an electronic device, a medium and a product. The method comprises the following steps: receiving a conference initiation request sent by a terminal, wherein the conference initiation request comprises a user identifier corresponding to the terminal; determining a target central server from at least two central servers in a video conference system according to attribute information of the at least two central servers and the user identifier, wherein the at least two central servers are in an active state, each of the central servers in the active state receives available media resource information reported by an edge media cluster, and the available media resource information is used to indicate that each of the central servers allocates media resources for a conference; and sending the conference initiation request to the target central server. The application can improve the resource utilization efficiency of the video conference system.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method for processing meetings, electronic devices, media, and products. Background Technology

[0002] Video conferencing systems are a crucial component of modern enterprise communication. With the development of cloud computing and distributed technologies, traditional single-center video conferencing systems can no longer meet the demands for high availability and disaster recovery. Current technologies primarily employ a primary / backup center model, where each video conferencing system has one primary center server and at least one backup center server. The primary center server handles all business, while the backup center server remains idle. Under this approach, the backup center server remains idle for extended periods, resulting in wasted hardware and network resources and low resource utilization efficiency. Summary of the Invention

[0003] This application provides a method for processing meetings, an electronic device, a medium, and a product, aiming to improve the resource utilization efficiency of video conferencing systems.

[0004] In a first aspect, embodiments of this application provide a conference processing method applied to a gateway device, comprising: The receiver terminal sends a meeting initiation request, wherein the meeting initiation request includes the user identifier corresponding to the terminal; The target central server is determined from the at least two central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier. The at least two central servers are both in an active state. Each of the central servers in the active state receives available media resource information reported by the edge media cluster. The available media resource information is used to instruct each of the central servers to allocate media resources for the conference. Send the meeting initiation request to the target central server.

[0005] Secondly, embodiments of this application provide a meeting processing method applied to a target central server, comprising: The receiving terminal sends a conference initiation request through a gateway device. The conference initiation request includes a user identifier corresponding to the terminal. The target central server is determined based on the attribute information of at least two central servers in the video conferencing system and the user identifier. The at least two central servers are both in an active state. Each of the central servers in the active state receives available media resource information reported by the edge media cluster. The available media resource information is used to instruct each of the central servers to allocate media resources for the conference. Create the first meeting based on the meeting initiation request.

[0006] Thirdly, embodiments of this application provide an electronic device, including: at least one processor; at least one memory for storing at least one program; and when at least one of the programs is executed by at least one of the processors, implementing the conference processing method as described in the first aspect.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for performing the conference processing method as described in the first aspect.

[0008] Fifthly, embodiments of this application provide a computer program product, including a computer program or computer instructions, the computer program or computer instructions being stored in a computer-readable storage medium, a processor of an electronic device reading the computer program or computer instructions from the computer-readable storage medium, and the processor executing the computer program or computer instructions to cause the electronic device to perform the processing method of the meeting as described in the first aspect.

[0009] In this application, after receiving a conference initiation request from a terminal, the gateway device determines the target central server from among multiple active central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier carried in the request, and then sends the conference initiation request to the target central server. Through this method, the gateway device can rationally allocate conference services based on the real-time attribute information of each central server. Compared with the existing master-slave mode, by ensuring that at least two central servers are active and each receives available media resource information reported by the edge media cluster, the gateway device can rationally allocate conference services among multiple available central servers, avoiding overload of a single central server and improving the overall resource utilization efficiency of the video conferencing system. Attached Figure Description

[0010] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0011] Figure 1 This is a flowchart illustrating the meeting processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the components of the video conferencing system provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the meeting processing method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the meeting processing method provided in an embodiment of this application; Figure 5This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] Exemplary embodiments will be described more fully below with reference to the accompanying drawings; however, the described exemplary embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will enable those skilled in the art to fully understand the scope of this application.

[0014] As used herein, the term "and / or" includes any and all combinations of one or more related enumerated purposes.

[0015] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of a feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded.

[0016] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0017] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in common dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in the embodiments of this application.

[0018] It should be understood that in the description of the embodiments of this application, the use of terms such as "first" and "second" is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of technical features indicated, or implicitly indicating the order of the technical features indicated. "At least one" refers to one or more, and "more" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any group of these items, including any group of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0019] To facilitate understanding of the solutions in the embodiments of this application, some contents involved in the embodiments of this application are described below: Video conferencing systems are a crucial component of modern enterprise communication. With the development of cloud computing and distributed technologies, traditional single-center video conferencing systems can no longer meet the demands for high availability and disaster recovery. Current technologies primarily employ a primary / backup center model, where each video conferencing system has one primary server and one backup server. The primary server handles all business operations, while the backup server remains idle. This technical solution has the following drawbacks: First, low resource utilization: the backup center server is idle for a long time, resulting in a waste of hardware and network resources; Second, the failover time is long: when the main central server fails, the backup central server needs to be started and the business needs to be migrated, which takes a long time. Third, media resource isolation: the media resources of the main center server and the backup center server are isolated from each other, making resource sharing impossible and resulting in uneven resource allocation; Fourth, recovery from anomalies is difficult: when a central server malfunctions, the resources it occupies on the edge media cannot be released in a timely manner, affecting the overall performance of the system.

[0020] Therefore, the primary / backup center model in existing technologies cannot meet the requirements for high availability and resource sharing.

[0021] To address the aforementioned technical problems, this application proposes a conference processing method applied to a gateway device. The conference processing method provided by this application will be described in detail below with reference to the accompanying drawings and through some embodiments and application scenarios.

[0022] See Figure 1 , Figure 1 This is a flowchart illustrating a meeting processing method provided in an embodiment of this application.

[0023] like Figure 1 As shown, the conference processing method is applied to the gateway device, and the conference processing method includes, but is not limited to, the following S101, S102 and S103.

[0024] S101, receive a conference initiation request sent by the terminal, wherein the conference initiation request includes the user identifier corresponding to the terminal.

[0025] In this embodiment, the gateway device can be a traffic splitting gateway. The gateway device is responsible for receiving conference initiation requests sent by terminals and distributing these requests to the corresponding central server according to the traffic splitting strategy. The terminal can be a video conferencing client, such as a PC client, a mobile app, or a hardware video conferencing terminal.

[0026] The aforementioned meeting initiation request includes the user identifier corresponding to the terminal. This user identifier can be the user's registered account in the video conferencing system or the user's application identifier (appid).

[0027] In addition, the aforementioned meeting initiation request may also include meeting requirement information, such as parameters like meeting type, number of participants, meeting duration, and media quality requirements. Meeting type may include instant meetings and scheduled meetings; the number of participants indicates the number of terminals expected to participate; and media quality requirements may include video resolution, audio sampling rate, etc.

[0028] In this embodiment, after receiving a meeting initiation request sent by the terminal, the gateway device obtains the user identifier and meeting requirement information by parsing the meeting initiation request.

[0029] S102, determine the target central server from the at least two central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier, wherein the at least two central servers are in an active state, and each of the central servers in the active state receives available media resource information reported by the edge media cluster, and the available media resource information is used to instruct each of the central servers to allocate media resources for the conference.

[0030] In this embodiment, at least two central servers in the video conferencing system are both active, meaning that both central servers simultaneously handle the service, rather than a primary / standby mode where one is active and the other is idle. Each active central server receives available media resource information reported by the edge media cluster, which is used to instruct each central server to allocate media resources for the conference.

[0031] The attribute information of the aforementioned central server includes its operating status and target information. The operating status indicates whether the central server is currently available, and includes normal and abnormal states. The target information includes at least one of load information and location information, used to assist the gateway device in selecting the optimal central server.

[0032] Specifically, the gateway device can execute a user-feature scheduling policy based on the user identifier to determine the target central server from at least two central servers. For example, the gateway device executes the center selection policy as follows: First, it queries the user's home center configuration based on the user identifier. If the user has already configured a central server as the home center corresponding to that user identifier, and the home center is in a normal operating state, then that home center is selected as the target central server. If the user has not configured a home center or the home center is in an abnormal state, then the target central server can be further selected from at least two central servers based on the target information of the central server.

[0033] The central server corresponding to the aforementioned user identifier refers to the home center that the user pre-configures in the video conferencing system. Each user can configure one home center server, and the gateway device maintains the mapping relationship between user identifiers and home center servers.

[0034] For example, suppose a video conferencing system includes central server 1 and central server 2, and user A's home center is configured as central server 1. When user A sends a conference initiation request through a terminal, the gateway device first queries user A's home center configuration to determine that user A belongs to central server 1, and then checks the operating status of central server 1. If the operating status of central server 1 is normal, then central server 1 is determined as the target central server.

[0035] For example, if user B has not configured a home center, or if the home center server to which user B belongs is in an abnormal state, the gateway device will execute a load balancing strategy and select the home center server with the lowest load as the target home center server based on the load information of each available home center server.

[0036] S103, send the meeting initiation request to the target center server.

[0037] In this embodiment, after the gateway device determines the target central server, it forwards the meeting initiation request sent by the terminal to the determined target central server. For example, when forwarding the meeting initiation request, the gateway device can also attach routing information to the request. This routing information may include a gateway identifier, a routing timestamp, etc., so that the target central server can perform subsequent processing.

[0038] In addition, if all centers in the video conferencing system are unavailable, an error message indicating that the system is busy can be returned to the terminal, ending the meeting initiation request.

[0039] In this embodiment, after receiving a conference initiation request from a terminal, the gateway device determines the target central server from among multiple active central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier carried in the request, and then sends the conference initiation request to the target central server. Through this method, the gateway device can rationally allocate conference services based on the real-time attribute information of each central server. Compared with the existing master-slave mode, by ensuring that at least two central servers are active and each receives available media resource information reported by the edge media cluster, the gateway device can rationally allocate conference services among multiple available central servers, avoiding overload of a single central server and improving the overall resource utilization efficiency of the video conferencing system. In one embodiment, the attribute information includes running status and target information, wherein the target information includes at least one of load information and location information; The step of determining the target central server from the at least two central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier includes any one of the following: In response to the existence of a central server corresponding to the user identifier among the at least two central servers, and the central server corresponding to the user identifier being in an available state, the central server corresponding to the user identifier is determined as the target central server. In response to the absence of a central server corresponding to the user identifier among the at least two central servers, or the central server corresponding to the user identifier being in an unavailable state, a target central server is selected from the at least two central servers based on the target information of each of the available central servers.

[0040] In this embodiment, the aforementioned available state refers to the state where the central server is operating normally and can receive and process conference requests. The gateway device can determine the operating status of each central server by periodically receiving heartbeat messages or health check responses from the central server.

[0041] The above-mentioned situations where there is no central server corresponding to the user identifier include situations where the user has not configured a home center, or where the user's home center configuration information is lost.

[0042] The aforementioned unavailability state refers to a state where the central server is unable to receive and process conference requests due to reasons such as failure, maintenance, or network interruption. When the central server corresponding to a user identifier is in an unavailable state, the gateway device needs to select another available central server to handle the conference request.

[0043] In this embodiment, the process of determining the central server can first employ a user-feature-based scheduling strategy. That is, if a central server corresponding to a user identifier exists among at least two central servers, and the central server corresponding to the user identifier is in an available state, then the central server corresponding to the user identifier is directly determined as the target central server. If a central server corresponding to a user identifier does not exist among at least two central servers, or the central server corresponding to the user identifier is in an unavailable state, then a load balancing strategy can be used to select the target central server from at least two central servers based on the target information of each available central server.

[0044] When using a load balancing strategy, the gateway device can first obtain a list of all candidate central servers that are in an available state, and then select one based on the load information or location information of each candidate central server.

[0045] For example, if user D has not configured a home center, the gateway device will find that both central server 1 and central server 2 are available. If a load-based selection method is used, the load of the two central servers will be compared, and the central server with the lower load will be selected as the target central server. If central server 1 currently has 50 meetings, CPU utilization of 60%, and memory utilization of 55%, while central server 2 currently has 30 meetings, CPU utilization of 40%, and memory utilization of 35%, then central server 2 will be selected as the target central server.

[0046] For example, if a location-based selection method is adopted, the central server closest to the terminal is selected as the target central server based on the geographical location of the terminal and the geographical location of each central server.

[0047] In this embodiment, the target central server corresponding to the terminal is determined first based on the user's affiliation. When the target central server cannot be determined according to the user's affiliation, the target central server is selected based on the load information and / or location information of each central server, thus ensuring the stability of user service scheduling.

[0048] In one embodiment, in response to the target information being the load information, selecting a target central server from the at least two central servers based on the target information of each of the central servers in an available state includes: The overall load score of each central server is determined based on the load information of each central server, wherein the load information includes at least one of the following: number of meetings, CPU utilization, memory utilization, and network bandwidth utilization of the central server. The central server with the lowest overall load score is identified as the target central server.

[0049] In this embodiment, if the target information is load information, the comprehensive load score of each central server can be determined based on the load information of each central server, and the central server with the lowest comprehensive load score can be determined as the target central server.

[0050] The above-mentioned number of meetings refers to the total number of meetings currently being processed by the central server. A higher number of meetings indicates a heavier workload for the central server. The above-mentioned CPU utilization rate refers to the utilization rate of the central processing unit of the central server, reflecting the usage of computing resources. The above-mentioned memory utilization rate refers to the proportion of memory used by the central server, reflecting the usage of memory resources. The above-mentioned network bandwidth utilization rate refers to the proportion of network bandwidth used by the central server, reflecting the usage of network resources.

[0051] In this embodiment, the gateway device can calculate the overall load score of each central server based on at least one of the load indicators mentioned above: number of meetings, CPU utilization, memory utilization, and network bandwidth utilization. The overall load score can be calculated using a weighted summation method. For example, the formula for calculating the overall load score can be: S = w1 * C + w2 * M + w3 * N + w4 * K, Where S is the overall load score, C is the CPU utilization rate, M is the memory utilization rate, N is the network bandwidth utilization rate, K is the normalized value of the number of meetings, and w1, w2, w3, and w4 are the weighting coefficients of each load indicator.

[0052] The weighting coefficients mentioned above can be configured according to the actual needs of the system. For example, in video conferencing scenarios, network bandwidth utilization has a significant impact on meeting quality, so a higher weight can be set; w1 can be set to 0.25, w2 to 0.20, w3 to 0.35, and w4 to 0.20.

[0053] For example, if the CPU utilization of central server 1 is 50%, the memory utilization is 45%, the network bandwidth utilization is 60%, the current number of meetings is 40, and its normalized value is 0.4, then the overall load score of central server 1 is S1 = 0.25*50 +0.20*45 + 0.35*60 + 0.20*40 = 12.5 + 9 + 21 + 8 = 50.5.

[0054] For example, if the CPU utilization of central server 2 is 30%, the memory utilization is 35%, the network bandwidth utilization is 40%, the current number of meetings is 25, and its normalized value is 0.25, then the overall load score of central server 2, S2, is: S2 = 0.25*30 + 0.20*35 + 0.35*40 + 0.20*25 = 7.5 + 7 + 14 + 5 = 33.5.

[0055] Since S2 is less than S1, central server 2 is determined as the target central server.

[0056] In this embodiment, by comprehensively evaluating multi-dimensional load indicators, the central server with the lowest load is selected as the target central server, which can achieve load balancing and improve the overall resource utilization efficiency of the system.

[0057] In one embodiment, the method further includes: Receive a status anomaly indication sent by the first central server, wherein the status anomaly indication includes an anomaly center identifier; According to the status anomaly indication, the status of the central server corresponding to the anomaly center identifier is updated to an anomaly status. The anomaly status is used to indicate that new meetings should not be assigned to the central server corresponding to the anomaly status. The first central server is any one of the at least two central servers.

[0058] In this embodiment, the gateway device can also receive status anomaly indications from each central server and update the status of the central server according to the status anomaly indications.

[0059] Specifically, the gateway device receives a status anomaly indication sent by the first central server. The first central server can be any one of at least two central servers. The status anomaly indication includes an anomaly center identifier, used to indicate which central server has experienced an anomaly.

[0060] Based on the status anomaly indication, the gateway device can update the status of the central server corresponding to the anomaly center identifier to an anomaly state. This anomaly state is used to indicate that new meetings should not be assigned to the central server corresponding to the anomaly state.

[0061] For example, the gateway device maintains a central server status table, which records whether each central server is currently in a normal or abnormal state. When the gateway device receives a status abnormality indication, it changes the status of the corresponding central server from normal to abnormal in the status table.

[0062] For example, if central server 1 fails, central server 2, acting as the first central server, sends a status anomaly indication to the gateway device. This indication includes the anomaly center identifier as "Center 1". Upon receiving this indication, the gateway device updates the status of central server 1 in its status table to an anomaly state.

[0063] In subsequent conference request distribution, the gateway device will no longer allocate new conference requests to the central server 1, which is in an abnormal state, but will instead route all new conference requests to the central server 2, which is in a normal state.

[0064] In this embodiment, by receiving status anomaly indications in a timely manner and updating the status of the central server, the gateway device can quickly detect central anomalies and adjust the routing strategy based on the abnormal status of the central server to avoid allocating new services to the abnormal central server and ensure the normal creation of new meetings.

[0065] In one embodiment, the method further includes: Receive a route recovery request sent by the first central server, wherein the route recovery request includes an identifier of the recovered center; According to the route recovery request, the status of the central server corresponding to the recovered central identifier is updated to normal status. The normal status is used to indicate that the recovery will allocate a new meeting to the central server corresponding to the normal status. The first central server is any one of the at least two central servers.

[0066] In this embodiment, after updating the status of the central server to an abnormal state, the gateway device can also receive a route recovery request sent by the first central server and restore the status of the corresponding central server to a normal state.

[0067] Specifically, the gateway device can receive route recovery requests sent by the first central server. These route recovery requests can be sent by a central server that has resumed normal operation, or they can be forwarded through other normal central servers.

[0068] The aforementioned route recovery request includes a recovered center identifier, indicating which center server has returned to normal operation. The route recovery request can be initiated by the center server after completing fault repair, or it can be triggered by the disaster recovery management service in other center servers after confirming that the center server has returned to normal operation.

[0069] In this embodiment, after receiving a route recovery request, the gateway device updates the status of the central server corresponding to the recovered central identifier to a normal status based on the route recovery request. This normal status indicates that new meetings will be allocated to the central server corresponding to the normal status.

[0070] For example, after central server 1 recovers from a fault, central server 2, acting as the first central server, sends a route recovery request to the gateway device. This request includes the recovered center identifier as "Center 1". Upon receiving this route recovery request, the gateway device updates the status of central server 1 in its maintained central server status table from an abnormal state back to a normal state. Then, in subsequent traffic distribution strategies, the gateway device reinstates central server 1 into the list of available centers and distributes new meeting requests to central server 1 according to the normal load balancing strategy, thus restoring the dual-center active-active operation mode.

[0071] In this embodiment, when the central server recovers from the abnormal state, the routing device is updated with the operating status of the central server in a timely manner through a routing recovery request, so that the recovered central server can resume business, realize the automatic recovery and load balancing of the two centers, and improve the resource utilization of the system.

[0072] This application also proposes a meeting processing method applied to a target central server, the method comprising: The receiving terminal sends a conference initiation request through a gateway device. The conference initiation request includes a user identifier corresponding to the terminal. The target central server is determined based on the attribute information of at least two central servers in the video conferencing system and the user identifier. The at least two central servers are both in an active state. Each of the central servers in the active state receives available media resource information reported by the edge media cluster. The available media resource information is used to instruct each of the central servers to allocate media resources for the conference. Create the first meeting based on the meeting initiation request.

[0073] In this embodiment, the target central server is determined from at least two central servers based on the attribute information and user identifier of at least two central servers in the video conferencing system. It is the central server used to accept the meeting initiation request. This target central server can receive available media resource information reported by the edge media cluster, which is used to instruct each central server to allocate media resources for the meeting.

[0074] In this embodiment, the target center server receives a meeting initiation request sent by the terminal through the gateway device. The meeting initiation request includes the user identifier corresponding to the terminal, and optional meeting requirement information, which includes at least one of the following: meeting type, number of participants, and media quality requirements.

[0075] After receiving a meeting initiation request, the target central server first verifies the validity of the request. This verification includes checking the validity of the user ID, the user's permission to create a meeting, and the validity of the meeting parameters. If the validity verification passes, the first meeting is then created. This first meeting refers to the meeting instance created on the target central server for the meeting initiation request.

[0076] In some embodiments, the meeting creation process may include: generating a meeting identifier for a first meeting, which is used for subsequent management and referencing of the meeting; determining meeting parameters for the first meeting, which may include meeting topic, participant limit, meeting duration, media quality level, etc.; and allocating meeting control resources for the first meeting, which may include meeting control threads, signaling processing resources, etc.

[0077] In this embodiment, the target central server is determined based on the attribute information and user identifier of each central server. The selected target central server receives the conference initiation request and creates the conference, which can realize the reasonable distribution of conference services among multiple central servers, avoid overload of a single center, and improve the overall resource utilization efficiency of the system.

[0078] In one embodiment, creating a first meeting based on the meeting initiation request includes: Based on the meeting request information in the meeting initiation request and the available media resource information reported by multiple edge media clusters, the target media cluster is determined from the multiple edge media clusters. Send a resource request to the target media cluster; In response to receiving the resource allocation result sent by the target media cluster, the first conference is created based on the resource allocation result.

[0079] In this embodiment, during the process of the target central server creating the first meeting based on the meeting initiation request, it is necessary to determine the target media cluster from the edge media cluster and allocate resources.

[0080] Specifically, the target central server can determine the target media cluster from multiple edge media clusters based on the meeting requirement information in the meeting initiation request and the available media resource information reported by multiple edge media clusters.

[0081] The aforementioned available media resource information includes the number of available media channels, the number of available codec resources, and geographical location of each edge media cluster. The target center server maintains a locally cached edge media cluster resource status table, which periodically receives updates on the resource status reported by each edge media cluster.

[0082] In some embodiments, the target central server can calculate the resource requirements of the first meeting based on meeting demand information. For example, if the first meeting requires 10 participants and 1080p video quality, the required number of media channels is calculated to be 10 video channels plus 10 audio channels, and the required encoding and decoding resources are determined based on the video resolution and encoding format.

[0083] The target central server can then filter edge media clusters that meet the resource requirements based on the aforementioned resource availability. Filtering criteria include: the number of available media channels is greater than or equal to the required number of channels, sufficient available codec resources, and network bandwidth meeting transmission requirements.

[0084] When multiple edge media clusters meet the requirements, the target central server can select the optimal cluster based on either geographical proximity or resource sufficiency. For example, it can prioritize selecting the edge media cluster geographically closest to most participants to reduce network transmission latency; or it can select the cluster with the most abundant resources to ensure meeting quality.

[0085] In some embodiments, after determining the target media cluster, the target central server sends a resource request to the selected target media cluster. This resource request includes parameters such as conference identifier, required number of media channels, codec format, and bandwidth requirements. The codec format can be H.264, H.265, or AAC, etc.

[0086] After receiving a resource request, the target media cluster first verifies the validity of the request and checks whether its currently available resources meet the requirements. If the resources meet the requirements, the target media cluster allocates media channels and codec resources, creates a media session context, generates a media session identifier, media transmission address, encryption key, and other information, and obtains the resource allocation result based on the above operations. Then, the target media cluster returns the resource allocation result to the conference control service of the target central server, and the returned information includes: media session identifier, media transmission address, codec parameters, session validity period, etc. The target center server responds by receiving the resource allocation results sent by the target media cluster and creates the first meeting based on the resource allocation results.

[0087] If resource allocation fails due to insufficient resources, network anomalies, equipment malfunctions, or other reasons, the target media cluster returns an error code and error description to the target central server. The target central server can choose to retry with other edge media clusters. After the number of retries exceeds the retry threshold, a resource allocation failure error message is returned to the terminal. The retry threshold can be 3 times.

[0088] For example, suppose the target central server selects edge media cluster A as the target media cluster and sends a resource request to it. After verifying that the resources meet the request requirements, edge media cluster A allocates 10 video channels and 10 audio channels, creates a media session context, generates a media session identifier and media transmission address, and returns this information to the target central server. The target central server then uses this information to complete the creation of the first meeting.

[0089] In this embodiment, through a globally shared edge media cluster resource pool, the target central server can select the optimal edge media cluster from the media resources of the entire system for resource allocation, thereby achieving unified resource management and scheduling, and improving resource utilization and meeting creation success rate.

[0090] In one embodiment, after creating the first meeting based on the meeting initiation request, the method further includes: Construct the meeting information for the first meeting, wherein the meeting information includes meeting identifier, meeting status, cluster identifier of the target media cluster corresponding to the first meeting, media resource information, meeting topic, creation time, creating user, and at least one item from the list of participants; The meeting information of the first meeting is saved to the database of the target center server.

[0091] In this embodiment, after the target center server creates the first meeting according to the meeting initiation request, it can construct the meeting information of the first meeting and save the meeting information to the database of the target center server.

[0092] Specifically, the aforementioned meeting information may include at least one of the following: meeting identifier, meeting status, cluster identifier of the target media cluster corresponding to the first meeting, media resource information, meeting topic, creation time, creating user, and list of participants.

[0093] The meeting identifier is information used to uniquely identify the meeting, such as "CONF-20250712-001"; the meeting status includes "in progress", "ended", "resumed", etc.; the cluster identifier is used to indicate the edge media cluster that allocated media resources to the meeting, such as "CLUSTER-A"; media resource information includes media session identifier, media transmission address, codec parameters, etc.; the meeting topic is the title or description of the meeting; the creation time is the timestamp of the meeting creation; the creating user is the user identifier of the user who initiated the meeting; the participant list is a list of user identifiers participating in the meeting.

[0094] The target central server saves the meeting information of the first meeting to a local database, which can be PostgreSQL. The saving process can employ a transaction mechanism to ensure data consistency and integrity.

[0095] For example, after creating the first meeting, the target central server constructs the following meeting information: the meeting identifier is "CONF-20250712-001", the meeting status is "in progress", the cluster identifier of the target media cluster is "CLUSTER-A", the media resource information includes the media session identifier "MEDIA-001" and the transport address "192.168.1.100:10000-10009", the meeting topic is "Project Weekly Meeting", the creation time is "2025-07-12 09:00:00", the creating user is "User E", and the list of participants includes "User E, User F, User G", etc. The target central server saves this information to the meeting table in the database.

[0096] In this embodiment, by persisting the meeting information to the database, it is ensured that the meeting data will not be lost due to the restart or failure of the central server; at the same time, it provides a data foundation for subsequent data synchronization and disaster recovery, and ensures the consistency of data in each central server.

[0097] In addition, after successfully creating the first meeting, the target center server can also return a response message to the terminal through its meeting control service. This response message may include: meeting identifier, meeting access address, media access parameters, meeting validity period, etc., to inform the terminal that the meeting has been established.

[0098] In one embodiment, after saving the meeting information of the first meeting to the database of the target center server, the method further includes: The meeting information of the first meeting is sent to other central servers besides the target central server in the video conferencing system.

[0099] In this embodiment, after saving the meeting information of the first meeting to the local database, the target central server sends the meeting information of the first meeting to other central servers outside the target central server in the video conferencing system.

[0100] In some embodiments, at least two central servers in a video conferencing system can deploy the pgsync component and configure bidirectional synchronization rules. These synchronization rules include: the scope of the central server synchronization table in the video conferencing system includes the conference table, user table, and resource table, etc.; a synchronization latency threshold; and a conflict resolution strategy. The synchronization latency threshold can be 100ms, and the conflict resolution strategy can be last-write-first, meaning that when multiple centers modify the same data almost simultaneously, the modification with the later timestamp takes precedence, overwriting the earlier write.

[0101] When data changes occur in the database of any central server in the video conferencing system, the pgsync component captures the change event and encapsulates the changed data into a synchronization message. This synchronization message is transmitted via a dedicated network to the pgsync components on other central servers, where the components parse the message and apply it to their local databases.

[0102] For example, assuming the target central server is central server 1, after it saves the meeting information of the first meeting to its local PostgreSQL database, the pgsync component captures this insert operation, generates a synchronization message, and sends it to central server 2 via a dedicated network. Upon receiving the synchronization message, the pgsync component on central server 2 inserts the meeting information into the meeting table of its local database.

[0103] In some embodiments, if synchronization fails due to network interruption, abnormality of the peer center, or other reasons, the pgsync component will cache the synchronization message in a local queue and automatically retry after the network is restored. It is necessary to ensure eventual data consistency across at least two central servers in the video conferencing system. Furthermore, at least two central servers can periodically perform data consistency checks, configurable to once per hour, and automatically repair any data inconsistencies detected.

[0104] In this embodiment, a two-way data synchronization mechanism is used to ensure that the meeting data of at least two central servers in the video conferencing system remains consistent, so that any central server can query complete meeting information; when a disaster recovery switch occurs, the taking over central server can obtain the latest meeting data to ensure business continuity.

[0105] In one embodiment, the method further includes: In response to determining that the second central server is abnormal, a status abnormality indication is sent to the gateway device, wherein the status abnormality indication includes an abnormal center identifier, and the status abnormality indication is used to instruct the gateway device to stop allocating new meetings to the central server corresponding to the abnormal center identifier; The second central server is any central server other than the target central server in the video conferencing system.

[0106] In this embodiment, if the target central server determines that the second central server is malfunctioning, it sends a status malfunction indication to the gateway device. The second central server can be any central server other than the target central server in the video conferencing system.

[0107] In some embodiments, the target central server can determine whether the second central server is abnormal through its disaster recovery management service. Anomaly detection methods may include: receiving notifications of multiple consecutive failed health checks, detecting a fault in the second central server, or receiving shutdown or isolation operations for the second central server.

[0108] Specifically, the disaster recovery management service of the target central server can periodically send health check requests to both central servers. If N consecutive health checks fail, the corresponding central server is determined to be abnormal, where N can be 3 or 5.

[0109] If the second central server is determined to be abnormal, the target central server sends a status abnormality indication to the gateway device. This status abnormality indication includes an abnormal central server identifier, indicating which central server has experienced the abnormality. This status abnormality indication instructs the gateway device to stop allocating new meetings to the central server corresponding to the abnormal central server identifier.

[0110] For example, suppose the target central server is Central Server 1, which detects an anomaly in Central Server 2 through its disaster recovery management service. Central Server 1 sends an anomaly status indication to the gateway device, which includes the identifier of the abnormal central server as "Center 2". Upon receiving this indication, the gateway device stops allocating new meeting requests to Central Server 2.

[0111] In this embodiment, the abnormal status of the other central server of the gateway device is promptly notified by the normal central server, so as to realize the rapid adjustment of the routing policy, avoid new services being assigned to the abnormal center, and ensure the availability of the system.

[0112] In one embodiment, the method further includes: In response to the determination that there is an anomaly on the second central server, take over the second meeting that is running on the second central server.

[0113] In this embodiment, if the target central server determines that the second central server is malfunctioning, it can take over the second meeting currently running on the second central server. Taking over means that the target central server gains control of the second meeting, ensuring that the meeting service can continue to operate even in abnormal circumstances. The number of second meetings can be one or more.

[0114] In some embodiments, the target central server retrieves the meeting information of the second meeting running on the second central server from the database. Due to a data synchronization mechanism, the meeting information of the second meeting has been synchronized to the database of the target central server. Based on the meeting information of the second meeting, the target central server sends a resource release notification to the edge media cluster corresponding to the second meeting, then reallocates media resources for the second meeting, and sends a meeting resumption notification to the terminal devices corresponding to the second meeting, thereby completing the takeover of the second meeting.

[0115] For example, suppose that conference "CONF-002" is running on central server 2. After central server 1 detects an anomaly in central server 2, it retrieves the conference information of "CONF-002" from the database, takes over control of the conference, and ensures that the participants can continue the video conference.

[0116] In this embodiment, based on the data synchronization of the central server, a normal central server can take over the conference services of an abnormal central server, realize the automatic recovery of conference services, ensure uninterrupted conferences, and improve the disaster recovery capability of the system.

[0117] In one embodiment, taking over a second meeting running on the second central server includes: Based on the meeting information of the second meeting, a resource release notification is sent to the edge media cluster corresponding to the second meeting, wherein the resource release notification is used to instruct the release of media resources occupied by the second meeting corresponding to the second central server; Media resources are allocated to the second meeting, and a meeting resumption notification is sent to the terminal device corresponding to the second meeting.

[0118] In this embodiment, during the process of the target central server taking over the second conference running on the second central server, the target central server first sends a resource release notification to the edge media cluster corresponding to the second conference based on the conference information of the second conference. This resource release notification is used to instruct the release of media resources occupied by the second conference corresponding to the second central server.

[0119] Specifically, the aforementioned meeting information may include a meeting identifier, a list of participants, media resource information, and an edge media cluster identifier. The target center server extracts the edge media cluster identifier and media session identifier corresponding to the second meeting from the meeting information and sends a resource release notification to the corresponding edge media cluster. The resource release notification may include: an abnormal center identifier, a list of media session identifiers to be released, the release reason, and a release timestamp. The release reason may be an abnormality occurring on the second center server.

[0120] After receiving the resource release notification, the edge media cluster corresponding to the second meeting can further perform resource release operations: First, the edge media cluster can verify the legality of the resource release notification, check whether the media session identifier exists and whether it belongs to the second central server; then, stop the corresponding media channel, release the codec resources, delete the media session context; update the local resource status table, mark the released resources as available; and return a resource release confirmation message to the target central server.

[0121] After the resources are released, the target central server allocates media resources for the second meeting. The allocation process is similar to the resource allocation when a new meeting is created: the target central server queries the locally cached edge media cluster resource status table, selects the edge media cluster that meets the meeting's resource requirements, sends a resource request to the selected edge media cluster, and then receives the resource allocation result and updates the media resource information in the meeting record.

[0122] After resource allocation is complete, the target center server sends a meeting resumption notification to the terminal devices corresponding to the second meeting. This notification includes the new meeting access address, media access parameters, meeting resumption time, etc.

[0123] After receiving the meeting resumption notification, participants' terminals re-establish media connections based on the new media access parameters, and the meeting continues. The resumption process is transparent to users; participants only need to wait a short time to restore audio and video communication.

[0124] In this embodiment: by releasing the media resources occupied by the anomaly center and reallocating the resources, the media resources are ensured to be fully and effectively utilized; and by issuing a meeting recovery notification, the participating terminals are automatically reconnected, thereby achieving automatic recovery of the meeting service and improving the user experience of disaster recovery switching.

[0125] In one embodiment, allocating media resources for the second conference includes: In response to the existence of multiple second meetings, media resources are allocated to the multiple second meetings in descending order of their meeting priority.

[0126] In this embodiment, if there are multiple second conferences, the target central server allocates media resources to the multiple second conferences in descending order of their conference priority.

[0127] In some embodiments, the meeting priorities mentioned above can be determined based on factors such as the importance of the meeting, the number of participants, and the type of meeting. For example, high-level management meetings and large training meetings can be set as high priority; regular departmental meetings can be set as medium priority; and ad-hoc meetings can be set as low priority.

[0128] For example, meeting priorities can be specified by the user who creates the meeting, or they can be automatically assigned by the system according to preset rules. For instance, meetings with more than 50 participants are automatically set to high priority; meetings whose topics contain keywords such as "urgent" or "important" are also set to high priority.

[0129] In some embodiments, when the target central server takes over multiple second meetings, it first sorts the multiple second meetings according to their meeting priorities, and then allocates and restores resources in order from high priority to low priority.

[0130] In addition, if resources are insufficient to resume all second meetings, the target center server will resume high-priority meetings according to their priority, and return a resource shortage notification for low-priority meetings, suggesting that users retry later or reduce the meeting size.

[0131] In this embodiment, by prioritizing meetings, important meetings are ensured to be resumed first, thereby prioritizing the continuity of core business under limited resources.

[0132] In one embodiment, the method further includes: In response to determining that the second central server is abnormal, a first status push message is sent to the second central server, wherein the first status push message includes the operating status of the target central server and the operating status of the second central server; In response to receiving the first recovery confirmation message sent by the second central server, the operating status of the second central server is updated to normal status; A route recovery request is sent to the gateway device, which instructs the gateway device to resume allocating meetings to the second central server.

[0133] In this embodiment, if the target central server determines that the second central server is malfunctioning, it sends a first status push message to the second central server. This first status push message includes the operating status of both the target central server and the second central server.

[0134] In some embodiments, the aforementioned status push messages are periodically sent by the disaster recovery management service of the target central server. The first status push message includes: the status of the target central server, the status of the second central server, the number of currently active meetings, system load information, etc. The periodic sending cycle can be 10 seconds or 20 seconds. The status of the first central server can be either a primary status or a normal status, while the status of the second central server can be an abnormal status.

[0135] In some embodiments, if the network of the second central server is interrupted, the target central server caches the first status push message in its local queue and retryes it after the network is restored. If the target central server receives the first recovery confirmation message sent by the second central server, it updates the operating status of the second central server to the normal state.

[0136] The first recovery confirmation message mentioned above is sent by the second central server after completing its local cleanup process. Upon receiving the first status push message, the second central server detects its own status as "abnormal" and triggers the local cleanup process: it queries all meeting records in the local database to identify any remaining meeting services from before the failure; it sends a meeting termination notification to the local meeting control service to terminate all remaining meetings; it updates the meeting status in the database to "terminated" for any remaining meetings; and it clears the locally cached meeting status and resource usage information. After completing the cleanup, the second central server sends the first recovery confirmation message to the target central server.

[0137] After updating the status of the second center server to normal, the target center server sends a route recovery request to the gateway device. This route recovery request instructs the gateway device to resume allocating meetings to the second center server. Upon receiving the route recovery request, the gateway device adds the second center server back to the list of available centers.

[0138] In this embodiment, the normal central server continuously pushes status information to the abnormal central server, triggering the abnormal central server to perform automatic cleanup. After the abnormal central server completes the cleanup and recovery, the multi-center active operation mode is restored without manual intervention, thus improving the self-healing capability of the video conferencing system.

[0139] In one embodiment, the method further includes: Receive the second status push message sent by the second central server; In response to the second status push message indicating that the target center server is in an abnormal operating state, the meeting information on the target center server is cleared. A second recovery confirmation message is sent to the second central server, wherein the second recovery confirmation message is used to indicate that the operating status of the target central server has been restored to normal.

[0140] In this embodiment, if the target central server receives a second status push message sent by the second central server, and the second status push message indicates that the target central server itself is in an abnormal state, it performs local cleanup.

[0141] In some embodiments, if the second status push message indicates that the target center server is in an abnormal operating state, the target center server performs the following local cleanup process: Clean up meeting information on the target center server: Query all meeting records in the local database to identify the remaining meeting services before the failure; send a meeting termination notification to the local meeting control service to terminate all remaining meetings; update the meeting status in the database to "terminated" for the remaining meetings, and record the termination reason as a failure of the target center server; then clean up the locally cached meeting status and resource usage information.

[0142] In some embodiments, after the target central server completes local cleanup, it sends a second recovery confirmation message to the second central server. This second recovery confirmation message indicates that the target central server's operating status has returned to normal.

[0143] For example, if central server 1 was previously abnormal, upon recovery, it receives a second status push message from central server 2. Central server 1 detects its own "abnormal" status and performs local cleanup: terminating all remaining meetings, updating the meeting status to "terminated," and clearing the cache. After completion, it sends a second recovery confirmation message to central server 2. Based on this, central server 2 updates central server 1's status to normal and notifies the gateway device to restore routing.

[0144] In this embodiment, after the abnormal central server recovers, it automatically triggers a local cleanup process by receiving a status push message to release the resource occupation left over during the failure, ensuring that the system returns to an active running state without resource residue and avoiding data inconsistency between multiple central servers.

[0145] In one embodiment, the method further includes: The second central server is determined to be abnormal if at least one of the following conditions is met: The system receives K consecutive health check failure responses from the second central server, where K is a positive integer. A malfunction was detected in the second central server; Receive shutdown or isolation operations for the second central server.

[0146] In this embodiment, the abnormality determination conditions of the central server include the following conditions one, two and three. As long as at least one of the abnormality determination conditions is met, it can be determined that the central server is abnormal.

[0147] Specifically, condition one is that the health check response from the second central server is received K consecutive times as a health check failure, where K is a positive integer.

[0148] In some embodiments, the aforementioned health check is periodically performed by the disaster recovery management service of any central server. The check includes the status of the central control service, database connection status, network connectivity, system resource utilization, etc. The default value of K can be 3, and the execution cycle of the health check can be 5 seconds, that is, if the health check fails for 15 consecutive seconds, the central server is considered abnormal.

[0149] For example, if the disaster recovery management service sends health check requests to the central server 2 three times in a row, and the central server 2 does not respond or the response times out, then the central server 2 is determined to be abnormal.

[0150] Condition two is: A fault is detected in the second central server. These faults include sudden failures such as power outages, network outages, crashes of critical service processes, and database inaccessibility. Fault detection can be achieved through monitoring system alarms, service heartbeat timeouts, and network probing. For example, if the database service process of central server 2 exits abnormally and an alarm is reported on the monitoring system, then central server 2 is determined to be faulty.

[0151] Condition three is: receiving user requests to disable or isolate the second-center server. These disable or isolation operations are manually triggered by operations and maintenance personnel through the management portal (Uportal).

[0152] For example, if operations and maintenance personnel need to perform system upgrades or hardware maintenance on central server 2, they can select "Disable Center" or "Isolate Center" through the management portal, enter the reason for the operation, and confirm the information. The management portal sends a disable or isolation request to the disaster recovery management service, which records the operation log and triggers the corresponding disaster recovery switchover process.

[0153] In this embodiment, multiple anomaly detection conditions are used to ensure that the system can detect abnormal states of the central server in a timely and accurate manner.

[0154] In addition, the disaster recovery management service of any central server can perform anomaly recovery monitoring.

[0155] Specifically, the disaster recovery management service monitors the disaster recovery switchover progress in real time, recording the execution time and results of each step. If any anomalies occur during the disaster recovery switchover process, such as resource allocation failure or unresponsive edge media clusters, the disaster recovery management service records the anomaly log and triggers an alarm. The disaster recovery management service pushes a disaster recovery switchover status notification to the management portal, informing operations and maintenance personnel of the disaster recovery switchover progress and results. After the disaster recovery switchover is completed, the disaster recovery management service generates a disaster recovery switchover report, which includes: failure time, failure cause, switchover time, number of restored meetings, resource release status, etc.

[0156] For ease of understanding, the following specific embodiments are provided as examples: The following embodiments are implemented in a video conferencing system, and the architecture of the video conferencing system is as follows: Figure 2 As shown, the video conferencing system includes user terminals, a gateway device for traffic splitting (i.e., a traffic splitting gateway), and two central servers: Central Server 1 and Central Server 2. Each central server includes a conference control service, a disaster recovery management service, a management portal, and a PG database. Furthermore, the system includes N edge media clusters (Edge Media Cluster 1 to Edge Media Cluster N), distributed in different geographical locations and communicating with both central servers, simultaneously reporting available media resource information to both servers.

[0157] Example 1 See Example 1 Figure 3 The steps of a video conferencing system in a normal business process include: Step 1: The user initiates a meeting request through the client. User E clicks the "Create Meeting" button on the computer client of the enterprise video conferencing system, enters the meeting topic "Project Weekly Meeting", selects 10 participants, and sets the video quality to 1080p. The client generates a meeting initiation request, which includes parameters such as User E's user ID, meeting type, number of participants, and media quality requirements, and sends the request to the gateway device used for traffic splitting.

[0158] Step 2: The gateway device executes the central server selection strategy. After receiving the conference initiation request, the gateway device parses the user identifier. It queries the user's home center configuration and determines that user E's home center is central server 1. The gateway device checks that central server 1's operating status is "normal," thus successfully identifying central server 1 as the target central server. Furthermore, if center selection fails, an error message can be directly returned to the client to inform them that the conference cannot proceed.

[0159] Step 3: The gateway device forwards the conference initiation request. The gateway device forwards the conference initiation request to the central server 1.

[0160] Step 4: Central Server 1 creates the meeting. After receiving the meeting initiation request, the meeting control service on Central Server 1 generates a meeting identifier, queries the locally cached edge media cluster resource status table to determine if an available edge media cluster exists. If an available edge media cluster exists, the target media cluster is selected from among them. For example, if both edge media cluster A and edge media cluster B meet the resource requirements, edge media cluster A is selected as the target media cluster based on the principle of geographical proximity. Alternatively, if no available edge media cluster exists, an error message can be directly returned to the client to inform them that the meeting cannot proceed.

[0161] Step 5: Resource Allocation. Central server 1 sends a resource request to edge media cluster A, requesting the creation of media channels and codec resources. For example, it can request 10 video channels and 10 audio channels. After verifying that the resources are sufficient, edge media cluster A creates the resources and returns resource information such as media session identifier and transport address to the conference control service of central server 1. Furthermore, if resource creation fails, an error message can be directly returned to the client to inform the client that the conference cannot proceed.

[0162] Step 6: Meeting Information Saving and Synchronization. Central Server 1 constructs the meeting information and saves it to a local PostgreSQL database. The pgsync component captures data changes and synchronizes the meeting information to the database on Central Server 2.

[0163] Step 7: Return creation result. Central server 1 returns a successful meeting creation response to the client, including meeting identifier, meeting access address, media parameters, etc. The meeting is now established.

[0164] Example 2: Example 2 describes a video conferencing system with two active central servers, namely Central Server 1 and Central Server 2. See [link to example]. Figure 4 The steps in the video conferencing system's anomaly recovery process include: Step 1: Fault Detection. The disaster recovery management service periodically sends health check requests to Central Server 1 and Central Server 2. Assume that Central Server 1 fails to respond to health checks three consecutive times due to a network failure. The disaster recovery management service determines that Central Server 1 is faulty.

[0165] Step 2: Status Update and Notification. The disaster recovery management service of central server 2 marks central server 1 as "abnormal" and sends an abnormal status indication to the gateway device, instructing the gateway device to stop allocating new services to central server 1. This gateway device is a traffic distribution gateway.

[0166] Step 3: Routing Policy Adjustment. After receiving the status anomaly indication, the gateway device removes Central Server 1 from the list of available central servers. All subsequent new conference requests will be routed to Central Server 2; that is, the routing gateway stops allocating new conference services to Central Server 1.

[0167] Step 4: Business Takeover. Central Server 2 queries the database to obtain a list of all active meetings running on Central Server 1. For example, all active meetings on Central Server 1 include meetings "CONF-002" and "CONF-003". Central Server 2 takes over these meetings in order of priority.

[0168] Step 5: Resource Release. Central server 2 sends a resource release notification to the edge media clusters corresponding to conferences "CONF-002" and "CONF-003", instructing them to release the media resources originally occupied by central server 1. The edge media clusters return a confirmation message after performing the resource release operation.

[0169] Step 6: Meeting Resumption. Central server 2 reallocates media resources for meetings "CONF-002" and "CONF-003", and then sends a meeting resumption notification to the participating terminals. After receiving the notification, the participating terminals re-establish media connections, and the meeting continues.

[0170] Step 7: Status Push. The disaster recovery management service of central server 2 periodically sends dual-center status push messages to central server 1. Even if the network of central server 1 is interrupted, the message will be cached and retried.

[0171] Step 8: Anomaly Center Recovery and Cleanup. Assume the network failure of Central Server 1 is repaired. Central Server 1 receives a status message pushed by Central Server 2, detects its own status as "anomaly," and triggers a local cleanup process: terminating all remaining meetings, updating the meeting status to "terminated," and clearing the local cache. Upon completion, it sends a recovery confirmation message to Central Server 2.

[0172] Step 9: Active-Active Recovery. After receiving the recovery confirmation message, Central Server 2 updates the status of Central Server 1 to "Normal" and sends a route recovery request to the gateway device. The gateway device adds Central Server 1 back to the list of available centers. The system resumes active-active dual-center operation.

[0173] It should be noted that the various embodiments described in this application can be combined with each other or implemented individually without conflict, and this application does not limit this.

[0174] This application also provides an electronic device, such as... Figure 5 As shown, the electronic device 1700 includes: One or more processors 1710; The memory 1720 stores one or more programs that, when executed by one or more processors 1710, cause the one or more processors 1710 to implement the conference processing method described in any of the above embodiments.

[0175] Memory 1720, as a non-transitory network system, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory 1720 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 1720 may optionally include remotely located memories 1720 relative to processor 1710, which can be connected to processor 1710 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0176] The memory 1720 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1720 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1720 and is called and executed by the processor 1710.

[0177] The processor 1710 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0178] In some embodiments, the electronic device further includes: Input / output interfaces are used to implement information input and output; The communication interface is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). The bus transmits information between various components of the device (such as processor 1710, memory 1720, input / output interfaces, and communication interfaces); The processor 1710, memory 1720, input / output interface, and communication interface can communicate with each other within the device via a bus.

[0179] One embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions for performing a conference processing method as provided in any embodiment of this application.

[0180] One embodiment of this application also provides a computer program product, including a computer program or computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the computer device to perform a conference processing method as provided in any embodiment of this application.

[0181] The system architecture and application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that as system architectures evolve and new application scenarios emerge, the technical solutions provided in this application are also applicable to similar technical problems.

[0182] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0183] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0184] The above description, with reference to the accompanying drawings, illustrates some embodiments of this application, but does not limit the scope of this application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of this application shall be within the scope of this application.

Claims

1. A method for processing a conference, applied to a gateway device, comprising: The receiver terminal sends a meeting initiation request, wherein the meeting initiation request includes the user identifier corresponding to the terminal; The target central server is determined from the at least two central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier. The at least two central servers are both in an active state. Each of the central servers in the active state receives available media resource information reported by the edge media cluster. The available media resource information is used to instruct each of the central servers to allocate media resources for the conference. Send the meeting initiation request to the target central server.

2. The method according to claim 1, characterized in that, The attribute information includes running status and target information, and the target information includes at least one of load information and location information; The step of determining the target central server from the at least two central servers based on the attribute information of at least two central servers in the video conferencing system and the user identifier includes any one of the following: In response to the existence of a central server corresponding to the user identifier among the at least two central servers, and the central server corresponding to the user identifier being in an available state, the central server corresponding to the user identifier is determined as the target central server. In response to the absence of a central server corresponding to the user identifier among the at least two central servers, or the central server corresponding to the user identifier being in an unavailable state, a target central server is selected from the at least two central servers based on the target information of each of the available central servers.

3. The method according to claim 2, characterized in that, In response to the target information being the load information, the step of selecting a target central server from the at least two central servers based on the target information of each of the central servers in their available state includes: The overall load score of each central server is determined based on the load information of each central server, wherein the load information includes at least one of the following: the number of meetings, CPU utilization, memory utilization, and network bandwidth utilization of the central server. The central server with the lowest overall load score is identified as the target central server.

4. The method according to claim 1, characterized in that, The method further includes: Receive a status anomaly indication sent by the first central server, wherein the status anomaly indication includes an anomaly center identifier; According to the status anomaly indication, the status of the central server corresponding to the anomaly center identifier is updated to an anomaly status. The anomaly status is used to indicate that new meetings should not be assigned to the central server corresponding to the anomaly status. The first central server is any one of the at least two central servers.

5. The method according to claim 1, characterized in that, The method further includes: Receive a route recovery request sent by the first central server, wherein the route recovery request includes an identifier of the recovered center; According to the route recovery request, the status of the central server corresponding to the recovered central identifier is updated to normal status. The normal status is used to indicate that the recovery will allocate a new meeting to the central server corresponding to the normal status. The first central server is any one of the at least two central servers.

6. A method for processing a conference, applied to a target central server, comprising: The receiving terminal sends a conference initiation request through a gateway device. The conference initiation request includes a user identifier corresponding to the terminal. The target central server is determined based on the attribute information of at least two central servers in the video conferencing system and the user identifier. The at least two central servers are both in an active state. Each of the central servers in the active state receives available media resource information reported by the edge media cluster. The available media resource information is used to instruct each of the central servers to allocate media resources for the conference. Create the first meeting based on the meeting initiation request.

7. The method according to claim 6, characterized in that, The step of creating a first meeting based on the meeting initiation request includes: Based on the meeting request information in the meeting initiation request and the available media resource information reported by multiple edge media clusters, the target media cluster is determined from the multiple edge media clusters. Send a resource request to the target media cluster; In response to receiving the resource allocation result sent by the target media cluster, the first conference is created based on the resource allocation result.

8. The method according to claim 6, characterized in that, After creating the first meeting based on the meeting initiation request, the method further includes: Construct the meeting information for the first meeting, wherein the meeting information includes meeting identifier, meeting status, cluster identifier of the target media cluster corresponding to the first meeting, media resource information, meeting topic, creation time, creating user, and at least one item from the list of participants; The meeting information of the first meeting is saved to the database of the target center server.

9. The method according to claim 8, characterized in that, After saving the meeting information of the first meeting to the database of the target center server, the method further includes: The meeting information of the first meeting is sent to other central servers besides the target central server in the video conferencing system.

10. The method according to claim 6, characterized in that, The method further includes: In response to determining that the second central server is abnormal, a status abnormality indication is sent to the gateway device, wherein the status abnormality indication includes an abnormal center identifier, and the status abnormality indication is used to instruct the gateway device to stop allocating new meetings to the central server corresponding to the abnormal center identifier; The second central server is any central server other than the target central server in the video conferencing system.

11. The method according to claim 6, characterized in that, The method further includes: In response to the determination that there is an anomaly on the second central server, take over the second meeting that is running on the second central server.

12. The method according to claim 11, characterized in that, The takeover of the second meeting running on the second central server includes: Based on the meeting information of the second meeting, a resource release notification is sent to the edge media cluster corresponding to the second meeting, wherein the resource release notification is used to instruct the release of media resources occupied by the second meeting corresponding to the second central server; Media resources are allocated to the second meeting, and a meeting resumption notification is sent to the terminal device corresponding to the second meeting.

13. The method according to claim 12, characterized in that, The allocation of media resources for the second meeting includes: In response to the existence of multiple second meetings, media resources are allocated to the multiple second meetings in descending order of their meeting priority.

14. The method according to claim 6, characterized in that, The method further includes: In response to determining that the second central server is abnormal, a first status push message is sent to the second central server, wherein the first status push message includes the operating status of the target central server and the operating status of the second central server; In response to receiving the first recovery confirmation message sent by the second central server, the operating status of the second central server is updated to normal status; A route recovery request is sent to the gateway device, which instructs the gateway device to resume allocating meetings to the second central server.

15. The method according to claim 6, characterized in that, The method further includes: Receive the second status push message sent by the second central server; In response to the second status push message indicating that the target center server is in an abnormal operating state, the meeting information on the target center server is cleared. A second recovery confirmation message is sent to the second central server, wherein the second recovery confirmation message is used to indicate that the operating status of the target central server has been restored to normal.

16. The method according to any one of claims 10-14, characterized in that, The method further includes: The second central server is determined to be abnormal in response to at least one of the following conditions: The system receives K consecutive health check failure responses from the second central server, where K is a positive integer. A malfunction was detected in the second central server; Receive shutdown or isolation operations for the second central server.

17. An electronic device comprising: At least one processor; At least one memory for storing at least one program; The conference processing method of any one of claims 1 to 16 is implemented when at least one of the programs is executed by at least one of the processors.

18. A computer-readable storage medium storing computer-executable instructions for performing the conference processing method according to any one of claims 1 to 16.

19. A computer program product comprising a computer program or computer instructions stored in a computer-readable storage medium, wherein a processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions to cause the electronic device to perform the conference processing method according to any one of claims 1 to 16.

Images